软件需求说明书-模板.doc

研制令号

日期

项目
软 件 需 求 说 明 书
（该文档仅供内部参考）

负责单位： 研发部门名称
协作单位： 协作单位名称 （如有）
作 者： 研发人员签名
批 准： 总工程师签名

修改及签收情况记录：

版本号
修改人
修改日期
修改批准人
部门资料室签收

研发人员签名

研发部门主任签名
部门资料员存档签名

**********股份有限公司

软件需求说明书 〈Vm.n〉
修改记录
文件编号
版本号
拟制人/
修改人
拟制/修改日期
更改理由
主要更改内容
（写要点即可）
<
Vm.n
XXX
2006/10/24
XXX
XXXX>

注1：每次更改归档文件（指归档到事业部或公司档案室的文件）时，需填写此表。
注2：文件第一次归档时，“更改理由”、“主要更改内容”栏写“无”。

<
模板修改记录
文件编号
版本号
拟制人/
修改人
拟制/修改日期
更改理由
主要更改内容
（写要点即可）

V1.0
***
2013-12-23
初版

>
目 录
1 引言 7
1.1 编写目的 7
1.2 预期的读者和阅读建议 7
1.3 文档约定 7
2 术语、定义和缩略语 8
2.1 术语、定义 8
2.2 缩略语 8
3 综合描述 9
3.1 背景 9
3.2 功能概述 10
3.3 运行环境 11
3.4 用户类及其要求 11
4 具体需求 13
4.1 功能需求 18
4.1.1 <需求编号1 + 两个空格 + 需求名称1（use case例）> 19
4.1.2 <需求编号2 + 两个空格 + 需求名称2（IPO例）> 25
4.2 性能需求 28
4.2.1 <需求组1编号 + 两个空格 + 需求组1名称> 28
4.2.2 <需求编号2 + 两个空格 + 需求名称2> 29
4.3 质量属性需求 29
4.3.1 可靠性 31
4.3.2 安全性 32
4.3.3 可维护性 33
4.3.4 可移植性 34
4.3.5 扩展性 34
4.3.6 可测试性 35
4.4 外部接口需求 36
4.5 其它需求 36
4.5.1 通用化、系列化、模块化需求 36
4.5.2 设计和实现上的限制 37
4.5.3 执行标准 39
4.5.4 国际化需求 41
4.5.5 杂类需求 42
5 需求追踪 43
6 验收准则 43
7 参考文献 44

<术语说明：
a) 需求：是指“被描述系统”“做什么”（功能需求）及“做什么”时的水平（非功能需求，如性能需求、质量属性需求、外部接口需求、其它需求）。
b) 软件需求：由软件实现的需求。包括功能需求、性能需求、质量属性需求、外部接口需求及其它需求。
c) 软件需求说明书（software requirement specification，SRS）：是这样一类文档，它以特定的格式记载了软件必须实现的所有软件需求（又叫软件需求规格、软件需求规格说明），在必要时，也应描述软件肯定不做什么（何谓必要？在某些上下文语境中，如果不作这样的声明，可能会令读者发生误会）。SRS为后续的项目软件计划、概要设计、（软件）系统测试、用户文档等工作提供基础与约束。

