分析技术和呈现格式
词汇表
强有力沟通的一个重要内容是一致地使用术语和惯用语。每次谈话都涉及对术语的共同理解。
工作流图（也称为流程图、UNL活动图和过程图）
工作流程把一个或多个业务过程的细节可视化地呈现出来，以澄清理解或提出过程改进建议。
一种相对新颖的制作工作流图的方法叫做业务过程建模表示法（Business Process Modeling Notation）。
另一类工作流图是在过程改进六西格玛中出现的。六西格玛工作流图被称为SIPOC图：供应商（Supplier）、输入（Inputs）、过程（Process）、输出（Outputs）和客户（Customer）。用于表示体现整个业务交易的概要视图。SIPOC图中的过程可被分解成更详细的SIPOC图。六西格玛技术被用于找出并度量当前的业务活动，并进行根本原因分析，找出过程效率不高的部分。
Lean方法使用一种称为价值映射的方法来分析物资的流动和信息的流动，从而如何把产品或服务送到客户那里。它包括供应链的标准符号，关注过程改进和减小浪费。
工作流图也被用来表示实施和转换需求。
在员工流程手册、标准操作流程和上线计划中，除了文字描述外再增加可视化的图形表示，将有利于更好地沟通。
为什么使用工作流图？
工作流图非常灵活，可用不同标准和表示法来进行创建，所以在许多类型的项目中都是非常有用的。
业务改进项目非常依赖于于是和要是图。软件开发项目在业务需求层面（用户做什么）或功能需求层面（用户将怎么做）使用工作流图。这项技术在诸如并购和收购等企业级项目中也非常有用。当合并两个部门的时候，有必要分析两个部门的当前流程是什么，并做比较，这样才能描述共同活动并标志出差异。
项目团队也可以利用指标找出最佳实践，并建议合并后的未来流程（要是）。
此外，工作流图对于开发面向服务架构的组织也非常关键。
实体关系图
数据需求是用实体关系图(ERD)表示的，这种图及其附加的描述和细节共同组成了“数据模型”。这是业务领域或应用软件系统信息需求的一种可视化表达。这项技术使用了实体、属性和业务规则等核心需求组件，这项技术可帮助分析师涉及信息需求的提问。
为什么要构建逻辑数据模型
最重要的原因是要确认用户和分析师对业务数据需求的理解，并确保软件开发满足业务需要。逻辑数据建模为分析师提供了一种做分析的结构化工具和技术。大多数领域专家可以把问题和可能的解决方案表达出来；但不幸的是，他们的问题和解决方案通常是基于目前系统的约束，而不是真正的业务需要。向业务人员询问以细致了解每项数据（属性）要求，理解并清晰地能表达业务的方方面面。这一过程使业务驱动系统设计。识别并细化出模型中的数据，就会进一步发现需求和问题，并且在软件设计之前的阶段就开始处理它们。
能帮助分析师从不同角度理解业务，帮助分析师发现重要的业务规则，并提取出能够发现更多隐含业务规则的详细问题。
当项目设计创建和修改数据库的时候，负责创建和维护IT数据的人更倾向于用ERD作为沟通工具。ERD更易于理解，它在分析师和数据库管理员之间建立沟通的共同语言。
逻辑数据模型还能促进数据复用和共享。
使用分解图进行业务过程建模
分解图在无需表现任何顺序和关系的情况下展示了核心业务流程。
分解分析把复杂系统分解成可管理的小块。因为这种图本身就遵循组织架构图的基本规则。被分解的原因在于，每个过程都可以被分解成为多个详细描述它的过程，把它们看成独立的任务将更有帮助。通过把各个组成部分独立开来，你就能洞见复杂业务流程和系统的核心组成。把这些组成内容看成独立的单元也有助于思考未来可以如何构造或者以不同方式实现这些过程。
确保在一张分解图（使用不同的标签）上只展示一种类型的组件。分解图常被用于战略规划，把公司的高层战略目标分解成低层的处室或部门目标。
用这种作图技术，以项目启动文档和对业务的基本理解作为依据做分解图，并给领域专家去修正。
分解图的每个过程都要继续用触发器、追踪器、相关业务规则和数据来描述。这些描述和图一起被称为“过程模型”或“业务模型”。
分解图技术有些关键规则可以保证其一致性和严谨性。
分解图的作图规则：
- 在图中只体现组件之间一种类型的关系：父子关系（用方块之间的一条线来表示）
- 在一张图中只显示一种类型的需求（如果你正在分解过程，就不要显示任何业务规划；只显示过程）
- 每个父节点都可以有多个子节点
- 不显示顺序（没有箭头）
- 一个子节点必须比它的父节点低一级（更详细而细致地区分）
尽管有许多分解图制作规则，但对同一组需求来说，任何两位业务分析师都不可能做出同样的图来。每个分解图都可以表达不同观点并包含不同细节。
分解图有助于组织和结构化分析工作，它使团队以可视化方法在业务背景下观察每个过程，使小组一次只关注一个特定过程，它可帮助设定详细分析工作的边界。
为什么要构建分解图？
分解图是业务领域的一种图形化表示，它易于评审和修订。分解图可以是概要的也可以是详细的。它可用来设计任何类型的解决方案：软件、硬件、流程的或手工的。
用例图
用例是软件系统的一个目标。
用例图展示了主要用例以及所涉及的角色。用例图技术使用来展示功能需求的 - 软件系统是如何与它的用户（角色）交互的。它常用于表示系统的一个未来视图。这种图在显示项目或软件产品的范围时非常有用。
用例图是一种软件设计的工具，但它也可用于业务需求（非技术）层面。用例可以独立于技术命名和定义（商业论证）。用例图也可以用来表示需求和分析工作的范围。
用例描述
用例图中的每个用例都是用例子来描述的。每个用例描述都是一个功能需求交付物，包含特定软件功能的所有需求组件。用例描述还包括一系列顺序的步骤描述软件和角色应如何交互以实现业务目标。
在用例的步骤中，分析师通常会放一条主要路径（开心路径）和几条备用路径。备用路径显示了意外处理和错误条件。对每一步，分析师都描述角色将会采用的动作和系统的响应方式。这个描述包括详细数据需求以及适用的业务规则。
用例方法的主要缺点是：一个用例描述可能涉及几个需求组件（数据、过程、业务规则、外部实体），而不是分别描述它们。把组件写在一起很容易遗漏需求，而且需求组件很难被复用。信息系统中的大多数数据元素会被一个以上的过程使用。当一个数据元素出现在一个用例中时，它必须在所有用到它的用例中被重复定义。这既浪费时间，又可能出错。如果某个数据元素的特性发生改变，你必须在所有用到这个数据元素的用例中进行同样的修改。如果漏掉一个，你的需求就会不一致，而且软件开发就会出粗。
为什么使用用例图
用例图是UML（标准建模语言）的一部分。它是干系人评审的简单图，可以使业务干系人和技术干系人之间的沟通更加容易。
用例图的价值不像其在设计过程的讨论和决定那么重要。但可以与业务干系人，特别是决定者一起使用，因为它要求对人（角色）与系统合作方法作出决定。图中角色和用例之间简单的一根线可能会彻底改变业务人员的工作。它可能会使工作描述、职责发生变化，也可能会出现新的流程。
为什么要使用原型和仿真？
原型是一款出色的软件开发分析工具，因为它让业务干系人很容易能确定设计是否包括了所有必要的数据组件、标签和描述是否有意义，还能针对屏幕上各条目的位置及其美观方面给出特别建议。原型对于IT开发人员来说也是一种出色的需求呈现交互物，因为通过他们呢能够看出到底构建了什么样的系统。
事件建模
识别并分析事件是另外一个很有价值的需求角度。事件是指在业务领域外发生的二业务领域必须响应的事情。
用户故事
用户故事是一种相对较新的需求技术，源自用例技术。一个用户故事是对软件需要完成的某种事情的描述。敏捷软件开发和极限编程经常采用用户故事技术来快速获取需求。故事经常是非正式地写在索引卡上，在开发过程中也不去维护它们。它们不是用来获取详细需求的，只是提供对软件的优先级和估算上的整体需求，更详细的需求是由开发人员和用户在构建软件时讨论的。
