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

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

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

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

Из чего состоит проверяемое требование

У любого проверяемого нефункционального требования четыре части. Если хотя бы одной нет, на приёмке спорить будет не о системе, а о смысле слов.

Свойство — что именно меряем: время отклика, долю успешных запросов, время восстановления.
Величина — граница, за которой требование нарушено.
Условия — объём данных, число одновременных пользователей, время суток, тип операции.
Способ измерения — где и чем меряем, кто и когда проверяет.

Было
  Поиск по каталогу должен работать быстро.

Стало
  NFR-03  Время отклика поиска по каталогу
  величина     95 % запросов — не дольше 1 с, 99 % — не дольше 3 с
  условия      каталог 500 тыс. позиций, 200 одновременных пользователей
  измерение    нагрузочный тест на стенде перед каждым релизом;
               на проде — по журналу сервера за сутки

Процентиль, а не среднее

Среднее время отклика прячет хвост. Если девять запросов из десяти отвечают за 0,2 секунды, а десятый — за восемь, среднее будет около секунды и выглядит прилично. Пользователь, который попал в десятый, видит восемь секунд. Поэтому время задают процентилем: «95 % запросов не дольше…», а для важных операций — ещё и 99 %.

О чём спросить, даже если заказчик молчит

Заказчик редко называет нефункциональные требования сам. Их приходится выспрашивать, и полезно иметь перечень. Готовый перечень характеристик качества даёт стандарт ISO/IEC 25010; на практике чаще всего нужны вот эти:

Свойство	Вопрос заказчику	Что обычно не знают
Производительность	Сколько можно ждать ответа в самой частой операции?	Разницу между «обычно» и «в пик»
Объём и рост	Сколько записей сейчас и сколько будет через год?	Рост, особенно после подключения нового канала
Доступность	Сколько простоя в месяц допустимо и когда можно проводить работы?	Цену часа простоя
Восстановление	Сколько данных можно потерять при сбое и за сколько надо подняться?	Что эти два числа разные и задаются отдельно
Доступ и журнал	Кто что видит, и нужно ли знать, кто что сделал?	Что журнал действий нельзя добавить задним числом
Хранение	Сколько хранить данные и что с ними потом?	Требования закона и договоров
Совместимость	На каких устройствах и в каких браузерах должно работать?	Долю пользователей на старых версиях

Откуда взять число, если его никто не знает

Ответ «не знаю, но чтобы быстро» — нормальный. Число всё равно можно получить, и не из головы:

Из текущего состояния. Замерить, как система работает сейчас, и договориться, что новая версия не хуже.
Из денег. Если час простоя стоит сумму, которую бизнес может назвать, допустимый простой считается, а не угадывается.
Из аналогов. Как ведут себя похожие продукты, с которыми пользователь сравнивает.

Число, взятое так, остаётся допущением, и это нужно записать рядом: «принято по замеру текущей версии, пересмотреть после первого месяца». Такое число лучше пустого места — с ним есть о чём спорить.

Требование без способа проверки — пожелание. Если нельзя назвать, кто, где и чем будет мерить, требование не войдёт в критерии приёмки и не будет проверено. Нагрузочный тест, о котором вспомнили за день до релиза, не успевают провести.

Кто проверяет и когда

Функциональное требование проверяется на готовой функции. Нефункциональное часто — только на собранной системе с реалистичными данными, а такой стенд надо подготовить заранее. Поэтому у каждого нефункционального требования в постановке полезно указать не только способ, но и момент проверки: на стенде перед релизом, на проде по журналам, раз в квартал учением по восстановлению.

Признак, что нефункциональных требований нет: о производительности впервые говорят в инциденте.

Проверка за десять минут

Найдите в текущей постановке слова «быстро», «удобно», «надёжно», «безопасно», «при необходимости», «в разумные сроки». Каждое из них — недописанное требование. Для каждого попробуйте назвать четыре части: свойство, величину, условия и способ измерения.

Готовая форма и три примера — шаблон нефункционального требования.

Что дальше

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