Процесс формирования, анализа, документирования и проверки описания функциональных возможностей и ограничений, накладываемых на программную систему, называется разработкой требований (requirements engineering).
Артефакты: спецификации требований, техническое задание
Разработка требований служит отправной точкой всего технологического процесса создания ПО, без которого разработка ПО просто не имеет смысла. По данным исследования, проведенного IBM в области IT, 60% затрат времени организации-разработчики программного обеспечения несут в результате неэффективного подхода к управлению тре-бованиями. В организациях, не располагающих достаточными возможностями бизнес-анализа, проекты в три раза чаще заканчиваются не-удачей, чем успехом. При правильном определении требований и управ-лении ими перерасходы по проекту можно снизить на 20% благодаря сокращению числа неточных, неполных и упущенных требований
1. Требования к программному обеспечению
Понятие требование
Требование
- Способность системы решить конкретную проблему пользователя или обеспечить достижение его бизнес-цели (проблема - ценность).
- Свойство или ограничение, которому компонент системы обязан удовлетворять согласно контракту, стандарту или спецификации (свойство - ограничение).
- Формальное документированное представление возможности, доступное для однозначной проверки и тестирования (описание как артефакт процесса).
Требование = Намерение пользователя + Ограничение технологий + Фиксация в документе —
Инженерная задача
Из неформального желания заинтересованной стороны получить проверяемое требование.
Например:
«Система должна работать быстро»
превратить в:
«Система должна формировать результат поиска не более чем за 2 секунды для 95% запросов при нагрузке …»
Артефакт
Requirement Specification
Уровни требований
Инженерная задача
Алгоритм
Цель (бизнес-требование)
↓
Потребность пользователя (пользовательские требования)
↓
Функциональное требование
↓
Критерий приемки (тестовые сценарии
Из бизнес-описания системы построить цепочку «цель → потребность → требование → критерий приемки».
Артефакт
Requirement Traceability Matrix
2. Процесс разработки требований
| Этап | Инженерная задача | Артефакт |
|---|---|---|
| Выявление | Найти заинтересованные стороны и их потребности | Stakeholder Map |
| Сбор | Получить исходные требования | Raw Requirements |
| Анализ | Найти конфликты, пропуски, зависимости | Analysis Model |
| Спецификация | Сформулировать требования | SRS |
| Проверка | Найти дефекты требований | Review Report |
| Управление | Обработать изменения | Change Request |
Методы сбора и выявления требований
Задача 1. Интервью
Сформулируйте 10 вопросов для [роль], который является пользователем системы [назначение].
Задача 2. Наблюдение
Какие требования невозможно надежно получить только из интервью?
Задача 3. Анализ стекхолдеров
Определите заинтересованные стороны и их интересы.
Артефакты
список требований
Методы анализа требований
Инженерная задача
Дан набор требований:
R1 ...
R2 ...
R3 ...
Найти:
- противоречия;
- пропуски;
- зависимости;
- неоднозначности;
- нереализуемые требования.
Артефакты
- DFD;
- Use Case;
- матрица зависимостей.
Документирование требований
как неформальное намерение преобразовалось в проверяемое утверждение
Классический синтаксис используется для написания строгих системных требований, технических заданий (ТЗ) и нефункциональных ограничений. Избавляет текст от двусмысленности.
[Условие / Триггер] ➔ [Субъект (Система)] ➔ [Модальный глагол] ➔ [Действие] ➔ [Объект]
👥 **Продуктовый синтаксис: Пользовательские истории (User Story)
Применяется в Agile-командах (Scrum/Kanban).**
Смещает фокус с сухих технических функций на реальную бизнес-ценность и потребности живых людей.
Шаблон: Как [Роль пользователя], я хочу [Действие / Функция], чтобы [Бизнес-ценность]
- Кто? (Роль): Конкретный персонаж (например, «Преподаватель», а не просто абстрактный «Пользователь»).
- Что? (Действие): Какую задачу или действие в интерфейсе нужно совершить.
- Зачем? (Ценность): Какую проблему это решает. Самая важная часть для разработчика.
Инженерная задача
Одно и то же “неявнятное” пожелание представить:
- как User Story;
- как формальное системное требование;
- как критерий приемки.
3. Качество требований
Связь характеристик качества с проверкой требований
| Характеристика качества | Анализ требований (Analysis) | Проверка требований (Validation/Verification) |
|---|---|---|
| Корректность (Correctness) | Анализирует соответствие бизнес-целям и потребностям | Подтверждает у Stakeholder, что требование действительно нужно |
| Полнота (Completeness) | Выявляет отсутствующие детали и сценарии | Проверяет, что спецификация не содержит пропусков |
| Однозначность (Unambiguity) | Устраняет неоднозначные формулировки | Проверяет, что разные участники понимают требование одинаково |
| Непротиворечивость (Consistency) | Ищет конфликты между требованиями | Проверяет отсутствие логических противоречий в наборе требований |
| Проверяемость (Verifiability) | Определяет возможность проверки | Подтверждает наличие тестов, критериев приемки или метода проверки |
| Осуществимость (Feasibility) | Оценивает техническую и ресурсную реализуемость | Проверяет, что утвержденные требования реально выполнить |
| Необходимость (Necessity) | Анализирует ценность требования | Проверяет отсутствие лишних требований |
| Трассируемость (Traceability) | Устанавливает связи источник → требование | Проверяет наличие обратной и прямой трассировки |
| Приоритетность (Priority) | Определяет относительную важность | Проверяет согласованность приоритетов с целями проекта |
| Стабильность (Stability) | Оценивает вероятность изменений | Используется для оценки рисков изменения требований |
Инженерная задача
Найти дефекты требований.
Для списка требований составить чек-лист:
☐ Correct
☐ Complete
☐ Unambiguous
☐ Consistent
☐ Verifiable
☐ Feasible
☐ Necessary
☐ Traceable
☐ Prioritized
☐ Stable
4. Аттестация требований
- продемонстрировать, что требования действительно определяют ту систему, которую хочет иметь заказчик
| Метод | Что из себя представляет? | Главная цель (Зачем нужен?) | Пример из практики |
|---|---|---|---|
| 1. Обзоры требований (Reviews / Inspections) | Совместное чтение и аудит ТЗ аналитиками, разработчиками и QA. | Найти логические противоречия и нестыковки в тексте. | Архитектор замечает, что база данных не выдержит указанную в ТЗ нагрузку. |
| 2. Прототипирование (Prototyping) | Создание интерактивного макета интерфейса (например, в Figma). | Показать систему «вживую», чтобы заказчик подтвердил логику. | Клиент кликает по макету приложения и понимает, удобно ли оформлять заказ. |
| 3. Тестирование моделей (Model Validation) | Автоматическая проверка требований, описанных через UML или BDD-сценарии. | Исключить человеческий фактор и проверить математическую строгость логики. | Специальный софт проверяет UML-диаграмму на отсутствие тупиковых сценариев. |
| 4. Приемочные тесты (Acceptance Tests) | Написание сценариев тестирования до начала разработки (ATDD/BDD). | Убедиться, что требование в принципе можно проверить и измерить. | Тестировщик пишет тест-кейс: «Если файл > 2 ГБ, система должна выдать ошибку №413». |
7. Управление требованиями
деятельность, направленная на обеспечение того, чтобы требования оставались актуальными, согласованными и контролируемыми на протяжении всего жизненного цикла разработки программного обеспечения
