软件需求与可视化模型

这本书只是介绍软件需求说明里面要用到的可视化模型，并不是指导写软件需求说明的，要结合software requirements一起使用

名词解释

名词	定义	案例
特征	特征是一组相关功能的简短描述，系统必须具备特征从而达实现业务目标；特征是需求的集合，特征用来说明以及组织需求。 A feature is a short-form description of an area of functionality， that the solution will ultimately include， to meet the business objectives 。 Features are collections of requirements that are used to articulate and organize the requirements Table 1-1 shows a few examples。
需求	需求是在解决方案中实现的任何东西，包括功能性需求，非功能性需求，业务规则。 A requirement is anything that the business needs to have implemented in the solution。 can include functional requirements, non-functional requirements, business rules, and even what many people traditionally call design
功能性需求	系统提供给用户的能力，不考虑任何条件。 A functional requirement is a behavior or capability that the solution can provide irrespective of any qualifers	系统能够自动审批/拒绝授信申请
业务规则	一个能够修改功能需求的条件语句，包括如，什么时候可以使用功能，谁能够使用功能，通常有 if、when修饰 A business rule is a requirement that represents a conditional statement that modifes a functional requirement, including, but not limited to, when the function is available and who is allowed to execute the function. A business rule contains words such as “if,” “when,” and “then.” A nonfunctional requirement is any requirement that is not a functional requirement (including business rules)	如果信用分＞70，系统审批通过
业务规则		如果信用分＜70，使用以下算法决定是否审批通过
非功能性需求		接收审批申请后，30s内完成审批
业务问题
业务目标	业务目标是用于说明业务问题被解决的可度量目标。 可度量的目标。 可以用业务目标来说明业务问题被解决了，即完成了业务目标，就解决了业务问题。 Business objectives are the measureable targets that specify when the business problem is solved

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

软件需求是什么？

软件需求指，软件的消费者向软件提出的要求。

软件需求的来源？

需求是研发要实现的功能，是系统要提供的功能，没有一个模型能够完整地捕获需求，我们需要从各个层面去捕捉需求，确保需求的完整性。

需求可以从业务目标中得到——高层次需求，产品应当具备的高层次特征，以组成产品概念，满足业务目标。

需求可以从特征树中得到——基于高层次特征分解得到的低级别特征，用于支撑高层次特征、补充高层次特征。

需求可以从业务流程中得到——基于业务实现的角度得到需求。

需求可以从用例中得到——从用例实现路径中得到需求，但这种需求是隐性在用例描述中的，不是显性的需求。

 

各个模型识别的需求的关系？

模型之间识别的需求不是渐进明细的，而是相互独立的，之间的关系有重叠、补充。

（1）并不是说从业务目标导出的需求就是全的，业务目标导出的需求不一定会包含用户使用系统的需求。

（2）并不是说从用例导出的需求是全的，毕竟用例也是从其模型（角色清单、流程图、业务数据图）中发现的，用例导出的需求侧重的是用户与系统交互层面。

（3）特征树组织的需求与用例导出的需求不存在 包含与被包含关系。

 

 

 

1.需求建模

1.1需求建模基本概念

1.1.1需求建模的职责

需求分析人员作为中介，连接需求提出者、需求实现者（需求提出——需求分析——需求实现），需要服务于两者：

1.告诉需求提出者（业务方）：为了完成目标需要进行什么活动，需要资源、多久完成。

2.告诉需求实现者（研发）：要实现业务目标需要完成的活动，需要服务哪些用户，开发哪些功能。

1.1.2需求建模工作内容

从业务需要进行层层建模，最终得出需要什么样的软件，层层解剖下，可能会涉及到研发认为是设计领域的东西，但这些都是为需求服务的，加深团队对项目理解的。（低层次的设计师服务于高层次的需求的。因此每个层次都可以看做是下一层次要实现的需求；是为了实现上一层次所完成的设计。）

层层建模：业务目标建模、人员建模、系统建模、数据建模 

每个层侧的建模都始于一个特定的绑定模型，绑定模型是对该层侧的目标、范围进行建模的，框定了范围。

1.1.3需求建模并不是重点

需求模型只是提供了方案的具体场景，以及需求的全貌，需求模型不能够直接为开发、测试人员使用，需要再从需求方案中提炼出需求清单。

模型的价值在于组织需求，帮助读者理解需求，确认是否有遗漏、错误的地方。

1.2模型分类（边界模型 bounding models）

类型	类型描述	具体模型	具体模型描述
目标	描述系统业务价值 提炼系统特征 对特征进行优先级排列	业务目标模型 bounding model
		特性树
		需求映射矩阵
人员	描述 使用、维护系统的人员	组织架构图 bounding model	和新开发系统相关的人：使用系统的人，维护系统的人
		业务流程图
		用例
		角色权限矩阵
系统	描述方案中： 1.有哪些系统 2.用户界面是什么样的 3.系统之间是如何交互的 4.系统是怎么运行的	生态系统图 bounding model
数据	从用户角度描述业务数据对象之间的关系 业务数据对象的生命周期

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

2.业务建模

2.1边界模型_目标模型

2.1.1业务模型模板

 

最初的业务问题可以是多个！

最终的结果一定是产品特性！

2.1.1.1案例

打印机公司管理层正在思考公司的财务问题，他们发现一些产品线的利润率正在下降。进一步调查发现，利润率下降的原因是，客户中心为了应对客户咨询，储备了大量的客户服务人员。

 

 经过进一步讨论，管理层决定将180客户中心雇员转移到能够产生收入的部门，以实现降低客户中心的人力成本。然而，如果将这180名员工转移走，客户中心需要每周少处理3000件客户咨询，否则，这180名是无法转移走的。基于这个新目标，管理层建立了一个问题-目标模型。

 

 分析师会问，“当前，是什么原因阻止我们实现目标？”，在分析呼叫中心的数据后，管理层发现，人们打进电话来的原因主要有两个：

55%的客户打电话是为了需求解决他们新遇到的问题。

30%的客户之前打过一次电话，但当时问题没有得到解决，因此他们再打一次来确认问题是否被解决。

这两个原因形成了下一层级的业务问题。分析师帮助管理层识别了两个业务目标，如果两个目标实现了，业务问题将会得到解决。

 

 

 

分析师继续提问：“是什么阻止我们实现这些目标呢？”，答案是，没有在线系统来处理这些客户咨询。团队确认了能够减少呼叫量的产品的特性，他们确认了系统高层次的产品特性，

具备这些特性的系统将能够解决他们的业务问题。

 

 最终，团队一起确认了那些可以量化的业务目标，并对这些业务目标设定量化指标。

2.1.1.2案例分析过程

 

 

