大象不是长颈鹿，不需要用户故事。它们具有共同的特征和共同的背景，但这并不等同于它们。但是，许多人认为用户故事是对传统上所谓的软件需求的一种新读法-毕竟，项目中一定有需求，对吗？因此，我会回答-不，再一次不。首先，这些不是需求，其次，需求不是我们真正需要的。首先，用户故事是一个机会，可以看到不同的实现选项，以便以后您可以利用已经开放的机会。需求...就是提前解决所有问题，以便以后陷入困境。
写这样的文章有什么意义吗？以上似乎不明显吗？不，我相信，诸如“积压需求”之类的频繁陈述表明，思维范式保持不变，只是迹象已经改变。需求文档开始被称为待办事项，需求本身即用户故事，现在我们变得“敏捷” ...
另一个可能引起误解的迹象是广泛存在的做法，即通过分配唯一ID将用户故事存储在数据库中。这样做可能只是为了方便起见，但这可能是持久地根据需求进行思考的结果。
但是，将用户故事包含在合同中的做法已经100％表示已将用户故事视为要求。这里的问题是，根据定义，用户故事不能像要求那样明确，这会使合同贬值。当然，有时也可以相当自由地解释需求，但是最初编写需求的技巧就意味着消除了模棱两可，这对于用户故事是不能说的。此外，由于需求已包含在项目合同中，因此可以灵活地进行更改。为了更改或添加新要求，必须将它们通过CCB传递。换句话说，利益相关者必须首先同意并批准。有关合同的更多详细信息，请参见下文。
那么什么是用户故事？将它们视为计划工具。在用户故事的帮助下，我们确定优先级，评估并确定将在哪个sprint中实施相应功能。这些都是计划工具的典型功能，因此请勿尝试将其转换为其他功能。
用户故事的力量在于它们引发了对话。我们开始讨论，而不只是将规范传递给同事，该规范首先由开发人员解释，然后由测试人员解释。我们包括具有不同沟通技巧的员工。等等-每个新功能。
由于用户故事本身并没有多大意义，因此我们可以在实现相应功能后将其丢弃。如果您愿意，您可以仔细保存销售的故事数的统计信息，但这是完全有可能且有限的。
事实证明，我们不需要要求吗？实际上这是不正确的。毕竟，一种方式或其他方式都有局限性。例如，医疗设备必须符合FDA法规。因此，我们称它们为约束！
但是，这些要求详细描述了系统，也许这样的描述对我们有些价值？例如，如果我们没有以一种或另一种形式提出的正式要求，我们如何确定系统的某些行为是否是错误？ “示例规范”技术将在这里为我们提供帮助。因此，决定需要实现某些功能。您以下列方式编写业务规则和一系列示例：a）易于阅读； b）可实现的。根据该描述，应该清楚系统应该做什么。而且，如果由于更改而出现问题-违反业务规则是导致此功能失调的原因。
如我之前所写，该错误的描述应该简单明了。错误是破坏信息的事物，无论我们是否有一个涵盖特定案例的需求描述，它们都是不好的。
合同
（由Matthias Skarin撰写）
那么我们将使用什么代替需求规范？毕竟，我们需要了解我们是否已完全实施了所需的服务？我们将使用敏捷合同。敏捷-合同是为树木看森林的机会，它们使您可以专注于项目的实质和目标的共同实现，该目标的实施将满足用户的需求。
请记住，当您在项目期间考虑合同以检查您的合作伙伴是否违反任何条款时，这已经意味着出现了问题。合同必须在各方之间建立信任，以便有可能超越细节，而不会陷入细节之中。
概要
- 尽管大象和长颈鹿都有四只脚，但它们是不同的动物。
- 用户故事不是要求，而是计划工具。
- 与要求最接近的是“按规格说明”。