编制SRS时经常被问到以下问题：
a) 实践中出现了不少这样的情况：明明要求写软件需求说明书，但结果写出了模块需求说明书。这实际上反映了这些实践未正确确定“被描述系统”。那么，如何确定“被描述系统”呢？
1) 在编写SRS前，一定要明确“被描述系统”，该系统应是上游文档中已经明确划分出来的；同时应将“被描述系统”作为黑盒（特殊情况下可以是灰盒甚至是白盒，如网管软件，可以按终端、服务器）来描述。
2) 对于纯软件项目，很显然，由于SRS的上游文档－研制任务书－没有对软件进行划分，因此，SRS中“被描述系统”应该是整个软件，而不是其中的某个模块。
3) 对于软硬件大系统，一般通过系统设计活动，SRS的上游文档－系统方案－已经对系统进行了划分，因此，SRS中“被描述系统”可以是划分出来的任何一个软件块。
b) 应该编写几篇SRS？
1) 对于软硬件大系统，SRS是根据系统方案、标准/协议/规范、研制规范、原始需求（其中可能直接含有功能需求、性能需求、质量属性需求、外部接口需求、其它需求）开发出来的。根据系统的复杂程度，可以编制一到多篇SRS。如果SRS的上游文档（系统方案）满足其编制要求，则可以为每个单板的软件部分（如果该单板存在软件的话）写一篇SRS。
注意：在系统方案模板中，此处的单板软件被统称为“软件子系统”，该“子系统”（按业务按纵向划分）的概念比我们熟悉的诸如“OSS子系统”、“DBS子系统”更广泛，“OSS子系统”、“DBS子系统”（横向即分层划分）等是通过软件概要设计设计出来的，并体现在《软件总体设计方案》中。
2) 对于纯软件项目，SRS是根据研制任务书、标准/协议/规范、原始需求说明书开发出来的。一般说来，只写一篇SRS是比较合适的。
c) SRS编写到什么程度才算完成？比较通行的原则是：
1) 如果设计与开发人员需要SRS的作者额外的解释才能理解需求，并进而进行设计和实现，则在继续工作前，需求还需要进一步细化。
2) 如果（软件）系统测试人员需要SRS的作者额外的解释才能理解需求，并进而编写（软件）系统测试规程/测试用例，则在继续工作前，需求还需要进一步细化。
d) 在概要甚至详细设计前怎么能描述功能需求的正常过程呢？
1) 首先要明确，软件需求描述的是“被描述系统”（如整个软件或某个软件子系）对外提供的功能、性能、质量属性、外部接口等，可以将“被描述系统”看成一个黑盒（如果在需求描述的过程中，涉及到了“被描述系统”内部的组成，则可以认为该描述不满足要求。当然，也有些例外情况。如对于网管这种已经很成熟的软件，在描述需求时，可以按终端与服务器分别进行描述）。而概要设计是对“被描述系统”内部组成及其相互关系进行设计，此时，“被描述系统”是一个白盒。
2) 功能需求的过程描述是对完成功能的操作/执行步骤（而不是具体的内部实现流程）进行描述，一方面为后续设计提供基本的处理流程，另一方面（更为重要）在描述正常过程、可选过程及异常过程（后两个过程在以往的实践中经常需要到详设、甚至编码时才能部分确定）的过程，揭示各种数据项（详细定义于数据字典中）及业务规则（如数据合法性、一致性、匹配等）。
3) 除了设计和实现上的限制及标准化相关需求外，SRS只描述软件“做什么”，不应该包括设计、构造、测试或工程管理的细节。而概要设计是讲“如何做”才能满足“做什么”。

编制SRS时，应考虑以下情况：
a) 在编制SRS前，应熟悉软件需求说明书评审检查单。在编制过程中应注意避免出现检查单中所列的常见问题。
b) 如果不能保证与上游文档间的追踪关系，则SRS的编制就是失败的，同行评审将不能关闭（甚至可以将这个要求列入同行评审的准入条件）。因此，对于SRS的作者来说，应将需求追踪放到足够重要的位置。作为检查的手段之一，在提交SRS进行同行评审前，作者应先进行需求追踪。
c) 对于需求主要由协议/标准/规范规定的软件，在编制SRS时，为了准确、完整描述需求，同时为减少文档的规模，可以采用“引用”的方法（建议句式为“……见……”），但“引用”应完整，读者能方便、快速地找到目标内容。这就要求引用时应列出协议/标准/规范名称、篇/章节号（如果不是整节引用，还应列出“开始页号及行号、结束页号及行号”）。如果是不完全引用，应明确说明并指出异同。注意：此处未要求列出具体版本，“协议/标准/规范”的版本信息在“执行标准”中统一列出，这样可避免同时引用一份“协议/标准/规范”的多个版本。这也意味着，一旦“协议/标准/规范”发生变更，所有的引用可能都得修改。本条要求同样适用于对文件的引用。
d) 为了更好地使用需求追踪工具RequisitePro（以下简称RP）进行需求追踪，在描述需求时应注意图与表格的使用。
1) 图可以是Word图（此处图是指插入的“对象”）、PaintBrush图、PowerPoint图、Visio图等，但应是“嵌入型“的，而不能是“浮于文字上方”等其它形式。同时，应尽可能将图插在需求描述的中间，这样当图发生变化时，就可以通过在图前或图后加减空格，使得RP知道需求发生了变化。
2) 由于RP只能识别整表或一个一个的单元格，因此，一条需求要么只占一个单元格，要么占满整表。

