Нефункциональные требования

Функциональные требования отвечают на вопрос «что система должна уметь». Нефункциональные требования отвечают на вопрос «с каким качеством». Кнопка «Отменить заказ» относится к первым. Время, за которое открывается страница заказа, и защита от чужого доступа относятся ко вторым.

Нефункциональное требование - требование к качеству работы системы, а не к её функциям. Метрика - то, что мы измеряем, чтобы судить об этом качестве, например время ответа в секундах.

Кейс: «сайт должен быстро работать»

Перед распродажей владелец магазина «Узелок» просит: «Сайт должен быстро работать». Разработчик согласен и делает как умеет. В день распродажи страница заказа открывается долго, покупатели жалуются, и каждый участник уверен, что был прав. Владелец ожидал секунды, разработчик считал приемлемым ожидание в несколько секунд, а тестировщик не знал, с чем сравнивать.

Проблема не в скорости, а в формулировке: слово «быстро» у каждого свой смысл. Числа в этом кейсе условные: мы взяли их для иллюстрации, а не из реального магазина.

Основные группы

Нефункциональные требования удобно разбирать по группам. Качество программного продукта принято описывать набором характеристик; среди них производительность, надёжность, безопасность, взаимодействие с пользователем (раньше называлось удобством использования) и другие. Для работы чаще всего хватает шести групп, которые перекликаются с этими характеристиками.

• Производительность: как быстро система отвечает и обрабатывает данные.
• Надёжность и доступность: как долго система работает без сбоев и какую долю времени доступна.
• Безопасность: кто какие данные и действия видит.
• Масштабируемость: сколько пользователей и данных система выдержит и как будет расти.
• Удобство: сколько шагов до цели и насколько понятен интерфейс.
• Аудит: какие действия записываются в журнал и как долго он хранится.

Нагрузку и масштабирование подробнее разбирает статья 06-09, отказоустойчивость статья 06-11, безопасность статья 06-12.

Как сделать требование измеримым

Измеримое требование отвечает на четыре вопроса: что мы измеряем, какое значение считаем достаточным, при каких условиях и как будем проверять. Если хотя бы на один вопрос нет ответа, проверка превращается в спор.

Для кейса запись может выглядеть так (числа условные): «Страница заказа открывается не дольше чем за 2 секунды в 95% случаев при 100 одновременно работающих покупателях. Проверка: замер на тестовом стенде перед релизом».

Фраза «в 95% случаев» нужна, потому что время ответа меняется от запроса к запросу. Одно среднее число скрывает медленные случаи, а запись «95% запросов укладываются в границу» показывает, как себя чувствует почти каждый покупатель. Такое значение называют 95-м перцентилем.

Как выяснять значения

Цифру не придумывают сами, её выясняют. Полезные вопросы к владельцу и команде:

• Сколько пользователей и запросов ожидается в обычный день и в пик?
• Что произойдёт, если страница откроется за 5 секунд: покупатель уйдёт, пожалуется, подождёт?
• Сколько можно терять данных и времени при сбое?
• Есть ли требования закона или договора к хранению, доступу и журналу действий?

Требования к персональным данным вынесены в отдельную статью 02-14, а пример с формулой измеримой записи есть и в статье 02-06 о метриках успеха.

Где нефункциональные требования ломаются

Чаще всего ломается одно из трёх. Требование не записано: все надеются на «разумное» поведение. Требование записано без числа: «быстро», «надёжно», «безопасно». Требование записано, но не проверяется: нет стенда, нет замера, нет ответственного.

Ещё одна частая беда: требования противоречат друг другу. Строгая защита замедляет вход, а шифрование данных увеличивает время ответа. Такие конфликты лучше видеть заранее, поэтому в статье 02-18 мы разберём поиск противоречий.

Где это встречается в работе

• В описании функции рядом с функциональной частью: время ответа, доступность, права доступа.
• В обсуждении релиза: нагрузочное тестирование проверяет требования к производительности, о чём пойдёт речь в статье 02-24.
• В договоре или соглашении об уровне сервиса, где доступность и время восстановления записаны числами.
• В разборе инцидента: часто выясняется, что требование «просто не обсуждали».

Итог

• Нефункциональные требования описывают качество работы системы.
• Группы: производительность, надёжность, безопасность, масштабируемость, удобство, аудит.
• Измеримое требование включает метрику, значение, условия и способ проверки.
• Значения выясняют у владельца и команды, а не придумывают.
• Конфликты между требованиями видны заранее, если смотреть на них вместе.

Что дальше

• 06-09 Нагрузка и масштабирование: как оценить нагрузку и что даёт масштабирование.
• 02-14 Персональные данные: какие требования возникают при работе с данными людей.
• 02-24 Виды тестирования: как проверяют нефункциональные требования.