5.2.5 需求规格说明书

软件需求规格说明书（Software Requirement Specification，SRS）是在需求分析阶段需要完成的文档，是软件需求分析的最终结果，是确保每个要求得以满足所使用的方法。编制该文档的目的是使项目干系人与开发团队对系统的初始规定有一个共同的理解，使之成为整个开发工作的基础。SRS是软件开发过程中最重要的文档之一，任何规模和性质的软件项目都不应该缺少。 在国家标准《计算机软件文档编制规范》（GB／T 8567）中，提供了一个SRS的文档模板和编写指南，其中规定SRS应该包括范围、引用文件、需求、合格性规定、需求可追踪性、尚未解决的问题、注解和附录。

• （1）范围：包括SRS适用的系统和软件的完整标识，（若适用）包括标识号、标题、缩略词语、版本号和发行号；简述SRS适用的系统和软件的用途，描述系统和软件的一般特性；概述系统开发、运行和维护的历史；标识项目的投资方、需方、用户、承建方和支持机构；标识当前和计划的运行现场；列出其他有关的文档；概述SRS的用途和内容，并描述与其使用有关的保密性和私密性的要求；说明编写SRS所依据的基础。
• （2）引用文件：列出SRS中引用的所有文档的编号、标题、修订版本和日期，还应标识不能通过正常的供货渠道获得的所有文档的来源。
• （3）需求：这一部分是SRS的主体部分，详细描述软件需求。具体可以分为以下项目：所需的状态和方式、需求概述、需求规格、软件配置项能力需求、软件配置项外部接口需求、软件配置项内部接口需求、适应性需求、保密性和私密性需求、软件配置项环境需求、计算机资源需求（包括硬件需求、硬件资源利用需求、软件需求和通信需求）、软件质量因素、设计和实现约束、数据、操作、故障处理、算法说明、有关人员需求、有关培训需求、有关后勤需求、包装需求和其他需求，以及需求的优先次序和关键程度。
• （4）合格性规定：这一部分定义一组合格性的方法，对于第（3）部分中的每个需求指定所使用的方法，以确保需求得到满足。合格性方法包括演示、测试、分析、审查和特殊的合格性方法（例如，专用工具、技术、过程、设施和验收限制等）。
• （5）需求可追踪性：这一部分包括从SRS中每个软件配置项的需求到其涉及的系统（或子系统）需求的双向可追踪性。
• （6）尚未解决的问题：如果有必要，可以在这一部分说明软件需求中尚未解决的遗留问题。
• （7）注解：包含有助于理解SRS的一般信息（例如，背景信息、词汇表、原理等）。这一部分应包含理解SRS所需要的术语和定义，所有缩略语和它们在SRS中的含义的字母序列表。
• （8）附录：提供那些为便于维护SRS而单独编排的信息（例如，图表、分类数据等）。为便于处理，附录可以单独装订成册，按字母顺序编排。 另外，国家标准《计算机软件需求规格说明规范》（GB／T 9385）中也给出了一个详细的SRS写作大纲，可以作为SRS写作的参考之用。 资深软件工程师都知道，当以SRS为基础进行后续开发工作时，如果在开发后期或在交付系统之后才发现需求存在问题，这时修补需求错误就需要做大量的工作。相对而言，在系统分析阶段，检测SRS中的错误所采取的任何措施都将节省相当多的时间和资金。因此，有必要对于SRS的正确性进行验证，以确保需求符合良好特征。需求验证也称为需求确认，其活动需要确定的内容包括：
• · SRS正确地描述了预期的、满足项目干系人需求的系统行为和特征；
• · SRS中的软件需求是从系统需求、业务规格和其他来源中正确推导而来的；
• · 需求是完整的和高质量的；·需求的表示在所有地方都是一致的；
• · 需求为继续进行系统设计、实现和测试提供了足够的基础。 在实际工作中，一般通过需求评审和需求测试工作来对需求进行验证。需求评审就是对SRS进行技术评审，SR[S]{.underline}的评审是一项精益求精的技术，它可以发现那些二义性的或不确定性的需求，为项目干系人提供在需求问题上达成共识的方法。需求的遗漏和错误具有很强的隐蔽性，仅仅通过阅读SRS，通常很难想象在特定环境下系统的行为。只有在业务需求基本明确、用户需求部分确定时，同步进行需求测试的情况下，才可能及早发现问题，从而在需求开发阶段以较低的代价解决这些问题。