系统功能需求说明书模板

产品名称密级

机密

产品版本

共12页

XX系统YY功能需求说明书

目录

1简介.....................................................................4

1.1背景.....................................................................4

1.2假设和约束...............................4

1.3待确定问题................................4

2需求概述.................................................................4

2.1需求之间的依赖和联系（可选）.............4

2.2应用场景..................................4

2.3概要层用例（可选）........................4

2.3.1XX功能需求（含编写建议的模板、用例格式：动词+名词）...........................5

2.3.2XX功能需求（含编写建议的模板、非用例格式）...................................10

2.3.3XX功能需求（无编写建议的模板、用例格式：动词+名词）..........................II

23.4XX功能需求（无编写建议的模板、非用例格式）...................................11

3用户目标层用例.........................................................11

3.1XX功能需求（无编写建议的模板、用例格式：动词+名词）....................11

3.2XX功能需求（无编写建议的模板、非用例格式）........................12

4子功能层用例（可选）...................................................12

4.1XX功能需求（无编写建议的模板、用例格式：动词+名词）..............12

4.2XX功能需求（无编写建议的模板、非用例格式）..............................12

5非功能需求.............................................................12

6备注和附录.............................................................12

表目录

表I样表：用户角色定义错误!未定义书签。

图目录

错误！未找到图形项目表。

第2页，共12页

关键词:

摘要:

缩略语清单:

缩略语英文全名中文解释

第3页，共12页

2.用户目标层:完成了主执行者某个特定的价值目标,通常由一个主执行者在一个位置,

较短时间段内进行。特别说明,用例中的主执行者不仅仅包括人,也包括与系统交互的任何东

西。

3.子功能层:完成了用户目标层的部分细节。

写作概要层用例的目的是将多个相关用户目标层的用例组织起来,提供裔层的理解。写作子功

能层用例的目的是为了隘藏细节,在用户目标层的用例中突出主体。用户目标层的用例是功能需求

文档的主体。在用户目标层的用例已经表达的足够清楚的情况下,不需要写作概要层或子功能层的

用例。写作概要层用例和子女能层用例的目的是支撑用户目标层用例。

每一个用户目标层用例都必须是一个功能需求。概要层用例和子功能层用例可以不作为功能需

求,在文档中只是为了更好的理解功能需求而存在。当然,将概要层用例和子功能层用例作为功能

需求也是允许的,特别是概要层用例描述了多个用户目标层用例的关系,对系统测试非常有用。

在每一个用例中,不应该将不同层次的目标混合描述,根据本功能需求的名称确认此用例的层

次，在描述用例具体的执行步骤时,必须保持在此层次中写作,而不应该描述更低层次的细节。

概要、用户目标、子功能三个层次的用例的写作格式是一样的。即使使用非用例格式写作功能

需求,这些功能需求同样可以被划分为概要、用户目标、子功能三个层次。

2.3.1XX功能需求（含编写建议的模板、用例格式：动词+名词）

本章节的主成功场景和第一层扩展场景默认使用“UseCase1”样式，第二层扩展场景默认使用

“UseCase2”样式,其它文字描述默认使用“正文缩进”样式，请尽量使用已有样式,不要自定义样

式。

本文不要求写作需求的编号、优先级、需求类型、来源、实现的版本号,这些内容在需求管理

工具中描述。

本章节描述单个功能需求。本章节的格式是按照用例的格式编排的.

功能需求的名称就是用例的名字,同时也是用例的目标.为每个用例定义一个好名字非常重要,

如果找不到合适的名字,则意味者此用例的目标不清晰。

使用动词+名词的方式命名每一个用例,这个动名词的出语必须能够清晰的表达出此用例的主

执行者的H标。完整并且清瞄的目标的特征如下:

1.它明显和一个主执行者密切相关,而且只和一个主执行者密切相关。

2.它对主执行者和其它相关人员是有价值的。

3.它与你当前正在写作的目标层次一致。如果不一致,则需要重新思芍这个用例,或将它

移动到合适的层次中。

如果某个用例确实存在多个目标,则应该考虑将它抽象成一个概要层的用例,在概要层次上,

此用例仅仅有一个目标;然后将概要层用例分解为多个用户目标层用例,每个用户目标层的用例必

须有一个而且只能有一个清晰的目标。

用例的这一个目标必须是主执行者的目标。执行者是与系统具有任何行为的事物。执行者可能

是一个人,一个公司或组织、一个程序或计算机系统、一个其他功能或本功能自身。主执行者是通

