Бизнес-анализ в разработке программного обеспечения

Роль бизнес-анализа в жизненном цикле разработки ПО

Бизнес-анализ в разработке программного обеспечения (ПО) — это работа по выявлению реальных потребностей бизнеса и пользователей, формулированию требований к будущему продукту и обеспечению общего понимания между заинтересованными сторонами (заказчиками, пользователями, разработчиками, тестированщиками, руководителями).

Главная ценность бизнес-анализа в том, что он снижает риск сделать не то (или сделать то, но не так), помогает принимать обоснованные решения и повышает вероятность того, что продукт принесёт ожидаемую пользу.

> Working software over comprehensive documentation — один из ключевых принципов Agile, который часто неверно трактуют как отказ от требований. На практике он означает приоритет результата, но не отменяет необходимость ясного общего понимания. Источник: Agile Manifesto

Жизненный цикл разработки ПО и место бизнес-анализа

Жизненный цикл разработки ПО (часто говорят SDLC — Software Development Life Cycle) — это последовательность этапов, через которые проходит продукт от идеи до поддержки в эксплуатации.

Независимо от выбранного подхода (каскадная модель, итеративная разработка, Agile), бизнес-анализ присутствует на всём протяжении жизненного цикла, но интенсивность и форма артефактов меняются.

!Цикл SDLC и точки участия бизнес-аналитика

Кто такой бизнес-аналитик в разработке ПО

Бизнес-аналитик (БА) — специалист, который помогает команде:

понять проблему и цели бизнеса

определить, какой результат должен быть достигнут

перевести потребности в требования, понятные для реализации и проверки

согласовать ожидания и договориться о критериях успешности

Важно отличать бизнес-аналитика от смежных ролей:

Product Manager чаще отвечает за стратегию продукта, рынок, P&L и приоритизацию на уровне бизнеса

Product Owner в Agile обычно управляет бэклогом и максимизацией ценности продукта

System Analyst чаще фокусируется на технических требованиях, интеграциях, данных и ограничениях системы

В реальных компаниях роли могут пересекаться, но функция бизнес-анализа (смысл и задачи) остаётся.

Что именно делает бизнес-анализ на этапах SDLC

Ниже — типичная картина участия бизнес-аналитика по этапам. Этапы могут называться иначе, но смысл остаётся.

| Этап жизненного цикла | Цель этапа | Роль бизнес-анализа | Типичные результаты (артефакты) | |---|---|---|---| | Идея и инициирование | Понять, зачем нужен продукт/изменение | Уточняет проблему, цели, заинтересованных лиц, ограничения | Описание проблемы, цели, границы, список стейкхолдеров | | Исследование (discovery) | Проверить гипотезы и ценность | Собирает потребности, исследует процессы, выявляет боли | Карта текущего процесса (as-is), гипотезы, риски | | Формирование требований | Согласовать, что нужно сделать | Описывает требования, устраняет неоднозначности | Пользовательские истории, сценарии, бизнес-правила, критерии приемки | | Проектирование решения | Спроектировать, как это будет работать | Уточняет требования, помогает выбрать вариант, выявляет исключения | Прототипы, описания экранов, модели данных на уровне понимания | | Разработка | Реализовать функциональность | Поддерживает команду, отвечает на вопросы, управляет изменениями | Уточнения требований, решения по спорным кейсам | | Тестирование и приемка | Доказать соответствие ожиданиям | Помогает формировать критерии и сценарии, участвует в приемке | Критерии приемки, уточнения по дефектам, чек-листы | | Внедрение и поддержка | Запустить и улучшать | Собирает обратную связь, оценивает эффект, инициирует улучшения | Список улучшений, анализ метрик, обновление требований |

Ключевые активности бизнес-анализа

Работа со стейкхолдерами

Стейкхолдеры — это люди или группы, на которых влияет продукт или которые влияют на продукт.

Задачи бизнес-аналитика:

выявить всех важных стейкхолдеров

понять их интересы и ожидания

организовать коммуникацию так, чтобы решения принимались вовремя

Типичные инструменты:

интервью

воркшопы (совместные сессии обсуждения)

наблюдение за работой пользователей

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

Выявление и формализация требований

Требование — это проверяемое описание того, что должно быть реализовано или соблюдено.

Чтобы требования были полезны команде, они должны быть:

понятными (без двусмысленностей)

проверяемыми (можно определить, выполнено или нет)

согласованными (не противоречат друг другу)

актуальными (соответствуют текущим целям)

На практике бизнес-аналитик часто использует сочетание форматов:

пользовательские истории (user stories)

сценарии использования (use cases)

бизнес-правила (например, условия расчёта скидок)

критерии приемки (условия, при которых работа считается принятой)

Управление изменениями требований

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

Роль бизнес-аналитика — сделать изменения управляемыми:

фиксировать запрос на изменение

оценивать влияние (на сроки, стоимость, риски, архитектуру, тестирование)

помогать принять решение: внедряем сейчас, позже или отклоняем

обновлять требования и поддерживать их согласованность

Поддержка качества: связь требований и тестирования

Качество повышается, когда от требований можно перейти к проверкам.

Практика, которая помогает команде:

формулировать критерии приемки вместе с командой

связывать требования со сценариями тестирования

заранее проговаривать пограничные случаи и исключения

Бизнес-анализ в Agile и в каскадной модели

Подход к разработке влияет на то, когда и как описываются требования.

Если используется каскадная модель

Обычно требования стараются максимально детализировать заранее, чтобы затем последовательно пройти проектирование, разработку и тестирование.

Плюсы для бизнеса:

проще согласовать объём работ на старте

легче фиксировать бюджет и сроки

Риски:

изменения в ходе проекта стоят дороже

часть требований может устареть к моменту релиза

Если используется Agile

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

Плюсы:

быстрее получаем работающий результат

легче адаптироваться к изменениям

Риски:

при слабой дисциплине анализа возможны разночтения и «плавающий» объём

без ясных критериев приемки команда может по-разному понимать “готово”

Роль бизнес-аналитика в Agile часто выражается через:

подготовку и уточнение бэклога (списка работ)

проработку требований на ближайшие итерации

фасилитацию обсуждений и снятие неоднозначностей

Типичные ошибки, которые предотвращает сильный бизнес-анализ

Решение разрабатывается без ясной бизнес-цели

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

Требования непроверяемы (нет критериев приемки)

Разные стейкхолдеры ожидают разный результат, конфликт всплывает поздно

Изменения вносятся хаотично, и продукт становится несогласованным

Минимальный набор артефактов, который полезен почти всегда

Ниже — практичный набор документов/описаний, который можно адаптировать под размер проекта.

цели и метрики успеха (как поймём, что стало лучше)

границы решения (что входит и что не входит)

ключевые пользовательские сценарии

приоритизированный список требований

критерии приемки для важных требований

список открытых вопросов и принятых решений

Итоги

Бизнес-анализ — это не “документация ради документации”, а функция управления пониманием: от целей бизнеса до проверяемых требований и согласованных решений. В жизненном цикле разработки ПО бизнес-анализ связывает стратегию и реальную разработку, помогает снижать риски, управлять изменениями и повышать ценность результата.

Стейкхолдеры, цели продукта и границы проекта

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

Кто заинтересован в изменении и влияет на него (стейкхолдеры)

Зачем мы делаем продукт или изменение (цели)

Что именно входит в работу, а что точно не входит (границы проекта и решения)

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

Стейкхолдеры

Кто такой стейкхолдер

Стейкхолдер — это человек или группа людей, которые:

получают пользу или ущерб от результата

участвуют в принятии решений

влияют на ресурсы, сроки, приоритеты

будут пользоваться системой или поддерживать её

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

Зачем выявлять стейкхолдеров рано

Раннее выявление стейкхолдеров снижает типовые риски:

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

появляются неожиданные ограничения (например, по персональным данным)

продукт формально готов, но не принят, потому что критерии успеха у разных сторон разные

Типы стейкхолдеров в разработке ПО

Полезно разделять стейкхолдеров по роли в изменении:

