需求工程-需求定义

2021-05-28 11:32:09   38  举报





AI智能生成

需求工程-需求是一项工程，主要包括需求定义（项目立项时应该做）、需求捕获、分析与建模、需求管理，该图以宏观角度对需求工程进行了概述并表明了需求过程中的主要任务《需求工程-需求定义》主要针对项目目标识别与分析、业务域的划分、接口的识别划分进行了描述欢迎各位大神留言探讨需求相关问题

需求工程

需求分析

作者其他创作

大纲/内容

什么是需求？

需求：需求 = 预期 - 现状

当预期高于现状时：用户希望自己的业务、管理能够开展得更好，甚至有明确的改进预期。
用户通常比较积极的配合需求调研，只要调研方法得当，就能够很好的识别出目标

当预期等于现状：用户通常对变化表现不积极，基本很难用直接的方法来获取需求

当预期低于现况：用户会表现出抗拒，对需求调研表现出消极态度（这种一般少见）

目标分析

常见问题（现况）

在项目立项时没有很好的完成目标定义工作，主要原因是因为项目立项阶段可能还未完成招标等，开发团队还未介入

后期需要补课，对客户或产品经理等粗略定义的目标进行深化，目标明确，要具有指导意义，要遵循SMART原则

项目立项报告中目标描述空洞无物、混沌不清，写出一些放之四海而皆准的定性描述，失去了指向性（丢失了成功标准《参考：掌握需求过程》）

需求分析师需要破解空洞无物的目标，不要满嘴大话，目标明确，要具有指导意义，要遵循SMART原则

很多项目不愿意在目标定义方面投入精力（开发总觉得多此一举），但这样的做法最终的结果将是“欲速则不达”，还容易造成需求蔓延、丢失方向

思维模式最致命。要认真审视需求定义的产物，大海上没有灯塔，在漫长的黑夜如何指望船只顺利靠岸？

什么是目标？

目标就是问题或机会

问题

如果客户预期高于现状，那么他就会意识到“问题”，即 意识到的需求

机会

给用户一个新解决方案，使其获得新预期，从而产生需求

如果客户对现状满意，就需要需求分析时提出新预期来让他产生需求，这就是“机会”，即用户无意识需求

寻找机会场景的关键在于从用户角度思考，而不是从系统中找优点

目标分析针对的“关键人物”

项目发起人

项目提出者，通常对预期和现状有清晰的了解；同时也对问题的解决或机会的创造最重视

出资人

为项目提供预算的人或部门；通常对项目的成本/效益更为关注

项目属主

负责推动项目实施的责任人或部门。当项目发起人/出资人认为自己直接推动项目会有阻力时，就会寻求一个属主来推动

如何描述？

定性描述

从总体属性、趋势、宏观角度来说，如“全面提高客户服务质量”。这种描述只能指明一个模糊的方向，无法有效的界定系统的范围

定量描述

从微观的角度，会使用具体的、精确地数据描述。遵循SMART原则

具体的（Specific）

可衡量的（Measurable）

可实现的（Attainable）

与相关性的（Relevant）

有时限性的（Time-based）

场景化描述

用故事场景来描述用户的期望

任务执行指引

访谈“问题”：
通过对关键干系人的访谈，识别预期与现状的差距

项目由内部提出
（通常已经有了基本思路）

现况与存在问题

客户的项目发起人可能已经发现了问题，但由于提出后逐层上报对目标进行“逐层提升”，以使其看上去宏观有规模，最终导致给出宏观、空洞的大话表述，抽象造成了沟通的困难

应对策略：表象原因决策提问法

先尝试找出当前项目真正的发起人，他肯定知道项目发起的初衷或者为什么要做这件事

通过“还原表象、分享原因、共商决策”三个提问步骤实现访谈

指标：询问发起人是如何验证、评估自己提出的“宏观要求”的。如“全面提高客户满意度”，
怎么验证、评估客户满意度？要给出一个“成功标准”，并且可验证；

起因：询问发起人为什么要发起这个需求？是什么事情导致发起人要做这件事？

原因：要处理问题肯定存在问题，询问发起人认为造成问题的原因是什么？

解决方案：和发起人一起探讨解决方案

项目由外因触发
（通常问题不太清晰）

参观考察

场景

“老板”通过外出考察或交流等形式发现了“XXX能够做到怎么怎么样，而我们只能怎么怎么样”，
创造了一种“离开现状看到新预期的场景”发现了新的预期和现状之间的差距。
最终“老板”以一种抽象、提炼的形式描述出他的要求

带来的问题

很容易高度定性化描述（大而空，看了不知道要具体解决啥问题），从而出现沟通问题

应对策略：分享收获

还原用户观察的内容，使问题场景化，以便理解“老板”的目标
（让“老板”将发现的XXX能够做到怎么怎么样，而我们只能怎么怎么样”分享出来，并说清楚是哪些方面，且希望做到什么程度）

