Справочник аналитика: требования к ПО

Handbook / Cheatsheet

Полное руководство по работе с требованиями к программному обеспечению: от классификации и сбора до управления изменениями и шаблонов документов.

Основано на: Handbook of Requirements and Business Analysis (Bertrand Meyer, Springer, 2022), Software Requirements (Wiegers & Beatty, 2013), BABOK v3 (IIBA, 2015), SWEBOK v4 (IEEE, 2024), ISO/IEC/IEEE 29148:2018, ГОСТ 34.601-90, FURPS+ (Grady, 1992), и практическом опыте.

Определения — базовый глоссарий

Ключевые источники и стандарты

Часть 1: Виды требований. Модели классификации

1.1 PEGS-модель (Meyer, 2022)

Фреймворк для первичной классификации любого требования. Каждое требование относится ровно к одному из четырёх измерений.

Принцип: каждое требование — ровно один PEGS-компонент. Никаких пересечений. Это основа трассируемости.

1.2 FURPS+ — модель атрибутов качества

Модель Grady (HP, 1992) для классификации нефункциональных требований.

1.3 Традиционная классификация (по уровню абстракции)

Часть 2: 14 критериев качества требований

Модель Bertrand Meyer (2022). Каждый критерий имеет код для быстрой ссылки в чек-листах.

Группа A: Содержательные критерии

6 видов полноты (Meyer, 2022)

1. Сценарная полнота — описаны normal, alternative, exceptional flows
2. Интерфейсная полнота — описаны все внешние интерфейсы (user, API, hardware)
3. Командно-запросная полнота — все операции: create, read, update, delete (CRUD) + query
4. Исключительные ситуации — ошибки сети, некорректные данные, пиковая нагрузка
5. Данные — описаны форматы, структуры, ограничения всех входов/выходов
6. Атрибуты качества — производительность, безопасность, надёжность, масштабируемость

Группа B: Коммуникативные критерии

Группа C: Инженерные критерии

Группа D: Поддерживаемость

Группа E: Дополнительные

Часть 3: Техники сбора требований

3.1 Процесс выявления требований (итеративная модель)

Шаг 1. Подготовка к сбору:

• Что необходимо выяснить? — анализ текущего описания требований, текущей реализации системы, выявление недостающих и недостаточно описанных требований.
• У кого? Где? — список доступных источников (документация, артефакты) и стейкхолдеров.
• Каким образом? — выбор оптимального метода выявления.

3.2 10 техник сбора требований

Интервью со стейкхолдерами

Когда: начало проекта, уточнение неясных зон, сбор контекста.

Правила проведения:

1. Всегда ведите запись встречи (с согласия собеседника).
2. Small talk для разрядки (2–3 вопроса, не затягивать).
3. Начинайте с объявления проблематики.
4. Следуйте плану, задавайте вопросы последовательно.
5. Указывайте тайм-коды для каждого вопроса.
6. Раскрывайте вопросы дополнительными вопросами — беседа должна быть живой.
7. В конце подтвердите позицию собеседника закрытым вопросом: «Я правильно вас понял, что {тезис}?»

Шаблон протокола интервью:

ПРОТОКОЛ ИНТЕРВЬЮ
─────────────────────────────────────────────────────
Проект:          {Название проекта}
Дата проведения: {ДД.ММ.ГГГГ}
Интервьюер:      {Кто проводит}
Интервьюируемый: {Кому задаём вопросы}
Проблематика:    {Тема интервью}
─────────────────────────────────────────────────────
Вопрос № 1:
  Тайминг:       00:00–00:05
  Текст вопроса: {Формулировка вопроса}
  Ответы:        {Запись ответа}
─────────────────────────────────────────────────────
Вопрос № 2: ...
─────────────────────────────────────────────────────
Заключение:
  Я правильно вас понял, что {тезис}?

Плюсы: наиболее эффективный метод; меньше недопонимания; выявляет скрытые требования. Минусы: сложность согласования разных стейкхолдеров; высокие временные затраты; качество зависит от интервьюера.

Воркшопы (Requirements Workshop)

