概述提出了对软件需求说明的纵览，这有助于读者理解文档如何编写、如何阅读。如：
本章说明XXX产品的软件需求规格书（简称SRS，下同）的编写目的、编写约定、预期读者和参考文献。
章节1.1、编写目的
指出这个软件需求规格书预期的目的。如：
编写本SRS，以期达到下列目的：
章节1.2、文档约定
描述编写文档时所采用的标准或排版约定，包括正文风格、提示区或重要符号。例如，说明了高层需求的优先级是否可以被其所有细化的需求所继承，或者每个需求陈述是否都有其自身的优先级。
章节1.2.1、通用规则
1.编号及应用规则
2.在正式开发之前，TBD（tobedetermined）项均应该消除。
3.需求描述建议：
4.其它约定：
章节1.2.2、编号规则
章节1.2.2.1、ID编号规则
ID=需求类型+4位编号
需求类型：
功能需求SF（SoftwareFunction）
性能需求SP（SoftwarePerformance）
非功能需求NF（None-Function）
外部接口:
用户界面UI（UserInterface）
硬件接口HI（HardwareInterface）
软件接口SI（SoftwareInterface）
通信接口CI（CommunicationInterface）
质量属性QA（QualityAttribute）
业务规则BR（BusinessRule）
用户文档要求UD（UserDocument）
其它需求OR（OtherRequirement）
4位编号：由四位字符组成，每个字符可以为0~9，A-Z，无次序要求，但上下文是唯一的。
注：如果为大产品，需求项很多，可使用5位编号。
章节1.2.2.2、需求过程描述项编号规则
Number=描述分类+4位编号
描述分类：
前置条件C
后置条件R
正常过程N
异常过程E
可选过程A
4位编号：从0XXY开始。XX从01开始，Y从0开始，开始时Y以零编号，修改时，可从中间插入。采用4位数字编号。
章节1.2.2.3、需求过程描述项编号规则
REF=产品（项目）编号+“.”+需求规格书类型+“.”+最高级ID+“.”+次级ID+“.”+…+最低级ID
产品（项目）编号：产品的编号（如只有项目，就用项目编号），如P001等。
需求规格书类型
用户需求URS
产品需求PRS
软件需求SRS
子系统需求SSRS
模块需求MRS
如：P001.SRS.SF0001.A0001.B0002.N0010表示P001产品的软件需求规格书的SF0001需求项的A0001子项的B0002子项的N0010项。
章节1.3、预期读者和阅读建议
列举了软件需求规格书所针对的不同读者，例如开发人员、项目经理、营销人员、用户、测试人员或文档的编写人员。描述了文档中剩余部分的内容及其组织结构。提出了最适合于每一类型读者阅读文档的建议。如：
预期的读者和阅读建议参见表1.1。
表1.1
章节1.4、术语和定义
术语（Terms）可以理解为数据字典的数据项（词条），将本文引用的部分罗列出来。如：
术语和定义参见表1.2。
表1.2
章节1.5、缩略语
缩略语（Abbreviations）为专业词汇或自定义词汇的缩写（一般是英文缩写）。如：
缩略语参见表1.3。
表1.3
章节1.6、参考文献
章节2、综合描述
这一部分概述了正在定义的产品以及它所运行的环境、使用产品的用户和已知的限制、假设和依赖。
章节2.1、产品背景
章节2.2、产品的范围
给出系统边界图和描述。
章节2.3、产品总体功能
概述了产品所具有的主要功能。其详细内容将在第3~6章中描述，所以在此只需要概略地总结，例如用列表的方法给出。很好地组织产品的功能，使每个读者都易于理解。用图形表示主要的需求分组以及它们之间的联系，例如数据流程图的顶层图或类图，都是有用的。
章节2.4、用户类型和特征
章节2.5、运行环境
描述了软件的运行环境，包括硬件平台、操作系统和版本，还有其它的软件组件或与其共存的应用程序。
章节2.6、设计和实现上的限制
确定影响开发人员自由选择的问题，并说明这些问题为什么成为一种限制。可能的限制包括如下内容：
章节2.7、假设和依赖
列举出在对软件需求规格书中影响需求陈述的假设因素(与已知因素相对立)。
这可能包括你打算要用的商业组件或有关开发或运行环境的问题。你可能认为产品将符合一个特殊的用户界面设计约定，但是另一个SRS读者却可能不这样认为。如果这些假设不正确、不一致或被更改，就会使项目受到影响。
此外，确定项目对外部因素存在的依赖。例如，如果你打算把其它项目开发的组件集成到系统中，那么你就要依赖那个项目按时提供正确的操作组件。如果这些依赖已经记录到其它文档(例如项目计划)中了，那么在此就可以参考其它文档。
章节3、功能需求
章节3.1、SF0100功能需求1
需求描述：
优先级：
参与者/角色（用户）：
前置条件：
后置条件：
正常过程：
可选过程：
异常过程：
非功能需求：
注：功能需求的描述，使用UseCase方式，后面将给出一个书写示例。
章节3.2、SF0105功能需求2
章节4、其它非功能需求
这部分列举出了所有非功能需求，外部接口需求和限制不在此处描述。
章节4.1、性能需求
阐述了不同的应用领域对产品性能的需求，并解释它们的原理以帮助开发人员作出合理的设计选择。
你还可以在这里定义容量需求，例如存储器和磁盘空间的需求或者存储在数据库中表的最大行数。
尽可能详细地确定性能的需求。可能需要针对每个功能需求或特性分别陈述其性能需求，而不是把它们都集中在一起陈述。
章节4.2、质量属性
下列质量属性中，选择你需要描述的部分，加以说明，或者加上你认为需要的其它质量属性。
章节4.2.1、有效性
章节4.2.2、效率
效率是用来衡量系统如何优化处理器、磁盘空间或通信带宽。
如果系统用完了所有可用的资源，那么用户遇到的将是性能的下降，这是效率降低的一个表现。拙劣的系统性能可激怒等待数据库查询结果的用户，或者可能对系统安全性造成威胁，就像一个实时处理系统超负荷一样。如：
为了在不可预料的条件下允许安全缓冲，你可以这样定义：“在预计的高峰负载条件下，10％处理器能力和15％系统可用内存必须留出备用。”
在定义性能、能力和效率目标时，考虑硬件的最小配置是很重要的。
章节4.2.3、灵活性
就像我们所知道的可扩充性、增加性、可延伸性和可扩展性一样，灵活性表明了在产品中增加新功能时所需工作量的大小。如果开发者预料到系统的扩展性，那么他们可以选择合适的方法来最大限度地增大系统的灵活性。灵活性对于通过一系列连续的发行版本，并采用渐增型和重复型方式开发的产品是很重要的。
灵活性目标可如下设定：“一个至少具有6个月产品支持经验的软件维护程序员可以在一个小时之内为系统添加一个新的可支持硬拷贝的输出设备。”
章节4.2.4、安全性
安全性(或完整性)主要涉及：防止非法访问系统功能、防止数据丢失、防止病毒入侵并防止私人数据进入系统。
安全性对于通过WWW执行的软件已成为一个重要的议题。电子商务系统的用户关心的是保护信用卡信息，Web的浏览者不愿意那些私人信息或他们所访问过的站点记录被非法使用。安全性的需求不能犯任何错误，即数据和访问必须通过特定的方法完全保护起来。用明确的术语陈述安全性的需求，如身份验证、用户特权级别、访问约束或者需要保护的精确数据。
一个安全性的需求样本可以这样描述：“只有拥有查账员访问特权的用户才可以查看客户交易历史。”
章节4.2.5、互操作性
互操作性表明了产品与其它系统交换数据和服务的难易程度。为了评估互操作性是否达到要求的程度，你必须知道用户使用其它哪一种应用程序与你的产品相连接，还要知道他们要交换什么数据。
“XX系统”的用户习惯于使用Officeexcel表格工具，所以他们提出如下的互操作性需求：“XX系统应该能够导入和导出excel格式的数据。”
章节4.2.6、可靠性
如果软件满足了它的可靠性需求，那么即使该软件还存在缺陷，也可认为达到其可靠性目标。要求高可靠性的系统也是为高可测试性系统设计的。
章节4.2.7、健壮性
一个健壮性需求是这样说明的：“所有的规划参数都要指定一个缺省值，当输入数据丢失或无效时，就使用缺省值数据。”
章节4.2.8、易用性
它所描述的是组成“用户友好”的主要因素。易用性衡量准备输入、操作和理解产品输出所花费的努力。
同样，调查新系统是否一定要与任何用户界面标准或常规的相符合，或者其用户界面是否一定要与其它常用系统的用户界面相一致。这里有一个易用性需求的例子：
“在文件菜单中的所有功能都必须定义快捷键，该快捷键是由Ctrl键和其它键组合实现的。出现在MicrosoftWord2000中的菜单命令必须与Word使用相同的快捷键”。
易用性还包括对于新用户或不常使用产品的用户在学习使用产品时的简易程度。易学程度的目标可以经常定量地测量，例如，
当你定义易用性或可学性的需求时，应考虑到在判断产品是否达到需求而对产品进行测试的费用。
章节4.2.9、可维护性
”在图形引擎工程中，我们知道，我们必须不断更新软件以满足用户日益发展的需要，因此，我们确定了设计标准以增强系统总的可维护性：“函数调用不能超过两层深度”，并且“每一个软件模块中，注释与源代码语句的比例至少为1：20”认真并精确地描述设计目标，以防止开发者做出与预定目标不相符的愚蠢行为。
章节4.2.10、可移植性
可移植性是度量把一个软件从一种运行环境转移到另一种运行环境中所花费的工作量。软件可移植的设计方法与软件可重用的设计方法相似。可移植性对于工程的成功是不重要的，对工程的结果也无关紧要。可以移植的目标必须陈述产品中可以移植到其它环境的那一部分，并确定相应的目标环境。于是，开发者就能选择设计和编码方法以适当提高产品的可移植性。
章节4.2.11、可重用性
从软件开发的长远目标上看，可重用性表明了一个软件组件除了在最初开发的系统中使用之外，还可以在其它应用程序中使用的程度。比起创建一个你打算只在一个应用程序中使用的组件，开发可重用软件的费用会更大些。
可重用软件必须标准化、资料齐全、不依赖于特定的应用程序和运行环境，并具有一般性。确定新系统中哪些元素需要用方便于代码重用的方法设计，或者规定作为项目副产品的可重用性组件库。
章节4.2.12、可测试性
可测试性指的是测试软件组件或集成产品时查找缺陷的简易程度。如果产品中包含复杂的算法和逻辑，或如果具有复杂的功能性的相互关系，那么对于可测试性的设计就很重要。如果经常更改产品，那么可测试性也是很重要的，因为将经常对产品进行回归测试来判断更改是否破坏了现有的功能性。
章节4.3、安全设施需求
一个安全设施需求的范例如下：“如果并发请求数的超过了规定的最大值的90％，那么必须在1秒钟内进行限流处理”
章节4.4、业务规则
列举出有关产品的所有操作规则，例如什么人在特定环境下可以进行何种操作。这些本身不是功能需求，但它们可以是某些功能需求需考虑的业务规则。
一个业务规则的范例如下：“只有持有管理员密码的用户才能执行$100.00或更大额的退款操作。”
章节4.5、用户文档需求
列举出将与软件一同发行的用户文档，例如，用户手册、在线帮助和教程。明确所有已知的用户文档的交付格式或标准。
章节5、外部接口需求
利用本章来确定可以保证新产品与外部组件正确连接的需求。关联图表示了高层抽象的外部接口。需要把对接口数据和控制组件的详细描述写入数据字典中。如果产品的不同部分有不同的外部接口，那么应把这些外部接口的详细需求并入到这一部分的实例中。
章节5.1、用户界面
陈述所需要的用户界面的软件组件。描述每个用户界面的逻辑特征。
现在有UI&UE设计，故可以直接写：
参见XXXUI&UE交互设计。
章节5.2、硬件接口
描述系统中软件和硬件每一接口的特征。这种描述可能包括支持的硬件类型、软硬件之间交流的数据和控制信息的性质以及所使用的通信协议。
章节5.3、软件接口
描述该产品与其它外部组件(由名字和版本识别)的连接，包括数据库、操作系统、工具、库和集成的商业组件。
明确并描述在软件组件之间交换数据或消息的目的。描述所需要的服务以及内部组件通信的性质。确定将在组件之间共享的数据。如果必须用一种特殊的方法来实现数据共享机制，例如在多任务操作系统中的一个全局数据区，那么就必须把它定义为一种实现上的限制。