什么样的软件需求文档才算是合格的软件需求文档？文档作为沟通方式之一，目的是让阅读者理解想要表达的含义。软件需求文档同时是为了让其阅读者准确理解软件项目的需求，明白想要做一个什么样的系统。所以，能准确的让需求文档读者（个人以为重点是项目组开发、测试）理解项目需求就是合格的软件需求文档。

软件需求文档就其涵盖的内容而言，应包括功能需求、接口需求、质量需求三个方面。功能需求描述部份应涵盖了系统的所有功能，关键性功能及细节应描述清晰，涉及到流程的部分，应形成闭环、状态的转换及条件应该有一个清晰的描述。接口需求（这里主要是指和其他系统的接口）应清晰的描述消息的物理信道、通信协议、错误校验机制、消息体的数据格式等要求。质量需求主要包括性能需求，如响应速度、单机并发数；安全性要求以及甲方未来可能面临的安全性风险；可用性、可维护性等方面。

适当的编写、排版形式有助于理解需求文档。如场景描述、系统原型等形式展现用户的需求。针对整体全局性的要求没必要每个功能点都进行说明，可以在文档中设置一个全局业务规则的页面，减少重新性的描述，同时能将精力花在其他部分。如下图所示：

隐形需求度的把握。在项目中处理基本的常识和经过磨合的团队达成共识的部份才能作为隐形需求，否则需求都应该显性化，如果不显性化，则这个地方就可能造成风险。隐性需求度的把握很大程度上影响文档的质量。

如果是集中办公的项目团队，可以考虑将需求讲解/评审会议的部分当做需求文档的补充，需要把握的就是通过文档项目组成员能回忆起需求讲解/评审会议产品经理的口述部分，至少会留有一印象，在记忆不太清晰的情况下可以再咨询产品经理而到达开发工作不返工的目的即可。

        编写合格的软件需求文档当然不仅仅只是上面提到的部分，也许有更多优秀的方式、方法来编制需求文档，欢迎各位来一起探讨如何编写合格的软件需求文档这个话题。