2009年5月19日,星期二,09:10

为什么要可视化需求?

撰写者

您参加过几次会议,讨论一组要求,方法论或项目计划等,有人从主席那里站起来说"where's the whiteboard let me draw what I mean"?

我可以告诉你,这已经足够了!

尽管需求规范是记录与新产品或现有产品功能相关的详细信息的好方法,但我们所有人都生活在一个贫穷的社会中,我们中很少有人有时间浏览大型文档并提取我们所需的信息,然后开始似乎无休止的电子邮件线程讨论与每个需求相关的各个用例,这些用例由许多消息组成,这些消息以“您用X表示什么?”开头和结尾,“我的意思是X和Y,但我想您以为我的意思是Z! ”取而代之的是,为什么我们不坚持图片的谚语来讲一千个单词,而不是一页一页地创建文档的视觉表示-希望在一幅图片中传达一千个单词。

但是,我们必须记住的是,需求可视化的含义可能有所不同。例如,有些人可能会在与仿真图相同的上下文中查看需求可视化,而其他人则将可视化解释为通常在MS Visio类型工具中创建的简单用例图或业务流程。对我来说,所有这些使用情况上下文都可以表示可视化,因此,与其尝试将可视化分类为一种类型,我认为最好是在一个规模上以一个简单的流程在一端观看,而在另一端进行高端模拟来查看它,并且用户选择在任何给定时间最适合他们的方法。例如,如果您试图显示用户将如何在应用程序中移动以进行购买,那么使用MS Visio定义流程就足够了。但是,如果您试图设想一个新UI(用户界面)的外观,则样机和更丰富的内容可视化将更好地为您提供服务。无论选择哪种方法,可视化都有许多好处,包括:

  • 灵活性和可用性-流程图可以更轻松地导航以帮助查找内容
  • 在可视化中更容易发现错误
  • 更容易识别需求和业务流程之间的潜在并行性
  • 在业务流程中更容易发现丢失的用例
  • 自己了解需求
  • 加深对需求之间依赖性的了解
  • 业务流程的可视化可以提供到业务流程模型或SOA存储库的第一座桥梁

现在,我们已经探索了可视化的一些好处,现在该问题变成了何时应使用?我们应该可视化我们编写的每个需求还是仅仅可视化一些需求?如果我们要选择性,我们应该选择哪个需求?

我认为,我们可以问自己很多问题,这些问题可以帮助确定何时以及何时不可视化。这些包括(还有更多):

  • 开发方法的类型-我们需要问自己一个问题:需求可视化是否符合对更敏捷,更快速的需求定义的需求,或者它们会增加开发时间吗?
  • 需求的复杂性-如果需求有太多的子需求,这是否会创建一个“蜘蛛网”图,可能会使需求的定义变得过于复杂?
  • 需求类型-我们应该只可视化用户故事,并将与此用户故事相关的功能需求定义为文本,还是我们要可视化所有需求?
  • 要求的风险级别-仅高优先级或高风险要求才可以可视化?

重要的是要注意,我并不是说需求可视化是实现有效的业务和IT交流的“灵丹妙药”,但是它将起到很好的促进者的作用,有助于促进双方之间更好的交流和理解。 。

因此,现在由您决定。为什么不尝试将需求可视化并反馈给小组呢。


基因法·墨菲 在Hewlett-Packard担任需求管理产品经理的工作和博客。这篇文章首先出现在 惠普社区。

©版权所有2009 Hewlett-Packard Development Company,L.P.

©BA Times.com 2020

麦格雷戈徽标白色网站