Когда: нужно быстро согласовать требования с группой. JAD-сессия (Joint Application Development) — 1–3 дня. Эффективность: в 3–5 раз быстрее серии интервью.

Шаблон повестки:

[Дата] | [Проект] | Workshop по требованиям
────────────────────────────────────────────
1. Бизнес-цели и контекст (30 мин)
2. Сценарии использования (90 мин)
3. Приоритизация MoSCoW (30 мин)
4. Анализ рисков (30 мин)
5. Следующие шаги (15 мин)

Наблюдение (Job Shadowing)

Когда: пользователи не могут сформулировать потребности. Как: сядьте рядом с пользователем на 2–4 часа, записывайте всё. Выявляет: неосознаваемые потребности — то, что кажется пользователю очевидным.

Анализ документов

Когда: есть legacy-документация, регламенты, стандарты. Как: изучите существующие ТЗ, контракты, инструкции, баги-трекер. Ищете: ограничения (E), скрытые требования, описание ошибок.

5️⃣ Прототипирование

Когда: неясны UI/UX, высокая неопределённость. Как: low-fidelity (бумага, wireframes) → high-fidelity (Figma, Axure, интерактивные). Лучшая валидация — дать прототип пользователю и наблюдать за его действиями.

Анкетирование

Когда: большая (100+) аудитория респондентов. Как: опросники с открытыми/закрытыми вопросами. Риски: низкий response rate, поверхностные ответы. Плюсы: большой охват; небольшие временные затраты; возможность повторного использования. Минусы: не подходит для неявных требований; невозможно заранее учесть все вопросы.

Мозговой штурм

Когда: генерация идей, креативные требования, нет готового решения. Правила: на этапе генерации — без критики. Плюсы: выявляет WOW-требования; глубокая проработка (разные эксперты). Минусы: ограниченный круг стейкхолдеров; нужна жёсткая модерация; требуется высокая вовлечённость.

Анализ конкурентов

Когда: есть аналоги на рынке. Как: сравните по функциям (feature matrix), оцените UX, прочитайте отзывы.

Шаблон feature-матрицы:

User Stories + Use Cases

Когда: Agile / гибкая разработка.

User Story шаблон:

Как [роль / user persona]
Я хочу [действие / функция]
Чтобы [цель / бизнес-ценность]

Принцип INVEST:

• Independent — независимые
• Negotiable — обсуждаемые
• Valuable — ценные
• Estimable — оцениваемые
• Small — маленькие
• Testable — тестируемые

Reverse Engineering

Когда: система уже существует, документация утеряна. Как: анализируйте код, UI, базы данных, API. Риски: можно воспроизвести ошибки legacy.

3.3 Дополнительные методы сбора

3.4 Ключевые источники требований по уровням

📋 Часть 4: 15 правил написания требований

4.1 Золотая структура требования

Хорошее требование должно содержать три компонента:

[Роль пользователя, которая получает выгоду]
    + [Желаемое состояние, которое роль хочет достичь]
        + [Метрика, позволяющая проверить требование (где применимо)]

Пример:

«Как менеджер по закупкам, я хочу получать уведомление при снижении цены на 10% на товары из моего списка отслеживания, чтобы своевременно перезаключать контракты».

4.2 15 правил — таблица

⚠️ Часть 5: Топ-10 ловушек — с примерами и решениями

🚫 Часть 6: Стоп-слова — таблица замен

📋 Часть 7: Приоритизация требований

7.1 MoSCoW

7.2 Kano Model

7.3 RICE Framework

Формула: $$RICE = \frac{R \times I \times C}{E}$$

👤 Часть 8: User Personas

8.1 Что такое User Persona

User Persona — архетипический портрет пользователя. Не реальный человек, а собирательный образ на основе исследований (интервью, наблюдения, аналитики).

8.2 Шаблон User Persona

8.3 Пример

Имя:           Елена Петрова
Роль:          Менеджер закупок
Возраст:       32 года
Опыт:          Средний пользователь ПК, Excel — уверенно

Цели:
  1. Сократить время обработки заявки до 5 минут
  2. Исключить ошибки ручного ввода

