百度文库 - 让每个人平等地提升自我需求分析规范用例描述文档编写规范（精要）版本 <>文档编号：001-0002-2版本历史日期版本描述作者2006-07-01 <> 初稿整理吕春秋目录1.前言51.1目的51.2范围51.3本文档说明52.基本要求63.用例事件流的描述63.1基本事件流的要求73.2子事件流的要求73.3备选事件流的要求83.4事件流中的序号标号93.5事件流中“确认”与“执行”操作描述的建议94.业务规则的描述94.1业务规则的种类94.1.1业务规则的抽取及编号104.1.2公共业务规则的抽取及编号104.2业务规则描述结构104.2.1要点说明式104.2.2顺序结构114.2.3分支结构114.2.4循环结构124.2.5混合结构134.2.6注意事项134.3业务规则描述中的缩进规则134.4业务规则描述中的标号135.子用例的定义与描述135.1子用例的设计方法135.2子用例中判断上级调用用例的方法136.用例描述中的其它规范146.1类、属性、参数、值的书写规则146.1.1类名的书写规则146.1.2属性名的书写规则146.1.3参数名的书写规则146.1.4各种值的书写规则146.2用例描述中的注释信息156.2.1注释要求156.2.2注释信息的描述156.3描述一致性157.接口158.新一代ERP系统中的几个公共机制158.1删除完整性检查158.2消息机制168.3编号管理169.用例描述中用词规范169.1范围值的描述16用例描述文档编写规范（精要）1. 前言1.1 目的本用例描述文档编写精要对新一代ERP项目组几年来用例设计经验进行总结，广泛吸收各方长处，分析编写过程中出现的弊端，整理出了这些编写用例文档需要掌握的要点，为指导今后需求设计、需求更改过程中文档编写起到规范的作用，不足，发现优点。
还要不断地充实和完善。
提高用例编写水平，1.2 范围本“用例描述文档编写精要”作为一个规范性的文件，适用于新一代ERP项目组需求分析与设计过程中的用例描述文档的设计工作。
1.3 本文档说明采用说明与案例相结合的方式进行描述，便于理解。
本文档描述的内容相对比较多，每次应用时都通篇阅读比较费时。
为了重点突出，文档描述中带“双下浪线”的文字都是当前章节的要点内容，便于概览阅读。
为了问题说明重点突出，所有例子都是化简之后的实例，不能认为例子与原用例的不一致就是用例错误或例子错误。
新一代ERP项目的需求规范是在开发过程中不断总结和完善的，因此，本“用例描述文档编写精要”同样需要逐步完善的过程，如果发现文档存在问题，发现需求设计工作存在问题，或者有好的建议，或者有不同见解，请及时与需求主管联系，诚谢。
系统的效率2. 基本要求对于用例描述文档的书写（需求设计），不同部分会有不同的要求，但是从整体上来讲应该遵循以下几项原则：1、要从开发者的角度完善文档的可读性及处理性能；2、要站在客户的角度考虑程序的可操作性3、用例所用的表结构要和ROSE中的业务类图保持一致，用例中使用的类属性描述；4、需求设计基本上还是逻辑功能设计，应该是面向任何开发工具和开发平台的。
因此，在需求文档中应该只描述出功能即可，而不应该绝对具体，以免限制设计人员针对具体开发工具的物理实现设计和程序人员的发挥；5、在用例描述文档中对事件流、业务规则、公共业务规则、例外、扩充点、注释等内容的引用，要进行链接，便于阅读。
3. 用例事件流的描述用例文档中有三种事件流：基本事件流、子事件流、备选事件流，事件流编写的基本要求如下：1、事件流描写“执行者”和“系统”的交互过程，一般不应该夹杂着业务规则和条件判断；2、子事件流和备选事件流的确定：有的事件流在一个用例文档中既作为子事件流出现，又作为备选事件流出现，此时没有必要把这一个事件流分别作为子事件流和备选事件流写成两个，而是以流程的执行或书写的顺序，在第一次使用这个事件流时它是子事件流，就将它放在子事件流章节中作为子事件流来书写；在第一次使用这个事件流时它是备选事件流，就将它放在备选事件流章节中作为备选事件流来书写；3、界面流转在事件流中一定要说清楚；例如：(2) 系统显示“选择查询战略”界面（CCA120-09）。
(3) 执行者选择“按信息结构查询”。
(4) 系统根据条件 {“应用环境”=当前应用环境.并且.“物流应用程序标志”＝真} 在“物流信息系统”类中查找符合条件的信息，显示在界面内（CCA120-10“应用程序选择”界面）。
正确的描述方法应该是：(2) 系统显示“选择查询战略”界面（CCA120-09）。
(3) 执行者选择“按信息结构查询”。
(4) 系统进入“应用程序选择”（CCA120-10）界面，并根据条件 {“应用环境”=当前应用环境.并且.“物流应用程序标志”＝真} 在“物流信息系统”类中查找符合条件的信息，显示在界面内。
4、流程中描写的操作应该是一个抽象的操作功能，而不应该写成“按XX按钮”或“双击XX项”等具体的操作方法。
例如，操作者要选择“执行”操作，可以写成：执行者选择“执行”。
系统按照XX业务规则处理发货。
而不写成：执行者按“执行”按钮，或执行者双击“执行”按钮；3.1 基本事件流的要求任何用例都必须有基本事件流，基本事件流是一个用例的入口点，是一个用例的主要流程。
编写基本事件流应该注意以下要点：1、基本事件流描写的是一个用例的主要流程，从这个主要流程能够看出用例执行的全貌；而非主要流程或细节流程，可以放在子事件流或备选事件流中进行描写2、基本事件流是流程中正确处理的流程，例外流程应该作为备选事件流来描述；3、基本事件流一定要清晰、完整，要有始有终，具有一个出口结束点；4、基本事件流描写的步骤不宜太多（过程比较复杂的用例的基本事件流一般也要控制在20个步骤之内）；5、3.2 子事件流的要求子事件流是另一个前序事件流中一个处理步骤的细节交互处理过程。
编写子事件流应该注意以下要点：1、子事件流要放在用例文档的“子事件流”章节中，子事件流的编号为“S-nn”（nn是从01开始的连续的两位数字编号）；2、子事件流的定义除了要有子事件流编号之外，还应该给子事件流一个中文名称，便于阅读。
例如：子事件流S-01：创建一个成本要素（1）系统按照业务规则“”显示“创建成本要素-基本数据”界面（）（2）执行者输入或选择编辑项……3、子事件流要完整（有始有终），子事件流结束后，正常应该返回到引用子事件流之处，但是也允许将控制转移到其它事件流；4、引用子事件流之处可以用“按照‘子事件流编号’进行XXX操作”等描述将控制转入子事件流。
例如：……（4）执行者选择“确定”。
（5）系统进入“创建次级成本要素-基本数据”界面（），创建一个次级成本要素。
……3.3 备选事件流的要求备选事件流是前序事件流中某个备选操作项的详细过程描述，是前序事件流的一个处理分支。
编写子事件流应该注意以下要点：1、备选事件流要放在用例文档的“备选事件流”章节中，编号为“A-nn”（nn是从01开始的连续的两位数字编号）；2、备选事件流结束正常应该返回到引用备选事件流之处，但是也允许将控制转移到其它事件流；3、引用备选事件流之处应该用“或某操作‘备选事件流编号’”的方式将控制引入备选事件流；4、在引用备选事件流之处允许有多个备选操作项，例如：……（3）执行者选择“确定”（或“显示”、或“创建”A-02、或“退出”）。
……5、对于“复制”、“删除”、“取消”、“退出”等备选操作，在“ERP-REQ-一般说明.doc”文档中有标准的操作结果描述，如果当前用例对这些操作的记过与“ERP-REQ-一般说明.doc”文档标准操作相一致，则在备选操作引用之处指出操作种类，而不同再重复描写备选操作流程；例如，上例的“或‘退出’”备选项；6、有条件的备选流可以借助于其它方式进行描述，例如可以在界面原型中说明。
3.4 事件流中的序号标号事件流中，对描述执行者和系统之间操作过程的步骤序号统一规范，使用“（1）”、“（2）”标号形式。
3.5 事件流中“确认”与“执行”操作描述的建议在事件流描述中，经常会遇到“确认”与“执行”之间备选操作的时候。
在新一代ERP项目早期的用例描述中习惯于以下的方式：(3) 系统显示“创建分配因子主数据界面”（ CCA120-02）；(4) 执行者维护“名称”、“……”属性值并确认；(5) 系统根据业务规则（）检查执行者录入；(6) 执行者执行“保存”操作；(7) 系统根据业务规则（）再次检查并更新“分配因子”类；这样描述之后，程序开发人员在阅读之后提出异议：在“确认”操作的时候都按照业务规则检查，“保存”时为什么还重复检查？其实用例描述的本意是允许执行者在执行“保存”之前可以先使用“确认”功能进行一次检查。
为了意思表达清楚，规定：在遇到“确认”与“执行”之间备选操作的时候使用备选流的方式进行描述，并且将“确认”功能作为备选流描述：(3) 系统显示“创建分配因子主数据界面”（ CCA120-02）；(4) 执行者维护“名称”、“……”属性值并执行“保存”（或“确认”A-02）；(5) 系统根据业务规则（）检查之后，并更新“分配因子”类；……A-02：创建界面确认(1) 系统按照业务规则（）检查检查界面数据项；(2) 事件流结束，返回调用点。
4. 业务规则的描述业务规则是需求文档中对业务处理要求及处理逻辑的描述，因此，除了在事件流当中描写的处理过程之外，其它需求都应该放在业务规则中描写。
4.1 业务规则的种类在新一代ERP系统开发规范中，按照业务规则的应用范围（即所在文档）的不同，将其分为业务规则和公共业务规则两类，它们在描述上没有什么区别，只是作用范围不同。
对于它们共同的规定有以下几方面：1、在用例描述文档中，对于重复使用的处理逻辑及处理规则，2、无论业务规则还是公共业务规则，除了给出正确的编号之外，还要给出其相应的中文名称。
中文名称的要求是：能够高度概括业务规则的主要功能；3、为了便于阅读，无论业务规则还是公共业务规则，在其起始处都要给出简要的注释说明；4.1.1 业务规则的抽取及编号这里所说的“业务规则”是用例文档中放在业务规则章节中描述的业务处理要求及处理逻辑，其有效作用范围是所在用例。
业务规则的编号为：BR-nnn，（nnn为用例中业务规则连续编号的序号）；业务规则处理4.1.2 公共业务规则的抽取及编号公共业务规则和用例文档中的业务规则没有什么特别之处，只是超过一个以上的用例共同遵循或者执行的业务规则。
有的公共业务规则是为其它模块提供的“接口”。
1、一般情况下，一个子模块的公共业务规则放在一个独立的公共业务规则文档中；2、公共业务规则的编号为：BR-nnn-XXX，（nnn为独立公共业务规则文档中业务规则连续编号的序号；XXX为三位的子模块编码）；3、公共规则一定要抽取，避免冗余陈述。