Спонсор: дает бюджет и ожидает бизнес-эффект

Заказчик: формулирует запрос и принимает результат

Пользователи: выполняют задачи в системе

Владельцы процессов: отвечают за операционную эффективность

Эксперты по предметной области: знают правила и исключения

Смежные ИТ-команды: интеграции, инфраструктура, безопасность

Поддержка и обучение: будут жить с результатом после релиза

Регуляторы и комплаенс: задают обязательные требования

Как находить стейкхолдеров

Рабочие источники для поиска:

оргструктура и матрица ответственности

карта бизнес-процесса (кто выполняет шаги, кто утверждает)

системы и интеграции (владельцы соседних систем)

документы и регламенты (кто их автор и владелец)

инциденты и обращения в поддержку (кто чаще всего сталкивается с проблемой)

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

Карта стейкхолдеров: влияние и интерес

Один из самых простых инструментов — матрица влияние–интерес. Она помогает понять, кому нужна плотная коммуникация, а кого достаточно информировать.

!Матрица помогает определить частоту и формат коммуникации с разными стейкхолдерами

Цели продукта: что значит «успех»

Цель продукта и требование — не одно и то же

Цель описывает зачем мы делаем изменение и какой эффект ожидаем

Требование описывает что система должна делать или какое условие соблюсти

Пример различия:

цель: сократить время обработки обращения клиента

требование: добавить в карточку обращения поле «Категория» и автоподстановку по тексту

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

Как формулировать цели так, чтобы ими можно было управлять

Хорошая цель:

понятна всем участникам

допускает проверку по факту

привязана к бизнес-проблеме

Популярный ориентир — SMART-критерии. Полезно помнить их смысл, но не превращать в бюрократию.

Specific: конкретная

Measurable: измеримая

Achievable: достижимая

Relevant: релевантная

Time-bound: ограниченная по времени

Источник: SMART criteria

Метрики и прокси-метрики

Иногда эффект нельзя измерить напрямую быстро. Тогда договариваются о прокси-метриках, которые отражают движение к цели.

Примеры:

цель: уменьшить потери выручки из-за ошибок в заказах

метрика эффекта: доля возвратов по причине неправильной комплектации

прокси-метрика: доля заказов, прошедших автоматическую проверку перед отправкой

Важно фиксировать кто смотрит метрику, где она считается и как часто.

Формат «цель как утверждение»

Практичный шаблон (можно использовать в документе инициирования или на discovery):

проблема: что сейчас не так

целевая аудитория: у кого боль

ожидаемый эффект: что улучшится

способ измерения: по чему поймем

срок: когда ожидаем увидеть эффект

Этот формат помогает удерживать разговор на уровне ценности, а не функций.

Границы проекта и границы решения

Почему границы важны

Границы отвечают на вопрос: что мы точно делаем в рамках этой инициативы, а что точно нет.

Если границы не зафиксированы, появляется:

скрытый рост объема работ

конфликты ожиданий между подразделениями

неуправляемые изменения, которые ломают сроки и бюджет

Это часто называют scope creep — расползание объема.

Два вида границ, которые стоит различать

Границы проекта: организационные рамки работ (сроки, бюджет, команды, этапы, что будет поставлено)

Границы решения (product scope): функциональные и пользовательские рамки (какие сценарии покрываем, какие системы трогаем, какие данные обрабатываем)

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

In scope / Out of scope

Самый понятный инструмент — два списка:

In scope: что входит в поставку

Out of scope: что осознанно исключили

Ключевое правило: out of scope — это не «никогда», а «не в этой итерации или проекте». Если тема важная, её стоит занести в бэклог улучшений или отдельную инициативу.

Контекстная диаграмма (границы системы)

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

!Контекстная диаграмма фиксирует границу решения и внешние взаимодействия

Допущения, ограничения и зависимости

Чтобы границы были реалистичными, рядом с ними фиксируют:

допущения: что считаем истинным, пока не доказано обратное

ограничения: что нельзя нарушать (регуляторика, технологии, сроки)

зависимости: от каких команд, поставок или решений мы зависим

Примеры:

допущение: пользователи будут иметь корпоративную учетную запись

ограничение: персональные данные нельзя передавать во внешние сервисы

зависимость: интеграция с CRM возможна только после обновления API у команды CRM

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

Ниже — минимальный практический комплект для старта, который хорошо стыкуется с тем, что мы обсуждали в теме про роль бизнес-анализа в SDLC:

список стейкхолдеров и формат коммуникации (кто принимает решения, кого консультируем)

1–3 цели продукта с метриками успеха

in scope / out of scope

контекстная диаграмма (если есть интеграции или несколько систем)

список допущений, ограничений, зависимостей

список открытых вопросов и принятых решений

Этот набор дает команде общее понимание еще до детальной проработки требований и снижает вероятность «сюрпризов» на разработке и приемке.

Частые ошибки и как их предотвратить

ошибка: стейкхолдеров ищут по должностям, а не по влиянию и участию в процессе

профилактика: искать через процесс и данные, проверять матрицей влияние–интерес

ошибка: цель формулируют как функциональность

профилактика: разделять цель и требования, фиксировать метрику успеха

ошибка: границы описаны общими словами

профилактика: явно перечислять in scope / out of scope и риски по зависимостям

ошибка: решения принимаются без «владельца»

профилактика: заранее договориться, кто принимает финальные решения по спорным вопросам

Итоги

Стейкхолдеры, цели продукта и границы проекта — это фундамент бизнес-анализа, который превращает «хотелки» в управляемую инициативу. Определив кто вовлечен, зачем мы делаем изменение и что именно входит в работу, вы создаете основу для качественных требований, предсказуемой разработки и приемки, а также для управляемых изменений на протяжении всего SDLC.

Источник принципа приоритета результата при сохранении общего понимания: Agile Manifesto

Сбор требований: интервью, воркшопы, наблюдение, анализ данных

В предыдущих темах курса мы разобрали роль бизнес-анализа в SDLC и то, как стейкхолдеры, цели и границы проекта задают рамку для будущих требований. Следующий практический шаг — сбор требований (часто говорят elicitation): получение информации от людей и из источников данных, чтобы понять потребности, правила, ограничения и ожидаемую ценность.

Важно различать:

Сбор требований: как мы получаем информацию (интервью, воркшоп, наблюдение, анализ данных).

Формализация требований: как мы фиксируем и делаем информацию проверяемой (user stories, сценарии, бизнес-правила, критерии приемки).

Один и тот же метод сбора может приводить к разным артефактам. Например, интервью с оператором колл-центра может закончиться списком проблем, а может — описанием процесса as-is и набором критериев приемки для нового экрана.

Что нужно подготовить до сбора требований

Чтобы сбор был управляемым, бизнес-аналитик заранее опирается на фундамент из прошлой статьи:

Список стейкхолдеров и понимание, кто принимает решения.

Цели и метрики успеха, чтобы не собирать “всё подряд”.

Границы in scope / out of scope, чтобы вопросы не уходили в бесконечность.

Ограничения и зависимости, чтобы не обещать невозможного.

Практичный минимальный набор подготовки:

сформулировать 5–10 ключевых вопросов, на которые нужно ответить (про боль, процесс, правила, исключения, риски)

выбрать техники сбора под эти вопросы

запланировать участников, время, формат, артефакты на выходе

!Визуально показывает связь целей, границ и стейкхолдеров с выбором методов сбора требований и результатами

Как выбрать метод сбора требований

На практике почти всегда работает комбинация методов. Выбор зависит от того, какой тип информации вы ищете:

мнения, ожидания, боли и контекст — хорошо раскрываются в интервью

согласование общего понимания и правил — удобно делать на воркшопах

реальная работа “как есть”, обходные пути, скрытые сложности — лучше видны в наблюдении

масштаб проблемы, частота, тренды и аномалии — лучше видны в данных

Ниже — ориентир по техникам.