2.1.1.3实践过程中的错误

 

 

 

可以发现，这个问题目标链很有问题，目标就是直接解决问题，而没有对问题进行分析，找到原因，根据原因去解决问题。

 

2.1.1.4正确思考框架

业务目标不是简单地解决业务问题，需要先对业务问题进行原因分析，真对原因得到业务目标，再分析业务目标不能实现的原因，这个原因就是业务问题，。

 

因此以上模型的分析步骤是：

P确认业务问题→分析业务问题的原因→O针对原因设定目标→P影响目标实现的障碍（新的问题）→分析障碍的原因→O得出新的目标→P影响目标实现的障碍（新的问题）

 

2.1.2使用目标模型

业务目标模型应当在项目初期建立，最好是第一个创建的模型。并且在项目生命周期的整个过程中都去使用这个模型，以便关系人能够关注到解决方案的业务价值。

2.1.2.1提供关于项目价值的共识  providing a common understanding of a project‘s value

业务目标模型提供了一个思考框架，以便众多相关者对项目背景、目标、价值形成共识。

• 首先，从业务目标模型出发推导需求，就能保证这些需求是用来支撑业务目标的实现，确保需求的合理性。管理者可以使用这个模型来验证他们所投资建立的系统是否正确。  

（When the stakeholders focus on the Business Objectives Model frst, the requirements that are described from the other models will be the right ones to support the specifc business objectives Executives can use this model to validate the investment they are making ）

• 其次，为了使模型更容易使用，业务模型将项目价值汇总在一个页面，一目了然。

（The structure of the model allows the project value to be viewed in one page for easy consumption ）

2.1.2.2界定解决方案范围

所有项目第一件要做的事情都是界定业务问题。

业务目标模型能够让所有相关方就要解决的问题达成一致。

基于业务目标模型，结合其他模型，能够确保项目只开发与问题、目标相关的产品特性，清晰、准确业务目标模型能够帮助所有的相关方理解决方案的范围。

2.1.2.3理解正在实施的项目

大多数项目都不会建立业务目标模型，更不用说每天对问题进行例行讨论。

如果你被派去加入一个这样的项目，很自然的会陷入懵逼状态，通过构建当前项目的业务目标模型，可以让你认识到项目要解决的问题，项目要实现的目标，以及要开发的产品的高层次特性。（）

（1）识别需求的典型错误方法：跳过问题、目标，直接形成产品概念

 

 如上图所描述，大多数项目都是从已经成熟的产品概念开始的,（因为产品概念是从老板那得到的，或者是直接拷贝竞争对手的产品，并不是从业务问题、目标着手），直接开始需求定义与需求设计这一步，缺少了问题、与目标的指引，产品概念是不稳固的，没有依据的，团队无法把握产品概念的来龙去脉，容易偏离业务目标。

这是一个非常麻烦的情况，如果业务分析师直接基于产品概念中的高层次特性去推导需求，极有可能会出现下面的问题：

• 开发一些不必要的需求，没有业务目标指引，很容易会提出来一些与目标无关的需求。
• 当不必要的需求被提出来以后，团队很可能发现预算、时间不足以支撑，但离开了项目问题、目标的指引，无法对需求进行裁剪，因为不知道每个需求的定量业务价值。
• 即使需求与业务目标保持一致，但缺少对业务问题的理解，业务目标本身也有可能是错的，基于错误业务目标得出的解决方案最终也无法解决业务问题。例如，在一个保险公司中，因为项目团队认为业务目标是将7个系统整合成一个系统，但业务团的实际业务目标是将7个业务团队合并成一个团队，通过一个统一的团队、统一的流程来替代目前的独立团队、流程，来减少工作重复、不必要的工作。在这个案例中，系统整合是多么容易的一件事情，做一个单点登陆就可以了，但流程并没有被整合，业务目标并没有被实现。

 

（2）识别需求的理想方法：从业务问题、业务目标触发

 

 

 在理想的情况下，项目从业务问题出发，通过分析原因得到业务目标，再基于业务目标分析出实现目标所面临的问题，再对新的问题进行分析出原因得出新的目标，如此迭代，最终得到底层的业务目标，并得出高层次的产品特性，基于产品特性得到高层次的产品需求，并逐层分解。

上图模型的缺陷是，这种方法并不反映实际情况，大多数组织对项目的思考并不是自顶向下的，可能是下面提问题、背景，产品概念，上层来决策是否可以做；项目分析师通常是在产品概念产生以后才加入项目的，无法从一开始就接触到项目，很可能接手时只有一个产品概念，无法了解到业务问题与业务目标。

（3）更贴近实际的方法

 

 

很多项目以一个产品概念作为开端，原因是业务分析师在这个产品概念阶段才加入项目，因此，对于业务分析师来说，理想中的从业务问题开始一个项目的场景是几乎不存在的，但是仍然可以在这个阶段构建目标模型。

当从产品概念阶段开始项目时，一些需求已经被定义了（上图 original requirement）。但是，从产品概念这一步往回做起，我们仍然可以得到并理解业务问题，事实上，业务问题、业务目标可能已经有了，只是没有被记录下来，我们可以向相关人员提问，来得到业务问题、业务目标，当我们得到业务问题、业务目标后。

通过业务问题、业务目标，相关人员可以重新定义一个产品概念、高层次产品特性，这个产品概念、特性有可能与最初的产品特性相同、也有可能不同。基于新的产品概念、高层次特性，我们可以分析得到新的成功指标，需求。最终得到的需求可能和原始需求相同，也有可能不同。

通常如果是从产品概念开始着手项目的，进行业务问题、业务目标界定，得到的产品概念，产品特性通常与原产品、概念会有所不同，因此有必要尽早地开始这项工作。

2.1.2.4获取需求

业务目标模型阐述了高层次业务目标，直接从业务目标推导需求是很困难的，但是业务目标模型记录了产品特性，这与高层次的需求是一致的，使用产品特性，可以组织详细需求：扩充、完善、分析高层次产品特性来得到具体的需求。

2.1.2.5什么时候使用目标模型

因为业务问题、商业机会而需要开发新的功能时，都应当时候目标模型，来引出产品特性。

包括以下场景：

（1）全新的客户需求开发场景。

（2）对旧项目进行功能扩展。

2.1.2.6什么时候不使用

当项目只需要开发新一个新系统替代原系统，并保持原系统功能特性时就不需要使用目标模型了，KPIMS更合适。

2.1.2.7错误运用模型

（1）错误说明业务目标

业务目标应当与货币紧密相关，是业务性的描述，一个常见的错误是将产品概念当做业务目标。在上面的保险案例中，业务目标被记录为“将7个系统整合在一起”，这其实是个产品概念。

