Системный и бизнес-анализ: кто такой аналитик и что он реально делает

Аналитик — не «писатель ТЗ», не курьер между бизнесом и разработкой и не «человек, который рисует схемы в Miro». Роль существует ради одной вещи:

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

Всё остальное — интервью, BPMN, ERD, спецификации, критерии приёмки — инструменты под эту цель. Если инструмент её не приближает, он превращается в ритуал: документ, который никто не читает, и схема, которую никто не сверяет с кодом.

Эта статья — вход в трек. Разберём проблему с первых принципов, посмотрим на реальные артефакты (хорошая и плохая user story, use case, схема процесса, модель данных, контракт API), отдельно разберём четыре класса поломок, которые встречаются в 90% проектов, и договоримся, где нужен формальный документ, а где хватит разговора и схемы на доске.

1. Проблема: два человека знают половину каждый

1.1. Разрыв, который никто не закрывает по умолчанию

Заказчик знает предметную область — как реально устроен склад, почему бухгалтерия отказывается принимать возврат без акта, что означает статус «в пути (частично)». Но он не знает, что можно построить, во что это обойдётся и какие вопросы разработчик задаст на третий день.

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

Между ними — разрыв. Он не закрывается сам: каждая сторона считает свою половину очевидной. Аналитик — это функция, которая делает неявное знание явным и проверяемым. Отсюда следует практическое определение:

Требование — проверяемое утверждение о поведении или свойстве системы, привязанное к чьей-то задаче и имеющее владельца, который может подтвердить или опровергнуть его выполнение.

Три части одинаково важны. Нет проверяемости — нельзя сдать работу. Нет привязки к задаче — нечем защищать при урезании скоупа. Нет владельца — некому разрешить противоречие.

1.2. Почему ошибка в требованиях дороже ошибки в коде

Популярный график «стоимость исправления растёт в 10 раз на каждой фазе» восходит к Барри Боэму («Software Engineering Economics», 1981) и с тех пор бесконечно перерисовывается. Относиться к точным цифрам стоит скептически: Лоран Боссави в «The Leprechauns of Software Engineering» показывает, что многие такие «законы» — цепочка пересказов с потерянными исходными данными. Знаменитый отчёт NIST/RTI 2002 года об экономике дефектов ПО и цифры Standish CHAOS тоже подвергались серьёзной методологической критике — см. Eveleens & Verhoef, «The Rise and Fall of the Chaos Report Figures», IEEE Software, 2010.

Но механизм-то верный, и он не требует веры в конкретный множитель. Дефект требования дорожает не мистически, а потому что на нём успевают построить решения. Неверно понятое «возврат оформляется на заказ» вместо «на позицию заказа» к моменту обнаружения уже зашито в:

• схему БД (одна строка возврата на заказ — нет места для частичного);
• контракт API со складом (в запросе нет массива позиций);
• UI (нет чекбоксов у товаров);
• отчётность бухгалтерии и уже проведённые проводки;
• данные в проде, которые придётся мигрировать, угадывая, что имел в виду оператор.

Цена = не «переписать функцию», а «переделать пять решений и мигрировать историю». Именно поэтому дешёвый вопрос «возврат бывает частичным?» на этапе анализа стоит две минуты, а через полгода — две недели. Вся профессия построена на этой асимметрии.

1.3. Чем аналитик не является

2. Что аналитик делает физически: рабочий цикл

Разложим работу не по должностным инструкциям, а по действиям. Любая задача проходит один и тот же цикл, и на каждом шаге у аналитика есть конкретный выход.

Ключевое, что видно на схеме: валидация и приёмка возвращают в анализ. Аналитик, у которого поток строго линейный («написал — отдал — забыл»), не аналитик, а транспорт. Дыры находятся именно на обратных дугах, и цель — находить их как можно левее.

Как это выглядит в календаре типичной недели (не идеальной, а реальной):

Если письменная работа съедает 60% — вы почти наверняка пишете документы, которые не влияют на решения. Если разговоры съедают 70% — вы не фиксируете договорённости и одни и те же вопросы приходят по третьему кругу.

3. BA, SA, PO, PM: где границы

Названия ролей в разных компаниях означают разное — это нормально, но обсуждать надо явно. Полезно разделять по предмету работы, а не по титулу.