| Техника | Когда полезна | Сильные стороны | Ограничения | Типичный результат | |---|---|---|---|---| | Интервью | Нужно понять мотивацию, детали ролей, исключения | Глубина, можно уточнять | Риск субъективности, зависит от навыка интервьюера | Боли, цели пользователей, бизнес-правила, список требований | | Воркшоп | Нужно быстро синхронизировать несколько стейкхолдеров | Общее решение, скорость согласования | Сложно организовать, риск доминирования | Договоренности, приоритеты, варианты решения | | Наблюдение | Нужно увидеть реальный процесс и фактические трудности | Выявляет “как на самом деле” | Требует времени, вопросы приватности | Карта процесса, проблемы, исключения | | Анализ данных | Нужно подтвердить масштаб, приоритет, эффект | Объективнее мнений, видны тренды | Данные могут быть неполными, нужна интерпретация | Метрики, сегменты, гипотезы, точки улучшения |

Интервью

Интервью — это структурированный разговор, цель которого не “получить список фич”, а понять:

какую задачу человек решает

почему текущий способ неудобен

какие правила и исключения существуют

какие критерии “хорошо / плохо” у стейкхолдера

Полезное введение в интервью и вопросы — материалы Nielsen Norman Group: User Interviews.

Виды интервью

Полуструктурированное: есть план тем, но порядок и уточнения гибкие.

Экспертное: у владельца процесса или специалиста по правилам.

Проблемное: фокус на болях и причинах, а не на “как вы хотите кнопку”.

Подготовка к интервью

определить цель интервью в одном предложении (что должно проясниться)

выбрать роль и правильного представителя (не всегда “самый главный” знает детали)

подготовить список тем и 10–15 вопросов

заранее решить, что вы фиксируете как артефакт (заметки, черновик процесса, список правил)

Как задавать вопросы

Рабочие принципы:

начинать с контекста и фактов: “Опишите ваш последний случай…”

отделять “что было” от “что хотелось бы”

просить примеры и артефакты: письма, шаблоны, скриншоты, выгрузки

уточнять исключения: “А когда бывает иначе?”

Примеры удачных формулировок:

“Как вы понимаете, что задача выполнена правильно?”

“Какие причины приводят к возврату заявки?”

“Какие поля вы заполняете всегда, а какие — только иногда?”

Чего лучше избегать:

наводящих вопросов: “Правильно ли я понимаю, что нужно добавить фильтр?”

вопросов про “идеальный интерфейс” без понимания задачи

попытки спроектировать решение вместо выявления потребности

Фиксация результатов интервью

Хорошая практика — завершать интервью коротким резюме:

что мы поняли

какие открытые вопросы остались

что нужно проверить данными или у других стейкхолдеров

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

список потребностей и проблем, сгруппированных по темам

бизнес-правила в виде проверяемых утверждений

сценарии: основной поток и 3–5 исключений

решения и спорные моменты — в журнале решений

Воркшопы

Воркшоп — это сессия совместной работы, где важно не “поговорить”, а получить согласованный результат. Воркшоп особенно полезен, когда:

есть конфликт интересов между стейкхолдерами

нужно быстро согласовать правила или приоритеты

требования затрагивают несколько ролей или подразделений

Роли на воркшопе

Фасилитатор (часто бизнес-аналитик): ведет процесс, следит за временем и вовлечением.

Предметные эксперты: дают содержание, правила, исключения.

ЛПР: фиксирует финальные решения или подтверждает их позже.

Секретарь: помогает фиксировать договоренности (иногда это тоже фасилитатор, но лучше разделять).

Форматы, которые часто работают в разработке ПО

согласование as-is / to-be процесса (что меняем и почему)

разбор кейсов и исключений (набор “сложных ситуаций”)

приоритизация (например, MoSCoW: must/should/could/won’t)

story mapping (раскладка пользовательского пути на активности и шаги)

Если в команде используются практики доменного моделирования, иногда проводят event storming — это воркшоп-формат, где участники раскладывают события и шаги процесса, чтобы согласовать понимание предметной области простыми словами.

Структура хорошего воркшопа

цель и ожидаемый результат сессии

правила коммуникации (не перебиваем, критикуем идеи, а не людей)

таймбокс на блоки (чтобы сессия не “уплыла”)

фиксация решений в явном виде

список открытых вопросов и владелец каждого вопроса

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

Наблюдение

Наблюдение помогает увидеть то, что люди часто не проговаривают на интервью:

обходные пути и “ручные костыли”

реальные задержки и переключения между системами

фактические исключения и причины ошибок

Один из известных подходов — contextual inquiry (наблюдение в рабочем контексте с уточняющими вопросами). Хорошее описание подхода: Contextual Inquiry.

Как проводить наблюдение безопасно и эффективно

заранее договориться о цели и границах (что наблюдаем, сколько времени)

уточнить правила конфиденциальности (особенно если видны персональные данные)

наблюдать “живой” кейс, а не демонстрацию “как должно быть”

фиксировать шаги, системы, поля, решения пользователя и причины

Результаты наблюдения обычно оформляют как:

карта процесса as-is с болями и узкими местами

список улучшений, привязанных к конкретным шагам

набор реальных кейсов для дальнейшей проработки требований и тестирования

Анализ данных

Анализ данных нужен, чтобы дополнить слова людей фактами и ответить на вопросы:

как часто происходит проблема

где процесс “ломается” чаще всего

какие сегменты пользователей страдают больше

какой эффект можно ожидать после изменений

Типичные источники данных в разработке ПО:

продуктовая аналитика (события, воронки, пути пользователей)

логи приложения и ошибки

обращения в поддержку и тикеты

CRM и данные по продажам

результаты опросов и NPS (если есть корректная методика)

Важные ограничения анализа данных

данные могут не отражать причины (видим симптом, но не мотивацию)

трекинг может быть неполным или искаженным

корреляция не равна причинности (две величины меняются вместе, но не факт, что одна вызвала другую)

Поэтому данные почти всегда лучше использовать вместе с интервью и наблюдением.

Как превращать данные в требования

Данные редко дают “готовую фичу”. Чаще они дают гипотезу:

факт: 35% пользователей бросают оформление на шаге оплаты

гипотеза: пользователи не доверяют способу оплаты или не понимают условия

план проверки: интервью + просмотр записей сессий (если это разрешено политиками) + анализ ошибок платежного шлюза

результат: требования к сообщениям об ошибках, альтернативным способам оплаты, логированию, SLA интеграции

Совмещение методов и проверка понимания

Сильный бизнес-анализ почти всегда использует триангуляцию — проверку выводов через несколько источников:

интервью дает объяснение и язык предметной области

наблюдение показывает реальную работу и исключения

данные дают масштаб и приоритет

воркшоп согласует правила и финальные решения

Полезная практика завершения цикла сбора:

короткая сессия подтверждения с ключевыми стейкхолдерами (что верно, что поправить)

фиксация решений и спорных вопросов

обновление границ in scope / out of scope, если вскрылись новые факты

Типичные ошибки при сборе требований

сбор “хотелок” без привязки к целям и метрикам

интервью только с руководителями без исполнителей процесса

отсутствие фиксации решений после воркшопа

игнорирование исключений и пограничных случаев

доверие только одному источнику (только мнениям или только данным)

Итоги

Сбор требований — это управляемое получение информации из четырех основных каналов: интервью, воркшопы, наблюдение и анализ данных. Опираясь на стейкхолдеров, цели и границы, бизнес-аналитик выбирает комбинацию техник, получает факты и договоренности, а затем превращает их в проверяемые требования и критерии приемки, снижая риск сделать “не то” и уменьшая количество переделок в разработке.

Документирование требований: user stories, use cases, SRS и NFR

В предыдущих статьях курса мы построили основу: поняли роль бизнес-анализа в SDLC, определили стейкхолдеров, цели и границы, а затем собрали информацию через интервью, воркшопы, наблюдение и анализ данных. Следующий шаг — документирование требований: превращение найденных потребностей и правил в форму, которая одинаково понятна бизнесу, разработке и тестированию.

Ключевая идея: разные форматы требований решают разные задачи. Нет “единственно правильного” документа. Важно выбрать минимально достаточный набор артефактов, чтобы:

снять неоднозначность

согласовать ожидания

