项目经理可用的110种商业分析工具和技术（上）

▍b.生态系统图：

显示了所有相关的系统，系统之间的关系，以及流经它们的可选的任何数据对象，这些系统其实是从商业角度来描绘的逻辑系统，而不是从实施角度来描绘的实际物理结构图。

生态系统图一般也用在项目初期创建，有利于理解所有的系统间的相互关联和影响关系，帮助识别项目集、项目之间的潜在依赖性；它还有助于发现直接与解决方案连接的系统，发现解决方案上下游系统在哪些地方可能存在接口需求或数据需求。

▍c.系统交互图：

显示了解决方案中的所有直接系统和人机界面，清晰地描述了范围内的系统和所有的输入或输出，包括提供输入和接收输出的外部系统或参与者。

系统交互图通常应尽早创建，它总结了产品范围和用来确定需求的相关信息，用以识别和明确接口需求和数据需求。系统交互图有时候被称为“0级数据流图”，它可以用于引导后续创建其他接口模型，也可以模拟现在和未来的状态以帮助进行差距分析。

▍d. 功能模型/特性模型：

用树状或层级结构排列，以可视化的方式表示解决方案的所有特性，在这样的层级结构里，顶层特性是第 1 级（L1）特性，其次是第 2 级（L2）特性，等等。特性模型有助于说明特性是如何组合在一起的，以及哪个特性是其他特性的子特性。

特性模型通常在项目初期开始创建，以显示项目集或项目范围内的所有特性，并且在启发和分析过程中识别附加特性时进行更新。在适应型项目中，特性可以在不同的迭代中加以标记以便于发布计划。

特性模型可与头脑风暴法结合使用，类似于亲和图，以帮助干系人通过关注分组来识别特性。这种模型通常不显示需求，而显示需求集；可以帮助确定如何为商业分析工作组织需求，或者如何展现需求；在功能模型里的功能也可用来跟踪需求，以确保没有遗漏的功能或需求。

▍e. 用例图：

显示了解决方案范围内的所有用例。用例是用文本叙述的手法来描述系统—用户的交互以成功完成目的的过程模型。

创建用例图包括识别解决方案的使用者和每个使用者将如何使用解决方案的可能场景清单。把用户和相关用例相关联，显示了用户和用例之间需要创建的接口，并且确定哪些用例在给定解决方案的范围内，哪些在范围外，这有助于管理干系人的期望。

同时，它也可以帮助项目团队在建立解决方案时规划和跟踪过程，概括功能的范围以及功能和参与者之间的关系，有助于为商业分析工作组织需求或展现需求。

▍f. 事件清单：

描述了触发解决方案行为的任何外部事件。事件清单帮助定义解决方案必须做出反应或处理的范围内事件，从而确保定义工作范围，并且随着工作的持续开展和新事件的识别而更新。

事件响应表是事件清单的延伸，用于描述系统对任何事件触发器的响应。事件响应表有助于识别（过程模型）用例、用户故事或系统流。

▍g. 组织结构图：

展示了组织内部或部分组织内部的报告结构，描述了整个组织的部门、部门角色或报告结构中的个人。

我们在进行干系人识别和分析时，可能也会用到组织结构图，在对需求分析期间使用的组织结构目的与之不同，主要是确定使用解决方案或受解决方案影响的人员，而这些人员不一定是那些与项目组合、项目集或项目紧密合作的人员，除此之外，我们还需要帮助识别有安全性和权限需求的用户或用户组。

组织结构图需要在早期被创建，并保持持续更新，以确保任何干系人或干系人群组的识别不会被遗漏。

这些就是常见的范围模型，范围模型通常在项目或者商业分析的早期被创建。

二过程模型

描述商业过程及干系人与其交互方式的模型。

▍a.过程流：

用于以可视化的方式，记录人们在工作中或与解决方案交互时，所执行的步骤或任务。过程流又名泳道图、过程地图、过程图或过程流图。

过程流可以分成多个层级，其中 1 级（L1）过程流可用 7～10 个步骤在高层级上显示完整的端到端过程；L1 过程流中的步骤被分解为用户将要执行的下一级过程，用 2 级（L2）过程流来表示。

过程流根据包含信息的不同，有几种变体：

总结起来说，过程流在商业分析活动中，经常会被使用到。在需求启发阶段，促进与干系人的沟通；分析过程中，跟踪需求的各个步骤，识别丢失的功能或需求；还可以展示原有和将来的商业过程；对比讨论新/旧解决方案的过程，识别变化和差距；显示对当前解决方案所做的变更或改进；扩展/附加每个步骤的详细信息，以确保干系人能够理解情况；还可以用于显示关键绩效指标（KPI），包括基准或目标指标。

它可以在项目开始前创建，也可以在项目开始后创建，并且随着产品信息被逐步明细而继续创建。

▍b.用例：

