需求规格说明书与评审：体育管理信息系统的原理与应用

1.需求规格说明书

在需求分析阶段结束之前必须形成需求规格说明书SRS。在软件开发的问题定义阶段，开发方就与用户共同确定目标软件的范围和目标。在分析阶段，这些目标将要被进一步细化，最后形成文档，即SRS。

SRS主要包括功能与行为需求描述和非行为需求描述两大部分。功能与行为需求描述说明系统的输入、输出以及相互关系。非行为需求是指软件系统在工作时候应该具备的各种特征，例如可靠性、安全性、可维护性、可移植性以及效率等。在美国IEEE830-1998号标准和我国国家标准GB856D-88中，都对SRS的内容做了一些规定，主要包括引言、信息表述、功能描述、行为描述、质量保证、接口描述以及其他描述等几个部分，如表5-2所示。

表5-2　SRS内容

(https://www.xing528.com)

SRS的主要目标是要便于用户、分析人员和软件设计人员进行交流和理解。一方面用户通过SRS在分析阶段就可以初步判定目标软件是否能满足预期，另一方面设计人员会把SRS作为软件设计的出发点。SRS还起到控制系统进化的作用。在需求分析结束后，如果用户追加需求，那么需求规格说明将用于确定追加的需求是否是新需求，如果是，开发人员将重新针对新需求进行分析、扩充SRS或者等待下一期的开发等。最后，在软件开发结束时验收的依据是SRS，因此SRS的各项需求应该是可以进行测试的。

2.需求评审

SRS并不是直接提交给设计人员的，而是要进行评审。评审的主要标准按重要次序排列依次为：正确性、无歧义性、完全性、可验证性、一致性、可理解性、可修改性和可追踪性。要求SRS中的功能、行为、性能等描述必须达到用户对目标软件的期望，描述的内容要没有歧义，不能遗漏用户的任何需求，需求的各个部分之间不能有冲突。

评审的形式通常是会议，由用户、分析人员和系统设计人员共同参与。一般流程是分析人员首先说明目标软件要实现的总体目标，例如产品的主要功能、交互以及相关的性能指标等。然后参会人员还要对SRS的核心部分需求模型进行评估，讨论该模型的合理性，接着会议还要针对原始软件问题讨论除了当前模型以外的其他的解决方法，并对可能会影响到软件设计和质量的因素进行综合考虑，决定说明书中采用的方法是否合理。最后，需求评审会议应该对软件质量确认的方法进行讨论，最终形成用户和开发人员都能接受的各项测试指标。

如果在评审的过程中发现任何错误、遗漏，都应该及时进行增补，重新进行相应部分以及相关部分的初步需求分析、建模、修改SRS，并再次进行评审。只有评审通过的SRS才能被交付到下一阶段。