2012年10月9日,星期二,05:31

定义软件和UI要求的残破电话游戏

撰写者

坏了的电话游戏在世界各地播放。根据 维基百科,游戏的玩法如下:“一个人向另一个人窃取一条消息,该消息通过一行人传递,直到最后一位玩家向整个团队宣布该消息为止。错误通常会在重传中累积,因此最后一位玩家宣布的声明与第一个玩家所说的明显不同,并且常常很有趣。

试图通过使用从客户传递给业务分析人员,UI / UX设计人员以及开发人员和测试人员的信息来定义软件和UI要求的许多组织也无意中玩了此游戏。

这是一个典型的例子:

  • BA或产品所有者通常从功能列表和用例中获取客户的需求并将其写下来。
  • UI / UX团队对用例进行了解释,以开发UI模型和情节提要。
  • 测试会解释情节提要,模型和用例以开发测试用例。
  • 然后,开发人员解释用例,模型和情节提要以编写代码。

与破碎的电话游戏一样,每次切换都会更改信息。由于以下因素的组合,因此产生的方法包括大量的返工和不断增加的项目成本:

  • 用例不能正确代表客户需求。
  • UI / UX设计 与用例不一致。
  • 错误的测试用例会导致错误的错误。
  • 缺少测试用例会导致未发现的错误。
  • 开发人员构建的功能无法满足客户的需求。

原始需求越破损的电话线越深,它们变得越失真。因此,UI故事板,测试用例和代码通常需要大量的修改,因为在到达UI和测试团队时,需求被误解或翻译不正确。

如何减少电话损坏的影响?

好消息是,对流程和可交付成果进行了一些相当简单的更改,这些更改将减少电话故障的影响。以下技术的共同目标是减少越区切换和转换。

与跨学科团队面谈客户

一种方法是让BA,UI / UX和质量保证人员直接参与与客户的启发过程。您甚至可以提出一个案例,包括首席开发人员。通过在面试过程中代表所有学科,各方可以直接从客户那里听到要求,从而减少了对BA文档的依赖。同样重要的好处是,每个学科都具有不同的观点,这可以引导访谈过程沿着不同的对话和需求收集路径进行。

例如,与BA或UI / UX资源相比,QA资源可能会问有关与边缘或错误条件有关的要求的更多问题。将UI / UX成员放在客户面前将为您提供一个机会,以了解经常用于管理最终用户认知负担的功能。

将用例,UI模型和UI故事板合并并发展为集成的可交付成果

减少电话损坏的另一种方法是,通过将用例,模型和情节提要组合成一个“集成的交付项”,避免将它们作为单独的交付项创建。要创建集成的可交付成果,请从用例开始,并将UI原型附加到每个步骤。这会自动创建一个UI故事板,其步骤与用例相同(包括主要流程和替代流程),这意味着它们不会失去同步。另外,由于UI样机已附加到每个步骤,因此您知道它们将与该步骤中概述的目的和要求一致。

通常,会出现新的需求或对现有需求的更改,并且如果情节提要和模型与用例分开,则不会更新原始用例。这会使您的开发人员,测试人员和利益相关者感到困惑。将您的用例,模型和情节提要组合到一个集成的可交付成果中,可以更轻松地使三个实例保持同步,从而大大减少了需求冲突的可能性。

集成的可交付方法鼓励您的BA和UI / UX团队进行协作和组合的创作和审阅用例和UI / UX设计,从而更准确地定义和理解需求。

为使该概念变为现实,下面的示例以BA或产品经理定义的用例开始,而未提及特定于UI的要求。

用例:ATM现金提取

带有Y形符号的台阶是具有交替流动的台阶。

Oct9thMartin1

交替流

Oct9thMartin2

Oct9thMartin3

当UI / UX团队开始将UI原型附加到每个步骤时,将创建一个UI故事板,该故事板使用与用例相同的确切主流程和替代流程。用主流程和备用流程表示的UI故事板的好处是减少了传统线性故事板的数量。 如果要通过上述用例为每个独特的路径创建传统的UI故事板,则总共有11个,每个步骤都有重复的步骤。 具有主要流程和替代流程的UI故事板可减少线性UI故事板中出现的返工和错误。

您可以在Word中通过插入在其他UI样机工具中创建的UI样机图像来做到这一点,但是要使UI样机保持最新状态将变得既费时又容易出错。诸如PowerStory(PowerPoint的插件)之类的产品使您可以将用例步骤与UI样机结合在一起以创建UI Storyboard,从而使此过程变得更加容易。

在下面的屏幕快照中,您将看到PowerStory添加了一个专门用于创建主流程和用例的备用流程的面板,并将这些流程中的步骤与PowerPoint中的典型幻灯片相关联。

10月9日马丁5

如前所述,旁边带有Y形符号的台阶表示交替流动。将鼠标悬停在该图标上时,可以查看和输入与该步骤关联的替代流程。

Oct9thMartin6

PowerPoint是用于创建UI样机的极其强大的工具 与典型的线框模型工具相比,该工具可以支持更多的UI设计思想,尤其是像 动力模型 and 微软即将推出的故事板插件.

编写测试用例和UI故事板

测试用例通常包括“用户操作”和“预期结果”。如果在创建用例和UI时花费更多的前期时间来定义哪些步骤是“用户操作”以及哪些步骤是“预期结果”故事板,您可以节省测试团队的时间。通过在每个步骤中定义主要参与者,用例非常适合这种方法。以参与者为系统的任何步骤都应归为测试用例的“预期结果”步骤,参与者是最终用户的任何步骤都应标记为“用户操作”。

下面显示了从上面定义的组合用例派生的测试用例之一,遵循的规则是:最终用户参与者的步骤是动作,而拥有系统参与者的步骤是预期结果。

Oct9thMartin4

直接从用例自动创建测试用例

使用可以从您的用例和UI故事板自动生成测试用例的工具,可以为您节省大量时间和金钱,通常由您的测试团队花费在创建手动测试用例上。在本文的上下文中,它还消除了切换,从而减轻了电话中断的影响。当质量检查团队解释需求并将其转换为测试用例时,他们可能会误解需求并创建错误的测试用例和/或未满足要求及其对应的测试用例。

要点

开发软件需求,UI设计和测试用例可以反映我们小时候都玩过的坏电话游戏。每次我们传递信息时,都会对其进行更改和曲解,从而导致项目成本增加,并向您的客户提供错误的解决方案。按照上面概述的步骤,您可以减少损坏的电话效果,并按照更简化的过程进行操作,以使产品开发清晰明了。

不要忘记在下面留下您的评论。

马丁·克里斯普

马丁·克里斯普 在过去的6年中,他首先在需求定义和管理领域担任Blueprint Software的CTO,现在担任 动力故事. 在此之前,马丁从2002年开始担任其他初创公司的CTO职位。 在职业生涯的前十年,他在EDS,埃森哲和德勤咨询公司工作期间,在销售和交付大型系统的集成项目方面也拥有丰富的经验。  马丁还是eMersion的创始人,eMersion是一家电子商务咨询公司,后来卖给了德勤咨询。

©BA Times.com 2020

麦格雷戈徽标白色网站