需求用例编写规范.docx

资源描述

需求用例编写规范.docx

《需求用例编写规范.docx》由会员分享，可在线阅读，更多相关《需求用例编写规范.docx（22页珍藏版）》请在冰豆网上搜索。

需求用例编写规范.docx

需求用例编写规范

需求用例编写规范-V1.0

文档编号：

文档名称：

需求用例编写规范

文档类别：

设计规范

密级：

机密

版本信息：

1.0

建立日期：

2005-08-26

创建人：

016

审核者：

批准人：

批准日期：

编辑软件：

MicrosoftOffice2003中文版

文档修订记录

版本编号

*变化

状态

简要说明

（变更内容和变更范围）

日期

变更人

批准日期

批准人

更改请求号

V1.0

参考《编写有效用例》

2005-08-26

016

*变化状态：

C——创建,M——修改，D——删除

文档审批信息

序号

审批人

角色

审批日期

签字

备注

1简介1

1.1文档目的1

1.2有效范围1

2梗概1

2.1用例定义1

2.2用例格式2

2.2.1非正式用例2

2.2.2正式用例3

3非正式用例3

3.1用例名3

3.2自然语言描述体4

3.3图例说明4

4正式用例4

4.1范围4

4.2级别4

4.3主执行者4

4.4项目相关人员和利益4

4.5前置条件4

4.6最小保证5

4.7成功保证5

4.8触发事件5

4.9主成功场景5

4.10扩展场景5

4.11相关信息6

4.11.1解释说明6

4.11.2约束条件7

4.11.3改进建议7

5编号7

6批注7

7超链接8

8字体及颜色8

9如何快速书写需要用例8

9.1非正式用例8

9.2正式用例9

10范例10

1简介

1.1文档目的

本文档中的内容是为了更好的书写与理解需求用例，阅读本文后，达到读者能够书写规范有效的需求用例。

如果读者需要立即书写需求用例，则可以直接阅读第9节“如何快速书写需求用例”。

本文参考AlistairCockburn编著，王雷、张莉翻译由机械工业出版社出版的《编写有效用例（WritingEffectiveUseCases）》一书，有兴趣的读者可以详细阅读此书。

1.2有效范围

本文适用于各种软件开发项目的需求分析。

2梗概

2.1用例定义

用例是代表系统中各个项目相关人员之间就系统的行为所达成的契约，用例描述了在不同条件下，系统对某一项目相关人员的请求所作出的响应。

如果用用例来记录一个组织的业务过程，那么被讨论的系统是指组织本身，项目相关人员是指公司的股东、客户、供应商和政府管理部门，这种用例称为业务用例，业务用例可以作为软件需求采集时使用；如果用用例来记录一个软件的行为需求，那么被讨论的系统是指计算机程序，项目相关人员是指使用该程序的人、拥有该程序的公司、政府管理部门和其他一些计算机程序，这种用例称为系统用例，系统用例可以作为软件需求分析时使用。

用例不是所有的需求，用例不能详细地描述外部接口、数据格式、业务规则和复杂公式，用例只是需要收集的所有需求中的一部分，虽然这一部分是非常重要的一部分，但毕竟仅仅是“一部分”，不能全部反映“需求”。

2.2用例格式

需求用例分为正式用例与非正式用例，非正式用例是用自然语言及图例进行用例描述，正式用例是具有规范格式的用例描述。

读者在此不必深究用例如何书写，后续章节中有详细说明。

2.2.1非正式用例

用例名

自然语言描述体

图例说明

2.2.2

用例名

自然语言描述体

图例说明

范围：

级别：

主执行者：

项目相关人员和利益：

前置条件：

最小保证：

成功保证：

触发事件：

主成功场景：

1.成功动作描述

2.成功动作描述

扩展：

1.a.场景执行过程中非顺利情况

1.a.1.处理动作描述

1.b.场景执行过程中非顺利情况

1.b.1.处理动作描述

相关信息：

✧解释说明