编制本文档时，容易犯的错误有：
a) 不顾文档上下游之间的关系，先编写设计方案，然后（有些项目拖得非常后）再编写本文档。这种做法是不对的，容易导致几个问题。一是在没有确定做什么（需求）的情况下就去描述怎么做（设计），极易导致返工。二是在需求文档中大段大段地描述如何设计与实现。三是在已有设计文档的情况下，写需求文档被认为是炒冷饭，因此不愿意再完整编写。
b) 认为只有在详细设计时才可能把处理过程写清楚。甚至认为功能需求根本无需描述处理过程，因为那是详细设计要做的事。这种认识无疑是错误的。因为，用户是通过与软件（系统）交互来完成其任务的，如果设计与实现的交互过程与用户要求或想象的不一致，则用户就会认为软件（系统）不好。因此，交互过程应最大限度地被满足，应该尽早在需求说明书中描述。另外，可选、异常及业务规则（如“只有经理级人员才可查看成本价”）都隐藏于交互过程中，在需求开发过程中，如果没有描述交互，则很可能遗漏可选、异常及业务规则。
c) 在一段中描述若干条需求，或将若干需求合并在一条需求中描述（常见于“性能需求”的描述中）。这种写法比较难以阅读，进行需求追踪时捕获需求也不是很方便。
d) 对于非功能需求（如性能、质量属性需求等），只定性描述（如系统要稳定、CPU占用率低）。这样的描述无法验证。应该定量描述，且还应描述对应的条件。

本模板在格式上有以下一系列约定：
a) 用“< >”括起来的内容，是编写指导，在使用本模板编制的文档中应予以删除或去掉“< >”后予以适当沿用。
b) 本模板提供的示例，格式上都采用整行的“<===Example Begin==…”和“====Example End==…==>”框起来，同时还会给例子一个编号和名称，以方便阅读与引用。
c) 为了方便模板使用者删除，对<>内的所有编写指导文字都使用蓝色，但<>本身保持黑色。同时，由于示例部分可能会被模板的使用者直接沿用，因此仍然使用黑色，（即“<===Example Begin==…”和“====Example End==…==>”、或者其它如表格中的例子用黑色）。但如果示例中又插入了一些指导说明文字，则这些文字必须用蓝色。
d) 如果某章节内容无需填写，而且本模板又没有特殊要求或说明，则在该章节下写“无”，而不要将该章节删除或不填写任何内容（即留白。留白将使评审员或读者无法判断：是本章节内容无需填写还是因为疏忽而忘了填写？）。

1 引言
1.1 编写目的
本文通过详细描述软件的功能需求、性能需求、质量属性需求、外部接口需求以及其它需求，为后续概要设计、软件（系统）测试、用户文档等工作提供基础与约束。
1.2 预期的读者和阅读建议
预期的读者和阅读建议参见表1.1。
表1.1
读者分类
阅读重点及目的
备注
<项目经理
全文，并据此编制/修订项目软件）开发计划等。

设计与开发工程师
需求的完整性、正确性、可行性、优先级、无二义性，为概要设计作准备。

市场工程师/客户代表
需求的必要性、优先级，并据此准备市场资料。

测试工程师
需求的可验证性，并据此准备（软件）系统测试方案。

