Нефункциональные требования к системе превращают слова «быстро», «надёжно» и «много данных» в проверяемые условия. Примеры должны содержать операцию, нагрузку, допустимый результат и способ измерения. Без этого заказчик и подрядчик могут честно считать одну систему одновременно быстрой и медленной.
Ниже — набор карточек для внутреннего сервиса заявок. Он помогает согласовать скорость, доступность, рост данных и эксплуатационные ограничения до оценки разработки. Все числа условные: их выбирают по рабочему процессу, возможностям инфраструктуры и последствиям отклонения.
Начните с операции и её последствий
Не задавайте одинаковую скорость всему сервису. Поиск заявки на звонке клиента, формирование месячного отчёта и ночная загрузка справочника имеют разные допустимые ожидания. Пользовательский результат определяет требование.
Запишите, что считается началом и концом операции. Для поиска это может быть нажатие кнопки и появление пригодного списка в браузере. Для фонового отчёта — принятие задания и готовность файла. Время ответа одного серверного запроса не всегда описывает ожидание сотрудника.
Уточните рабочее место и сеть. Если проверка проводится рядом с сервером, она не подтверждает опыт филиала с иным каналом. Не обязательно воспроизводить каждую возможную сеть, но условия испытаний должны совпадать с областью обещанного результата.
Опишите нагрузку без двусмысленности
«Сто пользователей» может означать зарегистрированные учётные записи, одновременно открытые окна или активные действия каждую секунду. Для оценки это разные задачи. Назовите число активных участников и характер их работы.
В условном сервисе зарегистрированы 200 сотрудников, в напряжённый период одновременно работают 25, каждый выполняет поиск примерно раз в 30 секунд. Средний поток поиска — около 25 / 30 = 0,83 операции в секунду. Это оценка по допущению, а не описание пикового распределения.
Если все 25 сотрудников нажмут поиск одновременно после утреннего входа, возникнет иной профиль. Испытание должно включать согласованный всплеск, а также обычный смешанный набор: чтение, сохранение, поиск и фоновую загрузку. Равномерный поток одной операции не доказывает устойчивость всего процесса.
Заполненный пример требования к скорости
- Операция: поиск открытых заявок по объекту и ответственному.
- Начало: пользователь отправил заполненные условия.
- Конец: список пригоден для просмотра в браузере.
- Данные: 300 тысяч заявок с представительными связями и историей.
- Нагрузка: 25 активных сотрудников по согласованному сценарию.
- Критерий: не менее 95% завершённых поисков укладываются в две секунды.
- Дополнительно: ошибки и незавершённые операции учитываются отдельно.
- Проверка: согласованный прогон с фиксированной версией и условиями.
- Ответственный: технический специалист измеряет, владелец процесса подтверждает достаточность.
Порог 95% не означает, что медленные пять процентов не важны. Установите отдельное ограничение для чрезмерно долгих ожиданий и допустимой доли ошибок. Иначе успешные быстрые ответы могут скрыть зависшие операции.
Правильно определите доступность
Уточните, доступность чего измеряется: страницы входа, создания заявки или полного маршрута с внешним подтверждением. Сервер может отвечать, пока нужное действие не выполняется. Поэтому технический индикатор и бизнес-доступность рассматривают отдельно.
Задайте период обслуживания, правила плановых работ и начало недоступности. Например, условное окно составляет 22 рабочих дня по восемь часов, всего 176 часов. При целевой доступности 99,5% допустимая недоступность в этом окне равна 0,88 часа, или 52,8 минуты.
Этот расчёт не является рекомендацией уровня сервиса. Он показывает, зачем договориться о знаменателе. Доступность за календарный месяц и за рабочие часы нельзя сравнивать без пересчёта. Исключения также не должны появляться задним числом после сбоя.
Разделите доступность и восстановление
Хороший показатель доступности не подтверждает, что система восстановится после потери основной среды. Для восстановления отдельно задают допустимую потерю данных, срок возвращения к рабочей операции и состав проверок.
Например, наличие вчерашней копии не отвечает, можно ли восстановить сегодняшние заказы. Укажите, какое состояние требуется вернуть и как будут учтены новые операции, если они создавались во время сбоя в другом порядке.
Не сводите эти требования к одному слову «резервирование». Дублирование компонентов, копирование данных и проверка восстановления решают разные задачи. Нужный набор зависит от процесса и согласуется с технической командой.
Задайте объём и рост данных
Считайте рабочие сущности, историю и вложения раздельно. Триста тысяч карточек без файлов не похожи по нагрузке на такой же набор с фотографиями и многолетними журналами. Для испытания нужны характерные размеры и связи.
Укажите горизонт: текущая база, ожидаемый объём через год и сценарий пересмотра. Если прогноз ненадёжен, определите диапазон и наблюдаемый признак, при котором потребуется расширение. Не выдавайте одну точную цифру за доказанный рост бизнеса.
Проверьте не только запись, но и поиск, отчёты, удаление по утверждённому порядку и восстановление. Ограничение объёма должно сопровождаться понятным поведением: предупреждением, отказом или предусмотренным расширением, а не молчаливой потерей данных.
Соберите реестр требований карточками
Для каждой строки будущей таблицы используйте одинаковые поля: идентификатор, операция, условия, данные, нагрузка, порог, метод проверки, ответственный и исключения. Такой формат можно вести списком, а затем перенести в рабочий реестр.
Добавьте основание порога. «Две секунды нужны, чтобы оператор не прерывал разговор» — понятная бизнес-причина. «Так было в чужом проекте» не объясняет необходимость и может увеличить стоимость без пользы.
Отметьте статус подтверждения: требование принято, метод испытания согласован, результат измерен или проверка пока невозможна. Утверждённая цифра не становится автоматически достигнутой характеристикой программы.
Не дайте средним значениям скрыть проблему
Среднее время может выглядеть хорошим при нескольких очень долгих операциях. Поэтому показывайте распределение результатов, медленные случаи и ошибки. Условие «95% не дольше двух секунд» должно сопровождаться числом наблюдений и способом подсчёта.
Опишите прогрев, длительность испытания и изменения среды. Сравнение холодного запуска одной версии с подготовленной средой другой может вводить в заблуждение. Повторяемость важнее красивого единственного результата.
Нефункциональные требования включите в критерии приёмки. При сравнении оценок убедитесь, что команды учитывают одинаковую нагрузку: этому посвящена статья о предложениях подрядчиков.
Попросите заказчика и техническую команду независимо пересказать одну карточку. Они должны одинаково назвать данные, нагрузку, начало отсчёта и допустимое отклонение. Различие в ответах показывает, что испытание ещё не согласовано, даже если обе стороны уже подписали общую фразу о высокой производительности.
Следующий шаг
Выберите три операции: частую, критичную и ресурсоёмкую. Заполните карточки с текущими данными и явно обозначенными допущениями. С ExtentLab можно обсудить реалистичные требования к внутренней системе и состав испытаний, по которым заказчик сможет проверить результат разработки.