✧约束条件

✧改进建议

正式用例

3非正式用例

非正式用例包括三部分：

用例名、自然语言描述体、图例说明。

3.1用例名

用例名就是用例的名称，应是一个主动语态动词短语来表示的用例目标。

3.2自然语言描述体

用自然语言描述成功场景和可能会出现的失败场景，及其相应的处理动作，还包括用例所需要的功能操作等。

3.3图例说明

对于较复杂的需求用例，可以用图表说明用例之间关系，使用例更加清晰明朗。

4正式用例

正式用列具有格式规范，包括：

用例名、自然语言描述体、图例说明、范围、级别、主执行者、项目相关人员和利益、前置条件、最小保证、成功保证、触发事件、主成功场景、扩展场景和相关信息等项目，用例格式并不是硬性规定必须包括这此内容，只是为需求用例编写者提供正式用例编写格式参考，具体项目具体分析，以增减正式用例内容，更好地为需求分析服务；用例名、自然语言描述体、图例说明的编写方法同非正式用例，只是自然语言描述体只阐述不能在主成功场景和扩展场景中描述的部分，不必将场景全部说明。

4.1范围

范围（scope）用来描述项目开发人员负责的设计工作的边界，以便与应由其他人负责的设计工作或已经完成的设计工作相区别；范围应该是一个简单明确的名词，比如说需求人员正在对“固定资产”项目进行需求分析，则“范围”可以是“固定资产系统”。

4.2级别

级别分为三个目标层次：

概要、用户目标、子功能，书写需求用例时，只能选择其一，下面对其具体说明：

✧概要：

包括多个用户目标，它有“显示相关目标的生命周期顺序”和“为低层用例提供一个目录表”的功能，概要用例通常需要执行几个小时、几天、几个星期、几个月、甚至几年。

✧用户目标：

它是主执行者努力使工作得以完成的目标，或是用户使用系统的目标，通常情况下指系统为用户提供的界面操作。

✧子功能：

指那些在实现用户目标时可能会被用到的目标，一般是指系统内部执行，而用户看不到界面的用例。

4.3主执行者

用例的主执行者是指任何具有行为的事物，主执行者通常是触发用例的执行者，可能是一个人、一个公司或组织、一个计算机程序或一个计算机系统，主执行者应该是一个主语名词，如“账务主管”、“总账系统”等。

4.4项目相关人员和利益

项目相关人员是对行为具有特定利益的人或物，他们的利益在系统执行的检查和确认中、在创建的日志中、以及在系统执行的动作中得以体现；项目相关人员是一个名词，紧接的利益是简明扼要的短语。

4.5前置条件

前置条件是指启动该用例之前系统必须满足的条件，通常，前置条件是已经通过其他用例的执行进行了设置，前置条件必须是由“主－谓－宾”构成的短语，如“用户已经登录系统”、“系统已经存在会计科目”。

4.6最小保证

最小保证是系统向项目相关人员作出的最低承诺，如“系统将错误信息写入系统日志”，从这个例子可以看出，最小保证也是由“主－谓－宾”短语所构成的。

4.7成功保证

成功保证说明了用例成功结束后项目相关人员的哪些利益得到了满足，用例可以通过执行主场景获得成功，也可以通过执行扩展场景可选路径获得成功，其格式同最小保证“主－谓－宾”形式，例如“系统保存记账凭证”。

4.8触发事件

触发事件指明了启动用例的事件，一般是肯定性的短语，如“总账启用后必须执行此用例进行设置”。

4.9主成功场景

自顶向下进行描述，这个描述包含一个容易理解的相当典型的场景，在该场景中，主执行者完成了目标，所有项目相关人员的利益都被满足，这个场景就是主成功场景，其他的成功场景和所有错误的处理，都会在主成功场景的扩展中进行描述，主成功场景包括场景编号、场景动作描述两部门，场景编号是以数字为基础的顺序编号。

主成功场景的书写规则如下：

✧使用简单的语法：

