需求工程-需求捕获、分析与建模

客户夸夸而谈，说出的流程都很理想化、规范化，但实施时却与实际大相径庭。<br>通过观察用户的说法方式来发现，通常这种“言过其实”的表述都会以非常肯定的语气，并且讲述时十分流畅，没有什么打断；<br>因为这个时候只需要创造，而不需要回忆

差异展现法：遇到关键流程、有怀疑的流程时就不同用户代表访谈并整理结果，在开发前将差异展现给客户中高层管理人员，就如何解决达成共识

瓶颈分析法：尤其是流程，发现某个角色或人员过度参与时，就应该针对时间瓶颈、人员瓶颈进行分析，避免流程瓶颈导致系统无法顺利运转

不管是不是自己负责或熟悉的业务，都喜欢侃侃而谈，并根据自己的理解和想象进行肯定的描述

解决这种问题，关键还是要识别并找到合适的被访谈者，也就是回答问题的最佳人选。注意：<br>最佳有两层含义：<br>1.问题的层次要正确：高层解决宏观问题、中层解决脉络（业务流程）问题，基层解决细节（活动）问题；<br>2.被访谈者是否合适：执行者往往就是最佳人选，所以有效识别该问题所针对的业务环境是由谁负责处理的

被访谈者没有将访谈当作一件优先级很高的事情，有主观与客观两类因素：<br>客观因素：访谈时在办公室等环境容易被打断，影响访谈效果；<br>主观因素：非计划内的事情通常都会被认为是优先级低的事情

这种心理是由于客观与主观因素导致的，所以要解决这两个因素：<br>主观因素：提前做计划，与客户约好时间并明确主题；<br>客观因素：尽量避开办公室类的环境，会议室最好

在基层比较常见，因为信息化系统对操作层而言效益并不那么明显，且经常使得工作量增加，还会带来许多培训的负担。<br>这就使得操作层用户代表在需求捕获过程中会将对信息化系统的敌对转化为对BA的敌对。敌对状态下是无法有效沟通的

想办法“化敌为友”，需要BA有好的共情能力，能倾听客户代表的抱怨，良好的关系才能较好的开展工作

“你找中层，中层让你找基层；找基层，基层说我们没需求，这事你要找领导”<br>中层回应体现了项目目标不够明确，操作层的回应则体现了推卸责任的心理<br>

首先，先考虑为什么项目目标不明确，是客户的原因还是BA前期在目标分析时存在问题；<br>然后针对基层，最简单有效的策略<b><font color="#0076b3">让被访谈者介绍工作场景</font></b>：<br>先从工作场景开始，问客户从事哪些工作，工作是如何进行的？工作中存在什么障碍，有啥困难等

解决XXX事情的时候一般如何处理？

处理过程需要哪些支持？

原来处理时存在什么困难或不便？

还有哪些相关的问题是比较棘手的？

弹性的架构不意味着修改是没有成本的！

架构是根据业务制定的折中方案，在某些方面有弹性就意味着会带来另一方面的限制<br>BA只有将影响架构的因素写在PRD中才能帮助架构师做出正确的决定

最严谨的就是对历史项目、当前项目的变更进行分析、分类，搞一个TOP10，之后重点关注发生频率比较高的并重点捕获

最实用的就是和开发沟通一次，了解开发最惧怕哪些方面的变更，哪些变更会导致较高的工作量

最笨的就是“前车之鉴后事之师”，在整个软件开发过程中不断总结哪类变更较多，在后续的捕获中重视

从业务流程梳理业务场景时，客户代表常会提出将与业务流程相关、但超出业务目的的业务活动纳入范围，对于项目而言就需要和用户代表进行协商，根据“目标分析”中的目标来明确边界

造成这样的原因是因为业务流程捕获时，为避免在分析、设计阶段断章取义，并没有考虑系统边界。因此客户代表很容易从业务流程的“服务请求”开始要求实现，但“目标决定范围”，与目标无关或者无直接贡献的应移除。与客户代表协商时，以客户方高层领导“目标”划分即可

典型场景：客户提出的需求或变更会导致需求蔓延或较大幅度增加工作量

