软件需求第5章(编辑修改稿)

软件需求第5章(编辑修改稿)内容摘要：

害结果（如果风险成为事实）。 有时，人们只说明了风险条件（如“客户不同意产品的需求说明”）或者只说明了结果（“我们只能满足某些主要的客户”）。 最好将这样的说明句子合并成条件 —— 结果形式的结构：“如果有些客户不赞同 产品的需求说明，那我们只能满足某些主要客户的意见。 ”而一个条件下可能有多个结果，同时也可能出现多个条件下导致同一个结果。 模板能记录风险变为事实的可能性及对项目的消极影响，还有整个的风险危害值（可能性 影响）。 我用 （极不可能）到 （肯定发生）来描述可能性，用 1（无甚么影响）到 10（有很深、很大的影响）来表示影响。 将这两个因素相乘即可作为评估风险危害值的依据。 不要试图精确量化风险。 你的目标是将最有威胁的风险和那些不急需处理的风险区别开来。 大家可能更愿意用高、中和低来估计可能性及影响。 但风险条目中至 少应有一个为高的风险。 制定降低风险计划来明确控制风险要采取的活动，其中一些策略是尽量降低风险发生的可能性；而另一些则是减少风险发生后带来的影响。 做计划时要考虑降低风险所耗费用，千万别花费 20， 000美元来控制一项仅会损失 10， 000美元的风险。 为每项风险安排一个负责人，并确定完成活动的截止日期。 长期或复杂的风险可能需要具有多个阶段性成果的多步骤降低风险策略计划。 图 53说明了本章开始部分介绍的“化学制品跟踪系统”小组领导者讨论的一个风险。 小组凭他们以前的经验估计了风险的可能性及其影响。 除非他们把其它风险 因素也估计出来，否则他们并不明白风险危害值。 降低风险措施的前两条是通过更多的用户参与项目来减少风险发生的可能性。 而采用原型法则可以利用用户关于界面的早期反馈来减少风险的潜在影响。 制定风险管理计划 一张风险列表还不等于一个风险管理计划。 对于一个小项目，你可以把控制风险的计划放在软件项目管理计划里。 但一个大项目则需要一份独立的风险管理计划，包括用于识别、评估、编写、跟踪风险的各种方法与途径。 这份计划还应包括风险管理活动的角色和责任。 你可能希望专门让一个项目风险管理人员负责可能引起麻烦的事。 通常，项目小组为他们的关键活动制定了计划，却在项目中没有按计划去实施或者未能按实际情况进行及时的调整。 要坚持按照所采取的风险管理活动计划去执行。 项目的进度安排上也应给风险管理留出足够时间来确保项目并未浪费早期投资在风险计划制定上。 工程项目的工作分类细目结构中包括降低风险的活动、状态报告，以及更新风险清单。 和其它项目管理活动一样，你需要建立起周期性的监控措施。 保持对十来个有最大危害的风险的高度重视，并追踪降低风险措施的有效性。 当完成一项活动后，重新评估那项风险的可能性和影响，更新风险清单和其它相关的计划。 当 控制住原本有很高优先级的风险后，必然有新条目会进入前十条。 请记住，不要仅仅因为完成了一项降低风险的活动而人为去增加一条风险来进行控制。 你应当想想你降低风险的方法是否的确减少了风险的危害，使其减少到了一个可以接受的水平。 45b3ab679e853e21c524018e30c33611 46 图 53 化学制品跟踪系统的风险条目样例 与需求有关的风险 下面几页介绍的风险因素是按需求工程中获取、分析、编写规格说明、验证和管理汇总起来的，并推荐了一些方法用于降低风险发生的可能性或减轻风险发生给项目带来的影响。 这张清单仅仅是一个起点，在你做项目逐渐积累经验过程中，加入你的风险因 素清单和减轻风险的策略。 使用这里提供的条目来帮助你识别需求风险并采用条件 —— 结果的格式来书写风险说明。 需求获取 产品视图与范围。 如果团队成员没有对他们要做的产品功能达成一个清晰的共识，则很可能导致项目范围的逐渐扩大。 因此最好在项目早期写一份项目视图与范围将业务需求涵盖在内，并将其作为新的需求及修改需求的指导。 化学制品跟踪系统的风险条目样例 序列号： 1 确定日期： 5/4/99 撤消日期： 描述： 需求获取中无合适用户参与 ,导致测试之后用户界面的返工 . 可能性： 影响： 7 危害值： 降低风险计划： 1．在第一阶段早期就要收集易学、易用的需求。