2009年1月20日,星期二,04:35

需求可追溯性的重要性

邓肯·麦克唐纳(Duncan McDonald)撰写

发现需求列表,然后不将其链接到设计,构建和测试,通常会导致交付的系统可能无法完全支持其旨在实现自动化的业务流程。只有通过可追溯性,项目团队才能确保所有要求都得到了实施。可追溯性向业务利益相关者保证,开发的系统支持其原始要求。

客户案例:大型金融机构

一家大型金融机构认识到他们的IT项目始终未能满足项目利益相关者的期望。交付缺少或不正确的业务需求的系统会导致业务流程的修改或昂贵的解决方法,从而可以使用该系统。因此,产生了许多昂贵的变更请求,通常是为了实施在项目生命周期的需求阶段中确定的需求。

得到教训

  1. 设计的每个元素都必须来自业务需求。
  2. 为了使系统交付价值,它必须支持流程。该系统基于设计。因此,设计必须基于系统要支持的过程。
  3. 为了确保满足期望,测试用例应基于业务需求,而不是技术设计。
客户对几个交付的系统无法完全满足需求的项目进行了分析,并确定问题的根源是无法得出和记录业务需求的方法不一致。经过搜索过程,选择了IAG来评估需求方面的组织成熟度。 IAG还负责根据行业和组织的最佳实践以及在数百个需求项目中获得的IAG实践经验,开发定制的最佳需求流程。

成功秘诀

为了确定需求不足的根本原因,IAG进行了需求管理成熟度评估(RMMATM)。 RMMA用于识别和改进组织的业务分析,需求定义和需求管理功能。评估不仅评估过程的组织能力,还评估员工的能力,实践和技术,所使用的工具,组织基础设施和支持,可交付成果以及当前正在取得的成果。

IAG与利益相关者团体进行了一系列的结构化访谈,包括业务分析师,项目经理以及业务和IT部门的关键成员。此外,IAG还进行了评估调查和业务分析师能力测试,以衡量负责需求管理的员工的感知和实际技能水平。在与利益相关者团体进行访谈时出现了几个共同的主题,其中之一是在发现需求后缺乏可追溯性。许多关键的利益相关者甚至对任何新的需求方法的成功表示怀疑,因为过去的项目是在没有合并以前使用的实践发现的所有需求的情况下实施的。可以确定,这些过去失败的根本原因是,一旦记录了业务需求并将其移交给设计和施工团队,便不再引用这些需求。实际上,测试用例通常会测试设计而不是业务需求。如果要求没有纳入设计中,则测试将无法解决问题。

“这种方法首次为我们提供了一种灵活,适应性强的方法,可以通过软件设计无缝地满足客户的真实业务需求。我们还从一开始就生成了测试用例,并通过我们的SDLC确保了可追溯性。”

J.S.,个人系统AVP

在完成RMMA之后,IAG制定了《需求实践指南》,其中包括一个启发框架以及从发现到测试和实施的稳健需求跟踪。然后,IAG通过多个项目的成功展示了可追溯性的价值,其中金融机构在需求阶段邀请IAG作为合作伙伴。金融机构现在编写功能需求,这些功能需求直接来自描述业务流程时发现的业务需求。使用需求可追溯性矩阵管理这些需求,将它们连接到设计和测试元素,甚至链接在项目过程中创建的变更请求。这导致了遗漏需求的急剧减少,这体现在类似规模的项目的变更请求减少了75%。

给项目经理的建议

在管理项目的需求时,请考虑此客户的需求:一个更好的流程来为每个要自动化的业务组件创建功能需求,以及通过设计,构建和测试来跟踪这些需求以确保每个业务需求的能力符合预期。

客户的期望是,系统将执行其业务需求中记录的功能以支持其业务流程。因此,您必须在功能需求中反映客户的业务流程。最终,您必须提供一个系统,该系统可使企业以所需状态运行。您可以通过为每个要自动化的业务组件创建功能需求来实现这一目标-但是-不要忘记在开发生命周期中跟踪每个需求。两者都需要确保系统满足利益相关者的期望。


邓肯·麦克唐纳 是IAG Consulting(http://www.iag.biz/)拥有20多年为众多行业的客户提供实用建议的经验。 邓肯已经与IAG的客户一起完成了数十个大型需求项目,作为主要的需求促进者和需求架构师。 作为需求培训师和最佳实践顾问,邓肯还支持各种大型客户提高需求发现和管理实践的效率。 邓肯(Duncan)是一位备受追捧的顾问,他为希望大幅提高绩效的客户提供务实的解决方案。  

©BA Times.com 2020

 麦格雷戈徽标白色网站