是用文本叙述的手法，来描述系统和用户的交互，以成功完成其目的。用例的核心在于用户与系统间的复杂互动，在对需求的启发中可用于发现和描述这些复杂的交互。用例主要应描述和记录系统或运营的功能性特征，不用来记录系统的非功能性特征。

用例的目的是代表主要参与者在用例中试图完成的任务。每个用例都包含一个正常流（系统和用户之间最常见的交互场景），以及当场景偏离正常流时的替代流和异常流。用例常用于识别和明细需求，尤其是在将商业需求转移到干系人需求或解决方案需求时。

用例通常在过程流之后被创建，为过程流中的具体步骤提供更多详细信息；有时也被用来代替过程流并用于识别功能性或非功能性需求或验收标准；也可以用作展示解决方案需求的方式。

▍c. 用户故事：

是一种从用户的角度记录干系人需求的方法，重点是关注用户在完成故事后获得的价值或效益。用户故事的构成有三要素“我作为<参与者>，我希望能够拥有<功能>，这样我就可以满足需要的<商业原因>”。每一个用户故事也应该匹配相应的验收标准，“在指定的<前提条件>下，当<事件>发生时，会产生<预期结果>”。

用户故事有助于把商业需求和解决方案需求连接起来，用于将需求或验收标准，映射到反映整体商业用户任务的过程模型上。在适应型方法中，用户故事通常是表达需求的方法。一个用户故事可能包含许多需求，它是需求的功能组合；故事可以直接追溯到商业目标以证实需求的价值；用户故事也能够追溯到其他模型的元素；可用来在每个版本和迭代过程中管理、优化、追踪和分配功能。

关于用户故事的详细用法，之前写过一篇文，感兴趣的可以查看《用户故事帮你了解需求的真相》

这三类就是常见的过程模型，过程模型通常在项目的早期到中期被创建。

三规则模型

为执行既定的商业政策而定义的商业规则，这些规则是有关商业各个方面的概念，限制了商业的相关行为。常见的规则模型一共有两类：

▍a.商业规则目录：

详细说明了所有商业规则及其相关属性，一般用表格的形式来展现。商业规则不是过程或程序，而是用来描述如何约束或支持商业运营中的行为。了解商业规则非常重要，因为它们需要由解决方案来实施或执行，并且很多情境下，一些干系人可能想要或需要变更商业规则以支持商业运营。

商业规则目录可在识别商业规则的任何时刻被创建和更新。任何给定的项目组合、项目集或项目都可能跟踪商业规则的不同属性。商业规则目录还可以显示从每个规则到相关过程的映射，以执行规则，或者应用这些规则来创建数据模型。

▍b. 决策树和决策表：

决策树和决策表都是描述一系列决策和这些决策所导致的成果的规则模型。决策树和决策表都经常用于商业规则建模，且常需要同时使用。

决策树，顾名思义，树状的结构显示了导致成果的决策和选择的流向，并且可以显示有序排列的决策，最适合用于二元选择（即：是/否）；而决策表则有助于确保商业分析专业人士考虑了所有可能的决策场景及相应成果的组合，能应用于有更多选择并且分析变得复杂的情况；当决策顺序并不重要的时候，最好使用决策表。

决策树和决策表可以帮助识别任何与支持这些商业规则或特定结果有关的需求。它们也都可作为创建测试用例的基础，每个决策和成果的组合都是一个测试用例。

四数据模型

记录在过程或系统中使用的数据以及数据的生命周期的模型，用来描述数据间的关系，以显示数据如何与过程关联，并进一步帮助提取需求和相关商业规则。

▍a.实体关系图：

实体关系图也称为商业数据图，是一种显示产品中的商业数据对象或感兴趣的信息片段，以及这些对象之间基数关系的数据模型。

在这个概念中，商业数据对象是指业务思考和关注的，从商业角度得到解决方案中数据的概念视图，而不是数据库中确切的数据对象，代表了业务关注的人、地方、事物和概念；基数是指一个实体和其他实体发生关系的次数，以及这种关系是否必需或可选。

实体关系图是用来描述现实世界的概念模型，有助于识别在系统中创建、被系统使用或从系统输出的数据。当与过程模型一起使用时，实体关系图还可用于从过程的角度对重要数据进行建模。

实体关系图通常在分析的早期阶段被创建以便于理解要分析的数据的范围。此模型还有助于识别可能创建、使用或处理数据的任何过程及有关数据的商业规则。此外，实体关系图也是数据库的设计人员和架构师在设计数据库时可能使用到的输入。

▍b. 数据字典：

数据字典是罗列数据对象的数据域及其属性的一种数据模型。是实体关系图中数据对象的补充细节，它的属性详述了域的信息，包括数据执行的商业规则。

数据字典通常在使用其他数据模型识别数据对象之后，并且在数据对象需要指定更多细节时创建。它们通常与定义需求和验收标准一起创建。

数据字典通常用表格形式，显示数据域和这些域的属性。常见的属性包括名称、描述、大小和验证规则。用于明确数据非常详细的方面，并从商业干系人的视角获取数据域和属性。

