第22章 需求风险管理

第22章需求风险管理所谓风险就是可能给项目的成功带来某些损失或威胁的情况。由于需求在软件项目中具有十分重要的地位，所以精明的项目管理者应尽早确定与需求相关的风险并积极主动地控制它们。典型的需求风险包括：误解需求。用户的参与不恰当。项目范围和目标不确定或随意进行变更。对需求不断进行变更等。本章将对软件风险管理进行简要介绍(Wiegers1998b)。本章后面还会提到需求工程活动中出现的许多风险因素2软件风险管理基本原理除了与项目范围和需求有关的风险外，项目还面临着许多其他风险。对外部实体的依赖就是一种常见的风险来源。项目管理一直面临各种风险的挑战：评估不准确、管理人员拒绝开发人员的准确评估、对项目状态不了解以及进行了人员调整等原因所引起的风险。技术风险威胁着高度复杂或很前沿的开发项目。知识的缺乏是风险的另一种来源，另外还有参与者对所用的技术或项目应用领域经验不足。经常变更的或强制执行的一些政府规定可能会使最好的项目规划彻底作废。风险管理的要素风险管理(riskmanagement)就是使用某些工具和步骤把项目风险限制在一个可接受的范围内。风险管理提供了一种标准的方法，可以指出风险因素并将其编写成文档，评估这些风险的潜在威胁，并提出减少这些风险因素的战略。风险管理包括图所示的这些活动。风险评估(riskassessment)是一个对项目进行检查以确定潜在风险领域的过程。风险避免(riskavoidance)是处理风险的一种方法，也就是尽量不要做冒险的事。编写项目风险文档只是认识到项目所面临的风险是远远不够的，我们还必须以某种方式对风险进行管理，以便在整个项目开发过程中可以将风险问题和状态传达给项目的涉众。图展示了一个模板，用于对单个风险编写文档。制定风险管理计划对于小型项目，可以把控制风险的计划包括在软件项目管理计划内。但对一个大型项目，则应该编写一个单独的风险管理计划，详细说明打算采用哪些方法来识别、评估、编档和跟踪风险。这一计划还应该包括风险管理活动的角色和职责。要建立起周期性进行风险监控的措施。

