Интеграция бизнес-правил с пользовательскими историями

Question

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

Например, рассказ о себе, например:

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

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

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

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

Answer 1

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

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

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

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

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

---

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

Answer 2

В качестве критериев приемлемости. В конце концов, это правила, которые могут быть выполнены как тесты. Определенно, не новые истории, это было бы неправильно, потому что цель не достижима.