1.业务名词
业务分析：与干系人一起工作而采取的一系列任务和技术，其目的是为了理解一个机构的结构、策略和运营，并为帮助机构实现其目标推荐解决方案。
项目：一种临时性（具有确切的起止时间）的工作，它通过创造特殊的产品或服务带来收益变化或增加价值。
产品：产品是项目的结果。但不是所有项目都这样。一个业务流程改进项目可能以流程再造为结果，提升了效率但并没有开发什么新的产品。
解决方案：是任何可以“通过解决问题或允许一个机构利用机会来满足业务需要”的东西（BABOK）。它可能包括产品、现有系统、流程和组织结构的变化。
交付：在软件开发中被用来描述任何给别人的东西。交付需要交给或者展示给干系人，因为它对于干系人具有价值或者期待干系人据此采取行动。
机会：一系列使得做一些事情成为可能的事件。
2.业务分析内涵
- 确定业务问题和商业机会；
- 引导干系人的需要并分析制约因素；
- 分析干系人的需要以定义解决方案的需求；
- 分析和验证潜在和实际的解决方案；
- 管理“产品”或者需求范围。
3.业务分析师向谁汇报？
IT部门，独立的业务单元，独立的业务分析团队。
4.业务分析基础：
- 什么是需求？
- 什么是引导、分析和展示需求的技术？
- 什么是干系人、我对干系人的责任是什么？
- 如何解决业务问题？
- 那些技术是可用的？
5.需求核心组件
人：可能包括机构内部和外部（称为代理或者参与者）的个人和部门；
信息：指数据；
流程：指实施业务的手册、自动执行的活动或者流程；
规则：指业务活动运行需要遵循的业务规定、指导原则、限制和策略。
6.与谁一起工作？
- 项目决策人或发起人
项目是否还会达到增加利润或者减少成本的预期目标？ - 项目经理
- 其他业务分析专业人员
- 专家和用户
理解业务需求的人，或可以提供设计思路的人 - 质量保证分析师
负责验证需求，计划如何正确测试最终产品 - 可用性专业人士
- IT架构师
- IT开发人员
- 数据管理员/架构师/分析师
- 数据库设计师/管理员
- 供应商
7.干系人分析
- 你是否已经和干系人建立了一种关系？
- 这是不是一种好的工作关系？
- 你觉得干系人信任你吗？
- 干系人与 项目的关系是什么？（项目对于干系人的工作有显著的影响还是影响甚微？）
- 干系人对项目的态度是怎样的？对项目感到兴奋还是害怕？
- 干系人在业务领域的知识渊博程度如何？
- 干系人在机构工作多长时间了？
- 干系人在机构中的级别是什么？（管理层）
- 干系人如何与人沟通？他能清晰理解概念吗？他关注细节吗？
- 干系人如何学习东西？
8.平衡干系人需求
在技术团队面前维护业务干系人的利益，并且确认业务需求得到满足。如果业务人员对于总结出来他们自己的需求不同意怎么办？这就需要业务分析师成为一个很强的协调人和共识建立者，甚至有时候是一个谈判专家。
为了企业利益整体最大化而平衡干系人的需求，首先，业务分析师必须理解企业的目标和战略，其次，业务分析师必须理解哪个干系人或团队在资助特定的项目，以及项目追求的特定目标。希望项目的目标与企业的目标是一致的，并且是支持企业的目标的。
9.会议
- 会议的原因是什么？
- 多少人参加会议？
- 会议要完成什么？
- 会议的交付是什么？
- 何时创建需求最好，是会议期间还是之后？
- 什么类型的协同工具比较合适？
了解你的项目
1.商业论证开发（调研、逻辑推理和很强的沟通技能）
可行性分析和成本/收益分析
当你试图说服别人去采取行动时，就是在建立“用例”。
仔细考虑一个项目被批准之后会发生的积极结果，评估潜在的收益并对应可能花费的成本或努力来权衡收益，当收益超过成本，行动就将获得批准。展示各种想法和机会，并且评估相关的价值。
2.为什么决定投资一个项目？
- 出现了一个问题
确定真正需要解决的问题。五个为什么，根本原因分析。 - 减少成本（工作量）
裁员等 - 外部法规要求
政府部门、行业监督机构、标准化机构强制规定。 - 一个业务机会
- 为了市场或者广告
- 支持业务流程
战略规划
项目组合是指机构为了支持战略规划而确定，并进行优先排序之后的一组项目和项目集。
项目集是支持多个相关项目的持续的战略业务动因。项目集和项目组合是两种不同的项目逻辑编组方式。
项目组合管理和项目集管理是业务分析专业人士必须掌握的重要技能。
企业架构
战略规划过程中的工作之一就是建立企业架构。
- 业务架构
1.目标（确定未来5、10年的目标）
2.组织结构图
（机构的部门、分支和业务单元是怎么样的？他们之间的关系如何？机构的高层决策层如何计划未来几年的组织结构变迁？）
3.地点（可以支持多少个办公地点？未来的期望是什么样子？新增的地点在哪儿？）
4.SWOT分析（优势、劣势、机会和威胁）
5.产品（机构现有产品和服务有一个清单，包括产品的描述、过去的销售量、利润等） - 信息架构
信息架构就是一个机构关于如何安全、准确并以易于获取的方式存储数据的计划。 - 应用架构
是一个关于机构的应用系统的规划，它包括维护现有应用及替换策略和新的应用规划。 - 技术架构
支持应用架构，描绘所有需要使用的硬件、软件、操作系统等 - 安全架构
是描绘诸如数据库和业务规则等企业资产的安全保证的计划，通过确定备份、重装和恢复计划来保护应用系统的安全。
沟通战略规划
大机构的小员工心态，是管理大型机构一个实实在在的挑战。
项目发起
项目经理和业务分析师一起，评估项目需求，同干系人一起交流理解项目目标，带领团队就要做的项目范围建立共识。
项目发起的要素：
方法或方法论（关于如何进行项目工作的描述）
工作目的说明（电梯间讲话：解释为什么要发起、批准和投资项目）
项目目标（需要做到SMART【Specific-具体，Measurable-可衡量，Agreed upon-共识，Realistic-可行，Time-framed-时效性】）
问题和机会（干系人想从项目中得到的东西）
干系人（所有专家和团队成员）
业务风险（项目风险【可能妨碍项目成功的潜在问题或事件】-项目经理；业务风险【妨碍业务成功的潜在问题】-业务分析师）
4种风险应对策略：
避免：变更项目减少风险
转移：把风险转移到其他项目或团队
缓解：减少风险的可能性或者影响
接受：允许风险存在并制定应急计划范围之外的条目（这个清单是为了告知所有干系人，某些特定的条目、需求、特性、目标等不在项目范围内。对于项目范围之外的澄清非常重要）
假设条件（建设条件是解决方案运行的基础。如假设办公室的电力是24小时不间断供给。）
确定业务范围（外部互动和高阶流程）
在项目发起阶段最重要的工作就是描述或者通过图示显示需要研究的业务范围（研究领域）。
- 使用高阶数据流图限定分析范围
理解如何决定和记录分析的范围非常重要，范围帮助确定研究领域的边界，并让团队集中精力。
限定范围的技术-建立高阶数据流图：- 与项目交互的机构单元（外部机构）
- 需要和项目交互的现有企业应用（外部机构或接口）
- 涉及项目的员工、客户、供应商等（外部机构）
- 进出项目的信息（箭头）
- 研究领域
- 高阶业务流程（流程是业务人员转移信息【数据】的行为，流程可以在不同的详细程度上进行命名和描述。）
- 通过例图限定分析范围
项目范围蔓延的合理理由：
- 项目开始后的业务变革（新的客户定制产品需求，需求数量突然增加等）
- 外部法规变化
- 分析揭示了会受到影响但是不在项目范围内的业务
- 业务领域带来了新的业务干系人
总结
理解并解释项目重要性及为什么干系人会为项目的最终目标感到兴奋非常关键。了解一个项目的最终目标将明确分析工作的方向。当业务分析师了解了发起项目的原因，他们就会被要求去创建商业论证、成本/收益分析或者可行性研究。
无论是否在项目上，都要做到：
- 必须了解为什么要做一个项目，最重要的关键字是“为什么”。
- 应该了解你和你的团队在帮助机构实现其长期目标。
- 有人推荐的选项与高阶的战略规划不一致时，你应该能够解释为什么这个想法与战略不一致，以及它会给机构整体带来什么负面影响。
- 项目的起源有很多原因，包括政府强制、对竞争压力的反应或者一个明显的成本改进变革，大多数软件开发项目是抱着提高生产力和提高竞争优势的期望而得到投资并期望回报的，理解为什么投资项目对你来说非常关键。
- 项目发起阶段你需要与项目发起人和项目经理一起工作。定义项目边界，并为项目的完成进行规划。
了解业务环境
了解企业
- 阅读宣传资料
产品宣传册的目的是为了建立品牌认知或者加强企业的形象，也可能是为了销售某个特定的产品。 - 阅读公司财务报告
损益表、资产负债表和现金流分析。看看公司利润、市场份额、股东价值和负债方面的表现。了解业务干系人会如何感受和行动。 - 回顾企业战略规划
什么是公司的使命？使命如何实现？
如何解读业务
- 阅读已有文档
系统和软件文档、员工程序手册、政策手册。 - 观察
干系人在哪工作？理解这个角色典型的一天是怎样度过的。发现流程执行中的偏差。 - 访谈
了解现有业务并谈及可能的改进 - 问卷调查
问卷调查对于信息源分布在不同的地点或者参与回复的人数很多是非常有用。对一群人询问相同的问题，去除任何主观访谈的偏见。 - 促进会议
把不同业务领域的人召集到一起，专注于某个特定的流程或者话题。他们一起工作建立对流程的理解共识，也可以产生解决问题的方案的想法。
- 竞争分析（全面了解企业的方法）
必须了解谁是你的干系人的竞争者。看公司是否有定期的竞争报告。
你公司的竞争对手是谁？你的项目是否涉及直接客户或者对产品的影响？如果是这样，你必须理解你的竞争对手提供的产品和服务，机构是以最出色的产品引领行业还是只是市场的追随者？公司采用怎样的与竞争对手不同的策略？他们是如何比较的？竞争优势是什么？ - 画现有流程的工作流图
- 业务规则表
什么是业务流程？
很多机构使用“业务需求”来表示概要的业务目标。理解一项业务，必须理解它的工作，这个工作可以被定义为业务流程。
- 从上和从下观察。具备看到全景和细节的能力。分解图
- 培训
用户需要了解为什么进行变化，以及变化对他们工作的价值。
为什么召开促进会议？
- 多个人参与和个体参与，避免需求遗漏
- 消除决议差异
- 平衡需求的优先级
- 确定项目范围
- 团队建设
- 流程改进确认
解读业务的技巧
1. 了解公司的使命陈述？你的部门或业务单元的愿景是什么？
2. 看看公司网站传递了什么信息，是否容易理解和使用？
3. 看几个你的竞争对手的网站，你的公司和他们的有什么不同？
4. 如果是上市公司，找到最近的财务报告，熟悉下员工人数、总收入、利润率、市场份额等数据。注意阅读脚注。
5. 阅读项目涉及的业务领域的员工或系统流程手册。
第五章 了解你的技术环境
业务分析师要了解那些技术？
软件开发/编程术语
软件开发方法论
- 瀑布方法：阶段、任务、角色和交付的结构化的软件开发方法。从高阶项目目标和需求一级一级向下延伸。
技术架构
操作系统
计算机网络
数据管理
业务分析师要经常问这些问题
- 谁是数据的所有者？如何维持这种所有关系？
- 数据如何使用？为什么需要维护这些数据？
- 希望的数据容量有多大？
- 数据的最佳来源是什么？数据存储在什么地方？
- 数据合并的数据映射是怎样的？
- 数据是如何从现有系统转换到新的基于互联网的应用的？
- 数据变化的频率是怎样的？
- 数据仓库里的数据多久刷新一次？需要实时数据吗？
软件可用性/人机界面设计
- 1.任务的适宜性：这条原则建议软件功能应该根据特定任务而设计，这个任务将基于用户需要和用户的技能水平，这包括协调逻辑工作流和与其他应用工作的软件的能力。
- 2.自我描述性：界面应该直观并很容易提示用户下一步做什么，遵守这条原则会有助于减少帮助系统和对在线程序手册的需要。
- 3.可控制性：用户应该能够控制互动的步骤和顺序并在需要的时候很容易退出系统。
- 4.遵从用户期望：软件应该如用户期望并表现一致，任何与用户期望不一致的软件反应都应该是一个可用性问题（如用户敲下取消按键的时候就希望从当前的状态退出）
- 5.容错：软件应该容许并准备处理任何用户错误，错误信息必须非常清楚并使用用户的语言书写，它们要解释错误是如何产生的，并说明用户如何改正问题。在可用性最好的系统中，软件可以预测和防止用户的错误。
- 6。个性化适宜性：软件应该可以根据个人用户的需求进行个性化定制（如菜单、屏幕显示），应该在给新用户提供帮助的同时给专家用户更高效率的产出。
- 7.学习的适宜性：软件应该简单并支持学习，以便用户可以变得更加有效和提高产出，它应该使用清晰的业务数据，并减少用户的记忆负担。
软件测试
支持测试专业人士验证他们的产品能否满足业务需求。
当一个项目的解决方案进入测试阶段时，业务分析师应该密切参与；当测试进行并发现缺陷时，业务分析师是找到缺陷根源并帮助找到方法纠正的最佳人选。
软件测试方法基于V模型。V模型中有很多变量，但是这个模型的基本概念是软件测试应该从项目开始就进行，越早越好。V模型推荐软件测试团队独立于开发团队，这种独立性将产生更加彻底和公正的产品质量评估。
在软件开发生命周期对应的测试阶段：单元测试、集成测试、系统测试和用户验收测试。
单元测试：通常由开发人员完成。
集成测试：首先要单独测试需要集成的单元，并对较大的单元或子系统进行测试。集成测试的目标是发现元件或者系统一起工作的问题，这些测试会验证软件架构设计。
通常来说，由于在开发过程中等待太久而没有进行足够的集成测试，是导致项目失败的一个主要原因。
系统测试：是项目团队把产品交给用户检查之前验证产品的最后一个机会。其目标是发现软件产品满足用户需求方面的问题，这些测试验证软件满足最初的需求。
回归测试：新的需求得到满足后，验证旧功能的完好，是重要的隐含需求。任何软件变更后，对于软件没有改变的功能重新测试，确定结果仍然正确。回归测试必须进行，软件非常复杂，一个微小的变化可能都会很容易破坏之前正常工作的部分。
用户验收测试（UAT）：通常当软件销售到开发机构以外时，用户验收测试被称为beta测试，并让用户在正式发布之前试验使用新的版本。
实施后的用户评估：是软件完全使用于业务领域之后对其效率的评估。实施后用户评估的目标是检验解决方案满足用户需求的程度，这项评估工作由业务分析师、项目经理或者质量保证分析师通过对用户的实际操作观察或者仔细设计的问题来实现。
敏捷项目的特性：
- 基于最高业务价值的范围短期迭代（2-4周）
- 小型专职项目团队密切配合工作
- 给团队分配全职业务干系人
- 使用联合应用开发或促进会议快速引导需求
- 每天简短的会议保证项目方向正确
- 软件设计采用“按需设计”方法
- 用户需求采用“按需演示”方法
- 需求的沟通非常不正式
- 团队需要自我管理
采用敏捷开发的好处：
- 对业务干系人的业务价值很快体现
- 每天简短的和经常的检查会让所有团队成员保持方向和专注
- 对于典型的迭代周期为10-30天，因此在每个迭代周期内不需要正式的变更控制。一旦迭代的范围达成一致，就不允许变更（除非范围不可行），需求的变更在后面的迭代周期再去考虑。
- 不需要写大量的需求文档，业务分析师不需要花几个小时的时间斟酌需求文档的词句进行文档检查，需求在产品演示的团队讨论中确定。
- 工作原型显示从最原始的设计到产品软件的演化，因此业务用户可以看到他们需要的变化，开发人员也可以轻松地随着项目进程对可用性进行改进。
- 包括全职业务干系人的专职团队参与，意味着每个人在指定的时间范围内都会专注于现实目标。
业务分析必须先于软件分析完成
让IT架构师介入项目
- 新的应用运行在什么平台上？
- 使用什么数据库管理系统管理数据？
- 应用程序接口会遇到什么样的限制？
- 需要什么类型的技术架构？
第六章 了解你的分析技术
需求分析：从业务干系人那里引导需求、分析需求、把需求呈现给业务干系人评审、把需求呈现给方案团队执行。
分类和呈现需求
收集和管理需求
什么是需求？
需求是干系人为了解决某个问题或达到某个目的所需要的一个条件或能力。
为什么要需求分类？
- 使需求更有条理，易于查找
- 根据受众的不同把需求分别存放，正式文档化和呈现需求的唯一理由是为了沟通和确认理解。
- 复用性
为组织需求开发一个系统
- 是否把不同类型的需求分开？
- 按照什么顺序收集需求？
- 谁将评审需求？
- 每条需求将如何使用？
- 需求之间相互关系如何？
- 是否要为不同干系人以不同方式呈现同一需求？
- 哪条需求可以复用？
推荐的分类系统
业务需求
业务需求是为了完成业务使命所需要的信息、业务活动、业务规则和外部交互的详细描述。
业务需求关注业务问题、业务需要和业务目标，不关心它们将被怎么解决和实现。
业务需求包括项目启动组件（目的陈述、目标、风险等）和数据、过程和业务规则等核心需求组件。它们共同组成了业务的全景图，或称为业务模型。
功能需求
功能需求描述了怎么完成工作。怎么实施业务规则？怎么与人、组织或系统沟通？当软件来支持业务需求时，功能需求描述了最终用户所看到的系统是“什么样子的”。
对于没有软件支持的业务需求，功能需求包括员工的流程、表格、工作流、策略文档和指南，这些描述了工作是怎么完成的。
非功能需求
方案需求一般被分为功能需求和非功能需求。某些方法论也把其称为补充需求、约束需求或服务质量需求。这些需求只在开发软件系统时创建，它们是软件的需求，不一定要和特定业务需要、功能或行为有直接关系。这些需求是系统为了满足用户需要必须满足的需求。例如：
- 可访问性
- 审计和控制
- 兼容性
- 效能（由投入所产生的性能）
- 效率（某个给定负荷所消耗的资源）
- 可延展性（在下一个主要版本升级中增加特性或继续定制）
- 法律和软件许可问题
- 可维护性
- 性能/响应时间
- 质量（发现的差错，交付的差错）
- 可靠性
- 资源约束
- 安全
- 可扩展性
- 安全性
- 稳定性
- 系统可用性
技术需求
技术需求包括技术架构框架、数据库定义、业务规则引擎、编程逻辑、开发对象、应用系统接口、网络架构、安全组件和方案等许多技术规格说明书（技术需求）的详细描述。
核心需求组件
核心需求组件概述
数据（实体和属性）
数据时业务完成工作所使用的信息，它是构建系统的基本组件。
过程（用例）
过程是业务所完成的活动或工作。它们是构建系统的第二个基本组件。每个真正的过程都使用数据，每个重要数据都至少被一个过程所使用。
外部主体（角色）
外部主体是与所讨论的业务领域有交互的人、组织或系统。他们是客户、政府、厂家、供应商、其他部门或者外部软件硬件系统。
业务规则
业务规则是业务运转的约束或指南。
当你确认、命名并定义数据、过程和外部主体后，你可以使用相关的组件名来撰写业务规则。
核心需求的模板
核心需求组件：实体（数据）
实体关系图技术经常用于分析数据需求。该技术定义了三种数据组件：实体、属性和关系（业务规则）。
实体表的模板
核心需求组件：属性（数据）
属性的模板
属性是否具有唯一性：是否可用来查询、搜索并找出特定数据集合。客户号的唯一性。
属性是否强制：客户电子邮件是否是强制的？是否有多条业务规则来搜集数据。
属性是否重复：某个属性会多次出现吗？客户的多个电话号码？围绕重复属性引导需求。
核心需求组件：业务规则
业务规则是主导工作完成形式的一个条件。分析师通过提问把规则明确地提炼出来并形成清晰的书面文字。
业务规则是一个关系需求组件，因为它们常常把其他需求组件联结到一起。当规则“超过50美元的订单可以免费送货”被提炼出来时，它就把几个其他需求组件联系起来了：数据（订单总量、送货费用）、过程（计算送货费用）和外部主体（客户、送货人）。
是否把业务规则看成“需求”并不重要，重要的是在业务分析中要引导、文档化并确认业务规则。它们必须包含在需求包或一个单独文档中。
找出业务规则：定义了业务的约束或规则，所以可把它们看成决策点。每条规则都帮业务干系人作出决策。规则要被清晰地表达出来，确保决策的一致性。（昨天那位售货员告诉我可以退回这个货品）
在需求研讨会中，常常出现两位业务干系人认识到他们对同一条规则有不同理解。把这些未知的差异展现出来时分析的价值，业务领域也因此随即改进了沟通并提高了一致性。
通常，业务规则实在围绕过程和数据的需求引导过程中暴露出来的。
分析技术和呈现格式
词汇表
强有力沟通的一个重要内容是一致地使用术语和惯用语。每次谈话都涉及对术语的共同理解。
工作流图（也称为流程图、UNL活动图和过程图）
工作流程把一个或多个业务过程的细节可视化地呈现出来，以澄清理解或提出过程改进建议。
一种相对新颖的制作工作流图的方法叫做业务过程建模表示法（Business Process Modeling Notation）。
另一类工作流图是在过程改进六西格玛中出现的。六西格玛工作流图被称为SIPOC图：供应商（Supplier）、输入（Inputs）、过程（Process）、输出（Outputs）和客户（Customer）。用于表示体现整个业务交易的概要视图。SIPOC图中的过程可被分解成更详细的SIPOC图。六西格玛技术被用于找出并度量当前的业务活动，并进行根本原因分析，找出过程效率不高的部分。
Lean方法使用一种称为价值映射的方法来分析物资的流动和信息的流动，从而如何把产品或服务送到客户那里。它包括供应链的标准符号，关注过程改进和减小浪费。
工作流图也被用来表示实施和转换需求。
在员工流程手册、标准操作流程和上线计划中，除了文字描述外再增加可视化的图形表示，将有利于更好地沟通。
为什么使用工作流图？
工作流图非常灵活，可用不同标准和表示法来进行创建，所以在许多类型的项目中都是非常有用的。
业务改进项目非常依赖于于是和要是图。软件开发项目在业务需求层面（用户做什么）或功能需求层面（用户将怎么做）使用工作流图。这项技术在诸如并购和收购等企业级项目中也非常有用。当合并两个部门的时候，有必要分析两个部门的当前流程是什么，并做比较，这样才能描述共同活动并标志出差异。
项目团队也可以利用指标找出最佳实践，并建议合并后的未来流程（要是）。
此外，工作流图对于开发面向服务架构的组织也非常关键。
实体关系图
数据需求是用实体关系图(ERD)表示的，这种图及其附加的描述和细节共同组成了“数据模型”。这是业务领域或应用软件系统信息需求的一种可视化表达。这项技术使用了实体、属性和业务规则等核心需求组件，这项技术可帮助分析师涉及信息需求的提问。
为什么要构建逻辑数据模型
最重要的原因是要确认用户和分析师对业务数据需求的理解，并确保软件开发满足业务需要。逻辑数据建模为分析师提供了一种做分析的结构化工具和技术。大多数领域专家可以把问题和可能的解决方案表达出来；但不幸的是，他们的问题和解决方案通常是基于目前系统的约束，而不是真正的业务需要。向业务人员询问以细致了解每项数据（属性）要求，理解并清晰地能表达业务的方方面面。这一过程使业务驱动系统设计。识别并细化出模型中的数据，就会进一步发现需求和问题，并且在软件设计之前的阶段就开始处理它们。
能帮助分析师从不同角度理解业务，帮助分析师发现重要的业务规则，并提取出能够发现更多隐含业务规则的详细问题。
当项目设计创建和修改数据库的时候，负责创建和维护IT数据的人更倾向于用ERD作为沟通工具。ERD更易于理解，它在分析师和数据库管理员之间建立沟通的共同语言。
逻辑数据模型还能促进数据复用和共享。
使用分解图进行业务过程建模
分解图在无需表现任何顺序和关系的情况下展示了核心业务流程。
分解分析把复杂系统分解成可管理的小块。因为这种图本身就遵循组织架构图的基本规则。被分解的原因在于，每个过程都可以被分解成为多个详细描述它的过程，把它们看成独立的任务将更有帮助。通过把各个组成部分独立开来，你就能洞见复杂业务流程和系统的核心组成。把这些组成内容看成独立的单元也有助于思考未来可以如何构造或者以不同方式实现这些过程。
确保在一张分解图（使用不同的标签）上只展示一种类型的组件。分解图常被用于战略规划，把公司的高层战略目标分解成低层的处室或部门目标。
用这种作图技术，以项目启动文档和对业务的基本理解作为依据做分解图，并给领域专家去修正。
分解图的每个过程都要继续用触发器、追踪器、相关业务规则和数据来描述。这些描述和图一起被称为“过程模型”或“业务模型”。
分解图技术有些关键规则可以保证其一致性和严谨性。
分解图的作图规则：
- 在图中只体现组件之间一种类型的关系：父子关系（用方块之间的一条线来表示）
- 在一张图中只显示一种类型的需求（如果你正在分解过程，就不要显示任何业务规划；只显示过程）
- 每个父节点都可以有多个子节点
- 不显示顺序（没有箭头）
- 一个子节点必须比它的父节点低一级（更详细而细致地区分）
尽管有许多分解图制作规则，但对同一组需求来说，任何两位业务分析师都不可能做出同样的图来。每个分解图都可以表达不同观点并包含不同细节。
分解图有助于组织和结构化分析工作，它使团队以可视化方法在业务背景下观察每个过程，使小组一次只关注一个特定过程，它可帮助设定详细分析工作的边界。
为什么要构建分解图？
分解图是业务领域的一种图形化表示，它易于评审和修订。分解图可以是概要的也可以是详细的。它可用来设计任何类型的解决方案：软件、硬件、流程的或手工的。
用例图
用例是软件系统的一个目标。
用例图展示了主要用例以及所涉及的角色。用例图技术使用来展示功能需求的 - 软件系统是如何与它的用户（角色）交互的。它常用于表示系统的一个未来视图。这种图在显示项目或软件产品的范围时非常有用。
用例图是一种软件设计的工具，但它也可用于业务需求（非技术）层面。用例可以独立于技术命名和定义（商业论证）。用例图也可以用来表示需求和分析工作的范围。
用例描述
用例图中的每个用例都是用例子来描述的。每个用例描述都是一个功能需求交付物，包含特定软件功能的所有需求组件。用例描述还包括一系列顺序的步骤描述软件和角色应如何交互以实现业务目标。
在用例的步骤中，分析师通常会放一条主要路径（开心路径）和几条备用路径。备用路径显示了意外处理和错误条件。对每一步，分析师都描述角色将会采用的动作和系统的响应方式。这个描述包括详细数据需求以及适用的业务规则。
用例方法的主要缺点是：一个用例描述可能涉及几个需求组件（数据、过程、业务规则、外部实体），而不是分别描述它们。把组件写在一起很容易遗漏需求，而且需求组件很难被复用。信息系统中的大多数数据元素会被一个以上的过程使用。当一个数据元素出现在一个用例中时，它必须在所有用到它的用例中被重复定义。这既浪费时间，又可能出错。如果某个数据元素的特性发生改变，你必须在所有用到这个数据元素的用例中进行同样的修改。如果漏掉一个，你的需求就会不一致，而且软件开发就会出粗。
为什么使用用例图
用例图是UML（标准建模语言）的一部分。它是干系人评审的简单图，可以使业务干系人和技术干系人之间的沟通更加容易。
用例图的价值不像其在设计过程的讨论和决定那么重要。但可以与业务干系人，特别是决定者一起使用，因为它要求对人（角色）与系统合作方法作出决定。图中角色和用例之间简单的一根线可能会彻底改变业务人员的工作。它可能会使工作描述、职责发生变化，也可能会出现新的流程。
为什么要使用原型和仿真？
原型是一款出色的软件开发分析工具，因为它让业务干系人很容易能确定设计是否包括了所有必要的数据组件、标签和描述是否有意义，还能针对屏幕上各条目的位置及其美观方面给出特别建议。原型对于IT开发人员来说也是一种出色的需求呈现交互物，因为通过他们呢能够看出到底构建了什么样的系统。
事件建模
识别并分析事件是另外一个很有价值的需求角度。事件是指在业务领域外发生的二业务领域必须响应的事情。
用户故事
用户故事是一种相对较新的需求技术，源自用例技术。一个用户故事是对软件需要完成的某种事情的描述。敏捷软件开发和极限编程经常采用用户故事技术来快速获取需求。故事经常是非正式地写在索引卡上，在开发过程中也不去维护它们。它们不是用来获取详细需求的，只是提供对软件的优先级和估算上的整体需求，更详细的需求是由开发人员和用户在构建软件时讨论的。
可回溯性指标
该分析技术，通过找出各个需求组件之间的关系，以及该关系的所有特征，分析师能够找出遗漏或不一致的内容。几乎任何两个需求组件都可以联系起来，根据项目类型和风险决定什么样的链接是有用的。
当业务需求详细到功能和技术需求时，就要对它们进行回溯。当业务干系人描述了一个核心业务过程，比如“记录订单”，团队也设计出一个数据输入页面让客户输入订单信息的时候，业务需求“记录订单”就被连接到该页面。最终的解决方案的每个组件都可能被回溯到一个业务需求上。
考虑到可回溯性有助于开发出完整的需求。当你识别出一个新的需求时，可以针对可能的相关组件提出问题。
差距分析
差距分析用来发现在软件或手工流程中的特定差距。差距分析使用结构化的文档格式比较两个或多个系统。差距分析的常用方法包括：
- 把业务数据需求与某种COTS应用数据库比较（采购选择评估或者转换需求）
- 把现有软件应用系统功能与一个COTS应用功能表进行比较（为了将选择评估打包）；
- 在兼并和收购过程中（为了决定并购的最佳实践），比较两个相似部门的数据、过程和数据规则。
数据流图是最早的分析技术图，主要用于极其复杂的系统分析。现在用多个分解图，模块化代替。
业务分析可选择一种技术来分析和理解，选择另一种技术向业务干系人呈现需求。
业务当前状态与未来状态的分析
在引导、分析和记录需求的时候，业务分析师必须随时意识到当前业务环境的状态。
有两种状态：业务的当前状态，即“as is”； 还有一个是业务潜在的未来状态，即“to be”。
业务分析师对当前状态是否有一个清晰、完整的描述？没有。那需要提出更多问题：
- 什么数据项被输入应付账款系统才能处理支付？
- 信息是怎么确认的？
- 如果支付信息不正确或不完整改怎么办？
- CRM系统信息是否被更新？
- 什么系统信息要被输入CRM系统中？
- 多少字段要被同时输入两个系统中？
- 字段的名字一样吗？
- 为什么流程要求输入两次？
- 如果客户已经在CRM系统中了呢？
- 个人资料是够已经被更新？
打包需求
应该怎样正式地用文档记录需求？
许多组织不愿意在需求上花时间的主要原因，是在太多的项目分析师做了一大堆没人看的文档。敏捷开发方法就是对这种正式文档的强烈反击。
敏捷方法对于软件开发的吸引力源自一个错误概念，那就是认为无需用文档记录需求。
业务分析师常常要在理解复杂过程、清晰沟通和保证时间之间寻求平衡。
什么是需求包？
在传统方法论中，需求包是一种组织并呈现所有需求信息的方式。在需求包被呈现给发起人和领域专家并获得批准后，开发团队才开始开发系统。
第七章 提升你的价值
业务分析职业最精彩的部分，就是能通过学习新技术和不断提升技能，为自己的组织带来更多价值。
- 打好基础
- 时间管理
- 构建你的关系和沟通技能
- 不断学习新的分析技术
- 不断提升你的技能
- 业务分析规划
打好基础
技能：开始
拼图：在不知从何处入手时，你能做的事情就是开始做点什么！
- 1.执行发起人和业务干系人共同提出初始的项目要求，审查所有项目发起文件
- 2.从概要问题开始提问，找到分析工作的边界，并对项目有一个宏观的理解
- 3.业务分析师和项目经理与干系人一起把项目范围文档化
- 4.与干系人一起验证和确认项目的范围，请项目发起人签字
- 5.规划分析工作
-
- 启发详细需求
- 7.找出业务组件并用文档记录下来
- 8.建立一个完备的术语词典
- 9.通过把数据和所处理的需求连接起来，进一步确认是否遗漏了需求
- 10.一旦业务需求完成，与业务领域专家和技术团队一起设计解决方案
- 11.启发功能需求和非功能需求，并用文档记录下来
技能：分析地思考
训练大脑能够把问题和复杂系统分解为多个可管理的组成部分。
技能：记笔记
提问并准确记录下干系人的回答。
- 速记或手写笔记
- 采用一种分析技术来画图或建模
- 轮廓法或思维导图
- 需求引导阶段的视频或录音
在需求引导阶段记笔记非常关键，有两个原因：
第一，高效的业务分析师能有效地利用他们干系人的时间，除非是出于澄清的目的，否则不恩能够让干系人重复他们的需求。
第二，在与干系人会谈时不记笔记显得很无礼。
技术：头脑风暴
该技术能帮助与会人跳出目前的工作流程而产生创新想法而被广泛采用。在需要对现有流程合理化、解决复杂问题或开拓新的商业机会时，人们往往会采用头脑风暴技术。鼓励小组成员贡献所有未经过滤的想法。
技能：与复杂细节共舞
业务分析师必须能够准确地引导并文档化这些细节。耐心地记录详细的需求是项目成功的关键。
时间管理
技能：理解项目的本质
对项任务进行优先级排序。
技能：要事第一
组织总是把最重要和最难做的工作分配给最有价值的员工和顾问。
- 为什么沃恩在做这项工作？
- 这项工作对项目的意义是什么？
- 这项工作的回报应该在什么时候？
- 这项工作的回报值得我们付出这样的努力吗？
技术：理解80/20规则
业务分析师用20%的时间引导80%的需求，其他80%的分析时间用来引导另外20%的需求。
技术：时间盒（Timeboxing）
时间盒技术认为，某些类型的任务是难以完成的，因为它们的最终交付物的状态是主观的。这项技术被用于时间有限而交付物可谈判的软件开发中。时间盒给开发人员一段时间来完成给定的任务，目标是在给定的时间内尽可能多地完成工作。
是一项比较难的技术，因为它强迫分析师把最重要的工作找出来。
该技术对理想主义和有过度承诺倾向的人非常有价值。
构建关系和提高沟通技能
技能：建立紧密的关系
建立关系是成功的业务分析师的一项重要技能。
- 1.知识和经验。 你无法了解和经历所有事情，你能做的就是与那些具备你现在所需要的知识和经验的人建立关系。
- 2.进入和开发。你的项目对你而言优先级是第一位，但对那些你需要的专家和干系人却不是。在项目开始前和过程中与这些干系人建立紧密的关系将帮助你打开那扇门，鼓励他们把自己的时间给你。
技能：问正确的问题
一项重要的分析技能是设计出好问题。一位业务分析专业人士永远在设计寻求答案的问题。
开始在与干系人的访谈中，要提出宽泛的问题以引导能描绘整体概念的回答，然后再采用细节性、澄清概念性的问题。
业务分析大师会围绕每个流程、每项数据、每条业务规则提出详细的问题，有些问题可能略微超出范围，但业务分析师要确保没有遗漏。
这些问题包括：
- 谁完成这个流程？
- 谁管理和批准这个流程？
- 谁提供流程的输入？谁接受输出？
- 是用什么数据、材料、表格或软件？
- 什么约束、策略或过程指导这个流程？
- 这个流程发生了什么问题？
- 这个流程在哪里完成？
- 什么时候完成这个流程？是固定时间吗？还是某个触发事件后？
- 为什么要完成这个流程？
- 怎么完成这个流程？
-我怎么才能引导这个信息？
- 我怎样才能更好地把信息记录下来？
- 回答是否非常关键？
- 在这个回答中可能发现什么样的需求组件？
- 谁会有这个问题的答案？
来自组织的不同部门、处于不同级别的干系人都会提供不同的信息，重要的是向正确的人问正确的问题，不要让干系人觉得自己无能或无知。
最好向高级干系人“为什么”的问题，高层管理者能看的更全面，他们知道组织决策的原因。中层能回答“谁在什么地方做什么”及“每项活动与其他工作的目标是什么”等问题。业务工作人员能够回到“怎么做”及“某项活动与其他工作的关系”等特定的细节问题。
技能：主动聆听
聆听是在对话中一项主动的、有意识的决定。业务分析师必须决定去聆听并且在聆听的过程中积极地参与。
优秀的聆听者能够帮助解决纷争和冲突，他们能在谈话中找到各方的共同点，并把各方的观点清晰地表达出来。
研究表明，一条信息55%的内容是通过非口头的方式传递的。要有意识地观察人们的身体语言和面部表情。
通过声音和身体的语言表达出你的兴趣和好奇。
聆听的障碍
有许多聆听的障碍。这些障碍使聆听者无法准确地理解对方所表达的信息。找出你的障碍并尝试克服。
有一种障碍使过滤器。每个人的大脑通过自童年开始形成的过滤器来处理所有新的信息。你可能不会意识到影响你聆听能力的过滤器。
过滤器来自偏见、信仰、价值观、态度、过去的经历、兴趣和恐惧。
了解自己的过滤器形成的原因。
聆听的另一个障碍是缺乏兴趣。
先入为主也是一种聆听的障碍。对于熟悉的话题或人，人们往往有先入为主的观念和想法，倾向于有选择地听到自己希望听到的内容，过滤掉那些不符合你预期的内容。
聆听需求
技能：出色的呈现
经常要正式或非正式地向干系人呈现信息：
- 向总裁们呈现商业论证及其投入/产出分析，促使他们批准建议。
- 向项目经理和项目发起人呈现工作计划和时间估计
- 向业务干系人呈现业务需求以确认清晰地理解了业务
- 向方案团队干系人呈现业务需求来启动设计会议
- 向业务干系人呈现功能需求和设计理念以获取对理念的反馈。
技能：促进协调和建立共识
业务分析师知道应该怎么提出问题、讨论答案、提出建议，他们在协调或在使用户更容易地解释他们的要求。
仔细聆听、诠释不明晰的话语、提出问题澄清、帮助人们达成共识
为了提高促进协调技能，要首先关注自己的主动聆听技能。其次，提高自己的口头演讲技能。准确而简洁地说话，直接而诚实。
技能：组织高效会议
业务分析师常常要计划和组织会议。
当确定会议是实现目标的恰当手段时，要花一点时间计划会议。选择合适的参会人、做一个会议日程、高效地开会，并在会后跟踪后续工作。
会议日程
应该在会议前准备会议日程并发给参会人。
- 会议目标（包括预期结果）
- 日期及开始和结束的时间
- 地点
- 会议参加人
- 议题及每项议题的预计时间
- 会议的组织人及每项议题的发言人
组织成功会议的小贴士
会议领导者应该不断提醒并专注于会议的成功。
- 永远准时开始；邀请迟到人员在会后了解他们错过的内容
- 考虑把会议的开始时间安排在整点后的15分钟，这样让参会人有时间从他们的上个会议转换到你的会议。
- 向大家介绍每位参会人并解释其参会的原因。这让大家了解自己在此次会议中被期望扮演的角色，并鼓励大家踊跃参与。
- 介绍会议目标并展现日程，在开始前询问变更的建议或澄清
- 按照日程一项一项地通过议题，每次只过一项议题，在进入下一个议题前确保所有参会人都认为上个议题已经讨论完成。把突出事项和问题放到一个跟踪问题清单中便于后续跟踪。
- 注意看时间并确保小组注意力集中地讨论
- 准时结束会议（即使日程中的议题没有讨论完）。必要的话，在小组成员都在的情况下组织加时会议或后续跟踪会议。
- 把突出事项分配给合适的小组成员，并指定预期完成的日期。
- 感谢参会人的参与并强调会议工作的价值，使参与人对自己在会议上所付出的时间赶到满意。
后续跟踪和会议纪要
以文字的方式记录了会议中所做额决策并对会议达成的协议确认达成一致的理解。尽快把这些内容发给参会人，从而验证每个人理解并同意会议的工作成果。
组织需求评审
- 1.决定评审的目的
-
- 与参会人计划时间
- 3.分发评审材料
- 4.让参会人在会议前评审材料
- 5.组织评审会议
- 6.做好评审笔记
- 7.更新材料
- 如果有必要，组织第二次评审
技术：根本原因分析
人们往往在没有仔细研究问题时就提出不恰当的问题解决方案。
鱼骨图是一种结构化根本原因分析的可视化技术。
另一种根本原因分析的技术是5个为什么。为什么问题是工具箱中最有价值的工具了。它被用来帮助挖掘问题或机会的根本原因或底层原因。
技术：机智的违抗
是指能够在不影响个人职业或关系的情况下与组织的决定有不同意见。
机智违抗的三个组件：1.收集事实；2.毫无感情色彩地呈现事实；3.愿意接受决定并继续向前。
另一个非常有用的组件是有一个替代计划。
规划业务分析
一旦了解了项目发起和资金投入的原因后，你就要规划自己的那部分工作。
技术：映射项目
映射项目从两个维度帮助分析师决定所需要的分析工作：什么和怎么及现状和将来。
第一维度（行）代表业务领域的什么和怎么。
什么指的是业务需求：
- 核心流程是什么？
- 核心数据元素是什么？
- 业务规则是什么？
- 业务目的是什么？
第二个维度（列）代表业务的当前和未来的状态。
技能：计划你的工作
业务规划的第一步是了解项目。回顾所有现存项目文档，对工作有一个初步的理解。根据你的研究，询问项目经理和发起人一些问题来评估项目当前的状态。
- 有项目章程或愿景陈述吗？
- 有项目计划吗？
- 项目范围确定了吗？
- 所有的干系人都明确了吗？
- 项目目标是否清晰定义了？
技术：评估业务影响
业务影响是一种衡量，它说明这个项目对业务干系人及其工作的关键程度。
决定业务影响的因素
- 用户的数量
- 干系人数量
- 干系人等级
- 干系人的地理位置
- 业务复杂性
- 解决方案复杂性
- 业务风险
- 质量需求及预期
- 严格的截止日期
- 项目时长
- 项目预算相比于公司规模
技术：干系人分析
是业务分析规划框架的第二块工作
技能：设计业务分析任务清单
- 交付物：应收账款领域的流程分解
- 干系人：三名关键领域专家，在同一办公室工作。
头脑风暴确定有关需要做的事：
- 决定怎么画图
- 做一个向领域专家问的初步问题清单
- 安排首次会议 - 确定有白板或活动挂图
- 协调首次会议
- 根据首次会议得到的信息起草分解图
- 与每位领域专家确定后续跟踪问题的时间
- 与领域专家会面讨论后续问题
- 根据后续跟踪的结果修正分解图
- 与领域专家计划评审会时间
- 准备演示和评审的图
- 在会议之前交给领域专家
- 协调会议并记笔记
- 根据评审会议笔记最后修改分解图
- 把最终版的分解图分发出去并得到签字