用例描述文档编写规范及需求分析附加说明.docx

《用例描述文档编写规范及需求分析附加说明.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 业务规则的抽取及编号这里所说的“业务规则”