ch3 需求分析 软件工程课件.pptVIP

第3章 需求分析 3.1 需求分析的任务 3.2 与用户沟通获取需求的方法 3.3 分析建模与规格说明 3.4 实体-联系图 3.5 数据规范化 3.6 状态转换图 3.7 其他图形工具 3.8 验证软件需求 3.9 小结 需求分析案例 需求分析案例 需求分析案例 需求分析案例 软件需求的定义 I E E E软件工程标准词汇表（ 1 9 9 7年）中定义需求为： （1）用户解决问题或达到目标所需的条件或权能（ C a p a b i l i t y）。 （2）系统或系统部件要满足合同、标准、规范或其它正式规定文档所需具有的条件或权能。 （3）一种反映上面（1）或（2）所描述的条件或权能的文档说明。 需求的层次 三个不同的层次：业务需求、用户需求和功能需求（也包括非功能的需求） 需求的层次 业务需求（ business requirement）反映了组织机构或客户对系统、产品高层次的目标要求，它们在项目视图与范围文档中予以说明。 用户需求(user requirement) 文档描述了用户使用产品必须要完成的任务，这在使用实例（ use case）文档或方案脚本（ s c e n a r i o）说明中予以说明。 功能需求(functional requirement)定义了开发人员必须实现的软件功能，使得用户能完成他们的任务，从而满足了业务需求。 需求分析是软件定义时期的最后一个阶段，其任务是准确地回答“系统必修做什么”，对目标系统提出完整、准确、清晰、具体的要求。 由系统分析员和用户合作，得到软件需求规格说明书——以书面形式描述软件需求。 需求分析方法应遵守的准则： 必须理解并描述问题的信息域，建立数据模型 必须定义软件应完成的功能，建立功能模型 必须描述作为外部事件结果的软件行为，建立行为模型 必须对描述信息、功能、和行为的模型进行分解，用层次的方式展示细节 3.1 需求分析的任务 确定对系统的综合要求 功能需求 指定系统必须提供的服务。通过需求分析应该划分出系统必须完成的所有功能。 性能需求 指定系统必须满足的定时约束或容量约束，通常包括速度(响应时间)、信息量速率、主存容量、磁盘容量、安全性等方面的需求。 可靠性和可用性需求 可靠性需求定量地指定系统的可靠性。可用性与可靠性密切相关，它量化了用户可以使用系统的程度。 3.1 需求分析的任务 确定对系统的综合要求 出错处理需求 系统如何响应环境错误 接口需求 描述应用系统与它的环境通信的格式。常见的接口需求有：用户接口需求；硬件接口需求；软件接口需求；通信接口需求。 约束 设计约束或实现约束描述在设计或实现应用系统时应遵守的限制条件。常见的约束有：精度；工具和语言约束；设计约束；应该使用的标准；应该使用的硬件平台。 确定对系统的综合要求 逆向需求 逆向需求说明软件系统不应该做什么。理论上有无限多个逆向需求，我们应该仅选取能澄清真实需求且可消除可能发生的误解的那些逆向需求。 将来可能提出的要求 列出那些虽然不属于当前系统开发范畴，但是据分析将来很可能会提出来的要求。这样做的目的是，在设计过程中对系统将来可能的扩充和修改预做准备 分析系统的数据要求 导出系统的逻辑模型 由系统的综合要求和数据要求，我们可导出系统的逻辑模型 ，通常用数据流图、实体联系图、状态转换图、数据字典和处理算法来描述。 修正系统开发计划 根据在分析过程中获得的对系统的更深入更具体的了解，可以比较准确地估计系统的成本和进度，修正以前制定的开发计划。 3.2 与用户沟通获取需求的方法 访谈 访谈是最早开始使用的获取用户需求的技术，也是迄今为止仍然广泛使用的需求分析技术。 正式访谈：系统分析员将提出一些事先准备好的具体问题。 非正式访谈：分析员将提出一些用户可以自由回答的开放性问题，以鼓励被访问人员说出自己的想法。 3.2 与用户沟通获取需求的方法 访谈 情景分析 所谓情景分析就是对用户将来使用目标系统解决某个具体问题的方法和结果进行分析。 作用 它能在某种程度上演示目标系统的行为，从而便于用户理解，而且还可能进一步揭示出一些分析员目前还不知道的需求。 保证用户在需求分析过程中始终扮演一个积极主动的角色。需求分析的目标是获知用户的真实需求，而这一信息的惟一来源是用户 3.2.2面向数据流自顶向下求精过程 结构化分析方法就是面向数据流自顶向下逐步求精进行需求分析的方法。 分析数据流图 沿数据流图从输出端往输入端回溯，确定每个数据元素的来源 初步定义有关算法 用户审查 必须请用户对上述分析过程中得出的结果仔细地复查，从输入端开始，分析员借助数据流图、数据字典和IPO图向用户解释输入数据是怎样一步一步地转变成输出数据的。复查过程验证了已知的元素，补充了未知的元素，填补了文档中的空白。 3.2