Боли:
  1. Тратит 3 часа в день на сверку заявок в Excel
  2. Нет прозрачности — не знает, на какой стадии заявка

Контекст:
  Работает в офисе, ПК Windows 11, браузер Chrome.
  Использует систему ежедневно, 6–8 часов.

Ключевые сценарии:
  • Создать заявку на закупку
  • Отследить статус согласования
  • Сформировать отчёт по закупкам за период

🎯 Часть 9: Impact Mapping

9.1 Что такое Impact Mapping

Техника, связывающая бизнес-цели с пользовательским поведением и конкретными фичами. Создана Gojko Adzic (2012).

9.2 Структура Impact Map

9.3 Пример Impact Map для цели «Сократить время обработки заявки на 50%»

📋 Часть 10: Acceptence Criteria и Definition of Done

10.1 Acceptance Criteria (AC)

Условия, при которых требование считается выполненным. Формат — Given-When-Then (Gherkin).

Шаблон:

Given [начальное состояние / контекст]
When  [действие пользователя / событие]
Then  [ожидаемый результат]

Пример:

Функциональное требование F-01: Создание заявки на закупку

AC-01.1: Успешное создание
  Given Менеджер закупок авторизован в системе
    And Ключевые поля каталога заполнены (наименование, количество, бюджет)
  When Менеджер нажимает «Отправить на согласование»
  Then Система создаёт заявку со статусом «На согласовании»
    And Система отправляет email руководителю
    And Номер заявки отображается пользователю

AC-01.2: Обязательные поля не заполнены
  Given Менеджер закупок авторизован
    And Поле «Наименование» пусто
  When Менеджер нажимает «Отправить на согласование»
  Then Система показывает сообщение: «Заполните обязательные поля»
    And Заявка не создаётся

10.2 Definition of Done (DoD)

Минимальный набор критериев, при котором задача/требование считается готовой. DoD — это контракт команды.

Пример DoD для требования:

• Код написан и проходит code review
• Unit-тесты написаны и проходят (> 80% coverage)
• Интеграционные тесты написаны и проходят
• Требование проверено (QA) по Acceptance Criteria
• Документация обновлена (SRS, README, API spec)
• Все AC проходят — автоматически или вручную
• Нет новых критических багов
• Требование принято Product Owner'ом

📋 Часть 11: Use Case Specification — полный шаблон

11.1 Структура полного Use Case (по Вигерсу/Коберну)

11.2 Пример заполненного Use Case

UC-01: Создать заявку на закупку
─────────────────────────────────────────────────────
Действующие лица: Менеджер закупок (главный), Руководитель (вторичный)
Триггер:          Пользователь в меню выбрал «Новая заявка»
Предусловия:      Пользователь аутентифицирован, авторизован на создание заявок
Постусловия:      Заявка создана со статусом «На согласовании»,
                  Руководитель получил уведомление
─────────────────────────────────────────────────────
Основной поток:
  1. Система отображает форму создания заявки
  2. Пользователь заполняет поля: наименование, количество, бюджет, комментарий
  3. Пользователь нажимает «Отправить на согласование»
  4. Система проверяет заполнение обязательных полей
  5. Система сохраняет заявку со статусом «На согласовании»
  6. Система отправляет email Руководителю
  7. Система отображает подтверждение: «Заявка №123 создана»

Расширения:
  2a. Товар из каталога:
      2a1. Пользователь нажимает «Выбрать из каталога»
      2a2. Система открывает каталог с поиском
      2a3. Пользователь выбирает позицию — поля автозаполняются
  2b. Если наименование не заполнено → система отключает кнопку «Отправить»
  4a. Если не заполнен бюджет:
      4a1. Система подсвечивает поле красным
      4a2. Система выводит сообщение: «Укажите бюджет»
      4a3. Возврат на шаг 2
  5a. Если сумма > 500 000:
      5a1. Система дополнительно запрашивает комментарий о необходимости
      5a2. Система устанавливает флаг «Двойное согласование»

Специальные требования:
  • Время сохранения заявки ≤ 1 секунда
  • Форма должна быть доступна на мобильных устройствах

