需求用例编写规范

需求用例编写规范-V1.0文档编号:文档名称:需求用例编写规范文档类别:设计规范密级:机密版本信息:1.0建立日期:2005-08-26创建人:016审核者:批准人:批准日期:编辑软件:Microsoft Office 2003 中文版 *变化状态: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用例定义用例是代表系统中各个项目相关人员之间就系统的行为所达成的契约,用例描述了在不同条件下,系统对某一项目相关人员的请求所作出的响应。如果用用例来记录一个组织的业务过程,那么被讨论的系统是指组织本身,项目相关人员是指公司的股东、客户、供应商和政府管理部门,这种用例称为业务用例,业务用例可以作为软件需求采集时使用;如果用用例来记录一个软件的行为需求,那么被讨论的系统是指计算机程序,项目相关人员是指使用该程序的人、拥有该程序的公司、政府管理部门和其他一些计算机程序,这种用例称为系统用例,系统用例可以作为软件需求分析时使用。用例不是所有的需求,用例不能详细地描述外部接口、数据格式、业务规则和复杂公式,用例只是需要收集的所有需求中的一部分,虽然这一部分是非常重要的一部分,但毕竟仅仅是“一部分”,不能全部反映“需求”。 第 1 页共16 页2.2用例格式需求用例分为正式用例与非正式用例,非正式用例是用自然语言及图例进行用例描述,正式用例是具有规范格式的用例描述。读者在此不必深究用例如何书写,后续章节中有详细说明。2.2.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 ,直到条件满足”例如:网上购物的主成功场景 4.10 扩展场景扩展实质上是一个从主用例中被拆分的用例。扩展开始于一个与它相关的条件。它包含了一个执行步骤的序列,该序列描述了在这个条件下发生了什么。扩展以完成或放弃扩展目标作为结束。扩展是为了处理多个条件和转移,可能会遇到扩展中又包含扩展的情况。扩展分为扩展条件和处理动作描述两部分,扩展条件是指对应的主成功场景出现的不同情况,应该是一条肯定的条件短语,不能出现“如果那么”这种形式的语句;处理动作描述是指对扩展条件的处理。扩展同样需要进行编号,编号格式为对应主成功场景编号.扩展条件编号.处理动作编号,其中扩展条件编号以字母为序号,即az。如果处理动作只有唯一动作,其格式可以是“扩展条件:处理动作”,处理动作不唯一则必须换行编写。需求用例是子用例,并且被多处引用,但由于引用子用例的用例之间可能有不需要的成功场景,即存在特性主成功场景,此时编写子用例时,对特性的主成功场景可以写入扩展场景中,并做出相应的解释说明。扩展场景的书写规则如下:使用简单的语法:“主-谓-宾”语法形式明确地写出执行者描述过程根据主成功场景向前推移描述执行者的意图而不是动作“确认”而不是“检查是否”重复动作描述“循环执行步骤x到y,直到条件满足”用“检测到什么”的方式来编写条件例如: 4.11相关信息4.11.1解释说明解释说明业务词语或定义等,便于业务人员和软件设计人员理解。4.11.2约束条件用例中的计算公式和约束限制等,有助于软件设计和程序设计人员进行软件设计。4.11.3改进建议升级新版本时,对旧版本的改进建议,如果不存在旧版本,则可不存在此项目。5编号用例之间需要进行编号,编号以多级符号形式,即“1.”“1.1.”“1.1.1.”,通常情况下,最顶级不进行编号,即“XXX系统”,而是对其下级开始多级编号,例如: 如果用例中包含图例,则需要对图例进行编号,编号格式为“图-”,如“图2-3 xxxx图”,如果是最顶级用例,则以系统名称的开头汉字作为顶级用例编号,如总账系统的第一张图则表示为“图总-1 xxxx图”。6批注必要时可以对公式、约束、名词、列表内容等项目编写注释说明,便于用例阅读者理解用例,对于必要约束,必须添加批注,例如: 7超链接必要时可以对相关用例、子用例、名词解释等插入超链接,其中子用例必须插入超链接,以明确说明子用例的出处,例如: 8字体及颜色标题字号不能小于正文字号,并且以加粗显示,以明显示区分,如“用例名”、“主成功场景”等。对于不同内容,如功能操作、新系统用例等使用不同颜色进行区分,通常情况下,功能操作前景色使用“”颜色,新系统用例部分使用“”颜色以示区别,还可以使用其它的颜色对不同并有警示意义的内容进行标识,可以适当地设置背景色,但无论使用什么样的颜色,都应对其说明。9如何快速书写需要用例用例分为正式用例和非正式用例,由于时间原因,用例编写者可能无法详细阅读本规范,所以提供了此章节,希望读者通过阅读本章节,能够达到快速编写需求用例的目的。9.1非正式用例 9.2正式用例 说明:1.概要:包括多个用户目标,它有“显示相关目标的生命周期顺序”和“为低层用例提供一个目录表”的功能。2.用户目标:它是主执行者努力使工作得以完成的目标,或是用户使用系统的目标。3.子功能:指那些在实现用户目标时可能会被用到的目标。4.批注:必要时可以对公式、约束、名词、名词项目必须内容等编写注释说明。5.超链接:必要时可以对相关用例、子用例、名词解释等插入超链接。6.字体及颜色:对于不同内容,如功能操作、新系统用例等使用不同颜色进行区分。7.图表:对于较复杂的用例,可以用图例说明用例之间关系。10范例 EBS 开发小组 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. 系统告知用户，并提示用户做资产处置操作 相关信息： 解释说明 资产来源是指企业获得资产的方式，包括： 购置