Требования к ПО классифицируют по разным критериям. Разберу основные виды подробно.
1. По уровням (иерархии)
Бизнес‑требования (business requirements):
- описывают высокоуровневые цели организации или заказчика;
- отвечают на вопросы «Зачем?» и «Почему?»;
- обычно формулируются теми, кто финансирует проект;
- фиксируются в документах о видении (vision) и границах проекта (scope).
Примеры:
- «Система должна сократить время обработки заказов на 30 %».
- «Необходимо вести учёт взаиморасчётов с контрагентами в разрезе договоров».
Пользовательские требования (user requirements):
- определяют задачи и цели, которые пользователи должны решать с помощью системы;
- описывают, что пользователь должен иметь возможность делать;
- могут быть представлены в виде:
- пользовательских историй (user stories);
- сценариев использования (use cases);
- сценариев взаимодействия (scenarios).
Пример: «Я как менеджер хочу видеть актуальный остаток товара на складе, чтобы оперативно отвечать на запросы клиентов».
Функциональные требования (functional requirements):
- задают конкретное поведение системы в определённых условиях;
- формулируются с использованием слов «должен», «должна»;
- описывают функции, которые система обязана выполнять.
Примеры:
- «Система должна автоматически отправлять уведомление клиенту после подтверждения заказа».
- «Пользователь должен иметь возможность фильтровать товары по цене и категории».
- «Система должна сохранять историю изменений документа».
2. По характеру (содержанию)
Нефункциональные требования (non‑functional requirements):
- описывают характеристики и ограничения системы, а не её функции;
- задают критерии качества работы ПО;
- часто требуют количественных метрик.
Ключевые категории нефункциональных требований:
- Производительность: время отклика, пропускная способность, использование ресурсов.
Пример: «95 % транзакций должны выполняться не более чем за 3 секунды при нагрузке до 1 000 запросов в минуту». - Надёжность: доступность, устойчивость к сбоям, время восстановления.
Пример: «Система должна иметь доступность не менее 99,9 % (допускается не более 8,76 часов простоя в год)». - Безопасность: аутентификация, авторизация, шифрование данных.
Пример: «Все пароли должны храниться в зашифрованном виде с использованием алгоритма bcrypt». - Масштабируемость: способность системы расти с увеличением нагрузки.
Пример: «Система должна поддерживать линейное увеличение производительности при добавлении вычислительных ресурсов до 20 серверных узлов». - Удобство использования (юзабилити): интуитивность интерфейса, доступность для разных групп пользователей.
Пример: «Новый пользователь должен выполнить типовую задачу за не более чем 5 кликов без обучения». - Поддерживаемость: модульность, тестируемость, простота внесения изменений.
- Совместимость: взаимодействие с другими системами, соответствие стандартам.
Системные требования и ограничения:
- определяют условия, которым должна соответствовать система;
- включают требования к аппаратному и программному окружению.
Примеры:
- «Система должна работать на серверах с ОС Linux Ubuntu 22.04».
- «Требуется поддержка браузеров Chrome и Firefox последних версий».
Бизнес‑правила (business rules):
- корпоративные политики, законы, отраслевые стандарты;
- не являются прямыми требованиями к ПО, но влияют на его функционал.
Примеры:
- «При отгрузке заказа менеджер должен запросить у бухгалтера товарно‑транспортную накладную».
- «Если оплата по счёту не поступила в течение 15 дней, заказ считается отменённым».
Ограничения (constraints):
- накладывают рамки на выбор решений при разработке;
- могут касаться технологий, сроков, бюджета и т. д.
Пример: «Разработка должна использовать фреймворк React.js версии не ниже 18.0».
Требования к интерфейсам (interface requirements):
- описывают взаимодействие между ПО и:
- пользователями (UI/UX);
- другими системами (API);
- оборудованием (драйверы, протоколы).
Пример: «API метода GET /api/users должен возвращать JSON с полями id, name, email».
Переходные требования (transition requirements):
- нужны для плавного перехода от старой системы к новой;
- включают задачи по миграции данных, обучению пользователей и т. п.
Пример: «Перед запуском новой системы необходимо перенести все данные о клиентах из старой CRM за последние 3 года».
Краткий итог:
- Функциональные требования отвечают на вопрос «Что система должна делать?».
- Нефункциональные — «Как она должна это делать?» (характеристики качества).
- Бизнес‑требования задают стратегические цели.
- Пользовательские описывают задачи конечных пользователей.
- Ограничения и правила формируют рамки разработки.
Грамотное сочетание всех видов требований позволяет создать ПО, которое не только выполняет нужные функции, но и соответствует ожиданиям пользователей по удобству, надёжности и безопасности.