真正的业务问题是7个业务团队的人员工作都是特异的，一个团队不能处理其他团队的业务，这个问题的可能原因是，这些团队的人使用了不同系统进行训练，业务目标应当是7个团队的成员可以互相支撑，产品概念是一个将原有7个系统不同流程的工作整合的新系统。

（2）业务目标不可测量

（3）不理解业务问题

2.1.3创建业务目标模型

从问题触发，分析导致问题的原因，得到目标，最终定义实现目标的产品特性

 

（1）业务问题

 业务问题有高层次、低层次之分，但不管如何业务问题都应当是个问题，通常是否定形式的，太高、太多、不能xxx，无法xxx。

业务问题是stakeholders的，不是一个人的问题，可能是多个人多个问题。

 高层次业务问题：与收益、成本相关的，组织是盈利的，如果问题不影响成本、收益，那就都不是问题。

低层次业务问题：业务过程中，遇到的具体问题，业务上的困难。

（2）业务目标

业务目标有高层次、低层次之分。但不管如何，业务目标应当是可以衡量的。

• 高层次页
• 其中最低层次业务目标，应该与系统相关，表述为：“使用系统完成XX业务目标”，基于这一表述，在与系统相关的最低层次目标基础上，推导出产品应当具备的特性。

（3）产品概念

 包含的是高层次产品特性，模块级别的，如账户管理，请求监控，而不是简单的增、查、改、删功能。

 2.1.3.1识别业务问题

组织发起项的目的通常都是为了解决业务问题，即使发起项目时，没有明确地提出业务问题，但也是大致的问题而提出产品概念的。

尽管在许多项目中，相关方并没有就业务问题形成共识，但几乎所有的业务问题都可以被最终划分为增加收入、减少成本。

（1）增加收入

与增加收入相关的业务问题通常不会被业务方声明的那么直接“增加xx产品收入”、“我们要赚更多的钱”，而是以间接指标的方式表达出来“提高客户满意度”、“提高客户复购率”、“培养客户消费习惯”等等。

（2）减少成本

业务而关于减少成本的业务问题会说得比较直接了“我们的客户支持团队成本太高了”，但也会用成本指标来说明，如所需工时，采购费用，耗时等等。

（3）合规需求

合规需求指业务需要满足一定的法律、法规、行业规则，这些规则也是业务问题。

（4）引出业务问题

业务问题与业务目标构成了业务问题-目标层次结构。（业务问题也有高层次、低层次之分，在组织高层眼中，高层次问题与成本、收益、合规直接相关，在低层次人员眼中，低层次业务问题与具体的业务相关，做什么事情遇到了什么困难，如客户咨询太多了，忙不过来；如工具太少了，效率低）

在结构的顶层，业务问题应当与降低成本、增加收益直接相关；但在低层次，业务问题、目标仅与上一层次业务目标有关，不一定与钱直接有关：一个功能需求，乃至一个较大的功能特性所对应的业务目标、业务问题并不和钱直接关联，但我们向上推导，总能将这个业务问题归于解决降低成本、提高业务收益之中。

引出业务问题通常需要和相关方，尤其是管理层讨论，是什么因素导致收益降低，成本增加。

如果业务方找到你时，他们自认为已经知道要做什么产品，或要完成什么业务目标，为了构建完整的业务目标模型，那么你要做两件事，找到业务问题、找到业务目标：

第一，从产品概念出发，沿着层次结构向上找到与增加收入、降低成本直接相关的最顶层业务问题；

第二，从业务目标出发，验证层次结构向下，找到与产品概念直接相关的最底层业务目标。

以下的例子显示了从产品概念推导出业务问题：当前组织正在建立一个web为客户提供自助服务，你在接触到这个项目时，需要与管理者进行讨论来识别发起项目的业务问题。

Q1：为什么我们要建立一个自助服务网站？

A1：这样，客户可以在网站上寻找解决方案。

Q2：为什么我们希望客户在网上寻找解决方案呢？

A2：我们的客户支持团队太忙了，已经不能支持每个客户咨询。

Q3：那为什么我们不雇佣更多的员工来处理客户咨询呢？

A3：因为人工成本太高了，新增雇员会导致产品利润率下降。

在A3中，分析师识别出一个关于成本的顶层业务目标。公司建立自助服务平台的最终目的是为了减少客户支持团队的成本。这意味着除了建设自助服务平台外，项目团队应当明确，项目应当聚焦于减少咨询数量的特性。　

很显然，建立自主服务平台的目的是为了减少成本，但在项目实际开发过程中，项目团队很容易忘记项目是为了减少客户咨询量来减少成本，而非功能本身。如果项目团队不能始终关注项目问题，项目团队可能完成了既定的任务，但却没解决业务问题。

 

你在识别业务问题时，很可能会遭遇到业务方的一些阻力，业务方会说，“这太浪费时间了”、“这不是显而易见的嘛，不需要我们再强调了”之类的。但是，正确认识业务问题是十分必要的：

• 整个项目团队如果对业务问题有更深入的了解，那么他们将会作出更好的决策，他们会产出更好的解决方案，而非仅仅实现业务方的产品概念、业务目标。
• 基于业务方现有的产品需求，回过头来了解清楚业务问题，有可能会推导出业务方需求的不合理，这可以让组织减少在无效方案上的资源浪费。

2.1.3.2识别业务目标（Identify Business Objectives ）

 

2.1.3.3定义其他的业务问题与目标

 

2.1.3.4定义产品概念

 尽管业务目标不讨论特定的实现（最底层业务目标表述为，使用系统来完成XXX业务处理），但产品特性需要讨论方案的实现，因此产品概念需要描述解决方案的愿景，产品方案包含为了实现底层业务目标而构想的高层次产品特性（为了实现XXX，系统应该能够XXX）

• 产品特性是产品为了实现业务目标而应当具备的功能集的简单描述——特性是描述一组功能的；特性应当简短；特性是用于实现业务目标的。
• 特性是需求的集合，特性用于组织、阐明需求——特性是高层次的，对特性进行分析，可以得到需求。
• 特性可以被制作成一个列表，帮助不了解项目的人形成对方案所交付功能集的本质认识。

 

 

2.2目标链

2.2.1目标链模板

 

2.2.2使用目标链

 

2.2.3创建目标链

 

2.3关键指标模型KPIM

 

2.4特征树

 

特征是解决方案的功能区域的简称，一个特征包含了一系列相关的功能。特征是需求的合集。

2.2.1特征树模板

 

 

2.2.2特征树用途

（1）描述项目范围depict project scope 

一个需求清单让人无法看懂，不知道有没有全，不知道有没有遗漏，不知道包含哪些类型需求。而特征树将需求分类组织，可以让相关人员检查需求是否全面。

