Всем привет! Меня зовут Ольга. Я middle системный аналитик в крупной российской IT-компании.

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

Немного теории

Что такое бизнес-история?

Бизнес-истории (или также называемые "бизнес-сценарии" или "сценарии использования") представляют собой инструмент в области системного анализа, который используется для описания взаимодействия между пользователями и информационной системой. Они фокусируются на рассказе о том, как пользователи взаимодействуют с системой в рамках определенного бизнес-процесса или ситуации.

Зачем нужны бизнес-истории?

1. Понимание бизнес-потребностей: Бизнес-истории помогают системным аналитикам и разработчикам полностью понять бизнес-процессы и потребности пользователей. Это позволяет создавать информационные системы, которые действительно соответствуют бизнес-целям и требованиям.

2. Улучшение коммуникации: Описывая взаимодействие пользователей с системой в виде историй, бизнес-истории способствуют более ясному и понятному обмену информацией между участниками проекта, включая заказчика, разработчиков и тестировщиков.

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

Как пишутся бизнес-истории?

При написании бизнес-историй важно сосредоточиться на ключевых аспектах взаимодействия пользователей с системой. Каждая бизнес-история должна включать в себя следующие элементы:

1. Заголовок или название: Краткое описание ситуации или процесса, который описывается в истории.

2. Роли пользователей: Определение ролей пользователей, которые взаимодействуют с системой, и их целей или задач в рамках данной истории.

3. Описание сценария: Последовательное описание шагов или действий, которые выполняются пользователями в рамках бизнес-процесса.

4. Ожидаемый результат: Описание ожидаемого результата или цели, которую должна достичь система в результате выполнения данного сценария.

А зачем нужен гайд для самопроверки?

... спросите вы)

Вот и я надеюсь, что нет)

Итак, приступим к пошаговой проверке своей бизнес-истории

Шаг №1. В пользовательской истории указан явный бизнес-бенефит. Ключевое слово "бизнес"

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

Шаг №2. В матрицу ролей добавлены все необходимые полномочия (на объекты и операции)

Полномочия. Не роли. Полномочие можно дать любой роли, поэтому роль тут вторична.

Шаг №3. В бизнес-истории покрыта только одна бизнес-история

Ключевое слово "одна" - ни больше, ни меньше)

В бизнес-истории на создание не может быть просмотра карточки. В бизнес истории просмотра карточки не может быть редактирования. В удалении не может быть просмотра списка. И т.д. И т.п.

Если при самопроверке выясняется, что бизнес-история покрывает несколько других - декомпозируй!

Шаг №4. В бизнес-истории указано, должна ли она лицензироваться, и как проверяется лицензия

Шаг №5. В доменную модель добавлены все необходимые сущности и атрибуты

** А у атрибутов указаны тип, обязательность (мандаторность) и множественность.

Шаг №6. Доменная модель бизнесовая, не физическая (техническая)

БД и UI обманчивы - мы им доверяем, но проверяем. Они не равны бизнесовой доменной модели, потому что по доменной модели мы можем 100-500 разных ERD спроектировать, и все они не будут ей противоречить.

Пожалуйста, не ограничивай себя физической (технической) реализацией - абстрагируйся! Тогда, если она изменится, тебе не придётся переделывать доменку).

Шаг №7. Множественность связей между сущностями не противоречит множественности атрибутов, за эти связи отвечающие

Пример: Если атрибут "Департамент" в сущности "Должность" помечен как [1], то как бы странно видеть на связи между сущностями "Департамент" и "Должность" [0..1] возле сущности "Департамент".

Шаг №8. В доменной модели отсутствуют дублирования атрибутов

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

2. Если две сущности связаны, то атрибут, обеспечивающий связь, должен быть в той, где он жёстко необходим при создании её экземпляра.

Шаг №9. Агрегации действительно являются агрегациями

ЕСЛИ

1. экземпляр одной сущности нефункционален, когда у него нет связи с экземплярами другой сущности

   ИЛИ

