我有一组用户故事和一组业务规则(主要是约束我的合规要求的法律)。在敏捷 SDLC 中,我不确定这些“规则”在我的用户故事中的位置。
例如,像这样的用户故事:
作为一名医生,我想添加患者信息以创建新的患者文件。
和这样的规则:
必须在每位患者的记录中输入以下信息: (a) 患者: (i) 姓名和名字;(ii) 地址;(iii) 出生日期;(iv) 性别;
这两个显然结合在一起,但我怎样才能将它们联系起来呢?作为我的用户故事中的测试验收定义?另一个用户故事?
我有一组用户故事和一组业务规则(主要是约束我的合规要求的法律)。在敏捷 SDLC 中,我不确定这些“规则”在我的用户故事中的位置。
例如,像这样的用户故事:
作为一名医生,我想添加患者信息以创建新的患者文件。
和这样的规则:
必须在每位患者的记录中输入以下信息: (a) 患者: (i) 姓名和名字;(ii) 地址;(iii) 出生日期;(iv) 性别;
这两个显然结合在一起,但我怎样才能将它们联系起来呢?作为我的用户故事中的测试验收定义?另一个用户故事?
我已经看到了几种不同的处理方式:
创建一个工件来保存业务规则并存储在所有规则的某个中央存储库中,以便整个开发团队都知道这一点,并维护知识库。这可能会变得很难看,因为在构建应用程序的短短几年内可能会有数百条规则。
规则可以放在用户故事中的不同卡片上。因此,虽然用户故事是那一行,但可能有 6-8 张卡片构成了要完成该故事的所有任务。例如,必须创建一个新的患者表格,在表格上进行验证等。因此,不难看出这在卡片上的一行是一种以这种方式跟踪需求的方式。这对我来说是最自然的,尽管这不是将具体列表 100% 写下来的地方,因为卡片可能是“确保表格上的某些字段是强制性的”。
没有明确的链接,而是规则是 QA 或 BA 需要注意的,以便用户验证表单是否强制执行此规则。这类似于一个,但问题是开发人员在这方面的责任是什么。在这种情况下,可能是 QA 而不是开发人员来跟踪的东西。
用户故事旨在开始讨论,而不是需求的完整列表。当开发人员与用户讨论如何在我的脑海中创建新的患者文件时,该规则应该出现。
我喜欢在故事完成后在卡片上坚持几个冲刺的想法,但我确实看到卡片最终会被摧毁的观点。同时,应该有代码在其适当的区域实现规则。要使用您发布的示例,可能会在一些地方注意到必填字段列表,因为有 UI 层必须显示字段并且可能会显示错误消息,但也应该有一些业务逻辑层有这个逻辑可以看到在尝试创建新患者文件之前专门完成了某些字段。正在构建的系统也将以某种形式包含规则。
As acceptance criteria. After all these are rules that can be executed as tests. Definitely not new stories, that would just be wrong as there is no deliverable goal.