接前一篇文章：软考 系统分析师系列知识点之需求管理（1）

所属章节：

第11章. 软件需求工程

        第8节. 需求管理

11.8.2 需求风险管理

人们做事情总希望一帆风顺，做项目也是如此，总是希望项目进展顺利，按照计划如期交付。但现实却总是残酷的，会有许多潜在威胁和阻碍项目按计划进行的因素，这就是风险。风险可能会给项目成本、进度、质量和团队工作效率等方面带来负面影响。当然，所谓“塞翁失马焉知非福”，风险有时候也能给项目带来机会。

风险管理的目的就是希望让项目管理人员能够“掌控”风险，风险事件一旦发生，能够按照预先制定的应对计划有条不紊地处理风险。

1. 带有风险的做法

系统分析师在进行需求开发的过程中，有时也会“陷自身于困境”，无意之中给项目带来风险。这些做法列举如下：

（1）无足够用户参与

在需求获取的过程中，如果没有足够的用户参与，系统分析师所获得的需求就是片面的和不完整的。这样，在需求开发之初就埋下了风险。

（2）忽略了用户分类

用户不止一个人，各类用户有其自身的特点和需求。如果系统分析师不能针对所有主要用户进行分类，就必然会导致有的用户对产品感到失望。例如，菜单驱动操作对高级用户来说太低效了，但命令和快捷键又会使不熟练的用户感到困难。

（3）用户需求的不断增加

需求蔓延有可能引起项目范围蔓延，而这是项目中的大忌，因为它会对项目成本、进度和质量等方面带来很大的负面影响，甚至直接导致项目失败。

（4）模棱两可的需求

模棱两可的需求会使不同的项目干系人产生不同的期望，会使开发人员为错误问题而浪费大量时间。

（5）不必要的特性

这是技术人员的一个通病，喜欢画蛇添足。经常发生的情况是，用户并不认为这些添加的“足”很有用，以致在其上耗费的努力白搭，浪费项目资源。

（6）过于精简的SRS

过于精简的SRS为用户和开发人员提供了“无限遐想”的机会，却给项目带来了无限的麻烦，导致不断地修改，项目完工遥遥无期。

（7）不准确的估算

系统分析师在信息不充分的情况下，如果未经深思就对需求做出估算，则这种估算通常只是一种猜测而已。一旦传递给用户，他们却认为这是一种承诺。

2. 与需求有关的风险

项目风险管理的一个主要过程是识别风险，也就是要“预知”项目进展过程中可能会发生的风险，然后对其进行分析，制订相应措施。根据业内人士的经验，与需求有关的主要风险及其应对措施如下表所示：

阶段	主要风险	风险应对措施
需求获取	产品试图与范围	在项目早期写一份项目视图与范围文档，将业务需求涵盖在内，并将其作为新的需求及修改需求的指导
	需求开发所需时间	记录所参与的每个项目中实际需求开发的工作量，这样就能知道所花的时间是否合适，并改进将来项目的工作计划
	忽略市场对产品的反馈信息	强调市场调查研究，建立原型，并运用客户核心小组来获得产品的反馈信息
	没有非功能需求	编写非功能需求文档和验收标准，作为可接受的标准
	客户反对产品需求	确定出主要的客户，并采用产品代表的方法来确保客户代表的积极参与，确保在需求决定权上有正确的人选
	期望需求	尽量识别并记录用户的期望，提出大量的问题来提示用户，以充分表达他们的想法和建议
	将已有的产品作为需求基线	将在逆向工程中收集的需求编写成文档，并让用户评审以确保其正确性
	给出期望的解决办法	从用户描述的解决方法中提炼出其本质需求
需求分析	划分需求优先级	评估每项新需求的优先级，并与已有的工作对比，以做出相应的决策
	带来技术困难的特性	分析每项需求的可行性，以确定是否能按计划实现
	不熟悉的技术、工具、平台	明确那些高风险的需求，并留出充裕时间进行学习、实验和测试原型
需求定义	系统分析师和用户对于需求的不同理解	使用高水平的系统分析师；使用模型和原型，使一些模糊的需求变得清晰
	时间压力对待确定因素的影响	记录解决每项待确定因素的负责人的名字、如何解决的，以及解决的截止日期
	SRS的完整性和正确定	以用户的任务为中心，采用用例技术获取需求；根据场景写需求测试用例，建立原型；让用户代表对SRS和分析模型进行正式评审
	具有二义性的术语	建立一本术语和数据字典，用于定义所有的业务和技术词汇
	需求说明中包括了设计	仔细评审SRS，以确保它是在强调“做什么”，而非“怎么做”
需求验证	未经验证的需求评审	从用户代表方获得参与需求正式评审的承诺，并尽早通过非正式评审
	审查的有效性	对参与需求评审的所有人员进行培训，以使评审工作更加有效
需求管理	需求变更	将项目视图与范围文档作为变更的参照；用户积极参与需求获取过程；将那些易于变更的需求用多种方案实现，并在设计时注意其可修改性
	需求变更过程	建立规范的变更控制流程，并严格执行
	未实现的需求	使用需求跟踪能力矩阵或相关工具
	项目范围蔓延	在项目早期编制视图与范围文档，并得到用户确认；采用迭代式开发方法

系统分析师和项目管理人员可以利用上表来识别项目中的需求风险。但要注意的是，上表只是一个总结性的风险清单。具体到每一个项目，可能都会有些不同，需要根据实际情况进行增加或删减。在风险应对措施方面，也需要根据经验和项目约束，进行调整或改进。

更多内容请看下回。