SERU-需求定义思维导图模板_ProcessOn思维导图、流程图

需求定义常见问题

项目立项阶段开发团队（包含需求分析师）还没有开始工作，甚至团队还未成立

事后补课，必须认真审视需求定义阶段的产物

项目立项输出的目标与泛微很空洞，难以落实，如：全面提高企业信息化应用水平

通过内部寻根或外部溯源来破解混沌不清的项目目标

内部寻根：尝试寻找真正的项目发起人，和这些项目发起人进行深入沟通

外部溯源：外部因素所激发的项目，需求定义时要找到目标参照物，通过对目标参照物的分析与了解，做好需求定义工作

需求定义是什么

需求定义四进阶GPOA

定义目标：通过内部寻根或外部溯源的方法，先将整个项目要解决的问题或机会罗列出来，例如“废品率太高”

寻找问题根源：针对目标层面的问题进行分析，找到导致该问题产生的根源问题，然后将其全部列出来，例如“订单不准确”、“运输损耗”等

提出可选方案：针对每个问题罗列出可能解决的方案，例如针对“订单不准确”问题，可选方案可以包括“用户直接通过电子化手段下订单”、“对订单内容进行电子化校核”等

建议方案：从各种可选的方案中挑出认为比较合理，对解决问题贡献度更高的方案

需求定义策略

问题分析五步法

在问题定义上达成共识

手段： 采用统一的格式（模板）写出来就是很有效的手段

RUP建议模板4大要素

问题/机会定义：描述真实世界中存在的问题或潜在的机会

影响人群：该问题影响的主要人群有哪些

影响结果：该问题对这类人群产生了什么影响

系统预期：预期什么样的解决方案，希望系统应该具备哪些优点

问题定义技巧

转换： 要善于将未知解问题转换成已知解问题，注意如何将客户的需求转换成自己的已有产品或者熟悉的场景

本源： 问题经常会被表象所掩盖，要寻找问题本质，直接修改错误，不要用其他方案来弥补错误。 但在确定某问题的解决方案时，一定要思考是否会引发新问题

影响人群分析： 根据影响用户的年纪段、性别、区域等自然因素进行分析

理解根本原因（寻找问题的本源）

策略

鱼骨图（因果鱼骨图）

好处

使分析人员将问题原因而不是症状放在首位

提供给一种运用集体智慧解决问题的方式

直观、简明、易于操作

步骤

选择问题：选择一个具体的问题或结果

头脑风暴：对所有的问题进行头脑风暴，找到所有可能导致问题的潜在原因

确定原因类型：对头脑风暴的结果进行整理分类（一般不宜超过6种），确定出主要的原因类型

分配原因：将头脑风暴得出的潜在原因进行按类（原因类型）分配，保证每一项原因都归类于适合的类别中

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

帕累托图

作用

为80%的问题找出关键的20%的原因

一目了然的显示出每个原因的相对重要程度

有助于预防在解决了一些问题后，引入新的问题或者让其他问题变得更糟糕

步骤

确定问题和相关原因：在鱼骨图分析中已完成

收集数据：对每一个根本原因有针对性的收集数据，统计该原因造成问题的数量

绘制直方图：将原因放在横轴，数量信息置于纵轴，从数量从高到低绘制条形图，再用同一条线表示累计错误比率

确定相关人员和用户

Stakeholder解析

项目是一个博弈的游戏，有很多人都拥有相应的筹码，项目经理的目标就是尽可能多地获得筹码，只要获得的筹码足够多，项目就将获得成功： 操作层手里的筹码相对来说是很少的，人数最多； 中层管理人员手中有一定的筹码，人数较少； 高层管理人员手握着最有分量的筹码，而且人数极少。

用户分析

用户是指是直接使用系统的人群，也是Stakeholder的一类

了解用户的特点、能力，按照不同的角度对用户进行划分，然后对每类用户的特点进行分析，以便为后续的需求分析提供相应的信息

定义解决方案的界限

术语

范围：是指系统涵盖的内容，是涉及的事、物

边界：是指用户与系统的职责边界，是各自需要完成的事

边界管理策略

边界划分：梳理出业务场景流程，按照流程节点进行边界划分并按照先后顺序编号（从小到大编号）

边界确定：客户的预算是有限的，需要对每个边界右侧的系统实现进行工作量评估，以确定预算内边界的最小值

边界谈判：人永远希望用同样的钱干更多的事，在客户提出预算外的功能实现时，尽量从用户自身的困难和障碍触发说服客户，不要一开始就处处说开发的困难，更不要说“你要的功能太多了，这点投资是不够的！”，这种回复的说服力太有限了

创新边界：在客户预算充足甚至是预算可增加的情况下，为了争取更多的项目收益，可以考虑把顾客、顾客行为习惯纳入了系统的范围，在现有的业务流程基础上做前伸，创造原来没有的边界，继而扩大项目范围，索取更多项目经费

确定加在解决方案上的约束

技术开发约束

项目实施约束

需求定义的产物和重点

项目立项产物　

项目综述（POS）类：主要是项目型软件开发工作产出

愿景类（Vision）：主要是生命周期较长、应用面较广的项目或产品软件开发工作产出，更注重于对市场潜在机会的分析

需求定义重点

目标

好的目标描述应该满足SMART原则

S：Specific，必须能够指导具体的工作

M：Measurable，必须是可度量的，能够进行成本/效益分析

A：Attainable，必须是技术可实现的

R：Relevant，必须和其他目标有相关性

T：Time-Base，必须有明确的截止期限

目标的具体写作过程，主要关注的几个要素：目标、业务优势（带来的好处）、度量指标（数据指标）、合理性（经济可行性）、可行性（可以达到的结果）、可达成性（技术可行性）

范围

需求定义工作的核心工作就是确定范围，描述范围采用“两图一纲”（4.4节描述）