在需求过程当中,要通过网罗知识,与客户、顾客交流需求,清晰记录下需求,给出每条需求的验收标准,形成需求规格说明书,通过质量关的审查和确认。除此之外,还应进行风险分析。进行需求风险分析,可以针对这些需求风险事先制定缓解措施,这样可以在风险发生时将风险的影响降到最低。

下面所列的是要考虑的8种需求风险。

1. 缺少风险承担者参与

风险承担者,或者叫利益相关方,是那些对软件开发有影响的人。一般地,包括下列角色:用户、客户、顾客、项目负责人、产品经理、业务专家、设计、编码、测试、系统分析、QA、反对者、技术专家、相邻系统等。对着这一长串名单,可以比较一下,通常有几个是容易被忽略的,比如业务专家、反对者等。这条风险是比较常见的一条需求风险。

• 风险编号:Risk001

• 风险描述:由于缺少某个风险承担者的的参与,使得需求的收集不完整,可能会在软件开发过程中引入新的需求或重大的需求变更。

• 风险影响:高

• 风险发生概率:中

• 风险缓解措施:与未参与需求收集过程的风险承担者沟通,尽快收集她对软件的期望。

2. 需求上很少或不能达成一致

不同的风险承担者对于软件的期望有着不同的见解。在软件开发早期,应当使不同的风险承担者对需求的理解达成一致,避免因风险承担者对需求的不一致理解而给软件开发带来阻碍。

• 风险编号:Risk002

• 风险描述:由于存在不同的风险承担者对需求理解的不一致,可能会对软件开发的进度造成重大影响。

• 风险影响:较高

• 风险发生概率:中

• 风险缓解措施:召集风险承担者参与的需求讨论会,消除存在的需求理解的不一致问题。

3. 需求蔓延

随着软件开发的进程,用户或客户或顾客,可能会不断地提出新的需求,导致需求不断蔓延,以至于项目的进度和成本远远超出预期。

• 风险编号:Risk003

• 风险描述:由于用户不断提出新的需求,需求不断蔓延,可能会使项目的进度和成本超出预期。

• 风险影响:高

• 风险发生概率:低

• 风险缓解措施:与用户约定项目的范围,如果有新增的需求,应当协商增加项目的开发周期和成本。

4. 镀金需求

镀金需求,是那些锦上添花的需求。完成了镀金需求,可能会使用户满意度提高,不完成也不会使用户的不满意度增加。

• 风险编号:Risk004

• 风险描述:由于可能存在镀金需求,会对软件开发的进度带来一定影响。

• 风险影响:中

• 风险发生概率:中

• 风险缓解措施:针对每条需求,让客户或用户进行满意度和不满意度分析,以此确定需求实现的优先级,对于镀金需求,可以商定实现的时机。

5. 没有需求验收标准

每条需求,都应有相应的可量化的验收标准。这样,在测试需求是否实现的时候,有量化的数值可以准确无异议地作出判断。

• 风险编号:Risk005

• 风险描述:由于有需求未给出验收标准,可能对该需求的测试造成影响。

• 风险影响:高

• 风险发生概率:中

• 风险缓解措施:为需求建立量化的验收标准,必要时和用户或顾客进行沟通,理解其真正的需求。

6. 快速变化的需求

需求变化过于频繁。不断的需求变更,导致设计和实现不断变更,项目进度、成本、质量都会受很大影响。

• 风险编号:Risk006

• 风险描述:频繁的需求变更,可能对项目的进度、成本、质量造成很大影响。

• 风险影响:高

• 风险发生概率:低

• 风险缓解措施:与用户约定项目的范围,如果有频繁的需求变更,应当进行变更影响分析,尽量减少不必要的变更,如果一定要变更,应当协商增加项目的开发周期和成本。

7. 需求变更控制不够

如果需求变更控制不力,可能会使得不必要的需求变更过多,或者变更后的验证不充分,引入新的缺陷。 风险编号:Risk007 风险描述:由于需求变更控制不够,导致项目进度受严重影响。 风险影响:高 风险发生概率:中 风险缓解措施:加强需求变更影响分析,尽量减少不必要的变更;加强变更后的验证活动,尽量避免引入新的缺陷。

8. 新进入未知的业务,需求不确定

存在过多待定的需求,可能会在将来引入过多的需求变更。

• 风险编号:Risk008

• 风险描述:由于进入新的领域,业务不熟悉,存在过多的待定的需求,可能会引入较多的需求变更,影响项目的进度。

• 风险影响:高

• 风险发生概率:高

• 风险缓解措施:确定风险承担者时,要引入业务专家,并通过与业务专家的交流,减少由于业务不熟悉带来的过多的不确定的需求。