数据库设计者使用数据字典作为输入来创建数据库结构。对于需求分析来说，它可以用来获取非常详细的需求和它们的商业规则。该模型可以独立，不需要多余的需求说明书。

▍c. 数据流向图：

描述了数据在外部实体、数据存储和过程之间流动，外部实体可以是参与者或系统。数据流图说明了系统、参与者和数据之间的关系，其中数据在一个或多个进程间交换和处理。

数据流向图显示了每个过程的数据输入和输出，但不指定操作的时间和顺序。它的作用是帮助收集需求，而不是用来设计技术结构。它能宏观地描绘出数据是如何在解决方案中移动的，帮助干系人和开发展来进一步确定具体的数据需求。

通常，我们需要先创建实体关系图、过程流和生态系统图，以识别在数据流向图中所显示的数据对象、过程和系统。

▍d. 状态表和状态图：

都是用于显示对象的有效状态，并允许在它们之间进行过渡的数据模型。首先让我们先来理解一下，什么是对象，什么是状态。

对象可以是在分析解决方案时的商业数据条目或任何感兴趣的信息；而状态描述了一个对象的生命周期；一个对象的状态必须是相互排斥的，一个对象在任何情况下只能处于多个状态中的一个状态。

状态表和状态图描述了单个对象在一个解决方案中所具有的所有状态，也描述了该对象在状态之间如何过渡。它们对于涉及工作流的解决方案特别有用，有助于发现与对象状态流转相关的商业规则。

这两种模型的区别在于：状态表最常用来进行分析，以确保涵盖所有的过渡，而状态图更便于让干系人以可视化的方式看到有效的过渡流。

以上就是常见的数据模型，数据模型通常在项目的后期被创建。

五接口模型

辅助理解特定系统，以及它们在解决方案和用户之间的关系的模型。

▍a. 报告表：

用表格形式描述了单个报告的详细需求，包括整体信息（如报告名称或根据报告做出的决策）以及域级别的信息（如：数据域的显示及计算）。

报告表通常和报告原型一起使用，以便向实施团队展示报告应有的样式。报告表通常可在解决方案的初始报告列表已被识别并被排序后的任何时间点创建，应首先为优先级最高的报告创建报告表。

▍b. 系统接口表：

为单一系统接口获取所有详细层级需求的一种接口模型。系统接口表的创建使得每个系统与解决方案系统建立连接。系统接口表中的信息包括：系统之间传递的数据域、数据传递的频率和数量，确保数据被正确传递和存储所需的确认规则、以及传递的实际数据对象等。

系统接口表通常在创建生态系统图和系统交互图以识别接口之后创建，它详细到足以代表实际的接口需求和验收标准，不需要其他书面的需求。

▍c. 用户界面流：

显示了功能设计里特定的用户界面和常用的屏幕显示，并且描绘了用户如何在界面间导航。用户界面流可以和过程流或用例组合使用，有助于以可视化的方式显示用户与系统的交互场景。

用户界面流通常在过程流和用例之后被创建，以确保用户界面在系统中的导航是合理的且正确的。我们在定义一个项目的解决方案时，用户界面流可以帮助跟踪所有需要进一步定义的屏幕界面。

界面流也可以用于启发会议，以确定更多关于用户在屏幕界面间的功能细节。这个模型没有反映个人需求说明，它可以追溯到其他需求模型，如显示—操作—响应模型、过程流和个人需求。

▍d. 原型、线框图、显示—操作—响应模型：

这三种某种程度上是相似的接口模型。原型是在构建预期解决方案之前的表示法，可分为低保真原型和高保真原型。

线框图是原型的一种，专用于模拟用户界面设计，也用于呈现屏幕外观。线框图可以是低保真的，如草图；也可以是高保真的，如能真实呈现最终用户界面外观样式。

显示—操作—响应模型采用扁平化的格式来描述页面元素及赋予每个元素的功能，通常与原型或线框图结合使用，以连接用户界面元素需求和可视化的呈现方式。

用户界面的设计可能由用户体验专家或用户界面分析师来完成，商业分析则用于确定用户界面在解决方案的不同状态中如何显示和运行、如何协同工作，以及如何与底层商业逻辑进行交互。

原型和线框图（特别是两者的低保真版本）可能在屏幕刚刚搭建完成之前创建，或者在某分析阶段的中途具体说明。显示—操作—响应模型通常是在功能需求或验收标准得到明确后创建的。

至此我们就学完了五类分析模型：（1）范围模型——界定解决方案范围，（2）过程模型——如何使用解决方案，（3）规则模型——解决方案需要遵守的规则，（4）数据模型——在过程或系统中使用的数据及数据的生命周期，（5）接口模型——解决方案如何与其他系统和用户交互。

通过五种不同角度或模型类别来对解决方案进行分析，来帮助我们获得产品的完整轮廓。

发布于 2022-03-18 09:27

项目管理

项目经理

一范围模型