文档工程师
全文，为编写用户文档作准备。
>
1.3 文档约定
<本节描述编写文档时所采用的排版约定（如正文风格、重要符号），说明需求优先级的取值及其含义等。应将每一类内容用一段或若干段进行描述，即应避免在一段中描述所有这些内容。>
<===Example Begin============================
例 文档约定
本文使用了如下的文档约定：
1) 表头文字使用4级灰度背景；
2) 插图一律使用MS Visio 2003中文版绘制，并一律“嵌入”于需求描述正文中，而非“浮于文字上方”。；
3) 用同号、同体但加粗的文字来强调需要读者重视的内容。
4) 采用用例（use case）技术对功能需求进行描述。
另外，每个需求都有优先级属性。优先级的可能取值为：5、4、3、2、1，具体定义如下：
5：是必须的，它规定了系统/软件的必备功能。没有这些功能，系统/软件将不能完成用户的工作，从而也就无法达到市场的准入条件。
4：是重要的，它规定了那些竞争对手已经实现且用户感觉很好的功能、本系统/软件区别于其它同类系统/软件的独特功能及其它一些功能。只有完成这些功能，才能使本系统/软件有市场竞争力。
3：是应该的，它规定了当前版本可以不做, 但必须在未来版本中实现的功能。此种需求对系统/软件的体系结构影响可能较大，因此必须在系统分析及设计时予以考虑。
2：是可能的，它规定了那些有了会更好但没有也没有什么关系的功能，如一些提高效率的小工具。
1：是备忘的，它规定了我们想象的但目前无法或无需实现的需求。
====Example End=========================================>
2 术语、定义和缩略语
2.1 术语、定义
本文使用的专用术语、定义见表2.1，通用术语、定义见<文件编号> 《术语、定义和缩略语》。
表2.1
术语/定义
英文对应词
含 义
<需求追踪记录
requirement trace record
表示需求之间及需求和其它工作产品元素之间相互关联关系的文档，可利用字处理工具、表格工具、数据库工具或专用需求管理工具建立和维护。
工作产品元素
work product element
工作产品的单元性的构成，如：用例、需求、设计单元、函数、测试用例、用户手册章节等>
2.2 缩略语
本文使用的专用缩略语见表2.2，通用缩略语见<文件编号> 《术语、定义和缩略语》。缩略语已按其第1个字母顺序排列。<注意：缩略语应按其第一个字母顺序排列>
表2.2
缩略语
英文原文
中文含义

3 综合描述
3.1 背景
<说明：一般说来，SRS中应有项目范围的描述，而项目范围一般通过项目视图并最终通过业务需求来体现。我司不管哪种类型的项目，总要首先编写《研制任务书》，将业务需求、项目视图、范围写在《研制任务书》中是最合适的。因此，SRS中不反映这部分内容。>
<本节主要描述以下内容：
a) 系统的背景和起源。重点说明该系统是否是产品系列中的下一成员、是否是现有应用的替代品，或者是否是一个新型的、自含型产品。对于在老版本之上升级的系统，则还应说明：
1) 老版本出现的主要问题；
2) 新版本需要增加或改进的主要内容。
此段内容可能来自于可行性研究报告等上游相关文档。应该对相关内容进行概括而不是照抄，篇幅一般应控制在5个自然段之内。
b) 本系统在整个系统或整个环境中的位置。必须使用上下文图(context diagram) 或高层用例图说明本系统（必须用文字及不同的颜色明确标识出来）与外界（可能包括整个系统外的实体）之间的联系，如图3.1。上下文图能清晰地表达系统与外部环境的边界，及系统与外部环境的关系，帮助读者更好、更快地理解被描述的系统。实践中经常犯的错误是：
1) 不画图；
2) 画了系统内部组成图或协议栈；
3) 在上下文图中，还描述了外部系统之间关系。

图3.1 “化学制品跟踪系统”上下文图
>
<===Example Begin====================================================
例 背景
网管软件需要管理两种网元：一种是ANU，一种是ICSC。两种网元不同之处在于前者用的是A型机平台，后者用的是B型机平台。两者的操作方式差异很大：ANU的操作以字符人机命令为主；ICSC的操作命令基本上已实现图形化。对于用户来说，需要在一个网管软件上实现对这两种网元的统一处理。本文即描述了统一管理ANU和ICSC的网管软件的需求。
图3.2描述了本网管软件的上下文图(Context diagram)。

