12个问题帮你搞定需求风险评估

lovedemon · 发表于 2012-12-5 15:24:54

在如今的IT行业中，需求决定项目已经是一个广泛的共识，项目是否做的好与需求密切相关，越晚发现问题，对项目的影响越大，越容易造成项目成本的不可控。理想状态下的一个项目，在需求阶段就能把所有的问题都找到，这样在后期的项目实施时才能合理的规避这些问题，也就是规避那些风险。
  但是早期获得的需求是停留在业务层面的需求，都是简单的描述功能需要，无法对项目起到有积极意义的影响，甚至有时候影响反而是负面的，更谈不上找问题了。简简单单的一句功能描述，后期的项目团队根本无所适从，这条需求该花费多大的精力去实现它？该给予多大的关注程度？这些问题如果不在早起需求阶段加以强调，到后期很可能会导致严重的问题最终导致项目的失败。那么项目团队如何能在这些需求里识别出可能存在的风险，并予以标注，以便后期开发测试时着重注意以避免可能出现问题呢？
  显然拍脑门的做法是不值得的推荐的，原因很简单，它不科学。那么在早期信息量很少的情况下我们如何来做基本的判断呢？我推荐给大家12个问题，通过这12个问题，我们能够在项目成了之初，就能初步的确定一个需求的风险程度，根据这个风险程度，我们就能合理的那排工作时间，以及需求关注程度以避免后期不可控的问题。
  我将12个问题分别是：
  进程类型
故障的影响
使用频率
受影响用户的数目/重要性
更改类型
软件完备性
缺陷率
受影响的屏幕/实地数目
逻辑进程步骤数
所涉及的数据量
对其他系统的依赖关系
进程中的计算级别
看上去12个问题很乱，也无从下手，但是如果我们将12个问题梳理一下，按照三个大类进行梳理，我们就能比较清晰的理解这12个问题其实并不是杂乱无章的，而是每个问题都有所指的，按照哪三类呢？
业务严重性：
进程类型
故障的影响
使用频率
受影响用户的数目/重要性
失败可能性
更改类型
软件完备性
缺陷率
受影响的屏幕/实地数目
功能复杂性
逻辑进程步骤数
所涉及的数据量
对其他系统的依赖关系
进程中的计算级别
按照如上所示的分类，将12个小问题分为3个大类，立体的理解需求。
  当拿到一条需求我们的脑子里要首先划分出这三个类问题，通过这三个类问题将一条平面的需求立体化。在通过这3大类所包含的12个问题，将这3大类充实化。但是虽然有了这12个问题，我们怎么确定每个需求的风险呢？这里就需要一个计分系统，也就是说我们给每个问题一些可选的答案，并给这些答案赋予相应的权重，当我们回答这12个问题后，通过12个问题的答案，我们计算出每条需求的权重值，然后比较每条需求的权重值，通过这个计算模型我们就能得出我们所要面对的诸多业务需求的风险程度。
  每个人对12个问题的理解可能是不同的，给出的答案和权重也可能是不同的，我推荐给大家一套比较通用的答案，以供大家参考和分析
首先以业务严重性这一类来说，它包含了进程类型，故障的影响，使用频率，受影响用户的数目/重要性，这4个问题。
我们逐条进行分析。
进程类型：顾名思义，他的意思是要实现这条需求我们所要调用的进程是哪些类型进程他所提供的答案应该包括：数据更改，计算/验证，显示。并且分别设置不同的权重
计算/验证-由需求表示的功能是重要的计算或验证。无疑应该是活的最高权重的答案，我们将其权重设计为30
数据更改-由需求表示的功能将修改应用程序数据，我们将其设计为18
显示-由需求表示的功能将修改应用程序显示，它是最低权重，权重为8
以此类推，我们给其他问题对应的答案和权重
故障的影响：未满足需求对业务的影响。
  合法 - 可能存在合法的结果。权重30
