有这种方法注释需求，可以：
1） 帮助客户对每个需求给予更周密的考虑，通常可以在需求中澄清隐藏的假设； 2） 帮助开发者做出正确的设计决定，并对软件产品不同部分作出相应的努力。 5.2.1 稳定性
注释需求的一种方法是使用稳定性量纲。当一个需求在软件预期的生存期间内描述不改变的话，可以认为该需求是稳定的，否则可以认为是易变的。 5.2.2 必要性等级
注释的另一种方法是把需求分成必须保证级、期望级和任选级。
5） 必须保证是指软件必须和这些需求相一致，否则该软件不可能被接受； 6） 期望是指这些需求将提高软件产品的功能，但如果缺省的话也是可接受； 7） 任选是给开发者一个机会，可以提供某些超出SRS规定的目标。 5.2.3 注意事项
在注释需求之前，必须彻底理解这种注释的实质性含义。
5.3 在表达需求时遇到的共同弊病
SRS的基本点是它必须说明由软件获得的结果，而不是获得这些结果的手段。编写需求的人必须描述的基本问题是：
1） 功能——所设计的软件要做什么；
2） 性能——是指软件功能在执行过程中的速度、可使用性、响应时间、各种软件
功能的恢复时间、吞吐能力、精度、频率等等；
3） 强加于实现的设计限制——在效果、实现的语言、数据库完整性、资源限制、
操作环境等等方面所要求的标准；
4） 属性——可移植性、正确性、可维护性及安全性等方面的考虑因素； 5） 外部接口——与人、硬件、其他软件和其他硬件的相互关系。 编写需求的人应当避免把设计或项目需求写入SRS之中，应当对说明需求设计约束与规划设计两者有清晰的区别。
5.3.1 在SRS中嵌入了设计
在SRS中嵌入设计说明，会过多地约束软件设计，并且人为地把具有潜在危险的需求放入SRS中。
1） SRS必须描述在干什么数据上、为谁完成什么功能、在什么地方、产生什
么结果。SRS应把注意力集中在要完成的服务目标上。通常不指定如下的设计项目：
? 把软件划分成若干模块； ? 给每一个模块分配功能；
? 描述模块间的信息流程或者控制流程； ? 选择数据结构。
2） 把设计完全同SRS隔离开来始终是不现实的。安全和保密方面的周密考虑
可能增加一些直接反映设计约束的需求。例如： ? 在一些分散的模块中保持某些功能；
? 允许在程序的某些区域之间进行有限的通讯； ? 计算临界值的检查和。 3） 通常应考虑到，若要为软件选择高层次的设计，就可能需要大量的资源（可
能占整个产品开发成本的10%-20%以上）。有两种选择：
? 不顾本指南的警告，在SRS中描述了设计。这意味着，或者将一个潜
在不适当的设计作为一个需求进行描述（因为，若要得到好的设计，
所花费的时间是不够的），或者在需求阶段花费了过多的时间（因为在SRS完成之前整个设计分析都要完成）；
? 采用本指南中5.1.3条中的建议，用模型设计描述需求，这种模型设
计只用于辅助描述需求，而不使之成为实际的设计。
5.3.2 在SRS中嵌入了一些项目要求
SRS应当是描写一个软件产品，而不是描述生产软件产品的过程。
项目要求表达客户和开发者之间对于软件生产方面合同性事宜的理解（因此不应当包括在SRS中）例如：
1） 成本； 2） 交货进度； 3） 报表处理； 4） 软件开发方法； 5） 质量保证；
6） 确认和验证的标准； 7） 验收过程。
项目需求在另外文件中描述。在SRS中提供的只是关于软件产品本身的需求。
6 SRS大纲
本章着重讨论SRS的每一个基本部分，可以作为一个SRS的大纲。表1给出该大纲目录，表2至表5给出大纲中第3章的具体需求内容。各开发者和客户应当根据所描述的实际情况，按本指南有关规定编写自己的SRS。
1 前言 1.1 目的 1.2 范围 1.3 定义、缩写词、略语 1.4 参考资料 2 项目概述 2.1 产品描述 2.2 产品功能 2.3 用户特点 2.4 一般约束 2.5 假设和依据 3 具体需求 （参阅本指南6.3.2 条中具体需求的组织形式） 附录 索引
6.1 前言（SRS第1章）
本章提供整个SRS综述。 6.1.1 目的（SRS的1.1条）
在这一条包括下列内容： 1）描述实际SRS的目的； 2）说明SRS所预期的读者。 6.1.2 范围（SRS的1.2条）
1） 通常应考虑到，若要为软件选择高层次的设计，就可能需要大量的资源（可
能占整个产品开发成本的10%-20%以上）。有两种选择：
2） 用一个名字标识被生产的软件产品。比如：×××数据库系统，报表生成
程序等等；
3） 说明软件产品将干什么，如果需要的话，还要说明软件产品不干什么； 4） 描述所说明的软件的应用。应当：
? 尽可能精确地描述所有相关的利闪、目的、以及最终目标。
? 如果有一个较高层次的说明存在，则应该使其和高层次说明中的类似
的陈述相一致（例如，系统的需求规格说明）。
6.1.3 定义、缩写词、略语（SRS的1.3条）
本条中必须提供全部需求的术语、缩写词及略语的定义，以便对SRS进行适当的解释。这些信息可以由SRS的附录提供。也可以参考其他的文件。 6.1.4 参考资料（SRS的1.4条）
本条应包括：
1） 在SRS中各处参照的文件的全部清单，如经核准的计划任务书，上级机关
批文、合同等；
2） 列出其他参考资料，如属本项目的其他已发表的文件和主要文献等。每一
个文件、文献要有标题，索引号或文件号，发布或发表日期以及出版单位； 3） 详细说明可以得到该参考文件的来源。这个信息可以通过引用附录或其他
文件提供。
6.2 项目概述（SRS第2章）
本章应描述影响产品和其需求的一般因素，本章不说明具体的需求，而仅使需求更易于理解。
6.2.1 产品描述（SRS的2.1条）
这一条是把一个产品用其他有关的产品或项目来描述。
1） 如果这个产品是独立的，而且全部内容自含，应在此说明；
2） 如果SRS定义的产品是一个较大的系统或项目中的一个组成部分，那么本
条应包括如下内容：
? 要概述这个较大的系统或项目的每个组成部分的功能，并说明其接口； ? 指出该软件产品主要的外部接口。在这里，不要求对接口详细地描述，
详细描述放在SRS其他章条中；
? 描述所使用的计算机硬件、外围设备。这里仅仅是一个综述性描述。 在本条的描述中，用一个方框图来表达一个较大的系统或项目的主要组成部分、相互联系和外部接口是非常有帮助的。
本条既不用来强迫进行设计方案的描述，也不是描述在解决问题时的设计约束。本条应对在以后具体需求一章中说明的设计约束提供理由。 6.2.2 产品功能（SRS的2.2条）
本条是为将要完成的软件功能提供一个摘要。例如，对于一个记帐程序来说，SRS可以用这部分来描述：客户帐目维护、客户财务报表和发票制作，而不必把功能所要求的大量的细节描写出来。
有时，如果存在较高层次的规格说明时，则功能摘要可直接从中取得，这个较高层次的规格说明为软件产品分配了特殊的功能，为了清晰起见，请注意：
1） 编制功能的一种方法是制作功能表，以便客户或者第一次读这个文件的人
都可以理解；
2） 用方框图来表达不同的功能和它们的关系也是有帮助的。但要牢记，这样
的图不是产品设计时所需求的，而只是一种有效的解释性的工具。 这一条不用作陈述具体需求，只是对后来SRS中具体需求一章中为什么要描述的某些需求提供理由。
6.2.3 用户特点（SRS的2.3条）
本条要描述影响具体需求的产品的最终用户的一般特点。
许多人在软件生存周期的操作和维护阶段与系统相关。而这些人中有用户、操作员、维护人员和系统工作人员。这些人的某些特点，象教育水平、经验、技术、专长等，都是施加于系统操作环境的重要约束。
如果系统的大多数用户是一些临时用户，那么就要求系统包含如何完成基本功能的提示，而不是假设用户已经从过去的会议或从阅读用户指南中了解到这些细节。
这一条的内容不能用来陈述具体需求或强加若干特殊的设计约束，本条应对在SRS的具体需求一章之中的某些具体需求或设计约束的描述提供理由。 6.2.4 一般约束（SRS的2.4条）
本条对设计系统阳限制开发者选择的其他一些项作一般性描述。而这些项将限定开发者在设计系统时的任选项。这些包括：
1） 管理方针； 2） 硬件的限制；
3） 与其他应用间的接口； 4） 并行操作； 5） 审查功能； 6） 控制功能；
7） 所需的高级语言； 8） 通信协议； 9） 应用的临界点；
10）安全和保密方面的考虑。
本条不陈述具体需求或具体设计约束：而对SRS的具体需求一章中为什么要确定某些具体需求和设计约束提供理由。 6.2.5 假设和依据（SRS的2.5条）
本条列出影响SRS中陈述的需求的每一个因素。这些因素不是软件的设计约束，但是它们的改变可能影响到SRS中的需求。例如：假定一个特定的操作系统是在被软件产品指定的硬件上使用的，然而，事实上这个操作系统是不可能使用的，于是，SRS就要进行相应的改变。 6.3 具体需求（SRS的第3章）
本章应包括软件开发者在建立设计时需要的全部细节。这是SRS中篇幅最大和最重要的部分。
1） 根据本指南第4章所规定的准则（如可验证性、无歧义性等），对每一个需求
细节作具体描述；
2） 在SRS的前言、项目概述、附录部分的有关讨论中，要提供对任何一个具体
需求交叉引用的背景；
3） 具体需求分类的方法如下：
? 功能需求； ? 性能需求；
? 设计约束； ? 属性；
? 外部接口需求。 本章中要注意的二点是：
1） 符合逻辑的和可读的方式组织；
2） 详细描述每个需求，使该需求应达到目标能够用指定的方法进行客观的验证。 6.3.1 具体需求的内容
6.3.1.1 功能需求
本条描述软件产品的输入怎样变换成输出。即软件必须完成的基本动作。 对于每一类功能或者有时对于每一个功能，需要具体描述其输入、加工和输出的需求。这通常由四个部颁组成：
1） 引言
这部分描述的是功能要达到的目标、所采用的方法和技术，还应清楚说明功能意图的由来和背景。
2） 输入
这部分应包括：
? 详细描述该功能的所有输入数据，如：输入源、数量、度量单位、时
间设定、有效输入范围（包括精度和公差）；
? 操作员控制细节的需求。其中有名字、操作员活动的描述、控制台或
操作员的位置。例如：当打印检查时，要求操作员进行格式调整； ? 指明引用接口说明或接口控制文件的参考资料。 3） 加工
定义输入数据、中间参数，以获得预期输出结果的全部操作。它包括如下的说明：
? 输入数据的有效性检查；
? 操作的顺序，包括事件的时间设定；
? 异常情况的响应，例如，溢出、通信故障、错误处理等； ? 受操作影响的参数； ? 降级运行的要求；
? 用于把系统输入变换成相应输出的任何方法（方程式、数学算法、逻
辑操作等）；
? 输出数据的有效性检查。 4） 输出
这部分应包括：
? 详细描述该功能所有输出数据，例如：输出目的地、数量、度量单位、
时间关系、有效输出的范围（包括精度和公差）、非法值的处理、出错信息；
? 有关接口说明或接口控制文件的参考资料。
此外，对着重于输入输出行为的系统来说，SRS应指定所有有意义的输入、输出对及其序列。当一个系统要求记忆它的状态时，需要这个序列，使得它可以根据本次输入和以前的状态作出响应。也就是说，这种情况犹如有限状态机。
6.3.1.2 设计约束
设计约束受其他标准、硬件限制等方面的影响。
1） 其他标准的约束：本项将指定由现有的标准或规则派生的要求。例如：报
