SAP需求分析规范用例描述文档编写规范模板Word格式.docx

SAP需求分析规范用例描述文档编写规范模板Word格式.docx

《SAP需求分析规范用例描述文档编写规范模板Word格式.docx》由会员分享，可在线阅读，更多相关《SAP需求分析规范用例描述文档编写规范模板Word格式.docx（12页珍藏版）》请在冰豆网上搜索。

为了问题说明重点突出，所有例子都是化简之后的实例，不能认为例子与原用例的不一致就是用例错误或例子错误。

SAP项目的需求规范是在开发过程中不断总结和完善的，因此，本“用例描述文档编写精要”同样需要逐步完善的过程，如果发现文档存在问题，发现需求设计工作存在问题，或者有好的建议，或者有不同见解，请及时与需求主管联系，诚谢。

系统的效率

2.基本要求

对于用例描述文档的书写（需求设计），不同部分会有不同的要求，但是从整体上来讲应该遵循以下几项原则：

1、要从开发者的角度完善文档的可读性及处理性能；

2、要站在客户的角度考虑程序的可操作性

3、用例所用的表结构要和ROSE中的业务类图保持一致，用例中使用的类属性描述；

4、需求设计基本上还是逻辑功能设计，应该是面向任何开发工具和开发平台的。

因此，在需求文档中应该只描述出功能即可，而不应该绝对具体，以免限制设计人员针对具体开发工具的物理实现设计和程序人员的发挥；

5、在用例描述文档中对事件流、业务规则、公共业务规则、例外、扩充点、注释等内容的引用，要进行链接，便于阅读。

3.用例事件流的描述

用例文档中有三种事件流：

基本事件流、子事件流、备选事件流，事件流编写的基本要求如下：

1、事件流描写“执行者”和“系统”的交互过程，一般不应该夹杂着业务规则和条件判断；

2、子事件流和备选事件流的确定：

有的事件流在一个用例文档中既作为子事件流出现，又作为备选事件流出现，此时没有必要把这一个事件流分别作为子事件流和备选事件流写成两个，而是以流程的执行或书写的顺序，在第一次使用这个事件流时它是子事件流，就将它放在子事件流章节中作为子事件流来书写；

在第一次使用这个事件流时它是备选事件流，就将它放在备选事件流章节中作为备选事件流来书写；

3、界面流转在事件流中一定要说清楚；

例如：

（2）系统显示“选择查询战略”界面（CCA120-09）。

（3）执行者选择“按信息结构查询”。

（4）系统根据条件{“应用环境”=当前应用环境.并且.“物流应用程序标志”＝真}在“物流信息系统”类中查找符合条件的信息，显示在界面内（CCA120-10“应用程序选择”界面）。

正确的描述方法应该是：

（4）系统进入“应用程序选择”（CCA120-10）界面，并根据条件{“应用环境”=当前应用环境.并且.“物流应用程序标志”＝真}在“物流信息系统”类中查找符合条件的信息，显示在界面内。

4、流程中描写的操作应该是一个抽象的操作功能，而不应该写成“按XX按钮”或“双击XX项”等具体的操作方法。

例如，操作者要选择“执行”操作，可以写成：

执行者选择“执行”。

系统按照XX业务规则处理发货。

而不写成：

执行者按“执行”按钮，

或

执行者双击“执行”按钮；

基本事件流的要求

任何用例都必须有基本事件流，基本事件流是一个用例的入口点，是一个用例的主要流程。

编写基本事件流应该注意以下要点：

1、基本事件流描写的是一个用例的主要流程，从这个主要流程能够看出用例执行的全貌；

而非主要流程或细节流程，可以放在子事件流或备选事件流中进行描写

2、基本事件流是流程中正确处理的流程，例外流程应该作为备选事件流来描述；

3、基本事件流一定要清晰、完整，要有始有终，具有一个出口结束点；

4、基本事件流描写的步骤不宜太多（过程比较复杂的用例的基本事件流一般也要控制在20个步骤之内）；

5、

子事件流的要求

子事件流是另一个前序事件流中一个处理步骤的细节交互处理过程。

编写子事件流应该注意以下要点：

1、子事件流要放在用例文档的“子事件流”章节中，子事件流的编号为“S-nn”（nn是从01开始的连续的两位数字编号）；

2、子事件流的定义除了要有子事件流编号之外，还应该给子事件流一个中文名称，便于阅读。

