我有一组用户故事，我有一套业务规则（主要是法律约束我的要求是合规的）。在Agile SDLC中，我不确定这些“规则”在哪里附加到我的用户故事中。
例如，用户故事如：
作为医生，我想添加患者信息以创建新的患者档案。
这样的规则：
必须在每位患者的记录中输入以下信息： （病人： （i）姓名和名字; （ii）地址; （iii）出生日期;和 （iv）性别;
这两个显然是在一起，但我如何链接它们？作为我的用户故事中的测试验收定义？另一个用户故事？
答案 0 :(得分：5)
我看到过这种处理的方式有几种：
创建工件以保存业务规则，并存储在所有规则的某个中央存储库中，以便在整个开发团队中了解这一点，并维护知识库。这可能会变得很难看，因为在构建应用程序的短短几年内就可能有数百条规则。
规则可以放在用户故事中的单独卡片上。因此，虽然用户故事是一行，但可能有6-8张卡构成该故事的所有任务。例如，必须创建一个新的患者表格，在表格上进行验证等。因此，不难看出这种情况在卡片上显示为一种跟踪需求的方式。这是我最自然的想法，虽然这不是特定列表将被100％写下来的地方，因为卡片可以“确保表格上的某些字段是强制性的。”
没有明确的链接，而是规则是QA或BA的注意事项，供用户验证表单是否执行此规则。这类似于一个，但问题是开发人员在这方面的责任是什么。在这种情况下，QA可能会跟踪而不是开发人员。
用户故事旨在开始讨论，而不是完整的要求列表。当开发人员与用户讨论如何创建新的患者文件时，该规则应该会出现。
我喜欢在故事结束后挂上卡片进行一些短跑的想法，但我确实看到卡片最终会被摧毁的意思。同时，应该有代码在某个地方实现规则。要使用您发布的示例，可能会在一些地方注意到所需字段的列表，因为UI层必须显示字段并且可能是错误消息，但也应该有一些业务逻辑层有这个逻辑，看到在尝试创建一个新的患者文件之前，某些字段是专门完成的。正在构建的系统也将以某种形式存储规则。
答案 1 :(得分：1)
作为验收标准。毕竟这些是可以作为测试执行的规则。绝对不是新故事，因为没有可交付的目标，这只会是错误的。