{新}第3章 需求分析.pptVIP

软 件 工 程 第3章 需求分析 3.1 需求分析的任务 3.2 与用户沟通获取需求的方法 3.3 分析建模与规格说明 3.4 实体-联系图 3.5 数据规范化 3.6 状态转换图 3.7 其他图形工具 3.8 验证软件需求 3.9 小结 需求分析是软件定义时期的最后一个阶段，它的基本任务是准确地回答“系统必须做什么?”这个问题，而不是“怎样实现”。 【分析结果】：系统分析员应该写出软件需求规格说明书，以书面形式准确地描述软件需求。 【掌握内容】：对一个软件系统来说，数据是稳定的，事务处理可能是变化的。 需求分析的原则： (1) 必须理解并描述问题的信息域，根据这条准则应该建立数据模型。 (2) 必须定义软件应完成的功能域，这条准则要求建立功能模型。 (3) 必须描述作为外部事件结果的软件行为，这条准则要求建立行为模型。 (4) 必须对描述信息、功能和行为的模型进行分解，用层次的方式展示细节。 系统分析员在软件开发中的作用 在系统分析过程中，系统分析员除了起用户和设计人员的接口作用以外，还应充分代表用户的利益，在整个开发过程中起着关键作用。 §3.1 需求分析的任务 §3.1.1 确定对系统的综合要求 功能需求 性能需求 可靠性和可用性需求 出错处理 接口需求 约束与环境需求 逆向需求 将来可能提出的要求 1、功能需求 系统做什么？ 系统何时做什么？ 系统何时及如何修改或升级？ 3、可靠性和可用性需求 可靠性需求定量地指定系统的可靠性。 可用性与可靠性密切相关，它量化了用户可以使用系统的程度。 4、出错处理需求 有选择地提出这类出错处理需求。我们的目的是开发出正确的系统，而不是用无休止的出错处理代码掩盖自己的错误。 5、接口需求 接口需求描述应用系统与它的环境通信的格式。常见的接口需求有：用户接口需求；硬件接口需求；软件接口需求；通信接口需求。例如： 6、约束与环境需求 描述在设计或实现应用系统时应遵守的限制条件，是用户或环境强加给项目的限制条件。常见的约束有：精度；开发工具和语言约束；设计约束；数据库约束；应该使用的标准；应该使用的硬件平台及现场环境等。 7、逆向需求 逆向需求说明软件系统不应该做什么。理论上有无限多个逆向需求，我们应该仅选取能澄清真实需求，且可消除可能发生的误解的那些逆向需求。 8、将来可能提出的要求 应该明确地列出那些虽然不属于当前系统开发范畴，但是分析将来很可能会提出来的要求。 目的：在设计过程中对系统将来可能的扩充和修改预做准备，以便一旦确实需要时能比较容易地进行这种扩充和修改。 9、用户或人的因素 10、文档需求 12、资源需求 14、安全保密要求 15、质量保证 §3.1.2 分析系统的数据要求 是需求分析的一个重要任务。主要体现在： 如何定义数据？数据的作用？如何用？如何表达数据间的关系？ 如何存储？为减少数据冗余，如何简化数据，并进行规范化？ 分析系统的数据要求通常采用建立数据模型的方法(见3.4节E-R关系图)。 §3.1.3 导出系统的逻辑模型 通过对系统的综合要求和数据要求分析的结果可以导出系统的详细的逻辑模型，通常用以下内容描述这个逻辑模型： 数据流图 实体-联系图 状态转换图 逻辑模型组成 数据字典 主要的处理算法 §3.1.4 修正系统开发计划 根据在分析过程中获得的对系统的更深入更具体的了解，可以比较准确地估计系统的成本和进度，修正以前制定的开发计划。 需求分析技巧： 需求的收集贯穿于整个项目过程中; 解释技术，使甲方积极参与； 使用用户的术语，用共同的语言进行交流； 取得管理层的支持—— “一把手工程”； 已有的文档是需求的很好来源——复用已有的资源； 记住今天的用户就是明天的分析者和以后的开发者。 §3.2 与用户沟通获取需求的方法 §3.2.1 访谈 访谈是最早开始使用的获取用户需求的技术，也是迄今为止仍然广泛使用的需求分析技术。 访谈有两种基本形式： 正式访谈时：系统分析员将提出一些事先准备好的具体问题。 非正式访谈：分析员将提出一些用户可以自由回答的开放性问题，以鼓励被访问人员说出自己的想法。 §3.2.2 面向数据流自顶向下求精 【目的】：通过可行性研究中目标系统的高层数据流图，需求分析的目标之一就是把数据流和数据存储定义到元素级。 【实施方法】：在实际业务中，数据决定了需要的处理和算法，是需求分析的出发点，所以重点围绕数据流中数据元素的来源、用途、去向获取需求，并进行详细细化分解。 图3.1 面向数据流自顶向下求精过程 §3.2.3 简易的应用规格说明技术 使用传统的访谈或面向数据流自顶向下求精方法定义需求时，用户处于被动地位而且往