сделать требования проверяемыми

управлять изменениями

!Карта показывает, как результаты сбора превращаются в разные форматы требований и связываются с целями и тестированием

Что такое требование и что значит “хорошо задокументировано”

Требование — это проверяемое описание того, что должно быть реализовано или соблюдено.

Документирование не означает “написать большой документ”. Оно означает зафиксировать согласованное понимание так, чтобы команда могла:

оценить объём работ

реализовать

проверить

принять

Практичные критерии качества требований:

однозначность: одинаково понимается разными участниками

проверяемость: можно подтвердить выполнение

согласованность: нет противоречий между требованиями

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

Когда какой формат использовать

Ниже — рабочая шпаргалка. В реальности часто используют комбинацию.

| Формат | Когда особенно полезен | Сильные стороны | Типичный риск при неправильном применении | |---|---|---|---| | User stories | Agile-команды, бэклог, итеративная поставка | Быстро, ориентировано на ценность, удобно приоритизировать | Истории становятся слишком общими без критериев приемки и деталей | | Use cases | Сложные сценарии, много исключений, несколько ролей | Хорошо описывает взаимодействия и альтернативные потоки | Может стать слишком тяжёлым для простых задач | | SRS | Регулируемые домены, контрактная разработка, сложные интеграции | Единая спецификация, удобно согласовывать объём и полноту | Риск “заморозить” требования и усложнить изменения | | NFR | Производительность, безопасность, надёжность, совместимость | Снижает риск “всё работает, но пользоваться нельзя” | Часто забывают или формулируют непроверяемо |

Полезный ориентир: документируйте ровно столько, сколько нужно, чтобы избежать переделок и конфликтов на разработке и приёмке.

User stories

User story — короткое описание потребности пользователя в формате, который помогает обсуждать ценность и согласовывать критерии готовности.

На практике часто используют шаблон:

Как роль

я хочу возможность

чтобы получить ценность

Общее описание user story: User story

Что важно помнить про user stories

User story — это не спецификация “в вакууме”, а триггер разговора. Чтобы история стала реализуемой и тестируемой, почти всегда нужны дополнения.

Минимально полезный комплект для одной истории:

формулировка истории

критерии приемки

бизнес-правила, если они влияют на поведение

уточнения по данным и интеграциям, если затрагиваются

Критерии приемки

Критерии приемки — условия, при которых стейкхолдеры согласны считать историю выполненной.

Критерии приемки должны быть:

конкретными

наблюдаемыми

проверяемыми

Популярный формат — Given-When-Then из BDD (часто описывают в синтаксисе Gherkin): Gherkin Reference

Пример user story с критериями приемки:

история: Как оператор поддержки я хочу видеть причину возврата заказа чтобы быстрее решать обращения клиента.

критерии приемки:

Given открыт заказ со статусом “Возврат”, When оператор открывает вкладку “История”, Then отображается поле “Причина возврата” и дата фиксации причины.

Given причина возврата не заполнена, When оператор открывает вкладку “История”, Then показывается сообщение “Причина возврата не указана”.

Given оператор без роли “Супервайзер”, When он пытается изменить причину возврата, Then изменение недоступно.

INVEST как проверка качества истории

INVEST — набор свойств “хорошей” истории (часто используют как чек-лист). Подробное объяснение термина: INVEST (mnemonic))

Independent: по возможности независима от других

Negotiable: обсуждаема, не превращена в контракт заранее

Valuable: несёт ценность

Estimable: оцениваема

Small: достаточно мала для итерации

Testable: проверяема

Use cases

Use case — описание взаимодействия актора (пользователя или внешней системы) с системой для достижения цели, включая основной поток и альтернативы.

Базовое определение: Use case

Use cases особенно полезны, когда:

много ветвлений и исключений

участвуют несколько ролей

есть интеграции и важные состояния

нужно заранее согласовать “что происходит, если…”

Типовая структура use case

Часто достаточно следующего шаблона:

название и цель

акторы

предусловия

триггер

основной поток

альтернативные потоки и исключения

постусловия

бизнес-правила и ограничения, применимые к кейсу

Пример фрагмента use case:

Название: “Оформление возврата товара”

Акторы: клиент, оператор, платёжный шлюз

Предусловия: заказ доставлен; возврат разрешён по политике

Основной поток:

Клиент выбирает заказ и нажимает “Оформить возврат”.

Система показывает список позиций и доступные причины.

Клиент выбирает позиции, указывает причину, подтверждает.

Система создаёт заявку на возврат и отправляет уведомление.

Альтернативы:

Если у заказа истёк срок возврата, система показывает отказ с причиной.

Если платёжный шлюз недоступен, система создаёт заявку со статусом “Ожидает возврата средств” и ставит задачу на повтор.

Use case не обязан быть “огромным документом”. Его сила в том, что он дисциплинирует команду обсуждать потоки, исключения и состояния.

SRS

SRS (Software Requirements Specification) — спецификация требований к программному продукту в виде структурированного документа.

SRS часто используют, когда важны:

полнота и единое место правды

формальное согласование объёма

внешние подрядчики

требования аудита и регуляторов

Один из наиболее известных стандартов, описывающих структуру и качество требований: ISO/IEC/IEEE 29148

Что обычно включает SRS

Содержание варьируется, но практично держать в SRS следующие разделы:

контекст и цели

область (in scope / out of scope)

термины и определения

пользовательские классы и роли

функциональные требования

интерфейсы и интеграции

данные (основные сущности, правила валидации на уровне требований)

нефункциональные требования

ограничения (технологические, юридические, организационные)

допущения и зависимости

критерии приемки на уровне релиза или ключевых функций

Как не превратить SRS в “кладбище текста”

Практики, которые повышают полезность SRS:

писать требования атомарно: одно требование — одна мысль

нумеровать требования, чтобы обсуждать изменения и трассировать тесты

избегать слов “быстро”, “удобно”, “современно” без измеримых критериев

связывать требования с источником: стейкхолдер, цель, гипотеза, правило

NFR

NFR (Non-Functional Requirements) — нефункциональные требования: условия качества и ограничения, при которых функциональность считается приемлемой.

Общее определение: Non-functional requirement

Если функциональные требования отвечают на вопрос “что система делает”, то NFR отвечают на вопрос “насколько хорошо, при каких условиях и с какими ограничениями”.

Типовые категории NFR

Ниже — частые группы нефункциональных требований:

производительность и ёмкость (время ответа, количество одновременных пользователей)

надёжность и доступность (uptime, восстановление)

безопасность (аутентификация, авторизация, аудит, шифрование)

совместимость и переносимость (браузеры, устройства, версии ОС)

удобство использования и доступность (в том числе требования доступности)

сопровождаемость и наблюдаемость (логирование, метрики, трассировка)

В качестве справочника по характеристикам качества часто используют модель качества ПО: ISO/IEC 25010

Как формулировать NFR так, чтобы их можно было проверить

Слабая формулировка:

“Система должна работать быстро.”

Проверяемая формулировка (пример логики, не универсальный шаблон):

“Для 95% запросов поиска по каталогу время ответа не превышает 2 секунд при 500 одновременных активных пользователях в рабочее время.”

Чтобы NFR были проверяемыми, полезно договориться:

как измеряем (где метрика, какой инструмент)

на каком окружении проверяем

какой сценарий нагрузки и данные

какой порог приемлемости

NFR как часть критериев приемки

Частая ошибка — держать NFR отдельно от разработки и тестирования. Практичнее связывать NFR:

с конкретными пользовательскими сценариями (что именно “быстро”)

с критериями приемки релиза

с планом тестирования (нагрузочные, безопасность, отказоустойчивость)

Как сочетать user stories, use cases, SRS и NFR в одном проекте

Один из практичных подходов:

user stories управляют бэклогом и приоритизацией

use cases описывают сложные сценарии и исключения

SRS фиксирует общую спецификацию и интеграции, если нужен единый документ

NFR задают измеримые рамки качества и ограничений

Пример “комбинации без лишней бюрократии”:

для каждой крупной функции: эпик в виде user stories

