软件需求说明书是软件开发项目管理中最重要的文档，没有之一。
它准确地描述了软件开发项目的范围，是用户和软件开发人员之间达成的技术协议，用户通过它在分析阶段即可初步判定目标软件能否满足其原来的期望，开发人员则将它作为开发设计的基础，是软件测试和验收的依据。在软件产品研发中，也称之为产品需求文档，简称PRD。
软件需求说明书是用户需求分析和软件设计的产物，其编制过程也是需求分析和软件设计的过程，它包含了需求背景和目标、用户及特点、业务流程、业务架构、功能结构、功能需求说明、非功能需求说明等内容。
因此，在项目售前或合同签订阶段往往难以明确定义这些内容，所以软件需求说明书的编写和确认也是重定义项目范围的过程，在这个阶段需要项目经理和用户进一步明确项目实现的细节，以免在项目交付和验收时出现反复。
软件开发项目中80%的问题都来自于需求的问题，可见一份完整、准确，同时又简明易懂的软件需求说明书是何等的重要。
各位小伙伴在需求沟通的过程中有没有经常碰到这样一种情况?
产品或项目经理把从用户那里收集过来的需求转述给开发时，开发会说“你这个需求不清楚，没法做!”，或者开发做着做着问题百出，不断和产品确认细节，而产品会觉得“我已经描述清楚我的需求了啊，哪里还不清楚?”。这种时候往往是因为产品只是描述了用户需求，而不是软件需求。用户需求是问题，而软件需求是解决方案，软件需求说明书要准确描述软件设计的细节。
在需求分析时要特别注意搞清楚用户的问题是什么，才能给出合适的解决方案，因为用户在描述问题时经常性是描述他所期望的解决方案，而用户提出的解决方案很可能不合适。
还是举个之前的例子：
我需要一个苹果。客户经常这样提出需求。
你需要判断这是一个问题还是解决方案。
问题是“饿了”?还是“想吃苹果”?
如果是“饿了”，则“需要一个苹果”是客户针对问题提出的解决方案。那我给你一个面包是不是更好?况且我手里正好有个面包。
如果是“想吃苹果”，则是问题，那就给个苹果好了…
所以搞清楚“问题”什么至关重要。
那么回到本文的主题，如何写好一份软件需求说明书?我们从文档结构和内容着手，一一讲解。上面讲到，软件需求说明书包含背景和目标、用户及特点、业务流程、业务架构、功能结构、功能需求说明、非功能需求说明等。它们具体都有哪些内容，如何体现，又有何作用和注意事项?
○ 背景和目标：说明软件系统开发的背景，总结现状、存在的问题和挑战，描述高层级战略需求和目标，体现系统的核心价值。PRD则主要描述产品定位、目标市场等内容。
○ 用户及特点：说明系统的最终用户，说明角色和使用场景，以及其岗位职责和所在组织的结构。不同角色的使用场景和核心需求会有区别，后续需求分析过程中才能全面且有针对性的考虑用户需求。toC领域中也称之为用户画像。
○ 业务流程：流程图，重点描述核心业务流程，其他细化流程可以在对应的功能模块中再具体体现。梳理业务流程能全面了解业务处理的过程，分析业务流程的合理性，并通过业务流程图分析哪些部分可以利用软件来实现，确定系统的主功能模块。toB软件系统在流程抽象、复用上有天然的基因，普遍按照企业已有的标准流程或基于业界通用流程改造。在产品敏捷开发中则习惯采用用户故事地图体现业务核心流程，并作为Roadmap规划版本迭代。
○ 业务架构：是业务和技术的融合。针对复杂的业务流程，通过设计业务架构，分解业务流程，切分软件系统功能模块，设定工作边界。并从用户需求视角展示功能模块，表现功能和功能之间的关联关系，使用户和设计者能清晰地看到业务和系统的全貌。
○ 功能架构：是功能模块的细化拆分，根据用户场景合理、完整的划分功能点，以鸟瞰的方式对整个系统的功能结构形成一个直观的认识，避免功能模块和功能点缺失。
○ 功能需求：系统的硬实力，包含所有功能点的说明、用户场景、流程图、界面原型、业务规则等，准确的描述软件需求的具体细节。
a.功能说明：概述该功能点的能力、作用及其价值。
b.用户场景：使用场景描述，阐述需求和设计的背景，帮助用户和设计者回顾需求的合理性和有效性，以免出现“自以为是”的需求和设计。
c.界面原型：以低廉的成本快速让用户生动、具体的感受系统的效果，使各相关方更准确的评估需求，且更好的达成一致的理解。通常只需要设计低保真原型，其他内容备注说明即可，搭配原型设计原稿，具体细节可由UX和UI设计师完成。
d.流程图：可能包含业务流程图、系统处理逻辑图、数据流图、状态转换图等，根据不同功能点的复杂度而定。软件的本质就是数据输入、处理和输出的过程，通过流程图可以更清晰的阐述该过程。
e.业务规则：针对界面原型和流程图的补充说明，详细说明界面上每一个元素的类型、数据范围、是否必填、默认值、处理规则等，以及每个按钮数据处理逻辑。这也是软件需求说明中最容易考虑不充分的部分，需要开发人员在实现过程中及时提出和确认。
业务流程图/系统处理逻辑图/数据流图
○ 非功能需求：是系统的软实力，体现其综合素质。包含系统性能、稳定性、安全性、兼容性、运行环境等内容。这些都是需求分析过程中容易忽视却又必不可少的内容，对软件开发设计有很大的影响，如果不能提前确认清楚，在软件交付使用时则会出现诸多问题。
以上内容，则尽可能完整、准确，同时又简明易懂的描述了软件需求，使得用户和软件开发人员之间对系统是否满足需求和设计实现有了共同的依据。
最后，我想稍微提一下软件的开发设计。其主要输出物是概要设计说明书，在编码之前必须要求开发人员输出概要设计并通过评审。它是软件需求转化为开发设计的结果，是软件设计者初步判断目标软件能否在功能和非功能上满足需求的依据。
除了软件需求本身的内容外，主要包含数据结构设计、接口设计(初期可以不要求接口细节，只定义接口清单)、程序处理流程等，我一般主抓这三部分，基本上编码实现上就不会有太大偏差。如果是完整的产品开发设计，还需要充分考虑应用架构、数据架构、技术架构及组件选型等等。
