商业分析实践指南-第四章-需求启发与分析

需求的启发和分析是迭代性的工作，包括计划，准备和实施来自干系人的启发信息，分析和记录这项工作的结果，最终定义出足够详尽的一组需求，一边定义和选择最好的解决方案。启发和分析活动由启发技术和分析模型支持

帮助干系人定义问题和机会，并确定应该采取哪些应对措施

重要性：支持行政决策成功应用影响力协助谈判或调节解决冲突定义问题

启发的结果是商业分析工作的核心输入

启发的意义

启发计划元素：需要获取的信息获取信息的来源获取信息的方法（启发方法）启发活动排序

制定启发计划：要启发的信息哪里可以找到这些信息如何获取信息排序启发活动

启发计划

确定目标：目标是启发活动开展的原因

确定参与者

确定讨论的问题

启发准备：可以是正式或非正式的

启发讨论准备笔记元素：目标参与者要讨论的问题

建立框架，设定基调和融洽的氛围

引言：确定活动基调，提出启发讨论的总体目标

问题的类型开放式：被问者可以用任何方式回答的问题封闭式：从优先选项列表里做选择性回答，是被动和有线的选择且需要确认语境问题：只能根据手头的主题作为参考回答语境无关的问题，在任何情境下都可以提问的问题，也用作获取信息来定义解决方案的切入点

提出恰当的问题

倾听：需要重述或复述听到的内容

主体：提出问题和回答问题的阶段

你还有其他问题吗？我们是否有遗漏或者应该讨论却没有讨论的事情？还有谁可能掌握有助于启发目标的信息？

结尾：为讨论画上句号

分享所有修订后的笔记

后续跟进：与参与者一起整合确认信息

头脑风暴：群体集思广益，展开讨论

文档分析：分析现有文档优点：客观，准确，全面缺点：文档可能得不到或是过时的

引导式研讨会/需求研讨会跨职能部分的关键干系人形成决策BA做主持人时长长（4hr~2days)

焦点小组：专家做主持人不形成决策有相关专家<=2hrs8~12人

结构化访谈：从预设问题清单开始，提出清单上所有问题并获得答案非结构化访谈：从预设的问题清单开始，只有第一个问题是确定会提出的，接下来的问题取决于上一个问题的答案

同步访谈：现场实时进行-电话，视频会议（虚拟会议），互联网协作工具异步访谈：不是实时进行-电子邮件，录音录像

访谈

被动观察：观察工作，不打断，不提问，不寻求说明。记录观察后的几天问工人有关观察活动的问题以验证笔记优点：把对工作的干扰降到最低、

主动观察：会中断工作过程寻求问工人在做什么，请他们澄清事实和征求意见优点：启发信息的即时性和收集到的信息量的增加缺点：中断工作流可能导致生产效率降低，也可能在观察期间改变行为

参与式观察：参与执行活动优点：允许提出问题而不引起误会，有机会体验到工作从而发现在引导式讨论会或访谈中永远不会讨论出的功能，特征和改进

仿真：观察者再现工作，模拟工作

观察：获取大量问题域无偏见的，客观的，真实的信息

低保真原型：通常用纸笔，马克笔和白板完成。模拟用户界面屏幕以及跟与其用户分享可视化的解决方案线框图界面屏幕或报告的模型一栋楼的建筑效果图屏幕布置图新产品草图所有正在进行的设计

抛弃式原型：一旦界面被确认就被废弃，用来帮助定义产品制造的工具和过程，原型本身不卖演进式原型：过程中的实际成品，第一个是最终成品的最早可工作版本，随着迭代更好的功能被增加会改进

高保真原型：创建最最终成品

原型法：干系人能体验的最终产品有形的模型

故事板：通过一系列图像或插图显示序列号或导航的原型技术，代表事件序列的图形展示，通常是静态和抛弃式的，聚焦于体验线框图：展示景泰蓝图或用户界面示意图，表示基本功能，代表了精简的页面和简化的版本，识别所有入口点和出口点，可被开发为一种低保真度的基本蓝图

问卷和调查没有澄清机会可能会使答案毫无意义问题往往是封闭式的，这会使得答案按毫无意义收到的相应数量不足以作为具有代表性的样本

启发技术

开展启发活动

当对其发结果进行分析的时候，结果都记录到可交付成果和表格里，让读者都能使用

启发活动的文档输出

启发过程是一个启发信息和分析所获得信息这两个步骤交替进行的迭代过程，被视为信息的渐进明细

完成启发

BA不能访问到合适的干系人-文档分析

干系人不知道自己想要什么-原型法，故事板对每个可能的解决方案可视化，首选适应性项目周期

干系人难以定义需求：有解决方案但无法细化成needs-组织干系人直接跨越到解决方案，问”为什么”

干系人没有提供足够的细节用于开发解决方案-通过可视化模型技术启发需求

启发的问题和挑战

分析定义：检查，分解，合成信息以进一步了解，完善和改进信息的过程