для самых рискованных эпиков: 1–3 use case на критические сценарии

NFR: отдельный раздел или отдельные требования, связанные с функциями

решения и спорные моменты: журнал решений

Трассируемость: чтобы требования не жили отдельно от целей и тестов

Трассируемость — это способность ответить на вопросы:

какая цель стоит за требованием

кто источник требования

как требование будет проверено

что сломается, если требование изменить

Минимальная таблица трассируемости может быть очень простой:

| Идентификатор | Требование | Источник | Связанная цель | Проверка | |---|---|---|---|---| | FR-12 | Показать причину возврата в карточке заказа | Интервью: поддержка | Сократить время обработки обращений | Тест-кейс TC-45 + критерии приемки истории | | NFR-03 | 95% запросов поиска до 2 секунд при 500 пользователях | Цель продукта + данные | Удержание пользователей в каталоге | Нагрузочный тест LT-02 |

Частые ошибки в документировании требований

смешивают цели и требования, из-за чего “делают функции вместо эффекта”

пишут требования без критериев приемки, и команда по-разному понимает “готово”

фиксируют только основной сценарий и забывают исключения

формулируют NFR непроверяемо, поэтому качество обсуждают слишком поздно

нет единого места для решений, и контекст теряется

Итоги

Документирование требований — это выбор подходящего формата фиксации договорённостей, чтобы команда могла реализовать и проверить ожидаемый результат. User stories удобны для управления бэклогом и ценностью, use cases — для сложных сценариев и исключений, SRS — для единой спецификации в формальных контекстах, а NFR — для измеримых рамок качества. Чем лучше требования связаны с целями, границами и проверками, тем ниже риск переделок и конфликтов на приёмке.

Моделирование процессов и данных: BPMN, UML, ER-диаграммы

В предыдущих статьях курса мы прошли путь от зачем (цели и метрики) и кто (стейкхолдеры) к что нужно сделать (сбор и документирование требований в формате user stories, use cases, SRS и NFR). Следующий практический шаг, который сильно повышает качество понимания в команде, — моделирование.

Модели нужны не ради «красивых схем», а чтобы:

быстро синхронизировать понимание между бизнесом, разработкой и тестированием

увидеть пробелы, исключения и противоречия раньше разработки

зафиксировать границы, роли, состояния и данные в проверяемом виде

В этой теме разберём три самых прикладных семейства моделей в бизнес-анализе ПО:

BPMN для бизнес-процессов

UML для поведения и взаимодействий в системе

ER-диаграммы для данных и их связей

Что моделировать и как выбрать нотацию

Выбор нотации зависит от вопроса, на который вы отвечаете.

| Что хотим прояснить | Лучший тип модели | Типичный результат для требований | |---|---|---| | Как люди и подразделения выполняют работу, где ожидания и передачи, какие варианты пути | BPMN (процесс) | Согласованный as-is/to-be процесс, точки автоматизации, исключения | | Какие роли взаимодействуют с системой и какие сценарии происходят «по шагам» | UML (use case, activity, sequence) | Уточнённые сценарии, альтернативные потоки, правила и критерии приемки | | Какие сущности храним, какие поля обязательны, какие связи и ограничения целостности | ER (данные) | Единое понимание предметных данных, основа для API/БД/валидации |

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

BPMN для моделирования процессов

BPMN (Business Process Model and Notation) — стандартная нотация для описания бизнес-процессов. Она удобна тем, что позволяет в одной схеме показать:

участников процесса

последовательность шагов

развилки и условия

ожидания и события

передачи между ролями и системами

Официальный стандарт поддерживается OMG: BPMN 2.0 Specification.

Основные элементы BPMN, которые реально нужны в проектах

Чтобы начать, достаточно базового набора.

Pool: граница процесса, часто одна организация или одна система

Lane: дорожка внутри pool, отражает роль или подразделение

Task: шаг работы

Gateway: развилка (например, «Да/Нет»)

Event: событие (старт, окончание, ожидание сообщения)

Sequence flow: стрелка порядка выполнения

Message flow: обмен между участниками (между pools)

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

Как использовать BPMN в бизнес-анализе

BPMN хорошо работает как мост между результатами сбора требований и формализацией.

Строите as-is процесс по наблюдениям и интервью.

Отмечаете боли, ручные операции, задержки, источники ошибок.

Проектируете to-be процесс с учётом границ in scope/out of scope.

На развилках фиксируете бизнес-правила, которые потом превратятся в требования.

Примеры вопросов, на которые BPMN помогает ответить:

Где именно возникает ожидание и кто его владелец?

В каких местах решение принимает человек, а где можно автоматизировать?

Какие исключения ломают основной поток?

!Пример BPMN, показывающий участников, шаги, развилку и уведомления

Типовые ошибки в BPMN и как их избегать

Ошибка: схема превращается в «картиночку», без правил на развилках.

Решение: рядом с gateway фиксировать условие в виде проверяемого правила.

Ошибка: смешивание уровней детализации, когда один шаг описан как «работа отдела», а рядом — «клик по кнопке».

Решение: договориться об уровне, например «шаг = значимое действие роли», а клики оставить для UI-описаний.

Ошибка: роль и система перемешаны в одной дорожке.

Решение: отдельная lane для системы помогает видеть автоматизацию и ручной труд.

UML: модели поведения и взаимодействий

UML (Unified Modeling Language) — семейство диаграмм для описания структуры и поведения систем. Для бизнес-анализа в разработке ПО чаще всего полезны диаграммы, которые помогают уточнить сценарии и взаимодействия.

Стандарт поддерживается OMG: UML Specification.

Диаграмма вариантов использования (use case diagram)

Use case diagram отвечает на вопрос: кто и какие цели реализует через систему. Она полезна на уровне границ решения:

какие акторы взаимодействуют с системой

какие крупные сценарии входят в scope

какие интеграции важны

Use case diagram не заменяет use case текстом, но помогает увидеть «дыры»: забытые роли, недостающие сценарии, ошибочные ожидания.

Activity diagram для сценариев и правил

Activity diagram близка по логике к блок-схеме и удобна, когда нужно описать:

последовательность действий внутри одного сценария

условия ветвления

параллельные шаги (если это важно)

На практике activity diagram часто является промежуточным шагом между BPMN (уровень процесса) и критериями приемки (уровень поведения функции).

Sequence diagram для интеграций и сложных взаимодействий

Sequence diagram отвечает на вопрос: кто с кем и в каком порядке обменивается сообщениями. Особенно полезна, когда:

есть несколько систем и API-вызовы

есть асинхронность, очереди, ретраи

важно согласовать ответственность и точки ошибок

!Пример sequence diagram для согласования порядка вызовов и альтернатив

Class diagram и доменная модель

Class diagram в BA-контексте чаще используют не для проектирования кода, а как доменную модель:

какие сущности есть в предметной области

какие отношения между ними

какие атрибуты принципиальны для правил

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

ER-диаграммы для данных и правил целостности

ER-диаграмма (Entity-Relationship) — модель данных: сущности, атрибуты и связи. Классическая основа: Entity–relationship model.

ER полезна, когда требования упираются в вопросы:

что именно считаем «заказом», «клиентом», «обращением»

можно ли иметь несколько адресов, несколько контактов, несколько статусов

какие поля обязательны и уникальны

какие связи 1:1, 1:N, M:N

Минимальный набор понятий ER, нужный бизнес-аналитику

Сущность: объект предметной области (например, Заказ)

Атрибут: характеристика сущности (например, orderDate)

Связь: как сущности связаны (Клиент делает Заказы)

Кратность: сколько объектов может участвовать в связи (1:N)

Ключ: атрибут, однозначно идентифицирующий запись (например, orderId)

Даже если команда использует UML class diagram для данных, смысл тот же: синхронизировать понятия, обязательность и связи.

!Пример ER-диаграммы: сущности, ключи, связи и кратности

Как ER помогает писать требования

ER-диаграмма часто превращает «неясную хотелку» в проверяемые правила.

Примеры трансформации:

Было: «У клиента могут быть несколько адресов».

