Требования к программному обеспечению (ПО) — это совокупность запросов или утверждений относительно атрибутов, свойств или качеств программной системы, которую предстоит реализовать. Они формируются в процессе анализа и синтеза задания на разработку или модернизацию ПО.
Требования могут быть представлены:
- в виде текстовых утверждений;
- с помощью графических моделей (диаграмм, схем и т. д.).
Этапы разработки требований
Процесс формирования требований включает несколько ключевых этапов:
- Выявление требований — сбор и понимание потребностей заинтересованных сторон (заказчиков, пользователей и др.).
- Анализ — проверка целостности, непротиворечивости и полноты требований.
- Спецификация — документирование требований, синтез текстовых и графических моделей.
- Проверка правильности — верификация требований на соответствие изначальным нуждам и целям проекта.
Виды требований
По уровням:
- Бизнес‑требования — определяют назначение ПО, описывают его роль в достижении бизнес‑целей. Фиксируются в документе о видении проекта (vision) и его границах (scope).
Пример: «Система должна сократить время обработки заказов на 30 %». - Пользовательские требования — описывают задачи, которые пользователи должны решать с помощью ПО, и сценарии их выполнения. Могут быть оформлены как:
- сценарии использования (use case);
- пользовательские истории (user stories);
- сценарии взаимодействия (scenario).
Пример: «Пользователь должен иметь возможность сформировать заказ в один клик».
- Функциональные требования — определяют конкретные функции и поведение системы.
Пример: «Система должна автоматически отправлять уведомление клиенту после подтверждения заказа».
По характеру:
- Функциональные — описывают, что система должна делать (её поведение).
- Нефункциональные — задают характеристики и ограничения системы (качество, производительность, безопасность и т. п.). К ним относятся:
- бизнес‑правила (корпоративные политики, законы, стандарты);
- системные требования и ограничения (оборудование, ПО, интерфейсы, документация, дизайн, безопасность, надёжность, производительность, условия эксплуатации и др.).
Примеры:- «Время отклика системы не должно превышать 2 секунд»;
- «Данные должны передаваться по защищённому протоколу HTTPS»;
- «Интерфейс должен быть адаптирован для пользователей с нарушениями зрения».
Источники требований
Требования формируются на основе:
- законодательства (федерального, муниципального, отраслевого);
- внутренних регламентов организации (уставов, приказов, положений);
- текущей организации деятельности (бизнес‑процессов, моделей деятельности);
- ожиданий пользователей и заказчиков;
- анализа существующих систем (журналов использования, статистики);
- изучения конкурирующих продуктов.
Качество требований
Чтобы требования были эффективными, они должны соответствовать ряду критериев:
- Атомарность — требование нельзя разбить на более мелкие без потери смысла.
- Недвусмысленность — чёткая формулировка без жаргона и неоднозначных фраз; допускает одну интерпретацию.
- Выполнимость — возможность реализовать требование в рамках проекта.
- Проверяемость — возможность подтвердить выполнение требования (тестом, демонстрацией, осмотром или анализом).
- Актуальность — соответствие текущим нуждам (не устарело).
- Отслеживаемость — связь с бизнес‑целями и документирование.
- Последовательность — отсутствие противоречий с другими требованиями.
- Обязательность — значимость для решения задачи (без него система будет неполноценной).
Роль требований в жизненном цикле ПО
Требования используются:
- на стадии проектирования — как основа для разработки архитектуры и функционала;
- при проверке ПО — тесты создаются на основе требований;
- для коммуникации между заинтересованными сторонами (заказчиками, аналитиками, разработчиками, тестировщиками).
Документированные требования часто оформляют как техническое задание (спецификацию). За их создание обычно отвечает системный аналитик или бизнес‑аналитик.