Agile 如何在用户情景中定义默认行为

我目前正忙着为一个项目编写业务规则和用户故事。对于一些故事，应该有如下默认行为

该应用程序处理代表的订单。为某个区域下订单时，应选择默认仓库（某些区域有自己的仓库）

---

我想知道如何为用户故事定义这些行为。这些被认为是商业规则吗？

听起来你做得很好

是的，这绝对是属于用例的那种细节

---

依我看，默认行为是主要用户情景，任何替代方案都是另一个用户情景

所以是的，你必须添加这个用户故事

谢谢

拉德万先生

我想知道如何为用户故事定义这些行为

它们是您明确表示的用户期望

这些被认为是商业规则吗

对

棘手的是这一点

• 故事1：订单是手动处理的，用户选择仓库。这是每个人思想的前沿和中心。他们详细地讨论了这个问题

• 故事2：订单由系统自动处理，仓库由系统拾取。这是假定的。更重要的是，这里没有实际的用户交互。它只是在演员看不到或与之互动的情况下“发生”的。由于没有交互，这不是一个很好的用户故事。它不会导致一个花哨的屏幕和正常的工件，这些工件与用户与系统交互的适当用户故事一起出现

当“自动”或“默认”的事情发生时，用户故事就变成了一种退化的情况，因为没有屏幕、页面、表单或交互，似乎需要做的工作更少

然而，当“自动”或“默认”的事情发生时，某个地方的用户确实关心并且确实需要看到它发生了。即使它大量发生。在其他地方，用户故事2有一个变体

• 故事3：有人在某处检查默认仓库分配的计数和总数，包括手动和默认值。这里，默认仓库分配由与系统交互的参与者查看

---

自动或默认行为通常强调需要审查或审核或概述故事，以确保自动事件确实正确发生。

好的，那么这应该在用户故事中定义吗？像“在A区下订单时，应该使用1号仓库”这样的东西吗？我想你第一次做得更好。。。imhot这是一个很好的用户故事，您的“Region a=>Warehouse 1”将是一个很好的验收测试，可以验证这个故事。但最常见的是按场景分解用例/用户故事，然后在同一场景中讨论不同的备选方案（包括异常情况）。否则，您可能会失去“上下文”。这是一开始就有用例的要点。我投票结束这个问题，因为它与编程无关。