Признаки хороших требований
Признаки хороших требований
Введение
Не каждое требование одинаково полезно. Требование «система должна быть удобной» звучит хорошо, но протестировать его невозможно — удобство у всех разное. Хорошие требования имеют конкретные признаки, которые делают их пригодными для разработки и тестирования.
В этом уроке разберём критерии качественных требований и научимся отличать хорошие требования от плохих.
Критерии хороших требований
Однозначные (Unambiguous)
Требование должно иметь ровно одно толкование. Каждый член команды должен понимать его одинаково.
Плохо: «Система должна быстро загружать страницы» Хорошо: «Главная страница загружается за не более 3 секунд при скорости соединения 10 Мбит/с»
Полные (Complete)
Требование описывает все необходимые сценарии, включая граничные случаи и обработку ошибок.
Плохо: «Пользователь может войти в систему по email и паролю» Хорошо: «Пользователь может войти по email и паролю. При неверном пароле отображается сообщение "Неверный email или пароль". После 5 неудачных попыток аккаунт блокируется на 15 минут»
Непротиворечивые (Consistent)
Требования не должны конфликтовать друг с другом. Если два требования нельзя выполнить одновременно — одно из них неверно.
Пример противоречия:
- REQ-01: «Пользователь не должен вводить пароль повторно при выходе из системы»
- REQ-02: «При нажатии "Выйти" система запрашивает подтверждение паролем»
Проверяемые (Verifiable / Testable)
Требование можно проверить — существует конкретный способ убедиться, что оно выполнено.
Плохо: «Интерфейс должен нравиться пользователям» ← невозможно проверить объективно Хорошо: «Не менее 80% пользователей в ходе usability-теста выполняют задачу регистрации без помощи»
Приоритизированные (Prioritized)
Каждое требование имеет уровень важности. Это помогает команде сосредоточиться на главном при нехватке времени.
| Приоритет | Описание | Пример |
|---|---|---|
| Критический | Без этого продукт не работает | Авторизация пользователей |
| Высокий | Важная функция, нужна в релизе | Фильтрация товаров |
| Средний | Желательно, но терпимо | Сортировка по дате |
| Низкий | Можно отложить | Смена темы интерфейса |
Прослеживаемые (Traceable)
Можно отследить источник требования — откуда оно взялось и почему. Это помогает при изменениях понять последствия.
Пример: REQ-15 «Форма оплаты должна соответствовать стандарту PCI DSS» → источник: юридический отдел, документ Legal-2024-03.
Проверка требований перед тестированием
Перед тем как писать тест-кейсы, задай себе вопросы по каждому требованию:
| Критерий | Вопрос для проверки |
|---|---|
| Однозначность | Все ли в команде понимают это одинаково? |
| Полнота | Что происходит при ошибке? Что если поле пустое? |
| Непротиворечивость | Не конфликтует ли с другим требованием? |
| Проверяемость | Как я проверю, что это работает? |
| Приоритет | Насколько критично для бизнеса? |
| Прослеживаемость | Откуда взялось это требование? |
Распространённые ошибки при написании требований
- Расплывчатые слова: «быстро», «удобно», «надёжно», «современно» — без цифр ничего не значат
- Пассивный залог без субъекта: «должно быть обработано» — кем? системой? пользователем?
- Несколько требований в одном: «Система сохраняет данные и отправляет email, и обновляет счётчик» — это три разных требования
- Отсутствие негативных сценариев: описан только «счастливый путь», а ошибки не описаны
Что мы запомним
- Хорошее требование — однозначное, полное, непротиворечивое, проверяемое, приоритизированное и прослеживаемое
- Расплывчатые слова без цифр делают требование непроверяемым
- Требования должны описывать не только успешные, но и негативные сценарии
- Перед написанием тест-кейсов стоит проверить каждое требование по этим критериям
- Одно требование — одна мысль