图3.2 上下文图
本网管软件与外界的联系见图3.2的文字说明。<如图中没有描述这种联系，则应在此处用文字单独、简要描述。>
====Example End===============================================>
3.2 功能概述
<本节概述软件所具有的主要功能（如果需要，也可描述性能等需求）。由于其详细内容将在“具体需求”中描述，因此此处需要以较高的层次（如需求组）对需求进行概括性的总结，直接罗列“4.1 功能需求”中的所有需求（如用一个表格）并不是一个好主意，因为这会引起内容冗余以致引起维护问题，还会增大文档篇幅。可以使用图形表示主要的需求组以及它们之间的关系。
为什么要这样做呢？因为一般的软件需求说明书的规模都较大，上百页甚至数百页的规模都比较常见，如果在文档的开头没有对软件完成的主要功能进行介绍的话，读者只有在通读完所有内容后才能知道软件是干什么的，这就会影响读者的阅读情绪并进而影响阅读效果。
本节示例中的规划大师PlanMaster (V2)共有上百个比较重要的功能，但在进行功能概述时只在功能组这一级罗列（只有8行），任何具体功能都可归结到这8个功能组中，因此满足了覆盖具体需求的要求。同样，用户需求也未游离于这8个功能组之外，因此也覆盖了其上游文档《系统需求论证说明》（规划大师是纯软件项目）。>
<应注意避免本节易犯的三个主要错误：
a) 写得过于详细，而后面的“具体需求”则写的不完整（如“输入”、“处理”不是写“略”就是写“无”）。
b) 不能覆盖“4.1 功能需求”中的内容。
c) 不能与上游文档如《系统方案》中描述的软件功能相对应（对于软硬件大系统）。
>
<===Example Begin====================================================
例 功能概述
本软件具备以下主要功能：
a) 工程及设计管理；
b) 用于移动通讯领域的地理信息系统；
c) 数据管理（如设计参数、天线、传播模型、测试数据、基站小区等）；
d) 网络规划与分析（如基站小区规划、频率规划、覆盖干扰分析、话务分析等）；
e) 网络模拟（如小区选择、重选、切换等模拟）；
f) 网络优化（如话务均衡、手机测试数据的统计分析、OMC-R性能测量数据的统计分析等）；
g) 视图管理（提供各种相关数据、分析结果的显示等功能）；
h) 实用及辅助工具（提供报告生成、两点间信息查看等功能）。
====Example End====================================================>
3.3 运行环境
<本节描述软件的运行环境，包括硬件环境、操作系统及其版本，还有其它的软件组件或与其共存的应用程序。如果有版本配合要求、补丁要求，则应明确列出（如使用Windows 98，则Office可以使用97及其以上版本，如使用Windows2000，则应打上SP2，且Office只能使用2000版本且应打上SP1）。如不存在某项，则填写“无”，不要留白。
如果对开发环境有要求，可以写在“4.5.2. 设计与实现的限制”一节中。>
运行环境见表3.1。
表3.1
名 称
硬件(CPU/RAM/HD)
操作系统及其版本
其它软件环境
<

MMSP
PIII700/1G/18G
Windows NT 4 Server
Oracle 8i
DB Server
SPARC/1G/18G
SUN Solaris X
Oracle 8i
Bill Server
SPARC/1G/18G
SUN Solaris X
Oracle 8i>
3.4 用户类及其要求
<本节描述本软件的不同用户类并描述他们相关的特征。应根据用户使用软件的频度、应用领域和计算机系统知识、需要完成的任务、地理上的布局以及访问优先级等对用户进行分组。不同的用户类其需求是不同的，某些用户类的需求可能更加重要，需要优先考虑。本节内容对后续的设计会产生一定的约束与限制。
每一个用户类都有自己的一系列功能和非功能需求。如：一个没有经验或偶尔使用电脑的用户关心软件是否简单易用，因此，菜单、提示符和向导是很重要的。然而，对于那些一天使用几小时软件的用户，他们更关心软件的易用性和高效性，所以他们喜欢使用快捷键、宏以及脚本功能(scripting facility)。
有一些受软件影响的人并不一定是软件的直接使用者，而是通过报表或其它应用程序访问本软件的数据和服务。这些非直接的或次级(secondary )的用户也有自己的需求，可以将这些人加入“附加的用户类”。
用户类不一定都指人，其它应用程序或系统接口所用的硬件组件也可看成是附加用户类的成员。以这种方式来看待应用程序接口，可以帮助确定软件中那些与外部应用程序或组件有关的需求。
在项目中，要尽早为项目确定并描述出不同的用户类，这样，就能从每一个重要的用户类代表中获取不同的需求。>
<===Example Begin====================================================
例 用户类及其要求
本软件的用户分两类。一类为普通用户，一类为系统管理员。
普通用户为电信运营商的操作维护人员，一般具备计算机操作和unix、Windows操作系统的基础知识；熟悉SDH、WDM和数据传输系统基本原理。
系统管理员负责管理本软件。一般具备网络维护及管理、数据库维护及管理方面的知识，对中间件技术（如CORBA）也应该有一定的了解。
====Example End====================================================>