Стало: связь Customer 1:N Address, правило «один адрес может быть помечен как основной», ограничение «не более одного основного адреса на клиента».

Было: «Нужна история статусов заказа».

Стало: сущность OrderStatusHistory с полями orderId, status, changedAt, changedBy и правилом «при каждом изменении статуса создаётся запись».

Как связать модели с требованиями, тестированием и границами

Модели становятся особенно ценными, когда они не живут отдельно.

Практичная схема связей:

Цели и метрики объясняют, почему меняем процесс или данные.

BPMN фиксирует где и кем выполняется работа.

UML activity/use case уточняют сценарии и исключения.

UML sequence фиксирует контракты взаимодействий и альтернативы ошибок.

ER фиксирует, какие данные нужны для сценариев и правил.

Из моделей вынимаются требования и критерии приемки.

Минимальная трассируемость может выглядеть так:

| Артефакт | Что связываем | Зачем | |---|---|---| | BPMN шаг или развилка | User story / use case / бизнес-правило | Понимать, какой участок процесса покрываем | | Sequence сообщение | Требование к API и обработке ошибок | Согласовать ответственность и реакции на сбои | | ER сущность/связь | Поля в UI, API-контракты, валидации, миграции | Избежать «а где это хранить?» на разработке |

Практические рекомендации по качеству моделей

Делайте модели читаемыми для не-технарей

подписывайте элементы словами предметной области, а не техническими терминами

избегайте перегруженных схем, лучше несколько небольших

фиксируйте спорные места комментариями в требованиях или журнале решений

Договоритесь об уровне детализации

BPMN: шаги роли и системы, без кликов и пикселей

UML sequence: только значимые вызовы и ответы, плюс ветки ошибок

ER: только сущности и атрибуты, влияющие на правила и сценарии

Проверяйте модели через вопросы

Для процесса: «Кто владелец шага? Что является входом? Что является выходом? Что если условие не выполнено?»

Для интеграции: «Что происходит при таймауте? Где ретраи? Как пользователь узнает о результате?»

Для данных: «Можно ли удалить? Можно ли изменить? Как обеспечиваем уникальность? Как храним историю?»

Итоги

BPMN, UML и ER-диаграммы — это инструменты бизнес-аналитика для превращения разрозненных требований и договорённостей в согласованную, проверяемую картину.

BPMN помогает увидеть процесс, роли, ожидания и правила на развилках.

UML помогает уточнить сценарии и взаимодействия между ролями и системами.

ER-диаграммы помогают согласовать структуру данных, связи и ограничения целостности.

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

Валидация и приоритизация: критерии качества, MoSCoW, backlog

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

мы описали правильные требования или ошиблись в понимании?

что делать сначала, а что можно отложить без потери ценности?

Эта тема закрывает оба вопроса через две практики:

валидация требований: подтверждаем, что требования соответствуют реальной потребности и целям

приоритизация: выстраиваем порядок реализации и формируем управляемый backlog

!Общая картина: как требования проходят проверку и превращаются в упорядоченный backlog

Валидация и верификация: не путать

Термины звучат похоже, но отвечают на разные вопросы:

Валидация: делаем ли мы правильный продукт? Соответствует ли требование реальной потребности и цели.

Верификация: сделали ли мы продукт правильно? Соответствует ли реализация требованиям.

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

Что именно валидируем

Валидировать можно не только формулировку требования, но и весь контекст вокруг него:

ценность: какое влияние на цель продукта и метрики успеха

сценарии: основной поток и исключения, которые реально случаются

правила: бизнес-правила и ограничения, которые нельзя нарушить

данные: что считаем сущностями, как обеспечиваем целостность, что обязательно хранить

качество: нефункциональные требования (производительность, безопасность, надёжность)

границы: что входит in scope, а что осознанно out of scope

Если валидировать только текст user story, но не проверить исключения, данные и NFR, команда может сделать функцию, которая формально “готова”, но не работает в реальной жизни.

Критерии качества требований

Ниже — практичные критерии, которые помогают оценить качество требования в любом формате (user story, use case, SRS, отдельное правило).

| Критерий | Что означает простыми словами | Как проверить на практике | |---|---|---| | Однозначность | требование понимают одинаково разные люди | попросить разработчика и тестировщика пересказать смысл; сравнить трактовки | | Проверяемость | можно однозначно определить, выполнено ли требование | есть критерии приемки или тестовый сценарий, который даст “да/нет” | | Полнота в нужной глубине | хватает деталей для оценки, реализации и тестирования | нет критичных “дыр”: роли, входы/выходы, состояния, ошибки | | Согласованность | не противоречит другим требованиям и ограничениям | сверка с правилами, NFR, моделями BPMN/UML/ER | | Реалистичность | можно реализовать в рамках ограничений | сверка с технологиями, сроками, регуляторикой, зависимостями | | Трассируемость | понятно, откуда требование и зачем оно | есть связь с целью, стейкхолдером, решением, метрикой |

Эти критерии полезно применять как чек-лист на ревью требований.

Как проводить валидацию: рабочие техники

Валидация — это не один митинг “согласовали и забыли”, а цикл коротких проверок.

Обзор требований со стейкхолдерами

Цель обзора: найти неверные предположения и недостающие исключения.

Практика, которая работает:

заранее отправить краткий материал (истории, сценарии, прототип или модель)

на встрече идти не по “тексту документа”, а по реальным кейсам: “что происходит, если…”

в конце фиксировать результаты как:

1. принятые решения 2. изменения требований 3. открытые вопросы и владельцев

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

Прототипы и примеры экранов

Прототип (даже простой) часто валидирует быстрее, чем страницы текста, потому что:

пользователи легче узнают свою работу “в интерфейсе”

быстрее обнаруживаются пропущенные поля, статусы, сообщения об ошибках

проще договориться о критериях “удобно/неудобно” через наблюдаемые признаки

Важно: прототип не равен дизайну и не отменяет требований. Он снижает риск неверной интерпретации.

Валидация через критерии приемки

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

Признаки, что критерии приемки помогают валидировать:

описывают поведение в терминах сценария (условие, действие, результат)

покрывают не только “счастливый путь”, но и ключевые исключения

включают важные ограничения (например, по ролям доступа)

Если критерии приемки невозможно написать без большого количества “в целом”, “обычно”, “примерно”, это сигнал, что требование пока не достаточно понятно.

Сверка с моделями: BPMN, UML, ER

Модели из прошлой темы курса — сильный инструмент валидации:

BPMN помогает проверить, что процесс to-be не ломает ответственность ролей и передачи между участниками

UML activity/use case помогает убедиться, что сценарии согласованы по потокам и условиям

UML sequence помогает выявить “а что если интеграция недоступна?” до разработки

ER помогает поймать ошибки понятий: что является сущностью, какие связи и ограничения нужны

Практический приём: на каждом gateway в BPMN и на каждой альтернативе в use case задавать вопрос “а это действительно так происходит в жизни?” и “кто подтверждает правило?”.

Валидация NFR: чтобы качество не стало сюрпризом

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

привязать NFR к конкретным пользовательским сценариям

определить измерение: чем меряем, где меряем, кто смотрит

согласовать пороги приемлемости до начала разработки

Пример логики валидации:

требование: “поиск работает быстро”

уточнение: для кого и где: “для операторов колл-центра в рабочее время”

измерение: “время ответа для 95% запросов на прод-подобном стенде”

приемлемость: “не более 2 секунд”

Даже если числа потом изменятся, сам подход делает качество управляемым.

Приоритизация: зачем она нужна

Приоритизация нужна, потому что почти всегда есть ограничения:

время и бюджет

ограничение по команде и компетенциям

зависимости от внешних систем

риски и неопределённость

Если не приоритизировать, на практике получается “делаем всё понемногу”, и продукт долго не приносит ценность.

MoSCoW: простой и понятный метод приоритизации

MoSCoW — способ группировки требований по четырём категориям:

Must have: без этого релиз не имеет смысла или нарушает обязательные правила

Should have: очень важно, но можно временно обойтись

Could have: желательно, если останутся ресурсы