过用例达到了目标的执行考。

第5页，共12页

主执行者是通过用例、用例中的某个场景、场景中的某个动作达到了目标的执行者。

特别的,待开发系统和它的子系统也可以作为用例的一个执行者,但不能作为主执行者。只有

外部的执行者才能作为主执行者并通过用例实现自身的目标。例如“记录日志”用例,在此用例隐

含的主语是“系统”，但不能据此认为此用例完成了“系统”的目标。虽然没有出现“管理员”这

几个字,但此动作确实完成了“管理员”这个主执行者的目标。即在用例中,系统可以有动作,但

不能有目标,所有的目标必须是外部主执行者的。即用例只能100%从系统外部的角度考虑,描述

系统或系统内部行为的目的只能是为了实现某个外部主执行者的目标。

与用例的目标类似,用做中的每个场景、场景中的每个动作都必须具有目标,而且必须是某个

外部主执行者的目标。凡是没有外部主执行者认领的场景或动作,都不应该在用例中出现。不过,

我们必须为每个用例的H标命名,即为每个功能需求取名,但没有必要为用例中的每个场景、场景

中的每个动作命名。

用例的写作不追求尽善尽美,即使存在一定的模糊性,只要能够让大多数人理解并能够进行后

续工作即可结束。

具体而言,用例必须全部达到卜.面的3个判定标准:

1.所有的主执行者和目标都已经被识别并写出:

2.客户或其代表认为没有遗漏用例,并且每个用例都是正确并且可读的;

3.设计人员认为能够实现这些用例。

1.简要说明

在不需要“简要说明”的情况下，本章节应该被删除。

本章节描述此用例的背景、主执行者、范围（与主执行者对应的系统是什么）、利益相关人的

利益、假设和约束、以及任何需要说明的内容。

2.Actor

本章节描述此用例涉及的Actor（执行者）。

3.前置条件：

在没有“前置条件”的情况下,应该写“前置条件:无“。

用例的前置条件声明了启动该用例之前系统必须满足的条件。在此用例的执行过程中,前提条

件不能改变,系统也不检测前提条件。

一个帝见的例子是“用户已经通过了身份验证”。通常,前置条件是其他用例的执行结果,“用

户已经通过了身份验证”这个前提条件是“验证用户身份”用例执行成功后的结果。“验证用户身

份”用例在大多数产品中是子功能用例,但在少数产品中也可能是用户目标层用例。

4.最小保证：

在没有“最小保证”的情况下,应该写“最小保证:无”。

最小保证是系统向项目相关人员作出的最低承诺,尤其是在主执行者的目标不能被满足的情况

下。当然,在目标被满足的情况下它们同样必须成立。例如系统数据不能丢失,业务不能中断等。

第6页，共12页

最常见的最小保证是“系统将其执行进度写入日志”。在没有明确最小保证的情况下，记录成

功或失败的事务处理日志很容易被遗漏。

不必在最小保证中列举出用例的所有失败情况。失败的情况多种多样,而且千差万别,每一个

失败条件和处理方案都会在用例的某个扩展场景中进行描述。此处需要描述的是所有场景都必须做

到的系统承诺,而不是某几个场景所做的事情。例如“写磁盘失败的情况下提示用户”就不是一个

合适的最小保证。

无论用例如何被执行,最小保证最终都应为真。它表明每一个项目相关人员的利益都得到了满

足。

5.成功保证：

在没有“成功保证”的情况下,应该写“成功保证：无”。

在UML标准中,将“成功保证”命名为“后置条件”，“成功保证”和“后置条件”的含义

完全相同。

成功保证说明了用例成功结束后项目相关人员的哪些利益得到了满足,用例可以通过执行主成

功场景达到成功保证,也可以通过执行可选路径获得成功保讦c

成功保证至少要包含本功能需求标题（动词+名词）中声明的目标。

下而是成功保证的几个例子:

成功保证:申请人按照商定的金额得到赔偿,申请被关闭,解决方案被记入日忐。

成功保证：文件被保存。

成功保证:系统为客户创建一个订单,收到付款信息,并将订单请求记入日志。

找出成功保证的最好方法是问这样一个问题,“在用例成功结束时,什么事会使项目相关人员

感到不岛兴呢?”这个问题通常很容易回答,然后写出答案的反面回答。

6.触发事件：

在项R组约定将“触发事件”写作为用例主成功场景第一步的情况下,此章节可以被删除。

用例的“触发事件”不能为“空”，也不能为“无”。

