第22章节 需求风险管理.pptVIP

第22章 需求风险管理 所谓风险就是可能给项目的成功带来某些损失或威胁的情况。 由于需求在软件项目中具有十分重要的地位，所以精明的项目管理者应尽早确定与需求相关的风险并积极主动地控制它们。 典型的需求风险包括： 误解需求。 用户的参与不恰当。 项目范围和目标不确定或随意进行变更。 对需求不断进行变更等。 本章将对软件风险管理进行简要介绍(Wiegers 1998b)。本章后面还会提到需求工程活动中出现的许多风险因素 软件风险管理基本原理 除了与项目范围和需求有关的风险外，项目还面临着许多其他风险。 对外部实体的依赖就是一种常见的风险来源。 项目管理一直面临各种风险的挑战：评估不准确、管理人员拒绝开发人员的准确评估、对项目状态不了解以及进行了人员调整等原因所引起的风险。 技术风险威胁着高度复杂或很前沿的开发项目。 知识的缺乏是风险的另一种来源，另外还有参与者对所用的技术或项目应用领域经验不足。经常变更的或强制执行的一些政府规定可能会使最好的项目规划彻底作废。 风险管理的要素 风险管理(risk management)就是使用某些工具和步骤把项目风险限制在一个可接受的范围内。 风险管理提供了一种标准的方法，可以指出风险因素并将其编写成文档，评估这些风险的潜在威胁，并提出减少这些风险因素的战略。 风险管理包括图所示的这些活动。 风险评估(risk assessment)是一个对项目进行检查以确定潜在风险领域的过程。 风险避免(riskavoidance)是处理风险的一种方法，也就是尽量不要做冒险的事。 编写项目风险文档 只是认识到项目所面临的风险是远远不够的，我们还必须以某种方式对风险进行管理，以便在整个项目开发过程中可以将风险问题和状态传达给项目的涉众。 图展示了一个模板，用于对单个风险编写文档。 制定风险管理计划 对于小型项目，可以把控制风险的计划包括在软件项目管理计划内。 但对一个大型项目，则应该编写一个单独的风险管理计划，详细说明打算采用哪些方法来识别、评估、编档和跟踪风险。这一计划还应该包括风险管理活动的角色和职责。 要建立起周期性进行风险监控的措施。 与需求相关的风险 下面介绍的这些风险因素，是按照需求工程的分支过程组织的，即需求获取、需求分析、编写需求规格说明、需求确认和需求管理过程。 推荐的方法可以减小风险发生的可能性或风险发生后给项目造成的影响。 与需求有关的风险 无足够用户参与 用户需求的不断增加 模棱两可的需求 不必要的特性 过于精简的规格说明 忽略了用户分类 不准确的计划 需求获取 产品前景和项目范围 应该在项目早期，编写一份包括业务需求在内的前景和范围文档，并将它作为添加新需求和修改现有需求的指导。 需求开发所需的时间 将每个项目中需求开发所耗费的实际工作量记录下来，这样就可以判断出需求开发是否充分，并可以改进未来项目的工作计划。 需求规格说明的完整性和正确性 为了确保需求是客户真正需要的，应该以用户任务为中心，应用用例技术来获取需求。 创新产品的需求 对某类产品中的第1个产品，不太容易把握市场对产品的反映。 定义非功能需求 由于我们一般都会强调产品的功能，所以很容易忽略产品的非功能性需求。 需求获取 客户对产品需求意见一致 确定那些主要的客户，并采用产品代言人的方法，保证有足够的客户代表的积极参与 未加说明的需求 客户经常会有一些隐含的期望要求，但并未以文档的方式说明出来。尽量识别客户可能做出的任何假设。 把已有的产品作为需求基线来源 将通过逆向工程发现的需求编写成文档，让客户评审这些需求，以确保其正确性和相关性。 根据需要提出解决方案 分析人员必须提炼出隐藏在客户提出的解决方案背后的真正意图。 需求分析 设定需求优先级 要确保对每一个功能需求、特性或用例都设定了优先级，并安排在一个特定的系统版本或迭代中实现它们。 技术上难以实现的特性 采用项目状态跟踪来监控落后于实现计划的需求，并尽早采取纠正措施。 不熟悉的技术、方法、语言、工具或硬件 留出足够的时间用于从错误中学习经验、实验及制作原型。 编写需求规格说明 需求理解 开发人员和客户对需求的不同理解会导致彼此间的期望差距，并最终导致交付的产品无法满足客户的需要。 尽管问题待确定但迫于时间压力而继续向前 在软件需求规格说明中，将需要进一步研究的地方标上TBD，不失为一个好主意。 具有二义性的术语 对于不同的读者可能会有不同解释的业务术语或技术术语，应该创建一个术语表对这些术语进行定义。 需求中包括了设计 软件需求规格说明中所包含的设计对开发人员做出有效选择造成了不必要的限制，会妨碍他们发挥创造性设计出最佳方案。 需求确认 未经确认的需求 软件需求规格说明会令人望而生畏，在开发过程早期编写测试用例的想法就是基于