（2）组织需求搜集活动

可以使用特征树来组织需求搜集相关活动：

• 在转移到特征树下一个分支之前，团队可以充分识别一个L1分支的全部需求，然后在转移到下一个分支。
• 在敏捷项目中，可以将特征树转换为产品待办事项，以便确认这些待办事项的处理顺序。
• 特征树将完整的解决方案拆分为多个部分，使得团队能够一块一块讨论，并最终将这些部分组织成一个完整的解决方案。特征树尤其适用于大型项目，这些大型项目无比复杂，团队很容易走偏，如果没有特征树，很难想象一个10人的团队如何组织工作。　

（3）组织需求

• 特征树中的分支，以可交付物方式（特征）来组织需求，这是组织需求的的基本方式，信息以特征的方式被分组。需求按特征进行组织。

　　The divisions in a Feature Tree are an essential way to organize requirements in deliverables so that the information is grouped by feature.

　　In a requirement deliverable, all of the requirements for an L1 feature and its subfeatures can be grouped together, and the same is true for the next L1 feature,

　　and so on.

　　For the example discussed earlier, there could be a full set of models and requirements  for Account Management and another for Access Management.

• 在需求映射矩阵中会用到特征树中的特征。

 

（4）获取需求

特征图是在较高层面统领需求，可以用来捕捉，组织需求，特征图中的需求应当是完整、全面的，特征图中的需求通过业务流程、用例、系统流程反映出来。

• 特征树能够识别其他RML模型的缺失（流程图、用例），即特征一定会体现业务流程图、系统流程、用例上，而这些rml模型是用来获取需求的，——如果特征树上有些特征没有被覆盖，那么就有可能是缺少了流程、用例。

• 逐条审查特征树上的特征，查看是否应当为特征创建用例，如果不是用例，那么就一定是系统流程。（一种特征他的消费者必须是 用户、内部系统中的一个）
• 逐条检查用例清单上的用例，查看是否有对应的特征，如果有用例，没有特征，那说明特征缺失了。
• 当特征树被构建，需求被组织起来以后，通过查看一些需求特别少的特征来捕获需求。

（4）何时使用

　　特征树适用于绝大多数项目，在这些项目中用特征树来组织需求，并开展顶层交流。

（5）何时不适用

　　只有在采购成熟产品的实施过程中，特征树才不那么有作用。

（6）典型错误

• 错误的特征数量

　　在任一一个层级上，为了保证模型的可用性，特征的数量都应当在控制在5-9个。

• 错误的特征名字

　　尽管这听起来很奇怪，但给特征取名不是一个简单的活。取名的一个关键是，特征的命名格式应当一致，这样就便于理解，如果如果有些特征被写成名词，有些被写成动词，会使读者混乱。特征应该被写成2-3个单词的名词短语。

2.2.3创建特征树

 

（1）识别特征

• 在创建业务目标模型时，会生成产品概念，产品概念中包含了高层次的产品特征。
• 在高层次产品特征基础上，需要努力找到同层次的产品特征，并为每个高层次的产品特征分析下属产品特征。
• 在识别产品特征时，一定要考虑到终端用户的功能，管理型需求，系统间交互。
• 用例多数为操作数据，因此要考虑到数据管理方面的特征。
• 系统间交互也是一种特征。

 （2）组织特征

 

（3）创建特征树

（4）寻找未发现的特征

 2.3***需求映射矩阵

需求映射矩阵将模型中的信息映射成功能性需求、业务规则。

需求映射矩阵中包含多种层次的映射。最有用的映射是“从业务流程到需求的映射”，“以及需求到业务规则的映射”。

 2.3.1需求映射矩阵模板

 

 

 

 2.3.2使用RMM

（1）使项目方案更容易阅读

RMM完整地展示了从确定业务问题到形成完整解决方案的过程。是一个非常关键地表，通过这个表将方案串联起来。

（2）识别漏掉的需求

将流程流步骤映射到需求是正向映射，并用于在RMMs中执行验证。

如果流程中的步骤没有对应的需求，意味着在解决方案中这个步骤是不充分的，不会被正常实现。这意味着需要创建额外的需求，以使流程流正常工作。

（3）发现需求

3.人员建模

3.1组织结构图（人员建模边界模型）

3.1.1组织结构图概述

• 组织结构图用来确认 使用软件的人，以及对方案有影响的人。
• 组织结构图识别的是组织内部使用者。但实际上系统还有外部使用者，组织结构图无法组织这些外部使用者。

系统外部使用者（组织外的用户，如天猫的买家、卖家都是外部用户），不能通过组织结构图来表示。

有3中类型的组织结构图

• 部门组织结构图，这是最常见的组织结构图，也是最重要的组织结构图，结构图中的元素是公司的部门，如财务部，资金部，核算部，报表部
• 角色组织结构图，
• 人员组织结构图，

3.1.2组织结构图的用途

 ()获取需求

组织结构图无法直接用来获取需求，但通过组织结构图，分析师可以知道，要和谁去交流去获取需求。

（Requirements are not usually derived directly from an Org Chart Instead, Org Charts are used to ensure that you capture all stakeholders whom you need to interview for requirements ）

 

3.1.3创建组织结构图

 

3.2业务流程图

The Process Flow is an RML people model that describes a business process that will be executed by people .——"将要"由人员执行的业务流程，系统上线后，为了完成业务，人员需要执行的业务流程，人员通过哪些活动（包括与系统交互）来完成业务处理。

系统提供功能以实现业务流程，最终来实现业务目标。业务流程是为了实现业务目标的，因此，只要是给业务人员用的系统，都有必要创建业务流程图。

• 业务流程图描述的是系统用户在系统上完成哪些业务流程步骤来完成业务目标的，是描述系统上线后，使用系统的逻辑。

　　　而不是描述在系统完成之前的业务流程，这他妈的完全没必要，方案应该只展示方案要实现的东西。

　　　　（业务流程图的元素有用户、活动步骤step、活动关系，既然用户就是系统的用户，那么活动步骤必然是这些用户在系统上要完成的业务任务）

• 业务流程图是有层次的，L1是最顶层流程图，展示用户使用系统完成业务的全流程，对于小项目，小功能而言，L1级别的流程图已经足够了，可以从L1流程中直接提取用例。

　　　　对大项目而言，L1包含的信息太多，可以将其细化为L2流程图

• 创建一个流程的时候一定要对流程进行定性

　　　　是一个L1流程？还是L1流程中某个步骤的L2流程？——重点看是否是端到端业务流，还是只是一个业务过程的某个部分，

