Понятные требования удобно писать через user story для ценности и критериев приёмки, а use case - для пошаговых сценариев и исключений. Начните с цели пользователя и границ фичи, зафиксируйте допущения, затем оформите story по шаблону и добавьте тестируемые acceptance criteria. Для сложных потоков допишите use case и проверьте формулировки на однозначность.
Что важно помнить при формулировке требований
- Пишите про наблюдаемое поведение системы и результат для пользователя, а не про реализацию.
- Одна формулировка - один смысл: избегайте "и/или", скрытых условий и "по возможности".
- Всегда фиксируйте контекст: роли, ограничения, платформы, состояния данных, права доступа.
- Критерии приёмки должны быть проверяемыми: их можно превратить в тестовые шаги без догадок.
- Сначала договоритесь о границах: что входит в задачу, что явно не входит, какие допущения приняты.
- Для сложных ветвлений выбирайте use case, для продуктовых итераций - user story с критериями.
Понятие и роль user story в продуктовой разработке
User story - короткое описание потребности пользователя и ожидаемой ценности, удобное для планирования итераций и диалога "продукт-разработка-тестирование". Подходит, когда важно быстро уточнять требования, декомпозировать работу и согласовывать результат через критерии приёмки.
Когда user story уместны:
- фича даёт измеримый пользовательский результат и укладывается в 1-2 итерации после декомпозиции;
- есть понятная роль (персона) и контекст использования;
- команда готова обсуждать детали в разговоре, а не "прятать" всё в документ.
Когда лучше не ограничиваться user story:
- много ветвлений, исключений, альтернативных путей - нужен пример use case или модель процесса;
- высокие риски интеграций/безопасности/регуляторики - нужны отдельные нефункциональные требования и ограничения;
- важны точные состояния и переходы (сложные статусы, очереди, таймауты) - нужны диаграммы/спецификация состояний.
Если вы проходите обучение бизнес анализу требования, начинайте с user story как базового формата, но заранее оговаривайте, чем вы дополняете story для сложных сценариев.
Структура грамотной user story и правила INVEST
Базовый шаблон user story: "Как <роль> я хочу <действие/возможность>, чтобы <ценность/результат>". Дальше обязательно добавьте критерии приёмки и примечания по ограничениям.
Мини-структура одной story
- Заголовок - коротко, про результат (не про кнопку/экран).
- Формулировка по шаблону "роль-хочу-чтобы".
- Контекст: где работает, для кого, какие права/статусы/платформы.
- Acceptance criteria в формате Given/When/Then или списком условий.
- Out of scope: что точно не делаем в этой итерации.
- Риски и вопросы на уточнение (если есть).
INVEST как быстрая самопроверка
- I (Independent): по возможности независима от других задач или имеет явные зависимости.
- N (Negotiable): это повод для разговора; детали фиксируются критериями и уточнениями.
- V (Valuable): приносит ценность пользователю/бизнесу, а не только "техдолг ради техдолга".
- E (Estimable): команда понимает объём; если нет - дробите или уточняйте неизвестности.
- S (Small): достаточно мала для итерации; иначе - разрезайте по ценности/вариантам/платформам.
- T (Testable): есть проверяемые критерии приёмки.
Что понадобится до того, как писать
- Доступы и контекст: демо/стенд, текущая версия продукта, аналитика событий (если есть), политика ролей/прав.
- Согласованные термины: глоссарий (пусть даже на 10 строк) для ключевых сущностей.
- Решения по границам: какие платформы (web/iOS/Android), локали, минимально поддерживаемые версии, ограничения по данным.
- Инструменты: из инструменты для написания требований обычно достаточно связки трекера задач (Jira/YouTrack), базы знаний (Confluence/Notion) и доски (Miro/FigJam) для сценариев.
Если вы ищете курс написание требований, выбирайте программу, где отдельно отрабатываются критерии приёмки и декомпозиция, а не только формат "роль-хочу-чтобы".
Use case: когда выбирать и как описывать сценарии
Use case полезен, когда нужно описать пошаговое взаимодействие актёра с системой, альтернативные ветки, ошибки и пред-/постусловия. Он дополняет user story и снижает риск "мы все по-разному поняли поток".
Риски и ограничения перед описанием сценариев
- Риск скрытых состояний: один и тот же шаг ведёт к разным результатам из-за статуса/прав/данных. Смягчение: явно перечислите пред-условия и статусы.
- Риск разночтений терминов: "заказ", "заявка", "бронь" называются одинаково, но ведут себя по-разному. Смягчение: короткий глоссарий и ссылки на сущности.
- Риск "сценарий вместо цели": описание экранов без ценности. Смягчение: в начале use case фиксируйте цель актёра и бизнес-результат.
- Риск бесконечных ветвлений: документ разрастается и перестаёт использоваться. Смягчение: выделяйте отдельные use case на ключевые альтернативы и ошибки.
Пошаговая инструкция по написанию use case
- Определите актёра и цель. Назовите роль (кто) и результат (зачем), который должен быть достигнут без описания интерфейса. Если актёров несколько, выберите первичного (инициатор сценария).
- Зафиксируйте границы системы. Укажите, какие системы участвуют (продукт, платёжный провайдер, CRM) и что считается "внутри" вашего решения.
- Подсказка: перечислите интеграции и точки обмена данными.
- Опишите пред- и постусловия. Предусловия - что должно быть истинно до старта (авторизация, роль, наличие данных). Постусловия - что гарантируется после успеха и после отказа.
- Напишите основной успешный поток. Пронумеруйте шаги "Актёр → Система", по одному действию на шаг, с видимым результатом. Держите язык проверяемым: "система отображает/создаёт/сохраняет/отправляет".
- Добавьте альтернативы и исключения. Для каждого критичного условия (ошибка валидации, нет прав, таймаут, дубль) опишите отдельную ветку и точку возврата в основной поток.
- Правило: если ветка больше 5-7 шагов, выделяйте её в отдельный use case.
- Привяжите к проверкам. Для ключевых шагов выпишите, чем подтверждается результат (лог, изменение статуса, запись в БД, событие аналитики, уведомление). Это делает сценарий тестопригодным.
Если вам нужен быстрый пример use case, начните с 6 пунктов: актёр, цель, предусловия, основной поток (5-12 шагов), альтернативы, постусловия.
Практические шаблоны и примеры рабочих формулировок
Альтернативы формулировок по уровню детализации
- Коротко (для груминга): "Как покупатель хочу сохранить корзину, чтобы вернуться к ней позже".
- Средне (для разработки): + ограничения (гость/авторизованный), где хранится, срок, что происходит при изменении цены.
- Подробно (для сложных потоков): + use case с альтернативами, ошибки, нефункциональные требования (скорость, аудит, безопасность).
Таблица примеров: story → критерии приёмки → тестовые шаги
| User story | Acceptance criteria | Тестовые шаги |
|---|---|---|
|
Как пользователь хочу восстановить пароль по email, чтобы снова войти в аккаунт. Риск: утечка информации о существовании аккаунта. |
|
|
|
Как менеджер хочу экспортировать список заявок в CSV, чтобы анализировать их офлайн. Риск: неполный/некорректный состав полей и кодировка. |
|
|
|
Как пользователь хочу видеть причину отклонения формы, чтобы быстро исправить данные. Риск: "Ошибка 400" без указания поля приводит к росту обращений. |
|
|
Проверка результата: чек-лист перед тем, как отдавать в разработку
- Есть роль, цель и ценность; формулировка не про "добавить кнопку/поле", а про результат.
- Указаны границы: платформы, роли/права, статусы, зависимости от интеграций.
- Термины однозначны и совпадают с глоссарием/доменной моделью.
- Критерии приёмки проверяемы и не содержат "быстро", "удобно", "корректно" без определения.
- Out of scope прописан хотя бы одной строкой, чтобы предотвратить расползание.
- Учтены негативные сценарии, которые наиболее вероятны или наиболее дорогие по риску.
- Story/сценарий можно оценить; неизвестности вынесены в отдельные вопросы/спайки.
- Понятно, как подтвердить результат (экран, статус, файл, уведомление, событие).
Проверка качества: критерии приёмки и тестируемости
- Ошибка: критерии приёмки повторяют story ("пользователь может..."). Как исправить: перепишите в наблюдаемые условия и ожидаемые результаты (Given/When/Then).
- Ошибка: "должно быть удобно/быстро/понятно". Как исправить: определите, что именно считается успехом (сообщение об ошибке рядом с полем, формат, ограничения, поведение при пустых данных).
- Ошибка: не указаны роли и права. Как исправить: добавьте матрицу доступа в примечания или отдельный критерий: "для роли X доступно, для Y - нет".
- Ошибка: пропущены негативные сценарии (ошибки сети, дубль, отсутствие данных). Как исправить: выделите 2-3 самых вероятных/критичных отказа и опишите ожидаемое сообщение/поведение.
- Ошибка: смешаны несколько фич в одной story. Как исправить: разрежьте по ценности: базовый путь отдельно, расширения (фильтры, экспорт, уведомления) - отдельными story.
- Ошибка: формулировки завязаны на UI-реализацию ("кнопка справа"). Как исправить: описывайте намерение и результат; UI-детали оставляйте как необязательные заметки/макеты.
- Ошибка: нет проверяемого источника истины (что считать "сохранено"). Как исправить: укажите подтверждение: запись появляется в списке, меняется статус, приходит письмо, доступен файл.
- Ошибка: критерии конфликтуют между собой или с ограничениями. Как исправить: введите явные приоритеты и единый набор ограничений (например, какие поля обязательны всегда).
Типичные ошибки и риски при формулировке требований
Когда user story и use case недостаточно, используйте подходы ниже - они помогают снизить риски недопонимания и скрытых допущений.
- Specification by Example (примеры вместо абстракций). Уместно, когда логика правил сложная (скидки, проверки, расчёты). Формат: набор примеров входов/выходов + граничные случаи; снижает риск спорных трактовок.
- BDD-формат (Given/When/Then) как основной носитель. Уместно, когда важна тестируемость и общая "языковая" рамка для QA/разработки/аналитики. Риск: превращение в "простыню"; смягчение - группируйте по сценариям и держите один смысл на шаг.
- Моделирование состояний (state machine). Уместно для сущностей со статусами и переходами (заказ, заявка, тикет). Снижает риск "а что, если статус уже такой?" и помогает покрыть исключения.
- Прототип + ограниченный текст требований. Уместно для интерфейсных задач, где важно быстро согласовать UX. Риск: прототип воспринимают как точную спецификацию; смягчение - отдельно фиксируйте поведение, ошибки, права и нефункциональные требования.
Ответы на распространённые практические сомнения по требованиям
Можно ли ограничиться одной user story без критериев приёмки?
Нежелательно: без acceptance criteria команда начнёт дополнять требования догадками. Минимум - 3-5 проверяемых условий успеха и отказа.
Как понять, что пора писать use case, а не дополнять story?
Если есть ветвления, возвраты, исключения и зависимости от статусов/ролей, use case быстрее убирает неоднозначности. Story оставьте для ценности и рамок, а поток вынесите в сценарий.
Что делать, если заказчик просит сделать как в другом продукте, без деталей?
Зафиксируйте цель и ограничения, затем переведите референс в наблюдаемое поведение через примеры и критерии. Ссылку на аналог оставьте как иллюстрацию, не как источник требований.
Как писать критерии приёмки, если UI ещё не спроектирован?
Описывайте поведение и результат независимо от расположения элементов: что пользователь вводит, что система проверяет, что меняется в данных и что отображается/отправляется. UI-решения можно закрепить позже в макете.
Нужно ли в требованиях перечислять нефункциональные условия?
Да, если они влияют на реализацию и приёмку: безопасность, права, аудит, ограничения по данным, совместимость. Пишите их как проверяемые утверждения или явные ограничения.
Какие инструменты выбрать, если команда распределённая?
Достаточно трекера задач + базы знаний + доски для сценариев; главное - единые правила оформления и ссылки между артефактами. Из инструменты для написания требований выбирайте то, где проще поддерживать актуальность и поиск.
Как прокачаться быстрее: читать примеры или идти на курс?
Практика на реальных задачах важнее формата, но хороший курс написание требований ускоряет прогресс за счёт обратной связи. В рамках обучение бизнес анализу требования ищите домашние задания с разбором критериев приёмки и сценариев.
