软件需求与风险管理
在讨论新的“物流管理系统”项目时，项目经理、首席开发工程师与测试经理回顾了之前的“仓储调度优化”项目的经验教训 。项目经理提到：“记得在上次那个项目中，由于对用户界面和交互设计的忽视，导致我们在测试阶段收到了大量用户反馈，不得不花费六周时间返工和重新测试界面。”首席开发工程师补充道：“那次经历犹如一场噩梦，我们不能再重蹈覆辙。”测试经理回忆说：“确实，当时我们急于推动项目进度，导致忽略了编写详尽的需求文档，从而引发了不断的需求变更和新增功能，最终项目延期半年，成本严重超支。”项目经理强调：“如果这次的物流管理系统项目再出现类似状况，全体团队成员都将承担后果。”
测试经理建议：“我们应该总结上次仓储调度优化项目中遭遇的问题，并在物流管理系统项目中采取措施避免这些失误的发生。我最近读了一篇关于软件风险管理的文章，文中强调我们需要识别并管控项目中的各种风险。”然而，项目经理对此持有不同意见：“我们已经从仓储调度优化项目中汲取了教训，有信心在这次项目中做得更好。现阶段讨论风险管理或许为时尚早，而且我认为不应让消极情绪影响项目团队的士气。我们的目标应当是积极制定并实施成功的项目计划。”
风险管理在软件工程项目中的关键作用
与项目经理的观点相反，优秀的软件项目管理者必须高度重视并有效管理项目中的各类风险，尤其是在需求工程阶段。风险指的是那些可能导致项目延期、成本增加、技术难题增多、产品质量下降或团队效率下滑的潜在不利情况。风险管理作为一种软件行业内的最佳实践，目的在于尽早识别、评估并控制风险，以防它们升级为项目危机。一旦风险成为现实问题，就需要借助项目状态监控和纠正措施来应对，但这明显不如提前预防来得更为有效。
鉴于需求说明在软件项目中的核心地位，明智的项目经理会在项目启动阶段便密切关注与需求相关的风险，并采取积极措施进行管理。常见的需求风险包括需求误解、用户参与度不足、项目范围 和目标定义模糊或频繁变更等。项目经理需要与客户或客户代表密切配合，共同识别并量化需求风险，并制定相应的风险缓解策略，以增强双方的合作关系。
面对风险，正确的态度是不回避，而应在风险影响项目之前对其进行深入分析和妥善处理。本文将进一步概述需求风险管理的基本要素，并列举在需求工程过程中可能出现的各种风险因素，以帮助读者在风险对项目产生负面影响前做好预防和应对准备。
软件风险管理基础
在项目管理中，除了与项目范围和需求有关的风险外，还有许多其他风险。例如，依赖于外部实体，如转包承揽者或生产重用部件的另一个项目，是一种常见的风险来源。此外，不准确的估计、对准确估计的否决、对项目状态不清楚、资金周转等问题也是项目管理中的挑战。技术风险则威胁着复杂或前沿的开发项目，缺乏知识也是一种风险源。政府规范的强制性或频繁变更也会使好的计划彻底作废。因此，所有项目都应该认真地进行风险管理，不断察看水平线上是否出现了冰山。与其他过程一样，让你的风险管理活动与工程规模相适应。对于大规模项目的成功，正式的风险管理计划显得非常重要。
风险管理的要素
风险管理是通过使用特定工具和步骤来控制项目风险在可接受范围内的过程。它提供了一种标准化的方法来识别、编入文档并评估潜在威胁，以及减少这些风险的建议策略。风险管理包括以下活动：
风险评价：检查工程项目并识别潜在风险区域的过程。通常可以通过列举软件项目的风险因素来简化风险识别过程。
风险分析：检查特定风险对项目可能造成的潜在后果，并分级处理以便更注重处理最严重的风险。风险危害值(risk exposure)包括带来损失的可能性大小和潜在损失的规模。
风险避免：避免冒险的事情。可以通过不承担任何项目、采用成熟的技术或排除难以实现的特性来规避风险。
风险控制：管理已发现为高优先级 的风险。制定风险管理计划是一项处理具有重大意义风险的计划，包括降低风险的方法、应急计划、负责人和截止日期。
风险监控：跟踪风险解决过程的进展情况。这也是例外的项目状态跟踪的一部分内容。监控可以很好地了解降低风险工作的进展情况，并定期修订先前风险清单的内容和划分的优先级。
编写项目风险文档
风险条目跟踪模板
序列号：__________
确定日期：__________
撤消日期：__________
描述：________________________________________________
可能性：________%
影响：_______________________________________
危害值：________%×________%=________%
降低风险计划：_______________________________________
负责人：___________________________
截止日期：_______________________________________
在编写风险说明时，最好采用条件——结果的形式。也就是，先说明你关心的条件，接着是潜在的有害结果。有时，人们只说明了风险条件(如“客户不同意产品的需求说明”)或者只说明了结果(“我们只能满足某些主要的客户”)。最好将这样的说明句子合并成条件——结果形式的结构：“如果有些客户不赞同产品的需求说明，那我们只能满足某些主要客户的意见。”而一个条件下可能有多个结果，同时也可能出现多个条件下导致同一个结果。
模板能记录风险变为事实的可能性及对项目的消极影响，还有整个的风险危害值(可能性×影响)。我用0.1到1.0来描述可能性，用1到10来表示影响。将这两个因素相乘即可作为评估风险危害值的依据。不要试图精确量化风险。你的目标是将最有威胁的风险和那些不急需处理的风险区别开来。大家可能更愿意用高、中和低来估计可能性及影响。但风险条目中至少应有一个为高的风险。制定降低风险计划来明确控制风险要采取的活动，其中一些策略是尽量降低风险发生的概率；而另一些则是减少风险发生后带来的影响。做计划时要考虑降低风险所耗费用，千万不要花费20,000美元来控制一项仅会损失10,000美元的风险。为每项风险安排一个负责人，并确定完成活动的截止日期。长期或复杂的风险可能需要具有多个阶段性成果的多步骤降低风险策略计划。
本文开始部分介绍的“物流管理系统”小组领导者讨论的一个风险。小组凭他们以前的经验估计了风险的可能性及其影响。除非他们把其它风险因素也估计出来，否则他们并不明白风险危害值4.2究竟有多严重。降低风险措施的前两条是通过更多的用户参与项目来减少风险发生的可能性。而采用原型法则可以利用用户关于界面的早期反馈来减少风险的潜在影响。
制定风险管理计划
仅仅制定一份风险列表并不足以构建完整的风险管理计划。对于小型项目，可以将风险管理计划纳入软件项目管理计划中。但对于大型项目，需要独立的风险管理计划，其中包括用于识别、评估、跟踪和处理风险的方法和途径。该计划还应明确风险管理活动的角色 和责任，并指定专门的风险管理人员负责可能出现的问题。
通常情况下，项目小组会为关键活动制定计划，但在实施或根据实际情况进行调整方面存在困难。为了确保按照风险管理计划执行，项目进度安排必须留出足够的时间来执行风险管理活动。工程项目的工作分类清单应包括降低风险的活动、状态报告和更新风险清单等。
与其他项目管理活动一样，需要建立周期性的监控机制。保持高度关注可能会对项目造成最大威胁的十种风险，并跟踪降低风险措施的有效性。完成一项任务后，重新评估该任务的风险可能性和影响，更新风险清单和其他相关计划。当控制住原本高优先级的风险后，新的条目可能会进入前十名。请记住，不要仅因完成了一项降低风险的活动而人为增加一个风险以便更好地控制它。你应该考虑一下你采用的降低风险方法是否真正减少了风险的危害程度，并将其减少到可接受水平以下。
物流管理系统的风险条目样例：
- 序列号：[待填写]
- 确定日期：[待填写]
- 撤销日期：[待填写]
- 描述：由于需求获取中没有合适的用户参与，导致测试之后需要对用户界面进行返工。
- 可能性：0.6
- 影响：7
- 危害值：4.2
- 降低风险计划：
1. 在第一阶段早期就要收集易学、易用的需求。
2. 与产品代表一起召开 JAD 会议以开发需求。
3. 通过与产品代表和顾问的交流，开发一个包含核心功能的用户界面原型。让产品代表和其他用户来评估此原型。
- 负责人：李小军
- 截止日期：在 6/16/99 前完成 JAD 会议。
与需求有关的风险
下面是一些降低需求工程中风险的方法：
- 使用头脑风暴 和集体讨论来识别潜在的需求风险，确保所有相关方都参与到这个过程中。
- 对需求进行详细的分析和评估，以确定它们是否可行、可实现以及是否满足项目的目标和要求。
- 在编写规格说明时，要特别关注需求的细节和约束条件，避免遗漏或错误的描述。
- 在验证需求时，要进行充分的测试和验证，确保它们符合预期的质量标准和功能要求。
- 在管理需求的过程中，要及时跟踪和更新需求的状态和变化，确保项目能够按时交付并达到客户满意度。
总之，降低需求工程中的风险需要全面而系统地考虑和管理所有的环节和因素，包括识别、分析、编写、验证和管理需求。只有这样才能确保项目的成功交付并达到客户的期望和要求。
需求获取
产品视图与范围应该在项目早期明确，并将其纳入业务需求中。这有助于避免项目范围的扩大和需求被忽略。记录每个项目中实际需求开发的时间，以便了解所花费的时间是否合理并改进未来项目的工作计划。为确保需求规格说明的完整性和正确性，应以用户任务为中心，使用实例技术获取需求，并根据不同的使用情景编写测试用例和建立原型。对于革新产品的需求，应强调市场调查研究、建立原型和运用客户核心小组来获得反馈信息。明确非功能需求，如性能、使用性、完整性和可靠性等质量特性，并编写非功能需求文档和验收标准 作为可接受的标准。确保主要客户对产品需求表示赞同，采用产品代表的方法来确保客户代表积极参与需求决策过程。识别并记录客户可能存在的隐含期望和假设，提出大量问题以提示客户充分表达其想法和关注点。不要将已有的产品作为需求基线，而是应将其作为逆向工程的参考，并让客户评审以确保其正确性。最后，分析人员应尽力从客户推荐的解决方法中提炼出本质核心，避免掩盖实际需求导致业务处理低效或给开发人员带来压力。
需求分析
- 划分需求优先级
- 确定每项需求、特性或使用实例的优先级并安排在特定的产品版本或实现步骤中
- 评估每项新需求的优先级并与已有余下的工作主体相对比以做出适宜的决策。
- 运用项目状态跟踪的办法管理那些落后于计划安排的需求，并尽早采取纠正措施。
- 带来技术困难的特性
- 分析每项需求的可行性以确定是否能按计划实现。
- 确定高风险的需求并允许一段充裕时间用来从错误开始学习、实验及原型测试。
- 不熟悉的技术、方法、语言、工具或硬件平台
- 不要低估了学习曲线中表明的满足某项需求所需要的新技术的速度跟进情况。
需求规格说明
需求理解对于开发人员和客户来说都非常重要，因为不同的人可能会有不同的理解，这会导致最终产品无法满足客户的要求。因此，在对需求文档进行正式评审 时，应该包括开发人员、测试人员和客户等团队成员。
为了写出更好的规格说明，训练有素且经验丰富的需求分析人员可以通过询问客户一些合适的问题来了解需求。此外，模型和原型也可以从不同角度说明需求，有助于解决一些模糊的需求。
时间压力可能会影响 TBD(To Be Decided)的处理。如果 SRS(Software Requirements Specification)中需要将来进一步解决的需求被打上了 TBD 记号，但这些 TBD 并未解决，就会给结构设计和项目继续进行带来很大的风险。因此，应该记录解决每项 TBD 的负责人的名字、解决方法以及截止日期。
在需求文档中，可能会出现具有二义性的术语。为了避免不同的读者理解为不同的意思，可以建立一本术语和数据字典 ，用于定义所有的业务和技术词汇。特别是要说明清楚那些既有普通含义又有专用领域含义的词语。对 SRS 的评审可以帮助参与者就关键术语、概念等达成一致的共识。
最后，需求说明中可能包含了设计。但是，包含在 SRS 中的设计方法可能会对开发人员造成多余的限制并妨碍他们进行最佳设计的创造性。因此，在评审需求说明时，应确保它强调的是解决业务问题需要做什么，而不是怎么做。
需求验证
在审查需求时，需要花费相当多的时间和精力来确保其正确性和质量。这类似于在开发过程早期编写测试用例一样，但如果在构造设计开始之前通过验证基于需求的测试计划和原型测试来验证需求的正确性及其质量，就能大大减少项目后期的返工现象。因此，应在项目计划中为这些保证质量的活动预留时间并提供资源。同时，从客户代表方获得参与需求评审 的赞同，并尽早且以尽可能低的成本通过非正式的评审逐渐到正式评审来找出其存在的问题。
为了确保评审的有效性，需要对参与需求文档 评审的所有团队成员进行培训，并请组织内部有经验的评审专家或外界的咨询顾问来讲座、授教，以帮助使评审工作更加有效。
需求管理
如何减少需求变更的影响？
- 建立变更管理的纪律和氛围，包括对变更的影响评估、提供决策的变更控制委员会以及支持确定重要起点步骤的工具。
- 用户积极参与的需求获取过程可把需求变更减少近一半，同时在早期发现需求 错误的质量控制方法也能减少以后发生变更的可能。
- 将易于变更的需求用多种方案实现，并在设计时更要注重其可修改性。
如何避免未实现的需求？
- 使用需求跟踪能力矩阵来避免在设计、结构建立及测试期间遗漏任何需求，同时也有助于确保不会因为交流不充分而导致多个开发人员都未实现某项需求。
如何防止扩充项目范围？
- 在早期版本中实现核心功能，并在以后的阶段中逐步增加实现需求，以减少因开始未很好定义需求而导致的项目范围扩充的风险。同时，制定阶段递增式的生存期计划也很重要。