　　　　流程中的每个任务步骤是否已经够细致了，可以作为用例进行分析了？还是说这个流程任务仍然很大，需要进一步创建L3流程？

3.2.1业务流程图概述

 

 

 

 

•  业务流程图强调的是人执行动作，关注的是人要做哪些事情，不关注系统自动执行的功能，其中人操作系统也是一种活动，因此一定要明白，L1、L2、L3中的步骤可以是人去操作系统完成一项任务。实际上人完成任务既可以通过系统，也可以不通过系统。
• 一个公司有许多业务，每个业务从端到端都可以形成一个L1级别的流程图，对L1中的一个步骤，可以分析得到该步骤的L2流程图，同理根据需要可以得到L2中某个步骤的L3流程图。

3.2.2使用业务流程图

3.2.2.1为不同层次的用户提供项目信息

L1层次是所有干系人在一起执行一个宏观层面的业务，是一个顶层流程图。适用于大会。

L2层次是对某个人的某个L1 step进行详细说明，适用于一对一沟通。

3.2.2.2推进项目完整性

流程上

流程步骤上，让关系人在步骤范围内思考

3.2.2.3获取需求

流程图是推导需求，以及组织需求的有效工具，功能、需求、和业务规则都可以从业务流程中获取。但业务流程无法识别数据需求，非功能性需求，以及未包含在流程图步骤中的业务规则。

可以从L2、L3流程图中直接获取需求。L1层面的流程图太大，只能获取用户任务，职责，无法直接提供需求。

通过流程图获取需求前，需要确保流程图已经拆解到最低层次，最低层中，每个步骤相关的需求最好在控制在5-9个之间。

（If the Process Flows were done at the right level, as described previously, each step should have only 7+/-2 requirements associated with it） 

应当从最低层次的流程图去创建需求。功能性需求可以直接从最低层次的steps获取。

•  A Process Flow is a great tool for deriving and organizing requirements Features, requirements, and business rules can all be derived from Process Flows。

　　Note that Process Flows are not as helpful in identifying data requirements, non-functional requirements, and business rules that are not encapsulated in steps As the requirements and business rules are derived 　　from the steps, they should be associated with that process step in a Requirements Mapping Matrix (see Chapter 7, “Requirements Mapping Matrix”).

• Before beginning, make sure that the lowest-level Process Flows are detailed enough for deriving requirements，   If this is not the case, consider producing another level of Process Flows to learn even more detail about the process If the Process Flows were done at the right level, as described previously, each step should have only 7+/-2 requirements associated with it 
• You should derive requirements from the lowest-level Process Flows that you have created。Because the low-level Process Flows map back to the L1 Process Flow, all of the requirements will maintain that mapping as well.     Functional requirements are derived directly from the process steps, and business rules are derived from the decision steps and requirements Process Flows will generally not provide enough granularity to allow you to derive all of the business rules, but they will provide a start and then will point toward areas where additional business rules might be needed 。

• It is often tempting to write just a single requirement for each process step, but in most cases this is not suffcient to properly defne the system. However, if a process step is mapped to more than 7+/-2           requirements, it probably needs to be split into two steps

　　　　一方面，每个步骤step创建一个需求是十分诱人的（轻松，简单），但这通常不足以充分地定义系统； 潜台词就是每个步骤都要考虑充分，一个步骤不是那么简单的。

　　　　另一方面，如果一个流程步骤有5-9个需求，那么应当将这个步骤划分成2个步骤。  如果步骤相关的需求太多，就要拆分步骤。

　　　Try asking some of these questions about each step to fnd more requirements and business rules:

　　　　--What needs to be done before this step takes place?
　　　　-- What are the different possible outcomes from this step?
　　　　-- What possible error conditions might come out of this step?
　　　　--When this step is complete, what is triggered to let others know that the step is complete?
　　　　--What parts of the step are initiated by the user, and which are triggered automatically by the  system?
 　　　　--What rules are evaluated at this decision step?
　　　　--What are the possible outcomes emerging from this decision step?
　　　　--What calculation is performed at this step?

When writing the requirements, include enough detail about the context of each requirement, in case someone is implementing or testing the system without looking at the Process Flows 

3.2.3创建业务流程图

应当在项目早起创建L1流程图，来展示项目流程的完整范围（项目L1不一定是企业的顶级业务流，如财务部门要建立一套报销系统，这个L1就是报销的流程，而不是企业的进销存顶级流程）。以便基于L1流程创建其他更多的流程，L2、L3，并与业务方绘制出与解决方案相关的最顶层活动  highest level of activities that defne the full solution

L1流程步骤应当越简单越好，不要超过20个步骤。

3.2.3.1创建L1业务流程图

（1）创建流程：

当顶层活动被识别以后，将他们放到流程图中，并用箭头连接。

• 一个易于理解的L1流程图应当使各个L1顶层活动具有相同的细节。千万不要出现一个活动很细节，一个活动很抽象，这样读者就需要在抽象与具体之间来回切换，这很容易让读者抓不住重点，陷入混乱。
• L1流程图体现的是一项业务的最顶层流程，通常不包含决策分支，因为L1中的每个活动都很大，足以包含分支信息。如买票的L1流程就是，查票→购买，至于有没有票是被包含在查票步骤中的。

L1流程中的步骤应当被表述为：<verb> + <object>  

为每个流程编号，以便和对应的L2、L3系形成层次结构。

（2）Level1流程图的范围：

  在L1流程图中，应当展示完整的端到端流程（所有活动的起点、所有活动的重点），以便提供项目范围级别的情景，业务的来龙去脉，L1是最大的流程图。

L1流程不完整、稳定前，不要创建L2流程。

3.2.3.2创建L2业务流程图

当创建并评审完L1级别的流程图后，着手绘制L2级别流程图。基本上L1流程图中的每个用户活动都有对应的L2流程图。但以下情况例外：

• L1流程步骤不在项目范围内，那就无需为这个L1 步骤创建 L2流程。
• 多个L1流程步骤很简单，可以合并在一起用一个L2进行细化。

（2）识别流程步骤

• 举办引导会议

　　与这个L1活动步骤的用户代表交流，让他来描述这个L1可以被分解为怎样的L2流程。

• 观察

　　到现场观察，L1活动是怎么完成的。

• 场景模拟

　　想象自己是如何完成这个L1活动的。

• 查看现有的流程图

（2）写出流程中的步骤

在识别出某个L1对应的全部L2活动，并且确保这些活动是一个维度的后，就需要为这些活动命名，

L2活动通常格式为“[user] + <action> + <object> + [in system]”，xx用户在系统上做了yy事情。

有些时候会将[user]、[in system]省略，主要场景为：

如果L2活动只有一个用户来执行，那么就省略user

如果L2活动都在一个系统中完成，那么省略system

