高质量的软件需求规格说明规范(SRS)符合哪些要求？

需求如雾中建筑

一、需求总是飘忽不定，明确系统边界是成功的第一步

软件工程中有一门重要学科《需求工程》，强调不充分的需求经常导致不一致、不完整以及不正确的需求规格说明，并且开发项目中所遇到的大量问题也是由此产生。据统计显示，软件项目失败的原因40%以上归结于需求不明确。

一年之计在于春，好的开始等于成功一半。软件需求规格说明书的重要性无须赘述，相信大家深有体会。

软件需求规格说明书(Software Requirement Specification，简称SRS)。

国家推荐标准规范GB/T 9385-2008定义：SRS是在具体环境中执行确定功能的特定软件产品、程序或一组程序的规格说明。

具体环境就是需求定义的系统边界，它是后续所有工作的基础、卡尺。具体环境无法充分理解和定义，对后续研发将是灾难性的。

很多SRS定义失败：源于想让软件毕其功于一役，一次性适应所有环境。经常被领导怼的一句话：这个动态、那个动态、所有都动态。软件的可扩展性确实非常重要，但它是建立在需求正确性及可完成的基础上的。

软件的价值在于准确实现业务流程，并高效辅助或改进业务流程，而不在于动态、动态、动态，它们只是成功上的锦上添花。

二、需求总是摸不不清，理解8项特性是好的SRS的关键一步

准确、客观的需求是好的SRS的基本要求：正确、无歧义、完备及一致性。

无歧义、完备及一致都是正确性的特征。正确性的可靠标准是参与需求分析的人员达成一致，包括客户、设计、研发、测试等角色。混合式工作模式是达成需求正确性的快捷路径。

我们总是无法避免地带有主观臆断，是影响需求客观性的重要因素。“五问法”不停地问为什么设计这样功能？为什么会有这样的痛点？为什么… 寻求需求最开始的地方，是对客观性对好的保障。

混合式工作模式中不同参与人员因为不具备相同的背景，会对不同的术语有不同的理解方式，明确特定背景是确保无歧义的前提。文档中内容要保持各个参与者达成一致，理解一致、内容一致，内部保持一致性。

最容易忽视两个特征，决定软件质量的生死线：重要性或稳定性分级、可验证性

重要性或稳定性分级是帮我们在项目遇阻时，做出取舍的重要依据。因为它是测试人员编写测试用例等级的依据；同时，也是研发人员优先开发功能的依据。

可验证性是最容易忽视的、且无法引起重视的关键特性，如需求中包含“具有良好性能”、“最合适的人机界面”等，“良好”、“最合适”是无法验证的，因为每一个人都有不同的理解。

若是测试人员无法验证的功能，必然是无法满足客户需求的。

需求变更无法避免，降低变更影响也是重要准则：可修改性与可追踪性

可修改性要求对文档任何需求都可以进行全面、容易和一致性的修改，并保持原有文档的形式和结构。具体要求：

1. 具有连贯、方便使用的结构，包括目次、索引及清晰的互相引用；
2. 没有冗余(相同需求不应当出现在多处)
3. 分别表述每个需求，而不与其他需求相混淆。

可追踪性唯一目标就是当需求变更时，能保证找到与之相关联的需求集合，将受影响的功能进行统一修改。推荐两种类型：

1. 正向可追踪性：SRS中每个需求具有唯一的名称或索引 。

三、总说“需求变动是必然的”，是极其不负责任的

未来的不确定是唯一可以确定的，这句话没错！如果以它为标准去开展工作，将会给项目组带来无法预料的后果，也是项目经理不负责任的表现。

需求变动更多源于对需求分析的不重视。虽然大家都一致认为需求分析的重要性，但从实际投入的人力、时间，都远远不够。因为大家都认为需求变动是一定的，就不想再投入更多的资源，与客户进行深入沟通。

人类最大的教训就是从来不吸取教训。很贴切、很真实…