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

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

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

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

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

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

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


agile user-stories requirements business-rules
person code-gijoe    schedule 10.08.2010    source источник
comment
Я голосую за закрытие этого вопроса, потому что он не о программировании.   -  person Vadim Kotov    schedule 17.06.2021

Ответы (2)


arrow_upward
6
arrow_downward

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

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

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

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

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

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

person JB King    schedule 10.08.2010
comment
Итак, если во время обсуждения я соглашусь с несколькими правилами, я могу последовать вашему (2) предложению. Я думаю, это было бы неплохо. Единственная проблема в том, что пользовательские истории обычно саморазрушительны, т.е. я отбрасываю их после того, как история закончится. Так правила тоже теряются, или я ошибаюсь? - person code-gijoe; 11.08.2010

arrow_upward
1
arrow_downward

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

person user5344084    schedule 16.09.2015