На практике комбинации любые: «системный аналитик», который пишет и BPMN, и OpenAPI; «бизнес- аналитик», который заодно PO. Про продуктовую и проектную стороны подробно — в треках Product management и Project management; материал «Требования» в треке архитектуры смотрит на ту же тему со стороны решения. Здесь мы занимаемся именно требованиями и моделями.

Что стоит выяснить на собеседовании или в первый день (эти четыре вопроса определяют вашу работу сильнее, чем название должности):

1. Кто пишет критерии приёмки и кто их подписывает?
2. Кто решает приоритет, если два стейкхолдера хотят разного?
3. Где живёт актуальная версия требований и кто её обновляет после изменений в проде?
4. Аналитик участвует в приёмке или узнаёт о результате из релиз-ноутов?

4. Практика: user story, которая работает

4.1. Плохо и хорошо

Типичная история из реального бэклога:

Название: Возвраты
Описание: Реализовать функционал возвратов согласно требованиям бизнеса.
Нужно сделать удобно и быстро.

Здесь нет ничего: ни роли, ни задачи, ни границ, ни способа проверить. Разработчик спросит «а что делать, если товар уценённый?» — и узнает ответ через две недели, уже переписав код.

То же самое, приведённое в рабочий вид:

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

Ценность: 62% обращений в поддержку по возвратам — это «как оформить»;
цель — снять их из очереди оператора.

В скоупе:  оформление заявки, выбор позиций и количества, причина возврата,
           печать этикетки, отслеживание статуса.