“主－谓－宾”语法形式

✧明确地写出执行者

✧描述过程向前推移

✧描述执行者的意图而不是动作

✧“确认”而不是“检查是否”

✧重复动作描述“循环执行步骤x到y，直到条件满足”

例如：

网上购物的主成功场景

4.10扩展场景

扩展实质上是一个从主用例中被拆分的用例。

扩展开始于一个与它相关的条件。

它包含了一个执行步骤的序列，该序列描述了在这个条件下发生了什么。

扩展以完成或放弃扩展目标作为结束。

扩展是为了处理多个条件和转移，可能会遇到扩展中又包含扩展的情况。

扩展分为扩展条件和处理动作描述两部分，扩展条件是指对应的主成功场景出现的不同情况，应该是一条肯定的条件短语，不能出现“如果……那么……”这种形式的语句；处理动作描述是指对扩展条件的处理。

扩展同样需要进行编号，编号格式为［对应主成功场景编号］．［扩展条件编号］．［处理动作编号］，其中扩展条件编号以字母为序号，即a～z。

如果处理动作只有唯一动作，其格式可以是“［扩展条件］：

［处理动作］”，处理动作不唯一则必须换行编写。

需求用例是子用例，并且被多处引用，但由于引用子用例的用例之间可能有不需要的成功场景，即存在特性主成功场景，此时编写子用例时，对特性的主成功场景可以写入扩展场景中，并做出相应的解释说明。

扩展场景的书写规则如下：

✧使用简单的语法：

“主－谓－宾”语法形式

✧明确地写出执行者

✧描述过程根据主成功场景向前推移

✧描述执行者的意图而不是动作

✧“确认”而不是“检查是否”

✧重复动作描述“循环执行步骤x到y，直到条件满足”

✧用“检测到什么”的方式来编写条件

例如：

4.11相关信息

4.11.1解释说明

解释说明业务词语或定义等，便于业务人员和软件设计人员理解。

4.11.2约束条件

用例中的计算公式和约束限制等，有助于软件设计和程序设计人员进行软件设计。

4.11.3改进建议

升级新版本时，对旧版本的改进建议，如果不存在旧版本，则可不存在此项目。

5编号

用例之间需要进行编号，编号以多级符号形式，即“1.”“1.1.”“1.1.1.”，通常情况下，最顶级不进行编号，即“XXX系统”，而是对其下级开始多级编号，例如：

如果用例中包含图例，则需要对图例进行编号，编号格式为“图<顶级用例编号>-<图例在顶级用例的序号>”，如“图2-3xxxx图”，如果是最顶级用例，则以系统名称的开头汉字作为顶级用例编号，如总账系统的第一张图则表示为“图总-1xxxx图”。

6批注

必要时可以对公式、约束、名词、列表内容等项目编写注释说明，便于用例阅读者理解用例，对于必要约束，必须添加批注，例如：

主成功场景：

1.用户输入：

－会计科目编码

－方向

扩展：

1.a.系统验证会计科目编码长度与系统设置不相符

1.a.1.……

7超链接

必要时可以对相关用例、子用例、名词解释等插入超链接，其中子用例必须插入超链接，以明确说明子用例的出处，例如：

8字体及颜色

标题字号不能小于正文字号，并且以加粗显示，以明显示区分，如“用例名”、“主成功场景”等。

对于不同内容，如功能操作、新系统用例等使用不同颜色进行区分，通常情况下，功能操作前景色使用“■”颜色，新系统用例部分使用“■”颜色以示区别，还可以使用其它的颜色对不同并有警示意义的内容进行标识，可以适当地设置背景色，但无论使用什么样的颜色，都应对其说明。

9如何快速书写需要用例

用例分为正式用例和非正式用例，由于时间原因，用例编写者可能无法详细阅读本规范，所以提供了此章节，希望读者通过阅读本章节，能够达到快速编写需求用例的目的。

9.1非正式用例

9.2正式用例

说明：

1.概要：

