2.1.6 需求规格说明书
有的项目组拿着用户编写的原始需求就直接开始开发，随后状况不断，整个研发过程令人崩溃。在用户编写的原始需求的基础上，编写自己的需求规格说明书之所以重要，就在于用户编写的原始需求是脱离了技术实现的一份十分理想的业务需求，而理想与现实总是有差距。所以我们要编写自己的需求规格说明书，要本着实事求是、切实可行的态度，编写经过业务与技术两方面确认以后的业务需求，摒弃那些不可行的需求，或者换成更加可行的解决方案。这就是需求规格说明书的重要作用。
需求规格说明书分为用户需求规格说明书和产品需求规格说明书。用户需求规格说明书是站在用户角度描述的系统业务需求，用于与用户签字确认业务需求；产品需求规格说明书是站在开发人员角度描述的系统业务需求，是指导开发人员完成设计与开发的技术性文档。但是，笔者认为，用户需求规格说明书与产品需求规格说明书的差别并不大。当今敏捷开发注重的是“轻文档”，即在项目进程中只编写那些最有必要的文档。而本书后面要提到的领域驱动设计所提倡的，更是要让用户、需求分析员、开发人员站在一个平台，使用统一的语言（统一语言建模）来表达概念。从这个角度讲，需求规格说明书就应当只有一个，不需要区分用户需求规格说明书和产品需求规格说明书。
现在越来越多的团队开始敏捷转型，然而一些团队错误地将“轻文档”理解为不要文档，这给软件研发与日后维护带来诸多问题。“轻文档”是要将项目人员从繁重的文档编写中解脱出来，只写最有必要的文档，但不等于不写文档。而在所有这些文档中，需求规格说明书就是那个最有必要编写的文档。它的重要作用在于，将大家通过探讨最终确认下来的需求，以文字的形式确定下来。如果没有这个确定的过程，开发如何准确理解需求？测试用什么标准测试？用户又如何对软件成果进行验收？当系统上线运行起来以后，后续的团队如何接手现有的项目？如何在现有的基础上修改变更？没有文档会带来诸多问题。因此，需求规格说明书是敏捷团队在“轻文档”研发过程中必须要编写的文档。
那么需求规格说明书怎么写呢？不同的公司、不同的人、不同的项目，特别是在需求分析中采用不同的方法，写出来的需求规格说明书格式都是不一样的。在这里，我给大家一个采用用例模型的方式编写的需求规格说明书的模板，供大家参考。
1.引言
1.1 编写目的
描述你编写这篇文档的目的和作用。但最关键的是，详细说明哪些人可以使用这篇文档，用它做什么。需求规格说明书是用来做什么的？毫无疑问，首先是供用户与开发公司确认软件开发的业务需求、功能范围。其次就是指导设计与开发人员设计开发系统。此外，还包括指导测试人员设计测试，指导技服人员编写用户手册，以及帮助其他相关人员熟悉系统。描述这些，可以帮助读者确定这篇文档是否可以提供帮助。
1.2 业务背景
描述业务背景是为了让读者了解与该文档相关的人与事。你可以罗列与文档相关的各种事件，也可以描写与项目相关的企业现状、问题分析与解决思路，以及触发开发该项目的大背景、政策法规等。
1.3 项目目标（或任务概述）
就是项目能为用户带来什么利益，解决用户什么问题，或者说怎样才算项目成功。前面提到过，这部分对项目成功作用巨大。
1.4 参考资料
参考资料的名称、作者、版本、编写日期。
1.5 名词定义
就是文档中可能使用的各种术语或名词的定义与约定，大家可以根据需要删减。
2.整体概述
这部分是对系统整体的描述。
2.1 整体系统概述
从宏观的角度去描述系统整体的业务规划与功能。
2.2 整体用例分析
绘制第0层的整体用例图，然后对用例图中的每个用例编写用例描述。如果系统比较大，每个用例就是一个子系统，后面的“功能需求”分多个文档分别进行描述；如果系统比较小，则不写该部分，而是在后面的“功能需求”部分画用例图，然后对用例图中的每个用例编写用例描述。
2.3 角色分析
一个用例图，描述系统中所有的角色及其相互关系。在随后的说明中，详细说明每个角色的定义及其作用。
2.4 其他
这部分还可以根据项目需要编写其他的内容，如部署方案、网络设备、功能结构、软件架构、关键点难点技术方案，等等。
3.功能需求
3.1 功能模块（子系统）
描述系统中的每个功能模块（或子系统），即整体用例分析中的每个用例。这部分是需求规格说明书最主要的部分。如果系统规模比较大，可以将子系统分为多个文档进行编写；如果规模不大，可以分章节进行描述，每个章节按模块名进行命名。
3.1.1 用例图
绘制该模块的用例图。
3.1.2 用例说明
对用例图中的每个用例编写用例描述。
4.非功能需求
这里描述的是软件对非功能需求的一般要求，即整体设计原则。
5.接口需求
如果项目涉及与外部系统的接口，则编写这部分需求。
5.1 接口方案
详细描述采用什么体系结构与外部系统相连接。
5.2 接口定义
接口的中文名、英文名、功能描述、参数、返回值、使用者等内容。