Процесс формирования, анализа, документирования и проверки описания функциональных возможностей и ограничений, накладываемых на программную систему, называется разработкой требований (requirements engineering).
Артефакты: спецификации требований, техническое задание
Разработка требований служит отправной точкой всего технологического процесса создания ПО, без которого разработка ПО просто не имеет смысла. По данным исследования, проведенного IBM в области IT, 60% затрат времени организации-разработчики программного обеспечения несут в результате неэффективного подхода к управлению тре-бованиями. В организациях, не располагающих достаточными возможностями бизнес-анализа, проекты в три раза чаще заканчиваются не-удачей, чем успехом. При правильном определении требований и управ-лении ими перерасходы по проекту можно снизить на 20% благодаря сокращению числа неточных, неполных и упущенных требований
1. Требования к программному обеспечению
Требование
- Способность системы решить конкретную проблему пользователя или обеспечить достижение его бизнес-цели (проблема - ценность).
- Свойство или ограничение, которому компонент системы обязан удовлетворять согласно контракту, стандарту или спецификации (свойство - ограничение).
- Формальное документированное представление возможности, доступное для однозначной проверки и тестирования (описание как артефакт процесса).
Требование = Намерение пользователя + Ограничение технологий + Фиксация в документе —
Уровни требований
2. Процесс разработки требований
3. Методы сбора и выявления требований
4. Методы анализа требований
5. Документирование требований
Классический синтаксис используется для написания строгих системных требований, технических заданий (ТЗ) и нефункциональных ограничений. Избавляет текст от двусмысленности.
[Условие / Триггер] ➔ [Субъект (Система)] ➔ [Модальный глагол] ➔ [Действие] ➔ [Объект]
👥 **Продуктовый синтаксис: Пользовательские истории (User Story)
Применяется в Agile-командах (Scrum/Kanban).**
Смещает фокус с сухих технических функций на реальную бизнес-ценность и потребности живых людей.
Шаблон: Как [Роль пользователя], я хочу [Действие / Функция], чтобы [Бизнес-ценность]
- Кто? (Роль): Конкретный персонаж (например, «Преподаватель», а не просто абстрактный «Пользователь»).
- Что? (Действие): Какую задачу или действие в интерфейсе нужно совершить.
- Зачем? (Ценность): Какую проблему это решает. Самая важная часть для разработчика.
Связь характеристик качества с проверкой требований
| Характеристика качества | Анализ требований (Analysis) | Проверка требований (Validation/Verification) |
|---|---|---|
| Корректность (Correctness) | Анализирует соответствие бизнес-целям и потребностям | Подтверждает у Stakeholder, что требование действительно нужно |
| Полнота (Completeness) | Выявляет отсутствующие детали и сценарии | Проверяет, что спецификация не содержит пропусков |
| Однозначность (Unambiguity) | Устраняет неоднозначные формулировки | Проверяет, что разные участники понимают требование одинаково |
| Непротиворечивость (Consistency) | Ищет конфликты между требованиями | Проверяет отсутствие логических противоречий в наборе требований |
| Проверяемость (Verifiability) | Определяет возможность проверки | Подтверждает наличие тестов, критериев приемки или метода проверки |
| Осуществимость (Feasibility) | Оценивает техническую и ресурсную реализуемость | Проверяет, что утвержденные требования реально выполнить |
| Необходимость (Necessity) | Анализирует ценность требования | Проверяет отсутствие лишних требований |
| Трассируемость (Traceability) | Устанавливает связи источник → требование | Проверяет наличие обратной и прямой трассировки |
| Приоритетность (Priority) | Определяет относительную важность | Проверяет согласованность приоритетов с целями проекта |
| Стабильность (Stability) | Оценивает вероятность изменений | Используется для оценки рисков изменения требований |
6. Аттестация требований
Аттестация должна продемонстрировать, что требования действительно определяют ту систему, которую хочет иметь заказчик
| Метод | Что из себя представляет? | Главная цель (Зачем нужен?) | Пример из практики |
|---|---|---|---|
| 1. Обзоры требований (Reviews / Inspections) | Совместное чтение и аудит ТЗ аналитиками, разработчиками и QA. | Найти логические противоречия и нестыковки в тексте. | Архитектор замечает, что база данных не выдержит указанную в ТЗ нагрузку. |
| 2. Прототипирование (Prototyping) | Создание интерактивного макета интерфейса (например, в Figma). | Показать систему «вживую», чтобы заказчик подтвердил логику. | Клиент кликает по макету приложения и понимает, удобно ли оформлять заказ. |
| 3. Тестирование моделей (Model Validation) | Автоматическая проверка требований, описанных через UML или BDD-сценарии. | Исключить человеческий фактор и проверить математическую строгость логики. | Специальный софт проверяет UML-диаграмму на отсутствие тупиковых сценариев. |
| 4. Приемочные тесты (Acceptance Tests) | Написание сценариев тестирования до начала разработки (ATDD/BDD). | Убедиться, что требование в принципе можно проверить и измерить. | Тестировщик пишет тест-кейс: «Если файл > 2 ГБ, система должна выдать ошибку №413». |
7. Управление требованиями
деятельность, направленная на обеспечение того, чтобы требования оставались актуальными, согласованными и контролируемыми на протяжении всего жизненного цикла разработки программного обеспечения