2. этот экземпляр для нас "странненький", когда у него нет связи с экземплярами другой сущности ("странненький" = аномальный, ненормальный, любопытный, интересный, привлекающий внимание, корявый, нам хочется его исправить или "грохнуть"))

ТО Скорее всего данная сущность агрегирует вторую (белый ромбик).

Шаг №10. Сочетания\композиции действительно являются сочетаниями\композициями

ЕСЛИ

1. при удалении экземпляра одной сущности удаляются связанные с ним экземпляры другой сущности

   ИЛИ

2. при потере доступа к экземпляру одной сущности теряется доступ и к связанным с ним экземплярам другой сущности

ТО Скорее всего данная сущность сочетает\композирует вторую (чёрный ромбик).

Шаг №11. В доменной модели нет уродских неэстетичных пересечений линий

up, down, left, right на связях в помощь.

Шаг №12. Были сделаны изменения (ЕСЛИ ОНИ НЕОБХОДИМЫ) в доменной модели операционного слоя с поддоменами

Важно! Обновление схемы только после согласования изменений с ответственным за доменную модель операционного слоя.

Шаг №13. Все новые\изменённые сущности и атрибуты доменной модели проросли в словари сущностей

Иначе рассинхрон! Рассинхрон ведёт к бардаку! Бардак всех выбешивает агрит)

Шаг №14. Словари сущностей не противоречат доменной модели

Если противоречат, разберись:

1. сперва поправь доменную модель

2. уже потом словарь

Иначе см.про рассинхрон выше

Шаг №15. ERD не противоречит доменной модели и словарям сущностей

Если противоречит, разберись:

1. сперва поправь доменку

2. потом словари

3. уже потом ERD

Иначе см. про рассинхрон выше

Шаг №16. ERD нормализована хотя бы до третьей нормальной формы

Если не знаешь/забыл нормальные формы, велкам во всемогущий гугл)

Шаг №17. В диаграмме бизнес-процесса есть и слой бэка, и слой фронта

Иначе мы не сможем отловить места, где необходима серверная валидация.

Шаг №18. В любом действии, меняющем данные системы, на диаграмме бизнес-процесса есть и клиентская, и серверная валидация

** И они влекут за собой ошибки, с которыми пользователю что-то надо делать.

Шаг №19. В любом действии на стороне бэка есть ошибочный флоу

Мы не покрываем системные ошибки критериями приёмки, но мы указываем этот флоу для понимания рисков и ассампшенов.

Шаг №20. Если у вас диаграмма последовательности (sequence), то все "барчики" вовремя активируются и вовремя деактивируются

Иначе будет путаница и нелестные выражения в ваш адрес от лида системного анализа)

Шаг №21. Все критерии приёмки сгруппированы, а группы названы и выделены, чтобы облегчить чтение и восприятие

Шаг №22. Каждый критерий, как реченька, вытекает из предыдущего и не тянет с собой многокилометровый хвост из прекондишенов

Пример: Если в первом критерии у вас по прекондишену наличия прав показывается форма, то в следующем, связанном с ним критерии, не нужно снова упоминать права - пишем сразу "я УЖЕ вижу форму".

Шаг №23. Прекондишен лежит в прекондишене, тригер - в тригере, а результат - в результате

Тригер - это ДЕЙСТВИЕ. Самое последнее действие, после которого происходит подкапотный мэйджик

1. Не результат, который мы получим в мэйджике

2. Не заклинание, которое надо произнести прежде чем ударить волшебной палочкой об капот

3. А сам удар волшебной палочкой по капоту

Надеюсь, моя метафора понятна))

Шаг №24. Из каждой развилки на диаграмме бизнес-процесса (альтернатива в сиквенсе или шлюз "X" в BPMN) появились дочерние критерии, разбившие исходный по прекондишенам развилки

Шаг №25. Из каждого "сливания в экстазе" на диаграмме бизнес-процесса (шлюз "+" в BPMN или opt в сиквенсе) появился общий критерий на те части блоков, что оказались в итоге общими, не смотря на развилки. А уже из этого общего критерия появились дочерние, покрывающие каждую развилку