当我们与客户立场发生对立时，核心技巧在于问出客户的立场，当真正了解客户的利益诉求时，就可能找到很多折中的办法<br>问出客户立场最简单的办法：多问为什么!

当客户将所有需求都定义为高优先级或有意无意不指定优先级时，就会对项目计划造成影响甚至导致需求蔓延

相对重要→相对次要：选择一个其上级领导提出的、他也知道的需求来比较，告诉他实现他提出的需求就会影响领导关心的需求。如果需求不是很紧急，一般他就会放弃。<br>但如果他还坚持，就要重点审视需求的不可或缺性了！！！

优点：直接有效、形式灵活、交流深入、形象生动

缺点：用时长、信息可能存在片面性（用户代表有时各执一词，无法全面收集信息）

高层决策人员

中层管理人员

操作人员

技术团队

计划时间和人员

计划访谈内容

时间安排：一次用户访谈的时间应控制在1小时内，若时间不足考虑中场暂歇或安排下一次访谈

空间安排：尽可能选择会议室、洽谈室等封闭、不易被打扰的地方（参照“非正事心理”）

会议记录：建议采用“做笔记+录音”的组合形式，且在访谈者每陈述完一段话后进行复述，以确保双方达成共识

提前准备<font color="#f15a23"></font>

把握语言节奏

合理搭配问题类型

擅长使用模型

控制个人情绪

善于消除行业带来的隔阂

擅长捕捉客户肢体语言

优点：调查面广，是对用户访谈技术的有效补充，能克服片面性

<div>缺点：容易形而上学，不易深入</div>

存在大样本用户：尤其是基层，人员数量很大一一访谈不现实，需要用户调查来补充

存在跨地域用户：有些客户虽然岗位人数不多，但位于不同区域（尤其是省市区县级的公司），面临的问题也会不尽相同，就需要用户调查实现事先捕获差异点、矛盾性

用户访谈矛盾较多：当用户访谈信息片面性矛盾比较突出时就应该组织需求调查

篇幅：问卷填写时间不超过20分钟或保持在1~3页以内

布局：问题尽量按照从易到难排列：先易后难至少保证用户以良好的心态回答更多的问题

逻辑性：尽量将逻辑相关的问题按照业务逻辑顺序排列，跳跃性太大会干扰到被调查人的思路

避免封闭式问题：封闭式问题尽量使用半封闭式问题代替

开放式跟随：尽量让开放式问题跟随在相关封闭式、半封闭式问题之后；因为这时用户在脑海中有一些答案，填写出来的可能性就会大大增加

保持简单：对于开放性问题留给用户回答的空间<b><font color="#f15a23">不宜太长</font></b>，否则会使被调查者产生压力，不敢以简单的方式回答，最终导致干脆不回答的结果，因此通常建议只留1~2行的空间

误区：当我们辛辛苦苦地完成需求调查之后，如果不能够有效地对其进行分析的话，其效果也会大打折扣。但很多人只是简单地统计每个选项的结果，这实际上是不充分的。

目的：需求调查是用来克服用户访谈的片面性的。因此我们必须在分析调查结果时找到差异性，分析造成这些<b><font color="#f15a23">差异的具体原因</font></b>

技巧

优点：能详细、直观的对数据流细节进行了解和分析

缺点：文档数量比较大，有效信息提取不容易且容易被误导；文档是有滞后性的，所以信息很可能是过时的

<b><font color="#f15a23">切勿照搬线下流程</font></b>：很多系统在实施时就是简单的将原来的纸质流程照搬到线上，并没有有效的利用自动化对流程进行改良

<b><font color="#f15a23">主动索取资料</font></b>：不要无计划的让用户一股脑的将所有文档全部塞给BA，而是主动的标识出客户应该提供的文档。对每个业务流程进行分析时标识出业务活动协作所要处理、传递的表单/数据，形成一个列表，让用户按照列表提供

<b><font color="#f15a23">改进流程时考虑对新流程的影响</font></b>：在分析文档资料时应该思考对“新流程”的影响。纸质表单等线下会夹杂“人”的过分干预与判断，但上线后主要由系统控制，要注意“职责迁移、场景变化”等带来的新变化

