Инженерия требований

Инженерия требований — это структурированный подход к сбору, анализу, документированию, валидации и управлению требованиями на протяжении всего проекта. Этот процесс включает в себя определение функциональных, нефункциональных и ограничивающих требований, каждый из которых играет важную роль в успешной реализации проекта. Функциональные требования определяют, что система должна делать, нефункциональные — её качество и ограничивающие — неподвижные правила, которые система должна соблюдать. Важность нефункциональных требований заключается в том, что они определяют, сможет ли система выжить и успешно функционировать в реальных условиях эксплуатации.

Как это работает

Требование должно быть однозначным (иметь только одну валидную интерпретацию), тестируемым (можно проверить его выполнение), прослеживаемым (связано от источника до теста), приоритизированным (MoSCoW или эквивалент), и уникально идентифицированным (REQ-001, ...). Каждое функциональное требование должно описывать актёра и поведение системы ('Система должна позволять аутентифицированному пользователю...'). Нефункциональные требования, напротив, описывают качество системы и измеримые цели ('Page load p95 < 500ms'). Ограничительные требования указывают на то, что не может меняться и почему.

Когда применять

Инженерия требований особенно важна в начале проекта, когда необходимо выявить и документировать все ключевые требования. Однако этот процесс не завершается на начальной стадии — требования эволюционируют и изменяются по мере продвижения проекта и новых открытий. Для продуктовых agile-команд, работающих в условиях быстрого изменения, полезно использовать легкие требования, такие как user stories и критерии приёма. Для регулируемых, контрактных или критически важных систем безопасности рекомендуются тяжёлые требования, включающие формальные REQ-IDs, traceability-матрицы и процессы согласования.

Типичные ошибки

(1) Wishful requirements — 'система должна быть удобной' не поддается тестированию. Такие требования должны быть переформулированы, чтобы они были конкретными и измеримыми, например, 'задачи X/Y/Z выполняются под N секунд для 80% пользователей в usability-тестировании'. (2) Заморозка требований — фиксация требований до завершения discovery процесса; это может привести к необходимости позднего рерайта по мере выявления реальных требований. (3) NFR как afterthought — добавление 'и должно быть быстро' к спецификации фичи не делает производительность требованием; нефункциональные требования должны рассматриваться как first-class требования с явными целями.

Связанные понятия

• Functional Requirements
• Non-Functional Requirements
• Requirements Traceability