Магическая фраза в прекондишене "Вне зависимости от:" в помощь

Шаг №26. В колонке "результат" нет никаких ИЛИ - только И

Шаг №27. Увидел в прекондишенах или тригерах и И, и ИЛИ - остановился, выдохнул, подумал и решил - нужны ли скобки, и где, и почему

Есть малейшие сомнения? Открой гугл и освежи свои познания логических операторов.

Шаг №28. Критерии приёмки кратки, лакончины, легкопонимаемы и бизнесовы

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

Шаг №29. Во всех критериях, влияющих на изменение данных в системе, есть ссылка на таблицу валидации

*И все возможные учтённые ошибки - в ней, не в ста-мильёнах критериев на ошибки!

Шаг №30. Таблица валидации содержит все возможные бизнесовые ошибки. Системные тоже может, но главное - бизнесовые

Серверная валидация - это защита от дурака. Она есть всегда, её не может не быть. Фронта может не быть. На фронте может быть баг. Фронт может быть чужой. Но защита от дурака на сервере должна быть всегда. Потому что, дурак, вызвавший API напрямую, подсмотрев его в браузере, может оказаться очень умным

1. Уникальность проверяется на сервере

2. Проверка на максимальную длину все равно проверяется на сервере, даже если есть ограничения на фронте

3. Проверка полномочий дублируется на сервере

4. Все виды рассинхона проверяются на сервере - пока ты заполнил форму, ушёл пить кофеек, а потом вернулся, чтобы нажать на кнопку "Сохранить", на сервере всё могло давным-давно поменяться

Шаг №31. Критерии приёмки не противоречат доменной модели, словарям сущностей и диаграмме бизнес-процесса

Если противоречат, разберись:

1. сперва поправь доменку

2. потом словари

3. потом диаграмму бизнес-процесса

4. уже потом критерии приёмки

Иначе см. про рассинхрон выше

Шаг №32. Ты подумал о тестировщиках и поэтому все названия колонок, полей, их видимости, фильтруемости, сортируемости, типа виджета или элемента и прочей фронтовой шняги в дизайне строго совпадают с тем, что указано в требованиях к пользовательскому интерфейсу

Да, я тоже считаю, докапывание до подобных вещей недостойным внимания аналитика, но первое с чем придут к вам тестировщики, тестируя ваши фичи, это вот оно вот это самое.

Шаг №33. Дизайн не противоречит доменной модели, словарям сущностей, диаграмме бизнес-процесса и критериям приёмки

Если противоречит, разберись:

1. сперва поправь доменку

2. потом словари

3. потом диаграмму бизнес-процесса

4. потом критерии приёмки

5. уже потом дизайн

Иначе см. про рассинхрон выше

Шаг №34. API\Events не противоречат доменке, словарям сущностей, ERD, диаграмме бизнес-процесса и критериям приёмки

Если противоречит, разберись:

1. сперва поправь доменку

2. потом словари

3. потом ERD

4. потом диаграмму бизнес-процесса

5. потом критерии приёмки

6. уже потом API\Events

Иначе см. про рассинхрон выше

Шаг №35. Иерархия страниц тоже рассказывает историю, а не взрывает мозг

Самая первая в дереве - доменная модель, потом ERD, потом словари, потом общие ассампшены, потом общие риски, потом бизнес-истории в каком-то все же логичном порядке или хотя бы в порядке приоритета. Прошлись по дереву - уже в голове что-то структурировалось.

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

---

А теперь возьми свою бизнес-историю и проанализируй ее, используя все эти шаги.

Если все ответы на предыдущие пункты "ДА", то можешь выдохнуть и выпить чашечку ароматного кофе, а бизнес-историю отдать в груминг\на перепроверку лиду

Hidden text

Ну и молиться, чтобы от команды не прилетели правки, и не пришлось откатываться до заводских настроек твоей стори))

Заключение

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

Делитесь в комментариях, каких правил вы придерживаетесь при написании и проверке бизнес-историй. Очень интересно узнать ваш опыт и использовать его на практике!