4 具体需求
<本章描述功能需求、性能需求、质量属性需求、外部接口需求及其它需求。
我们规定：
a) 功能需求编号的前缀为SRF（F表示功能）；
b) 性能需求编号的前缀为SR-P（P表示性能）；
c) 质量属性需求编号的前缀为SR-Q（Q表示质量）；
d) 外部接口需求编号的前缀为SR-I（I表示接口）；
e) 其它需求编号的前缀为SR-M（M表示杂类）。
需要说明的是，如果一个项目有多篇SRS，假定划分的粒度是子系统，则其编号前缀应改为：“SR-” + “子系统名” + “-” + “需求类别（如F、P、Q、I、M）”，如SR-DB-F。如果需求是分组描述的，则还要在“需求类别”后再加上需求组，如SR-DB-F-G1。无论如何，应保证需求编号在项目中的唯一性。
在编写本章时，还应注意以下问题：
a) 如果项目被要求编写数据字典，则应在项目的早期（如项目论证阶段）就编写数据字典，以定义相关的数据元素和结构（如输入、输出、存储或数据表字段等，一般与功能、内外部接口等相关）的含义、类型、数据大小、格式、度量单位、精度以及允许取值范围。需求描述中的输入项可以直接引用数据字典的数据项。数据字典应独立维护。
b) 无论是需求编号还是需求内部描述的步骤号，都应手工编号，而不要使用编辑器的自动编号。因为如果采用自动编号，一旦增加或删除中间的某个编号，将会引起其后所有需求的RP记录的变更，并影响处理过程中的引用关系。
c) 需求优先级的设置应基于上游文档中相关内容的优先级，一般应不比上游的低。
d) 本文档中不得描述需求的实现版本信息。需求实现的版本信息应体现在两个地方：一是项目计划中；二是需求追踪工具RP中的需求属性：实现版本。

在阅读以下内容时，如果结合《软件需求说明书评审检查单》，将能取得更加好的效果。
好的单条需求的描述应具有以下特征。摘自《软件需求》第1.5节，Karl E. Wiegers
a) 完整性。每一项需求都必须将所要实现的功能描述清楚，以使设计与开发人员获得设计和实现这些功能所需的所有必要信息。
b) 正确性。每一项需求都必须准确地陈述其要开发的功能，判断依据为用户或系统需求说明。
c) 可行性。每一项需求都必须是在已知系统和环境的能力（capability）和限制范围内可以实施的。为避免不可行的需求，最好在获取(elicitation)需求过程中始终有一位设计/开发人员与需求分析人员/市场人员在一起工作，由他负责检查技术可行性。
d) 必要性。每一项需求都应能追踪到某项客户的输入，如use case或别的来源。这就要求我们将客户真正所需要的和最终系统所需遵从的标准记录下来以便追踪。
e) 划分优先级。给每项需求、特性或use case分配一个实施优先级以指明它在特定产品中所占的分量。如果把所有的需求都看作同样重要，那么项目管理者在需要调整项目范围时就无法进行取舍。
f) 无二义性。对所有需求说明的读者都只能有一个明确统一的解释，由于自然语言极易导致二义性，所以尽量把每项需求用简洁明了的用户性的语言表达出来。避免二义性的有效方法包括对需求文档的同行评审、编写测试用例、开发原型以及设计特定的方案脚本等。
g) 可验证性。检查一下每项需求是否能通过设计测试用例或其它的验证方法，如用演示、检测等来确定产品是否确实按需求实现了。如果需求不可验证，则确定其实施是否正确就成为主观臆断，而非客观分析了。一份前后矛盾、不可行或有二义性的需求也是不可验证的。

好的需求说明书的描述应具有以下特征。
a) 完整性。不能遗漏任何必要的需求信息。遗漏需求将很难查出。注重用户的任务而不是系统的功能将有助于提高完整性。如果知道缺少某项信息，用TBD (“待确定”)作为标准标识来标明这项缺漏。在通过评审前，必须解决需求中所有的TBD项。
b) 一致性。一致性是指与其它软件需求或高层（系统，业务）需求不相矛盾。在评审通过前必须解决所有需求间的不一致部分。
c) 可修改性。在必要时或为维护每一需求变更历史记录时，应该修订SRS。这就要求每项需求要独立标出，并与别的需求区别开来；每项需求只应在SRS中出现一次，这样更改时易于保持一致性。
d) 可追踪性。应能在每项软件需求与它的根源和设计元素、源代码、测试用例之间建立起追踪关系，这种可追踪性要求每项需求以一种结构化的，粒度好（fine-grained）的方式编写并单独标明，而不是大段大段的叙述。

