Как написать QRD: руководство по требованиям к качеству

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

QRD отвечает на вопрос: как мы узнаем, что этот продукт достаточно хорош для релиза?

Key insight

QRD — это не тест-план. Тест-план описывает, как тестировать систему. QRD описывает, что «качество» означает для конкретного проекта — бенчмарки, стандарты и критерии приёмки, которые тестирование должно подтвердить.

Кто пишет и для кого

Владелец QRD — обычно QA-лид, менеджер по качеству, тест-архитектор или технический проектный менеджер.

Читатель	Что ищет в документе
QA / тест-инженеры	Критерии приёмки, бенчмарки качества, цели по покрытию тестами
Разработчики	Стандарты качества для кода, definition of done
Продакт-менеджеры	Критерии готовности релиза, компромиссы по качеству
Проектные менеджеры	Вехи качества, пороги рисков, критерии go/no-go
Комплаенс / Legal	Регуляторные стандарты качества, требования аудита

Когда нужен QRD — и когда не нужен

QRD нужен, когда:

Проект должен соответствовать внешним стандартам качества (ISO 9001, IEC 62304 для медицинских устройств, DO-178C для авиационного ПО)
Несколько команд или подрядчиков вносят вклад в продукт и нуждаются в общих бенчмарках качества
У организации есть формальный процесс выпуска с quality gates
Предыдущие проекты имели проблемы с качеством из-за неопределённых критериев приёмки

QRD не нужен, когда:

У команды есть устоявшийся definition of done и культура качества
Требования к качеству уже покрыты в секции NFR документа SRD
Проект — прототип или MVP, где качество явно обменивается на скорость

Что содержит QRD

Основные секции

QRD обычно включает пять секций:

Введение — назначение, скоуп, связь с другими документами (SRD, PRD, тест-план), определения терминов качества.

Атрибуты качества — конкретные характеристики качества продукта с измеримыми целями.

Атрибут	Определение	Цель	Метод измерения
Надёжность	Аптайм и уровень ошибок	99.95% аптайм, менее 0.1% ошибок	Мониторинг продакшена, ежемесячно
Производительность	Время отклика под нагрузкой	P95 < 300мс при 5К пользователей	Нагрузочное тестирование
Безопасность	Устойчивость к известным уязвимостям	Ноль критических/высоких CVE	SAST + DAST, пентест
Юзабилити	Выполнение задач целевыми пользователями	90% завершения задач	Модерируемый юзабилити-тест, N=10
Поддерживаемость	Сложность кода и покрытие тестами	Цикломатическая сложность менее 15, покрытие более 80%	Анализ SonarQube
Доступность	Соответствие стандартам доступности	WCAG 2.2 AA	Автоматический + ручной аудит

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

Блокирующие критерии — релиз невозможен при провале:

ID	Критерий	Порог	Блокирующий?
QA-001	Все P0-требования проходят автотесты	100% pass	Да
QA-002	Нет открытых критических/высоких багов	0 открытых P0/P1	Да
QA-003	Нагрузочные тесты проходят на целевой нагрузке	P95 < 300мс при 5К	Да
QA-004	Сканирование безопасности чистое	0 критических CVE	Да

Рекомендательные критерии — отслеживаются, но не блокируют:

ID	Критерий	Цель
QA-006	Покрытие кода	>80%
QA-007	Документация	Все фичи задокументированы

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

QRD и другие документы требований

QRD работает параллельно с SRD:

MRD → BRD → PRD → FRD → SRD
                           ↑
                          TRD (инфраструктура)
                          QRD (стандарты качества)

SRD определяет нефункциональные цели. QRD определяет, как эти цели верифицируются, каковы пороги прохождения/провала и что происходит при несоответствии.

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

1. Определение качества без измерений. «Продукт должен быть высокого качества» бессмысленно. Качество должно быть разложено на конкретные, измеримые атрибуты с числовыми целями.

2. Всё — блокирующий критерий. Если каждый критерий блокирует релиз, ничего не выпускается. «Блокирующий» статус — для критериев, влияющих на пользователей, целостность данных или безопасность.

3. QRD написан в конце проекта. Требования к качеству должны быть определены до начала разработки.

4. Нет связи с тестированием. QRD без стратегии тестирования — это список пожеланий.

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

Ресурсы

Шаблон QRD — готовый к использованию
Генератор QRD — создайте QRD с помощью AI
SRD — полное руководство — спецификация требований к ПО
FRD — полное руководство — спецификация поведения
Навигатор документов — найдите нужный тип документа