使用案例之前需要启发技术的要求是什么？

Question

我为我的同事做了一些关于用例启发的演示，然后其中一个问 “用例之前需要启发技术的要求是什么？以及用例如何比以前的方法更好？ 我不知道，有人可以帮忙吗？

Answer 1

从Wikipedia，使用情况在1986年

首次制定了之前（甚至以后相当长的）猜测有与指定的预处理和后条件和故障情况沉闷的100-PG需求定义文件。

使用案例是obv。比对视觉上的简洁它提供了:)

然后详细的文档更好地来到用户故事

Answer 2

我觉得活动和符号来区分是很重要的。如上所述，以前，没有结构，因此每一项要求都是一系列的。用例定义了目标，特定的角色，可以包含另一个用例或者被其他用例扩展，甚至可以参数化。这可以以可理解的方式消除那些长需求文档中的大量重复。但这只是关于符号而已，用例本身并不伴随任何其他活动来引出需求而不是旧技术。另一方面，用户故事在没有明确的书面情景的情况下甚至更短。有趣的是，当你为用户故事编写场景时，就像使用Cucumber一样，实际上写的更多，用例更加脆弱，但重要的是用户故事提供了不同的活动。您不必事先试图覆盖这些情景，而是逐渐地，迭代地按需编写它们，这意味着您可以更好地应对需求变化。然而，很难从用户故事中删除重复内容，并且情景的Given-When-Then模板通过有限台机器取代用例的功能性质。