软件工程导论第三章需求分析.pptVIP

第3章 需求分析 3.1 需求分析的任务 需求分析的任务就是准确地回答“系统必须做什么?”这个问题，是通过系统分析员与用户一起商定，清晰、准确、具体地描述软件产品必须具有的功能、性能、运行规格等要求。软件需求分析阶段的目的是澄清用户的要求，并把双方共同的理解明确地表达成一份书面文档——软件需求规格说明书。 第3章 需求分析 需求分析的具体任务包括： 1. 功能需求 这方面的需求指定系统必须提供的服务。通过需求分析应该划分出系统必须完成的所有功能。 2. 性能需求 性能需求指定系统必须满足的定时约束或容量约束，通常包括速度(响应时间)、信息量速率、主存容量、磁盘容量、安全性等方面的需求。 第3章 需求分析 3.2 需求分析的过程 需求分析阶段可分为四个过程：调查研究、分析与综合、书写需求分析的文档和评审。 （1）调查研究 系统分析员协同程序员向用户做需求调查，阅软件计划中的可行性报告和项目开发计划报告，访问系统现场，并由此确定当前系统必须做什么，并获得当前系统的具体模型，用数据流图或IPO图表示出来。 第3章 需求分析 （2）分析与综合 分析员需从数据流和数据结构出发，逐步细化所有的软件功能，找出系统中各元素之间的联系、接口特征和设计上的限制，分析它们能否满足功能要求，是否合理。依据功能需求、性能需求、运行环境需求等，剔除其中不合理的部分，增加其需要的部分。最终综合成系统的解决方案后，给出目标系统的详细逻辑模型。 花括号内的信息条目构成顺序关系； 花括号从左至右排列表示树型层次结构； 符号“⊕”表示不可兼具的选择关系； 圆括号内的数字表示重复次数： （1,n）表示重复结构， （1）或不标次数表示顺序结构， （0,1）表示选择结构。 3.9 验证软件需求3.9.1 从哪些方面验证软件需求的正确性 需求分析阶段的工作结果是开发软件系统的重要基础，大量统计数字表明，软件系统中15%的错误起源于错误的需求。为了提高软件质量，确保软件开发成功，降低软件开发成本，一旦对目标系统提出一组要求之后，必须严格验证这些需求的正确性。一般说来，应该从下述4个方面进行验证： (1) 一致性所有需求必须是一致的，任何一条需求不能和其他需求互相矛盾。 (2) 完整性需求必须是完整的，规格说明书应该包括用户需要的每一个功能或性能。 (3) 现实性指定的需求应该是用现有的硬件技术和软件技术基本上可以实现的。对硬件技术的进步可以做些预测，对软件技术的进步则很难做出预测，只能从现有技术水平出发判断需求的现实性。 (4) 有效性必须证明需求是正确有效的，确实能解决用户面对的问题。 3.9.2 验证软件需求的方法 1. 验证需求的一致性 当需求分析的结果是用自然语言书写的时候，除了靠人工技术审查验证软件系统规格说明书的正确性之外，目前还没有其他更好的“测试”方法。但是，这种非形式化的规格说明书是难于验证的，特别在目标系统规模庞大、规格说明书篇幅很长的时候，人工审查的效果是没有保证的，冗余、遗漏和不一致等问题可能没被发现而继续保留下来，以致软件开发工作不能在正确的基础上顺利进行。 为了克服上述困难，人们提出了形式化的描述软件需求的方法。当软件需求规格说明书是用形式化的需求陈述语言书写的时候，可以用软件工具验证需求的一致性，从而能有效地保证软件需求的一致性。 2. 验证需求的现实性 为了验证需求的现实性，分析员应该参照以往开发类似系统的经验，分析用现有的软、硬件技术实现目标系统的可能性。必要的时候应该采用仿真或性能模拟技术，辅助分析软件需求规格说明书的现实性。 3. 验证需求的完整性和有效性 只有目标系统的用户才真正知道软件需求规格说明书是否完整、准确地描述了他们的需求。因此，检验需求的完整性，特别是证明系统确实满足用户的实际需要(即，需求的有效性)，只有在用户的密切合作下才能完成。然而许多用户并不能清楚地认识到他们的需要(特别在要开发的系统是全新的，以前没有使用类似系统的经验时，情况更是如此)，不能有效地比较陈述需求的语句和实际需要的功能。只有当他们有某种工作着的软件系统可以实际使用和评价时，才能完整确切地提出他们的需要。 弥补缺陷，重写需求的一种方法： 1、状态信息　　1.1 后台任务管理器因该以误差上下不超过10秒的 60秒间隔，在用户界面的指定位置显示状态信息　　1.2 如果后台进程处理正常，那么应该显示任务已完 成的百分数/比　　1.3 任务完成时，应显示相关的信息 　　1.4 后台任务出错应该显示错误信息 理想的做法是先根据需求分析的结果开发出一个软件系统，请用户试用一段