触发事件是启动用例的事件,紧接着就发生用例的第一步。

触发事件必须能够被系统检测到,“客户决定使用系统”不是一个恰当的触发事件。

7.主成功场景

本章节的内容不能为“空”。

在UML标准中,将“主成功场景”命名为"基本事件流”，“主成功场景”和“基本事件流”

的含义完全相同。

一系列的成功动作最终实现了主执行者的目标,并保护了项目相关人员的利益,它们构成了用

例的主成功场景。主成功场景应该简短明了,它指明了系统提供的服务。

第7页，共12页

主成功场景能够完成此用例的目标，并且故事直线发展。主成功场景不一定是达到用例目标的

最短路径,但它必须是最常发生或用户最喜欢发生的路径。其他的成功场景和所有错误的处理,都

在下一章节的扩展场景中进行描述。

用例中的每个场景、场景中的每个动作都必须具有外部主执行者的目标。主成功场景的目标是

实现主执行者的意图（并且与用例目标相同），扩展场景的H标是在异常情况下实现主执行者的某

个意图（其他的成功路径）,或者在不能实现主执行者意图的情况下,保证系统其他相关人员的利

益（失败路径）。

主成功场景使用带编号的步骤进行描述。场景中每一个步骤的粒度相近,而且每一步的目标层

次稍低于整个场景的目标层次。

对其中的每一个步骤,在任何情况下,都不能省略句子的主语,不能使用被动语态。建议不使

用更杂的句子结构。

.1.步骤1。

.2.步骤2。

.3......

.4.步骤N。

.5.主成功场景的最后一个步骤。此步骤完成后，必须达到了主执行者的目标。

场景的一次交互包含下面的4个部分:

1.主执行者向系统发送请求和数据。

2.系统验证收到的请求和数据。

3.系统更改内部状态。

4.系统向执行者返回结果。

作者可以把上面的每个部分写成一个单独的执行步骤,也可以用不同的方式合并其中的几个部

分,或者将4个部分合并成一个执行步骤。

合并的原则取决于每个部分的复杂程度和执行过程中在什么地方会发生扩展场景来决定,不存

在对所有用例通用的写作方式。

使用下面的2种方式之一表达重复的步骤:

1.在单个步骤中直接表达,例如:“主执行者执行XX动作,直到满足出条件叶停止”。

或“此步骤操作可能会重复多次”

2.在重复的步骤前面表达,例如:“步骤3—5可以重复执行”这句话放在步骤2之后,

步骤3之前,没有编号。

8.扩展场景

通常,本章节需要描述多个扩展场景。

在UML标准中,将“扩展场景”命名为“备选事件流,：“扩展场景”和“备选事件流”的

含义完全相同。

第8页，共12页

本章节的内容不能为“空”。在确实没有扩展场景的情况下，说明此功能需求十分简单,不需

要使用用例的格式进行描述，直接使用一段话描述此功能需求即可。

在主成功场景下，对于因为特别条件而出现行为分支的每个地方,写出分支的条件以及处理分

支的步骤,这就是扩展。每一个扩展场景最后必须能够回到主成功场景中,或者由于失败直接结束。

扩展由一系列的扩展场景组成。每一个扩展场景都开始于一个与它相关的前提条件，然后是一

个步骤的序列,该序列描述了在这个条件下发生了什么;每个场景以完成或放弃本场景的目标作为

结束。

由于每个扩展场景实质上是一个从主用例中拆分出来的小型用例,所以每个扩展场景也拥有自

己的目标、目标级别、前提条件、主干（完成了扩展目标的主成功场景）和分支（完成了扩展目标

的其他路径或保证其他相关人利益的其他失败路径），并同按照用例的写作方式进行写作。

任何一个扩展场景,都只能并且必须以下面的4种方式之一结束:

L修改或替换主成功场景的当前步骤，然后重新开始主成功场景的当前步骤、或者执行主

成功场景的下一步。在这种情况下,不需要说明扩展场景执行后怎么办。

2.系统给执行者其它的选择,执行完毕后回到主成功场景的某个步骤.在这种情况下,扩

展场景的最后一个步骤必须是“转到步骤N”.

3.与主成功场景不同的成功路径。在这种情况下,扩展场景的最后一个步骤必须是“用例

结束”。

4.没有达到主执行者目标的异常结束。在这种情况下,扩展场景的最后一个步骤必须是“用

例结束”,

每个扩展场景开始于一个编号和前提条件。此编号由3部分组成:

