Библией для requirements engineering до сих пор является стандарт ISO/IEC/IEEE 29148:2018. Вот что в нем говорится о возможных типах требований, их иерархии, процессе сбора и методиках, которые помогут вам собрать их эффективно.
Что такое требования и зачем они нужны?
Требования — это формальные описания того, что система должна делать, как она должна работать и какие ограничения на неё наложены. Без них проект превращается в “угадайку”: разработчики строят то, что им кажется нужным, а заказчик получает сюрприз. В софтверной архитектуре требования — основа для дизайна, тестирования и верификации. Они помогают избежать подавляющее число ошибок на ранних стадиях.
Ключевой принцип: требования должны быть SMART (Specific, Measurable, Achievable, Relevant, Time-bound), но в ISO 29148 это расширяется до 9 характеристик:
| Характеристика (англ.) | Официальное русское название | Что это значит на практике | Плохой пример (нарушает) | Хороший пример (соответствует) |
|---|---|---|---|---|
| Unambiguous | Однозначное | Требование имеет только одно возможное толкование | «Система должна быть быстрой» | «99-й перцентиль времени отклика ≤ 300 мс при нагрузке 5000 RPS» |
| Complete | Полное | Всё необходимое указано, нет пропусков и «само собой разумеется» | «Система поддерживает оплату картой» | «Система поддерживает оплату Visa/Mastercard/Mir через шлюз PayGate v4, с сохранением токена и без хранения CVV» |
| Consistent | Согласованное | Не противоречит другим требованиям | «Доступ только по VPN» + «Доступ через интернет без VPN» | Все требования к доступу используют один и тот же механизм (например, WireGuard) |
| Verifiable | Проверяемое | Можно объективно проверить тест-кейсом, инспекцией, анализом или демо | «Удобный интерфейс» | «95 % пользователей из целевой группы выполняют задачу «найти книгу» за ≤ 3 клика» (usability-тест) |
| Traceable | Трассируемое | Имеет уникальный ID и связи вверх/вниз по иерархии | «Система должна быть надёжной» | USR-001 → SYS.NFR.REL.001 → SW.NFR.REL.001 → TEST-REL-001 |
| Correct | Корректное | Решает именно ту задачу, которую нужно решить (валидация) | «Добавить двухфакторку через Google Authenticator» (пользователи просили SMS) | «Добавить двухфакторку через SMS и приложение-аутентификатор» (точно по интервью) |
| Understandable | Понятное | Ясно всем: технарям и нетехнарям | «Система должна использовать CQRS и Event Sourcing» (для заказчика) | «При изменении книги все пользователи увидят обновление мгновенно» |
| Modifiable | Изменяемое | Требование оформлено так, что его легко поменять без каскадных правок | Все требования в одном огромном абзаце | Каждое требование — отдельный пункт с уникальным ID |
| Feasible | Выполнимое | Технически и экономически реализуемо в заданных рамках | «Поиск по 500k книг за ≤ 10 мс на Raspberry Pi 2» | «Поиск по 500k книг за ≤ 500 мс на NAS с 8 ГБ RAM» |
Возможные типы требований
Требования классифицируют по уровням абстракции, источнику и природе. Вот основные типы с примерами из типичного e-commerce проекта:
| Тип требования | Описание | Пример из практики |
|---|---|---|
| Business Requirements (деловые) | Высокий уровень: цели бизнеса, ROI, стратегические выгоды. | “Увеличить конверсию на 25% за счёт упрощённой оплаты”. |
| Stakeholder Requirements (заинтересованных сторон) | Нужды всех вовлечённых: пользователей, регуляторов, эксплуатации. | “Система должна соответствовать GDPR для хранения данных клиентов”. |
| User Requirements (пользовательские) | Подмножество stakeholder: фокус на конечных пользователях, в формате “Я как [роль] хочу [действие] чтобы [польза]”. | “Я как покупатель хочу оплатить одним кликом, чтобы сэкономить время”. |
| System Requirements (системные) | Что должна делать вся система (ПО + hardware + процессы). | “Система должна обрабатывать 5000 заказов в час”. |
| Functional Requirements (функциональные) | Что система делает: поведение, входы/выходы. | “Система должна генерировать PDF-квитанцию после оплаты”. |
| Non-Functional Requirements (нефункциональные, или quality attributes) | Как система делает: производительность, безопасность, usability. | “Время отклика ≤ 200 мс при 1000 RPS”. |
| Interface Requirements (интерфейсные) | Протоколы обмена между компонентами или внешними системами. | “API должен использовать REST с JSON и аутентификацией OAuth 2.0”. |
| Constraints (ограничения) | Внешние рамки: технологии, бюджет, стандарты. | “Использовать только PostgreSQL для БД”. |
| Design Requirements (проектные) | Конкретные решения реализации (рекомендуется избегать на ранних этапах). | “Использовать микросервисную архитектуру на Kubernetes”. |
Non-functional часто разбивают по ISO 25010: performance, reliability, security, usability и т.д.
Иерархия требований
Требования — не плоский список, а пирамида. Они строятся сверху вниз с трассировкой (связями) для контроля изменений.
Business Requirements (стратегические цели бизнеса)
↓
Stakeholder Requirements (StRS: нужды всех сторон, включая User Requirements)
↓ (анализ и уточнение)
System Requirements (SyRS: что делает вся система)
↓ (детализация)
Software Requirements (SRS: функциональные + нефункциональные для ПО)
↓
Hardware/Process Requirements (если нужно)
Трассировка: Каждое требование ниже должно ссылаться на верхнее (trace to/from). Пример: USR-001 → SYS.REQ.001 → SW.FUNC.001. Почему иерархия важна: Меняется бизнес-требование — сразу видно, что сломается в коде.
Процесс сбора требований
Сбор — это итеративный процесс. Вот пошагово:
- Выявление стейкхолдеров (Elicitation preparation): Составьте onion-модель (в центре — система, вокруг — пользователи, заказчики, регуляторы, конкуренты). Используйте RACI-матрицу (Responsible, Accountable, Consulted, Informed).
- Сбор нужд (Elicitation): Опросите стейкхолдеров. Формат: сырые user stories, жалобы, идеи. Не фильтруйте — запишите всё.
- Анализ и формализация (Definition): Преобразуйте сырые нужды в Stakeholder Requirements (StRS). Добавьте атрибуты: приоритет, источник, верификация.
- Преобразование в системные/софтверные (Specification): Уточните в SyRS/SRS. Добавьте нефункциональные и ограничения. Проверьте на конфликты.
- Верификация и валидация (Verification & Validation): Проверьте на полноту (verification: “правильно ли описано?”) и соответствие нуждам (validation: “то ли описано?”).
- Управление изменениями (Management): Ведите Change Request (CR), оценивайте влияние, одобряйте через CCB (Change Control Board).
Процесс итеративный: возвращайтесь к шагу 1 при изменениях.
Методики сбора требований
| Методика | Описание и когда использовать | Пример применения в 2025 |
|---|---|---|
| Интервью | 1:1 беседы с стейкхолдерами. Для глубокого понимания. | Видеозвонок с 5 ключевыми пользователями: “Расскажите, как вы ищете книги сейчас?” |
| Опросы / Surveys | Google Forms / MS Forms для массового сбора. Для широкой аудитории. | Анонимный опрос: “Какие функции библиотеки важны для вас? (Поиск по тегам — да/нет)” |
| Воркшопы / Workshops | Групповые сессии с фасилитацией. Для выявления конфликтов. | Miro-доска с 10 стейкхолдерами: рисуем user journeys для скачивания книг. |
| Наблюдения / Observation | Смотрите, как пользователи работают с аналогичной системой. Для выявления скрытых нужд. | Shadowing: наблюдаем, как пользователь ищет в Flibusta и жалуется на медленный поиск. |
| Прототипирование | Быстрый мокап (Figma/Axure). Для валидации идей. | Прототип веб-интерфейса: “Вот поиск — попробуйте, что не так?” |
| Use Cases / User Stories | Формат “Я как [роль] хочу [действие] чтобы [польза]”. Для Agile. | “Я как читатель хочу фильтр по жанру, чтобы найти фантастику быстро”. |
| Brainstorming | Генерация идей без критики. Для креативных требований. | Командный Zoom: “Какие фичи сделают нашу библиотеку лучше Flibusta?” |
| Document Analysis | Разбор существующих документов (контракты, стандарты). Для compliance. | Анализ GDPR: “Требования к хранению метаданных пользователей”. |
| Focus Groups | Группа 5–10 пользователей обсуждает тему. Для мнений. | Онлайн-группа: “Что раздражает в LibGen? Как улучшить?” |
+ ChatGPT для генерации черновиков user stories или Miro AI для анализа заметок.
Почему это важно для архитектора
Типы, иерархия и сбор — основа, чтобы избежать 80% переделок. Помните: хорошие требования — это не текст, а договор между людьми. Собирайте итеративно, трассируйте и всегда проверяйте: “Это то, что хотел пользователь?”