第22章 需求风险管理

第22章需求风险管理2所谓风险就是可能给项目的成功带来某些损失或威胁的情况。由于需求在软件项目中具有十分重要的地位，所以精明的项目管理者应尽早确定与需求相关的风险并积极主动地控制它们。典型的需求风险包括：•误解需求。•用户的参与不恰当。•项目范围和目标不确定或随意进行变更。•对需求不断进行变更等。本章将对软件风险管理进行简要介绍(Wiegers1998b)。本章后面还会提到需求工程活动中出现的许多风险因素软件风险管理基本原理除了与项目范围和需求有关的风险外，项目还面临着许多其他风险。对外部实体的依赖就是一种常见的风险来源。项目管理一直面临各种风险的挑战：评估不准确、管理人员拒绝开发人员的准确评估、对项目状态不了解以及进行了人员调整等原因所引起的风险。技术风险威胁着高度复杂或很前沿的开发项目。知识的缺乏是风险的另一种来源，另外还有参与者对所用的技术或项目应用领域经验不足。经常变更的或强制执行的一些政府规定可能会使最好的项目规划彻底作废。风险管理的要素风险管理(riskmanagement)就是使用某些工具和步骤把项目风险限制在一个可接受的范围内。风险管理提供了一种标准的方法，可以指出风险因素并将其编写成文档，评估这些风险的潜在威胁，并提出减少这些风险因素的战略。风险管理包括图所示的这些活动。风险评估(riskassessment)是一个对项目进行检查以确定潜在风险领域的过程。风险避免(riskavoidance)是处理风险的一种方法，也就是尽量不要做冒险的事。风险管理评估避免控制识别分析优先级管理计划解决方案监控编写项目风险文档只是认识到项目所面临的风险是远远不够的，我们还必须以某种方式对风险进行管理，以便在整个项目开发过程中可以将风险问题和状态传达给项目的涉众。图展示了一个模板，用于对单个风险编写文档。风险条目跟踪模板ID号：顺序号确定日期：风险的确认日期撤消日期：风险的撤消日期描述：以“条件-结果”的形式描述风险可能性：风险转变为问题的可能性影响：如果风险转变为问题会有多大的潜在危害危害值：可能性×影响降低风险计划：一种或多种控制、避免、最小化或降低风险的方法负责人：负责解决这一风险的人截止日期：完成降低风险活动的截止日期制定风险管理计划对于小型项目，可以把控制风险的计划包括在软件项目管理计划内。但对一个大型项目，则应该编写一个单独的风险管理计划，详细说明打算采用哪些方法来识别、评估、编档和跟踪风险。这一计划还应该包括风险管理活动的角色和职责。要建立起周期性进行风险监控的措施。注意：不要想当然地以为，在识别出了风险并采取了降低风险的相应活动之后，风险就会处于您的控制之下。接下来还要实行风险管理活动。与需求相关的风险下面介绍的这些风险因素，是按照需求工程的分支过程组织的，即需求获取、需求分析、编写需求规格说明、需求确认和需求管理过程。推荐的方法可以减小风险发生的可能性或风险发生后给项目造成的影响。与需求有关的风险无足够用户参与用户需求的不断增加模棱两可的需求不必要的特性过于精简的规格说明忽略了用户分类不准确的计划需求获取产品前景和项目范围•应该在项目早期，编写一份包括业务需求在内的前景和范围文档，并将它作为添加新需求和修改现有需求的指导。需求开发所需的时间•将每个项目中需求开发所耗费的实际工作量记录下来，这样就可以判断出需求开发是否充分，并可以改进未来项目的工作计划。需求规格说明的完整性和正确性•为了确保需求是客户真正需要的，应该以用户任务为中心，应用用例技术来获取需求。创新产品的需求•对某类产品中的第1个产品，不太容易把握市场对产品的反映。定义非功能需求•由于我们一般都会强调产品的功能，所以很容易忽略产品的非功能性需求。需求获取客户对产品需求意见一致•确定那些主要的客户，并采用产品代言人的方法，保证有足够的客户代表的积极参与未加说明的需求•客户经常会有一些隐含的期望要求，但并未以文档的方式说明出来。尽量识别客户可能做出的任何假设。把已有的产品作为需求基线来源•将通过逆向工程发现的需求编写成文档，让客户评审这些需求，以确保其正确性和相关性。根据需要提出解决方案•分析人员必须提炼出隐藏在客户提出的解决方案背后的真正意图。需求分析设定需求优先级•要确保对每一个功能需求、特性或用例都设定了优先级，并安排在一个特定的系统版本或迭代中实现它们。技术上难以实现的特性•采用项目状态跟踪来监控落后于实现计划的需求，并尽早采取纠正措施。不熟悉的技术、方法、语言、工具或硬件•留出足够的时间用于从错误中学习经验、实验及制作原型。编写需求规格说明需求理解•开发人员和客户对需求的不同理解会导致彼此间的期望差距，并最终导致交付的产品无法满足客户的需要。尽管问题待确定但迫于时间压力而继续向前•在软件需求规格说明中，将需要进一步研究的地方标上TBD，不失为一个好主意。具有二义性的术语•对于不同的读者可能会有不同解释的业务术语或技术术语，应该创建一个术语表对这些术语进行定义。需求中包括了设计•软件需求规格说明中所包含的设计对开发人员做出有效选择造成了不必要的限制，会妨碍他们发挥创造性设计出最佳方案。需求确认未经确认的需求•软件需求规格说明会令人望而生畏，在开发过程早期编写测试用例的想法就是基于这一点。审查熟练程度•要对参与需求文档审查的所有团队成员进行培训，请组织内部有经验的审查人员或外界的咨询顾问来评述早先的审查。需求管理变更需求•将前景和范围文档作为批准需求变更的参照，可以减少范围蔓延。需求变更过程•与需求变更的处理方式相关的风险包括，缺少已定义的变更过程，采用无效的变更机制，以及不遵循制定的过程来做出变更。未实现的需求•需求跟踪矩阵有助于在设计、构造或测试期间避免遗漏任何需求。扩大目范围•如果最初的需求定义不够好，那么进一步定义需求就会扩大项目的范围。风险管理是我们的好帮手周期性地进行风险跟踪可以使项目经理了解风险对项目的威胁，没有得到有效控制的风险应该上报高层管理人员，他们可能开始采取一些纠正措施，也可能不管风险，依旧按照原来的业务决策思路进行。即使不能控制项目可能遇到的所有风险，风险管理也能帮助我们看清形势，做出合理的决策。风险管理的措施明确你当前项目面临的一些与需求有关的风险，不要把当前的问题当作风险，一定要是那些还未发生的事情。将风险因素编写成文档，为每项风险推荐至少一种可能的降低风险的方法。风险管理的措施召集代表开发、市场、客户和管理各方面的涉众召开风险“集体研讨”会议。尽力找出更多与需求有关的风险因素。估计每项风险发生的可能性及其影响，两者乘积就是风险危害值。通过按风险危害值降序排列找到最高的五项风险。为每项风险安排一个负责人负责实施降低风险的活动。第23章需求跟踪需求跟踪提供了一个表明与合同或说明一致的方法。更进一步，需求跟踪可以改善产品质量，降低维护成本，而且很容易实现重用。需求跟踪链使你能跟踪一个需求使用期限的全过程。通用的跟踪模型显示了我们要在软件开发的不同层面全面地跟踪需求。需求跟踪动机CMM的第三层次要求具备需求跟踪能力。需求跟踪的定义[IEEE，1994]开发过程的两个或多个产品之间能够建立关系的程度，尤其是那些具有前后关系或主从关系的产品。例如，某个给定组件的需求和设计的匹配程度。软件开发产品中每个元素能够建立其存在理由的程度；例如，数据流图中的每个元素定位它所满足需求的程度。跟踪关系需求跟踪链客户需要需求下游工作产品追溯到需求从需求回溯从需求追溯回溯到需求通用的跟踪模型涉众需要产品特性补充需求用例测试用例测试用例用例实现跟踪跟踪跟踪跟踪跟踪跟踪实现系统测试系统定义跟踪矩阵：用户需要与特性特性1特性2…特性n需要1XX需要2X…XX需要mX跟踪矩阵：特性与用例用例1用例2…用例n特性1XX特性2X…XX特性mX跟踪矩阵：特性与非功能性需求非功能性需求1非功能性需求2…非功能性需求n特性1XX特性2X…XX特性mX在实现领域跟踪需求用例功能需求设计元素代码测试实例UC-28catalog.query.sortclasscatalog.sort()search..7catalogsearch..8UC-29catalog.query.importclasscatalog.import()search.8catalogcatalog.validate()search..13search..14从用例跟踪到用例实现（一）用例用例实现跟踪实现领域系统定义领域从用例实现跟踪到实现（二）用例实现协作ABC参与类从补充需求跟踪到实现同步时钟设计模型协作需求时钟应该每24小时同步一次跟踪在测试领域跟踪需求用例测试用例跟踪系统测试领域系统定义领域跟踪场景到测试用例用例场景1测试用例1测试用例n……场景m从用例到测试用例的跟踪矩阵用例场景（标号）测试用例（ID）UC111.11.222.1UC211.122.12.22.3………第24章需求管理工具商业需求管理工具，包括让用户从源文档中产生需求，定义属性值，操作和显示数据库内容，让需求以各式各样的形式表现出来，定义跟踪能力联系链，让需求同其他软件开发工具相连等功能。使用需求管理工具的益处。如何实现需求管理自动化。商业需求管理工具介绍。基于文档存储需求的限制很难保持文档与现实的一致。不太容易做到为每一个需求保存增补的信息。很难在功能需求与相应的使用实例、设计、代码、测试和项目任务之间建立联系链。很难跟踪每个需求的状态。商业需求管理工具以数据库为核心的产品以文档为核心的方法一些商业需求管理工具工具开发商以数据库/文档为核心Caliber-RMTechnologyBuilders.Inc.以数据库为核心以文档为核心以数据库为核心实现需求管理自动化为需求管理工具定义项目需求。列出影响决策的10~15个因素。对上述步骤中列出的因素打分（总计100分）。获得有关可用的需求管理工具的最新信息，根据影响决策的因素对候选工具排序。根据给每个因素的加权值来计算每个候选工具的得分，从而确定最合适的产品。从候选工具的其他用户那里获得一些体会。从候选工具中前三名的开发商处得到评估拷贝。最好用一个实际的项目来评估工具。经过对排名、许可权费、开发商后续支持费、当前用户的输入、工作小组主观印象等的考虑之后做出决定。基于文档的存储需求的方法有许多局限性，例如：•不容易保持文档的最新和同步。•需要将变更人工通知给受影响的所有团队成员。•不容易存储每一个需求的增补信息(属性)。•很难定义功能性需求和其他系统元素之间的联系链。•很难跟踪需求状态。•很难同时管理多个分别用于不同产品版本或者相关产品的需求集。•想要重用需求，分析人员必须将文本从初始的软件需求规格说明复制到每一个想要使用这一需求的系统或产品的软件需求规格说明中。•如果有多人参与项目，要修改需求是很困难的。•没有一个合适的地方可以方便地存储提议之后被否决的那些需求，以及已从基线中删除的需求。使用需求管理工具的益处项目需求的收集工作做得很好，也应该使用自动化工具帮助您在开发过程中管理这些