Я видел, как это обрабатывается несколькими способами:
Создается артефакт для хранения бизнес-правила, который хранится в некотором центральном хранилище всех правил, так чтоизвестен всей команде разработчиков и поддерживается хранилище знаний.Это может показаться уродливым, поскольку в течение нескольких лет после создания приложения могут быть сотни правил.
Правила могут быть помещены на отдельные карточки в истории пользователя.Таким образом, в то время как пользовательская история - это одна строка, может быть 6-8 карт, которые составляют все задачи для этой истории.Например, должна быть создана новая форма пациента, проверка на форме и т. Д. Таким образом, нетрудно увидеть, как этот фрагмент вверх по линии на карточке как способ отследить требование таким образом.Это самое естественное, на мой взгляд, хотя это не тот случай, когда конкретный список будет записан на 100%, так как карта может быть «убедитесь, что некоторые поля в форме являются обязательными».*
Там нет явной ссылки, а правило - это что-то для QA или BA, чтобы пользователь мог убедиться, что форма применяет это правило.Это похоже на один, но вопрос в том, какова ответственность разработчика в этом.В этом случае QA может отслеживать не сам разработчик, а, возможно, разработчик.
Пользовательская история предназначена для начала обсуждения, а не для исчерпывающего списка требований.Это правило должно выработаться, когда разработчик обсуждает с пользователем, что нужно для создания нового файла пациента, на мой взгляд.
Мне нравится идея подвешивания к карточкам для некоторыхспринты после того, как история была закончена, но я вижу смысл в том, что карты в конечном итоге будут уничтожены.В то же время, где-то должен быть код, который реализует правила в соответствующей области.Чтобы использовать пример, который вы разместили, может случиться так, что в некоторых местах список обязательных полей будет замечен, поскольку существует слой пользовательского интерфейса, который должен отображать поля и, возможно, сообщение об ошибке, но также должен быть некоторый уровень бизнес-логики, которыйимеет такую логику, чтобы увидеть, что некоторые поля были специально заполнены, прежде чем пытаться создать новый файл пациента.Строящаяся система также будет содержать правила в той или иной форме.