Software Requirements (Разработка требований к программному обеспечению)
Авторы: Karl Wiegers, Joy Beatty
Издательство: Microsoft Press, 2013 (3rd Edition)
Объём: ~670 страниц
Классика от Карла Вигерса: уровни требований, техники выявления, приоритизация MoSCoW и Kano, управление изменениями.
Оригинал
ПереводКлючевые концепции
Уровни требований
- Business Requirements — цели бизнеса
- User Requirements — что пользователи смогут делать
- Functional Requirements — поведение системы
- Non-functional — качественные атрибуты
Quality Attributes
- Performance (latency, throughput)
- Scalability (load growth)
- Availability (uptime)
- Security, Maintainability, Usability
Stakeholders
Разные stakeholders имеют разные требования. Важно идентифицировать всех заинтересованных лиц и понять их приоритеты. На интервью это помогает задавать правильные уточняющие вопросы.
Use Cases
Описание взаимодействия пользователя с системой. Включает основной сценарий и альтернативные пути. Помогает не упустить edge cases при проектировании.
Структура книги
Software Requirements: What, Why, and Who
Основы: что такое требования, почему они важны, роли в процессе. The Business Analyst роль. Requirements engineering как дисциплина.
Requirements Development
Elicitation (выявление), Analysis (анализ), Specification (документирование), Validation (валидация). Техники интервью и воркшопов.
Requirements for Specific Project Types
Agile проекты, пакетные решения, outsourcing, embedded systems, business intelligence.
Requirements Management
Управление изменениями, версионирование, traceability, повторное использование требований.
Техники выявления требований
Интервью
Структурированные и неструктурированные беседы со stakeholders. Открытые вопросы для исследования, закрытые — для уточнения.
Наблюдение
Наблюдение за пользователями в их рабочей среде. Помогает выявить неосознанные требования и реальные workflows.
Прототипирование
Быстрые прототипы для валидации понимания требований. Помогает обнаружить пробелы на ранних стадиях.
Приоритизация требований
На интервью часто просят определить MVP или приоритизировать функции. Вигерс предлагает несколько подходов:
MoSCoW
- Must have — обязательно для релиза
- Should have — важно, но не критично
- Could have — желательно
- Won't have — не в этом релизе
Kano Model
- Basic — ожидаемое (must be)
- Performance — чем больше, тем лучше
- Excitement — wow-эффект
Типичные ошибки
❌ На интервью
- Сразу прыгать к решению без уточнения требований
- Не спрашивать о масштабе и нагрузке
- Игнорировать нефункциональные требования
- Не уточнять приоритеты фич
✓ Как правильно
- Начать с бизнес-контекста и целей
- Определить основные use cases
- Уточнить SLA/SLO (availability, latency)
- Согласовать scope и приоритеты