《用例描述文档编写规范及需求分析附加说明.docx》由会员分享，可在线阅读，更多相关《用例描述文档编写规范及需求分析附加说明.docx（24页珍藏版）》请在课桌文档上搜索。
1、ERP项目需求分析规范用例描述文档编写规范（精要）版本文档编号：001-0002-2版本历史日期版本描述作者2023-07-01草稿整顿吕春秋1 .序言1.1 目的1.2 范围1.3 本文档阐明2 .基本规定错误!未定义书签。错误!未定义书签。错误!未定义书签。错误!未定义书签。错误!未定义书签。3.用例事件流的描述3.1 基本领件流H勺规定3.2 子事件流的规定3.3 备选事件流的规定3.4 事件流中向序号标号3.5 事件流中“确认”与“执行”操作的描述错误!未定义书签。错误!未定义书签。错误!未定义书签。错误!未定义书签。错误!未定义书签。错误!未定义书签。4.业务规则的描述4.1 业务规
2、则向种类业务规则的抽取及编号公共业务规则的抽取及编号4.2 业务规则描述构造要点阐明式次序构造分支构造循环构造错误!未定义书签。错误!未定义书签。错误!未定义书签。错误!未定义书签。错误!未定义书签。错误!未定义书签。错误!未定义书签。错误!未定义书签。错误!未定义书签。错误!未定义书签。 错误!未定义书签。 错误!未定义书签。 错误!未定义书签。错误!未定义书签。 错误!未定义书签。错误!未定义书签。错误!未定义书签。 错误!未定义书签。 错误!未定义书签。 错误!未定义书签。 错误!未定义书签。 错误!未定义书签。 错误!未定义书签。 错误!未定义书签。 错误!未定义书签。错误!未定义书签
3、。 错误!未定义书签。 错误!未定义书签。 错误!未定义书签。 错误!未定义书签。 错误!未定义书签。混合构造注意事项1.3 业务规则描述中的缩进规则1.4 业务规则描述中的标号5 .子用例内定义与描述5.1 上级调用用例的判断措施6 .用例描述中的其他规范6.1 类、属性、参数I向书写规则类名的书写规则属性名的书写规则参数名的书写规则多种值的书写规则6.2 用例描述中的J注释信息注释规定注释信息的描述6.3 参数传递7 .新一代ERP系统中的几种公共机制7.1 删除完整性检查7.2 状态管理7.3 变更管理7.4 权限控制7.5 消息机制7.6 编号管理7.7 地址管理7.8 长文本错误!未
4、定义书签。错误!未定义书签。错误!未定义书签。错误!未定义书签。8 .用例描述中用词规范用例描述文档编写规范（精要）1 .序言1.1 目的本用例描述文档编写精要对新一代ERP项目组儿年来用例设计经验进行总结，广泛吸取各方长处，分析编写过程中出现的J弊端，整顿出了这些编写用例文档需要掌握的要点，为指导此后需求设计、需求更改正程中文档编写起到规范的作用，局限性，发现长处。还要不停地充实和完善。提高用例编写水平，1.2 范围本“用例描述文档编写精要”作为一种规范性的文献，合用于新一代ERP项目组需求分析与设计过程中的用例描述文档的设计工作。1.3 本文档阐明采用阐明与案例相结合的方式进行描述，便于理
5、解。本文档描述的内容相对比较多，每次应用时都通篇阅读比较费时。为了重点突出，文档描述中带“双下浪线”的文字都是目前章节的要点内容，便于概览阅读。为了问题阐明重点突出，所有例子都是化简之后的实例，不能认为例子与原用例的不一致就是用例错误或例子错误。新一代ERP项目的需求规范是在开发过程中不停总结和完善的，因此，本“用例描述文档编写精要”同样需要逐渐完善的过程，假如发现文档存在问题，发现需求设计工作存在问题，或者有好的提议，或者有不一样见解，请及时与需求主管联络，诚谢。系统的效率2 .基本规定对于用例描述文档的书写（需求设计），不一样部分会有不一样的规定，不过从整体上来讲应当遵照如下几项原则：1、
6、要从开发者口勺角度完善文档的可读性及处理性能；2、要站在客户H勺角度考虑程序的可操作性3、用例所用H勺表构造要和ROSE中的业务类图保持一致，用例中使用的类属性描述；4、需求设计基本上还是逻辑功能设计，应当是面向任何开发工具和开发平台的。因此，在需求文档中应当只描述出功能即可，而不应当绝对详细，以免限制设计人员针对详细开发工具的物理实现设计和程序人员的发挥；5、在用例描述文档中对事件流、业务规则、公共业务规则、例外、扩充点、注释等内容的引用，要进行链接，便于阅读。3 .用例事件流的描述用例文档中有三种事件流：基本领件流、子事件流、备选事件流，事件流编写的基本规定如下：1、事件流描写“执行者”和
7、“系统”的交互过程,一般不应当夹杂着业务规则和条件判断；2、子事件流和备选事件流确实定：有H勺事件流在一种用例文档中既作为子事件流出现，又作为备选事件流出现，此时没有必要把这一种事件流分别作为子事件流和备选事件流写成两个,而是以流程的执行或书写H勺次序，在第一次使用这个事件流时它是子事件流，就将它放在子事件流章节中作为子事件流来书写：在第一次使用这个事件流时它是备选事件流，就将它放在备选事件流章节中作为备选事件流来书写;3、界面流转在事件流中一定要说清晰;例如：(2)系统显示“选择查询战略”界面(CCAI20-09)0(3)执行者选择“按信息构造查询”。(4)系统根据条件“应用环境”=目前应用
8、环境.并且.“物流应用程序标志”=真在“物流信息系统”类中查找符合条件的信息，显示在界面内(CCA120-10应用程序选择”界面)。对的J的描述措施应当是：(2)系统显示“选择查询战略”界面(CC120-09)o(3)执行者选择“按信息构造查询”。(4)系统进入“应用程序选择(CCAI20-程)界面,并根据条件“应用环境”=目前应用环境.并且.“物流应用程序标志”=真在“物流信息系统”类中查找符合条件的信息，显示在界面内。4、流程中描写的I操作应当是一种抽象H勺操作功能,而不应当写成“按XX按钮”或“双击XX项”等详细的操作措施。例如，操作者要选择“执行”操作，可以写成：执行者选择“执行”。系
9、统按照XX业务规则处剪发货。而不写成：执行者按“执行”按钮，执行者双击“执行”按钮;3.1基本领件流的规定任何用例都必须有基本领件流，基本领件流是一种用例的入口点，是一种用例口勺重要流程。编写基本领件流应当注意如下要点：1、基本领件流描写的是一种用例的重要流程,从这个重要流程可以看出用例执行的全貌；而非重要流程或细节流程，可以放在子事件流或备选事件流中进行描写2、基本领件流是流程中对的处理的流程,例外流程应当作为备选事件流来描述：3、基本领件流一定要清晰、完整,要有始有终，具有一种出口结束点；4、基本领件流描写的环节不适宜太多（过程比较复杂的用例的基本领件流一般也要控制在20个环节之内）；5、
10、3.2子事件流的规定子事件流是另一种前序事件流中一种处理环节的细节交互处理过程。编写子事件流应当注意如下要点：1、子事件流要放在用例文档的“子事件流”章节中，子事件流H勺编号为“S-nn”（nn是从01开始时持续的两位数字编号）；2、子事件流的定义除了要有子事件流编号之外，还应当给子事件流一种中文名称,便于阅读。例如：1.2 子*件流S-01：创立一种成本要素（1）系统按照业务规则“BR.002：初始化基本数据界面规则”显示“创立成本要素-基本数据”界面（Nd）（2）执行者输入或选择编辑项3、子事件流要完整（有始有终），子事件流结束后，正常应当返回到引用子事件流之处,不过也容许将控制转移到其他
11、事件流:4、引用子事件流之处可以用“按照子事件流编号进行XXX操作”等描述将控制转入子事件流。例如：（4）执行者选择“确定”。（5）系统进入“创立次级成本要素-基本数据”界面（S1：创立一种次级成本要索）,创立一种次级成本要素。1.3 备选事件流的规定备选事件流是前序事件流中某个备选操作项的详细过程描述，是前序事件流口勺一种处理分支。编写子事件流应当注意如下要点：1、备选事件流要放在用例文档的“备选事件流”章节中，编号为“A-nn”（nn是从01开始的）持续的两位数字编号）；2、备选事件流结束正常应当返回到引用备选事件流之处,不过也容许将控制转移到其他事件流；3、引用备选事件流之处应当用“或某
12、操作各选骡件前编号”的方式将控制引入备选事件流；4、在引用备选事件流之处容许有多种备选操作项，例如：（3）执行者选择“确定”（或“显示”A-OV或“创立”A-02,或“退出”）。5、对于“复制”、“删除”、“取消”、“退出”等备选操作，在“ERP-REQ一般阐明.doc”文档中有原则的操作成果描述，假如目前用例对这些操作日勺记过与“ERP-REQ-一般阐明.doc”文档原则操作相一致,则在备选操作引用之处指出操作种类，而不一样再反复描写备选操作流程;例如，上例的“或，退出，”备选项；6、有条件的备选流可以借助于其他方式进行描述，例如可以在界面原型中阐明。1.4 事件流中的序号标号事件流中，对描
13、述执行者和系统之间操作过程日勺环节序号统一规范，使用“(1)”、“(2)”标号形式。1.5 事件流中“确认”与“执行”操作描述的提议在事件流描述中，常常会碰到“确认”与“执行”之间备选操作的时候。在新一代ERP项目初期的用例描述中习惯于如下的方式：(3)系统显示“创立分派因子主数据界面”(CCA120-02)；(4)执行者维护“名称”、“”属性值并确认：(5)系统根据业务规则(BR-OO2)检查执行者录入；(6)执行者执行“保留”操作：(7)系统根据业务规则(BR-OO2)再次检查并更新“分派因子”类：这样描述之后，程序开发人员在阅读之后提出异议：在“确认”操作的时候都按照业务规则检查，“保留
14、”时为何还反复检查？其实用例描述的本意是容许执行者在执行“保留”之前可以先使用“确认”功能进行一次检查。为了意思体现清晰.规定：在碰到“确认”与“执行”之间备选操作的时候使用备选流的方式进行描述，并且将“确认”功能作为备选流描述：(3)系统显示“创立分派因子主数据界面”(CCAI20-02)；(4)执行者维护“名称”、“”属性值并执行“保留”(或“确认”A-02)；(5)系统根据业务规则(BR-OO2)检查之后，并更新“分派因子”类；A-02：创立界面确认(1)系统按照业务规则(BR-OO2)检查检查界面数据项：(2)事件流结束，返回调用点。4 .业务规则的描述业务规则是需求文档中对业务处理规
15、定及处理逻辑的描述，因此，除了在事件流当中描写的处理过程之外，其他需求都应当放在业务规则中描写。4.1 业务规则的种类在新一代ERP系统开发规范中，按照业务规则的应用范围(即所在文档)的不一样，将其分为业务规则和公共业务规则两类,它们在描述上没有什么区别，只是作用范围不一样。对于它们共同的规定有如下几方面：1、在用例描述文档中，对于反复使用的处理逻辑及处理规则，2、无论业务规则还是公共业务规则，除了给出对的的编号之外，还要给出其对应日勺中文名称。中文名称的规定是：可以高度概括业务规则的重要功能；3、为了便于阅读，无论业务规则还是公共业务规则，在其起始处都要给出简要日勺注释阐明;4.1.1 业务
16、规则的抽取及编号这里所说的“业务规则”是用例文档中放在业务规则章节中描述的业务处理规定及处理逻辑，其有效作用范围是所在用例。业务规则的编号为：BRnnm（nnn为用例中业务规则持续编号的序号）；业务规则处理4.1.2 公共业务规则的抽取及编号公共业务规则和用例文档中的业务规则没有什么尤其之处，只是超过种以上的用例共同遵照或者执行的业务规则.有的公共业务规则是为其他模块提供的“接口”。1、一般状况下，一种子模块的公共业务规则放在一种独立H勺公共业务规则文档中;2、公共业务规则的编号为：BR-nnn-XXX,（nnn为独立公共业务规则文档中业务规则持续编号的序号；XXX为三位的子模块编码）；3、公
17、共规则一定要抽取，防止冗余陈说。4.2 业务规则描述构造对于软件需求的描述，根据要描述的需求口勺特性的不一样，可以采用要点阐明式的描述，也可以借鉴构造式软件开发措施，按照业务逻帽的构造进行描述。构造式描述共有三种构造方式：次序构造、分支构造、循环构造。无论采用哪一种描述方式，都不容许通过“转移”口勺措施实现业务逻辑，而是运用合理的构造体来实现多种业务逻辑关系。4.2.1 要点阐明式对于业务逻辑非常简朴、或者没有处理逻辑H勺需求，可以采用要点阐明式描述方式，通过若干个并列的阐明条目，将需求描述清晰。例如:4.2.2 次序构造对于具有次序逻辑构造关系的需求，可以采用次序构造方式进行描述。次序构造的
18、图示:次序构造可以按照操作的先后次序逐条描写。4.2.3 分支构造对于具有条件约束、满足特定条件才可以执行的功能阐明，可以采用分支构造方式进行描述。分支构造的图示：对于分支构造，在需求文档中使用“假如则”的语法进行描述,对于图（a）的描述:假如条件成立，则对应处理对于图(b)日勺描述：假如条件成立，则对应处理1否则对应处理2多重分支条件的描述(相称于CASE)：假如条件1成立，则对应处理1假如条件2成立，则对应处理2假如条件3成立，则对应处理34.2.4 循环构造对于需要反复处理、满足特定条件才可以结束口勺功能阐明，可以采用循环构造方式进行描述。循环构造的图示:1、 在循环构造中，一定要首先给
19、（指出）循环处理的，也可以用对象2、例1：例2：例3：4.2.5 混合构造一般状况下，对于一种比较复杂的需求，简朴地采用一种构造方式描述是不够时，常常是以上儿种构造方式互相嵌套的混合构造方式进行描述。4.2.6 注意事项不能引用此外某个过则（或流程）中“勺某几种环节，尤其是不持续的环节。4.3 业务规则描述中的缩进规则层次关系。4.4 业务规则描述中的标号提议：。5 .子用例0定义与描述所谓子用例，就是在UML中一种被其他用例所“包括”的用例。习惯称“包括”用例为上级用例，“包括”称为“引用”或“调用”。5.1 子用例B设计措施1、对于一种被引用的没有界面的处理过程，也可以将其设计为公共业务规
20、则。不过，具有独立界面和操作过程H勺处理过程，必须将其设计为子用例:2、多种用例中具有相似的操作界面和操作过程，应当将这个相似H勺操作界面和操作过程设计为一种子用例;3、对于多种用例中具有相似的操作过程或功能，这个操作过程不是执行者与系统之间交互进行的，可以将这个相似的操作过程或功能设计为一种子用例或者设计为一种公共业务规则;5.2 子用例中判断上级调用用例的措施在合理的用例层次构造设计过程中，常常会设计为：多种上级用例调用一种子用例，而子用例中的某一种处理功能又需要接受上级用例传递的参数来判断是哪一种上级用例调用执行的。在设计这种传递参数的时候，一定不要将用例编号设计为传递参数。由于，伴随系
21、统功能的扩充，用例有也许增减，用例编号也有也许发生变化。一旦用例编号被用作为参数传递，用例编号的变化就会受到限制，或者需要修改用例、修改程序，或者忘掉了修改用例和程序而使系统产生错误。一般对的的方案应当为：给每个上级用例设计一种不一样的功能代码（事务代码）值,并且，每个上级用例在调用子用例的时候传递属于的功能代码参数值。子用例中通过判断接受口勺功能代码参数值来确定是哪一种上级用例调用执行时。6 .用例描述中的其他规范6.1 类、属性、参数、值的书写规则6.1.1 类名的书写规则1、在用例描述文档及业务规则文档中，类名一定要放在引号中;2、在描写类对象查找条件时，要按照“按照条件在,类也查找匹配
22、对象”的书写版式进行描写；6.1.2 属性名的书写规则在用例描述文档及业务规则文档中对属性名口勺描写，在多属性判断的复合条件中一般状况下遵照开发语言的习惯，不放在引号（或）中;不过为了清晰起见，在单独使用属性的场所下，可以象类的描述同样，例如：检查“资本化固定资产标识”属性与否为“真”值，6.1.3 参数名的书写规则在用例描述文档及业务规则文档中对参数名的描写，遵照开发语言的习惯，一般状况下不放在引号（“”或，）中;6.1.4 多种值的书写规则在用例处理功能描述中，常常会出现判断某一种“值”口勺描述，这个值可以是类属性值（或参数值、或枚举值）。对于值描述的规范1、在用例描述文档及业务规则文档中
23、对属性值或参数值的直接描写，遵照开发语言的习惯，一定要放在引号（或“）中。本书写规则规定，要将值的描述放在引号（或）中，而代码值、或必要时注释放在其后的括号中；例如：、并且应用环境=”营业费用-工资”、并且2、一般状况下系统处理的都是代码值，本规则规定，将使用时值的描述放在引号（“”或）中，并且规定在其之后用括号“（）”给出代码值（或必要H勺注释性描述）。这样做的必要性：含义清晰，不会引起歧义；开发人员读文档时时侯有助于迅速理解文档；修改这些值的时候一旦忘掉了修改用例描述，事后轻易发现问题、便于修改。例如：假如目前段对象的“转出方规则”=记账金额（1）（对应的处理功能描述）（）6.2 用例描述
24、中的注释信息6.2.1 注释规定1、用例描述文档中需要必要注释描述;2、简要描述中3、/*74、注释章节6.2.2 注释信息的描述6.3 描述一致性用例中的类附属性一定要和TF表中的字段名保持一致。7 .接口8 .新一代ERP系统中的几种公共机制在新一代ERP系统中有某些公共机制会影响到系统开发及应用过程。有些公共机制对开发过程产生约束，开发必须遵照这些规范；有些公共机制的功能可以直接使用，在应用功能开发中几乎可以不用再去考虑这些问题。8.1 删除完整性检查对于已经被使用的某些主数据、设置数据等，一旦被其他数据所引用，就不容许对其执行删除操作，以防止系统内产生不完整的数据。这种删除确认检查在整
25、个系统内采用一种统一实现机制，称为“删除完整性检查”。在需求中对于删除完整性检查的规定：1、对于某些比较重要的主数据、组织数据等，都必须对其做删除完整性检查:2、在删除完整性检查表（REQ-ERP-IC-XXX-删除完整性检查.xls）中填写需要检查及做检查的类名、关键字属性名；3、 （DBA将删除完整性检查表中的数据导入到系统表中）；4、在需求文档中执行删除操作R流程或业务规则中写明“按照删除完整性检查规则进行检查，检查通过后执行删除操作”即可。8.2 消息机制新一代ERP系统采用统一的消息机制，消息支持多语言，消息错误级别可定制。需求文档中对于消息机制的描述：1、在消息清单文档（REQ-E
26、RP-ML-XXX-消息表.xlS）中，按照格式填写消息号、消息类别、与否容许顾客设置消息类别、消息文本等；2、在用例的消息3、消息参数8.3 编号管理1、PUB初始数据中填写编号对象；2、9 .用例描述中用词规范9.1 范围值的描述范围值的英文描述为formto，直译中文为“从”“至”。而在界面设计中，要设计为真正的中文，因此规范为“起始、截止”或“开始、结束”。以日期值为例，应当书写为“起始日期”与“截止日期”字样。“缺省值”，不倡导用“默认值”“冲销”，而不是“反冲”，“反冲”在系统(REM)中具有特定口勺意义。界面原型中按钮的原则用词：新建、修改、删除、显示；在用例中使用“创立”。界面原型的菜单栏上将“表视图”替代成“文献”。界面原型标题栏中的“视图”、“总览”字样去掉；“细节”、“细目”字样统一替代成“详细收白，1己思O“变式”替代成“参数”，但在用例内部使用“代码”“后勤”为“物流”类图和用例图主事件流一定要清晰完整，整篇文档保持一种粒度。最佳在用例文档中把PAI和PBO分清晰，有助于程序员开发。