错误信息 - 用户可能接收不准确的信息，但不会具有合法的结果。权重18
无影响 - 不会影响用户。权重8
使用频率：由需求表示的功能的使用频率。
非常频繁 - 该功能使用非常频繁。权重30
频繁 - 该功能使用相对频繁。权重18
很少 - 该功能很少使用。权重8
受影响用户的数目/重要性：受需求影响的用户数目以及受影响的用户对业务的重要程度。
多/高  - 该需求将影响许多用户或对业务具有高重要性的用户。权重30
组/中 - 需求将影响某些用户或对业务具有中等重要性的用户。权重18
少/低 - 该需求将影响少量用户或对业务具有最小重要性的用户。权重8
由于以上权重值，当我们回答完这4道题时，这一条需求在业务严重性这个环节上就得到了一个总权重，我们再将这个总权重与我们设定的权重范围进行比较，就能知道此条需求的风险了。
比如，将权重范围设为：A-严重，B-重要，C-良好，并且设定每个范围的权重值
A- 严重 76<=总权重<120
B- 重要 52<=总权重<76
C- 良好 32<=总权重<52
通过以上的权重模型，当拿到一条需求时，我们就可以通过回答简单的4道问题，得到该条需求在业务严重性方面的风险程度。为项目组决策这条需求提供了一个比较明确的信息，以便后续的项目成员能更好的在这条需求上分配工作时间和关注程度。
有了业务严重性这个作为例子，其他两类问题，我们也可以很简单的获得相应的数据
失败可能性：
更改类型：需求代表的功能是新功能、更改的功能还是未更改的功能。
新功能 - 需求代表此版本中的新功能。权重30
已更改的功能 - 需求代表先前已存在，但已在此版本中更改的功能。权重18
未更改的功能 - 需求代表自先前版本以来未更改的功能。权重8
软件完备性：由需求表示的功能代码的完备性。
不完备 - 该代码不完备。权重30
中等 - 代码的完备程度为中等。权重18
完备 - 代码的完备程度为高级。权重8
缺陷率：可能已打开的与需求相关的缺陷数的估计值。
高 - 可能已打开较多数目的缺陷。权重30
中等 - 可能已打开中等数目的缺陷。权重18
低 - 可能已打开较少数目的缺陷。权重8
受影响的屏幕/实地数目：受需求影响的应用程序屏幕和实体数目。
> 4。权重30
2-4．权重18
< 2。权重8
我们按照业务严重性的权重分配规则，给失败可能性这类问题也分配权重，将权重范围设为：A-高，B-中，C-低，并且设定每个范围的权重值
A- 高 76<=总权重<120
B- 中 52<=总权重<76
C- 低 32<=总权重<52
  由此我们又能得出一条需求在失败可能性所存在的风险。
  最后我们进行功能复杂性的风险评估
  功能复杂性：
  逻辑进程步骤数：用于执行业务活动的逻辑步骤数。
  3个以上。权重30
  2-3个。权重18
少于2个。权重8
所涉及的数据量：包含必须填写的字段数以及对源自不同进程的数据的依赖
最大数量。权重30
中等数量。权重18
最小数量。权重8
对其他系统的依赖关系：
外部依赖关系。权重30
仅内部依赖关系。权重18
无依赖关系。权重8
进程中的计算级别：
复杂。权重30
中等。权重18
简单。权重8
我们按照业务严重性的权重分配规则，给功能复杂性这类问题也分配权重，将权重范围设为：A-高，B-中，C-低，并且设定每个范围的权重值
A- 高 76<=总权重<120
B- 中 52<=总权重<76
C- 低 32<=总权重<52
  由此我们又能得出一条需求在功能复杂性所存在的风险。
当我们拿到一条新的需求时，通过回答3大类，12个小问题，我们能很快的能从理性的角度分析出一条需求在业务严重性，失败可能性和功能复杂性上所存在的风险。这对我们后续项目活动起着很好的指导作用。如果我们能将我们所有的需求都回到以上这些问题，那么我就可以根据所得到的值对所有需求进行风险排序，这样开发和测试在后续的工作中将不再盲从他们将有章可循。哪些需求需要加大开发测试力度，哪些需求不需要耗费过大的人力物力资源一目了然。
在IT行业竞争日益激烈的今天，最快最好的完成项目是我们一直在研究的课题，而良好的需求分析无疑是完成项目的第一步，我这里告诉大家的这个方法不是最好的方法，但是希望它能帮助你找到需求分析的一条思路。