预先思考分析：为多样化技术的使用做好准备

分析计划

分析需求

模型描述：信息的可视化表达形式

模型目的

目的模型和商业目标模型：组织并反应目的，商业问题，业务目标，成功衡量标准和高层及功能的图标，可视化的表示支持功能优先级决定决策和产品范围管理的价值。可在项目期间的任何时间创建，有助于竟快创建模型，提供了明确商业需求的结构。生态系统图：显示所有相关系统以及它们之间的关系或者流经他们的数据对象的图标-逻辑系统。方形代表系统，线代表关系，线上的标签代表数据对象，箭头代表数据流的方向。用来理解所有可能受影响的系统或将会影响范围内其他系统，可在项目初期表示项目范围内系统，也可用来确定哪里有可能有接口需求或数据需求。时系统接口高层级的表示，但不包括这些接口的具体要求。系统交互图/0级数据流图：显示解决方案中所有直接系统和人机界面的系统，包含了系统或提供或接受系统的参与者。开发中的系统在中心圆形，接口系统是方形，参与者人形或方形，线连接以显示实际的接口和流经数据。项目早期指定范围有用，包括待开发接口，显示了开发中的系统和其他系统或人之间所有外部触点。有助于确定哪里有接口需求或数据需求，可以模拟现在和未来状态以及帮助进行差距分析功能模型：可视化表示解决方案中所有梳状或分层结构排列的功能，结构可以是水平的或竖直的。有助于说明功能是如何组合在一起的，以及哪个功能是其他功能的子功能，可显示多个跨越不同层级的功能，代表了整个解决方案的功能集。通常不显示需求而显示需求（功能）集，有助于确定如何为商业分析工作组织需求或如何把功能安排在需求文档里。该模型中的功能也用来跟踪需求以确保没有以往的功能或需求用例图：显示系统所有范围内的用例，椭圆代表用例，人物线条画代表参与者，直线连接参与者所交互的用例-不反映信息是流进还是流出，仅建立连接。可用来概括解决方案的范围，突出添加的主要功能（用例）。不显示需求，但有助于为商业分析工作组织需求或将需求布局在需求文档中

范围模型：用于结构化和组织其特性，功能和正在分析的商业域边界的模型

过程流/泳道图/过程图/进程图/过程流程图：可视化地描述人们在工作中执行的任务；方形表示步骤，菱形代表决策逻辑，箭头表示过程顺序。在启发需求阶段可促进与业务干系人的会话。过程流通过跟踪需求的各个步骤，用来识别丢失的功能或需求。也可用来讨论目前解决方案的当前过程和新解决方案的未来过程以识别变化和差距。通过考量需要支持业务过程的功能或质量来提取需求的简单模型。在需求启发会议或需求分析环节完成。用例：描述一组情景，通过系统实现主要参与者目的的单个通道。用例是主要参与者从启动到成功实现目的所采取的系统活动，行为和反应。代表了系统或运营的功能性特征：名称，描述，参与者，组织利益，触发器，前提条件，正常流，后置条件，替代流，异常流。）用于用户和系统之间有复杂的来回作用的场合，可以用在启发会议中已发现和描述复杂的就。用于分析阶段，随后由干系人评审用例。用例通常不是单独的需求，但帮助确定功能性和非功能性需求。用例故事/用户故事：从客户的角度写的陈述，描述了解决方案中需要的功能，通常用于自适应方法（如敏捷）。常见格式：作为一个（参与者），我希望能够（功能），这样我就可以（业务原因）。INVEST确保用户故事质量（独立的，可协商的，有价值的，可估计的，小规模的，可测试的）。验收标准：约人这个故事完成并如预期工作。史诗：用户故事太大以至不能在单一迭代中完成，需要分解成小一点的故事。用户故事作为需求的功能组合，故事可以直接追溯到商业目标以证实需求的价值。

过程模型：描述干系人参与的业务过程及方法的模型

商业规则目录：商业规则和相关属性的表格，。商业规则不是过程和程序，而是描述如何限制或支持行动但适用于过程和程序，指导组织的活动。商业规则应各自独立，规则必须正确，可验证，一致，目录可用来查阅相关需求或管理文件。元素（ID，商业规则标题，商业规则描述，类型（事实，计算，约束，其他），参考）。决策树和决策表：描述了一系列列决策和决策导致的结果，常用于商业规则建模。决策树：是/否；有决策点的树，分支代表不同选择，最右端代表决策或决策带来的结果。决策表用于更多选择并分析逐渐复杂的情况；顶部代表决策，底部代表结果，列是商业规则。元素（条件说明，条件，行动说明，行动）。都用来建模复杂的分支逻辑，在启发或分析过程中适用于“如果。。。那么。。。”类陈述。决策表和决策树用来识别和标识商业规划

规则模型：定义或约束业务各方面以加强建立商业政策和概念和行为模型