Won’t have (this time): не делаем в этом релизе или итерации

Источник: MoSCoW method

Как не превратить MoSCoW в “почти всё Must”

MoSCoW ломается, когда стейкхолдеры ставят “Must” всему. Чтобы метод работал, нужны правила.

Практичные правила фасилитации:

“Must” ограничен квотой

1. заранее договориться, что Must покрывает только минимально жизнеспособный объём релиза 2. если Must слишком много, релиз становится неуправляемым

“Won’t” обязателен

1. список “Won’t” фиксирует границы и снимает ожидания 2. это снижает scope creep

Must должен иметь причину

1. регуляторное требование 2. критическая зависимость процесса 3. без этого нельзя проверить гипотезу или получить эффект по метрике

Когда MoSCoW особенно полезен

на раннем discovery, чтобы согласовать минимальный объём

при планировании релиза, когда нужно “обрезать” объём без конфликтов

при большом количестве стейкхолдеров, когда важна прозрачная договорённость

Ограничения MoSCoW

MoSCoW отвечает на вопрос “насколько важно”, но слабее отвечает на вопросы:

что делать раньше из двух Must?

как учесть зависимости и риски?

Поэтому на практике MoSCoW удобно сочетать с упорядочиванием внутри категории и явной фиксацией зависимостей.

Backlog: как превратить приоритеты в управляемый план

Backlog — это упорядоченный список работы по продукту: что команда может сделать, чтобы приблизиться к целям. В Agile-контексте чаще говорят product backlog.

Источник определения и роли backlog в Scrum: Scrum Guide (2020)

Что должно быть в backlog, кроме “хотелок”

Backlog становится управляемым, когда каждый элемент имеет минимальный контекст:

формулировку (user story или требование)

критерии приемки

приоритет или позицию в порядке

понимание ценности (какую цель/метрику поддерживает)

зависимости и риски (если есть)

статус готовности к разработке

Уровни элементов backlog

Часто используют иерархию (названия могут отличаться):

эпик: крупная цель или часть продукта

фича: заметная возможность внутри эпика

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

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

Backlog refinement: уточнение перед разработкой

Refinement (уточнение backlog) — регулярная практика, где команда:

проясняет формулировки и сценарии

добавляет или уточняет критерии приемки

выявляет зависимости

оценивает объём (в удобной команде форме)

готовит элементы к ближайшей итерации

В refinement бизнес-аналитик помогает удерживать требования проверяемыми и связанными с целями.

Definition of Ready и Definition of Done

Чтобы снизить риск “взяли в разработку сырое”, команды иногда договариваются о простых критериях.

Definition of Ready: что должно быть известно, чтобы брать элемент в разработку

Definition of Done: что должно быть выполнено, чтобы считать элемент завершённым

Эти определения не универсальны, но полезны как соглашение в команде.

Практичный алгоритм: от валидации к приоритизации и backlog

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

Убедиться, что есть цели, метрики и границы

Сформировать требования и критерии приемки

Провести валидацию с ключевыми стейкхолдерами

Применить критерии качества требований и исправить слабые места

Сделать MoSCoW-классификацию на релиз или крупную итерацию

Упорядочить элементы внутри Must/Should с учётом зависимостей и рисков

Сформировать backlog и договориться о правилах refinement

Поддерживать журнал решений и обновлять требования при изменениях

Частые ошибки и как их предотвращать

ошибка: “согласовали требования” без проверки исключений

- профилактика: валидировать через кейсы и альтернативные потоки

ошибка: NFR обсуждают после того, как “всё готово”

- профилактика: привязывать NFR к сценариям и критериям приемки заранее

ошибка: MoSCoW превращается в “всё Must”

- профилактика: квота на Must и обязательный список Won’t

ошибка: backlog — это склад идей без порядка

- профилактика: backlog должен быть упорядочен и связан с целями, а элементы должны проходить refinement

Итоги

Валидация и приоритизация превращают требования из “текста и схем” в управляемую разработку.

валидация снижает риск делать не то, проверяя требования на соответствие целям, реальным сценариям, правилам, данным и NFR

критерии качества помогают выявить слабые требования до разработки

MoSCoW даёт простой язык договорённостей о важности и фиксирует границы через категорию Won’t

backlog переводит приоритеты в упорядоченный план работы, который регулярно уточняется через refinement

Управление изменениями и коммуникации: трассируемость, UAT, релизы

В предыдущих темах курса мы научились выявлять потребности, фиксировать требования в удобных форматах, моделировать процессы и данные, а затем валидировать и приоритизировать требования, превращая их в управляемый backlog. Но в реальных проектах этого недостаточно.

Даже при отличной аналитике появляются новые факты: меняются бизнес-приоритеты, вскрываются ограничения интеграций, пользователи по-новому формулируют ожидания после просмотра прототипа, регуляторика приносит новые правила. Поэтому бизнес-анализ в разработке ПО обязательно включает:

управление изменениями, чтобы изменения были контролируемыми, а не хаотичными

коммуникации, чтобы все стейкхолдеры одинаково понимали, что меняется и почему

трассируемость, чтобы можно было быстро оценить влияние изменений и проверить, что всё нужное реализовано

UAT, чтобы пользователи подтвердили пригодность решения до выхода в прод

релизные практики, чтобы поставка была предсказуемой и с понятными последствиями

Почему изменения неизбежны

Изменение требований само по себе не является проблемой. Проблема возникает, когда изменение:

не фиксируется и происходит только в переписке

не оценивается по влиянию на сроки, стоимость, качество и риски

не согласуется с владельцами решений

не доводится до команды разработки, тестирования, поддержки и пользователей

Тогда появляется типичный эффект: команда делает не то, тестирование проверяет не то, а на приёмке выясняется, что ожидания разошлись.

Управление изменениями как управляемый цикл

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

!Жизненный цикл изменения: от запроса до релиза и коммуникации

Фиксация запроса на изменение

Запрос на изменение полезно фиксировать так, чтобы его можно было обсуждать предметно:

что меняем (суть)

зачем (цель или проблема)

для кого (затронутые роли)

какой ожидаемый эффект (ценность)

насколько срочно

Практичный формат для команды: change request как карточка в системе управления работами.

Оценка влияния

Оценка влияния отвечает на вопрос: что сломается и что нужно поменять, если мы это примем.

Обычно оценивают:

влияние на границы in scope / out of scope

влияние на требования и критерии приемки

влияние на модели (BPMN, UML, ER)

влияние на интеграции и данные

влияние на NFR (производительность, безопасность, доступность)

влияние на тестирование (какие тесты добавить или переписать)

риски и зависимости

Решение и его фиксация

Решение по изменению должно быть явным:

принимаем сейчас

откладываем (и до какого события)

отклоняем (и почему)

Ключевая практика коммуникаций здесь — журнал решений.

Обновление артефактов

После решения важно обновить источник правды:

backlog (приоритет, порядок, зависимости)

формализованные требования (user stories, use cases, SRS, NFR)

критерии приемки

модели процессов и данных

Если этого не сделать, изменение существует только в обсуждениях и неизбежно теряется.

Трассируемость: как быстро понять влияние и покрытие

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

Практический смысл трассируемости:

понять, зачем существует требование (связь с целью и стейкхолдером)

понять, что менять, когда приходит change request

доказать, что всё важное проверено (связь с тестами и UAT)

не забыть обновить документацию и релизные материалы

В стандартах требований трассируемость рассматривается как важная характеристика качества требований, например в контексте подходов к спецификации требований: ISO/IEC/IEEE 29148.

Что именно связывать

Минимально полезные связи в разработке ПО:

цель продукта → эпик/фича

эпик/фича → user stories или требования SRS

требование → критерии приемки

критерии приемки → тест-кейсы (QA)

тест-кейсы и критерии → UAT сценарии

требования → релиз (где это поставлено)

Матрица трассируемости требований

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

Общее понятие матрицы: Requirements traceability matrix.

Пример минимальной матрицы трассируемости:

