需求用例编写规范.doc_第1页
需求用例编写规范.doc_第2页
需求用例编写规范.doc_第3页
需求用例编写规范.doc_第4页
需求用例编写规范.doc_第5页
已阅读5页,还剩12页未读 继续免费阅读

下载本文档

版权说明:本文档由用户提供并上传,收益归属内容提供方,若内容存在侵权,请进行举报或认领

文档简介

EBS开发小组需求用例编写规范-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. 系统将这个商品加入顾客的“购物车”中顾客重复步骤34,直到顾客指明他完成了选购5. 顾客确认购买购物车中所有商品6. 4.10 扩展场景扩展实质上是一个从主用例中被拆分的用例。扩展开始于一个与它相关的条件。它包含了一个执行步骤的序列,该序列描述了在这个条件下发生了什么。扩展以完成或放弃扩展目标作为结束。扩展是为了处理多个条件和转移,可能会遇到扩展中又包含扩展的情况。扩展分为扩展条件和处理动作描述两部分,扩展条件是指对应的主成功场景出现的不同情况,应该是一条肯定的条件短语,不能出现“如果那么”这种形式的语句;处理动作描述是指对扩展条件的处理。扩展同样需要进行编号,编号格式为对应主成功场景编号扩展条件编号处理动作编号,其中扩展条件编号以字母为序号,即az。如果处理动作只有唯一动作,其格式可以是“扩展条件:处理动作”,处理动作不唯一则必须换行编写。需求用例是子用例,并且被多处引用,但由于引用子用例的用例之间可能有不需要的成功场景,即存在特性主成功场景,此时编写子用例时,对特性的主成功场景可以写入扩展场景中,并做出相应的解释说明。扩展场景的书写规则如下: 使用简单的语法:“主谓宾”语法形式 明确地写出执行者 描述过程根据主成功场景向前推移 描述执行者的意图而不是动作 “确认”而不是“检查是否” 重复动作描述“循环执行步骤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 记账凭证编制如果用例中包含图例,则需要对图例进行编号,编号格式为“图-”,如“图2-3 xxxx图”,如果是最顶级用例,则以系统名称的开头汉字作为顶级用例编号,如总账系统的第一张图则表示为“图 总-1 xxxx图”。6 批注必要时可以对公式、约束、名词、列表内容等项目编写注释说明,便于用例阅读者理解用例,对于必要约束,必须添加批注,例如:主成功场景:1. 用户输入:会计科目编码方向方向包括:借方贷方扩展:1.a. 系统验证会计科目编码长度会计科目编号长度为4位。与系统设置不相符1.a.1. 7 超链接必要时可以对相关用例、子用例、名词解释等插入超链接,其中子用例必须插入超链接,以明确说明子用例的出处,例如:主成功场景:34用户根据固定资产折旧清单生成记账凭证58 字体及颜色标题字号不能小于正文字号,并且以加粗显示,以明显示区分,如“用例名”、“主成功场景”等。对于不同内容,如功能操作、新系统用例等使用不同颜色进行区分,通常情况下,功能操作前景色使用“”颜色,新系统用例部分使用“”颜色以示区别,还可以使用其它的颜色对不同并有警示意义的内容进行标识,可以适当地设置背景色,但无论使用什么样的颜色,都应对其说明。9 如何快速书写需要用例用例分为正式用例和非正式用例,由于时间原因,用例编写者可能无法详细阅读本规范,所以提供了此章节,希望读者通过阅读本章节,能够达到快速编写需求用例的目的。9.1 非正式用例用例名用例名应该是一个主动语态动词短语来表示的用例目标描述体用自然语言描述需求用例,反映出主成功场景和扩展场景动作情况及业务流程,还包括用例所需要的一些功能操作等9.2 正式用例用例名用例名应该是一个主动语态动词短语来表示的用例目标描述体用自然语言描述需求用例,反映出主成功场景和扩展场景动作情况及业务流程,不需要详细说明,只要将无法在主成功场景或扩展场景说明的动作在此描述,还包括用例所需要的一些功能操作等范 围:设计范围,在设计时将系统作为一个黑盒来考虑级 别:概要、用户目标、子功能三者之一主执行者:主执行者的角色名称或主执行者的描述项目相关人员和利益:用例中的项目相关人员和关键利益的列表相关人员:利益前置条件:我们所希望的,周围环境已经达到的状态最小保证:在所有退出操作前,如何保证得到必须的信息成功保证:目标完成时环境的状态触发事件:什么引发了用例,可能是时间事件主成功场景:在这时写出从触发事件到目标完成以及清除的步骤步骤编号数字动作描述扩展:在这里写出扩展,每次写一个扩展,每一个扩展都指向主成功场景中的特定步骤被改变步骤编号扩展步骤编号字母扩展场景发生条件描述被改变步骤编号扩展步骤编号编号数字动作或子用例相关信息:n 解释说明解释说明业务词语或定义等n 约束条件用例中的计算公式和约束限制等n 改进建议升级新版本时,对旧版本的改进建议说明:1. 概要:包括多个用户目标,它有“显示相关目标的生命周期顺序”和“为低层用例提供一个目录表”的功能。2. 用户目标:它是主执行者努力使工作得以完成的目标,或是用户使用系统的目标。3. 子功能:指那些在实现用户目标时可能会被用到的目标。4. 批注:必要时可以对公式、约束、名词、名词项目必须内容等编写注释说明。5. 超链接:必要时可以对相关用例、子用例、名词解释等插入超链接。6. 字体及颜色:对于不同内容,如功能操作、新系统用例等使用不同颜色进行区分。7. 图表:对于较复杂的用例,可以用图例说明用例之间关系。10 范例期初资产录入用例系统建账后,固定资产会计必须进入固定资产系统,将建账月以前的资产卡片录入系统,实现手工账与计算机账的对接,使固定资产核算能够连续进行,并为固定资产的后续工作如工作量录入、折旧计提、折旧分摊等工作提供资产卡片基础数据。固定资产会计在操作此功能前需要保证资产类别、计量单位、存放地点、折旧方法现行系统未实现折旧方法设置,只能浏览,所以用户不需设置。已经设置,因为资产卡片需要从上述用例中获取基础数据。基本功能包括增加、修改、删除等操作。(此处可作为非正式用例)图1-3 期初资产录入与用例关系范 围:固定资产系统级 别:用户目标主执行者:固定资产会计项目相关人员和利益:固定资产会计:资产卡片计算机管理,快速查看资产。系统:获取固定资产计提折旧依据。前置条件:资产类别、计量单位、存放地点、折旧方法等基础信息已经设置。最小保证:系统运行失败,将失败信息写入日志。成功保证:系统保存固定资产卡片信息。触发事件:系统建账后,固定资产会计必须将企业已有的固定资产录入系统;以后各期不需要录入,现系统未控制,新系统应有控制点。主成功场景:1. 固定资产会计增加操作,系统自动计算资产编号资产编号长度为5位,资产编号=MAX(已经存在的资产编号)+1,资产编号长度不足5位的,前面以0补位。并显示,将所有数值型数据置为0,显示用户设置默认的残值率2. 固定资产会计输入:资产名称资产类别资产来源 资产来源包括:购置的固定资产自行建造的固定资产投资者投入的固定资产融资租入的固定资产接受捐赠的固定资产盘盈的固定资产计量单位存放地点所属部门启用日期是否计提折旧方法3. 固定资产会计选择折旧方法为工作量法,预计工作量和已用工作量可用,而预计使用月数和已用月数不可用4. 固定资产会计输入预计使用月数或预计工作量,系统根据折旧方法计算月折旧率月折旧额已提折旧已提折旧月折旧额已用月数账面净值账面净值资产总额已提折旧5. 固定资产会计输入已用月数或已用工作量,系统根据折旧方法计算月折旧率月折旧额已提折旧账面净值6. 固定资产会计输入资产总额,系统根据折旧方法计算残值残值资产总额残值率月折旧额已提折旧

温馨提示

  • 1. 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。图纸软件为CAD,CAXA,PROE,UG,SolidWorks等.压缩文件请下载最新的WinRAR软件解压。
  • 2. 本站的文档不包含任何第三方提供的附件图纸等,如果需要附件,请联系上传者。文件的所有权益归上传用户所有。
  • 3. 本站RAR压缩包中若带图纸,网页内容里面会有图纸预览,若没有图纸预览就没有图纸。
  • 4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
  • 5. 人人文库网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对用户上传分享的文档内容本身不做任何修改或编辑,并不能对任何下载内容负责。
  • 6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
  • 7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。

评论

0/150

提交评论