2009年6月16日,星期二,01:00

要求;我怎么知道我什么时候'm Done?

撰写者

这是业务分析师和项目经理中最常见和最具争议的问题之一:“何时完成需求?”坦率地说,我最想回答的问题是“当客户签字时”。重点必须放在您可以控制的内容上-定义的质量,及时性,完整性,准确性,清晰度或沟通水平-而不是您要控制的内容 不能 控制。但这仍然引出一个问题-“完成后如何知道?” -如果我没有遗漏任何东西,“ X”肯定会是什么?我会在后面拍拍吗?

这是每个寻求灵丹妙药的人都面临的问题:需求从未完成-至少在商业信息系统世界中没有。尝试“绝对”(组成一个新的,很酷的咨询词)将更有可能导致流程失败而不是成功。当您级联过去的业务需求并进入规格文档的越来越详细的迭代时,需求和解决方案之间的界限变得越来越模糊。

现在,在所有敏捷专家开始一致同意之前,“弃权”要求(您必须有平等的机会来编造咨询用语!)将导致令人难以置信的性能不一致-在单个资源级别,长期资产上管理和完整性级别,以及公司期望的管理级别。我什至可以证明这一点:低要求的成熟敏捷专家在准时/预算/成功绩效方面表现出色,而高要求的成熟敏捷专家(如果需要数据,请通过编辑器或 www.iag.com 网站并询问)。需求质量问题在所有开发方法中都很常见:如果您希望从根本上改变项目的绩效和成功率,则必须定义适合您情况的“清晰,准确和完整的需求”。

答案就在这里:定义“完整”意味着公司必须描述以下三个方面:

  • 需求状态(信息质量),
  • 需求的格式(用于可视化需求的模板和技术),以及
  • 实现这些工件的过程。

这样做定义了分析师和项目经理的“完成”。 “我做完了吗?”的问题只有在需求状态,格式或流程属性之一存在弱点的公司中才真正出现。处理这三个属性后,公司便开始沿着成熟的需求实践的道路前进,并从根本上改变了项目的按时/按预算/成功绩效比率。

好!站起来并伸展一下-对于那些说“嘿,他回避这个问题!”的人! - 还有更多。

并非每个人都能应对长期修复问题。作为日常管理的现实,我们有时必须进行快速修复。这是四个简单的测试,以评估是否满足要求 达到合理或足够的质量水平。这些是业务需求级别的测试,无论采用哪种交付方式,它们都可以起作用,并且可以提高您的需求质量:

  • 如果需求缺乏上下文。 始终存在支持企业要“做什么”的需求,而不是企业要如何“做”的需求。其中的“什么”部分是业务流程的上下文。没有了解需求会影响哪些业务流程,就意味着没人知道需求之间如何相互影响,删除需求的影响,或者无法确保所有需求共同完成或将满足特定的业务目标。公司在其文档中应用上下文的方式也会创建文档的结构。这是一个技术示例-用例。作为一种技术,用例可以为需求提供上下文和结构,并帮助分析师确保对项目范围进行充分的描述和排序。
  • 如果相互依赖性不明显: 您如何寻找证明相互依赖的证据?在材料中寻找一个称为“依赖关系”的部分,检查“问题列表”,寻找一种称为上下文关系图的分析技术(上下文关系图上的每一行都是相互依赖的)。为什么相互依存如此重要?有两个方面的范围:系统内部(例如,其功能,工作流和信息流等)和系统外部(例如,该系统如何与其他系统交互,工作流如何自动操作)跨其他部门)。在不了解相互依赖性的情况下,您只知道关于范围的故事的一半,因此很可能在任何复杂程度的任何系统上都会遇到范围的重大变化。
  • 不清楚的业务目标: 目标必须是具体的,可衡量的,可实现的,面向结果的和有时间限制的(易于记住的“ SMART”)。目标的缺乏消除了评估解决方案权衡的能力,使功能的优先级排序变得困难,等等。您可以通过用户验收测试来测试特定功能是否满足需求。除非您有明确的目标,否则您无法测试集体系统是否满足需求。
  • 从业务需求的描述中您无法确定信息将如何移动。 每当我看到以流程流程图表示的业务需求时,就需要10美元。这是一个不错的第一步(尽管效率低下),但这是问题所在:当您进入图片中的“决策菱形”并显示“批准政策(是/否)”时,您如何期望开发人员知道这意味着什么?详细说明此问题的唯一方法是提出以下问题:“批准该政策需要了解什么信息?”,“如何处理该信息?”,“从何处获取信息?”,“您还会将信息提供给谁?”等。业务想要做什么的描述越详细,流程的描述就越集中于信息如何移动以支持业务流程。直到达到表达信息移动的详细程度,您才从文档中不知道什么是业务意图。测试很容易-只需寻找名词即可。在描述过程中的步骤时,经常使用许多名词,这意味着您可能还可以。

