2010年9月27日,星期一15:14

1-2-3业务分析

由基思·巴雷特(Keith Barrett)撰写

业务分析师123 写作要求就像写一个故事,因为我们的目标是传递信息,使每个阅读该故事的人都可以清楚地理解和可视化正在发生的事件,总体情节和最终结局。从需求的角度来看,编写故事有三个不同的方面,它们构成了业务分析的1-2-3。

1.作者

要编写故事,我们必须考虑当今分析师可用的许多不同技术,例如:文本需求,流程图,用例,屏幕模型等。每一个都为故事提供了不同的视图并提供了分析师选项。他们如何描绘这个故事。选择合适的技术将启动该过程,并且取决于几个因素,而其中最重要的是方法论-敏捷,瀑布式或某种混合方式。一旦开始编写选定的技术,我们就需要在这些技术之间保持牢固的联系,这在业界被称为可追溯性。我们保持可追溯性,以便在整个过程中,我们可以评估进行更改的影响,并从覆盖范围的角度确认,需求正在分解为越来越少的细节。我们称其为 表达力 在编写您的要求时。

随着行业的成熟,我们已经了解到仅仅管理一系列文本要求中的变更混乱是不够的。它会阻止出血,但不会带来愈合。为了真正治愈需求过程,我们需要在创作阶段合并所有这些不同的技术,以便出现一个单一的故事。我们通过了解这些技术如何相互补充来做到这一点。例如,文本需求通常用于描述不同类别的需求,例如业务需求,用户任务和功能系统级别的行为,这可能导致我们创建描述高级业务流程的流程图和/或引导我们创建一个用例,描述用户为实现针对系统的给定目标而经历的特定事件序列。用例中描述的行为可能会驱使我们创建模拟屏幕,以帮助显示用户体验的视觉元素。

尽管可以使用MS Office等传统工具来编写这些不同的技术并将所有内容连接在一起,但是这需要大量的工作。利用诸如需求中心之类的东西,就可以在一个产品中创作和连接所有这些技术,并大大减少了编写需求故事所需的工作量。

2.验证

验证就是要询问某个人,无论是上游业务用户/利益相关者还是下游IT资源,需求故事是否正确和完整。可以提高需求质量的唯一方法是通过高度迭代的验证/审查会议,在这些会议中,我们分享迄今为止编写的内容,同时要求对准确性和完整性的反馈。今天的挑战是 我们如何进行审核会议阻碍了我们获得高质量反馈的能力。我们正在浏览的文档内容如此之小,以至于没有人真正看到并理解我们要讲述的故事,或者我们展示的是一个原型,它可以在一系列屏幕中导航,但仍然与之断开连接我们在用例中描述的真实行为。有时会同时使用两种方法。这些方法就像递给某人一本字典,然后问他们我们是否有正确的需求...所有内容都在其中,但是由于它们的排列方式,因此无法弄清楚需求故事的真正含义。

由于此过程对审阅者而言非常痛苦,因此最终结果几乎始终是认可的橡皮图章,以便该过程可以继续进行。大多数业务利益相关者刚刚接受了这样的现实:在系统真正完成他们需要做的事情之前,将需要实际产品发布的多次迭代。这就是为什么几十年来行业统计数据没有变化的原因-IT预算的40%由于需求不佳而被消耗掉。

验证必须从以橡皮图章结束的痛苦,漫长,不频繁的审查会议转变为提供质量改进反馈的令人愉悦,快速而频繁的会议。视觉化是做到这一点的唯一方法。但这就是问题所在,视觉化并不意味着仅仅向他们展示屏幕原型,因为原型制作只是整个故事的一部分。我们必须以一种具有凝聚力且内容丰富的方式来讲述该故事,这使得审阅者可以轻松地将自己的想法包裹在故事周围,并真正验证其是否正确和完整。这就是为什么Blueprint推动行业朝着基于实际需求的仿真发展的原因,该仿真实际上涵盖了我们所有的不同技术,并且首次使用户能够快速轻松地“获得它”,以便他们可以提供我们所需的反馈。模拟必须将行为要求(通常在用例中编写)与针对业务需求/规则的上游文本要求以及针对用户体验的下游屏幕设计合并。从仿真中剔除其中的任何一个,故事都是贫乏的。

3.沟通

在某个时候,当我们经历创作和验证需求故事的迭代过程时,我们需要将此信息传达给各种受众。交流与验证的不同之处在于,我们不需要征求反馈……这更像是告诉某人一个故事,而不是征求有关故事的反馈。我们经常需要从历史上记录事物在某个特定时间点的样子,或者我们需要提供可以正式签署的文档,或者我们只需要一个项目列表以促进优先级设置会话等。

不用说,当我们的主要创作环境是文档时,我们最终会创建易于管理且使用起来很糟糕的文档……想想字典。相反,我们需要能够生成各种格式的文档,以满足给定受众的特定需求,无论是Word文档,Excel电子表格还是HTML网站。我们需要以正确的方式,向正确的人员传达正确数量的信息。这就是为什么从工具中使用基于模板的文档生成过程总是比将我一直用来管理需求的文档的x版本交给某人更好的原因。

尽管可以将这些生成的输出用作验证过程的一部分,并且是将它们交给用于管理需求的文档的一个步骤,但最终即使生成的文档非常适合给定的受众,仍然不足以传达这些信息。故事足够好,以获得我们想要的反馈。因此,文档应主要用作参考点和签核机制,而其他技术(如需求模拟)则可用于推动验证和审查会议。

一切的网

要使需求正确无误,就需要一种集成的方法来在整个需求生命周期中创作,验证和交流需求故事。这不再是白日梦,也不是理论上的对话。

别忘了在下面留下您的评论


基思·巴雷特(Keith Barrett) 在软件开发行业有20年的经验,目前是Blueprint Systems的高级销售工程师。他还共同主持了 要求未插 Requirements.net网站上的播客系列。欲了解更多信息,请访问 www.blueprintsys.com

 

©BA Times.com 2020

麦格雷戈徽标白色网站