Зачастую основные ошибки/недочеты/неточности обнаруживаются в критериях приемки к требованиям, хотя именно в них отражается основная информация для разработчиков и тестировщиков.

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

Привет, меня зовут Алёна, я бизнес-аналитик в Red Collar. В этой статье я собрала частые ошибки при написании критериев приемки к пользовательской истории. Предлагаю советы, которые стоит учесть при при разработке требований.

1. Идём от общего к частному

Определяем блоки функциональности, из которых будет состоять продукт, затем определяем конкретные функции. После чего пишем истории и критерии приемки к ним. Нет смысла закапываться в детали продукта на этапе дискавери или этапе определения видения и границ проекта.

Антипример: На первом созвоне с клиентом выяснять, какого цвета кнопку «Купить» он хочет видеть на сайте своего магазина.

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

2. Не используем в требованиях слова, отражающие субъективную оценку (небольшой/хороший/яркий и т д)

Антипример: «Заголовок должен быть кратким».

Пример: «Заголовок должен быть длиной не более 20 знаков с пробелами».

3. Описываем подробности только по согласованию с заказчиком, дизайнером и разработчиком. Если не знаем — ставим «TBD (To Be Determined)» и идем узнаем

Антипример: «При нажатии кнопки “Создать заказ” открывается всплывающее окно розового цвета с фанфарами и песней Валерия Меладзе на фоне».

Пример: При нажатии кнопки «Создать заказ» появляются поля создания заказа. Формат TBD.

4. Дотошность и внимательность — главные друзья БА

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

Важно внимательно вычитать все скопированное и убрать «лишние» слова из других требований. В работе БА количество требований и скорость их написания ничего не значат, если в итоге в требованиях много ошибок и опечаток, которые могут повлиять на разработку конечного продукта.

5. Пишем названия юзер стори (чтобы при беглом взгляде на заголовок понять, о чем речь)

Антипример: User Story №1. Как клиент магазина бытовой техники, я хочу зарегистрироваться на сайте магазина, чтобы оформить онлайн заказ.

Пример: US1 - Регистрация.  Как клиент магазина бытовой техники, я хочу зарегистрироваться на сайте магазина, чтобы оформить он-лайн заказ.

6. Не смешиваем разные функциональности

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

Антипример: В US про регистрацию написать: «После нажатия кнопки “Зарегистрироваться” открывается личный профиль клиента. Профиль состоит из …».

Пример: В US про регистрацию написать: «После нажатия кнопки “Зарегистрироваться” открывается личный профиль клиента. Функциональность профиля клиента описана в US2 - Профиль».

7. Не дублируем одну и ту же информацию

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

Антипример: Повторно описывать правила валидации параметров, которые уже были описаны в другой US.

Пример: Сослаться на другую US или сделать отдельную страницу для всех валидируемых полей и всегда ссылаться на нее.

8. Описываем результаты как положительного сценария, так и отрицательного

Антипример: «При заполнении всех полей в соответствии с правилами валидации, указанными в таблице 1, после нажатия кнопки “Создать” открывается окно создания заказа».

Пример: «При заполнении всех полей в соответствии с правилами валидации, указанными в таблице 1, после нажатия кнопки “Создать” открывается окно создания заказа. При заполнении хотя бы одного поля не в соответствии с правилами валидации после нажатия кнопки “Создать” появляется сообщение об ошибке. Возможный текст:…».

9. Добавляем диаграммы, схемы, вайрфреймы, но только если они несут ценность для понимания данной US

У оформления критериев приемки нет четких правил. Вы можете описывать функциональность, как считаете нужным, но только если это действительно важно для понимания принимающей стороной

Антипример: «US1 Регистрация. Диаграмма движения популяции морских котиков прилагается».

Пример: «US1 Регистрация. Диаграмма процесса регистрации с учетом интеграций со сторонним сервисом прилагается».

10. Добавляем ссылку на дизайн или прототип, обновляем по мере готовности

Антипример: Мысли разработчика при виде требований без ссылок на визуал: «Гора текста, ниче не понятно, еще и картинки нет».

Пример: Мысли разработчика при виде требований со ссылками на прототип: «Гора текста, ниче не понятно, хоть картинка есть, слава Богу».

11. Всегда думаем головой в каждом конкретном проекте

Антипример: «В статье читал(а), что можно только так, поэтому лучше напишу, как там было указано».

Пример: «Автор статьи не видит этот конкретный проект и, если мне кажется, что здесь стоит применить другой подход, но я не уверен(а), стоит посоветоваться с коллегами».

Выводы: всегда есть место развитию

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

Данные пункты «не высечены в камне»: в разных компаниях в зависимости от уровня специалистов и других критериев подобный список может меняться. Надеюсь, что рекомендации помогут вам избежать ошибок при разработке требований к ПО и стать тем самым аналитиком, работать с которым на проекте — одно удовольствие!