b. 综合描述
　　这一部分概述了正在定义的产品以及它所运行的环境、使用产品的用户和已知的限制、假设和依赖。
b.1 产品的前景
　　描述了软件需求规格说明中所定义的产品的背景和起源。说明了该产品是否是产品系列中的下一成员，是否是成熟产品所改进的下一代产品、是否是现有应用程序的替代品，或者是否是一个新型的、自含型产品。如果软件需求规格说明定义了大系统的一个组成部分，那么就要说明这部分软件是怎样与整个系统相关联的，并且要定义出两者之间的接口。
b.2 产品的功能
　　概述了产品所具有的主要功能。其详细内容将在d中描述，所以在此只需要概略地总结，例如用列表的方法给出。很好地组织产品的功能，使每个读者都易于理解。用图形表示主要的需求分组以及它们之间的联系，例如数据流程图的顶层图或类图，都是有用的。
b.3 用户类和特征
　　确定你觉得可能使用该产品的不同用户类并描述它们相关的特征。有一些需求可能只与特定的用户类相关，将该产品的重要用户类与那些不太重要的用户类区分开。
b.4 运行环境
　　描述了软件的运行环境，包括硬件平台、操作系统和版本，还有其它的软件组件或与其共存的应用程序。
b.5 设计和实现上的限制
　　确定影响开发人员自由选择的问题，并说明这些问题为什么成为一种限制。可能的限制包括如下内容：
　　o 必须使用或者避免的特定技术、工具、编程语言和数据库。
　　o 所要求的开发规范或标准。
　　o 企业策略、政府法规或工业标准。
　　o 硬件限制，例如定时需求或存储器限制。
　　o 数据转换格式标准。
b.6 假设和依赖
　　列举出在对软件需求规格说明中影响需求陈述的假设因素，以及项目对外部因素存在的依赖。

c. 外部接口需求
　　利用本节来确定可以保证新产品与外部组件正确连接的需求。
c.1 用户界面
　　陈述所需要的用户界面的软件组件。描述每个用户界面的逻辑特征。以下是可能要包括的一些特征：
　　o 将要采用的图形用户界面（ G U I）标准或产品系列的风格。
　　o 屏幕布局或解决方案的限制。
　　o 将出现在每个屏幕的标准按钮、功能或导航链接（例如一个帮助按钮）。
　　o 快捷键。
　　o 错误信息显示标准。
　　对于用户界面的细节，例如特定对话框的布局，应该写入一个独立的用户界面规格说明中，而不能写入软件需求规格说明中。
c.2 硬件接口
　　描述系统中软件和硬件每一接口的特征。这种描述可能包括支持的硬件类型、软硬件之间交流的数据和控制信息的性质以及所使用的通信协议。
c.3 软件接口
　　描述该产品与其它外部组件（由名字和版本识别）的连接，包括数据库、操作系统、工具、库和集成的商业组件。明确并描述在软件组件之间交换数据或消息的目的。描述所需要的服务以及内部组件通信的性质，确定将在组件之间共享的数据。
c.4 通信接口
　　描述与产品所使用的通信功能相关的需求，包括电子邮件、Web浏览器、网络通信标准或协议及电子表格等等。定义了相关的消息格式，规定通信安全或加密问题、数据传输速率和同步通信机制。

d. 系统特性
d.1 说明和优先级
　　简短说明该系统的特性，并指出该特性的优先级是高、中，还是低。另外，还可以包括对特定优先级部分的评价，例如利益、损失、费用和风险。
d.2 激励/响应序列
　　列出输入激励（用户动作、来自外部设备的信号或其它触发器）和定义这一特性行为的系统响应序列。
d.3 功能需求
　　详列出与该特性相关的详细功能需求。这些是必须提交给用户的软件功能，使用户可以使用所提供的特性执行服务或者使用所指定的使用实例执行任务。

e. 其他非功能需求
e.1 性能需求
　　阐述了不同的应用领域对产品性能的需求，并解释它们的原理以帮助开发人员作出合理的设计选择。确定相互合作的用户数或者所支持的操作、响应时间以及与实时系统的时间关系。
e.2 安全设施需求
　　详尽陈述与产品使用过程中可能发生的损失、破坏或危害相关的需求。定义必须采取的安全保护或动作，还有那些预防的潜在的危险动作。明确产品必须遵从的安全标准、策略或规则。
e.3 安全性需求
　　详尽陈述与系统安全性、完整性或与私人问题相关的需求，这些问题将会影响到产品的使用和产品所创建或使用的数据的保护。定义用户身份确认或授权需求，明确产品必须满足的安全性或保密性策略。
e.4 软件质量属性
　　详尽陈述与客户或开发人员至关重要的其它产品质量特性，这些特性必须是确定、定量的并在可能时是可验证的。
e.5 业务规则
　　列举出有关产品的所有操作规则，例如什么人在特定环境下可以进行何种操作。这些本身不是功能需求，但它们可以暗示某些功能需求执行这些规则。
e.6 用户文档
　　列举出将与软件一同发行的用户文档部分，例如用户手册、在线帮助和教程，明确所有已知的用户文档的交付格式或标准。

f. 其他需求
　　定义在软件需求规格说明的其它部分未出现的需求，例如国际化需求或法律上的需求。你还可以增加有关操作、管理和维护部分来完善产品安装、配置、启动和关闭、修复和容错，以及登录和监控操作等方面的需求。这一部分可以省略。


　　无论你的需求从何而来，也不管你是怎样得到的，你都必须用一种统一的方式来将它们编写成可视文档。业务需求要编写项目视图和范围文档，用户需求要用一种标准用例模板编写文档，而软件需求规格说明则包含了软件的功能需求和非功能需求。
　　对于不同的需求对象，应该采用不同的需求规格说明方法，目前还不存在一种能适应所有对象的说明方法。通常，需求规格说明包含形式化和非形式化两种方法，形式化方法以数学理论为基础，使需求说明更加严密和精确，但往往难以掌握，特别是不易与用户沟通。非形式化方法采用某种说明规范，并定义一些图形符号，使需求说明更加直观和易于理解。与形式化方法相比，非形式化方法的应用更加普遍。