Вне скоупа: обмен товара, возврат без чека, самовывоз в ПВЗ (отдельная история 
           https://courses.digitable.life/post/systems-analysis/03-documentation/ — там же разберём шаблон целиком).

Обратите внимание на две редкие, но критичные части: «Вне скоупа» и «Ценность». Первая экономит недели споров, вторая позволяет отрезать историю, когда бюджет кончился, и понимать, что именно вы теряете.

4.2. Критерии приёмки: место, где история становится проверяемой

Критерии — это не пересказ описания, а набор конкретных проверок. Удобный формат — Given/When/Then из Gherkin (документация Cucumber); подход в целом описан у Гойко Аджича в «Specification by Example».

Функция: Оформление возврата покупателем

  Сценарий: Возврат части позиций в пределах срока
    Дано заказ 10045 доставлен 2026-07-10, в нём 3 позиции
    И текущая дата 2026-07-20
    Когда покупатель выбирает позицию "Кроссовки, 42" и указывает причину "не подошёл размер"
    Тогда создаётся заявка на возврат со статусом "Оформлена"
    И покупателю доступна PDF-этикетка для отправки
    И остальные 2 позиции остаются в статусе "Доставлен"

  Сценарий: Срок возврата истёк
    Дано заказ 10045 доставлен 2026-07-10
    И текущая дата 2026-07-26
    Когда покупатель открывает страницу заказа
    Тогда кнопка "Оформить возврат" недоступна
    И отображается текст "Срок возврата истёк 2026-07-24"

  Сценарий: Товар из перечня невозвратных
    Дано в заказе есть позиция категории "Парфюмерия" со снятой упаковкой
    Когда покупатель пытается добавить её в заявку
    Тогда позиция помечена как невозвратная со ссылкой на основание

Проверка качества критериев на глаз: можно ли по ним написать автотест, не задавая ни одного вопроса? Если нельзя — это не критерий, а пожелание. Подробнее про связь критериев и тестов — в треке тестирования.

4.3. INVEST как чек-лист, а не как мантра

Аббревиатуру предложил Билл Уэйк (INVEST in Good Stories), подробно разобрана у Майка Кона в «User Stories Applied».

5. Практика: use case, когда истории не хватает

User story намеренно короткая — это «напоминание о разговоре». Когда сценарий длинный, ветвистый и регламентированный (банковская операция, страховой случай, гособмен), нужна форма, где явно перечислены основной поток, альтернативы и исключения. Классика жанра — Алистер Кокбёрн, «Writing Effective Use Cases».

UC-07. Оформление возврата покупателем

Основной актор:      Покупатель
Заинтересованные:    Оператор поддержки (меньше обращений), Бухгалтерия (корректные проводки),
                     Склад (предсказуемый поток приёмки)
Уровень:             пользовательская задача (sea level)
Предусловия:         покупатель аутентифицирован; заказ в статусе «Доставлен»
Гарантия минимума:   заявка либо создана целиком, либо не создана; черновик не теряется
Гарантия успеха:     заявка зарегистрирована, покупателю выдана этикетка,
                     склад уведомлён, срок возврата денег зафиксирован

Основной поток:
  1. Покупатель открывает заказ и выбирает «Оформить возврат».
  2. Система показывает позиции, доступные к возврату, с остатком количества.
  3. Покупатель отмечает позиции, количество и причину.
  4. Система проверяет правила BR-03 (срок), BR-07 (невозвратные категории), BR-11 (лимит).
  5. Система создаёт заявку, резервирует ожидаемое поступление на складе.
  6. Система выдаёт этикетку и показывает срок возврата денег.

Альтернативные потоки:
  3a. Покупатель возвращает весь заказ  → шаг 4 выполняется для всех позиций.
  4a. Часть позиций не проходит BR-07  → система создаёт заявку на прошедшие позиции
      и показывает список отклонённых с основанием.
  6a. Склад недоступен (таймаут)       → заявка создаётся в статусе «Ожидает подтверждения»,
      уведомление склада уходит асинхронно, покупателю показывается этикетка.

Исключения:
  E1. Заказ уже имеет активную заявку на те же позиции → отказ, ссылка на существующую заявку.
  E2. Оплата не подтверждена (заказ в рассрочке)       → эскалация оператору, ручной режим.

Частота:  ~1200/сут в пике распродаж
Открытые вопросы:  кто платит доставку при возврате по браку? (владелец: коммерческий директор)

Три вещи, которые делают use case полезным, а не бумажным:

1. Явные исключения. 80% дыр в требованиях живут в ветках «а если нет».
2. Ссылки на бизнес-правила по номерам (BR-03). Правило меняется отдельно от сценария и часто используется в пяти местах — дублировать текст правила смертельно.
3. Секция открытых вопросов с владельцем и сроком. Это единственный честный способ показать, что решение ещё не принято, и не дать «неизвестности» тихо просочиться в код.

Подробный разбор форматов — в «Документирование», а про UML-нотацию и её чтение разработчиками — в «UML для аналитика».

6. Практика: процесс, а не только функция

Функциональная постановка отвечает на «что делает система». Процессная — на «как работают люди вокруг системы», и именно там обычно находится настоящая проблема. Схема ниже — упрощённая модель процесса возврата с дорожками (в BPMN — пулы и лейны).

Что эта схема ловит такого, чего не поймает список функций:

• Дорожка «Финансы» существует. Значит, есть срок «до 10 дней» — и его надо где-то показывать покупателю, иначе поддержка получит новый поток обращений вместо старого.
• Есть ветка расхождения (S5 → S7). Это отдельный интерфейс оператора, о котором в исходной постановке «сделать возвраты» не было ни слова, — а это недели работы.
• Между B2 и W1 живёт внешний мир: посылка идёт неделю, может потеряться. Отсюда требование о таймауте заявки и о статусе «В пути», которого не было в первой версии.

Формальную нотацию BPMN 2.0 (типы событий, шлюзы, сообщения, что означают жирные границы задач) и типичные ошибки схем разбираем в «Моделирование процессов»; официальная спецификация — OMG BPMN 2.0, лучший практический источник по стилю — Брюс Сильвер, «BPMN Method and Style».

7. Практика: жизненный цикл и матрица состояний

Самый дешёвый способ найти неявные требования — нарисовать состояния объекта и честно ответить, что происходит на каждом событии в каждом состоянии.

Теперь превращаем диаграмму в матрицу состояние × событие — таблицу, где каждая пустая клетка это вопрос, который никто не задал:

Три вопросительных знака в таблице — это три требования, которых нет в постановке, и три спора на приёмке, которых можно избежать за десять минут. Приём работает на любом объекте с состояниями: заказ, договор, заявка, аккаунт, платёж.

8. Практика: модель данных

Одно и то же слово в разговоре означает разные сущности, и это выясняется поздно. «Клиент» — это физлицо, аккаунт или плательщик? Модель данных — самый безжалостный инструмент против такой неоднозначности: в ней нельзя написать расплывчато.

Даже такая маленькая модель уже фиксирует четыре решения, каждое из которых было спорным:

• RETURN_ITEM.quantity — значит, частичный возврат количества возможен. Одно поле убивает многодневный спор.
• deadline_at хранится как значение, а не вычисляется каждый раз: правило «14 дней» изменится, а старые заявки должны жить по старому правилу. Это классическое требование-невидимка.
• refund_amount на позиции, а не на заявке: иначе не разложить скидку по корзине.
• RETURN_REQUEST ||--o| REFUND — ноль или один возврат денег. Если бизнес скажет «бывает двумя платежами», связь станет ||--o{, и это изменит и API, и отчётность.

Сопровождать модель обязан словарь данных: имя, тип, обязательность, источник истины, правило заполнения, пример.

-- Фрагмент, который аналитик отдаёт разработчику и бухгалтерии одновременно.
-- Комментарии здесь — часть требования, а не украшение.
CREATE TABLE return_request (
    id              uuid PRIMARY KEY,
    order_id        uuid NOT NULL REFERENCES "order"(id),
    status          text NOT NULL CHECK (status IN (
                        'draft','submitted','in_transit','received',
                        'discrepancy','refunded','rejected','expired')),
    created_at      timestamptz NOT NULL,           -- момент подтверждения, не создания черновика
    deadline_at     timestamptz NOT NULL,           -- снимок правила BR-03 на момент создания
    tracking_number text,                           -- NULL допустим до отправки посылки
    CONSTRAINT deadline_after_created CHECK (deadline_at > created_at)
);

Детали — сущности, ключи, нормализация, историчность — в «Моделирование данных»; фундамент реляционной модели — в треке баз данных. Если проект живёт в терминах домена, полезно посмотреть на event storming как на способ собрать процесс, события и сущности за один воркшоп.

9. Практика: контракт интеграции

Как только в сценарии появляется вторая система, требование превращается в контракт: формат, коды ошибок, поведение при отказе. Половина продакшн-инцидентов рождается не в бизнес-логике, а в фразе «ну там просто дёрнем их API».

# Фрагмент OpenAPI: создание заявки на возврат.
# Аналитик отвечает не за YAML как таковой, а за то, что в нём зафиксированы
# ВСЕ решения — включая поведение при повторе и при отказе смежной системы.
paths:
  /v1/returns:
    post:
      summary: Создать заявку на возврат
      parameters:
        - name: Idempotency-Key
          in: header
          required: true
          schema: { type: string, format: uuid }
          description: >
            Повтор с тем же ключом в течение 24 часов возвращает исходный результат
            и НЕ создаёт вторую заявку. Разные ключи с одинаковым телом — две заявки.            
      requestBody:
        required: true
        content:
          application/json:
            schema:
              type: object
              required: [orderId, items]
              properties:
                orderId: { type: string, format: uuid }
                items:
                  type: array
                  minItems: 1
                  items:
                    type: object
                    required: [orderItemId, quantity, reasonCode]
                    properties:
                      orderItemId: { type: string, format: uuid }
                      quantity:    { type: integer, minimum: 1 }
                      reasonCode:  { type: string, enum: [SIZE, DEFECT, NOT_AS_DESCRIBED, OTHER] }
                      comment:     { type: string, maxLength: 500 }
      responses:
        '201':
          description: Заявка создана
        '409':
          description: |
            Конфликт: по этим позициям уже есть активная заявка.
            Тело содержит returnRequestId существующей заявки.            
        '422':
          description: |
            Бизнес-правило не выполнено. Код в поле `code`:
            RETURN_PERIOD_EXPIRED | ITEM_NOT_RETURNABLE | QUANTITY_EXCEEDS_ORDER            
        '503':
          description: Склад недоступен. Клиенту следует повторить с тем же Idempotency-Key.

Обмен во времени лучше показывать последовательностью — здесь видно то, что не видно в схеме данных: кто кого ждёт, где таймаут и что происходит при отказе.

Вопросы, которые аналитик обязан задать по любой интеграции (и записать ответы в спецификацию):

1. Синхронно или асинхронно? Что показываем пользователю, пока ответа нет.
2. Что при таймауте? Ретраить можно, только если операция идемпотентна, — отсюда Idempotency-Key в контракте выше.
3. Кто источник истины по каждому полю? Если и мы, и склад считаем количество — будет расхождение, вопрос лишь когда.
4. Как выглядят ошибки? Строка «Ошибка сервера» на UI = поток обращений в поддержку.
5. Версионирование и совместимость: что произойдёт с нашим кодом, когда партнёр добавит поле или сменит enum.
6. Объёмы и лимиты: rps, размер батча, квоты. Это уже нефункциональные требования.

Разбор форматов, стилей API, схем ошибок и сценариев обмена — в «Анализ интеграций и API»; со стороны проверки полезен раздел про тестирование API.

10. Что ломается чаще всего

Четыре класса проблем, дающих львиную долю переделок. Их стоит уметь опознавать по формулировкам.

10.1. Неявные требования

Это знание, которое для носителя настолько очевидно, что не проговаривается. «Ну естественно, возврат нельзя оформить на заказ, оплаченный сертификатом». Опасность в том, что нет ни фразы, ни строки в документе, к которой можно придраться, — есть тишина.

Приёмы обнаружения:

• Матрица состояние × событие (раздел 7) — заставляет заполнить каждую клетку.
• Вопрос «а что, если нет?» к каждому шагу: не пришло, не совпало, не хватило, отменили.
• Наблюдение вместо интервью. Люди описывают идеальный процесс, а делают реальный — с бумажкой на мониторе и Excel-файлом «истинные остатки». Об этом — в «Выявление требований».
• Разбор реальных данных. Один SQL-запрос «сколько заказов имеет больше одного плательщика» убивает часовой спор о том, бывает ли такое вообще.
• Крайние значения. Ноль, один, много, максимум, отрицательное, вчера, 29 февраля, ночь перехода на летнее время, две валюты, отсутствующий адрес.

10.2. Противоречия между стейкхолдерами

Классика: коммерция хочет возврат «в один клик», финансы — обязательный акт и подпись, склад — предварительную заявку, юристы — хранение оснований пять лет. Каждый по-своему прав.

Что делает начинающий аналитик: пытается угодить всем и приносит требование-химеру, которое разваливается на первой же реализации. Что делает опытный:

1. Формулирует противоречие явно и письменно, в терминах интересов, а не позиций: «Финансы требуют подтверждённое основание до возврата денег; коммерция требует возврат денег в течение часа. Одновременно невозможно».
2. Ищет решение, снимающее конфликт, а не компромисс по середине: например, авто-подтверждение для сумм до 5000 и ручное — выше. Часто конфликт исчезает при уточнении границ.
3. Если решения нет — эскалирует с готовыми вариантами и ценой каждого. Не «решите как-нибудь», а «вариант А: −2 дня к сроку возврата, +1 FTE оператора; вариант Б: риск 1,2 млн в год по невозвратным товарам. Нужно ваше решение до пятницы».
4. Фиксирует решение и владельца там, где его найдут через полгода.

Отдельная статья трека — «Работа со стейкхолдерами». Про приоритизацию в условиях конфликта — в Product management.

10.3. «Хотелки» без задачи

Признак — требование сформулировано как решение, без проблемы за ним: «нужна кнопка экспорта в Excel на странице возвратов». Проблема может быть настоящей (руководителю нужен еженедельный отчёт по причинам возвратов), но предложенное решение — худшее из возможных.

Скальпель — короткая цепочка вопросов:

— Нужна кнопка экспорта в Excel.
— Что вы будете делать с файлом? — Строить сводную по причинам возвратов.
— Как часто? — Каждый понедельник, к планёрке.
— А сейчас как? — Прошу выгрузку у аналитика, жду до среды.
— Что произойдёт, если этого не будет? — Обсуждаем причины возвратов по памяти,
  решения принимаем с задержкой в неделю.

Настоящее требование: «руководителю категории нужен еженедельный отчёт по причинам возвратов к утру понедельника, самостоятельно». Решений минимум три: экспорт, готовый дашборд, письмо по расписанию. Второе и третье дешевле и лучше решают задачу — но их не было в запросе.

Формальные техники того же: «5 почему», impact mapping (Гойко Аджич, impactmapping.org), job story в формате «когда … я хочу … чтобы …». Важно не превратить это в допрос: цель — не поймать заказчика, а найти задачу.

10.4. Требования, которые невозможно проверить

Самый частый и самый дорогой класс: формулировка выглядит как требование, но не даёт способа сказать «сделано» или «не сделано».

Приём Тома Гилба (Planguage): у каждого нефункционального требования должны быть шкала, способ измерения, целевое значение и минимально допустимое. Тогда вместо спора «быстро или не быстро» получается измерение. Подробно — в «Нефункциональные требования».

Маленький практический инструмент — линтер расплывчатых формулировок. Он не заменяет ревью, но ловит львиную долю «удобно/быстро/оптимально» до того, как текст уйдёт в работу.

"""Простейший линтер требований: ищет расплывчатые формулировки и пассивные обязательства.
Сложность: O(n * m) по времени (n — длина текста, m — число паттернов), O(k) по памяти,
где k — число найденных замечаний. На объёмах реальных спецификаций это микросекунды."""
import re

WEASEL = {
    r"\bбыстр\w*": "нет метрики: укажите перцентиль, значение и нагрузку",
    r"\bудобн\w*": "не проверяемо: замените на измеримый критерий или тест юзабилити",
    r"\bоптимальн\w*": "оптимально по какому критерию и при каком ограничении?",
    r"\bи т\.?\s?д\.?|\bи др\.?|\bи прочее": "незакрытый перечень — источник спора на приёмке",
    r"\bпо необходимости\b|\bпри необходимости\b": "кто и по какому правилу решает?",
    r"\bдолжн\w+ поддерживать\b": "сколько, в каких единицах, при каких условиях?",
    r"\bминимальн\w*|\bмаксимальн\w*": "укажите число, а не превосходную степень",
    r"\bи/или\b": "неоднозначность: разделите на два требования",
}

def lint(text: str) -> list[tuple[int, str, str]]:
    """Возвращает список (номер строки, найденный фрагмент, объяснение)."""
    issues = []
    for lineno, line in enumerate(text.splitlines(), start=1):
        for pattern, why in WEASEL.items():
            for m in re.finditer(pattern, line, flags=re.IGNORECASE):
                issues.append((lineno, m.group(0), why))
    return issues

if __name__ == "__main__":
    spec = """Система должна быстро обрабатывать заявки на возврат.
    Оператору доступны фильтры по дате, статусу и т.д.
    Интерфейс должен быть удобным и поддерживать большое количество заявок."""
    for lineno, frag, why in lint(spec):
        print(f"строка {lineno}: «{frag}» — {why}")

11. Документ или разговор: как выбирать формальность

Главный источник профессионального выгорания аналитика — писать документы, которые никто не читает. Главный источник производственных провалов — договариваться на словах о том, что стоит миллионы. Ответ не в «всегда документируй» и не в «Agile отменил документацию», а в оценке.

Практическое правило: выбирай минимальную формальность, при которой цена ошибки всё ещё меньше цены документа. Оценивать по четырём факторам:

Конкретно:

• Хватит разговора и фото доски: порядок полей в форме, цвет статуса, поведение сортировки, внутренняя фича одной команды с обратимым решением.
• Нужны user story + критерии приёмки: любая работа, которую будут принимать, то есть практически всё, что попадает в спринт.
• Нужен use case или модель процесса: больше трёх альтернативных веток, несколько ролей, регламент, ручные шаги вне системы.
• Нужна полноценная спецификация: внешние интеграции, миграции данных, расчёты денег, безопасность, всё, что попадёт в аудит или в суд.
• Нужен документ с подписью: обязательства перед подрядчиком или заказчиком по договору, требования регулятора, SLA.

И симметричное правило: документ живёт ровно столько, сколько влияет на решения. Спецификация, которую перестали обновлять, вреднее её отсутствия — по ней принимают решения, считая актуальной. Если поддерживать нечем, честнее пометить «устарело, источник истины — код и тесты».

12. Как понять, что аналитик работает хорошо

Считать страницы документации бессмысленно — это метрика выхода, а не результата. Осмысленные сигналы (собираются из трекера почти без усилий):

Важная оговорка: все эти метрики легко испортить, если сделать их целью (закон Гудхарта). Задача уточнений — не «уменьшить до нуля»: ноль уточнений означает либо избыточно детальные спецификации, либо что команда молча додумывает. Здоровое состояние — вопросы есть, они задаются рано и закрываются быстро. Инженерные метрики потока разбираются в Project management.

13. Карта трека

• 01. Выявление требований — интервью, наблюдение, воркшопы, работа с документами и данными.
• 02. Виды требований — бизнес, пользовательские, функциональные, нефункциональные, ограничения и правила.
• 03. Документирование — user story, use case, спецификация, критерии приёмки.
• 04. UML для аналитика — какие диаграммы полезны и как их читают разработчики.
• 05. Моделирование процессов — BPMN, нотации, типичные ошибки в схемах.
• 06. Моделирование данных — сущности, связи, ERD, словарь данных.
• 07. Анализ интеграций и API — контракты, форматы, сценарии обмена, ошибки.
• 08. Нефункциональные требования — производительность, надёжность, безопасность и как их измерять.
• 09. Прототипирование — проверка гипотез до разработки.
• 10. Работа со стейкхолдерами — конфликты интересов, приоритеты, согласования.
• 11. Аналитик в Agile — груминг, декомпозиция, работа с неопределённостью.
• 12. Приёмка — как проверить, что сделали именно то.
• 13. Инструменты и карьера — грейды, специализации, что учить дальше.

14. Мини-итог

• Аналитик существует, чтобы сокращать неопределённость до уровня, на котором решение можно принять и проверить. Документы — побочный продукт, а не цель.
• Требование = проверяемое утверждение + привязка к задаче + владелец. Нет одной из трёх частей — это ещё не требование.
• Ошибка в требованиях дорожает потому, что на ней успевают построить схему БД, контракты, UI и данные в проде. Отсюда вся экономика профессии.
• Диаграммы — рабочий инструмент поиска дыр: состояния ловят пропущенные события, процесс — пропущенные роли и ручные шаги, ERD — неоднозначность терминов, последовательность — таймауты и отказы.
• Четыре главные поломки: неявные требования, противоречия стейкхолдеров, «хотелки» без задачи, непроверяемые формулировки. Для каждой есть конкретный приём, а не «быть внимательнее».
• Формальность выбирается по цене ошибки, числу сторон и сроку жизни решения — от разговора у доски до документа с подписью.

Источники

• ISO/IEC/IEEE 29148:2018, Requirements engineering — iso.org/standard/72089.html (характеристики хорошего требования: необходимое, однозначное, полное, единичное, реализуемое, проверяемое, трассируемое).
• IIBA, BABOK Guide v3 — iiba.org.
• Karl Wiegers, Joy Beatty. Software Requirements, 3rd ed. — karlwiegers.com.
• Suzanne & James Robertson. Mastering the Requirements Process; шаблон Volere — volere.org.
• Alistair Cockburn. Writing Effective Use Cases — alistair.cockburn.us.
• Mike Cohn. User Stories Applied — mountaingoatsoftware.com; Bill Wake, INVEST — xp123.com.
• Jeff Patton. User Story Mapping — jpattonassociates.com.
• Gojko Adzic. Specification by Example — gojko.net; Impact Mapping — impactmapping.org.
• OMG BPMN 2.0 — omg.org/spec/BPMN/2.0.2; OMG UML — omg.org/spec/UML.
• OpenAPI Specification — spec.openapis.org/oas/latest.html; RFC 2119 о значении MUST/SHOULD/MAY — rfc-editor.org/rfc/rfc2119.
• Laurent Bossavit. The Leprechauns of Software Engineering — leanpub.com/leprechauns (о том, как проверять индустриальные «законы» вроде кривой стоимости дефекта).

Что дальше

Мы договорились, зачем нужна роль и как выглядят её артефакты. Дальше — самая недооценённая часть работы: как вообще добыть требования из людей, документов и данных, если никто не может связно сказать, чего хочет.

Выявление требований: интервью, наблюдение, воркшопы, работа с документами