什么可以代替用例来收集需求？

Question

我是一名程序员，目前正在与BAs和PM一起工作，以收集/描述我们的案例管理系统的模块和功能；几次会议之后，我发现使用“用例”非常适合于记录新系统中所涉及和/或提出的许多内容和功能。当我建议我们需要创建‘用例’，这样我们就不会忘记我们说了什么/得出的结论，并且让编程人员知道他们应该编写什么代码时，前面提到的BA不喜欢‘用例’。

当应该编写用户需求的人说他们不喜欢“用例”时，或者当您意识到他们不想编写“用例”来描述系统应该做什么时，有什么可以用来收集/记录需求呢？

我试图找出使用“用例”来记录系统功能/场景是否有接近或有效的替代。

Answer 1

根据您/他们对“用例”的定义，您可以转而查看“用户故事”。如果您定义了一个类似于Usability.gov的定义的用例，我会这么说。

用例是对用户如何在网站上执行任务的描述。用例包括两个主要部分:用户将采取的步骤，以完成您的网站上的特定任务的方式，网站应响应用户的行动。用例从用户的目标开始，到目标实现时结束。

相反，您可以使用来自敏捷开发方法的用户故事。他们更多的是关于你想做什么，然后如何去做。关于用户故事有很多不同的文章和定义。这篇较早的文章实际上展示了他们所看到的用例和用户故事(新的用户故事？)之间的区别，最后，他们确实做了同样的事情。他们只是对它们进行了不同的设计。你仍然需要相同的信息，谁，什么，为什么(目标)。他们的意思是更多的叙述，人物角色链接到您的系统的真实用户类型。它们更具有描述性，但仍然包含您需要的所有信息。

在您的情况下，表示不同需要的相同信息可能正是您所需要的。

Answer 2

奇怪的是，BA拒绝一个需求的模板而没有提出另一个模板。一般来说，BA应该对文档提出建议(如果公司中还没有被接受的标准)，或者至少通知他/她准备需求的格式。

通常，业务需求文档(或BRD)没有严格的格式，但有些主题应该涵盖：

• 一般资料(目的、参考资料、假设等)
• 业务流程
• 需求范围
• 功能需求(也可以包括用例)
• 数据要求(数据量、数据转换等)
• 非功能性需求(安全性、性能、可伸缩性等)
• UI需求
• 等。

涵盖上述所有议题可能足以记录会议期间作出的所有决定。我还建议，除了描述最终决定之外，您还会提到为什么这个或那个决定是/没有做出的，以及为什么某个解决方案有效/不起作用。这将帮助你避免再次进行同样的讨论。

根据我的经验，与我一起工作的BA以UI图的形式向我们提供了需求。由于我们一直在同一个项目上工作，所以有一些我们都知道的约定，没有必要每次都将这些约定包括在需求中。除了图表之外，还描述了功能。这些文档被开发人员和UI设计人员使用，每当我们有问题时，我们都会被欢迎提问。在需求准备好并且开发人员对它们进行了研究之后，我们举行了一次计划会议，其间PM准备了用户故事和任务。

Answer 3

另一个选择是人物角色和故事。角色超越了用例参与者，因为它代表了使用系统的实际人员以及他们如何与系统交互。例如，对于薪资系统，您将具有如下角色：

• 会计部的鲍勃
• 艾丽斯来自人力资源部
• 经理汤姆
• 向雇员开账单
• 首席执行官约翰

这允许您创建关于这些用户如何使用系统进行日常生活的故事。要帮助了解这些概念，请参阅Mike的“用户故事应用”一书