阿拉伯数字：表示此前提条件出现在主成功场景的第N个步骤。此处不能使用自动编号,

建议由作者手工编号。

英文字母:表示在主成功场景的第N个步骤中,出现了多个扩展场景,这些扩展场景按照

到“z”的顺序编号。同一个步骤下出现的扩展场景不多,建议由作者手工编号。

（点）：分隔此编号和前提条件。

例如:“la.”表示主成功场景的步骤1发生的第/个扩展场景,“1b.”表示主成功场景的步

骤1发生的第2个扩展场景,以此类推。

特别的,有些扩展场景可能发生在任意一个步骤中,例如W表示此扩展场景发生在主成功

场景的任意一个步躲中。有些扩展场景可能发生在多个步骤中,例州“2-5a.”表示此扩展场景发生

在主成功场景的步骤2-5中。

针对豆杂的扩展场景,可能需要进一步写作此扩展场景下面的扩展场景,这种情况下,建议在

此扩展场景出现分支处理的步骤中,直接写作下层扩展场景。例如,编号“lb2a.”表示在扩展场景

“小”的步骤2中发生的第「个更下层扩展场景,此扩展场景应写作在“1b.”的步骤2下面。比

“lb2a.”更下层的扩展场景,建议不编号宜接写作（使用缩进），或者独立为1个单独的子功能用

例。

第9页，共12页

用一个描述系统检测到了什么的短语或句子描述扩展场景的前提条件,并且在扩展场景的前提

条件后面加一个冒号（:主用单元或备用单元发生故障、链路故障或切换、对端设备拒绝或拆线、

用户中途取消操作、被叫忙、配置数据不完整、低压或掉电等都是扩展场景常见的前提条件。

在扩展场景可以通过一句话或者一段话说清楚的情况下,将步骤与分支条件写在一行,例如:

2a.系统检测到XX条件：系统提示失败，退出YY操作，执行ZZ操作......用例结束。

在扩展场景必须通过多段话才能说清楚的情况下,将分支条件写成独立的一行,例如:

2a.系统检测到XX条件：

.1.系统提示用户，要求输入新的XX参数。

.2.用户输入XX参数。

包含更下层扩展场景的例子:

2a.系统检测到XX条件：

.1.系统提示用户，要求输入新的XX参数。

.2.用户输入XX参数。

2a2a:系统检测到XX」条件：

..1.系统提示用户，要求先执行XX操作后才能输入此参数

••2・♦・・・♦・

..3.用例结束

.3.转到步骤6。

在多个扩展场景中，如果处理行为一致,则应该合并这些场景。例如:

2b.系统检测到YY条件或检测到ZZ条件；系统提示失败，……，用例结束。

9,非功能需求

在没有“非功能需求”的情况下,本章节应该被删除。

本章节描述此功能需求附加的非功能需求,例如各个操作导致的业务中断时间、T.作的环境温

度、设备在各种配置下的启动时间、单板/模块最长启动时间、流量、带宽、转发能力、传输速率、

包缓存等。

10.数据字典和附加描述

在没有“数据字典和附加描述”的情况下,本章节应该被删除。

数据字典是所有与系统相关的数据元素的有组织的列表、以及精确的严格定义,目的是达成用

户和系统设计人员共同的理解。数据字典使用“数据：”+“详细解释”的格式进行描述,其中的

“数据”应该已经出现在用例中,可以是名词、动作、或者一个短语。

附加描述是需要解释或者备注说明的任何内容。有可能附加描述中的内容在其他用例中有详细

的执行步骤,但在本用例中并不关心这些细节,说明参加XX章节即可。

2.3.2XX功能需求（含编写建议的模板、非用例格式）

第10页，共12页

有些功能需求不合适以用例的方式描述,建议作者以下面的模板写作,或者自定义模板。

1.说明

本章节描述系统在各种正常场景和异常场景中的处理情况。需求应该简明,完整,不含糊,可

验证，必要的。当信息不确定的时候使用“待定”。

2.非功能需求

本章节描述此功能需求附加的非功能需求,例如各个操作导致的业务中断时间、工作的环境温

度、设备在各种配置下的启动时间、单板/模块最长启动时间、流量、带宽、转发能力、传输速率、

包缓存等。

2.3.3XX功能需求（无编写建议的模板、用例格式：动词+名词）

1.简要说明

2.Actor

3.前置条件：

4.最小保证：

5.成功保证：

6.触发事件：

7.主成功场景

8.