5.2子事件流

S-01：

创建一个成本要素

（1）系统按照业务规则“BR-002：

初始化基本数据界面规则”显示“创建成本要素-基本数据”界面（N-1）

（2）执行者输入或选择编辑项

……

3、子事件流要完整（有始有终），子事件流结束后，正常应该返回到引用子事件流之处，但是也允许将控制转移到其它事件流；

4、引用子事件流之处可以用“按照‘子事件流编号’进行XXX操作”等描述将控制转入子事件流。

（4）执行者选择“确定”。

（5）系统进入“创建次级成本要素-基本数据”界面（S-1：

创建一个次级成本要素），创建一个次级成本要素。

备选事件流的要求

备选事件流是前序事件流中某个备选操作项的详细过程描述，是前序事件流的一个处理分支。

1、备选事件流要放在用例文档的“备选事件流”章节中，编号为“A-nn”（nn是从01开始的连续的两位数字编号）；

2、备选事件流结束正常应该返回到引用备选事件流之处，但是也允许将控制转移到其它事件流；

3、引用备选事件流之处应该用“或某操作‘备选事件流编号’”的方式将控制引入备选事件流；

4、在引用备选事件流之处允许有多个备选操作项，例如：

（3）执行者选择“确定”（或“显示”A-01、或“创建”A-02、或“退出”）。

5、对于“复制”、“删除”、“取消”、“退出”等备选操作，在“ERP-REQ-一般说明.doc”文档中有标准的操作结果描述，如果当前用例对这些操作的记过与“ERP-REQ-一般说明.doc”文档标准操作相一致，则在备选操作引用之处指出操作种类，而不同再重复描写备选操作流程；

例如，上例的“或‘退出’”备选项；

6、有条件的备选流可以借助于其它方式进行描述，例如可以在界面原型中说明。

事件流中的序号标号

事件流中，对描述执行者和系统之间操作过程的步骤序号统一规范，使用“

（1）”、“

（2）”标号形式。

事件流中“确认”与“执行”操作描述的建议

在事件流描述中，经常会遇到“确认”与“执行”之间备选操作的时候。

在SAP项目早期的用例描述中习惯于以下的方式：

（3）系统显示“创建分配因子主数据界面”（CCA120-02）；

（4）执行者维护“名称”、“……”属性值并确认；

（5）系统根据业务规则（BR-002）检查执行者录入；

（6）执行者执行“保存”操作；

（7）系统根据业务规则（BR-002）再次检查并更新“分配因子”类；

这样描述之后，程序开发人员在阅读之后提出异议：

在“确认”操作的时候都按照业务规则检查，“保存”时为什么还重复检查？

其实用例描述的本意是允许执行者在执行“保存”之前可以先使用“确认”功能进行一次检查。

为了意思表达清楚，规定：

在遇到“确认”与“执行”之间备选操作的时候使用备选流的方式进行描述，并且将“确认”功能作为备选流描述：

（4）执行者维护“名称”、“……”属性值并执行“保存”（或“确认”A-02）；

（5）系统根据业务规则（BR-002）检查之后，并更新“分配因子”类；

A-02：

创建界面确认

（1）系统按照业务规则（BR-002）检查检查界面数据项；

（2）事件流结束，返回调用点。

4.业务规则的描述

业务规则是需求文档中对业务处理要求及处理逻辑的描述，因此，除了在事件流当中描写的处理过程之外，其它需求都应该放在业务规则中描写。

业务规则的种类

在SAP系统开发规范中，按照业务规则的应用范围（即所在文档）的不同，将其分为业务规则和公共业务规则两类，它们在描述上没有什么区别，只是作用范围不同。

对于它们共同的规定有以下几方面：

1、在用例描述文档中，对于重复使用的处理逻辑及处理规则，

2、无论业务规则还是公共业务规则，除了给出正确的编号之外，还要给出其相应的中文名称。

中文名称的要求是：

能够高度概括业务规则的主要功能；

3、为了便于阅读，无论业务规则还是公共业务规则，在其起始处都要给出简要的注释说明；

业务规则的抽取及编号

这里所说的“业务规则”是用例文档中放在业务规则章节中描述的业务处理要求及处理逻辑，其有效作用范围是所在用例。

业务规则的编号为：

BR-nnn，（nnn为用例中业务规则连续编号的序号）；