竞争对象动向

场景

当竞争对手新动向带来一定的威胁和挑战时，就会催生系统升级、建设的需求

存在的问题

用户通常没有明确清晰、完整的思路

应对策略：竞品分析

根据客户所在行业，根据不同规模、发展不同阶段、不同核心商业模式分类（根据实际情况可选），帮助
客户完成“竞品分析”，对不同类型的企业的关键业务问题、业务机会进行场景化描述，帮助客户明确自
己可从“竞品分析报告”中获益的要点

热点及新技术趋势

场景

市场上提出新的技术或概念（偏技术），公司希望通过各种新技术提供竞争力

存在的问题

对于新技术的价值、用途每个人的理解参差不齐，因此会带来一些类似的、似是而非的需求

应对策略：分享理解

只有真正了解项目发起人对新技术的看法、理解，才能够获取背后的真实需求

研讨“机会”：
通过与领域专家、技术专家、用户代表的交流，寻找潜在机会

机会场景发掘角度

新业务

追标杆

在特定领域商业模式最领先的企业，是很多成长企业的“未来”，从这种差距中总能找到新的“机会场景”

赛同行

关注跑在前面的同行的所作所为，可以发现很多有价值的“机会场景”

借他业

行业与行业之间是互相融合的，任何商业在本质上都有极多的相似之处，通过观察其他行业也能找到“机会场景”，借他山之石可以攻玉

新技术

关注新技术的发展路线、应用趋势，从中收获灵感

关注客户的业务问题、痛点，或者当前系统中的遗憾与不便

新人群

对于组织应用系统而言，新一代的管理层、员工都会因新的价值观带来新的思路，也意味者新的“机会场景”

定义问题/机会：
描述问题、机会，以及它影响谁、产生什么结果

思路：“讲故事”比“讲道理”更有效！建议对客户先讲故事，再讲数字

描述问题（如何讲？）

业务态

问题/机会描述是给客户听的，所以一定要从业务的角度阐述，而不是从系统的角度阐述

客观性

要说服别人，就一定要保持客观性（不要加入主观的判断），真实的还原问题，真实的描述现象

匹配性

目的的“观众”都是高层，定义的问题要与高管关注的视角相匹配；
经营层面、管理模式、业务模式等宏观问题才是他们关心的内容

不要将操作层遇到的非共性困难当做问题列入目标分析

分析影响

指代清晰，明确到人

尽可能的明确影响到了谁，范围越准确越好（不要使用“公司、客户”类指代不够清晰的描述，用岗位、部门、角色（一类人）最好）

视角清晰，影响明确

分析带来了什么影响，产生了什么后果（描述时要 推理合理，层次清晰）

分析问题并确定解决方案：
深入分析问题，然后确定策略级的解决方案

分析问题

要提出有效的解决方案，需要对问题进行深入分析找出问题背后的“本源”

鱼骨图法

帕累托图

问题现状树法

系统思考法

明确解决方案策略、界限

描述解决方案时，从宏观视角说明，并强调具体的策略（说明实现思路即可），以便客户高层能够理解
但不能直接从功能层面进行描述，会将非技术背景的客户拒之门外且容易陷入细节而失去重点

解决方案的能力总是有约束的，需要根据预算等明确系统边界，避免需求蔓延

提炼一句话目标

高层一般没时间去看大篇幅的东西，因此要将上面描述的目标场景进行概述。
要点在于“业务态、价值态”，以“措施+效果”的结构描述

产物

《问题卡片》

标题

必填，一句话目标，“业务态、价值态”，以“措施+效果”的结构描述

编号

可选，编号方便需求跟踪

描述

必填，业务态、客观性的描述问题

范围/限制

可选，说明要解决问题的范围（尤其是只解决问题的一部分时）

影响了谁

必填，指代清晰，明确到人

产生了什么后果

与“影响了谁”一一匹配，视角清晰，影响明确：对谁带来了什么影响，产生了什么后果

解决方案要点

必填，说明主要的策略（大概的执行思路）

优点

可选，当存在多个解决方案时，说明为什么推荐本方案的原因

其他

鱼骨图法

说明

也称因果鱼骨图，是一种以直观的图形找出问题或现象的所有潜在原因的方法，有利于追踪问题的根源

适用

当需求分析师认为要分析的问题是由一系列的子问题构成的，就可以用该方法分拆问题

好处

注重原因而非症状：使分析人员将问题的原因而不是症状放在首位

利于头脑风暴：提供了一种运用集体智慧解决问题的方式

直观、简明、易操作

步骤

选择一个具体的问题或现状：要做好问题定义，保证所有参与人能够正确理解要分析的内容

头脑风暴列举导致问题所有可能的原因

将所有原因进行分类整理，确定出主要的原因类型

