新·CH03-软件需求分析.pptVIP

图3-9　层次方框图实例 软件 硬件 服务 处理机 存储器 外部设备 培训 硬件维修 软件服务 产品 操作系统 编译程序 软件工具 系统软件 应用软件 * 3.4 软件需求说明 软件需求说明（SRS　Software Requirement Specification，又称软件规格说明书） 是系统分析人员在需求分析阶段需要完成的文档，是软件需求分析的最终结果。 它的作用主要是： 作为软件人员与用户之间事实上的技术合同说明； 作为软件人员下一步进行设计和编码的基础； 作为测试和验收的依据。 * 3.4软件需求说明 SRS必须用统一格式的文档进行描述，软件需求说明主要内容包括： 引言、 任务概述、 需求规定、 运行环境规定、 附录 等几部分。 * 引言 编写目的：阐明编写需求说明书的目的，指出预期的读者范围。 项目范围：待开发的项目名称及项目的开发目的；与项目的应用相关的利益目的及最终目标；项目的委托、开发单位和主管部门；该软件系统与其他系统的关系。 定义：列出文档中所用到的专门术语的定义和缩写词的原义。 参考资料：包括项目经核准的计划任务书、合同或上级机关的批文；项目开发计划；文档所引用 的资料、标准和规范。开出这些资料的作者、编号、发表日期、出自单位或资料来源。 * 任务概述 产品概述：描述开发意图、应用目标、作用范围、应向读者说明的有关该项目的开发背景。 用户特点：列出本软件最终用户的特点，说明操作人员、维护人员的教育水平和技术水平。 条件与限制：对设计系统时对开发者的条件与限制。 * 需求规定 对功能的规定：包括内部及外部功能的规定。 对性能的规定：包括对精度、时间要求、灵活性、适应性等的规定。 对输入输出的规定：包括所有输入输出数据、引用接口及接口控制文件、操作员控制的详细描述。 数据管理的规定：包括静态数据、动态数据、数据库、数据字典、数据采集的详细描述。 其他专门要求：如安全保密性、可使用性、可维护性、可移植性等。 * 运行环境规定 用户界面：如屏幕格式、报表格式、菜单格式、输入输出时间等。 设备 ：对系统硬件的要求描述。 软件接口：支持软件描述。 故障处理 * 附录 　实际的需求说明最好有附录，主要可以描述如格式样本、成本分析、用户调查结果、项目解决的问题描述、特殊的要求等相关信息。如果包含附录，必须指明是不是需求要考虑的部分。 * 3.5 需求验证 　　软件需要分析阶段的结果是软件开发项目的重要根据，大量统计数字表明，软件系统中约15%的错误起源于错误的需求。为了提高软件质量，确保软件开发成功，降低软件开发成本，对目标系统提出一组要求后，必须严格验证这需求的正确性。这个环节的参与者有用户、管理部门、软件设计、编码和测试人员。一般说来，应该从下述几个方面进行验证：一致性、现实性、完整性与有效性 。 * 一致性 所有的软件需求都必须是统一的，任何一条需求不能和其他需求矛盾。用自然语言书写的规格说明书是难于验证的，特别是目标规模大、需求说明书较长的时候，人工复审没有更好的方法进行测试。没有保证的、冗余的、遗漏和不一致的问题可能不容易被发现而被保留下来，为以后的软件设计留下后患。为了克服这困难，人们使用形式化的语言书写软件需求说明书，可以用软件工具验证需求的一致性。 * 现实性 　指定的需求应该是用现有的硬件技术和软件技术的能够基本实现的。如果超出了现有的技术基础，增加了软件实现的难度，提高软件开发成本，甚至导致软件开发的失败。由此，验证时，应该参照以往开发系统的经验，分析现有的软、硬件实现目标系统的可行性。必要的时候应该采用仿真或性能模拟技术，辅助分析软件需求书的现实性。 * 完整性与有效性 　需求必须是完整的，需求说明书中必须包括用户需要的每个功能或性能。需求必须是正确有效的，确实能解决用户的实际问题。只有用户才真正知道软件需求说明书是否完整、准确地描述他们的需求。检验需求的完整性与有效性必须在用户的合作下才能完成。而大多用户并不能清楚地说明自己的需求，也不能根据需求说明书确认是否满足自己的实际需求。使用快速原型方法是比较现实的解决方案。让用户试用一段时间原型系统，让他们能够认识到他们的真正需要什么。对比现有的需求分析，可以提出更符合实际的要求。同时，软件设计、编码及测试人员的参与，更进一步加深与用户的沟通，理解用户的真实需求，有益于软件开发的各个环节的关系，保证目标系统的完整性与有效性。 * * 需求分析的任务：就是借助于当前系统的逻辑模型导出目标系统的逻辑模型，解决目标系统的 “做什么” 的问题。 最终结果：获得需求规格说明书 3.1.2 需求分析的任务 认清问题、分析资料、建立分析模型 编写软件需求说明书 * 需求分析阶段的具体任务如下： 1．确定目标系统的具体要求 3.1.2 需求分析的任务