需求用例编写规范.doc

需求用例编写规范-V1.0文档编号：文档名称：需求用例编写规范文档类别：设计规范密 级：机密版本信息：1.0建立日期：2005-08-26创 建 人：016审 核 者：批 准 人：批准日期：编辑软件：Microsoft Office 2003 中文版文档修订记录版本编号*变化状态简要说明(变更内容和变更范围)日期变更人批准日期批准人更改请求号V1.0C参考《编写有效用例》2005-08-26016*变化状态：C——创建,M——修改，D——删除文档审批信息序号审批人角色审批日期签字备注目录1 简介 11.1 文档目的 11.2 有效范围 12 梗概 12.1 用例定义 12.2 用例格式 22.2.1 非正式用例 22.2.2 正式用例 33 非正式用例 33.1 用例名 33.2 自然语言描述体 43.3 图例说明 44 正式用例 44.1 范围 44.2 级别 44.3 主执行者 44.4 项目相关人员和利益 44.5 前置条件 44.6 最小保证 54.7 成功保证 54.8 触发事件 54.9 主成功场景 54.10 扩展场景 54.11 相关信息 64.11.1 解释说明 64.11.2 约束条件 74.11.3 改进建议 75 编号 76 批注 77 超链接 88 字体及颜色 89 如何快速书写需要用例 89.1 非正式用例 89.2 正式用例 910 范例 101 简介1.1 文档目的本文档中的内容是为了更好的书写与理解需求用例，阅读本文后，达到读者能够书写规范有效的需求用例。

如果读者需要立即书写需求用例，则可以直接阅读第9节“如何快速书写需求用例”本文参考Alistair Cockburn编著，王雷、张莉翻译由机械工业出版社出版的《编写有效用例（Writing Effective Use Cases）》一书，有兴趣的读者可以详细阅读此书1.2 有效范围本文适用于各种软件开发项目的需求分析2 梗概2.1 用例定义用例是代表系统中各个项目相关人员之间就系统的行为所达成的契约，用例描述了在不同条件下，系统对某一项目相关人员的请求所作出的响应如果用用例来记录一个组织的业务过程，那么被讨论的系统是指组织本身，项目相关人员是指公司的股东、客户、供应商和政府管理部门，这种用例称为业务用例，业务用例可以作为软件需求采集时使用；如果用用例来记录一个软件的行为需求，那么被讨论的系统是指计算机程序，项目相关人员是指使用该程序的人、拥有该程序的公司、政府管理部门和其他一些计算机程序，这种用例称为系统用例，系统用例可以作为软件需求分析时使用用例不是所有的需求，用例不能详细地描述外部接口、数据格式、业务规则和复杂公式，用例只是需要收集的所有需求中的一部分，虽然这一部分是非常重要的一部分，但毕竟仅仅是“一部分”，不能全部反映“需求”。

UI需求业务规则数据格式I/O协议性能需求······用例UI设计2.2 用例格式需求用例分为正式用例与非正式用例，非正式用例是用自然语言及图例进行用例描述，正式用例是具有规范格式的用例描述读者在此不必深究用例如何书写，后续章节中有详细说明2.2.1 非正式用例用例名 自然语言描述体 图例说明用例名自然语言描述体图例说明范 围：级 别：主执行者：项目相关人员和利益：前置条件：最小保证：成功保证：触发事件：主成功场景：1. 成功动作描述2. 成功动作描述扩展：1.a. 场景执行过程中非顺利情况1.a.1. 处理动作描述1.b. 场景执行过程中非顺利情况1.b.1. 处理动作描述相关信息：² 解释说明² 约束条件² 改进建议2.2.2 正式用例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，直到条件满足”例如：网上购物的主成功场景1. 顾客提供：－账号信息2. 系统查出顾客的爱好信息3. 顾客选择一个商品，并做上购买标记4. 系统将这个商品加入顾客的“购物车”中顾客重复步骤3～4，直到顾客指明他完成了选购5. 顾客确认购买购物车中所有商品6. ……4.10 扩展场景扩展实质上是一个从主用例中被拆分的用例扩展开始于一个与它相关的条件它包含了一个执行步骤的序列，该序列描述了在这个条件下发生了什么。

扩展以完成或放弃扩展目标作为结束扩展是为了处理多个条件和转移，可能会遇到扩展中又包含扩展的情况扩展分为扩展条件和处理动作描述两部分，扩展条件是指对应的主成功场景出现的不同情况，应该是一条肯定的条件短语，不能出现“如果……那么……”这种形式的语句；处理动作描述是指对扩展条件的处理扩展同样需要进行编号，编号格式为［对应主成功场景编号］．［扩展条件编号］．［处理动作编号］，其中扩展条件编号以字母为序号，即a～z如果处理动作只有唯一动作，其格式可以是“［扩展条件］：［处理动作］”，处理动作不唯一则必须换行编写需求用例是子用例，并且被多处引用，但由于引用子用例的用例之间可能有不需要的成功场景，即存在特性主成功场景，此时编写子用例时，对特性的主成功场景可以写入扩展场景中，并做出相应的解释说明扩展场景的书写规则如下：² 使用简单的语法：“主－谓－宾”语法形式² 明确地写出执行者² 描述过程根据主成功场景向前推移² 描述执行者的意图而不是动作² “确认”而不是“检查是否”² 重复动作描述“循环执行步骤x到y，直到条件满足”² 用“检测到什么”的方式来编写条件例如：主成功场景：1． 用户输入－会计科目编码－会计科目名称2． 系统验证通过后，保存会计科目扩展：1.a. 系统验证科目编号长度与系统设置长度不符1.a.1. 系统告知用户，并提示用户重新输入1.a.2. 用户重新输入，系统执行步骤11.a.3. 用户放弃输入，系统置为浏览状态1.b. 系统验证会计科目名称为空1.b.1. 系统告知用户，并提示用户重新输入1.b.2. 用户重新输入，系统执行步骤11.b.3. 用户放弃输入，系统置为浏览状态2.a. 系统验证数据库连接失败：退出系统4.11 相关信息4.11.1 解释说明解释说明业务词语或定义等，便于业务人员和软件设计人员理解。

4.11.2 约束条件用例中的计算公式和约束限制等，有助于软件设计和程序设计人员进行软件设计4.11.3 改进建议升级新版本时，对旧版本的改进建议，如果不存在旧版本，则可不存在此项目5 编号用例之间需要进行编号，编号以多级符号形式，即“1.”“1.1.”“1.1.1.”，通常情况下，最顶级不进行编号，即“XXX系统”，而是对其下级开始多级编号，例如：总账系统1 基础设置用例体……1.1 会计科目设置用例体……1.2 期初余额录入用例体……2 记账凭证用例体……2.1 记账凭证编。