（3）创建泳道

 如果在同一个L2流程中有多个用户users，使用泳道可以很好地区分不同用户的活动。

如果在同一个L2流程中只有一个用户，那么就不需要使用泳道。

如果一个L2中只有少数用户（2个），也可以不用画泳道，在活动方块上 把user说明。

3.2.34根据需要创建L3流程

如果L2流程图需要进一步说明，细分，那么为L2流程图中的步骤创建一个流程图，这就是L3级别的流程图，如果L2中，步骤过多，就可以将一些L2抽象成一个步骤，并为这个步骤提供L3流程图。

 L3流程中的步骤基本就是业务用例

The next level of detail beyond L3s can be Use Cases 

3.3用例

3.3.1用例概述

用于描述系统对用户提供的功能（外部用户可见的系统功能），一个用例具备一个完成的功能，而不是功能中的某个步骤。

用例的表述形式为“”通过系统创建订单”，由于默认是通过系统实现工作，因此把“通过系统”省略，表述为动宾短语“实现XX”。

用例只是代表用户通过系统完成的任务，没有展示系统要为用户提供的功能细节，实现方案，因此要对用例进行分析，从系统功能层面描述系统如何提供服务的。

通过用例分析可以拆解出功能清单，这些功能清单为用户实现用例。

3.3.2用例作用

（1）提供业务实现方案

用例是聚焦在某一个actor的某项任务上的，对于actor来说，能够聚焦在这个任务上，一步一步，循序渐进地创建业务流程。

Because Use Cases describe interactions from the user’s perspective, in a step-by-step fashion, they are easy for business stakeholders to review Business stakeholders can easily envision themselves at each step in the Use Case, and they have to consider only what comes next, which minimizes mental juggling of information 

（2）获取需求

 用例可以直接用来发现功能性、非功能性需求：

在用例说明的路径（main course）中，基于用户行为的系统执行步骤可以转换为传统意义上的功能性需求描述。

（Use Cases can be used to derive functional and non-functional requirements directly—the actions taken by the system based on user actions can be converted into traditional functional requirement statements about what functionality the system must support）

用例图代表了系统的特性，组织了需求；用例描述中的路径步骤可以解析出功能需求、非功能需求。

• 用例中的每个步骤是否有对应的系统功能来支撑，如果没有——这就是个需求。
• 如果用例中有语句：如果..就..——这就是业务规则。

（3）用例通常用来确认开发工作的优先级，

 由于用例捕获了操作对用户的组织收益organizational benefts ，可以用组织收益来确认与用例相关的需求的开发优先级。 

（4）重复利用用例

（5）用作验收测试

3.3.3用例使用场景

（1）什么时候该用

想要更清晰地展现用户与系统交互流程时，需要使用用例。用例能够承载大量关于用户与系统交互过程的信息。

在L3层级的业务流程中，使用用例。因为用例展现的多为L2、L3层面的信息。

（2）什么时候不用

当要表达的是系统与系统之间的交互时，不要使用用例，系统流程图更合适；

当要表达的是复杂决策流程时，也不要使用用例，决策树更合适；

3.3.4用例的错误使用方法

（1）用例的粒度太大

用例粒度太大，以致于用例中包含过得的细节，使得读者无法理解actor的任务目标。——用例太大了，包含了很多目标，读者很闷逼，不知道actor到底要干啥。

用例是用户操作和预期行为的高级表示，目的是向用户验证交互是否适合她的需要，并为开发人员提供实现路径。

（2）只用用例作需求说明

一些组织试图将用例作为需求说明的唯一方式。

但这显然是错误的，如果仅适用用例，那么用例就需要包含功能需求、业务规则、非功能需求信息，用例变成了各种信息的混合体，这使得

• 需求很难被跟踪，因为需求全揉在用例中了。
• 很难确认需求是完整的，分散在用例中的需求不能被分类展现，读者无法确认实现用例就实现了完整的需求。

　　（这句话太对了，一些非功能性需求是无法放在用例中的，因为他们和用户的任务无关，如安全性、可靠性、负载均衡；）

（3）将系统作为actor

用例是用来展示 actor的动机、行为、以及期望获得的系统反馈。

The purpose of Use Cases is to help the reader understand the motivations, actions, and expected results of an interaction with the system

系统永远不可能作为一个actor没因为系统没有动机

The system is never an actor because it does not have
motivations  

（这太他吗对了，有的书中，经常把其他系统也当做用例，这太扯淡了，可以使用系统流程图，决策树来做）

另外一方面，如果将系统作为actor，那么用例就变成：一个系统 与 另一个系统的交互，产生结果，这就变成了一个系统过程，那只需要使用系统流程图就行了。

If the system is the actor, the Use Case simply becomes a series of system steps. Use a System Flow to diagram system-only flows 。

3.3.5获取用例

（1）从业务流程图中得出用例

• L1从宏观角度描述在解决方案中的业务流程（L1是规划后的业务流程图：可能保持不变，只要系统支持其中的步骤，也有可能比现有流程优化），多个角色配合完成一项工作，每个人负责工作中的一部分，是一个人的工作职责。L1流程图中的某个步骤可能是一个角色的全部工作内容，粒度比较粗，直接作为一个用例会十分复杂，需要进一步拆解为L2流程图。
• L2、L3流程图对某个泳道角色L1任务进行分解，能够得到每个角色更具体的任务，这些任务需要被系统支持，L2、L3中的步骤有时候可以直接就是用例；有时候需要对L3进一步拆解，得到用例。　　 

              Use Cases often are used to detail the process steps of L2 or L3 Process Flows 

• 如何粒度合适，L3级别的流程图中，每个步骤可以作为一个用例，L3级别每个步骤描述上依然需要保持是业务活动的形式（业务活动可以是和系统交互得到业务结果），尽管步骤会很细。
• 如果L3中的步骤过于详细，没有必要创建用例，那么可以将多个步骤合并成一个用例进行说明。

One way to brainstorm Use Cases is to frst identify all the possible stakeholders by using an Org Chart (see Chapter 8, “Org Chart”). Then identify L1, L2, and L3 processes by using a Process Flow.

Use Cases often are used to detail the process steps of L2 or L3 Process Flows （用例通常用来说明\L2,L3的步骤）

（2）从特征图中得出用例

系统的特性要么是系统自动运行的（自动化程序），要么就是与用户交互的（用户服务程序），特性图中提供给用户使用的特性就可以得到用例。

产品特征通常是“具备xx特点，能够实现xxx”，这些特征中，有一部分涉及系统提供给用户的功能，这是用例的一个来源。

Another way to identify Use Cases is to look at the Feature Tree (see Chapter 6, “Feature Tree”) 