业务规则处理

公共业务规则的抽取及编号

公共业务规则和用例文档中的业务规则没有什么特别之处，只是超过一个以上的用例共同遵循或者执行的业务规则。

有的公共业务规则是为其它模块提供的“接口”。

1、一般情况下，一个子模块的公共业务规则放在一个独立的公共业务规则文档中；

2、公共业务规则的编号为：

BR-nnn-XXX，（nnn为独立公共业务规则文档中业务规则连续编号的序号；

XXX为三位的子模块编码）；

3、公共规则一定要抽取，避免冗余陈述。

业务规则描述结构

对于软件需求的描述，根据要描述的需求的特性的不同，可以采用要点说明式的描述，也可以借鉴结构式软件开发方法，按照业务逻辑的结构进行描述。

结构式描述共有三种结构方式：

顺序结构、分支结构、循环结构。

无论采用哪一种描述方式，都不允许通过“转移”的方法实现业务逻辑，而是利用合理的结构体来实现各种业务逻辑关系。

要点说明式

对于业务逻辑非常简单、或者没有处理逻辑的需求，可以采用要点说明式的描述方式，通过若干个并列的说明条目，将需求描述清楚。

顺序结构

对于具有顺序逻辑结构关系的需求，可以采用顺序结构方式进行描述。

顺序结构的图示：

顺序结构可以按照操作的先后顺序逐条描写。

分支结构

对于具有条件约束、满足特定条件才能够执行的功能说明，可以采用分支结构方式进行描述。

分支结构的图示：

对于分支结构，在需求文档中使用“如果……则……”的语法进行描述，

对于图（a）的描述：

如果《条件成立》，则

《相应处理》

对于图（b）的描述：

《相应处理1》

否则

《相应处理2》

多重分支条件的描述（相当于CASE）：

如果《条件1成立》，则

如果《条件2成立》，则

如果《条件3成立》，则

《相应处理3》

循环结构

对于需要重复处理、满足特定条件才能够结束的功能说明，可以采用循环结构方式进行描述。

循环结构的图示：

（a）（b）

1、在循环结构中，一定要首先给（指出）循环处理的，也可以用对象

2、

例1：

例2：

例3：

混合结构

一般情况下，对于一个比较复杂的需求，简单地采用一种结构方式描述是不够的，经常是以上几种结构方式相互嵌套的混合结构方式进行描述。

注意事项

不能引用另外某个过则（或流程）中的某几个步骤，尤其是不连续的步骤。

业务规则描述中的缩进规则

层次关系。

业务规则描述中的标号

建议：

。

5.子用例的定义与描述

所谓子用例，就是在UML中一个被其它用例所“包含”的用例。

习惯称“包含”用例为上级用例，“包含”称为“引用”或“调用”。

子用例的设计方法

1、对于一个被引用的没有界面的处理过程，也可以将其设计为公共业务规则。

但是，具有独立界面和操作过程的处理过程，必须将其设计为子用例；

2、多个用例中具有相同的操作界面和操作过程，应该将这个相同的操作界面和操作过程设计为一个子用例；

3、对于多个用例中具有相同的操作过程或功能，这个操作过程不是执行者与系统之间交互进行的，可以将这个相同的操作过程或功能设计为一个子用例或者设计为一个公共业务规则；

子用例中判断上级调用用例的方法

在合理的用例层次结构设计过程中，经常会设计为：

多个上级用例调用一个子用例，而子用例中的某一个处理功能又需要接收上级用例传递的参数来判断是哪一个上级用例调用执行的。

在设计这种传递参数的时候，一定不要将用例编号设计为传递参数。

因为，随着系统功能的扩充，用例有可能增减，用例编号也有可能发生变化。

一旦用例编号被用作为参数传递，用例编号的变化就会受到限制，或者需要修改用例、修改程序，或者忘记了修改用例和程序而使系统产生错误。

一般正确的方案应该为：

给每个上级用例设计一个不同的功能代码（事务代码）值，并且，每个上级用例在调用子用例的时候传递属于的功能代码参数值。

子用例中通过判断接收的功能代码参数值来确定是哪一个上级用例调用执行的。

6.用例描述中的其它规范

类、属性、参数、值的书写规则

类名的书写规则

1、在用例描述文档及业务规则文档中，类名一定要放在引号“”中；

