需求工程-需求捕获、分析与建模
2021-05-28 11:34:05 50 举报AI智能生成
登录查看完整内容
需求工程-需求是一项工程，主要包括需求定义（项目立项时应该做）、需求捕获、分析与建模、需求管理。 《需求工程-需求捕获、分析与建模》针对需求捕获过程中的三个阶段及需求捕获的方式方法、手段、关键任务、产物等进行了描述 欢迎各位大神留言探讨需求相关问题
作者其他创作
大纲/内容
需求捕获、分析与建模
需要的能力
外框
沟通能力：能够清晰表达自己的意思（善于打比方是提高专业沟通效果的好办法）
提问能力：好的提问其实很难，如何“一针见血”，问到点子上，聚焦问题是需要重点锻炼的
谈判能力：与客户争取筹码的能力，尽量争取主动权能够很好的帮助项目成功
理解能力：理解与沟通相辅相成，但良好的理解能力还需要专业的知识甚至心理学知识支撑
倾听能力：耳朵与嘴的比例，多听少说
共情能力：多理解客户的业务场景、客户感受甚至心理
需求捕获要有的意识
要足够主动：BA要保持主动的态度/心态，要不怕麻烦，厚脸皮，别指望客户或需求方送上门来，这好事不多
能够破除“客户”的作怪心理：与人打交道难免遇到各种各样的人，因此遇到阻碍需求捕获的“人”奇怪的心理就不足为怪了
言过其实
客户夸夸而谈，说出的流程都很理想化、规范化，但实施时却与实际大相径庭。通过观察用户的说法方式来发现，通常这种“言过其实”的表述都会以非常肯定的语气，并且讲述时十分流畅，没有什么打断；因为这个时候只需要创造，而不需要回忆
差异展现法：遇到关键流程、有怀疑的流程时就不同用户代表访谈并整理结果，在开发前将差异展现给客户中高层管理人员，就如何解决达成共识
瓶颈分析法：尤其是流程，发现某个角色或人员过度参与时，就应该针对时间瓶颈、人员瓶颈进行分析，避免流程瓶颈导致系统无法顺利运转
越俎代庖
不管是不是自己负责或熟悉的业务，都喜欢侃侃而谈，并根据自己的理解和想象进行肯定的描述
解决这种问题，关键还是要识别并找到合适的被访谈者，也就是回答问题的最佳人选。注意：最佳有两层含义：1.问题的层次要正确：高层解决宏观问题、中层解决脉络（业务流程）问题，基层解决细节（活动）问题；2.被访谈者是否合适：执行者往往就是最佳人选，所以有效识别该问题所针对的业务环境是由谁负责处理的
非正事
被访谈者没有将访谈当作一件优先级很高的事情，有主观与客观两类因素：客观因素：访谈时在办公室等环境容易被打断，影响访谈效果；主观因素：非计划内的事情通常都会被认为是优先级低的事情
这种心理是由于客观与主观因素导致的，所以要解决这两个因素：主观因素：提前做计划，与客户约好时间并明确主题；客观因素：尽量避开办公室类的环境，会议室最好
抗拒心理
在基层比较常见，因为信息化系统对操作层而言效益并不那么明显，且经常使得工作量增加，还会带来许多培训的负担。这就使得操作层用户代表在需求捕获过程中会将对信息化系统的敌对转化为对BA的敌对。敌对状态下是无法有效沟通的
想办法“化敌为友”，需要BA有好的共情能力，能倾听客户代表的抱怨，良好的关系才能较好的开展工作
推卸责任
“你找中层，中层让你找基层；找基层，基层说我们没需求，这事你要找领导”中层回应体现了项目目标不够明确，操作层的回应则体现了推卸责任的心理
首先，先考虑为什么项目目标不明确，是客户的原因还是BA前期在目标分析时存在问题；然后针对基层，最简单有效的策略让被访谈者介绍工作场景：先从工作场景开始，问客户从事哪些工作，工作是如何进行的？工作中存在什么障碍，有啥困难等
聚焦有重点：BA善于聚焦问题，使得需求访谈重点明确，以主动发问的形式、基于目标把控访谈走向，不要轻易将“话筒”交给客户否则极有可能会“提到需求太多”
解决XXX事情的时候一般如何处理？
处理过程需要哪些支持？
原来处理时存在什么困难或不便？
还有哪些相关的问题是比较棘手的？
关注对变更可能的捕获：在需求捕获过程中要加强这方面的意识，毕竟用户不会讲所有的变更可能告诉你
变更为什么很重要？因为“弹性架构”不是万能的
弹性的架构不意味着修改是没有成本的！
架构是根据业务制定的折中方案，在某些方面有弹性就意味着会带来另一方面的限制BA只有将影响架构的因素写在PRD中才能帮助架构师做出正确的决定
方法
最严谨的就是对历史项目、当前项目的变更进行分析、分类，搞一个TOP10，之后重点关注发生频率比较高的并重点捕获
最实用的就是和开发沟通一次，了解开发最惧怕哪些方面的变更，哪些变更会导致较高的工作量
最笨的就是“前车之鉴后事之师”，在整个软件开发过程中不断总结哪类变更较多，在后续的捕获中重视
需求协商：经常会遇到需要协商的情况，需要灵活应对各种场景，如何和客户谈判争取主动权？
需求范围明确
从业务流程梳理业务场景时，客户代表常会提出将与业务流程相关、但超出业务目的的业务活动纳入范围，对于项目而言就需要和用户代表进行协商，根据“目标分析”中的目标来明确边界
造成这样的原因是因为业务流程捕获时，为避免在分析、设计阶段断章取义，并没有考虑系统边界。因此客户代表很容易从业务流程的“服务请求”开始要求实现，但“目标决定范围”，与目标无关或者无直接贡献的应移除。与客户代表协商时，以客户方高层领导“目标”划分即可
拨开立场，寻找客户利益诉求
典型场景：客户提出的需求或变更会导致需求蔓延或较大幅度增加工作量
当我们与客户立场发生对立时，核心技巧在于问出客户的立场，当真正了解客户的利益诉求时，就可能找到很多折中的办法问出客户立场最简单的办法：多问为什么!
优先级“争夺”
当客户将所有需求都定义为高优先级或有意无意不指定优先级时，就会对项目计划造成影响甚至导致需求蔓延
相对重要→相对次要：选择一个其上级领导提出的、他也知道的需求来比较，告诉他实现他提出的需求就会影响领导关心的需求。如果需求不是很紧急，一般他就会放弃。但如果他还坚持，就要重点审视需求的不可或缺性了！！！
学会打比喻：由于信息的不对称，导致客户无法理解技术领域，这时候就适合利用对方熟悉领域的事物来解释深奥的问题
经常会发生客户要求增加或变更一个他们认为“简单”的功能，但技术实现或改动特别大的情况，这时客户与技术之间就存在信息壁垒，如何让客户认识到背后的工作量？
使用“隐喻”，找生活中熟悉的事情或案例向客户说明加“简单”功能背后所带来的的看不见的工作量，比如：客户要求增加一个字段并质疑到：“不就是改个字段，真的有这么为难！”BA：“你说如果想在家里的卧室中安排个水龙头会怎么样呀！”客户：“开玩笑，没有预留水路怎么能安装呢？”这位客户一边回答，一边就会心地笑了一下。
科学、有计划：BA要善于把握主动权，根据每次访谈的对象制定相应的计划，选择有效的捕获方法（详情见“需求捕获方法”）
敢于抛弃细节，不奢望一次成型
业务流程的识别与分析过程中：第一是善于、敢于抛弃细节，不要过早地钻研到业务活动的具体步骤中，这样必然会导致流程图的规模被扩大了，也就破坏了此目标的达成。第二个是抛弃一次成型的思路，不要精雕细琢，而是出草稿、谈问题、修正草稿、再讨论、再修正……最终达成共识，这才是合理的过程
想着“改进”
对于客户提出的需求，除了“线下到线上”的实现外，对原有业务流程的优化与改进至关重要
需求分析是做什么？
需求分析的任务是分析系统如何实现用户的需要
实际上是业务分析，也就是选择一种业务导向的线索将零散的需求串起来，形成一个体系完整的、内容清晰的框架，以知道后续的设计、开发工作。总结来说：需求分析就是先分解、再提炼，在这个过程中消除矛盾
需求捕获的手段/途径
用户访谈
优缺点
优点：直接有效、形式灵活、交流深入、形象生动
缺点：用时长、信息可能存在片面性（用户代表有时各执一词，无法全面收集信息）
面对人群及对应的目标
高层决策人员
执行阶段：需求定义阶段
话题中心：问题/机会
目标：探讨系统的目标与范围（对应“目标分析”）
访谈结果：是访谈中层管理人员的指导
中层管理人员
执行阶段：需求捕获一阶段
话题中心：业务流程/业务事件
目标：理清需求的脉络信息
访谈结果：是访谈操作层的指导
操作人员
执行阶段：需求捕获二阶段
话题中心：业务活动
目标：填充业务活动的细节
访谈结果：是业务用例（活动）的步骤梳理指导
技术团队
执行阶段：需求捕获（访谈是突发性的，当BA无法确定技术可实现性、成本无法预估时进行）
话题中心：解决方案
目标：论证解决方案的可行性
访谈计划
计划时间和人员
访谈计划是需要有目的性的，需要根据需求捕获所处的阶段来确定访谈的时间、人员、主题等，不应该是随机进行（看谁有时间就和谁聊聊）的，这样很难保证需求访谈的针对性与完整性
访谈主题
访谈要点
期望部门（对象）
备注
访谈人：由用户方联络人指定
访谈时间：由用户方联络人指定
可以有效避免“非正事”心理
计划访谈内容
根据访谈面对人群的不同，就他们关心的“话题中心、目标”准备问题
访谈时空安排
时间安排：一次用户访谈的时间应控制在1小时内，若时间不足考虑中场暂歇或安排下一次访谈
空间安排：尽可能选择会议室、洽谈室等封闭、不易被打扰的地方（参照“非正事心理”）
会议记录：建议采用“做笔记+录音”的组合形式，且在访谈者每陈述完一段话后进行复述，以确保双方达成共识
访谈的沟通技巧
提前准备
尽量制定访谈计划，罗列出要问的问题，事先发给被访谈对象，让他“有备而来”
发送时间原则：2天前，1周内
把握语言节奏
以业务为中心：访谈过程中要注意谈话中心是“业务”而非“技术”
多听少说：访谈的信息流是被访谈者→访谈者，因此要切记喧宾夺主，导致信息获取不足
言简意赅：尽量使用短句（主谓宾结构），少用“定状补”；不使用“被动句、双重否定”等容易歧义的句式；不要采用过多修辞手法
提问有层次感：将长问题尽量拆解问多个递进性的子问题，避免一次性提问
合理搭配问题类型
开放式问题（简答题）
半封闭式问题（选择题）/封闭式问题（判断题）
尽量使用开放式问题；当访谈开场或出现僵局时使用封闭式/半封闭式缓解；在需要使用封闭式问题时，尽量转化为半封闭式（降低过强的诱导性）
擅长使用模型
一图胜千言：擅长使用模型、草图表达，更容易达成一致
控制个人情绪
访谈中要保持注意力集中，认真对待被访谈者，不断与被访谈者“点头互动”等，传达一种友好、专注的信息（不好的情绪或动作行为很容易“暗示”被访谈者不好的信息，极易对访谈过程产生巨大的干扰，甚至变为“敌人”）
善于消除行业带来的隔阂
BA与客户常来自不同的行业或专业背景，所以交流过程中一定存在“术语”。在访谈过程中要勇于问客户的“术语”，尽量用通俗的语言表达技术术语，让双方在沟通时对“术语”的理解尽量一致
擅长捕捉客户肢体语言
客户在访谈过程中除了表述外，他的肢体语言还会反馈出一些语言之外的信息，应该抓住这些异常现象以便对问题建立更清晰、准确的理解
用户调查
优点：调查面广，是对用户访谈技术的有效补充，能克服片面性
缺点：容易形而上学，不易深入
使用方式：在需求捕获过程中，先访谈再调查是更合理的方式
使用时机
存在大样本用户：尤其是基层，人员数量很大一一访谈不现实，需要用户调查来补充
存在跨地域用户：有些客户虽然岗位人数不多，但位于不同区域（尤其是省市区县级的公司），面临的问题也会不尽相同，就需要用户调查实现事先捕获差异点、矛盾性
用户访谈矛盾较多：当用户访谈信息片面性矛盾比较突出时就应该组织需求调查
如何设计用户调查问卷？
篇幅：问卷填写时间不超过20分钟或保持在1~3页以内
布局：问题尽量按照从易到难排列：先易后难至少保证用户以良好的心态回答更多的问题
逻辑性：尽量将逻辑相关的问题按照业务逻辑顺序排列，跳跃性太大会干扰到被调查人的思路
避免封闭式问题：封闭式问题尽量使用半封闭式问题代替
开放式跟随：尽量让开放式问题跟随在相关封闭式、半封闭式问题之后；因为这时用户在脑海中有一些答案，填写出来的可能性就会大大增加
保持简单：对于开放性问题留给用户回答的空间不宜太长，否则会使被调查者产生压力，不敢以简单的方式回答，最终导致干脆不回答的结果，因此通常建议只留1~2行的空间
问卷分析
误区：当我们辛辛苦苦地完成需求调查之后，如果不能够有效地对其进行分析的话，其效果也会大打折扣。但很多人只是简单地统计每个选项的结果，这实际上是不充分的。
目的：需求调查是用来克服用户访谈的片面性的。因此我们必须在分析调查结果时找到差异性，分析造成这些差异的具体原因
技巧
筛除无效问卷：在分析统计之前一定要把无效问卷先排除掉：一种是存在大量的空白，第二种是连续出现相同的答案
对问卷的填写人进行分类：1.将问卷问题进行统计、分析，重点关注同一问题下分布差异化比较大的问题；2.对被调查者按照职位、年纪、地域等进行分类；3.将1中的问题分配给不同的人群，分析差异化是由什么原因导致的
对一些回复模糊不清、有明显差异的问卷进行针对性访谈，以了解其背后的原因（要求调查问卷应该是实名制的，实名的意思不仅仅是要写上名字，还应该填写部门、职位、联系方式等信息）
参考文档
优点：能详细、直观的对数据流细节进行了解和分析
缺点：文档数量比较大，有效信息提取不容易且容易被误导；文档是有滞后性的，所以信息很可能是过时的
使用时机：研究、分析、细化数据需求细节的时候。数据需求通常比较琐碎、趋于细节信息，因此不要期望用户能够将其记在脑子里，这些信息往往寄生于各种类型的文档中
要有的意识
切勿照搬线下流程：很多系统在实施时就是简单的将原来的纸质流程照搬到线上，并没有有效的利用自动化对流程进行改良
主动索取资料：不要无计划的让用户一股脑的将所有文档全部塞给BA，而是主动的标识出客户应该提供的文档。对每个业务流程进行分析时标识出业务活动协作所要处理、传递的表单/数据，形成一个列表，让用户按照列表提供
改进流程时考虑对新流程的影响：在分析文档资料时应该思考对“新流程”的影响。纸质表单等线下会夹杂“人”的过分干预与判断，但上线后主要由系统控制，要注意“职责迁移、场景变化”等带来的新变化
收集带数据的样本：在收集文档时，应尽可能让用户提供带有真实数据的样本。客户线下在使用纸质表单时可能会按照实际需要进行调整，而且空白的表单万一是由于客户复印太多还没有用完提供给BA的话，肯定会丢失信息。而带有真实数据的表单会将很多“隐藏信息”暴露出来
用户界面原型（情节串联）
优点：直观生动，用户界面提供了早期评审，易于用户理解
缺点：耗时
使用时机：在业务很复杂或很重要的需求部分时（不建议全程使用，除非有专门的UE），与客户就需求甚至方案产生盲区，不易达成共识时
以业务场景展现页面交互：在讲解原型时，按照客户工作的业务活动说明某个业务场景下客户应该怎么做，把相关的页面交互串联起来，让用户带着业务线索来审视系统的操作过程，看看是否合理、是否满足需求。串联体现了原型的动态性、交互性，用户不仅仅关心用户界面的样子，更关心用户界面的流转过程、交互过程
现场学习
优点：百闻不如一见，能够对需求与业务流程建立直观的认识
缺点：耗时长，不宜安排，且由于“观摩”心理干扰，可能会失真
使用时机：当客户无法详细解释他们在做什么或遇到问题说不清楚原因时。“人正在做一件事时，最能解释他在做什么、为什么要这么做”
避免失真：现场观摩或学习时，不要“大张旗鼓”的进行，导致操作者受到“办公室文化”影响而呈现出理想化的状态（会遮盖问题）
切勿走马观花：现场观摩时要努力总结整个任务的步骤、找到主要的业务活动（脉络），切不可嘻嘻哈哈看完了事
尽量录像：在条件允许的情况下可以录像反复观看，降低对客户的影响且可以给其他人员在需要时观看
联合开发（驻场）
优点：客户、BA、开发齐聚一堂一起探讨，更容易完成用户需求到解决方案的转换过程
缺点：成本高，且控制不当就会变成扯皮大会
项目启动初期：刚开始对项目的目标与范围都很模糊，需要一起讨论使得目标更明确，范围更清晰，为需求、开发指明方向
关键业务域、功能块：系统中核心的关键部分，保证需求的准确性
会议控制
会前准备
引起重视：让所有参与联合开发人员对这项工作引起重视、积极参与。可以让通过正式的文件、高层认可等形式来进行
确保合适的人参加：“该来的一定要来，不该来的不要请”，确保与议题直接相关的人到场，不要有一些关联的都请。人多极为容易增加组织难度，然后上面大会，下面小会，因为议题不是他们关心的，他们就会下面小会讨论他们关心的
准备好资料：事先收集、整理议题相关资料，会议前分配给参与者，保证所有的参与者都事先阅读了相关资料
做好后勤保障：会议后勤约越专业，就越能够向参与者传递出“会议是被高度重视”的信息，使参与者更专注
会中控制
如何做好会议控制？
会后总结
安排人员全程记录会议中大家提出的观点（记录人员必须有技术背景，且能够很好的理解所谈论内容，一般都是BA干）
记录人员将所有人的观点以条目式的形式记录下（记录下提出人是谁），切勿流水账
会议结束之前，由记录人员将观点列表展示出来，由大家表决将价值很低的需求去掉
将剩下的观点拿出并进行分类
对每一类进行投票，排出优先级，将生成结果发送给所有参会者
一阶段
流程相关知识
业务流程
定义：由多人协作，并且需要一些有效的规则来控制，才能达到预期效果的过程
6大特性
目标性
流程是针对目标进行设计的，是一个整体，或许从局部来说是低效的，但目标是整个流程的高效
内在性
流程本身是一个高内聚的整体，是一个很好分离业务耦合点的线索
整体性
通常流程是由多个业务活动组成的，分析的要点在于确定业务活动之间的关系
动态性
流程是行为流，不是一个静态的快照，而是一个顺序的行为流
层次性
组成流程的活动本身也可以是流程，这也经常困扰流程分析的BA人员。要点在于理清流程的层次，通过逐层嵌套的形式理清脉络
结构性
流程之间的关系主要包括串联、并联和反馈三种
分类
生产性流程
流程中最重要的部分，是企业/组织价值的核心体现，通常是最容易识别的一部分
管理性流程
是对生产性流程的管控，通常是由管理层发现的，对一些质量、效率进行监督的控制性流程，是容易忽略的部分
支持性流程
是对生产性流程的补充，通常是协作部门、本部门员工执行的工作，是最容易丢失的部分
设计原则
以产出为中心
流程以产出为中心，而非任务为中心。流程是否合理，是否高效，关键是从整体上进行评价，仅对一个业务活动进行分析是片面的。不要听从操作层的一面之词，要更多从整体来看待合理性
自食其力
让那些需要得到流程产出的人自己执行流程
权力下放
就是管理层级的扁平化，将决策权下放到更低的管理职位上，这样就会得到更高的效率
服务请求
流程的源头，找到服务请求就识别出来了业务流程
端到端流程
完整：服务请求从提出到满足的全过程。判断流程是否完整，应该站在服务请求的立场，判断请求是否满足或者被拒绝
边界：识别业务流程有“职能边界”和“系统边界”两部分，我们只需要关心“系统边界”。系统边界是“人”会触发“系统”的界限，将此界限作为服务请求
执行步骤
业务流程识别（确定子系统范围）
任务执行指引
识别外部引发的主、变、支流程
识别外部客户：本业务子系统有哪些外部客户？
识别外部员工：哪些其他部门员工会提出服务请求？
识别主业务流程：外部客户/外部员工的服务请求是什么？端到端流程是什么（主业务流程）？
识别变体业务流：主服务请求，存在的无法整合到主业务流程的独立变体
识别支撑业务流：为了更好服务外部客户/外部员工，需要哪些辅助业务流程支持？
识别内部引发的主、变、支流程
识别内部员工/时间/状态：特别注意哪些特定时间、状态引发的流程
识别主业务流程
识别变体业务流
识别支撑业务流
识别管理流程
业务上线类的审批控制；
人财物资源的管控
进度与异常的控制
判断业务流程优先级
是否为主营业务：主营、非主营
发生的频率高低：高、低
二维相乘：关键、重要、有用、一般
产物
《业务流程列表》
类型：说明是主业务、变体业务、支撑业务流程，管理流程
流程名称：不要将服务请求名称写入，转化为合适的流程名称（只通过服务请求寻找流程）
简要说明：说明流程的起点终点及流程目标概述
优先级：关键、重要、有用、一般
业务流程分析与优化
选择流程图描述方式：根据读者、流程类型选择合适的流程图来描述流程分析的结果
跨职能流程图/活动图：强调每个角色执行的活动
顺序图（序列图）：强调各角色之间的协作、交互
数据流图：强调数据流通、加工和处理过程
勾勒流程主体：厘清业务流程中的五大基本要素，搭出流程主体框架
五大基本要素
分工：从提出服务请求到服务请求被满足的端到端过程，涉及哪些角色？
活动：每个角色将负责完成哪些独立的业务活动？
协作：这些业务活动如何协作？是串行？并行？异步？
分支：针对不同情况如何处理？
产物：协作过程中会传递哪些文档？
补充事中管控点：厘清业务流程最终的三大管理要素
审批：在流程中应加入那些审核项，以便控制风险？在分析流程时，应该识别出审批内容、审批意图才是真正的分析到位
规则：在流程各活动有什么规则？
异常：完全无法按照流程执行时，如何应对？
分析流程执行过程的监管需求：从管理者的角度对流程进度、异常等进行管控识别、补充辅助相关需求
管理者如何监控流程执行的进度、效率？
管理者关心哪些异常？如何监控？
管理者对监控还有哪些要求？
流程图绘制
绘制要点
分工平级：保证在同一水平线，要么全岗位，要么全部门，不要混用。且如果全部门，尽量保证部门都是平级部门，尽量不要把人事部和董事会拉一起
活动命名采取动宾结构：活动是一个工作任务，因此不能够使用名词或名词短语，例：申请体检（正确命名）
不考虑系统边界：画流程图时先不考虑系统边界，不是只画与系统相关的部分，以免在分析、设计阶段断章取义
从服务请求者开始：流程起点从服务请求发起者开始，保证流程的完整
主从活动只留一个：流程中很多时间存在主动活动，比如消费者缴费→收费人员收费，按照流程图读者角度保留一个即可
方法/步骤
一听：请业务专家或客户代表讲述过程，在纸上或其他形式快速画出流程脉络，这时只需要明确分工、活动及基本的协作关系。过程中做到“不打断、不陷入细节”
二问：沿着流程发问
看看是否存在分支的情况，边问边修正；
问问各协作之间的产物关系，将其补充出来
和业务专家、客户代表就“异常”进行交流，思考“是否存在完全不能当前描述业务流程执行的情况？如果发生了，应该怎么处理？”建议使用文字或另一张异常流程图描述
询问“现在有哪些审批？还有哪些环节存在执行风险？需要增加哪些审批？由谁执行合适？”等问题
沿着流程思考是否需要设置一些规则
协作间规则：用于控制流程协作，例：满足什么条件，流程如何流转
活动执行规则：执行每个步骤时需遵循的规则，例：当前活动只能干什么，不能干什么
数据规则：针对产物格式、内容进行限制，例：金额需要精确到小数点后两位
针对业务流程的“执行进度、效率、异常执行、风险”等管控需求进行询问排查
三读：BA讲一遍流程，确保与客户代表/业务专家达成一致
流程优化
思路
要想“解决问题，首先要发现问题”，要优化流程同理。那如何发现流程中值的优化的地方？建议以“同理心”转换到客户角度，通过“穿越流程”的方法识别问题。通俗的讲，就是将自己想象为当前“执行人”执行流程时，让你自己去做一件事时，思考流程中有哪些繁琐、可以简化或优化的地方，识别出来
策略
E（清除无效）：找到流程中不产生效能的、浪费的、低效的环节，想办法清除
S（简化高频）：对流程中频率最高的环节进行优化，提升流程效率
I（整合依赖）：将相互依赖的环节整合在一起，提升效率，例：开单和收费就可以在“同一窗口”处理
A（自动化繁琐）：将人做起来麻烦的事情让电脑干，提升效率比，例：复杂的计算只需要人提供输入，由计算机按照预设规则运算，输出结果
流程图的层次
说明
流程图存在层次并不是它本身的特性，流程图是一种描述方式，目的是为了清晰地表达业务模式。既然要表达就需要有观众，观众天然的分为“高中基”三层，让决策层看基层的工作步骤太繁琐，让基层看部门间的协作又太抽象，所以流程图的描述就需要“看人下菜碟”
分级
组织级流程（宏观）
展现部门之间的协作
以部门/职责为泳道，抽象层次由读者对象的管理层视野决定
部门级流程（脉络）
展现岗位间协作
以具体岗位/角色为职能带区/泳道，与协作无关的原子性活动不应体现（两个原则：1.是否与协作有关2.是否是独立可汇报的工作单元）
个人级流程（细节）
定义岗位的操作规程/业务活动步骤
通常没有泳道/职能区带，可以尽量细化
子流程：如果个人级流程过于复杂，还可以再次分层细化
《业务流程描述》
业务流程名称：与《业务流程列表》保持一致
流程简要说明：说明流程的起点终点及流程目标概述，与《业务流程列表》保持一致
业务流程描述：选择适合的模型呈现分析结果。流程图一般用的较多，要呈现出业务流程八大要素
流程相关文档/表单
表单名称：流程中传递的表单的具体名称
流程环节：说明该表单是哪些环节产生的（生产）
说明：简述该表单/文档的作用，以及从哪里可以获得（可以写部门、岗位甚至到人）等相关信息
相关规则
类型：行为规则（协作间规则、活动执行规则）、数据规则
规则描述：对规则进行简述
变更可能与关键例外：该流程存在一些异常、例外、潜在的变化可能
管控点识别与分析
管理支持的核心
通常与业务流程识别、分析结合
重在分析其目的，及识别管控点
通过管理流程事前规避风险
通过规则和审批事中控制风险
通过数据分析事后优化实现管理优化
什么是管控点？
就是用户的管理意图，核心在于用户想要什么信息（而不是数据）
管控点是业务报表背后的真正需求（WHY）
不同的“报表”通过实现管控点来达到管理意图
管控点是需要“指标”进行评价的
不同的用户会使用不同的“指标”
标识管理者
问题
系统涉及哪些管理者？
是管理型还是经营型？
识别步骤
首先在子系统层面寻找相关的决策层（高管）、管理层用户（中、基层）
然后在流程层级寻找相关的管理层用户
最后在整个系统寻找先关的决策层用户
判断已识别的管理者属于管理型还是经营型（不同类型的管理者侧重点不一样）
标识管控点
管理型关注：事务、进度、异常员工、绩效指标
经营型关注：客户、产品/服务、财务、效益
分析所需指标
需要哪些角度的信息？
一个管控点需要哪些指标的支持
不合预期的情况如何识别？
通过用户调研，比如客户满意度；通过市场调研
可以归纳为哪些指标？
更多是站在业务角度
分析步骤
首先从正、反面进行分析，思考要实现一个管控点（WHY）需要哪些信息，找出针对这个管控点的指标
找到这些指标应该用哪些数据能呈现，用什么样的报表或其他数据分析手段(HOW）
注
管控点与指标之间是多对多的
指标是可以复用的：一个指标既可以分析A管控点，也可以为B管控点提供分析信息
分析实现方式
根据数据获取特点选择方法
基于固定数据源，查询条件固定：分析所需报表
基于固定数据源获取，但查询条件无法固定：分析BI需求
什么是BI?
针对的数据源需要重新梳理，查询条件也不固定：分析数据挖掘与数据仓库需求
《管控点列表》
类型：经营类/管理类
名称：管控点名称，应该能够体现管理意图，避免出现“统计、汇总”之类的技术性动词
简要说明：说明管控点的主要用户及使用价值
《管控点分析》
管控点名称
相关干系人：哪些管理层会使用
管控点目标：清晰的从业务角度，以价值态的形式说明每个干系人希望通过当前管控点达到的业务目标
所需业务报表：说明管控点需要哪些指标（及为什么需要）、各个指标需要哪些数据
BI/数据仓库/数据挖掘需求：如果存在一些指标无法简单地使用报表来实现，就需要使用较复杂的手段。因此需要列出需要对哪些指标、哪些数据进行挖掘（以黑盒子的视角明确相关需求）
二阶段
概念澄清
用例模型
定义
用例即业务场景、使用场景（一个完整的业务场景应该是独立的、可汇报的、可暂停的单元）
为什么使用？
用例需要能准确的表达用户的意图，而不是简单的“技术动词”（尽量不要使用CRUD原则描述用例）
常见误解
误把用例图当做了用例分析的全部内容。其实它包括两个有机的组织部分：用例图是目录，用例描述是封装所有需求的形式
常见问题
很多技术人员喜欢直接拿用例图给高中层管理者阅读来验证需求完整性，但效果奇差甚至引起客户不适。因为：管理者关心的是事到事的逻辑，因此更愿意看到流程图，而操作层关注的是人到事的逻辑，因此用例图就适合他们来阅读。因此在需求验证时要根据阅读者的角色来选择合适的模型
元素
参与者
参与者是在系统之外，透过系统边界与系统进行有意义交互的任何事物
参与者是用户相对系统而言所演的角色
判断的要点在于他们是不是系统行为的触发者（直接使用系统的最终用户）
用例
用例是对一类相关行为的抽象
粒度
业务场景是以某岗位为主完成的、相对独立的、可以汇报的业务活动。从某种角度来讲，粒度是由业务流程和组织分工决定的
一个合适的用例时有业务价值的，在百度“输入信息”转身离开明显没有价值
用户故事
定义：一种轻量的、有效的用户需求描述方式，以“作为XXX角色，我希望通过系统XXX（解决方案、功能要求），实现XXX业务目的、解决XXX业务问题”。本质上还是用户视角，也具有业务场景的特性
业务场景（用例）识别
边界确定
首先要排除掉不直接使用系统的岗位，因为它们不是系统要涉及的范畴
识别系统角色（分析业务流程中五大基本要素的“分工”）
“角色化”时，基层岗位通常在直接可以使用岗位只作为角色命名
识别业务场景（分析业务流程中五大基本要素的“活动”）
活动：哪些业务活动需要支持、哪些是部分支持
判断点：判断点是否为独立节点（还是某业务活动的一部分？）
补充业务场景
除了人为触发的业务场景外，还存在特定时间、特定状态触发的业务场景，它们极有可能在业务流程中没有体现出来，需要补充
绘制用例图，概述业务场景
参与者（角色）与用户的映射：角色是在系统权限角度抽象出来的，可能会引入新的命名，应该说明扮演角色的最终用户是谁
用例概述：一句话描述用例（除包含用例、扩展用例外）的业务目的
用例优先级：根据用例是否为主营业务、执行频率、是否必备进行优先级评估
收集原始需求
收集客户的原始需求形成列表
确定参与者
确定提出原始需求的参与者，并对他们承担的工作进行分析概述
合并用例
确定参与者后，按照参与者将原始需求进行分组，然后合并或分解为相应的用例
绘制用例图
《业务场景列表》
用例模型片段（含图例）：将用例图贴到文档中
角色与最终用户的关系
角色
最终用户
业务功能（用例）概述
类型：新增、修改
用例名称
用例简述：说明业务场景的核心业务意图
业务场景（用例）分析
概述业务场景
使用用户语言概述用户执行该业务场景所要完成的业务目的，重在传达用户意图
执行该业务场景有什么前提条件（前置条件）？结束前需要保证什么状态（后置条件）？
除场景执行者外，还有谁关心？为什么？
细化业务场景的业务步骤
基本事件流：最典型的、用户预期内的业务步骤是怎样的
扩展事件流：针对各个步骤，有哪些潜在的变化情况
异常事件流：针对各个步骤，有无异常情况，如何处理？
遍历步骤分析困难，导出功能
思考各个业务步骤、变化、异常情况下会遇到什么困难？
针对这些困难，系统需要提供什么样的功能支持？
思考是否会存在例外情况不能按照以上步骤处理？系统应该提供什么样的功能支持？
识别环境与规则
业务规则（见“业务规则分析”小结）
性能相关
该业务场景的执行人数（使用人数）
典型的业务量（日常的业务量）
峰值情况的业务量
密度（尤其是一天内业务发生的频率不一时）
易用性相关
用户的成长经历（年龄、文化程度、习惯等）
相关系统的是使用经验
用户的使用环境等
部署环境相关
用户所在的网络（例：内外网部署）
软硬件等环境
分析实现方式，完成初步交互设计
交互过程：也就是界面流转图，表达希望系统如何来实现业务场景的所有业务步骤
静态快照：每个页面的具体内容，用原型展示
设计说明：针对每个页面内容、界面流转做一些描述，核心在于说明自己为什么这么考虑，以及它是一种建议还是一种约束
《业务场景描述》
场景概述
任务名称：该场景的名称
任务简述：该场景的执行目的
任务前提：该场景的前置条件/后置条件
任务频率：该场景被执行的频率
场景分析
子任务（子场景）：写出最预期的步骤及每个步骤的问题
任务变体（扩展事件流）：写出一些扩展事件流及相应的问题
所需功能描述：写出针对以上问题所需要的功能
关键例外：说明该场景中一些特殊的、需要开发特点功能来支持的场景例外（选填）
用例描述注意点
重在人机交互
常会在描述用例时，引入大量的人机界面元素（细节实现元素）
人机交互是指人、系统分别在做什么；人机界面是指系统的UI，应该考虑用初步交互设计代替；
保留主语
在描述人机交互时保留主语（人/系统），重在说明人机各自的职责
结构化陈述
常在场景描述时很容易带入大量的分支、循环结构，导致不易读（技术人员尤其明显）
如果......，那么......
改用扩展事件流表示
重复执行第XXX步到第XXX步
改用子事件流表示
数据建模
要解决的问题
数据主线的范围：哪些数据要纳入系统
数据之间的关系
领域模型
描述
是以面向对象的视角看待现实世界的结果，也就是通过类图来描述现实世界中各种事物之间的联系。在构建这个模型时，最主要的工作是找出相关的类，然后命名类之间的关联关系，必要时加入一些多重性描述和业务规则约束
类图
类间关系
关系是针对特定的问题域/系统而言的，脱离系统环境谈关系是没有意义的
常见关系
聚合/组合是针对场景来定义的，没有场景的定义都是嘴瓢
关联
标识两个类之间存在某种语义上的联系，是所有关系中最通用、语义最弱的
泛化
描述了父类与子类之间的关系，继承是泛化关系的反关系。子类是从父类继承的，父类是子类的泛化；一般描述为：......分为几类，包括......，或者......是.....的一类
聚合
表示部分与整体的关系，表示：......（整体）是由....（部分）组成的。但部分可以独立于整体存在
组合
表示部分与整体的关系，表示：......（整体）是由....（部分）组成的。但部分不能独立于整体存在
四色建模法
缺少描述类数据，说明可配置性太差。初始化时就有内容，而且会不断变化
过程数据（红色）
当业务过程中有新的行为发生时，一般就会有过程数据（过程间产生的新数据）
不可或缺，系统中不可能没有需要记录的动作。在系统初始化时一般是空表
自然数据（绿色）
表示问题域中涉及的“参与者（人、公司等）、地点、东西（物品、服务）”
不可或缺，系统中总会涉及一些人、地点、东西等自然数据。在初始化时通常会有一些基础数据，并且会随着系统应用不断增加记录
角色数据（黄色）
对自然数据中的人进行抽象的结果
缺少角色，系统会不灵活
描述类数据（蓝色）
概述类：例如为了方便用户选择商品，抽象了品类的概述性名称，比如：体检套餐
规则类：想使用数据库表配置的相关规则，比如：折扣规则、积分规则
领域建模
原则
领域建模时应遵循“拒绝实现细节、大类不分拆、子类不合并、同类不抽象”的原则
急于由“需求”映射“DBA”
领域建模的视图是“需求视图”，数据库表是“DBA视图”，它们的关注点是不同的，领域建模是数据库表设计的基础，但不应过早地进行映射
过早的将子类合并掉
比如有个人客户和公司客户，急于合并为“客户”，觉得只要加一个“客户类型”字段即可，对于领域建模这是不正确的，导致没有有效的将客户的信息完整传达给开发，而且过早决定可能会产生预想不到的问题
过早的将大类拆分
例如将客户类分拆为：客户基本信息、客户联系信息……，以及经常会对一些同类进行抽象，例如将报表格式、表单格式抽象成为模板，这些做法都会阻碍与客户的交流与验证
针对各主业务流程识别过程数据，分析关系
主流程中新发生的动作就可能产生过程数据（其他流程产生的过程数据也要注意识别出来）
识别自然数据/角色数据并分析关系
针对每个过程数据，思考“有人”吗？这些“人”需要抽象成角色吗？有“地点”吗？有“东西”吗？
补充描述类数据
补充并完成和主流程领域类图片段
合并子系统内所有领域类图片段，得到系统领域模型
使用Rose或EA建模工具
子主题
《领域建模片段》
领域类图：类图，加上图例方便客户阅读
业务数据说明
业务数据名称：业务实体名称
别名（选填）
简要说明：说明该类存在的意义/用途
数据规则
编号
规则描述
业务数据分析
易忽略点
通常只认识到“数据构成”分析，重要的业务数据还可以进行数据应用、数据特点
数据应用分析
涉及本数据的领域类图片段
哪些流程会使用到该数据？及使用过程及产物？
在这些流程中会创建、查询、修改、删除该数据的记录吗？
每个流程需要使用的数据字段有哪些（数据窗口）？
通常只对核心的、重要的业务数据执行该步骤
数据构成分析
该业务数据包含哪些字段
数据类型：字符串型、整型、布尔型等
数据规格：长度、精度等
约束/取值范围：该字段可接受的值
其他：是否非空/是否自动编号（+编号规则）、是否派生（+计算规则）
数据特点分析
结构特点
主要字段与次要字段：用户主要会看哪些字段，决定在列表中显示哪些字段
哪些字段是常用的？：客户一般能直接想起
哪些字段常为空值？
稳定字段与不稳定字段：新业务通常带来的数据是不稳定的，在表结构设计时应考虑，因此BA要显性标识出来
哪些是稳定的？哪些有扩展需求？
使用特点
即时数据与历史数据：多久算是历史数据？这影响到历史数据的迁移，以提高查询速度
关键字段与辅助字段：谁可能会被当做查询的关键字？影响到索引等（数据库设计）
数据增长速度：影响性能的主要因素
《业务数据描述》
数据名称（同《领域建模片段》中的“业务数据名称”）
别名（同《领域建模片段》中的“业务数据名称”）
数据构成说明
字段名称
类型/规格
约束/取值范围
其他
数据与流程的关系
业务子系统
流程名称
数据窗口分析
其他说明（结构、数据增长情况等）
业务报表分析
前提
识别出管控点并对其进行分析
明确报表的使用场景
要素
谁是报表的主要使用者？
为什么要使用该报表？
使用频率如何？
谁是报表的生成者？是否存在“伪造”数据可能？
分析报表的内容
在生成报表前需要哪些输入条件/查询条件？
实现报表需要哪些数据源？
直接列出该报表应该从哪些数据表中获得基础数据（数据表多时可以使用类图展现）
报表由哪些数据项组成？
说明统计口径：对哪些数据项需要进行统计
这些数据项如何计算？
逐一列出报表中各个数据项及每个数据项的格式、计算方法
整理报表的输出要求
需要什么样的输出格式？
打印格式与输出格式一样吗？
需要图表来呈现吗？需要的话怎么呈现？
有特殊的排序要求吗？
对分页有什么要求？
对小计有什么要求？
《业务报表描述》
报表名称
使用者
业务意图
使用频率
报表输入条件（查询条件）
报表输出格式要求（原型/Excel）
报表数据来源分析（领域类图片段）
报表数据项说明
数据项名称
备注（含派生方式）
报表相关要求
报表概述
报表实现分析
维护需求分析
核心目标
分析运维阶段所需要的提供的辅助功能，主要包括：配置、运维、升级迁移及其他三方面
标识配置性维护场景
用户及配置权限如何要求？
维护用户
维护角色
维护权限
功能权限
数据范围权限
分配权限
业务数据需要可配置？
如何应对未来数据项的增加、数据构成的调整和变化
业务流程需要可配置？
如何有效应对流程变化对系统带来的影响
业务规则需要可配置？
如何有效应对当法规、管理制度等发生变化？
其他需要可配置？
标识系统运行阶段维护场景
正常时运维场景
故障时运维场景
是否需要监控运行状态？
服务（是否可用、负载是否正常）
网络（网络连通性、传输速度等）
数据库（可用性、负载是否正常）
客户端（客户端可用性、是否存在未授权连接）
数据备份有何要求？
备份内容
备份周期
是否需远程灾备
数据恢复
有什么排错场景？需要怎么支持？
针对故障处理，会否有相应的应急处理机制支持？
其他运行时维护场景？
补充其他维护场景
系统初始化时需要什么支持？
安装工具
初始化配置工具
测试工具
系统升级如何支持？
远程升级
自动化升级
版本检查
手动升级
系统迁移如何支持？
数据迁移
会否支持双系统并行运行
其他维护场景？
《维护需求描述》
配置类需求
用户权限配置需求
业务流程配置需求
业务规则配置需求
业务数据配置需求
其他配置需求
运行阶段维护需求
运行状态监控需求
数据备份/恢复需求
故障定位/排错需求
故障应急方案需求
其他维护需求
系统初始化支持需求
系统升级支持需求
系统迁移支持需求
三阶段
关键质量需求
重要性
在信息系统需求分析中，非功能需求主线的重点在于标识出最关键的质量需求，以便通过有效的技术手段保证系统能够达到要求，为业务提供稳定、可靠的支持
如何破解软件中定性描述非功能需求？具体有何要求？要怎么做?
逆向思考：质量需求是从思考威胁开始
场景化思考：不同的场景下质量需求的要求是不一样的
关键质量要求识别
识别重要质量属性
安全性
访问安全性
数据安全性
可靠性
要求高：7x24h
环境复杂：如异构系统、复杂多元的软硬件环境、存在古董级软硬件
误操作：使用者手生，相对更容易产生误操作，从而使得系统运行不稳定
易用性
效率要求高：易用性不好就会产生很大的影响
用户基础弱：界面要考虑更多提示，帮助用户学习
与“你”差异大：界面设计师与用户差别显著，你觉得好用他却觉得不好用
性能
高并发访问：需要做出最高并发的场景是关键
复杂的算法和逻辑：描述清楚由研发想办法处理
可维护性
业务变化：管理模式、业务模式、法规等发生变化
技术变化：出现新的应用技术、技术趋势
可移植性
系统生命周期长：使用周期越长就越可能经历多次技术变迁，就会增大移植需求
系统部署范围：涉及跨区域部署（省市区），移植就更困难
重要质量属性排序
评估威胁影响度
生命攸关 30
重大经济损失 20
频繁小损失 10
频繁小损失/频繁操作不便 5
评估出现频率
经常出现 3
偶尔出现 2
低概率出现 1
按照影响度和频率乘积排序
《关键质量需求列表》
质量目标类型：一级非功能需求，可以采用国际定义的安全性、可靠性、易用性、性能等归类
质量目标子类：是质量目标类型下的更具体的子项，如安全性可以分为数据安全性、访问安全性等
说明：说明该项为什么重要
排序
威胁影响度：如果该质量目标子类没有达到预期要求，会带来什么程度的损失/破坏
出现频度：此类质量目标子类发生的频率，比如：访问安全性，网站预计会经常被攻击（可以参照客户已有的类似的服务网站和市场上类似网站的被攻击频次）
质量场景分析
非功能需求描述之痛
定性之败
要破解定性之败，方法就是场景化
定量之伤
要在需求阶段对非功能需求做有效的量化，前提条件是“积累历史数据”。只有积累了历史数据，才能够是大家有效的理解量化所表达的“度”，给出科学、严谨的量化描述
全局之谜
非功能需求（特别是性能）是有局部性的，不能一概而论，经常需要在不同的场景下各自说明。如果写不出具体的响应时间，就写出使用频率
识别质量场景
逆向思考
站在系统预期的对立面（就拿安全性来说，你就站在攻击者的角度），思考什么时候不安全、不可靠、不易用、不好维护......
场景化思考
场景化就是给出具体的场景（有针对性）
制定对策
制定解决方案
就是针对某一特定的质量场景（第一步识别得出）所带来的的影响、威胁，采用什么样的技术手段来避免或降低风险
分析解决方案带来的代价
但新的解决方案可能会带来新的问题和影响，因此还要看清解决方案带来的潜在问题和影响
验证矛盾与解决
在需求分析时不仅要注意一个质量场景下带来的矛盾，还要注意其他质量场景的对策带来的矛盾
《质量场景分析》
目标：属于哪种质量类型，一般以《关键质量需求列表》中“关键目标类型-质量目标子类”表示，例：安全性-通信安全性
场景：说明影响质量需求的具体场景
策略及风险：通常由技术来写，说明针对该具体场景将采取的技术措施，以及该措施带来的副作用（风险）
约束分析
进度约束
设计约束
明确进度要求
明确最晚交付期限
最后期限背后的理由/原因
可以分阶段满足吗？
明确资源支持
接口人：用户方的在指定接口人是否明确？
开发/测试环境支持：是否要求客户提供场地、设备等各方面的资源支持？
明确预算需要求
用户有明确的预算限制？
可接受的预算范围是多少？
涉及的需求范围多大？同类系统的建设额通常在什么范围？竞争对手什么报价？
明确技术选型约束
政策、法规规定：诸如国产化数据库
内部规范要求：客户技术团队要求按照相关技术规范执行或选型
客户方技术偏好：客户方技术人员喜好的技术
明确部署环境带来的约束
遗留系统：对系统的实现产生响应的约束
软硬件环境：服务器、终端、网络选型对系统实现产生的约束
明确开发环境带来的约束
开发团队能力构成会对系统实现带来的约束
开发工具、环境对系统实现带来的约束
项目约束
进度要求
预算要求
可用资源
其他约束
技术选型要求
部署环境
开发环境
业务规则分析
如果规则特别多、系统很复杂，建议专门花时间进行处理
结合流程分析出行为规则
结合领域类图分析出数据规则
两个方面
理解业务动机：可能会发现规则欠考虑的地方能够得到更加合适的规则
可执行性考虑：可能会发现通过系统实现后，可以更好的优化规则
按作用域归类规则
规则影响范围
整个问题域
在该子系统下整理成专门章节
一个业务流程
在流程分析中描述
一个业务场景（用例）
在业务场景描述中描述
按类型二次归类规则
行为类：规则是指影响业务流程、场景的执行
适合放在相应的流程分析、场景分析中
数据类：规则是用于控制数据格式、内容的
适合放在领域模型的规则描述中
权限类：规则是用于控制用户的执行和数据查看权限
应该放在权限管理需求描述中
分析规则后的动机
业务动机：设置该规则是为了实现什么样的业务目的？
可执行性：用什么样的方式实现才能够满足这样的业务目的？
《规则与约束》
规则类型：行为类、数据类、权限类
说明：说明具体的规则/约束
动机：描述规则背后的动机，从业务动机与可执行性考虑
0 条评论
回复 删除
下一页