Typically, features are simply shorter names of Use Cases （特征是用例的缩写）

（3）从角色职责中得出用例

• 尽管角色职责体现在业务流程中，但这并不完全，角色的一些职责往往并不体现在流程图中。
• 从角色职责中可以对流程图中得到的用例进行验证。

3.3.6用例说明

3.3.6.1写需求简述 Write Descriptions 

3.3.6.2明确用例的收益，Capture Organizational Benefts 

3.3.6.3用例使用频率

3.3.6.4用例优先级

3.3.6.5识别actor

如果用例是从 相关者直接分析得到，那么天然已经得到用例的actor，如果是从特征得到用例，那么就需要为用例找到actor。

3.3.6.6确认用例触发器

触发器是用例执行的系统条件，必须是能够被系统感知到的，因此不能将用户的意图，用户想要生成报表，这种描述作为触发条件。

Because triggers are the system’s cue to start the execution of a Use Case  they must be things that the system can actually detect, as compared to a user’s intentions 

3.3.6.7确认前置条件 preconditions

前置条件是用例被触发后，执行前必须要完成的检查，只有通过这些检查，用例才能被执行。

3.3.6.8确认后置条件 postcondition

 后置条件与用例描述中的用户目标是一致的。因此，后置条件一定是能够被用户观察、感知到的，来确认用例完成目标。

3.3.6.9确认主流程 main course

主流程描述了用户、系统执行的步骤，通过这些步骤，系统完成了某项任务，最终实现了用例描述中的用户目标。——路径中的是用户的行为、系统的行为

The main course describes the steps that the user and system take in order for that user to accomplish a task in the system, ultimately achieving the goal outlined in the Use Case description 

用例的主路径应当尽量控制在10-15左右，如果路径小于10个步骤，说明用太简单，无需使用用例来组织；如果路径大于15个步骤，这个用例就很难被理解，应当尝试将用例拆成两个用例，或者用一个L3流程图替代用例（可能里面包含多个用户任务，用L3流程图描述即可）。

When you are creating the Use Case’s main course, it is best to limit the length to approximately 10 to 15 steps If you have less than 10, it is quite possible that the Use Case is degenerate and did not need to be written at all, or that it is part of another Use Case If you have more than 15 steps, the Use Case is probably too complex to be understood, and it should be split into two Use Cases, or an L3 Process Flow should be used instead There are exceptions to this guideline, but it is a good one to follow for a rough sizing estimate。

主流程的第一步应当是系统对user case trigger的反映，trigger启动了用例，系统则作出响应。 

The frst step of a Use Case should always be a system step. It was mentioned in the previous section that the system needs to detect the trigger statement, evaluate the preconditions, and then start the Use Case. Therefore, the frst step of the Use Case is really the system reacting to the trigger step. 

3.3.6.10确认替代流程 alternate course

3.3.7用例关系***

用例之间为什么会有include、extend、generalization关系呢？答案是为了提高用例可复用性，减少用例复杂性，减少建模工作，编码工作量。

如何提高可复用性呢？

（1）将不同用例中的公共部分提取出来形成单独用例，多个用例共享；

（2）将复杂用例中的不相关部分剥离出来形成单独用例。

3.3.x.1关联关系

3.3.x.2继承关系

子用例继承父用例，子用例与父用例功能类似，但具备更特征的功能。

3.3.x.1包含关系

 使用包含（Inclusion）用例来封装一组跨越多个用例的相似动作（行为片断），以便多个基（Base）用例复用。

当某用例的事件流过于复杂时，为了简化用例的描述，我们也可以把某一段事件流抽象成为一个被包含的用例。

• 基用例控制与包含用例的 关系，以及被包含用例的事件流是否会插入到基用例的事件流中。
• 基用例依赖包含用例执行的结果，离开被包含用例，基用例就不完整。
• 用例划分太细时，也可以抽象出一个基用例，来包含这些细颗粒的用例。

业务中，总是存在着维护某某信息的功能，如果将它作为一个用例，那新建、编辑以及修改都要在用例详述中描述，过于复杂；如果分成新建用例、编辑用例和删除用例，则划分太细。这时包含关系可以用来理清关系。

 

 

 

3.3.x.2扩展关系

为了降低用例复杂性，将用例中的一个独立片段摘出来形成扩展用例。

将基用例中一段相对独立并且可选的动作，用扩展（Extension）用例加以封装，再让它从基用例中声明的扩展点（Extension Point）上进行扩展，从而使基用例行为更简练和目标更集中。

• 基用例独立于扩展用例，不负责扩展用例是否可用。
• 扩展用例依赖于基用例，需要使用基用例的结果。

例如，系统中允许用户对查询的结果进行导出、打印。对于查询而言，能不能导出、打印查询都是一样的，导出、打印是不可见的。导入、打印和查询相对独立，而且为查询添加了新行为。因此可以采用扩展关系来描述：

 

 

用例关系

 

 

 4.系统模型

4.1生态系统图

 

4.2系统流程图

4.2.1系统流程图概述

系统流程图描述了系统执行的活动，

系统流程图展示了系统的活动、活动间的顺序，以及系统逻辑。

系统流程图从系统角度出发，展示方案逻辑。

对于许多自动执行的任务，一些相关人员并不在意背后有怎么样的系统运作流程，只在乎拿到结果，他们会将这个自动任务抛给开发团队去解决。

但对于关心系统运作的人（开发人员、产品人员、架构），就需要用系统流程图，将这些自动执行的任务，或者有大量系统后台运行步骤的功能的流程描绘出来。

系统流程图通常与业务流程图有关联，在一个业务流程步骤中，用户发起了一个操作，系统经过一系列流程产生结果并将其返回给用户，在一个图中绘制出用户操作、系统运行并不是不可以，但通常会因为视角在系统、人员之间来回切换导致理解上的混乱。

4.2.2使用系统流程图

（1）数据需求，如报表

当读者非常关注系统本身的运作时，系统流程可以很好地获取与组织需求。

System Flows are great tools for deriving and organizing requirements.

• 数据需求
• 非功能需求
• 业务规则

4.2.3创建系统流程图

 

 

系统流程也有L1、L2、L3层次，系统流程并不一定是业务流程细化后得到的系统处理过程（虽然大多数场景下，业务流程细化到最低层级后，必然涉及到用户与系统的交互，涉及到系统进行一定的自动处理，返回用户一个响应）。

系统流程与用户流程经常是有关联的，在业务流程中，用户触发了一个系统流程，系统开始自动执行任务，并返回结果。

4.2.3.1识别系统流程步骤（Identify System Steps ）