编写SRS时牢记：
a) 保持语句和段落的简短。
b) 避免将多个需求集中在一个冗长的叙述段落中。
c) 避免出现需求冗余。
d) 采用主动语态的表达方式。
e) 使用正确的语法、拼写、标点。
f) 保持术语的一致性，并尽可能编制术语表及数据字典。
g) 条件语句描述应完整。如果只出现了“如果”，而没有“否则”，则应仔细考虑“如果”没有发生（即出现了“否则”分支）会怎样。
h) 多从设计与开发人员的角度衡量需求是否已被有效定义。如果设计与开发人员需要SRS的作者额外的解释才能理解需求，并进而进行设计和实现，则在继续工作前，需求还需要进一步细化。
i) 如果验证某需求需要很多测试用例且测试用例很分散，则可认为需求的粒度太粗，应继续细化。
j) 必须以相同的详细程度描述每个需求。如，“组合键Control-S代表保存文件”与“组合键Control-P代表打印文件”的描述粒度是相同的，而“产品必须响应以语音方式输入的编辑指令”则相对太粗了。
k) 鼓励使用确定性词语，如：总是、每一种、所有、没有、从不、应、必须等。
l) 特别关注或避免使用如下词语。
1) 当然、因此、明显、显然、必然。这些词语意图诱使接受假定情况，当看到这些词语时，审查员应仔细审查推断或假定是否成立。
2) 某些、有时、常常、通常、贯常、经常、大多、几乎、用户友好、容易、简单、许多、最新技术、可接受的、健壮的。这些词语太过模糊，所描述的功能无法测试。
3) 等等、诸如此类、依此类推。以这样的词结束的功能清单无法测试。功能清单要绝对或者解释明确，以免让人迷惑，不知如何推论。
4) 良好、迅速、廉价、高效、小、稳定。这些是不确定的说法，不可测试。如果在文中出现，就必须进一步指明含义。
5) 已处理、已拒绝、已忽略、已消除。这些说法可能隐藏大量需要说明的功能。

几个需求说明的例子。
例1 “产品必须在固定的时间间隔内提供状态消息，并且每次时间间隔不得小于60秒”。
分析：这个需求是不完整的：什么是状态消息，并且在什么情况下向用户提供这些消息？显示时间多长？我们所说的是产品的哪一部分？时间间隔也会导致混淆。假定显示状态消息之间的时间间隔只要求不少于60秒，按这样推理，是否可以每隔一年显示一次状态信息？如果意图是消息之间的时间间隔不多于60秒，那么1毫秒会不会太短？消息显示的时间间隔怎样才能一致？“每次”这个词混淆了这一问题。由于这些问题的存在，导致了需求是不可验证的。
改进：假设本例是描述后台任务管理器（BTM）应该在用户界面的指定区域显示状态消息。
a) 在后台任务启动之后，消息必须每隔60（±10）秒更新一次，并且保持连续的可见性。
b) 如果正在正常处理后台任务，那么后台任务管理器（BTM）必须显示后台任务进程已完成的百分比。
c) 当完成后台任务时，后台任务管理器（BTM）必须显示一个“已完成”的消息。
d) 如果后台任务中止执行，那么后台任务管理器（BTM）必须显示一个出错消息。
将原先的需求分割成多个需求，因为每个需求都需要独立的测试用例并且使各个需求都具有可跟踪性。如果把多个需求都集中在一个段落中，那么在构造软件和测试时就很容易忽略其中某个需求。注意，修改之后的需求并没有精确地说明是怎样显示状态信息的。这是一个设计问题。

