用户故事设计约束

Question

如何将设计约束放入用户故事中？

待开发的系统将在付款时生成发票，并将发票发送到xMail (一种电子邮件工具)，然后将发票电子邮件发送给客户。

我应该如何将系统将发票发送到xMail的信息？

注意: xMail只是一个随机的名称，因为我无法透露实际名称。

Answer 1

考虑流程的关键步骤是什么，以及何时获得对客户的价值。试着在用户故事中捕捉到这一点。然后使用您的验收标准进一步清除需求。在故事中施加约束是没有错的；并不是每件事都可以/需要协商。

示例：

作为系统，我希望生成并发送一张发票给xMAIL，以便xMAIL可以将发票发送给客户。

1. 生成验证发票&在付款时发送。
2. 验证xMAIL接收发票
3. 验证客户通过xMAIL接收发票(这可以考虑在故事范围之外，因为xMAIL是一个外部系统。然而，它仍然是业务流程的一部分，也是QA候选)

Answer 2

用户故事对于捕获功能需求是很好的，但是对于设计约束和非功能需求，它们并不能很好地工作。

对于设计约束和非功能性需求，更传统的配方仍然是最有效的。

由于用户故事往往得到更多的关注，在故事的描述和可能的接受标准中引用相关的约束和非功能需求是一个好主意。

Answer 3

如果这是必需的，就把它写在故事里。只需确保这是一个实际的需求，而不是您对最终实现所做的假设。

作为该系统的用户，我希望在付款时向xMail发送发票，以便我们能够支持专门支持xMail的公司