【发布时间】：2010-05-31 07:34:28
【问题描述】：
我为我的同事做了一个关于用例启发的小演示，然后其中一个人问 “用例之前的需求获取技术是什么？用例如何比以前的方法更好？” 我不知道，有人可以帮忙吗？
【问题讨论】：
标签： history requirements use-case
【发布时间】：2010-05-31 07:34:28
【问题描述】：
来自Wikipedia，用例于 1986 年首次制定。
在此之前（甚至之后很长一段时间）猜测有枯燥的 100 pg 需求定义文档，其中包含指定的前置条件和后置条件以及失败场景。
用例是显而易见的。它提供的视觉简洁性比详细的文档更好:)
然后是用户故事
【讨论】：
我认为区分活动和符号很重要。如上所述，以前没有结构，因此每个需求都是一组行。用例定义目标、特定参与者，可以包含另一个用例或由另一个用例扩展，甚至可以参数化。这允许以易于理解的方式消除那些长需求文档中的大部分重复。但这仅是关于符号的，与旧技术相比，用例本身没有任何其他活动来引发需求。另一方面，用户故事没有明确的书面场景，符号更短。有趣的事情发生了，当你为用户故事编写场景时，就像用 Cucumber 一样，你实际上有更多的东西要写，也比用例的描述更脆弱，但重要的事实是，用户故事提供了不同的活动。与其尝试预先覆盖场景，不如按需、增量和迭代地编写它们，这意味着您可以更好地应对需求的变化。然而，从用户故事中删除重复是相当困难的，并且场景的 Given-When-Then 模板将用例的功能性质替换为有限状态机。
【讨论】：