Бизнес-правила:
  • BR-01: Заявка на сумму > 100 000 — два согласующих
  • BR-02: Обязательные поля: наименование, количество, бюджет

📋 Часть 12: Управление требованиями (Lifecycle)

12.1 Полный жизненный цикл требования

12.2 Процесс управления изменениями (Change Request Process)

12.3 Атрибуты требования — обязательные метаданные

12.4 Матрица трассировки (Traceability Matrix)

📋 Часть 13: ADR — Architecture Decision Records

13.1 Что такое ADR

Документ, фиксирующий архитектурное решение: почему выбран тот или иной подход, какие альтернативы рассматривались, какие последствия.

13.2 Шаблон ADR

ADR-{N}: {Краткое название решения}
────────────────────────────────────────
Статус: {Proposed | Accepted | Deprecated | Superseded}
Дата:   {ДД.ММ.ГГГГ}

Контекст:
  {Почему это решение необходимо?
   Какая проблема решается?
   Какие ограничения есть?}

Решение:
  {Что выбрали? Конкретная формулировка решения.}

Альтернативы:
  {Какие варианты рассматривались?}
  1. {Вариант А} — {почему не подошёл}
  2. {Вариант Б} — {почему не подошёл}

Последствия:
  {Плюсы и минусы решения.
   Что меняется в архитектуре?}

Linked ADRs:
  {Связанные решения: ADR-{N}, ADR-{M}}

13.3 Пример ADR

ADR-005: Выбор СУБД для хранения заказов
────────────────────────────────────────
Статус: Accepted
Дата:   01.06.2026

Контекст:
  Система должна хранить 5000+ заказов в день.
  Требования: ACID-транзакции, сложные отчёты, соединения с 1С.
  Команда: 3 бэкенд-разработчика — сильны в SQL.

Решение:
  PostgreSQL 16.
  Обоснование: ACID,成熟ая экосистема, JSONB для гибких атрибутов,
  опыт команды, бесплатно (MIT).

Альтернативы:
  1. MongoDB — не подошла: нет сложных JOIN для отчётов, команда слаба в NoSQL
  2. ClickHouse — не подошла: не ACID, не подходит для OLTP
  3. Oracle — не подошла: высокая стоимость, избыточна

Последствия:
  + Сильная поддержка ACID-транзакций
  + Хорошая документация и комьюнити
  − Нужно настроить репликацию для отказоустойчивости
  − Нет built-in шардирования (использовать Patroni)

Linked ADRs:
  ADR-003: Выбор языка программирования (Python)
  ADR-007: Паттерн репликации (Patroni + etcd)

📋 Часть 14: Шаблоны документов

14.1 Шаблон SRS (по ISO/IEC/IEEE 29148)

────────────────────────────────────────────────
СПЕЦИФИКАЦИЯ ТРЕБОВАНИЙ К ПРОГРАММНОМУ ОБЕСПЕЧЕНИЮ
(SRS — Software Requirements Specification)
Проект: [Название]
Версия: 1.0 | Дата: [Дата]
────────────────────────────────────────────────

1. ВВЕДЕНИЕ
   1.1 Назначение документа
   1.2 Область применения (Scope)
   1.3 Определения и глоссарий
   1.4 Ссылки (стандарты, документы)
   1.5 Обзор документа

2. ОБЩЕЕ ОПИСАНИЕ
   2.1 Контекст системы (диаграмма контекста)
   2.2 PEGS-классификация
   2.3 User Personas
   2.4 Impact Map
   2.5 Предположения и зависимости
   2.6 Ограничения (Constraints)

3. ФУНКЦИОНАЛЬНЫЕ ТРЕБОВАНИЯ
   [F-01] [формулировка] [трассировка: G-XX] [приоритет: MoSCoW]
   [F-02] ...

4. НЕФУНКЦИОНАЛЬНЫЕ ТРЕБОВАНИЯ
   4.1 Производительность (FURPS: Performance)
   4.2 Usability
   4.3 Надёжность (Reliability)
   4.4 Поддерживаемость (Supportability)
   4.5 Безопасность
   4.6 Ограничения (FURPS: +)