注意： 不要想当然地以为，在识别出了风险并采取了降低风险的相应活动之后，风险就会处于您的控制之下。接下来还要实行风险管理活动。与需求相关的风险下面介绍的这些风险因素，是按照需求工程的分支过程组织的，即需求获取、需求分析、编写需求规格说明、需求确认和需求管理过程。推荐的方法可以减小风险发生的可能性或风险发生后给项目造成的影响。与需求有关的风险无足够用户参与用户需求的不断增加模棱两可的需求不必要的特性过于精简的规格说明忽略了用户分类不准确的计划需求获取产品前景和项目范围应该在项目早期，编写一份包括业务需求在内的前景和范围文档，并将它作为添加新需求和修改现有需求的指导。需求开发所需的时间将每个项目中需求开发所耗费的实际工作量记录下来，这样就可以判断出需求开发是否充分，并可以改进未来项目的工作计划。需求规格说明的完整性和正确性为了确保需求是客户真正需要的，应该以用户任务为中心，应用用例技术来获取需求。创新产品的需求对某类产品中的第1个产品，不太容易把握市场对产品的反映。定义非功能需求由于我们一般都会强调产品的功能，所以很容易忽略产品的非功能性需求。需求获取客户对产品需求意见一致确定那些主要的客户，并采用产品代言人的方法，保证有足够的客户代表的积极参与未加说明的需求客户经常会有一些隐含的期望要求，但并未以文档的方式说明出来。尽量识别客户可能做出的任何假设。把已有的产品作为需求基线来源将通过逆向工程发现的需求编写成文档，让客户评审这些需求，以确保其正确性和相关性。根据需要提出解决方案分析人员必须提炼出隐藏在客户提出的解决方案背后的真正意图。需求分析设定需求优先级要确保对每一个功能需求、特性或用例都设定了优先级，并安排在一个特定的系统版本或迭代中实现它们。技术上难以实现的特性采用项目状态跟踪来监控落后于实现计划的需求，并尽早采取纠正措施。不熟悉的技术、方法、语言、工具或硬件留出足够的时间用于从错误中学习经验、实验及制作原型。编写需求规格说明需求理解开发人员和客户对需求的不同理解会导致彼此间的期望差距，并最终导致交付的产品无法满足客户的需要。尽管问题待确定但迫于时间压力而继续向前在软件需求规格说明中，将需要进一步研究的地方标上TBD，不失为一个好主意。具有二义性的术语对于不同的读者可能会有不同解释的业务术语或技术术语，应该创建一个术语表对这些术语进行定义。需求中包括了设计软件需求规格说明中所包含的设计对开发人员做出有效选择造成了不必要的限制，会妨碍他们发挥创造性设计出最佳方案。需求确认未经确认的需求软件需求规格说明会令人望而生畏，在开发过程早期编写测试用例的想法就是基于这一点。审查熟练程度要对参与需求文档审查的所有团队成员进行培训，请组织内部有经验的审查人员或外界的咨询顾问来评述早先的审查。需求管理变更需求将前景和范围文档作为批准需求变更的参照，可以减少范围蔓延。需求变更过程与需求变更的处理方式相关的风险包括，缺少已定义的变更过程，采用无效的变更机制，以及不遵循制定的过程来做出变更。未实现的需求需求跟踪矩阵有助于在设计、构造或测试期间避免遗漏任何需求。扩大目范围如果最初的需求定义不够好，那么进一步定义需求就会扩大项目的范围。风险管理是我们的好帮手周期性地进行风险跟踪可以使项目经理了解风险对项目的威胁，没有得到有效控制的风险应该上报高层管理人员，他们可能开始采取一些纠正措施，也可能不管风险，依旧按照原来的业务决策思路进行。即使不能控制项目可能遇到的所有风险，风险管理也能帮助我们看清形势，做出合理的决策。风险管理的措施明确你当前项目面临的一些与需求有关的风险，不要把当前的问题当作风险，一定要是那些还未发生的事情。将风险因素编写成文档，为每项风险推荐至少一种可能的降低风险的方法。风险管理的措施召集代表开发、市场、客户和管理各方面的涉众召开风险“集体研讨”会议。尽力找出更多与需求有关的风险因素。估计每项风险发生的可能性及其影响，两者乘积就是风险危害值。通过按风险危害值降序排列找到最高的五项风险。为每项风险安排一个负责人负责实施降低风险的活动。第23章需求跟踪需求跟踪提供了一个表明与合同或说明一致的方法。更进一步，需求跟踪可以改善产品质量，降低维护成本，而且很容易实现重用。需求跟踪链使你能跟踪一个需求使用期限的全过程。通用的跟踪模型显示了我们要在软件开发的不同层面全面地跟踪需求。需求跟踪动机CMM的第三层次要求具备需求跟踪能力。需求跟踪的定义[IEEE，1994]

开发过程的两个或多个产品之间能够建立关系的程度，尤其是那些具有前后关系或主从关系的产品。例如，某个给定组件的需求和设计的匹配程度。软件开发产品中每个元素能够建立其存在理由的程度；例如，数据流图中的每个元素定位它所满足需求的程度。跟踪关系需求跟踪链通用的跟踪模型跟踪矩阵：用户需要与特性

跟踪矩阵：特性与用例跟踪矩阵：特性与非功能性需求

在实现领域跟踪需求从用例跟踪到用例实现（一）从用例实现跟踪到实现（二）从补充需求跟踪到实现在测试领域跟踪需求跟踪场景到测试用例从用例到测试用例的跟踪矩阵

第24章需求管理工具商业需求管理工具，包括让用户从源文档中产生需求，定义属性值，操作和显示数据库内容，让需求以各式各样的形式表现出来