| ID | Требование | Связанная цель | Критерии приемки | Проверка QA | UAT | Релиз | |---|---|---|---|---|---|---| | FR-12 | Показать причину возврата в карточке заказа | Сократить время обработки обращений | AC-12.1..AC-12.3 | TC-45 | UAT-07 | 1.4.0 | | NFR-03 | Поиск заказа по номеру: 95% запросов до 2 секунд | Сократить время обработки обращений | AC-NFR-03 | LT-02 | UAT-NFR-01 | 1.4.0 |

Заметьте, что в таблице одновременно видны:

зачем (цель)

что (требование)

как принимаем (критерии)

как проверяем (QA и UAT)

когда поставили (релиз)

Практики, которые поддерживают трассируемость без бюрократии

единые идентификаторы требований и тестов

обязательная ссылка на цель или эпик для каждой истории

привязка change request к затронутым элементам backlog

регулярный refinement, где уточняются связи и зависимости

Частая ошибка: пытаться делать трассируемость как “большой документ раз в квартал”. Практичнее держать её живой через связи в рабочих артефактах.

Коммуникации: чтобы изменения не превращались в сюрпризы

Коммуникации в бизнес-анализе — это не “просто сообщить”. Это управляемый процесс, который:

доставляет информацию нужным людям

в нужное время

в нужном формате

с понятными решениями и следующими шагами

Коммуникационный план

Коммуникационный план можно держать очень простым: кто, о чём, как часто и в каком канале.

Пример структуры:

| Аудитория | Что им важно | Формат | Частота | Выход | |---|---|---|---|---| | Заказчик/спонсор | цели, статус, риски, бюджет | статус-митинг | раз в 1–2 недели | решения, приоритеты | | Пользователи/предметные эксперты | сценарии, правила, удобство | воркшоп, демо | по мере готовности | подтверждение, правки | | Разработка/QA | однозначность, критерии, зависимости | refinement, Q&A | регулярно | готовность к спринту | | Поддержка/операции | изменения поведения, FAQ | релиз-ноты, обучение | перед релизом | готовность поддержки |

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

Журнал решений и журнал изменений

Два коротких артефакта резко снижают количество конфликтов:

журнал решений: что решили, когда, кто утвердил, на что влияет

журнал изменений: что изменилось в требованиях и почему

Это особенно важно, когда один и тот же вопрос обсуждают в разных чатах и встречах.

UAT: пользовательская приёмка как проверка пригодности

UAT (User Acceptance Testing) — пользовательское приёмочное тестирование. Его цель: подтвердить, что решение подходит пользователям и бизнесу в реальных сценариях.

Терминология приемочного тестирования широко используется в тестировании ПО: Acceptance testing в глоссарии ISTQB.

Чем UAT отличается от QA-тестирования

QA-тестирование отвечает на вопрос: соответствует ли система спецификациям и техническим ожиданиям качества

UAT отвечает на вопрос: может ли бизнес реально работать в системе и принимать результат

UAT не заменяет QA. Если на UAT находят много базовых дефектов, это сигнал, что входные критерии UAT были нарушены.

Когда проводить UAT

UAT обычно проводят, когда:

реализована функциональность, входящая в согласованный объём

выполнено системное тестирование

есть согласованные критерии приемки и сценарии UAT

подготовлено окружение и тестовые данные, близкие к реальным

Подготовка UAT

Чтобы UAT не превратился в хаотичное “покликайте и скажите”, подготовку стоит вести как мини-проект.

Рекомендуемый набор:

Определить scope UAT

Сформировать UAT-сценарии

Подготовить тестовые данные

Назначить роли и ответственность

Согласовать критерии входа и выхода

Настроить процесс обработки результатов

#### Scope UAT

Scope UAT должен быть связан с границами и приоритетами:

какие Must/Should сценарии обязательно пройти

какие интеграции и роли критичны

какие NFR проверяются пользователями (например, удобство, доступность)

#### UAT-сценарии

Лучший источник UAT-сценариев:

ключевые use cases

user stories с критериями приемки

модели процесса to-be (BPMN), чтобы покрыть реальные ветвления

Каждый сценарий UAT должен иметь:

роль пользователя

предусловия и данные

шаги

ожидаемый результат

ссылку на требования или историю

#### Роли в UAT

Минимально нужно договориться о следующем:

кто выполняет сценарии (представители пользователей)

кто принимает итоговое решение (заказчик или уполномоченный представитель)

кто принимает дефекты и решает, блокируют ли они релиз (triage)

кто помогает пользователям (аналитик, QA, поддержка)

Результаты UAT и приёмка

Результат UAT должен быть формализован, иначе легко получить спор “мы же говорили, что почти нормально”.

Практичный формат итогов:

список пройденных сценариев и их статус

список дефектов и замечаний

классификация замечаний

решение о релизе

Классификация обычно включает:

блокирующие дефекты

критичные, но с временным обходом

улучшения (в backlog)

Релизы: как упаковать изменения для поставки

Релиз — это управляемая поставка изменений пользователям. Важно разделять понятия:

deployment: техническое развертывание кода

release: выпуск функциональности для пользователей и бизнеса, включая коммуникации, поддержку и правила включения

Общее понятие управления релизами часто обсуждается как дисциплина: Release management.

Что должен обеспечить бизнес-анализ в релизном контуре

Бизнес-анализ помогает сделать релиз предсказуемым через:

подтверждение, что в релиз входят только валидированные и готовые элементы backlog

финализацию критериев приемки на уровне релиза

готовность UAT и приёмки

подготовку понятных релизных коммуникаций

Release notes: коммуникация с пользователями и поддержкой

Release notes — это не “список коммитов”. Это объяснение изменения поведения системы.

Практичная структура release notes:

что нового (для каких ролей)

что изменилось (важные изменения поведения)

что исправлено (в пользовательских терминах)

что важно знать (ограничения, новые правила, миграции)

обратная связь: куда писать и что прикладывать

Версионирование

Если продукт поставляется версиями, удобно использовать согласованный подход к версиям. Один из самых известных подходов: Semantic Versioning.

Смысл семантического версионирования в том, что номер версии сигнализирует о характере изменений:

совместимые улучшения

исправления

несовместимые изменения

Даже если команда не использует SemVer строго, сама идея полезна для коммуникаций: пользователи и поддержка понимают масштаб изменения.

Контроль рисков релиза

Чтобы релиз не превращался в “ночной прыжок веры”, на практике заранее обсуждают:

план отката (что делаем, если всё плохо)

мониторинг после релиза (какие метрики и логи смотрим)

окно релиза и коммуникации (когда и кого предупреждаем)

обучение и инструкции для поддержки

Сквозная связка: от изменения до релиза

Ниже — пример того, как все элементы темы связываются в одну линию.

!Сквозная цепочка от цели до проверки и релиза

Практический эффект такой цепочки:

когда приходит change request, вы быстро находите затронутые истории, тесты, UAT и релизные материалы

когда релиз готовится, вы быстро проверяете покрытие Must-требований и наличие приёмки

когда возникает инцидент после релиза, вы понимаете, какие изменения могли повлиять на поведение

Типичные ошибки и как их предотвращать

ошибка: изменения обсуждаются, но не отражаются в backlog и требованиях

профилактика: обязательный change request и обновление источника правды

ошибка: нет трассируемости, влияние изменений оценивается “на глаз”

профилактика: минимальная матрица или связи в инструментах, привязка к целям и тестам

ошибка: UAT проводят без сценариев и без критериев входа

профилактика: UAT-сценарии из критериев приемки и моделей, заранее согласованные вход/выход

ошибка: релизные коммуникации отсутствуют, поддержка узнаёт постфактум

профилактика: release notes и подготовка поддержки как часть Definition of Done на релиз

Итоги

Управление изменениями, трассируемость, UAT и релизы связывают аналитику с реальной поставкой ценности.

управление изменениями делает эволюцию требований контролируемой

трассируемость позволяет оценивать влияние и доказывать покрытие целей и требований

UAT подтверждает пригодность решения для бизнеса и пользователей

релизы требуют коммуникаций, подготовки поддержки и прозрачной упаковки изменений

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