需求分析规范——附加说明1：用例描述文档编写规范

1、ER顷目需求分析规范用例描述文档编写规范（精要）版本 <>文档编号：001-0002-2版本历史日期版本描述作者2006-07-01<>初稿整理吕春秋1. 前言目的 范围 本文档说明2. 基本要求错误!未定义书签。错误!未定义书签。错误!未定义书签。错误!未定义书签。错误!未定义书签。3. 用例事件流的描述基本事件流的要求子事件流的要求备选事件流的要求事件流中的序号标号事件流中“确认”与“执行”操作的描述错误!未定义书签。错误!未定义书签。错误!未定义书签。错误!未定义书签。错误!未定义书签。错误!未定义书签。4. 业务规则的描述业务规则的种类业务规则的抽取及编号 公共

2、业务规则的抽取及编号业务规则描述结构要点说明式 顺序结构 分支结构 循环结构 混合结构 注意事项业务规则描述中的缩进规则业务规则描述中的标号5. 子用例的定义与描述上级调用用例的判断方法错误!未定义书签。错误!未定义书签。错误!未定义书签。错误!未定义书签。错误!未定义书签。错误!未定义书签。错误!未定义书签。错误!未定义书签。错误!未定义书签。错误!未定义书签。错误!未定义书签。错误!未定义书签。错误!未定义书签。错误!未定义书签。错误!未定义书签。6. 用例描述中的其它规范类、属性、参数的书写规则类名的书写规则 属性名的书写规则 参数名的书写规则 各种值的书写规则用例描述中的注释信息注释要

3、求注释信息的描述 参数传递错误!未定义书签。错误!未定义书签。错误!未定义书签。错误!未定义书签。错误!未定义书签。错误!未定义书签。错误!未定义书签。错误!未定义书签。错误!未定义书签。错误!未定义书签。7. 新一代ERPC统中的几个公共机制删除完整性检查状态管理错误!未定义书签。错误!未定义书签。错误!未定义书签。错误!未定义书签。错误!未定义书签。错误!未定义书签。错误!未定义书签。错误!未定义书签。错误!未定义书签。错误!未定义书签。变更管理 权限控制 消息机制 编号管理 地址管理 长文本8. 用例描述中用词规范用例描述文档编写规范（精要）1 .刖百1.1 目的本用例描述文档编写精要对

4、新一代ERP项目组几年来用例设计经验进行总结，广泛吸收各方长处，分析编写过程中出现的弊端，整理出了这些编写用例文档需要掌握的要点，为指导今后需求设 计、需求更改过程中文档编写起到规范的作用，不足，发现优点。还要不断地充实和完善。提高用例 编写水平，1.2 范围本“用例描述文档编写精要”作为一个规范性的文件，适用于新一代ERP项目组需求分析与设计过程中的用例描述文档的设计工作。1.3 本文档说明采用说明与案例相结合的方式进行描述，便于理解。本文档描述的内容相对比较多，每次应用时都通篇阅读比较费时。为了重点突出，文档描述中带“双下浪线”的文字都是当前章节的要点内容，便于概览阅读。为了问题说明重点突

5、出，所有例子都是化简之后的实例，不能认为例子与原用例的不一致就是用例错误或例子错误。新一代ERP项目的需求规范是在开发过程中不断总结和完善的，因此，本“用例描述文档编写精要”同样需要逐步完善的过程，如果发现文档存在问题，发现需求设计工作存在问题，或者有好的建 议，或者有不同见解，请及时与需求主管联系，诚谢。系统的效率2 .基本要求对于用例描述文档的书写(需求设计)，不同部分会有不同的要求，但是从整体上来讲应该遵循以下几项原则：1、要从开发者的角度完善文档的可读性及处理性能；2、要站在客户的角度考虑程序的可操作性3、用例所用的表结构要和 ROSE中的业务类图保持一致，用例中使用的类属性描述；4、

6、需求设计基本上还是逻辑功能设计，应该是面向任何开发工具和开发平台的。因此，在需求 文档中应该只描述出功能即可，而不应该绝对具体，以免限制设计人员针对具体开发工具的物理实现设计和程序人员的发挥；5、在用例描述文档中对事件流、业务规则、公共业务规则、例外、扩充点、注释等内容的引 用，要进行链接，便于阅读。3 .用例事件流的描述用例文档中有三种事件流：基本事件流、子事件流、备选事件流，事件流编写的基本要求如下：1、事件流描写“执行者”和“系统”的交互过程二般不应该夹杂着业务规则和条件判断:2、子事件流和备选事件流的确定：有的事件流在一个用例文档中既作为子事件流出现，又作为 备选事件流出现，此时没有必