5. ТРЕБОВАНИЯ К ИНТЕРФЕЙСАМ
   5.1 Пользовательский интерфейс
   5.2 API / программные интерфейсы
   5.3 Аппаратные интерфейсы

6. МОДЕЛЬ ДАННЫХ
   6.1 Концептуальная модель (сущности и связи)
   6.2 Словарь данных (Data Dictionary)

7. USE CASES
   7.1 UC-01: [Название]
   7.2 UC-02: [Название]
   ...

8. ПРИОРИТИЗАЦИЯ
   8.1 MoSCoW
   8.2 Kano
   8.3 RICE (для спорных требований)

9. ТРАССИРУЕМОСТЬ
   [Матрица: требование → цель → тест-кейс]

10. КРИТЕРИИ ПРИЁМКИ
   10.1 Acceptance Criteria для каждого функционального требования
   10.2 Definition of Done
   10.3 Критерии для NFR

11. УПРАВЛЕНИЕ ИЗМЕНЕНИЯМИ
   11.1 Процесс Change Request
   11.2 Состав CCB (Change Control Board)

12. ADR (Architecture Decision Records)
   12.1 ADR-001: ...
   12.2 ADR-002: ...

ПРИЛОЖЕНИЯ
   A. User Stories (для Agile-команд)
   B. Протоколы интервью
   C. Глоссарий
   D. Матрица трассировки (полная)

14.2 Шаблон плана управления требованиями

14.3 Шаблон матрицы трассировки

📋 Часть 15: Чек-листы

✅ Пред-утверждение требований (Quality Gate)

• PEGS-классификация выполнена для каждого требования
• FURPS+ категории проверены (нет пропущенных NFR)
• Все 14 критериев качества проверены (A1–E2)
• 15 правил написания соблюдены (атомарность, нет стоп-слов, нет предположений)
• Стоп-слова заменены на измеримые формулировки
• Исключительные ситуации описаны (6 видов полноты)
• Требования трассируются к бизнес-целям или ограничениям
• Приоритеты расставлены (MoSCoW: ≤ 30% Must)
• Стейкхолдеры валидировали требования (письменно)
• Нефункциональные требования присутствуют и измеримы
• Требования отделены от дизайн-решений (абстрактность)
• User Personas созданы (хотя бы 1–2 ключевых роли)
• Acceptance Criteria написаны для каждого FR (Given-When-Then)
• Матрица трассировки заполнена (требование → цель → тест)
• Документ структурирован и читаем целевой аудиторией

✅ Чек-лист функционального требования

• ID присвоен (уникальный, стабильный)
• Формулировка: «Система должна [глагол] [объект] [условие]»
• Активный залог (не «должна быть обеспечена возможность»)
• Не содержит стоп-слов
• Трассируется к бизнес-цели (G-ID)
• Приоритет MoSCoW указан
• Версионировано
• Acceptance Criteria написаны (Given-When-Then)
• Рецензировано минимум 1 разработчиком + 1 стейкхолдером

✅ Чек-лист нефункционального требования

• Классифицировано по FURPS+
• Измеримо численно (метрика + порог)
• Проверяемо (можно тестировать или моделировать)
• Реалистично (feasible)
• Трассируется к бизнес-ограничению или стандарту
• Не является дизайн-решением

✅ Чек-лист User Story

• Формат: «Как [роль], я хочу [действие], чтобы [цель]»
• INVEST: Independent, Negotiable, Valuable, Estimable, Small, Testable
• Есть Acceptance Criteria (Given-When-Then)
• Приоритет MoSCoW
• Story Points / T-Shirt size оценены

✅ Еженедельный чек-лист аналитика

• Проверил актуальность требований (ничего не устарело)
• Проверил баги/задачи — не появились ли новые требования из багов
• Согласовал все открытые вопросы с бизнесом
• Обновил матрицу трассировки
• Документировал принятые решения (ADR)
• Обработал Change Requests (если были)
• Описал новые исключительные сценарии (если появились)

🧭 Часть 16: Принципы работы с требованиями

16.1 10 золотых принципов

