需求分析规范——附加说明1用例描述文档编写规范
需求分析编写规范
序号修改条款修改单号页号修改人批准人实施日期注：对该文件内容增加、删除或者修改均需填写此变更记录，详细记载变更信息，以保证其可追溯性。
本规范根据GB/T8567-2022 编写。
目录1 引言 (4)1.1 标识 (4)1.2 系统概述 (4)1.3 文档概述 (4)1.4 引用文件 (4)2 任务概述 (4)2.1 目标 (4)2.2 用户类和特性 (5)2.3 假定和约束 (5)3 需求分析 (5)3.1 系统总体功能和业务结构及流程 (5)3.2 硬件系统需求 (5)3.3 软件系统需求 (5)3.4 接口需求 (5)3.4.1 系统外部接口标识和接口图 (5)3.4.2 系统内部接口标识和接口图 (5)3.5 系统能力需求 (6)3.5.1 ... 系统能力(子系统功能) .. (6)3.5.2 ... 系统能力(子系统功能) .. (6)3.6 系统内部数据需求 (6)3.7 系统适应性 (6)3.8 系统保密性和安全性要求 (6)3.9 操作需求 (6)3.10 故障处理需求 (7)3.10.1 软件系统出错处理 (7)3.10.2 硬件系统冗余措施说明 (7)3.11 计算机资源需求 (7)3.11.1 计算机硬件需求 (7)3.11.2 计算机资源利用需求 (7)3.11.3 计算机软件需求 (7)3.11.4 计算机通信需求 (8)3.12 系统质量因素 (8)3.12.1 系统可靠性 (8)3.12.2 系统易维护性 (8)3.12.3 系统灵便性 (8)3.12.4 软件可移植性 (8)3.12.5 易用性 (8)3.13 系统设计和构造的约束 (8)3.14 相关人员需求 (9)3.15 相关培训需求 (9)3.16 包装需求 (9)4 合格性规定 (9)5 需求可追踪性 (10)6 非技术性需求 (10)7 注释 (10)附录 (10)应包含本文档合用的系统和软件的完整标识，包括标识号、标题、缩略词语、版本号和发行号等。
功能需求分析用例描述文档
功能需求分析用例描述文档用例描述文档是一种为了记录和分析系统需求而设计的文档。
它描述了系统中的各个功能需求以及各种使用情景。
以下是一个功能需求分析用例描述文档的例子。
1.引言本文档旨在描述一个在线图书商城的功能需求。
该系统旨在为用户提供在线购买图书的便利，并提供统一的支付和物流服务。
通过购物车、订单管理和查找图书等功能，用户可以方便地购买图书并保障购买的安全性和准确性。
2.用户角色该系统涉及到两个主要的用户角色：-客户：通过该系统可以浏览、购买图书，并管理个人订单。
-管理员：负责管理图书库存，处理客户订单以及维护系统的正常运行。
3.功能需求3.1用户注册-用户可以通过提供必要的个人信息来注册一个新的账户。
-注册成功后，系统会自动生成一个唯一的用户ID。
3.2用户登录-系统会验证用户提供的登录信息的正确性。
3.3图书浏览和3.4添加至购物车-用户可以将感兴趣的图书添加至购物车。
-用户可以在购物车中查看已添加的图书，并对购物车中的图书进行管理，如修改数量或删除图书。
3.5下订单-用户可以在购物车中选择要购买的图书，并进入结算流程。
-在结算流程中，用户需要提供收货地址、支付方式等必要信息。
-系统会生成一个唯一的订单号，并将用户选择的图书、价格、数量等信息记录到订单中。
3.6订单管理-管理员可以查看系统中的所有订单，并对订单进行管理，如确认支付、发货等操作。
3.7物流跟踪-用户可以查看订单的物流信息，包括物流公司、运单号等。
-用户可以通过物流信息追踪订单的配送状态。
4.非功能需求4.1系统安全性-用户密码需要以安全的方式进行存储，例如使用哈希算法加密。
-用户的个人信息需要进行保护，不得泄露给除管理员外的其他人。
4.2系统稳定性-系统需要保证24小时的稳定运行，不得有较长的停机时间。
-系统需要定期备份数据，以防止数据丢失。
4.3用户友好性-系统需要提供直观和易于使用的界面，使用户能方便地使用各项功能。
-系统的响应时间应尽量减少，以提高用户体验。
需求分析规范
需求分析规范引言本标准规定了软件需求分析阶段的任务、过程和相关要求，以及需求分析阶段的完成标志。
它是软件开发规范的组成部分。
本标准适用于软件需求分析阶段的所有任务和相关人员，包括项目管理人员、软件需求分析人员、用户、文档编制人员和质量审核人员。
参考文献2.1 GB8566-88 计算机软件开发规范2.2 ISO/IEC 12207:1995 信息技术——软件生存周期过程2.3 GXB 02-001 软件开发规范：第一部分软件生存周期2.4 GXB 01-001 软件工程术语2.5 GXB 02-007 软件测试规范术语本标准的术语的定义与GXB 01-001软件工程术语中的定义相一致。
4、需求分析的任务和过程4.1 需求分析任务确定被开发软件的运行环境、功能、性能和数据需求，建立确认测试准则，编写用户手册，为概要设计提供需求说明书。
4.2 需求分析过程需求分析过程由下列步骤组成：1）确定需求分析方法和工具；2）对参加需求分析的人员进行培训；3）确定需求分析输入；4）需求分析；5）制定确定测试计划；6）确定开发计划；7）编制文档；8）需求分析评审；9）需求分析文档存档。
总体要求5.1 用户参与软件需求分析应该有客户指定的人员参加。
5.2 用户确认需求说明必须明确，经过客户同意，并用合同的方式予以确认。
情况特殊时（如税局项目），需由客户方负责人签字确认。
5.3 面向用户描述需求应以用户能够理解的形式和术语描述需求，以利于与用户沟通。
需求分析流程6.1 确定需求分析方法和工具选定合适的需求分析方法，在一个软件项目内所用的分析方法应该保持一致性。
候选分析方法：1）结构分析方法，包括面向数据流的分析方法和面向数据结构的分析方法。
2）面向对象的分析方法。
在需求分析方法选定后，应确定支持该方法的工具。
在一个软件项目内，需求建模语言和工具应该保持一致性和规范化。
6.2 人员培训针对所选定的设计方法和工具，以及相关的标准对需求人员进行相应的培训。
需求分析格式规范示例
《软件工程》实验报告——需求分析报告实验题目：宠物商店电子网站主设计人：崔海忠同组成员：魏宗辉刘芮专业班级：网络132003班所属系部：计算机科学与技术学院2015年11月04日《宠物商店电子网站》需求分析研究报告1引言 (1)1.1编写目的 (1)1.2预期读者 (1)1.3项目背景 (1)2任务概述 (1)2.1目标 (1)2.2运行环境操作系统 (1)2.3条件与限制硬件配置要求 (1)3系统说明 (2)3.1系统描述 (2)3.2系统角色分析 (2)3.3系统基本业务流程图 (2)3.4系统E-R图 (3)4功能需求 (4)4.1功能介绍 (4)4.2功能描述 (4)4.2.1系统顶层数据流图 (4)4.2.2用户系统 (4)4.2.3宠物商店 (5)4.2.4数据字典 (6)5性能需求 (7)6与系统交互需求 (7)7其它需求 (7)1引言1.1 编写目的本需求说明书全面描述宠物商店电子商务网站的各种功能，运行环境，使用户和宠物商店双方对本网站的初始规定有一个共同的理解，使之成为整个开发工作的基础。
1.2 预期读者本文档适用于电子宠物商店及用户预期读者:宠物商店，用户，供货商，项目开发人员，测试人员等1.3 项目背景该网站为了利于用户购物和宠物商店销售，使宠物商店能够为用户提供更好的服务，满足用户的需求，更快更好的适应现如今日益发展的社会，建立高效的服务平台。
2任务概述2.1 目标完善目前宠物商店电子商务网站，使之跟上时代的发展，并通过实践来提高自己的动手能力2.2 运行环境操作系统Window 7IIS5.0数据库SQL server 20052.3 条件与限制硬件配置要求硬件外部设备需奔腾133以上的pc机，内存需16兆以上。
软件要求操作人员具有初步的相关知识。
由于本系统为即时软件，对数据的同步要求较高，建议配置网络时使用可靠性较高的相关网络硬件设施。
3系统说明3.1 系统描述本网站主要为了方便用户购物、宠物商店销售，该系统可以提供更快、更优质的服务，而且在一定程度上可以提高宠物商店与用户的工作效率3.2 系统角色分析角色名称职务描述用户注册账号、创建登陆和支付密码后通过本网站查询商品、购物、退货等相关操作宠物商店提供商品信息，接收发送订单供货商接受订单3.3 系统基本业务流程图图3-1 业务流程图3.4 系统E-R图图3-2 E-R图4功能需求4.1 功能介绍网站的主要功能：宠物商店发布商品信息、接收发送订单等功能，用户创建账户、查询商品信息、购买商品、支付金额等功能，供货商接受订单并派送货物4.2 功能描述4.2.1系统顶层数据流图图4-1 系统顶层数据流图4.2.2用户系统1．功能介绍以用户购物为主要活动，相关记录根据购买情况结果进行调整，以使信息保持一致。
需求分析怎么写模板
需求分析写作模板需求分析是软件开发过程中至关重要的一环，它是确定软件系统需要满足的需求和约束的过程。
合理的需求分析能够帮助开发团队明确项目目标、规划开发过程、控制项目进度以及最终交付满足用户需求的产品。
下面是一个简单的需求分析写作模板，帮助团队成员规范地撰写需求分析文档。
1. 项目背景项目背景部分主要描述项目的背景信息，包括项目名称、项目目标、项目范围、项目时间表等内容。
需要明确说明项目的背景信息，以便团队成员对项目有一个整体的认识。
2. 需求分析目标需求分析目标部分主要说明本次需求分析的目标和范围，明确需求分析的重点和方向，以便更好地进行后续的工作。
3. 需求概述需求概述部分是对用户需求的一个整体描述，包括用户需求的基本情况、需求的重要性和紧急性等内容。
需要尽可能清晰、全面地描述用户的需求。
4. 功能需求功能需求部分是对系统功能需求的详细描述，包括系统应该具备的功能、功能之间的关系、功能的优先级和实现方式等内容。
需要对每个功能需求进行详细的分析和描述。
5. 非功能需求非功能需求部分是对系统非功能需求的描述，包括性能要求、可靠性要求、安全要求、可用性要求等内容。
需要对每个非功能需求进行详细的分析和描述。
6. 需求确认需求确认部分是对需求的确认和审核，需要与相关人员共同确认需求的准确性和完整性，确保项目的顺利进行。
7. 参考资料•相关资料1•相关资料2•…以上是一个简单的需求分析写作模板，团队成员可以根据项目实际情况进行适当调整，确保需求分析文档的完整性和准确性。
需求分析是项目成功的关键，希望所有团队成员都能够重视需求分析工作，为项目的顺利进行贡献力量。
需求分析规范——编码规范V1.0
需求编码规则I 日期：18.02.2004第二、三位为流水号。
给用例编号时，根据需要可以适当留空号）子模块代码（见附表ModuleList.xls ）1.需求类文档 XXX-REQ-XXX-XXX-XXX 子系统（或特性，见附表） 文档内容（见附表） 版本号或编号（如：用例编号）（当为整个项目的文档时，此段空）项目编号（见附表）2. 项目管理类文档XXX-PM-XXX-XXX-XXX版本号 3. 3.1文档内容子系统（或特性，见附表） 项目编号（当为整个项目的文档时，此段空）用例编号 正常用例编号XXX nnn 修改、3显示、4事务处理、 （第一位为1新建、2 理、8组织机构及通用的后台设置、9事务的后台设置;5事务处理、6查询打印、7期末处说明:(1) 正常按照功能划分的用例，其编号按照上面的规则进行编码，将来这个6位编码可以作为事务码来使用。
有些比较复杂的用例，为了书写方便的目的而将其拆分为几个子用例，这时没有必 要为每个子用例重新编号，而是在原来用例编号之后加2位数字顺序号表示，这个多于 6位的新编号将来不作为（也没有必要作为）事务码使用；(2) 划分子用例允许到多个层次级别，每向后增加一个级别，就在原用例编号之后再加 序号，以此类推。
2位数字顺3.2特定实施单位功能扩充用例编号 定义: （1）系统标准功能中已经有一个用例，某实施单位需要这个用例，但是与系统标准用例功能之间 存在着差异，需要对这个用例进行特殊增加或修改功能，从而产生新的用例； （2）没有或预计不会再有其他实施单位存在这个同样的功能差异，没有必要为这个新用例创建与 原用例编号没有任何联系的全新的用例编号。
编号规则: 在原正常用例的后面增加三位字符“ Xnn ”，其中：“ X ”代表特定实施单位（见附表 实施单位对照表 》）；“ nn ”为同一用例、在同一个实施单位的多个变型顺序号。
特定例如：用例INV413A01是依据INV413为轿车公司特制开发的第一个 变型用例。
需求分析报告编写规范
需求分析报告编写规范2.适用范围适用于本公司软件产品或软件工程的需求分析报告的编制。
3.术语及缩略语本程序采用NQ402100《质量手册》中的术语和缩略语及其定义。
4.编写标准4.1排版标准1〕整个标准由2节构成，模板单独一节。
2〕正文样式采用“标准正文”。
4.2模板使用需求分析报告的编写可依据具体情况选用摸板的格式或编写指南的格式。
1〕拷贝标准。
2〕删除第一节〔需求分析报告封面前的所有页〕。
3〕在修改完内容后，更新目录域和相关的页数域。
5.引用文件5.1NW503102《软件功能规格说明书编写标准》6.附录以下局部为需求分析报告的模板与编写指南。
1.2背景指出待开发的软件系统的名称；行业情况；本工程的任务提出者、开发者、用户；该软件系统同其他系统或其他机构的根本的相互来往关系。
网点简介1.4术语列出本报告中用到的专门术语的定义。
2.2系统〔或用户〕的特点如果是产品开发，应列出本软件的特点，与老版本软件〔如果有的话〕的不同之处，与市场上同类软件〔如果有的话〕的比拟。
说明本软件预期使用频度；如果是针对合同开发，那么应列出本软件的最终用户的特点，充分说明操作人员、维护人员的教育水平和技术专长，以及本软件预期使用频度。
这些是软件设计工作的重要约束。
3.假定和约束列出进行本软件开发工作的假定和约束，例如经费限制、开发期限等。
4.2对功能的一般性规定本处仅列出对软件系统的所有功能〔或一局部〕的共同要求，如要求界面格式统一，统一的错误声音提示，要求有在线帮助等。
4.3对性能的一般性规定对数据精度、响应时间的要求。
本处仅列出对软件系统的所有功能〔或一局部〕的共同要求，针对某一功能的专门性能要求应列在该功能规格说明中。
4.4其他专门要求视具体情况，列出不在本标准规定中的需求，如对数据库的要求，多平台特性要求，操作特性要求，场适宜应性要求等对一具体软件系统的所有功能〔或一局部〕的共同要求，针对某一功能的专门要求应列在该功能说明中。
用例文档编制规范指南
用例文档编制规范指南目次前言 II1 范围 12 规范性引用文件 13 概述 11 前言本标准是按照XX准化管理的工作任务及标准化委员会工作安排制定的。
制定本标准的目的是规范公司软件需求说明书内容。
本标准由公司研发部标准化委员会提出。
本标准由公司研发部标准化委员会负责起草。
准主要起草人：本标准主要审核人：本标准批准人：用例实现规约编制规范指南11 范围本标准规定了公司在用例实现规约文档内容。
12 规范性引用文件下列文件中的条款通过本标准的引用而成为本标准的条款。
凡是注日期的引用文件，其随后所有的修改单（不包括勘误的内容）或修订版均不适用于本标准，然而，鼓励根据本标准达成协议的各方研究是否可使用这些文件的最新版本。
凡是不注日期的引用文件，其最新版本适用于本标准。
《用例实现规约》《计算机软件工程国家标准汇编》《大唐思拓软件产品评审标准》13 概述1 目的和作用北京大唐思拓用例实现规约编制规范指南（以下简称本指南）为公司需求整理提供了一个规范化的方法，提供规范化的用例实现规约（以下简称用例文档）编写的格式及方式。
1.1 适用对象：1.1.1 软件开发者：通过对需求文档的分析以便他们准确了解客户需要什么样的产品，分析软件产品的流程、角色、状态和数据，以及其中的关系。
1.2 预计目标：1.2.1 程序用例文档是开发设计人员对需求的整理和分析。
对要实现的软件功能做全面描述、概括、分析、整理，帮助其他开发人员了解整个软件产品要实现的功能。
1.2.2 提高开发效率。
在程序用例文档中对各种需求进行反复分析、验证，还可以在开发早期发现遗漏、错误和理解偏差等问题，以便及时加以更正；同时也可以发现不能实现或不好实现的功能，及时调整开发资源的配置和开发计划。
2 编写程序用例文档的背景2.1 基本要求：2.1.1 程序用例文档必须要对一定的功能、性能进行分析描述。
2.1.2 程序用例文档必须以当前技术能够实现的方式确定这些功能、性能。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
百度文库 - 让每个人平等地提升自我需求分析规范用例描述文档编写规范（精要）版本 <>文档编号：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、公共规则一定要抽取，避免冗余陈述。