📝 Документация фазы требований
Фаза требований является основой разработки на основе спецификаций, где расплывчатые идеи функций преобразуются в четкие, тестируемые требования с использованием формата EARS (Easy Approach to Requirements Syntax). Эта фаза обеспечивает общее понимание у всех заинтересованных сторон о том, что нужно построить, перед переходом к этапам проектирования и реализации.
Цель и задачи
Фаза требований служит для:
- Преобразования расплывчатых идей в конкретные, измеримые и тестируемые требования
- Установления четких критериев приемки для оценки успешности функции
- Создания общего понимания между всеми участниками проекта
- Предоставления основы для принятия решений на этапах проектирования и реализации
- Обеспечения эффективных стратегий тестирования и валидации
Пошаговый процесс
Шаг 1: Первоначальная генерация требований
Цель: Создать первый черновик требований на основе идеи функции
Процесс:
- Анализ идеи функции: Разбить основную концепцию на пользовательские сценарии
- Определение ролей пользователей: Выявить всех участников взаимодействия с функцией
- Формулировка пользовательских историй: Описать в формате "Как [роль], я хочу [функция], чтобы [преимущество]"
- Перевод в требования EARS: Преобразовать пользовательские истории в тестируемые критерии приемки
Ключевые принципы:
- Начинайте с пользовательского опыта, а не технической реализации
- Фокусируйтесь на наблюдаемом и измеримом поведении системы
- Систематически рассматривайте граничные случаи и сценарии ошибок
- Думайте о полном пользовательском пути, а не отдельных шагах
Шаг 2: Структурирование требований в формате EARS
Цель: Оформить требования в стандартизированном, тестируемом формате
Структура документа:
### Требование 1
**Пользовательская история:** Как [роль], я хочу [функция], чтобы [преимущество]
#### Критерии приемки
1. КОГДА [событие] ТО [система] ДОЛЖНА [ответ]
2. ЕСЛИ [предварительное условие] ТО [система] ДОЛЖНА [ответ]
3. КОГДА [событие] И [условие] ТО [система] ДОЛЖНА [ответ]
[Дополнительные требования...]
Основные шаблоны EARS
1. Простое событие-ответ (наиболее частый шаблон)
Используется для прямого отклика системы на действие пользователя
Пример:
КОГДА пользователь нажимает кнопку "Отправить" ТО система ДОЛЖНА валидировать данные формы
2. Условное поведение
Применяется когда действие зависит от текущего состояния системы
Пример:
ЕСЛИ пользователь аутентифицирован ТО система ДОЛЖНА показать панель пользователя
3. Сложные условия
Комбинирует несколько условий с логическими операторами
Пример:
КОГДА пользователь отправляет форму И все обязательные поля заполнены ТО система ДОЛЖНА обработать отправку
4. Обработка ошибок
Описывает поведение системы в нештатных ситуациях
Пример:
КОГДА пользователь отправляет неверные данные ТО система ДОЛЖНА показать конкретные сообщения об ошибках
Руководство по применению EARS
- КОГДА: Всегда начинайте с триггерного события (действие пользователя или системное событие)
- ЕСЛИ: Используйте для описания предварительных условий, которые должны быть истинны
- ТО: Четко определяйте ожидаемое поведение системы (обязательно используйте "ДОЛЖНА")
- И/ИЛИ: Применяйте для комбинирования условий, но избегайте чрезмерной сложности
- ДОЛЖНА: Используйте последовательно для обязательных требований (не смешивайте с "МОЖЕТ" или "СЛЕДУЕТ")
Советы по формулированию
- Избегайте технических деталей реализации ("система использует Redis")
- Не используйте расплывчатые термины ("быстро", "удобно")
- Каждое требование должно быть независимым и тестируемым
- Проверяйте требования на полноту: нормальный путь, граничные случаи, ошибки
Шаг 3: Валидация требований
Критерии валидации:
- Каждое требование тестируемо и измеримо
- Требования покрывают нормальные, граничные и ошибочные сценарии
- Пользовательские истории предоставляют четкую бизнес-ценность
- Критерии приемки конкретны и недвусмысленны
- Требования независимы и не конфликтуют между собой
- Все роли пользователей и их взаимодействия учтены
Вопросы для проверки:
- Как мы проверим выполнение этого требования?
- Четко ли определено ожидаемое поведение?
- Какие предположения заложены в этом требовании?
- Что происходит при сбое или в нештатной ситуации?
- Все ли пользовательские сценарии учтены?
Шаг 4: Итеративное уточнение
Процесс уточнения:
- Обзор с заинтересованными сторонами: Сбор обратной связи по полноте и точности
- Выявление пробелов: Поиск отсутствующих сценариев или неясных формулировок
- Разрешение неоднозначностей: Устранение расплывчатых или конфликтующих требований
- Добавление недостающих деталей: Включение граничных случаев и обработки ошибок
- Проверка бизнес-ценности: Подтверждение, что каждое требование служит конкретной цели
Рекомендации:
- Вносите одно изменение за итерацию для отслеживания изменений
- Фиксируйте одобрение всех заинтересованных сторон после изменений
- Документируйте обоснование ключевых решений
- Поддерживайте баланс детализации: достаточно конкретно, но не на уровне реализации
Чек-лист итоговых требований
Полнота
- Все пользовательские роли и сценарии учтены
- Покрыты нормальные, граничные и ошибочные случаи
- Все взаимодействия имеют определенные системные ответы
- Бизнес-правила и ограничения явно зафиксированы
Ясность
- Требования используют точный, недвусмысленный язык
- Технический жаргон либо отсутствует, либо четко определен
- Формулировки сохраняют пользовательскую перспективу
- Ожидаемое поведение конкретно и измеримо
Согласованность
- Формат EARS применен последовательно во всем документе
- Терминология единообразна по всему документу
- Требования не противоречат друг другу
- Аналогичные сценарии обрабатываются по единому шаблону
Тестируемость
- Каждое требование можно проверить через тестирование
- Критерии успеха наблюдаемы и количественно измеримы
- Указаны как входные условия, так и ожидаемые результаты
- Формулировки достаточно конкретны для разработки тест-кейсов
Примеры корректно сформированных требований
Пример 1: Функция регистрации пользователей
Пользовательская история: Как новый пользователь, я хочу создать аккаунт, чтобы получить доступ к персонализированным функциям.
Критерии приемки:
- КОГДА пользователь предоставляет действительный email и пароль ТО система ДОЛЖНА создать новый аккаунт
- КОГДА пользователь предоставляет существующий email ТО система ДОЛЖНА показать ошибку "Email уже зарегистрирован"
- КОГДА пользователь предоставляет email в неверном формате ТО система ДОЛЖНА показать ошибку "Неверный формат email"
- КОГДА пользователь предоставляет пароль короче 8 символов ТО система ДОЛЖНА показать ошибку "Пароль должен содержать не менее 8 символов"
- КОГДА создание аккаунта успешно ТО система ДОЛЖНА отправить подтверждающий email в течение 30 секунд
- КОГДА создание аккаунта успешно ТО система ДОЛЖНА перенаправить на приветственную страницу
Пример 2: Функция валидации данных
Пользовательская история: Как пользователь, я хочу, чтобы мой ввод был валидирован в реальном времени, чтобы избежать отправки неверной информации.
Критерии приемки:
- КОГДА пользователь вводит данные в обязательное поле ТО система ДОЛЖНА убрать выделение ошибки для этого поля
- КОГДА пользователь отправляет форму с пустыми обязательными полями ТО система ДОЛЖНА выделить отсутствующие поля красным цветом
- КОГДА пользователь вводит данные, не соответствующие формату ТО система ДОЛЖНА показать требования к формату под полем ввода
- КОГДА все поля проходят валидацию ТО система ДОЛЖНА активировать кнопку отправки
- ЕСЛИ валидация не прошла ТО система ДОЛЖНА оставить кнопку отправки отключенной
- КОГДА пользователь наводит курсор на иконку подсказки ТО система ДОЛЖНА показать пример корректного формата
Распространенные ошибки и как их избежать
Ошибка 1: Расплывчатые формулировки
Проблема:
"Система должна быть быстрой и удобной"
Последствия:
Невозможно проверить выполнение, разные интерпретации
Как исправить:
"КОГДА пользователь запрашивает данные ТО система ДОЛЖНА отобразить результат в течение 2 секунд для 95% запросов"
Ошибка 2: Включение деталей реализации
Проблема:
"Система должна использовать Redis для кэширования данных"
Последствия:
Ограничивает возможности реализации, фокус на технике вместо результата
Как исправить:
"КОГДА пользователь повторно запрашивает часто используемые данные ТО система ДОЛЖНА возвращать результат в течение 500 мс"
Ошибка 3: Отсутствие обработки ошибок
Проблема:
Только описание "счастливого пути" без граничных случаев
Последствия:
Пробелы в функциональности, неожиданные сбои в работе
Как исправить:
Для каждого основного сценария добавьте 2-3 сценария обработки ошибок и граничных условий
Ошибка 4: Нетестируемые требования
Проблема:
"Интерфейс должен быть интуитивно понятным"
Последствия:
Невозможно подтвердить выполнение требования
Как исправить:
"КОГДА новый пользователь впервые заходит в систему ТО система ДОЛЖНА предоставить онбординг-тур, позволяющий выполнить основные действия за не более чем 3 клика"
Шаблон документа
# Требования к "[Краткое название функциональности]"
**Бизнес-цель:** [Описание бизнес-цели функции и её ценности для продукта/клиента]
**Область применения:** [Границы функциональности, что входит/не входит в функцию]
**Связанные документы:** [Ссылки на технические спецификации, пользовательские исследования и т.д.]
---
## [Название требования/функциональности]
**Пользовательская история:**
Как [роль пользователя], я хочу [описание функции], чтобы [бизнес-ценность/преимущество]
### Критерии приемки
*(Выберите подходящий шаблон EARS и заполните согласно инструкции)*
1. **[Простое событие-ответ]**
КОГДА [конкретное событие/действие пользователя] ТО система ДОЛЖНА [наблюдаемый результат]
*[Пример: КОГДА пользователь нажимает кнопку "Сохранить" ТО система ДОЛЖНА сохранить изменения в базе данных]*
2. **[Условное поведение]**
ЕСЛИ [предварительное условие/состояние системы] ТО система ДОЛЖНА [наблюдаемый результат]
*[Пример: ЕСЛИ корзина содержит товары ТО система ДОЛЖНА показать итоговую сумму]*
3. **[Сложное условие]**
КОГДА [событие] И [дополнительное условие] ТО система ДОЛЖНА [наблюдаемый результат]
*[Пример: КОГДА пользователь вводит пароль И длина пароля < 8 символов ТО система ДОЛЖНА показать ошибку]*
4. **[Обработка ошибок]**
КОГДА [нештатная ситуация] ТО система ДОЛЖНА [действие по обработке ошибки]
*[Пример: КОГДА соединение с сервером прервано ТО система ДОЛЖНА показать уведомление "Проверьте интернет-соединение"]*
*[Повторите структуру для каждого независимого требования]*
---
## Чек-лист качества требований
*(Заполняется после завершения документа)*
| Критерий | Выполнено | Комментарий |
| -------------------------------------------------------------------- | --------- | ----------- |
| Все требования тестируемы и измеримы | ☐ | |
| Покрыты нормальные, граничные и ошибочные сценарии | ☐ | |
| Отсутствуют технические детали реализации | ☐ | |
| Нет расплывчатых формулировок ("быстро", "удобно") | ☐ | |
| Все требования независимы и не конфликтуют | ☐ | |
| Для каждого требования указаны входные условия и ожидаемый результат | ☐ | |