1. Требование ≠ Дизайн. Описывайте ЧТО, а не КАК. Технические решения — разработчикам.
2. Измеряемость любой ценой. Нет метрики — нет требования. «Быстро» не принимается.
3. Один факт = одно требование. Атомарность. Никаких списков из 10 пунктов в одном ID.
4. Каждое требование имеет источник. Если неизвестно, кто попросил — удалите.
5. Трассируемость в обе стороны. От цели → к требованию → к тесту и обратно.
6. Приоритизация обязательна. 100% Must have — это 0% реальности. MoSCoW + Kano + RICE.
7. Исключения важнее нормы. Happy path — 20% кода. 80% — обработка ошибок.
8. Требования живут. Версионируйте, управляйте изменениями, не хороните документы.
9. Проверяемость — критерий качества. Если нельзя проверить тестом — требование бесполезно.
10. Стейкхолдер — не враг. Интервью, workshop, прототип — вовлекайте на каждом шаге.

16.2 PEGS-принцип (Meyer, 2022)

«Каждое релевантное утверждение о проекте относится ровно к одному из 4 измерений: Project, Environment, Goals или System. Требования, не относящиеся ни к одному из них, не являются релевантными и должны быть отклонены.»

16.3 Принцип Specification over Implementation

«Требования должны описывать желаемое поведение системы, а не то, как это поведение достигается технически. Specification — это контракт. Implementation — решение. Не смешивайте.»

16.4 Принцип Elicitation over Gathering

«Термин "elicitation" (выявление) предпочтительнее "gathering" (сбор), потому что требования не лежат на поверхности — их нужно выявлять, в том числе неявные и подразумеваемые, которые существуют только в головах людей или скрыты в сложных системах.» (BABOK)

📚 Часть 17: Библиография и ссылки

Книги

Стандарты

Статьи и онлайн-ресурсы

🔑 Шпаргалка: 10 секунд — быстрый старт

Если вы — разработчик, пишущий требования впервые:

1. Откройте шаблон SRS (Часть 14.1)
2. Сформулируйте цель (G): «Зачем мы это делаем?»
3. Заполните PEGS классификацию для каждого требования
4. Пишите через «Система должна [глагол] [объект]» — никакого пассива
5. Добавьте NFR: производительность, надёжность, безопасность
6. Заполните Acceptance Criteria (Given-When-Then)
7. Проверьте по чек-листу (Часть 15)

Если вы — аналитик, проводящий ревью:

1. Беглый взгляд на текст — найдите «должна быть обеспечена возможность» → отклонить
2. Найдите «быстро», «удобно», «надёжно» без метрик → запросить метрики
3. Проверьте атомарность: есть ли «и/or/также» внутри требования → split
4. Проверьте исключения: описан ли not-found? error? timeout?
5. Есть ли NFR? Хотя бы производительность и доступность?
6. Есть ли AC? Given-When-Then?
7. Трассируется ли до бизнес-цели?

Если вам нужно объяснить менеджеру, зачем это всё:

«Хорошие требования — это контракт. Они исключают двусмысленность, снижают риск переделок и дают чёткие критерии приёмки. Ошибка на этапе требований обходится в 10–100 раз дороже, чем ошибка на этапе разработки. Каждый час, потраченный на качественные требования, экономит 5–10 часов на переделках.» (IBM / Standish Report)

Финальная нота:

Требования — это не бюрократия. Это единственный способ убедиться, что все участники проекта — бизнес, аналитики, разработчики, тестировщики — говорят на одном языке и понимают под одними и теми же словами одно и то же. Хорошее требование — атомарное, однозначное, измеримое, трассируемое и проверяемое. Всё остальное — пожелания.

Что дальше

• Собеседование системного аналитика: полный гайд — карта компетенций, вопросы по темам, типичные ошибки, чек-лист подготовки
• Гайд по написанию Use Cases — структура, примеры, лучшие практики
• Как писать ТЗ: шаблоны, ГОСТы, этапы — практическое руководство по техническому заданию
• Информационная архитектура — моделирование данных, MDM, Data Governance
• System Design — проектирование систем с учётом данных и хранилищ