«Software Requirements» напоминает о простой вещи: хорошая архитектура почти никогда не начинается с компонентов и технологий, она начинается с правильно понятых требований. Книга показывает, как превратить размытые ожидания бизнеса и пользователей в рабочую инженерную рамку.
Практическая сила главы в том, что она связывает уровни требований, заинтересованные стороны, техники выявления, приоритизацию и управление изменениями. По ней хорошо видно, как слабые требования превращаются в дорогие архитектурные ошибки, а сильные задают ясные ограничения и реалистичные рамки задачи.
На интервью и в discovery-разговорах этот материал особенно полезен: он помогает задавать точные уточняющие вопросы, разделять обязательное и желательное и формулировать качественные атрибуты еще до появления первой схемы.
Практическая польза главы
Требования как вход
Показывает, как качество требований напрямую влияет на корректность архитектурного выбора.
Приоритизация
Помогает отделять критичные требования от желательных и не перегружать решение лишней сложностью.
Traceability
Учит связывать бизнес-цель, requirement и архитектурный артефакт в единую цепочку обоснования.
Interview clarity
На интервью улучшает стадию уточнения требований и демонстрирует зрелый discovery-подход.
Software Requirements (Разработка требований к программному обеспечению)
Авторы: Karl Wiegers, Joy Beatty
Издательство: Microsoft Press, 2013 (3rd Edition)
Объём: ~670 страниц
Классика от Карла Вигерса: уровни требований, техники выявления, приоритизация MoSCoW и Kano, управление изменениями.
Первоисточник
Официальная страница книги Karl Wiegers и Joy Beatty: Software Requirements.
Ключевые концепции
Уровни требований
- 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 и приоритеты
Применение на System Design интервью
Чек-лист вопросов (из книги):
Главные выводы
Связанные главы
- Что такое архитектура ПО и зачем она в System Design - задаёт архитектурный контекст, где требования превращаются в ограничения, качества и инженерные решения.
- Обсуждение фреймворков для проведения/прохождения system design interview - помогает структурировать discovery-этап: какие вопросы задать и как фиксировать рамки задачи.
- Подходы к проведению дизайн интервью - показывает пошаговый процесс формализации функциональных и нефункциональных требований.
- Рекомендации по подготовке к интервью (краткосрочно) - даёт практичный план тренировки навыка уточняющих вопросов и приоритизации scope.
- Clean Architecture (short summary) - связывает требования с проектированием границ, зависимостей и ответственностей модулей.
- Стратегии декомпозиции - переводит требования в решения о границах сервисов и контрактах между подсистемами.