⚙️ Правила формулировки функциональных требований

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

✅ Правило 1: Используйте глагол действия Функциональное требование должно содержать активный глагол, описывающий конкретное действие или функцию. 👉 Именно глагол и есть та функция, которую нужно реализовать. Пример (приложение для заметок): исправлять опечатки; синхронизировать записи; сохранять изменения.

✅ Правило 2: Будьте конкретными Избегайте размытых формулировок. Уточняйте, что именно должна делать система. Можно использовать CRUD-модель: Create (создание) Read (чтение) Update (изменение) Delete (удаление) Пример: ❌ «Пользователь должен уметь работать с заметкой». ✅ «Пользователь должен иметь возможность: создать заметку, просмотреть заметку, редактировать заметку, удалить заметку».

✅ Правило 3: Пользуйтесь единой терминологией Выберите один термин и используйте его везде. ❌ лицензия / сертификат / платный пакет / тариф. ✅ лицензия (и только этот термин). Документация станет «сухой», но зато максимально понятной и без путаницы.

✅ Правило 4: Сокращайте Хорошее требование — короткое и ясное. Несколько индикаторов, что его нужно разделить: «Украшения» — причастные обороты, метафоры, жаргон. Требования ≠ литература. Союзы «и/или» — часто скрывают несколько требований. ❌ «Система должна отправлять уведомление и сохранять событие в журнал». ✅ Требование 1: «Система должна отправлять уведомление». ✅ Требование 2: «Система должна сохранять событие в журнал». Фразы «пока не», «кроме» — признак того, что внутри зашито несколько требований. Пример: ❌ «Система должна блокировать доступ, пока не истечёт срок лицензии». ✅ «Система должна блокировать доступ при недействительной лицензии. При истечении срока лицензии система должна уведомить пользователя и завершить сессию».

✅ Правило 5: Указывайте триггер Если требование зависит от условий — пропишите их явно. ❌ «Система должна формировать отчёт о продажах». ✅ «В последний день каждого месяца система должна формировать отчёт о продажах за прошедшие 30 дней».

✅ Правило 6: Избегайте технических деталей Требование должно быть написано на языке пользователя, а не разработчика. ❌ «Система должна сохранять данные в MongoDB». ✅ «Система должна сохранять заметки с возможностью масштабирования и высокой скоростью доступа». Разработчики сами выберут подходящую реализацию.

✅ Правило 7: Исключайте негативные формулировки Формулируйте требования в позитивном ключе. Отрицания, особенно двойные, путают. ❌ «Система не должна терять данные при отключении». ✅ «Система должна сохранять данные при отключении питания».

📌 Итог Функциональные требования должны быть: ясными; конкретными; однозначными; написанными на языке пользователя.

💡 Чем чётче требования — тем меньше вопросов у разработчиков и тестировщиков, и тем быстрее продукт появится у пользователей.