Бизнес правила интеграции к историям пользователей

Question

У меня есть набор пользовательских историй, и у меня есть набор бизнес-правил (прежде всего законы, связывающие мои требования для совместимости). В Agile SDLC я не уверен, где эти «правила» прикреплены к моим историям пользователей.

Например, пользовательская история, как:

Как доктор, я хочу добавить информацию пациента, чтобы создать новый файл пациента.

И правило, как:

Следующая информация должна быть введена в записи каждого пациента: (а) пациента: (i) имя и имя; (ii) адрес; (iii) дата рождения; и (iv) секс;

Эти два явно собираются вместе, но как я могу связать их? Как определения принятия теста в моей пользовательской истории? Еще одна история пользователя?

Answer 1

Есть несколько разных способов, которыми я видел это обрабатываемое:

1. Артефакт создан для проведения бизнес-правила и хранится в каком-либо центральном хранилище всех правил, так что это известно на протяжении всей команды развития, а хранилище знаний поддерживается. Это может стать уродливым, так как могут быть сотни правил в течение нескольких лет построения приложения.

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

3. Там нет явной ссылки, а скорее правило - это то, что для Qa или Ba для того, чтобы пользователь, чтобы убедиться, что форма делает это правило. Это похоже на один, но вопрос в том, что ответственность за разработчик в этом. В этом случае это что-то для того, чтобы QA отслеживать, а не разработчики, возможно,.

Пользовательская история предназначена для начала обсуждения, а не всеобъемлющий список требований. Правило - это то, что должно придумать, когда разработчик обсуждает с пользователем, что нужно для создания нового файла пациента на мой разум.

---

Мне нравится идея висит на карточках для нескольких спринтов после того, как история была сделана, но я вижу точку, что карты в конечном итоге будут уничтожены. В то же время там должен где-то должен быть код, который реализует правила в его правильной области. Чтобы использовать пример, который вы опубликовали, может быть, что в нескольких местах будет замечен список обязательных полей, как есть слой пользовательского интерфейса, который должен отображать поля и, вероятно, сообщение об ошибке, но и должен быть какой-то уровень бизнес-логики, который Имеет эта логика, чтобы увидеть, что некоторые поля были специально завершены, прежде чем пытаться создать новый файл пациента. Созданная система также будет дополнять правила в какой-то форме или другой.

Answer 2

Как критерии приемки. Ведь это правила, которые могут быть выполнены в качестве тестов. Определенно не новые истории, которые бы просто ошибались, так как нет доставляющей цели.