<b><font color="#f15a23">收集带数据的样本</font></b>：在收集文档时，应尽可能让用户提供带有真实数据的样本。客户线下在使用纸质表单时可能会按照实际需要进行调整，而且空白的表单万一是由于客户复印太多还没有用完提供给BA的话，肯定会丢失信息。而带有真实数据的表单会将很多“隐藏信息”暴露出来

优点：直观生动，用户界面提供了早期评审，易于用户理解

缺点：耗时

<b><font color="#f15a23">以业务场景展现页面交互</font></b>：在讲解原型时，按照客户工作的业务活动说明某个业务场景下客户应该怎么做，把相关的页面交互串联起来，让用户带着业务线索来审视系统的操作过程，看看是否合理、是否满足需求。<br>串联体现了原型的<b>动态性、交互性</b>，用户不仅仅关心用户界面的样子，更关心用户界面的<b><font color="#f15a23">流转过程、交互过程</font></b><br>

优点：百闻不如一见，能够对需求与业务流程建立直观的认识

缺点：耗时长，不宜安排，且由于“观摩”心理干扰，可能会失真

<b><font color="#f15a23">避免失真</font></b>：现场观摩或学习时，不要“大张旗鼓”的进行，导致操作者受到“办公室文化”影响而呈现出理想化的状态（会遮盖问题）

<b><font color="#f15a23">切勿走马观花</font></b>：现场观摩时要努力总结整个任务的步骤、找到主要的业务活动（脉络），切不可嘻嘻哈哈看完了事

<b><font color="#f15a23">尽量录像</font></b>：在条件允许的情况下可以录像反复观看，降低对客户的影响且可以给其他人员在需要时观看

优点：客户、BA、开发齐聚一堂一起探讨，更容易完成用户需求到解决方案的转换过程

缺点：成本高，且控制不当就会变成扯皮大会

项目启动初期：刚开始对项目的目标与范围都很模糊，需要一起讨论使得目标更明确，范围更清晰，为需求、开发指明方向

关键业务域、功能块：系统中核心的关键部分，保证需求的准确性

会前准备

会中控制

会后总结

定义：由多人<b>协作，</b>并且需要一些有效的规则来<b>控制</b>，才能达到预期效果的过程

6大特性

分类

设计原则

流程的源头，找到服务请求就识别出来了业务流程

完整：服务请求从提出到满足的全过程。判断流程是否完整，应该<b><font color="#c41230" face="宋体">站在服务请求的立场，判断请求是否满足或者被拒绝</font></b>

边界：识别业务流程有“职能边界”和“系统边界”两部分，我们只需要关心“系统边界”。系统边界是“人”会触发“系统”的界限，将此界限作为服务请求

任务执行指引

产物

任务执行指引

流程图绘制

流程优化

流程图的层次

产物

管理支持的核心

什么是管控点？

任务执行指引

产物

定义<br>

为什么使用？

常见误解

常见问题

元素

粒度<b><font color="#f15a23"></font></b>

定义：一种轻量的、有效的用户需求描述方式，以“作为XXX角色，我希望通过系统XXX（解决方案、功能要求），实现XXX业务目的、解决XXX业务问题”。<br>本质上还是用户视角，也具有业务场景的特性

任务执行指引

任务执行指引

产物

任务执行指引

产物

要解决的问题

领域模型

执行步骤

前提

任务执行指引

产物

核心目标

任务执行指引

产物

在信息系统需求分析中，非功能需求主线的重点在于标识出最关键的质量需求，以便通过有效的技术手段保证系统能够达到要求，为业务提供<b><font color="#381e11">稳定、可靠</font></b>的支持

逆向思考：质量需求是从思考威胁开始

场景化思考：不同的场景下质量需求的要求是不一样的

关键质量要求识别

质量场景分析

明确进度要求

明确资源支持

明确预算需要求

明确技术选型约束

明确部署环境带来的约束

明确开发环境带来的约束

项目约束

设计约束

按作用域归类规则

按类型二次归类规则

分析规则后的动机

《规则与约束》