我已经为所有人提供了以上四个测试,因为它们始终适用。即使在组织的执行级别,这些事情也应被视为重要。无论您是计划驱动的,原型的,供应商提供的方法,敏捷的或任何其他功能,它们都是可以评估的清晰,可审核且与技术无关的特征。

当您是业务分析师时,对“完成”的看法会如何变化?

从业务分析人员的角度来看,深入挖掘并对质量负责是您的工作。我会为您提供一些想法,特别是对您来说:

有一些技术可以帮助分析师测试需求的完整性并发现缺失的业务逻辑。将CRUD图视为常见测试和技术的示例。将实体关系图(ERD)视为鲜为人知的测试(此处有点琐事:只要ERD中的实体之间存在空关系,您都需要问一个问题“您做什么...”充实发生的情况,例如,从不将线索分配给代理。查看这些技巧中的一些技巧,以提高您的主动能力,并在问题作为未解决的需求出现之前就予以识别。在您的作业中考虑进行一些这项活动的时间。

从分析师的角度来看,构成质量的门槛要高得多。当需求具有质量时,您就“完成了”。要具有需求质量,需求必须是:

  • 正确 -要求是对已记录的业务目标或目标的准确阐述
  • 明确的 -需求只有一种解释
  • 完成 -要求是独立的,没有丢失的信息
  • 一致的 -需求在外部与其文档记录的来源(例如更高级别的目标和需求)保持一致
  • 排名 -出于某种目的对需求进行了优先排序
  • 可验证的 -该要求可由必须验证和验证它的测试人员使用(例如,可测试)
  • 可修改的 -要求仅指定一件事
  • 可追溯的 -需求具有自己的唯一标识符,可用于跟踪目的

朋友,我这个月的发言时间很长,但是我希望这里的一些想法能为一个棘手的话题带来清晰度或新的观点。 “完成”永远不会发生;合理的事情。您对评估需求“质量”的看法取决于您的角色, 您可以教育组织有关组织的每个级别在评估要求是否合理清晰,准确和完整方面如何发挥作用。查看 http://www.iag.biz/resources/webinars/microcast--executive-guide-to-evaluating-requirements-quality.html 快速示例说明如何培训高管。

祝大家一切顺利。


基思·埃利斯(Keith Ellis) 是IAG Consulting市场营销副总裁( www.iag.biz ),他领导着这个业务需求发现和管理全球领导者的市场营销和战略联盟工作。 Keith是技术服务业务的资深人士,并且是业务分析公司Digital Mosaic的创始人,该公司于2007年被IAG收购。Keith的前世包括领导技术趋势观察者International Data Corporation在加拿大的咨询和服务研究工作,以及全球外包商CGI在金融服务领域的营销策略。 Keith是IAG的《业务分析基准》的作者,该基准是有关业务需求对技术项目的影响的权威数据。

©BA Times.com 2020

麦格雷戈徽标白色网站