常用的图形工具有层次方框图和Warnier图为减少数据冗余.pptVIP

改进的IPO图：这种图中包含某些附加的信息，在软件设计过程中将比原始的IPO图更有用。 在需求分析阶段可以使用IPO图简略地描述系统的主要算法(即数据流图中各个处理的基本算法)。 IPO表 系统：定货系统 作者：祁燕 模块：处理事务 日期：2010.3 编号：1.0 被调用： 定货系统 调用： 接受事务 更新库存清单 处理定货 输入： 事务 输出：定货信息 库存清单 处理： （用过程描述工具描述本模块的算法，如PAD图、N-S图、伪代码等） 局部数据元素： 注释： 3.8 验证软件需求 需求分析阶段的工作结果是开发软件系统的重要基础，大量统计数字表明，软件系统中15%的错误起源于错误的需求。为了提高软件质量，确保软件开发成功，降低软件开发成本，一旦对目标系统提出一组要求之后，必须严格验证这些需求的正确性。一般说来，应该从下述4个方面进行验证： 3.8.1 从哪些方面验证软件需求的正确性 (1) 一致性：所有需求必须是一致的，任何一条需求不能和其他需求互相矛盾。 (2) 完整性：需求必须是完整的，规格说明书应该包括用户需要的每一个功能或性能。 (3) 现实性：指定的需求应该是用现有的硬件技术和软件技术基本上可以实现的。对硬件技术的进步可以做些预测，对软件技术的进步则很难做出预测，只能从现有技术水平出发判断需求的现实性。 (4) 有效性：必须证明需求是正确有效的，确实能解决用户面对的问题。 3.8.2 验证软件需求的方法 1. 验证需求的一致性 　　当需求分析的结果是用自然语言书写的时候，除了靠人工技术审查验证软件系统规格说明书的正确性之外，目前还没有其他更好的“测试”方法。但是，这种非形式化的规格说明书是难于验证的，特别在目标系统规模庞大、规格说明书篇幅很长的时候，人工审查的效果是没有保证的，冗余、遗漏和不一致等问题可能没被发现而继续保留下来，以致软件开发工作不能在正确的基础上顺利进行。 　 为了克服上述困难，人们提出了形式化的描述软件需求的方法。当软件需求规格说明书是用形式化的需求陈述语言书写的时候，可以用软件工具验证需求的一致性，从而能有效地保证软件需求的一致性。 　　为了验证需求的现实性，分析员应该参照以往开发类似系统的经验，分析用现有的软、硬件技术实现目标系统的可能性。必要的时候应该采用仿真或性能模拟技术，辅助分析软件需求规格说明书的现实性。 2. 验证需求的现实性——仿真或性能模拟技术 　　只有目标系统的用户才真正知道软件需求规格说明书是否完整、准确地描述了他们的需求。因此，检验需求的完整性，特别是证明系统确实满足用户的实际需要(即，需求的有效性)，只有在用户的密切合作下才能完成。然而许多用户并不能清楚地认识到他们的需要(特别在要开发的系统是全新的，以前没有使用类似系统的经验时，情况更是如此)，不能有效地比较陈述需求的语句和实际需要的功能。只有当他们有某种工作着的软件系统可以实际使用和评价时，才能完整确切地提出他们的需要。 3. 验证需求的完整性和有效性 ——开发原型系统 　　理想的做法是先根据需求分析的结果开发出一个软件系统，请用户试用一段时间以便能认识到他们的实际需要是什么，在此基础上再写出正式的“正确的”规格说明书。但是，这种做法将使软件成本增加一倍，因此实际上几乎不可能采用这种方法。使用原型系统是一个比较现实的替代方法，开发原型系统所需要的成本和时间可以大大少于开发实际系统所需要的。用户通过试用原型系统，也能获得许多宝贵的经验，从而可以提出更符合实际的要求。 　　使用原型系统的目的，通常是显示目标系统的主要功能而不是性能。为了达到这个目的可以使用本章3.2.4小节介绍的方法快速建立原型系统，并且可以适当降低对接口、可靠性和程序质量的要求，此外还可以省掉许多文档资料方面的工作，从而可以大大降低原型系统的开发成本。 3.8.3 用于需求分析的软件工具 为了更有效地保证软件需求的正确性，特别是为了保证需求的一致性，需要有适当的软件工具支持需求分析工作。这类软件工具应该满足下列要求： (1) 必须有形式化的语法(或表)，因此可以用计算机自动处理使用这种语法说明的内容； (2) 使用这个软件工具能够导出详细的文档； (3) 必须提供分析(测试)规格说明书的不一致性和冗余性的手段，并且应该能够产生一组报告指明对完整性分析的结果； (4) 使用这个软件工具之后，应该能够改进通信状况。 　　1977年美国密执安大学开发了PSL/PSA(问题陈述语言/问题陈述分析程序)系统。这个系统是CADSAT（计算机辅助设计和规格说明分析工具）的一部