Виды требований¶

1. Бизнес-требования (Business Requirements)¶

Описание:
Высокоуровневые цели и задачи бизнеса. Обосновывают, зачем вообще разрабатывается система.

Примеры:
- Снизить среднее время обработки заказа с 10 до 5 минут.
- Повысить клиентскую удовлетворенность на 15% за счет автоматизации поддержки.
- Обеспечить соответствие новому законодательству.

Критерии оценки:
- Ясность: Сформулированы простым и понятным языком.
- Ценность: Отражают реальную потребность бизнеса.
- Измеримость: По возможности содержат количественные показатели.

2. Пользовательские требования (User Requirements)¶

Описание:
Описывают, что хочет получить конечный пользователь. Часто оформляются в виде user stories или сценариев использования.

Формат user story:

Как [роль], я хочу [цель], чтобы [ценность].

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

Критерии оценки:
- Понятность: Пользователь легко может прочитать и понять требование.
- Согласование: Подтверждено представителями целевой роли.
- Обоснованность: Есть причина/ценность для пользователя.

3. Функциональные требования (Functional Requirements)¶

Описание:
Описывают, что должна делать система, какую функциональность реализовать.

Примеры:
- Система должна позволять пользователю загружать изображение в формате JPG, PNG.
- После регистрации пользователь должен получить письмо с подтверждением.
- Администратор может деактивировать учетную запись.

Критерии оценки:
- Точность: Описывает конкретное поведение системы.
- Однозначность: Интерпретируется одинаково всеми сторонами.
- Полнота: Не упущены важные детали (условия, ограничения).

4. Нефункциональные требования (Non-Functional Requirements)¶

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

Виды и примеры:

Производительность:
- Система должна обрабатывать не менее 1000 запросов в секунду.
Надежность:
- Уровень доступности не ниже 99.9% в месяц.
Безопасность:
- Пароли должны храниться в зашифрованном виде (SHA-256).
Удобство:
- Новые пользователи должны уметь работать с системой без инструкции.
Масштабируемость:
- Архитектура должна позволять горизонтальное масштабирование.
Совместимость:
- Приложение должно работать во всех популярных браузерах.

Критерии оценки:
- Измеримость: Содержит количественные показатели.
- Проверяемость: Можно протестировать/замерить.
- Реалистичность: Выполнимо в заданных условиях.

5. Требования к интерфейсу (Interface Requirements)¶

Описание:
Описывают, как система взаимодействует с другими системами, пользователями и API.

Примеры:
- Система должна отправлять данные заказов в CRM через REST API.
- Авторизация должна происходить через SSO-провайдер.
- UI должен быть адаптивным и отображаться корректно на экранах от 320px до 1920px.

Критерии оценки:
- Совместимость: Описано, с чем и как должна взаимодействовать система.
- Документированность: Есть примеры, схемы, форматы обмена (JSON, XML и т.п.).
- Проверяемость: Можно реализовать тестовый обмен данными.

6. Системные (технические) требования¶

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

Примеры:
- Приложение должно работать под Ubuntu 22.04.
- Хранение данных — PostgreSQL версии 14 и выше.
- Веб-сервер — Nginx 1.20+.

Критерии оценки:
- Четкость: Указаны конкретные версии и технологии.
- Согласованность: Соответствуют инфраструктуре заказчика.
- Достаточность: Охватывают все компоненты системы.

7. Регуляторные и правовые требования¶

Описание:
Требования, связанные с законодательством, стандартами, внутренними политиками организации.

Примеры:
- Данные клиентов из ЕС должны храниться в соответствии с GDPR.
- Используемые сертификаты должны быть выпущены УЦ, аккредитованным ФСТЭК.
- Не допускается хранение паролей в открытом виде.

Критерии оценки:
- Обязательность: Являются юридически необходимыми.
- Документируемость: Ссылаются на нормативные документы.
- Проверяемость: Возможна проверка в ходе аудита.

8. Ограничения (Constraints)¶

Описание:
Ограничения по технологии, времени, бюджету или совместимости. Это рамки, в которых нужно работать.

Примеры:
- Использовать только open-source библиотеки.
- Срок сдачи MVP — 1 месяц.
- Бюджет проекта — не более 2 млн рублей.

Критерии оценки:
- Обоснованность: Подкреплены ресурсами или политиками.
- Ясность: Не допускают двусмысленности.
- Согласованность: Приняты всеми сторонами проекта.

Полезные критерии качества требований (по IEEE)¶

Критерий	Пояснение
Полнота	Охватывает все аспекты, нужные для реализации
Однозначность	Требование трактуется одинаково всеми участниками проекта
Проверяемость	Можно протестировать и подтвердить выполнение
Реалистичность	Возможно реализовать с учетом ресурсов и ограничений
Необходимость	Требование действительно нужно для достижения бизнес-цели
Трассируемость	Можно отследить связь между бизнес-целью и реализацией

Полезные ресурсы¶

Дополнительные материалы:

BABOK Guide — стандарт по бизнес-анализу от IIBA
IEEE 830/29148 — стандарты по оформлению требований
ISO/IEC 25010 — модель качества ПО