7、要把这一个事件流分别作为子事件流和备选事件流写成两个， 而是以流程的执行或书写的顺序，在第一次使用这个事件流时它是子事件流，就将它放在子 事件流章节中作为子事件流来书写；在第一次使用这个事件流时它是备选事件流，就将它放 在备选事件流章节中作为备选事件流来书写；3、界面流转在事件流中一定要说清楚：例如:(2)系统显示“选择查询战略”界面( CCA120-09 。(3)执行者选择“按信息结构查询”。(4)系统根据条件“应用环境”=当前应用环境.并且.“物流应用程序标志”=真在“物流信息 系统”类中查找符合条件的信息，显示在界面内(CCA120-10"应用程序选择”界面)。正确的描述方法应

8、该是：(2)系统显示“选择查询战略”界面(CCA120-09（3）执行者选择“按信息结构查询”。（4） 奏锂七里m序选建二工_CCA120-10_?M并根据条件“应用环境”=当前应用环境. 并且.“物流应用程序标志”=真在“物流信息系统”类中查找符合条件的信息，显示在界 面内。4、流程中描写的操作应该是一个抽象的操作功能J而不应该写成“按 XX按钮”或“双击 XX 项”等具体的操作方法。例如，操作者要选择“执行”操作，可以写成：执行者选择“执行”。系统按照XX业务规则处理发货。而不写成：执行者按“执行”按钮，或执行者双击“执行”按钮；3.1基本事件流的要求任何用例都必须有基本事件流，基本事件流

9、是一个用例的入口点，是一个用例的主要流程。编写 基本事件流应该注意以下要点：1、基本事件流描写的是一个用例的主要流程，从这个主要流程能够看出用例执行的全貌:而非 主要流程或细节流程，可以放在子事件流或备选事件流中进行描写2、基本事件流是流程中正确处理的流程.例外流程应该作为备诜事件流来描述;3、基本事件流一定要清晰、完整，要有始有终,具有一个出口结束点；4、基本事件流描写的步骤丕直太多（过程比较复杂的用例的基本事件流一般也要控制在20个步骤之内）；1.11.2 子事件流的要求子事件流是另一个前序事件流中一个处理步骤的细节交互处理过程。编写子事件流应该注意以下要点：1、子事件流要放在用例文档的“

10、子事件流”章节中，子事件流的编号&二_S-nnL （ nn是从01开 始的连续的两位数字编号）；2、子事件流的定义除了要有子事件流编号之外，还应该给子事件流1个，中文名称,.便于阅读。例如：子事件流S-01:创建一个成本要素(1)系统按照业务规则“ BR-002:初始化基本数据界面规则”显示“创建成本要素-基本数据”界面(N-1 )(2)执行者输入或选择编辑项3、子事件流要完整(有始有终)，子事件流结束后，正常应该返回到引用子事件流之处，但是 也允许将控制转移到其它事件流；4、引用子事件流之处可以用“按照 子事件流编号进行XXX操作”等描述将控制转入子事件 流。例如：(4)执行者选择“

11、确定”。(5)系统进入“创建次级成本要素 -基本数据”界面(S-1:创建一个次级成本要素)，创建一个次级成本要素。1.3 备选事件流的要求备选事件流是前序事件流中某个备选操作项的详细过程描述，是前序事件流的一个处理分支。编 写子事件流应该注意以下要点：1、备选事件流要放在用例文档的“备选事件流”章节中，编号为“A-nn” (nn是从01开始的连续的两位数字编号)；2、备选事件流结束正常应该返回到引用备选事件流之处但是也允许将控制转移到其它事件流；3、引用备选事件流之处应该用“或某操作备选事件流编号”的方式将控制引入备选事件流；4、在引用备选事件流之处允许有多个备选操作项，例如：(3)执行者选择

12、“确定”(或“显示”A-01、或“创建” A02、或“退出”)5、对于“复制”、“删除”、“取消”、“退出”等备选操作，在“ERP-REQ-般说明.doc”文档中有标准的操作结果描述，如果当前用例对这些操作的记过与“ERP-REQ-般说明.doc”文档标准操作相一致，则在备选操作引用之处指出操作种类，而不同再重复描写备选操作流 逞；例如，上例的“或退出”备选项;6、有条件的备选流可以借助于其它方式进行描述，例如可以在界面原型中说明。1.4 事件流中的序号标号事件流中，对描述执行者和系统之间操作过程的步骤序号统一规范，使用"(m标号形式。1.5 事件流中“确认”与“执行”操作描述的建议

13、在事件流描述中，经常会遇到“确认”与“执行”之间备选操作的时候。在新一代ERP项目早期的用例描述中习惯于以下的方式：(3)系统显示“创建分配因子主数据界面” (CCA120-02 ;(4)执行者维护“名称”、“ 属性值并确认；(5)系统根据业务规则(BR-002)检查执行者录入；(6)执行者执行“保存”操作；(7)系统根据业务规则(BR-002)再次检查并更新“分配因子”类；这样描述之后，程序开发人员在阅读之后提出异议：在“确认”操作的时候都按照业务规则检查，“保存”时为什么还重复检查其实用例描述的本意是允许执行者在执行“保存”之前可以先使用“确 认”功能进行一次检查。为了意思表达清楚，规定：

14、在遇到“确认”与“执行”之间备选操作的时候使用备选流的方式进行描述，并且将“确认”功能作为备选流描述：(3)系统显示“创建分配因子主数据界面” (CCA120-02);(4)执行者维护“名称”、“ 属性值并执行“保存”(或“确认”A=02);(5)系统根据业务规则(BR-002)检查之后，并更新“分配因子”类；A-02:创建界面确认(1)系统按照业务规则(BR-002)检查检查界面数据项；(2)事件流结束，返回调用点。4 .业务规则的描述业务规则是需求文档中对业务处理要求及处理逻辑的描述，因此，除了在事件流当中描写的处理 过程之外，其它需求都应该放在业务规则中描写。4.1 业务规则的种类在新一

15、代ERP系统开发规范中，按照业务规则的应用范围（即所在文档）的不同，将其分为业务 规则和公共业务规则两类，它们在描述上没有什么区别，只是作用范围不同。对于它们共同的规定有 以下几方面：1、在用例描述文档中，对于重复使用的处理逻辑及处理规则，2、无论业务规则还是公共业务规则，除了给出正确的编号之外，还要给出其相应的中文名称。中文名称的要求是：能够高度概括业务规则的主要功能；3、为了便于阅读，无论业务规则还是公共业务规则，在其起始处都要给出简要的注释说明；4.1.1业务规则的抽取及编号这里所说的“业务规则”是用例文档中放在业务规则章节中描述的业务处理要求及处理逻辑，其 有效作用范围是所在用例。业务

16、规则的编号为：BR-nnn, （ nnn为用例中业务规则连续编号的序号）；业务规则处理4.1.2公共业务规则的抽取及编号公共业务规则和用例文档中的业务规则没有什么特别之处，只是超过一个以上的用例共同遵循或 者执行的业务规则。有的公共业务规则是为其它模块提供的“接口”。1、一般情况下，一个子模块的公共业务蛆则放在一个独立的公共业务视则文档中;2、公共业务规则的编号为：BR-nnn-XXX, （nnn为独立公共业务规则文档中业务规则连续编号的序号；XXX为三位的子模块编码）；3、公共规则一定要抽取，避免冗余陈述。4.2 业务规则描述结构对于软件需求的描述，根据要描述的需求的特性的不同，可以采用要点

17、说明式的描述，也可以借 鉴结构式软件开发方法，按照业务逻辑的结构进行描述。结构式描述共有三种结构方式：顺序结构、 分支结构、循环结构。无论采用哪一种描述方式，都不允许通过“转移”的方法实现业务逻辑，而是利用合理的结构体 来实现各种业务逻辑关系。4.2.1 要点说明式对于业务逻辑非常简单、或者没有处理逻辑的需求，可以采用要点说明式的描述方式，通过若干 个并列的说明条目，将需求描述清楚。例如:4.2.2 顺序结构对于具有顺序逻辑结构关系的需求，可以采用顺序结构方式进行描述。顺序结构的图示:V顺序结构可以按照操作的先后顺序逐条描写。4.2.3 分支结构对于具有条件约束、满足特定条件才能够执行的功能说

18、明，可以采用分支结构方式进行描述。分支结构的图示:(a)(b)对于分支结构，在需求文档中使用“如果则”的语法进行描述,对于图(a)的描述：如果条件成立，则相应处理对于图(b)的描述：如果条件成立，则相应处理1否则相应处理2多重分支条件的描述（相当于CASE如果条件1成立，则相应处理1如果条件2成立，则相应处理2如果条件3成立，则相应处理3»4.2.4 循环结构对于需要重复处理、满足特定条件才能够结束的功能说明，可以采用循环结构方式进行描述。循 环结构的图示：(a)1、 在循环结构中，一定要首先给（指出）循环处理的，也可以用对象2、例1 :例2:例3:4.2.5 混合结构一般情况下，对

19、于一个比较复杂的需求，简单地采用一种结构方式描述是不够的，经常是以上几 种结构方式相互嵌套的混合结构方式进行描述。4.2.6 注意事项不能引用另外某个过则（或流程）中的某几个步骤，尤其是不连续的步骤。4.3 业务规则描述中的缩进规则层次关系。4.4 业务规则描述中的标号建议：。5 .子用例的定义与描述所谓子用例，就是在 UML中一个被其它用例所“包含”的用例。习惯称“包含”用例为上级用例，“包含”称为“引用”或“调用”。5.1 子用例的设计方法1、对于一个被引用的没有界面的处理过程，也可以将其设计为公共业务规则。但是，具有独立I一界面和操作过程的处理过程，必须将其设计为子用例；2、多个用例中具

20、有相同的操作界面和操作过程，应该将这个相同的操作界面和操作过程设计为一个子用例；3、对于多个用例中具有相同的操作过程或功能，这个操作过程不是执行者与系统之间交互进行 的，可以将这个相同的操作过程或功能设计为一个子用例或者设计为一个公共业务规则；5.2 子用例中判断上级调用用例的方法在合理的用例层次结构设计过程中，经常会设计为：多个上级用例调用一个子用例，而子用例中 的某一个处理功能又需要接收上级用例传递的参数来判断是哪一个上级用例调用执行的。在设计这种传递参数的时候，一定不要将用例编号设计为传递参数。因为，随着系统功能的扩 充，用例有可能增减，用例编号也有可能发生变化。一旦用例编号被用作为参数

21、传递，用例编号的变 化就会受到限制，或者需要修改用例、修改程序，或者忘记了修改用例和程序而使系统产生错误。一般正确的方案应该为：绚叁一上尊川例区立二t丕!1 叫叫熊代劲_争货休他）值？月国 每个 上级用例在调用子用例的时候传递属于的功能代码参数值。子用例中通过判断接收的功能代码参数值 来确定是哪一个上级用例调用执行的。6 .用例描述中的其它规范6.1 类、属性、参数、值的书写规则6.1.1 类名的书写规则1、在用例描述文档及业务规则文档中，类名一定要放在引号中：2、在描写类对象查找条件时，要按照“按照一二二条住在一:二二上至史查找匹配对象”的书写版式进 行描写；6.1.2 属性名的书写规则在用

22、例描述文档及业务规则文档中对属性名的描写，在多属性判断的复合条件中一般情况下遵循 开发语言的习惯，不放在引号（""或）中；但是为了清晰起见，在单独使用属性的场合下，可 以象类的描述一样，例如：检查“资本化固定资产标识”属性是否为“真”值，6.1.3 参数名的书写规则在用例描述文档及业务规则文档中对参数名的描写，遵循开发语言的习惯，一般情况下不放在引号（""或）中；6.1.4 各种值的书写规则在用例处理功能描述中，经常会出现判断某一个“值”的描述，这个值可以是类属性值（或参数值、或枚举值）。对于值描述的规范1、在用例描述文档及业务规则文档中对属性值或参数值

23、的直接描写，遵循开发语言的习惯，一 定要放在引号（""或）中。本书写规则要求，要将值的描述放在引号（""或） 中，而代码值、或必要的注释放在其后的括号中；例如：、并且 应用环境="营业费用-工资”、并且 2、 一般情况下系统处理的都是代码值，本规则要求，将使用的值的描述放在引号（"”或''）中，并且要求在其之后用括号“（）”给出代码值（或必要的注释性描述）。这样做 的必要性：含义清晰，不会引起歧义；开发人员读文档的时侯有助于快速理解文档；修改这 些值的时候一旦忘记了修改用例描述，事后容易发现问题、便于修改。例如：如果当

24、前段对象的“转出方规则”='记账金额（1）（对应的处理功能描述）（）6.2用例描述中的注释信息6.2.1注释要求1、用例描述文档中需要必要注释描述；2、简要描述中3、/* */4、注释章节6.2.2注释信息的描述6.3描述一致性用例中的类的属性一定要和 TF表中的字段名保持一致。7 .接口O8 .新一代ERP系统中的几个公共机制在新一代ERP系统中有一些公共机制会影响到系统开发及应用过程。有些公共机制对开发过程产生约束，开发必须遵循这些规范；有些公共机制的功能可以直接使用，在应用功能开发中几乎可以不 用再去考虑这些问题。8.1 删除完整性检查对于已经被使用的一些主数据、设置数据等，一旦被其它数据所引用，