-用户需求分析[]PPT课件
合集下载
相关主题
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
等。
.
第10页 共60页
2.1 需求分析慨论
（5）用户网络容量和性能需求分析 • 用户业务的时间规律； • 用户业务产生的网络流量规律； • 用户业务的安全需求； • 用户业务的可靠性需求； • 用户业务的最低带宽需求； • 用户业务最低响应时间需求。
.
第11页 共60页
2.1 需求分析慨论
2.1.4 需求分析中存在的问题 • 没有足够多的用户参与 • 用户的需求不断增加 • 模棱两可的需求 • 不必要的特性 • 过于精简的需求说明 • 不准确的计划
2.1 需求分析慨论
• 真正的“需求”实际上存在于人们的脑海中。任何 文档形式的需求（如需求说明书）仅是一个模型， 一种叙述。
• 定义：
网络工程需求分析的目的是描述网络系统的行为特征 与约束条件，指明网络系统必须实现的具体指标。
.
第3页 共60页
2.1 需求分析慨论
2.1.2 需求开发与管理 （1）需求开发
.
第19页 共60页
2.2 网络用户需求获取
2.2.3 需求获取中的沟通 • 需求过程中充满了沟通。 • 口头沟通：
沟通应该坦白、明确，不要产生误导或使用户难以 理解。沟通过程中，双方在某些问题上可能有截然 不同的理解。 • 会议和座谈： 会议可以促进用户对项目的了解，最后应当形成会议 备忘录之类的文档。
2.2 网络用户需求获取
• 如果用户是网络工程师不了解的一个行业或专业， 需求小组中最好有一个专家，而最终用户是最好的 专家。
• 如果需求获取的行业难度不是很大，网络工程师可 以通过自我学习，在短时间内了解用户的行业。
• 如果是进行系统更新，网络工程师应检查和使用目 前的旧系统。
• 网络工程师在大部分情况下可以通过调查来获取用 户需求。
第2章 用户需求分析 主讲：刘文硕
2.1 需求分析慨论
2.1.1 需求的定义 • IEEE软件工程定义的需求：
1）用户解决问题或达到目标所需要的条件或要求。 2）系统满足合同、标准、规范或其它正式规定文档 所需具有的条件或要求。 3）反映上面1）或2）所描述的条件或要求的文档说 明。
.
第2页 共60页
.
第5页 共60页
2.1 需求分析慨论
2.1.3 需求分析的工作内容 • 用户需求分析内容如表2-1所示。
.
第6页 共60页
2.1 需求分析慨论
（1）用户网络环境分析 • 用户建筑物布局情况，及建筑物之间的最大距离； • 外部网络接入点位置； • 网络中心机房位置； • 设备间的位置及电源供应情况； • 信息点数量及位置； • 两个用户之间的最大距离； • 用户部门的地理分布情况； • 特殊的需求或限制条件。
语等专业问题。 • 清楚的说明用户需求并不断完善它们。 • 系统需求说明应当力求准确详细。 • 对需求做出决策时，不要使用含糊不清的表态。 • 尊重网络工程师的成本估算和对需求的分析。 • 对一个复杂的网络系统，应当对单项需求、系统特
性等划分优先实现的等级。 • 评审网络工程师提出的需求分析文档和模型。
• 如果网络工程面向的是特定行业或特定用户，可以 由特定用户提交业务需求书。
• 如果系统集成商与用户有长期合作关系，可以在合 作过程中培养用户提出需求和表达需求的能力。
• 如果网络工程项目是面向市场的，那么市场的声音 都是用户的需求。系统集成商应当主动选择用户、 细分市场、定位系统。
.
第18页 共60页
.
第14页 共60页
2.2 网络用户需求获取
• 对需求进行变更时，网络工程师应当对成本、影响、 得失有真实可信的评估。
• 获得满足用户功能和质量要求的系统，并且这些要 求是开发人员同意的。
.
第15页 共60页
2.2 网络用户需求获取
（3）用户的义务 • 给网络工程师讲解用户业务，并说明业务方面的术
需求获取 需求分析 需求文档 需求验证 • 需求分析的结果是技术文档及相关分析模型。 • 需求分析文档定义了网络工程项目的需求基线。
.
第4页 共60页
2.1 需求分析慨论
（2）需求管理 • 很难分辨出需求管理和需求分析的差别，大多数网
络工程师在进行需求分析工作时，已经不知不觉的 在开展需求管理和需求分析两种活动。 • 需求管理包括以下工作： 需求跟踪 需求变更 需求评估
（3）用户网络服务需求分析 • 数据库和应用软件的共享服务需求； • 文件传输和存取的服务需求； • 网站系统建设和应用的服务需求； • 电子邮件系统的建设和应用需求； • 网络远程访问服务的需求； • 网络视频服务需求； • 企业IP电话的需求等。
.
第9页 共60页
2.1 需求分析慨论
（4）用户通信类型比例分析 • 数据、语音、视频等业务在应用中所占的比例； • 是否有无线通信、无线漫游通信、卫星通信的需求
.
第16页 共60页
2.2 网络用户需求获取
• 用户一旦对需求进行变更时，要马上与网络工程师 联系。
• 在进行需求变更时，应对遵照网络工程师确定的工 作流程来处理。
• 尊重网络工程师对需求分析采用的工作流程。
.
Hale Waihona Puke Baidu
第17页 共60页
2.2 网络用户需求获取
2.2.2 需求获取的方法
• 网络工程由需求驱动，需求源于用户的需要。
.
第12页 共60页
2.2 网络用户需求获取
2.2.1 用户的权利与义务 （1）用户的特点 • 用户是经过筛选的 • 用户是沉默的 • 用户是难以满足的 • 用户是可引导的
.
第13页 共60页
2.2 网络用户需求获取
（2）用户的权利 • 使用符合用户语言习惯的表达方式。 • 了解用户网络系统的业务及目标。 • 获取用户需求信息，并编写需求分析说明书。 • 对需求工作结果进行解释说明。 • 在交流过程中保持合作的职业态度。 • 对网络系统的实现及需求提供建议。 • 描述网络系统的基本特性。 • 允许用户利用已有的网络系统。
.
第7页 共60页
2.1 需求分析慨论
（2）用户网络设备状态分析 • 用户现有的计算机数量及分布情况； • 今后几年中用户信息点的可能增长情况； • 现有网络设备型号、性能、数量及技术参数； • 模拟通信设备，如电话、传感器、视频设备； • 现有网络设备之间的物理连接等。
.
第8页 共60页
2.1 需求分析慨论
.
第10页 共60页
2.1 需求分析慨论
（5）用户网络容量和性能需求分析 • 用户业务的时间规律； • 用户业务产生的网络流量规律； • 用户业务的安全需求； • 用户业务的可靠性需求； • 用户业务的最低带宽需求； • 用户业务最低响应时间需求。
.
第11页 共60页
2.1 需求分析慨论
2.1.4 需求分析中存在的问题 • 没有足够多的用户参与 • 用户的需求不断增加 • 模棱两可的需求 • 不必要的特性 • 过于精简的需求说明 • 不准确的计划
2.1 需求分析慨论
• 真正的“需求”实际上存在于人们的脑海中。任何 文档形式的需求（如需求说明书）仅是一个模型， 一种叙述。
• 定义：
网络工程需求分析的目的是描述网络系统的行为特征 与约束条件，指明网络系统必须实现的具体指标。
.
第3页 共60页
2.1 需求分析慨论
2.1.2 需求开发与管理 （1）需求开发
.
第19页 共60页
2.2 网络用户需求获取
2.2.3 需求获取中的沟通 • 需求过程中充满了沟通。 • 口头沟通：
沟通应该坦白、明确，不要产生误导或使用户难以 理解。沟通过程中，双方在某些问题上可能有截然 不同的理解。 • 会议和座谈： 会议可以促进用户对项目的了解，最后应当形成会议 备忘录之类的文档。
2.2 网络用户需求获取
• 如果用户是网络工程师不了解的一个行业或专业， 需求小组中最好有一个专家，而最终用户是最好的 专家。
• 如果需求获取的行业难度不是很大，网络工程师可 以通过自我学习，在短时间内了解用户的行业。
• 如果是进行系统更新，网络工程师应检查和使用目 前的旧系统。
• 网络工程师在大部分情况下可以通过调查来获取用 户需求。
第2章 用户需求分析 主讲：刘文硕
2.1 需求分析慨论
2.1.1 需求的定义 • IEEE软件工程定义的需求：
1）用户解决问题或达到目标所需要的条件或要求。 2）系统满足合同、标准、规范或其它正式规定文档 所需具有的条件或要求。 3）反映上面1）或2）所描述的条件或要求的文档说 明。
.
第2页 共60页
.
第5页 共60页
2.1 需求分析慨论
2.1.3 需求分析的工作内容 • 用户需求分析内容如表2-1所示。
.
第6页 共60页
2.1 需求分析慨论
（1）用户网络环境分析 • 用户建筑物布局情况，及建筑物之间的最大距离； • 外部网络接入点位置； • 网络中心机房位置； • 设备间的位置及电源供应情况； • 信息点数量及位置； • 两个用户之间的最大距离； • 用户部门的地理分布情况； • 特殊的需求或限制条件。
语等专业问题。 • 清楚的说明用户需求并不断完善它们。 • 系统需求说明应当力求准确详细。 • 对需求做出决策时，不要使用含糊不清的表态。 • 尊重网络工程师的成本估算和对需求的分析。 • 对一个复杂的网络系统，应当对单项需求、系统特
性等划分优先实现的等级。 • 评审网络工程师提出的需求分析文档和模型。
• 如果网络工程面向的是特定行业或特定用户，可以 由特定用户提交业务需求书。
• 如果系统集成商与用户有长期合作关系，可以在合 作过程中培养用户提出需求和表达需求的能力。
• 如果网络工程项目是面向市场的，那么市场的声音 都是用户的需求。系统集成商应当主动选择用户、 细分市场、定位系统。
.
第18页 共60页
.
第14页 共60页
2.2 网络用户需求获取
• 对需求进行变更时，网络工程师应当对成本、影响、 得失有真实可信的评估。
• 获得满足用户功能和质量要求的系统，并且这些要 求是开发人员同意的。
.
第15页 共60页
2.2 网络用户需求获取
（3）用户的义务 • 给网络工程师讲解用户业务，并说明业务方面的术
需求获取 需求分析 需求文档 需求验证 • 需求分析的结果是技术文档及相关分析模型。 • 需求分析文档定义了网络工程项目的需求基线。
.
第4页 共60页
2.1 需求分析慨论
（2）需求管理 • 很难分辨出需求管理和需求分析的差别，大多数网
络工程师在进行需求分析工作时，已经不知不觉的 在开展需求管理和需求分析两种活动。 • 需求管理包括以下工作： 需求跟踪 需求变更 需求评估
（3）用户网络服务需求分析 • 数据库和应用软件的共享服务需求； • 文件传输和存取的服务需求； • 网站系统建设和应用的服务需求； • 电子邮件系统的建设和应用需求； • 网络远程访问服务的需求； • 网络视频服务需求； • 企业IP电话的需求等。
.
第9页 共60页
2.1 需求分析慨论
（4）用户通信类型比例分析 • 数据、语音、视频等业务在应用中所占的比例； • 是否有无线通信、无线漫游通信、卫星通信的需求
.
第16页 共60页
2.2 网络用户需求获取
• 用户一旦对需求进行变更时，要马上与网络工程师 联系。
• 在进行需求变更时，应对遵照网络工程师确定的工 作流程来处理。
• 尊重网络工程师对需求分析采用的工作流程。
.
Hale Waihona Puke Baidu
第17页 共60页
2.2 网络用户需求获取
2.2.2 需求获取的方法
• 网络工程由需求驱动，需求源于用户的需要。
.
第12页 共60页
2.2 网络用户需求获取
2.2.1 用户的权利与义务 （1）用户的特点 • 用户是经过筛选的 • 用户是沉默的 • 用户是难以满足的 • 用户是可引导的
.
第13页 共60页
2.2 网络用户需求获取
（2）用户的权利 • 使用符合用户语言习惯的表达方式。 • 了解用户网络系统的业务及目标。 • 获取用户需求信息，并编写需求分析说明书。 • 对需求工作结果进行解释说明。 • 在交流过程中保持合作的职业态度。 • 对网络系统的实现及需求提供建议。 • 描述网络系统的基本特性。 • 允许用户利用已有的网络系统。
.
第7页 共60页
2.1 需求分析慨论
（2）用户网络设备状态分析 • 用户现有的计算机数量及分布情况； • 今后几年中用户信息点的可能增长情况； • 现有网络设备型号、性能、数量及技术参数； • 模拟通信设备，如电话、传感器、视频设备； • 现有网络设备之间的物理连接等。
.
第8页 共60页
2.1 需求分析慨论