包括多个用户目标，它有“显示相关目标的生命周期顺序”和“为低层用例提供一个目录表”的功能。

2.用户目标：

它是主执行者努力使工作得以完成的目标，或是用户使用系统的目标。

3.子功能：

指那些在实现用户目标时可能会被用到的目标。

4.批注：

必要时可以对公式、约束、名词、名词项目必须内容等编写注释说明。

5.超链接：

必要时可以对相关用例、子用例、名词解释等插入超链接。

6.字体及颜色：

对于不同内容，如功能操作、新系统用例等使用不同颜色进行区分。

7.图表：

对于较复杂的用例，可以用图例说明用例之间关系。

10范例

期初资产录入用例

系统建账后，固定资产会计必须进入固定资产系统，将建账月以前的资产卡片录入系统，实现手工账与计算机账的对接，使固定资产核算能够连续进行，并为固定资产的后续工作如工作量录入、折旧计提、折旧分摊等工作提供资产卡片基础数据。

固定资产会计在操作此功能前需要保证资产类别、计量单位、存放地点、折旧方法已经设置，因为资产卡片需要从上述用例中获取基础数据。

基本功能包括增加、修改、删除等操作。

（此处可作为非正式用例）

图1-3期初资产录入与用例关系

范围：

固定资产系统

级别：

用户目标

主执行者：

固定资产会计

项目相关人员和利益：

固定资产会计：

资产卡片计算机管理，快速查看资产。

系统：

获取固定资产计提折旧依据。

前置条件：

资产类别、计量单位、存放地点、折旧方法等基础信息已经设置。

最小保证：

系统运行失败，将失败信息写入日志。

成功保证：

系统保存固定资产卡片信息。

触发事件：

系统建账后，固定资产会计必须将企业已有的固定资产录入系统；以后各期不需要录入，现系统未控制，新系统应有控制点。

主成功场景：

1.固定资产会计增加操作，系统自动计算资产编号并显示，将所有数值型数据置为0，显示用户设置默认的残值率

2.固定资产会计输入：

—资产名称

—资产类别

—资产来源

—计量单位

—存放地点

—所属部门

—启用日期

—是否计提

—折旧方法

3.固定资产会计选择折旧方法为工作量法，预计工作量和已用工作量可用，而预计使用月数和已用月数不可用

4.固定资产会计输入预计使用月数或预计工作量，系统根据折旧方法计算

—月折旧率

—月折旧额

—已提折旧

—账面净值

5.固定资产会计输入已用月数或已用工作量，系统根据折旧方法计算

—月折旧率

—月折旧额

—已提折旧

—账面净值

6.固定资产会计输入资产总额，系统根据折旧方法计算

—残值

—月折旧额

—已提折旧

—账面净值

7.固定资产会计输入残值率，系统根据折旧方法计算

—残值

—月折旧额

—已提折旧

—账面净值

8.固定资产会计输入已提折旧，系统根据折旧方法计算

—账面净值

9.系统验证通过后，保存资产卡片信息

扩展：

2.a.系统验证启用日期大于等于当前操作日期

2.a.1.系统告知用户，并提示用户重新输入

2.a.2.用户重新输入，系统执行步骤2

2.a.3.用户放弃输入，系统置为浏览状态

5.a.系统验证已用月数大于预计使用月数

5.a.1.系统告知用户，并提示用户重新输入

5.a.2.用户重新输入，系统执行步骤2

5.a.3.用户放弃输入，系统置为浏览状态

8.a.系统验证已用工作量大于预计总工作量

8.a.1.系统告知用户，并提示用户重新输入

8.a.2.用户重新输入，系统执行步骤2

8.a.3.用户放弃输入，系统置为浏览状态

9.a.用户做修改操作，系统验证本月已经计提折旧

9.a.1.系统告知用户，并提示用户做资产变动操作

9.b.用户做删除操作，系统验证非本月增加

9.b.1.系统告知用户，并提示用户做资产处置操作