在上一章节中，简要介绍了基于用例和对象的软件开发方法。接下来，需要了解《需求规格说明书》如何体现上述的过程。
3.1 《需求规格说明书》的组成
这里的《需求规格说明书》对应着系统需求，要求以业务需求（业务流程）为纲，组织和提炼系统需求，并使用用例规约详细定义和描述系统需求。
《需求规格说明书》主要包括：
- 引言：注明文档的目的、主要读者及文档中使用的术语；
- 任务概述：简要介绍系统的目标、系统（或用户）的特点、假定和约束；
- 功能需求：这部分是文档的重点，占了很大部分；
- 非功能性需求：如外观需求、易用性需求等；
- 接口：识别系统和外部其它业务系统直接的交互；
- 文档需求：对帮助文件、联机手册、开发手册等特殊的文档需求；
- 需求分级：对需求的优先级排序。
上面已经提到，对于《需求规格说明书》而言，最重要的一部分是功能需求的描述。因为《需求规格说明书》主要是给开发人员看的，需要让他们清楚的知道产品要“长成”什么样。写好这一部分的要点是“以系统为单位、采用业务导向的树型层次结构来组织”，这是《需求规格说明书》的灵魂，也是可阅读、可理解的基础。
所谓“以系统为单位、采用业务导向的树型层次结构来组织”，其实就是要求《需求规格说明》的目录逻辑清晰、层次分明。如下图为《需求规格说明书》模板中功能需求目录结构。我们以此为基础，说明如何设计良好的目录结构以及其背后对应的软件开发方法。
《需求规格说明书》功能需求部分目录结构
3.2 以系统为单位
“以系统为单位”意味着不同的系统应该并列分别描述其系统需求，体现在目录结构上，就是应该在模板目录基础上增加和“第3章功能需求”完全并列的章节，其子目录完全相同。如果系统比较复杂，应适当的分拆文档，为每一个系统编写独立的《需求规格说明书》。
假设前述银行存款业务的例子中，我们需要同时开发“柜面系统”和“排队系统”，那么在不拆分文档时，其目录结构应如下图所示：
注意，这里分列的系统通常彼此的功能有很大的不同。而有一种情况则需要区分对待，在这种情况下，两个系统的功能大多相近或完全相同，只是在功能接口上输入或输出的内容有所差别。比如，使用同一个服务端的多个不同终端程序，一个为桌面应用、一个为安卓应用、外加苹果应用，这些终端程序功能相近，仅仅是界面元素有所增减或少量的功能删减。如果分别对这些终端应用编写《需求规格说明书》，可能存在大量的重复。 “文字越多，歧义越多，可理解性越差”，在这种情况下，应尽可能减少重复。如可以在同一个用例下，分别描述不同终端的界面事宜，在同一份屏幕说明中说明不同终端的显示差异（有或是无），如下图所示：
其中，“屏幕说明”部分可以在原有表格中，增加相应的列，说明不同终端应用的差异，如下表中“黄色”底色部分。
3.3 采用业务导向的树型层次结构来组织
构建树型层次结构，关键在于逐层分解，而业务导向，则意味着分解的各个功能模块或用例之间存在着关联关系，这个关系由业务流程来维系。在通常的软件界面中，大家最为熟知的就是功能菜单，但如果仅仅依据功能菜单一项一项的进行描述，这样的需求规格说明书对于不熟悉业务流程的人来说很难理解，也不利于他人评审提供建议。
比如某网络相册的产品，其功能菜单中有“创建相册、上传照片、管理相册”三个部分，如果《需求规格说明书》仅仅分别描述上述三个功能，而没有体现三者之间的关系，尤其是当三者描述的顺序完全混乱时，则整篇文档阅读起来，难免给人以逻辑混乱的印象。事实上，如果没有关系的表述，而且文档章节顺序完全没有规律的话，“逻辑混乱”几乎是肯定的答案。
业务导向其实就是从用户的角度来看，理清产品的业务逻辑和交互路径。如上述三个功能菜单之间业务逻辑可以表述为：“用户创建相册->上传相片->管理相册”。而交互路径是指更细的操作步骤的流程顺序（在用例规约中描述）。比如上传相片的交互路径是：点击上传按钮->选择相册->选择本地照片->点击上传->完成。
3.3.1 在“概述”中构建功能模块
首先，需要在《需求规格说明书》中的“概述”部分，根据系统的定义来构建系统的功能模块。从用户的需求出发，设计系统要实现的功能，清楚系统是由几大功能模块构成的。如前述“网络相册”产品，其基本功能模块要包括：创建相册、上传照片、管理相册。然后在这三个模块下细分功能，比如创建相册下的功能包括：创建相册、设置相册名称、设置相册访问权限等等。
把产品的功能模块构建出来了，整个《需求规格说明书》的骨架就有了。如下图所示，“项目管理平台”项目在概述中分为“需求管理、日志管理、项目管理……”等业务模块，则其在第3.1节概述后，分别对各个业务模块予以说明。注意，目录结构应和3.1节概述中的功能模块划分一致。
在“概述”中描述功能模块划分，可以使用“产品功能架构图、分级的功能列表、模块划分图”等方式。如上图为简单的模块划分图。
3.3.2 理清业务逻辑和交互路径
此时需要针对每一个功能模块理清业务逻辑和交互路径。仍以网络相册为例，其业务逻辑可以表述为：用户创建相册->上传相片->管理相册。而交互路径是指更细的操作步骤的流程顺序。比如上传相片的交互路径是：点击上传按钮->选择相册->选择本地照片->点击上传->完成。
在我们的《需求规格说明书》中，交互路径其实就是在用例规约中描述。用例规约的写作参见《需求用例编写规范》。
理清每个功能模块的业务逻辑，其实就是识别每一功能模块的关键业务并通过其业务流程描述其下各子用例之间的关系。如某项目管理系统中需求管理功能模块的核心业务流程如下图所示，其中“绿色”底色为其用例。
在写作《需求规格说明书》时，对每一功能模块应先识别并绘制其关键业务流程，然后再分别描述用例。用例可以使用“颜色标注”的方式在业务流程图中体现。见上图所示。需要的话，应对业务流程辅以文字说明。
3.4 注重设计细节
最后，写好《需求规格说明书》还包括一些细节的设定，比如用例规约、界面元素说明、业务规则细节等等。
其它写作过程中的技巧与注意事项：
- 层次分明，条理清楚。
- 用词准确，切忌模棱两可。
- 细节描述到位，换位思考自己是开发人员，看能否读懂文档。
- 适当搭配图表，增强可读性。
- 文档完成后，可以假想自己是一个开发人员，重新来阅读，看看是否有什么不懂和不清楚的地方，以这种方法来检验文档的质量。
- 合理利用颜色标注说明，提升可阅读性。比如：在功能架构图中利用颜色说明哪些是本文档包含的内容；利用颜色来区分，修改和新增的需求。