2、在描写类对象查找条件时，要按照“按照……条件在‘……’类中查找匹配对象”的书写版式进行描写；

属性名的书写规则

在用例描述文档及业务规则文档中对属性名的描写，在多属性判断的复合条件中一般情况下遵循开发语言的习惯，不放在引号（“”或‘’）中；

但是为了清晰起见，在单独使用属性的场合下，可以象类的描述一样，例如：

检查“资本化固定资产标识”属性是否为“真”值，…

参数名的书写规则

在用例描述文档及业务规则文档中对参数名的描写，遵循开发语言的习惯，一般情况下不放在引号（“”或‘’）中；

各种值的书写规则

在用例处理功能描述中，经常会出现判断某一个“值”的描述，这个值可以是类属性值（或参数值、或枚举值）。

对于值描述的规范

1、在用例描述文档及业务规则文档中对属性值或参数值的直接描写，遵循开发语言的习惯，一定要放在引号（“”或‘’）中。

本书写规则要求，要将值的描述放在引号（“”或‘’）中，而代码值、或必要的注释放在其后的括号中；

……、并且应用环境＝“营业费用-工资”、并且……

2、一般情况下系统处理的都是代码值，本规则要求，将使用的值的描述放在引号（“”或‘’）中，并且要求在其之后用括号“（）”给出代码值（或必要的注释性描述）。

这样做的必要性：

含义清晰，不会引起歧义；

开发人员读文档的时侯有助于快速理解文档；

修改这些值的时候一旦忘记了修改用例描述，事后容易发现问题、便于修改。

如果当前段对象的“转出方规则”＝‘记账金额’

（1）

（对应的处理功能描述）

（……）

用例描述中的注释信息

注释要求

1、用例描述文档中需要必要注释描述；

2、简要描述中

3、/**/

4、注释章节

注释信息的描述

描述一致性

用例中的类的属性一定要和TF表中的字段名保持一致。

7.接口

8.SAP系统中的几个公共机制

在SAP系统中有一些公共机制会影响到系统开发及应用过程。

有些公共机制对开发过程产生约束，开发必须遵循这些规范；

有些公共机制的功能可以直接使用，在应用功能开发中几乎可以不用再去考虑这些问题。

删除完整性检查

对于已经被使用的一些主数据、设置数据等，一旦被其它数据所引用，就不允许对其执行删除操作，以避免系统内产生不完整的数据。

这种删除确认检查在整个系统内采用一个统一实现机制，称为“删除完整性检查”。

在需求中对于删除完整性检查的要求：

1、对于一些比较重要的主数据、组织数据等，都必须对其做删除完整性检查；

2、在删除完整性检查表（REQ-ERP-IC-XXX-删除完整性检查.xls）中填写需要检查及做检查的类名、关键字属性名；

3、（DBA将删除完整性检查表中的数据导入到系统表中）；

4、在需求文档中执行删除操作的流程或业务规则中写明“按照删除完整性检查规则进行检查，检查通过后执行删除操作”即可。

消息机制

SAP系统采用统一的消息机制，消息支持多语言，消息错误级别可定制。

需求文档中对于消息机制的描述：

1、在消息清单文档（REQ-ERP-ML-XXX-消息表.xls）中，按照格式填写消息号、消息类别、是否允许用户设置消息类别、消息文本等；

2、在用例的消息

3、消息参数

编号管理

1、PUB初始数据中填写编号对象；

9.用例描述中用词规范

范围值的描述

范围值的英文描述为form…to…，直译中文为“从”…“至”。

而在界面设计中，要设计为真正的中文，因此规范为“起始…、截止…”或“开始…、结束…”。

以日期值为例，应该书写为“起始日期”与“截止日期”字样。

“缺省值”，不提倡用“默认值”

“冲销”，而不是“反冲”，“反冲”在系统（REM）中具有特定的意义。

界面原型中按钮的标准用词：

新建、修改、删除、显示；

在用例中使用“创建”。

界面原型的菜单栏上将“表视图”替换成“文件”。

界面原型标题栏中的“视图”、“总览”字样去掉；

“细节”、“细目”字样统一替换成“详细信息”。

“变式”替换成“参数”，但在用例内部使用“代码”

“后勤”为“物流”

类图和用例图

主事件流一定要清晰完整，整篇文档保持一个粒度。

最好在用例文档中把PAI和PBO分清楚，有利于程序员开发。