实体关系图（ERD)/商业数据图：显示商业数据对象（业务思考和关注的概念数据）或者一个项目中感兴趣的信息和这些对象的基数关系。商业数据对象：方框；关系：线条；基数：线条上的标签。多样性显示在关系线上，一代表一个实体和其他实体发生关系的次数（0-无；1-单；n-多）。实体关系图用来定义商业数据对象及其相互关系。数据流图：说明了系统，参与者和数据之间的关系，数据在一个或多个进程间交换和处理。可在商业数据图，过程流，生态系统图创建后使用。数据字典：表格形式，显示数据域和这些域的属性（名称，描述，大小，验证规则）状态表和状态图：模拟对象的有效状态和任何在这些状态之间允许的转换

数据模型：用于过程或系统及生命周期的文档化的数据的模型

报告表：为单个报告获取详细层级需求。表示实际的报告需求系统接口表：为单一系统接口获取所有详细层级需求的属性模型。详细到足以代表实际的接口需求，不需要其他的书面需求用户界面流：显示了功能设计里特定的页面，描绘了根据不同的触发器如何导航屏幕。通常用于解决方案定义阶段，也可用于启发会议以确定更多功能细节线框图和显示-操作-响应

接口模型：辅助理解特定系统及他们在解决方案中的关系的模型

模型分类

项目早期：系统交互图，生态系统图，高层级过程流项目后期：创建状态模型，决策模型和用户界面模型敏捷项目：选择用户故事而非用例报告或分析项目：数据模型：数据字典，报告表系统迁移项目：范围模型：生态系统图，系统交互图；数据模型：数据字典，商业规则目录

模型选择：考虑所有模型但所有模型运用于一个项目是不可能的。应考虑：方法论项目特征项目周期的时点模型类别抽象程度

使用模型细化需求

商业过程建模符号（BPMN）：用于复杂商业过程的建模，目的是改变这些过程需求模型语言（RML）：用于需求的可视化建模，以便所有干系人容易理解系统建模语言（SysML）：用于分析复杂系统，包括UML的子集统一建模语言（UML）：主要用于特定设计模型，也能用于特定需求各种其他建模语言：用于当摸个特定建模语言不适用或不是组织标准的一部分的时候

建模语言

模型化与优化需求

需求文档化的重要性：作为商业问题和机会解决方案的基准定义，解决方案演进的出发点，核实干系人需要的基准

商业需求文件-BRD：组织的目标，目的的高层次需要。

需求：产品需求以不同的细节详尽程度来记录，并和不同的需求类型相关联。分类：有助于发现含糊的，表述错误的，歧义的或写得不好的需求。若无法分类该需求可能是无效的（范围/功能/优先级/可测性过滤器。

解决方案文件:包括产品或服务的特征，功能，特性，用以满足商业和干系人的需求形式：需求文件：商业需求文件/功能需求规范/系统或软件需求规范书面的用户故事集包含非功能性需求的用例集产品未完项列表

记录假设记录制约因

需求规范：记录需求的常见形式，描述了解决方案可能发生的各种状况，条件，行动，反应，结果和错误条件

功能要求（条件，主语，祈使句，主动词，对象，商业规则（可选），结果（可选））明确性精确性一致性正确性完整性可测量可行性：运营，技术/系统，成本效益，时间可跟踪性可测性

需求编写指南

优先排序计划：MoSCow：必要的（项目成功的基础）；应该要（重要，但对项目成功无决定性作用）；可以要（可忽略，对项目没有影响）；不会有（目前不支持）多票制：投票时间盒法：先分析项目团队在特定时间段能够交付的工作量，然后据此排序加权排序

需求优先排序

以以下格式记录：线框图：描述用户界面外观模拟界面：指定用户界面细节数据模型和模式详细流程：数据图或活动图详细要求：技术参考

技术需求规范

记录用例

记录用户故事

未完项：具有优先级的产品需求和待完成的交付物

记录解决方案需求：结果需求以表格形式记录

持续确认的概念

需求巡检：与干系人一起评审需求并得到他们时效性的确认

确认需求：保证所有需求准确反映了干系人意图的过程，需要确保需求满足了他们的期望

同行审查：确保书面商业分析成果包括各种形式的需求文件满足组织的标准和通用的需求编写准则

检查：更严格的同行审查方式，审查准确性，完整性，相关性

核实需求：对需求的错误和质量进行审查的过程

批准会议

德尔菲：信息采集技术，有助于让主题专家们达成共识。匿名参加，问卷收集信息，然后统计，分发给专家，收集进一步评论。通常几轮后能达成共识。由助于消除数据偏差，避免某人对最终结果产生过多影响

多票制：团队经过头脑风暴，生成用于解决冲突可选的方案列表，团队决定最终列表上应该包含可选方案的数量。每人多票进行投票，若结果明显则采用，不明显则剔除少数结果，减少每个人的票，重复操作

加权排序

解决和需求有关的冲突

PBA-第四章-需求启发与分析