例2 “产品必须在显示和隐藏非打印字符之间进行瞬间切换”。
分析：该需求是不完整的，因为它没有说清状态切换的原因。在特定的条件下，软件产品是否可以进行自动切换或者可否由用户采取某些措施来激发这样转变？还有，在文档中显示转变的范围是什么？是所选的文本、整个文档或其它内容？这个需求也存在一个不确定性问题。“非打印”字符是否指隐藏文本、属性标记或者其它的控制字符？由于存在这些问题，该需求是不可验证的。
改进： “用户在编辑文档时，通过激活特定的触发机制，可以在显示和隐藏所有HTML标记之间进行切换”。（假设用户对触发机制并不关心）
现在，指代关系就清楚了，非打印字符指的是HTML标记。修改过的需求指明了是用户触发了显示状态的转换，但是它并没有对设计造成限制，因为它并没有精确定义所使用的机制。当设计人员选择好一种触发机制（例如热键、菜单命令或语音输入）时，就可以编写详细的测试用例来验证这种转换操作是否正确。

例3 “分析程序应该能生成HTML标记出错的报告，这样就可以使HTML的初学者使用它来迅速排错。”
分析：“迅速”这个词具有模糊性。缺乏对出错报告内容的定义表明该需求也是不完整的。还有一点不清楚的是：HTML初学者使用的是分析程序还是出错报告。并且何时生成这样的报告？
改进：
a) 在HTML分析程序完全分析完一个文件后，该分析程序必须生成一个出错报告，这个报告中包含了在分析文件过程中所发现错误的HTML所在的行号以及文本内容，还包含了对每个错误的描述。
b) 如果在分析过程中未发现任何错误，就不必生成出错报告。（描述了例外情况的处理）

例4 “如果可能的话，应当根据主货物编号列表在线确认所输入的货物编号。”
分析：“如果可能的话”这句话意味着什么？该需求是否在技术上可行？是否可以在线访问主货物编号列表？如果不能确信是否可以递交一个请求，那么就使用“TBD”（待确定）来表示未解决的问题。这个需求是不完整的，因为它并没有指明如果确认通过或失败，将会发生什么情况。
改进：“系统必须根据在线的主货物编号列表确认所输入的货物编号。如果在主列表中查不到该货物的编号，系统必须显示一个出错消息并且拒绝订货。”

例5 “产品不应该提供将带来灾难性后果的查询和替换选择。”
分析：“灾难性后果”存在二义性。本条需求关注的焦点实际上可能是多级撤销(undo)能力。
改进：“产品在编辑时应提供多级（可由用户配置，最大99级）撤销（undo）能力”

例6 “‘基站启动流程’中对和超级终端串口的通信进行检测，如果通信正常，则进行2）的处理。”
分析：该需求不完整。典型的只说一个分支的错误：只说了if，丢了else。
改进：“‘基站启动流程’中对和超级终端串口的通信进行检测，如果通信不正常，则转步骤10）；否则转到步骤2）。”

例7 “参见PPT相关设计文档，XXXX软件基本上是移植，改动主要涉及U口数量增多、相关进程增加等方面。”
分析：引用应明确写出引用的文档名称、章节号、开始页号及行号、结束页号及行号，方便读者准确、快速定位目标内容。同时应明确给出移植前后的差异，设计时才可根据差异进行设计，否则就要在设计时找出哪些差异（需求）然后再设计。

例8 “在RCR STD-28协议中对输入有明确的规定。”
分析：引用协议应明确写出协议的章节号、开始页号及行号、结束页号及行号。
>
4.1 功能需求
<功能需求表示了软件的行为，或期望软件能够完成的工作。这些需求通常是面向动作的，需要重点描述输入、输出与执行的过程。需要强调的是：
a) 外部接口相关的功能应在此处描述（而不是在“4.4 外部接口需求”中描述）。
b) 应确认是否有某些容易被忽略的功能，如环境监控相关的（如温度、湿度、烟雾等）、透明传输相关的功能。
应逐一描述每一个具体的功能需求，包括需求编号、需求名称、需求描述、优先级、使用频度等。输入、输出和处理等可以使用use case、IPO（输入/处理/输出）、规范化的模型或其它适当的方式进行描述。规范化的模型，包括实体-关系图、状态转换图、数据流图、对话图等。本模板建议优先使用use case场景描述方法，在特殊情况下才可使用IPO等其它方法（如，对于平台类API需求，如果处理流程是顺序的，则使用IPO方法比较有效）。
由于不同的功能需求可能有不同的性能、质量属性等需求，为了避免冗余，在描述功能需求时可在“特殊需求”一栏中同时描述对应的