Синтаксис требований
Контекст задачи
Четкая и точная формулировка требований важна для успеха проекта.
Формулировка
Из хаотичного, неструктурированного описания функции климатической станции (как обычно говорят реальные клиенты) составить четкие системные требования и поведенческие сценарии проверки для вашей программной системы.
Ожидаемый результат
- формализованные требования
- сценарий проверки
Инструментарий
Язык Gherkin используется на стыке человеческого языка и понятного для автотестов кода (Cucumber, SpecFlow) для валидации критериев приемки (Acceptance Criteria).
🧩 Шаблон:
- Дано (Given): Начальное состояние системы, контекст (где мы находимся, какие настройки активны).
- Когда (When): Действие пользователя, изменение состояния датчика или внешнее событие (триггер).
- То (Then): Ожидаемый результат (как реагирует система, что меняется в UI или логах).
- И / Но (And / But): Дополнительные условия или проверки, если одного предложения мало.
📝 Пример:
Дано (Given): Сервер тактов запущен, датчик вентиляции подписан и находится в режиме ожидания.Когда (When): На сервере происходит такт синхронизации №5.То (Then): Система вентиляции активирует мотор и переводится в режим «Слабая скорость».И (And): В логгер пишется информационное сообщение уровня INFO.
📝 Критерии оценки
- составлено не менее 3 требований
- Каждое требование сформулировано в формате «Система должна [действие]» или «Пользователь может [действие]». Требования однозначны и проверяемы
- Для каждого требования составлен сценарий проверки