|
对于实施GJB5000的组织来说，组织都会制定一个符合标准的需求规格说明文档模板，但是，并不是说有了文档模板，写出来的需求规格说明就符合要求，需求规格说明的评审就能不用心，走过场。 很多看似符合要求的需求规格说明，实际上可能存在很多问题。比如：
需求规格说明是站在开发的角度来描述软件需求，它的依据是用户需求。而一个软件的用户需求可能是软件研制任务书，也可能是其他形式的需求文档；还可能包括系统需求规格说明、接口规格说明、技术协议等其他包含用户需求的文档。 需求规格说明必须覆盖所有的、任何形式的用户需求。这不仅要求在引用文档中要包含这些用户需求文档，更重要的是功能、性能、接口以及其他非功能性需求要覆盖所有的用户需求，需求规格说明是在对所有用户需求合理的分析之后对需求的描述，并且与用户需求是一致的；需求规格说明中的需求双向追溯也应当体现对用户需求的完整覆盖。 脱离了用户需求的需求规格说明，只是纯粹的闭门造车，凭借想象编写，空话连篇，没有实际意义。
需求规格说明是开发人员对需求分析的结果的呈现，如果需求规格说明全部是照搬用户需求的描述，那么需求分析过程在哪里？ 用户需求是用户站在业务的角度对需求的描述，需求规格说明是开发人员站在技术的角度对需求的描述，二者本来在表述上就存在差异，而且需求规格说明是需求分析的结果的呈现，这里要根据技术要求定义软件功能需求，把性能、可靠性、安全性等非功能需求分配到功能需求，需要平衡各利益相关方的期望，需要考虑需求的充分性和必要性，需要标识关键需求…… 没有任何分析，照搬用户需求描述形成的需求规格说明等同于一堆废纸。
对于非嵌入式软件，我们通常会使用面向对象的分析方法，比如使用用例来描述功能需求，使用UML等工具绘制流程图、数据流图、状态图、时序图等。但是，如果对面向对象分析方法一知半解，不知道如何从业务需求中抽取用例并确定用例间的关系，绘制的UML图不完整，似是而非，这样需求规格说明无法为后续的开发提供帮助。
需求规格说明描述的需求应当满足“可测试”的需求验收标准，它不应该出现模糊而无用的用词，需求的描述应当定量而不是定性的。诸如“数据处理要快速完成”这样的性能需求，“保证软件安全可靠地运行”这样的可靠性需求，都不满足“可测试”的需求验收标准，这样的需求是无法开发，无法验证，无法确认的。 所以，组织不能因为有了需求规格说明文档模板就放松了对需求规格说明质量的检查，而是要加强质量保证人员对需求规格说明的审核，加强对需求规格说明的同行评审，杜绝似是而非、错漏百出的需求规格说明文档的产生。 这正是： 模板虽有非万能，严抓质量不放松 有些问题需深挖，似是而非可不行 参考书目：软件是这样炼成的——从软件需求分析到软件架构设计，作者：王朔韬，出版社：清华大学出版社 |
|
|