尽管在系统流程图中可能会有一些用户活动，但系统流程图中的步骤是应当都是系统步骤（系统活动），而不是用户步骤（活动）。在系统与用户的交互过程中，用户活动触发了复杂的系统运作流程，因此可以将用户活动理解为事件，用户活动在流程图的泳道上应当作为触发事情来表示。

另外，

（1）特征树

　　特征树是识别系统步骤的一个来源，检查特征树上的L1特征，判断是否需要由系统自动，具有复杂系统执行过程的特征，这些特征的实现就需要使用系统流程图来描述。

 

（2）数据流程图data folw diagrams

 

4.2.3.2写出流程步骤

系统步骤的格式为  xx系统进行xx实现xx： [system] + <action> + <object> 

 

 

 

在哪里用系统流程图

1.如果任务本身就是全自动或者，是几乎系统后台工作的，那么就直接创建L1、L2、L3系统流程图。通常是数据分析、自动执行、自动任务功能。

2.如果是通过业务流程图L1\L2\L3 用例分解得到 一个包含用户行为、系统行为的用例流程图，就不需要使专门用系统流程图

3.除非用例流程图中，某一步系统动作非常复杂、非常重要，就可以针对这一步创建系统流程图。

4.2.3.x

（1）什么时候使用系统流程图？

　　当用户启动流程后，不在进行任何操作，等待系统执行一系列过程返回结果，这个时候用系统流程图来描述系统运行的过程

　　以及系统自动完成的任务。

　　　　when a complex set of steps happens after a user action, there is little or no user interaction 

　　　　如杀毒软件，点一下就杀毒了，杀毒过程就用系统流程图表示。

　　　　如资金清分，点一下就清分了，清分过程要用系统流程图表示。

　　　　如自动对账，点一下就对账了，对账过程要用系统流程图表示。

　　　　如爬虫软件，点一下就爬到数据了，爬取的过程要用系统流程图表示。

　　　　如利息计算功能，自动海量用户利息，过程就要用系统流程图表示。

　　　　通常数据处理功能、自动化的功能，都需要用系统流程图来表示。

　　　　或者当系统是“实时系统”或者是“嵌入式系统”（when the system is a real-time or embedded system ），“自动化系统”。

　　　　嵌入式系统：与硬件合为一体的系统，控制程序存储在ROM中的嵌入式处理器控制板，用于直接控制设备的，如手表、微波炉、录像机、汽车等，都使用嵌入式系统，有些嵌入式系统还包含操作系统。

　　　　实时系统：软件不仅强调逻辑的正确性还强调结果的实时（如信号灯控制系统，如果换灯指令未生成就会产生可怕后果），这类系统通常就是

• 用于描述系统在屏幕后执行的的复杂行为。
• 描述系统之间的交互。

（xx）相关模型

• 业务流程图：业务流程图展示了用户的活动，每个步骤都是用户的活动，这些活动会出发一个系统流程，系统流程完成后，返回处理流程。

 

特征、业务流程、用例、系统流程的关系

 

 

 

 

 

特征树一定会出现在业务流程图、系统流程、用例上。

 

 

4.3界面流程图 Interface Flow

 

4.4DAR模型，Display-Action-Response

4.4.1DAR模型概述

DAR显示-动作-响应是RML模型中的一种系统模型，用于获取与描述与UI系相关的需求与业务规则。

DAR模型可以很好地从以下两个方面描述未来系统界面：

（1）用户界面上的元素：Display

（2）用户在界面上的操作：Action

（2）系统对用户界面操作的响应：Response

使用DAR为每块屏幕上的UI元素建模。注意，是为某个屏幕上UI元素建立DAR模型。DAR模型是用于描述UI元素的，但需要先用原型图表示出这个UI元素在屏幕上的布局信息，即位置，样式。

（1）UI屏幕布局：每个UI元素在屏幕上的位置，元素的样式。

 

 

（2）UI元素表格：UI元素是指具备显示属性、行为属性的UI实体，如按钮、表格、复选框。每个UI元素都有对应的元素表。UI元素表包括UI元素描述、UI元素显示属性、UI元素行为属性

 

• 元素描述Description

　　　ID：UI元素的编码

　　　description：UI元素的简单描述，可以加入这个元素的截图

• UI元素显示Display

　　　描述了在不同情况下，这个UI元素是如何显示的（即UI元素有多种显示效果，以及每种显示效果的条件）

　　　　不需要对静态UI元素进行Display描述，只要描述那种在不同状态、条件下，具备不同形态的UI元素，

　　　　precondition，系统的状态；包括当前用户的状态，用户预先发起的动作，业务数据对象的值

　　　　display，UI元素的显示效果，可以放截图展示。如使用管理员登录，导航栏展示系统设置选项。

• UI元素行为Beahvior（aciton-response）

　　　　定义了在一定条件下，用户对UI元素进行操作后，系统的响应。

　　　　不需要对静态UI元素进行Behavior描述，只需要对具备不同形态，可操作的UI元素进行描述。

　　　　precondition，用户发起操作时系统的状态；action，用户对ui元素的操作；respose 系统对动作的响应。

 

 

 

 

 

 

 

 

 

 

 

 

元素行为
操作前提	操作	系统响应
任何状态	点击导航条	转跳对应页面

 

 

 

 

 

 

 

 

 

4.4.2DAR模型用途

 4.4.2.1获取需求

DAR模型可以用来获取UI相关需求：

• 可以使用DAR对每个UI元素的显示效果、操作响应进行描述，确保UI元素相关的需求没有被遗漏掉。
• 用户对UI发起的操作可以用来创建功能性需求。用户对UI元素发起的操作要么对应已经识别的一个需求，或者是尚未被识别的需求。
• UI元素的display、behavior可以直接当做功能性需求。
• 前提条件可以当做业务规则。

Each row in the display or the behavior section of an element table or the behavior section will map to at least one, but sometimes several, functional requirements and business rules 。

In most cases, the behavior and display rows actually can become the requirements, and you can simply copy them to your complete list of requirements 。

The preconditions translate directly to business rules and modify display and behaviors based on system data 。

4.4.2.2帮助用户理解系统

能够帮助相关人员快速地理解系统长啥样，能干啥。

4.4.2.3啥时候该使用

当你特别担心UI界面不能够正常使用，或者UI界面特别复杂，开发人员可能会做错时，可以使用DAR。

当你担心相关方不知道系统怎么用，无法理解系统时，可以使用DAR。

4.4.2.4啥时候不该使用

系统的用户比较少时，可以不适用，因为DAR太费时间了。

系统的没有用户界面（嵌入系统、实时系统、自动化程序、数据处理程序），可以不适用，因为DAR太费时间了。

一些静态元素很多的界面，或者都是文字性、图片的界面可以不用创建DAR