Функциональные требования отвечают на вопрос "Что должна делать система?", а нефункциональные — "Как она должна это делать?". Они определяют качество работы системы, её ограничения и условия, при которых она будет эффективной. Без чётко прописанных нефункциональных требований даже идеально работающая функциональность может оказаться бесполезной — если, например, система будет слишком медленной, ненадёжной или небезопасной.
Что такое нефункциональные требования и зачем они нужны?
Нефункциональные требования дополняют функциональные, задавая критерии качества и ограничения для системы. Они отвечают не за возможности продукта, а за то, как эти возможности реализованы. Например, если функциональное требование гласит: "Система должна авторизовывать пользователей по логину и паролю", то нефункциональное может уточнять: "Время обработки запроса на авторизацию не должно превышать 2 секунды".
Эти требования делятся на три основных класса:
- Атрибуты качества — производительность, доступность, безопасность, удобство использования, совместимость.
- Требования к внешним интерфейсам — как система взаимодействует с пользователями и другими системами.
- Ограничения проектирования и реализации — технические, архитектурные и бизнес-ограничения, влияющие на разработку.
Кроме того, их можно разделить на две группы по времени их влияния:
- Design time (время проектирования) — требования, определяющие архитектуру и дизайн системы (например, масштабируемость, лёгкость интеграции).
- Runtime (время выполнения) — требования к работе системы в процессе эксплуатации (скорость отклика, устойчивость к нагрузкам, безопасность).
Как выявлять нефункциональные требования: 4 подхода
Поскольку нефункциональные требования не всегда очевидны, аналитики используют разные методы их выявления. Рассмотрим четыре ключевых подхода.
1. Использование шаблонов и стандартов
Если в компании уже есть устоявшиеся стандарты (например, PCI DSS для безопасности или OWASP для веб-приложений), можно опираться на них. Например:
- "Система должна обрабатывать не менее 1000 запросов в минуту".
- "Все пароли должны храниться в зашифрованном виде".
Этот подход экономит время и снижает риск упустить важные требования.
2. Интервью и анализ документации
Часто стейкхолдеры не могут сразу сформулировать нефункциональные требования, но могут указать на аналогичные решения. Например:
- "Сделайте так же, как в нашей старой CRM".
Но здесь важно не просто копировать, а разобраться, почему реализовано именно так, и адаптировать это под новый контекст.
3. Приоритизация
Нефункциональные требования могут конфликтовать. Например:
- "Страница должна загружаться мгновенно" (производительность).
- "Данные должны быть максимально защищены" (безопасность).
Усиление безопасности может замедлить работу системы, поэтому нужно определить, что важнее на текущем этапе.
4. Использование методологий
В Agile и BABOK есть техники для работы с нефункциональными требованиями:
- Моделирование процессов помогает выявить скрытые ограничения.
- Итеративная разработка позволяет постепенно уточнять требования.
- Совместные обсуждения с командой разработки помогают избежать нереалистичных ожиданий.
Этапы работы с нефункциональными требованиями
Чтобы избежать проблем на поздних этапах разработки, нефункциональные требования нужно прорабатывать заранее. Вот ключевые шаги:
1. Определение целей и ожиданий
Какие бизнес-задачи решает система? Например, если это банковское приложение, критически важны безопасность и надёжность.
2. Сбор и анализ требований
Здесь важно учитывать:
- Локализацию (язык, законодательство, культурные особенности).
- Масштабируемость (как система будет расти).
- Соглашения об уровне обслуживания (SLA).
3. Выделение обязательных требований
Не все требования одинаково важны. Сначала реализуем те, без которых система нежизнеспособна (например, соответствие законам о защите данных).
4. Проверка на соответствие бизнес-целям
Требование без бизнес-ценности — лишняя трата ресурсов. Например, "Интерфейс должен быть в тёмной теме" — это желание, а не требование, если не доказано, что это влияет на конверсию.
5. Документирование
Требования должны быть:
- Конкретными (не "быстрая загрузка", а "загрузка за ≤2 сек").
- Измеримыми (чтобы можно было проверить).
- Актуальными (регулярно обновляемыми).
6. Валидация
После разработки тестировщики проверяют, соблюдены ли требования. Например:
- Выдерживает ли система нагрузку в 1000 пользователей?
- Соответствует ли скорость отклика SLA?
Как оценивать качество: SLA, SLO, SLI
Для контроля качества используют три метрики:
- SLA (Service Level Agreement) — договорённость с заказчиком ("время ответа ≤1 сек").
- SLO (Service Level Objective) — цель команды ("обеспечим ответ за 1 сек").
- SLI (Service Level Indicator) — реальный результат ("фактическое время — 0,8 сек").
Эти метрики помогают объективно оценить, насколько система соответствует ожиданиям.
Вывод
Нефункциональные требования так же важны, как и функциональные. Они определяют, будет ли система быстрой, безопасной, удобной и надёжной. Чтобы избежать проблем на поздних этапах, их нужно выявлять и документировать как можно раньше, используя интервью, стандарты, приоритизацию и методологии. А контроль качества с помощью SLA, SLO и SLI поможет убедиться, что итоговый продукт соответствует всем критериям.