对所有潜在原因进行分析，找出造成某一结果的根本原因最有可能是什么，或者说哪些原因是最核心的

帕累托图

说明

根据问题的相对频度或大小从高到低降序排列，帮助我们把精力集中在最重要的问题上

形式

本质上就是直方图

问题现状树法

认为问题是由一系列因果关系产生的

系统思考法

认为问题是由一系列因果关系产生的，而且包括促进因和阻碍因两种

干系人识别与分析

干系人识别

什么是干系人？

英文:Stakeholder，也被译为“涉众、利益相关者、风险承担人”等

筹码（比重）

操作层：手握“铜币”，BA与操作层打交道太多，项目延误的可能性很大

中层：手握“银币”，BA与中层多打交道，项目延误率较低

高层：手握“金币”，BA与高层多打交道，项目延误率很小，且人数最少

常见误区

需求分析师经常认为客户高层（职位高权力大）说的要求或需求都很重要，优先级应该要拍的很高。要问这么几个问题：
- 说话的领导是真的关心这事吗？
- 这事成与不成与他利益相关度很高吗？
- 他是主管该部门或业务的吗？
- 他为什么要提出这个要求/需求呢？
大家往往都过分关注“影响力”而忽略了“相关度”，领导提出某个需求可能仅仅是因为会议其他大领导都在，他又不得不发言，其实他并不涉及系统，所以就提出了一些“边角料”的反馈，说的再高大上、合理化些，可能过去他立马就会忘记。
所以在实践中，要关注“影响力”，更多的要关注“相关度”。不相关的人说啥其实都不是很重要

任务执行指引

根据目标识别关键干系人

首先收集客户的组织架构

然后根据目标判断，标识出所有涉及的部门

将部门负责人、分支机构负责人（可选）标识为关键干系人

根据风险补充其他关键干系人

是否对基层大量人员造成负面影响？如果是，将基层用户标识为关键干系人

组织内是否有人具有“一票否决权”？这时要注意分析关键干系人的关键需求

技术实施是否存在高风险？技术实现、实施过程存在困难或风险时，开发团队成为关键干系人

产物

《干系人列表》

类型

出资人/发起人：通常不必列出，目标分析（需求定义）的产物就是他们的核心关注点

使用者：未来会直接或间接使用系统的用户

评价者：通常是财务、审计、法规、行业监管部门等会提出验收标准的，通常拥有一票否决权

其他：开发团队、运营团队、技术专家等

名称：干系人的名称，通常以职位或角色的形式描述

说明：说明他为什么是我们的关键干系人

相关度：分为“高、中、低”三级，描述项目与他的相关度

影响度：分为“高、中、低”，描述他对项目的影响力

干系人分析

任务执行指引

选择干系人代表：选择一位或几位具有代表性、典型性的干系人

访谈干系人：通过访谈等手段，收集原始需求信息

分析关注点：从中分析关键关注点和阻力点

分析角度

关注点：干系人希望系统能够提供的业务支持

阻力点：干系人希望避免出现什么样的负面影响

描述部分

干系人关注点/阻力点

相应的功能需求

干系人关注点整理：横向评估不同关键干系人之间关注点之间的冲突，并制定处理冲突的策略

产物

《干系人档案》

基本信息

名称

类别

相关度

影响度

代表：具体到人的姓名、职位

职责：该干系人的工作职责要点

联系方式

核心关注点

编号

内容：说明干系人的关注点或阻力点（可以考虑写成相应的功能）

重要性：使用“关键、重要、有用、一般”评估

备注

需求范围定义描述

常见问题

传统的划分方法经常是采用“业务名词+管理”（“自顶向下的程序”分解结构）的形式命名的，其中业务名词实际上就是业务实体，也就是“物”的线索；对于大多数业务系统而言都不是最佳的分解方式，因为这些业务实体会牵涉到大量的业务流程，流程势必会贯穿多个客户部门。
结构化划分割裂了流程/使用场景，使得用户无法介入到需求范围的评价中，使得需求范围执行时存在困难，且使用结构化分解得到的子系统（模块）的内容经常交错在一起，导致了需求捕获、分析无法实现有效的分工

正确思路

业务驱动、以用户为中心：应该采用业务导向的层次结构来整理
通俗来讲，就是根据业务流程来分解（以“事”为线索）

执行步骤

业务子系统划分

任务执行指引

划分业务子系统：根据系统特点，选择合适的划分策略进行分解

直接分析：基于原有系统升级与改造，直接分析是否增加新的子系统

按业务职能分解：针对支撑、管理业务的系统（对内）

按产品/服务分解：主要针对外部服务系统

不要拿个锤子看啥都是钉子

双维度划分：比如先按照产品/服务划分（对外），二级按照业务职能（对内）划分

按关键特性分解：针对偏向“计算机领域”的系统