Системный анализ для Junior: практический курс

Сбор и формализация требований: от слов заказчика к чёткому ТЗ

Представьте: заказчик говорит «мне нужна система для управления складом», а через три месяца выясняется, что он имел в виду не учёт товаров, а роботизированную сортировку с интеграцией в 1С. Кто виноват? Тот, кто не собрал требования правильно. Сбор и формализация требований — это фундамент, на котором строится всё остальное: архитектура, документация, сроки и бюджет. Если здесь ошибиться, дальше всё пойдёт по наклонной.

Почему заказчик не может сказать, чего хочет

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

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

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

Алгоритм сбора требований: пять шагов

Шаг 1. Интервью с заказчиком. Не спрашивайте «что вы хотите?» — это слишком широко. Задавайте наводящие вопросы: «Опишите типичный рабочий день сотрудника, который будет работать с системой», «Что сейчас занимает больше всего времени?», «Что происходит, когда что-то идёт не так?» Записывайте всё дословно, не фильтруя.

Шаг 2. Наблюдение за процессом. Если есть возможность — посмотрите, как работают люди прямо сейчас. Часто заказчик описывает идеальный процесс, а на деле сотрудники обходят систему через Excel или мессенджеры. Именно эти обходные пути показывают реальные боли.

Шаг 3. Классификация требований. Разложите всё собранное по трём корзинам: бизнес, пользователи, функционал. Один и тот же запрос может порождать требования на всех трёх уровнях. Например, фраза «чтобы не терялись заказы» превращается в бизнес-требование «снизить процент потерянных заказов до 0,5%», пользовательское «менеджер получает уведомление о новом заказе в течение 30 секунд» и функциональное «система отправляет push-уведомление через WebSocket при создании заказа».

Шаг 4. Приоритизация. Не все требования равнозначны. Используйте метод MoSCoW для расстановки приоритетов:

| Категория | Значение | Пример | |-----------|----------|--------| | Must have | Без этого система не работает | Авторизация пользователей | | Should have | Сильно улучшает продукт | Экспорт отчётов в Excel | | Could have | Приятное дополнение | Тёмная тема интерфейса | | Won't have | Не в эту версию | Мобильное приложение |

Шаг 5. Формализация в документ. Собранные требования нужно оформить в структурированный документ — модель требований. Каждое требование получает уникальный идентификатор (BR-001 для бизнеса, UR-001 для пользовательских, FR-001 для функциональных), описание, приоритет и критерий приёмки.

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

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

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

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

Практический приём: карта требований

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

Карта требований — это живой документ. Он обновляется на протяжении всего проекта и становится главным ориентиром при принятии решений. Когда разработчик спрашивает «а зачем нам это делать?» — вы показываете путь от функционального требования вверх к бизнес-цели. Это убивает 90% лишних споров.

Визуализация бизнес-процессов и потоков данных: BPMN и UML на практике

Когда вы описываете процесс словами, каждый участник понимает его по-своему. Бухгалтер думает, что согласование происходит до оплаты, а менеджер — что после. Визуализация убирает эти разночтения: диаграмма не оставляет места для интерпретаций. Два главных инструмента для этого — BPMN для бизнес-процессов и UML для моделирования систем и потоков данных.

BPMN: язык бизнес-процессов

BPMN (Business Process Model and Notation) — это стандарт нотации для описания бизнес-процессов. Его сила в том, что диаграммы BPMN понимают и аналитики, и менеджеры, и разработчики. Это мост между бизнесом и технической командой.

Базовый элемент BPMN — процесс, который состоит из событий, задач и шлюзов. Событие — это что-то, что происходит (круг). Задача — действие, которое кто-то выполняет (прямоугольник с закруглёнными углами). Шлюз — точка принятия решения (ромб).

Рассмотрим на примере процесса обработки заказа в интернет-магазине:

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

> Главное правило BPMN: диаграмма должна быть читаема без пояснений. Если вам нужно объяснять, что означает элемент — диаграмма плохая.

Когда BPMN недостаточно: уровни детализации

BPMN отлично работает на уровне «что делает бизнес», но когда нужно показать, как данные перемещаются между компонентами системы, на помощь приходит UML (Unified Modeling Language).

В системном анализе для Junior наиболее полезны три типа UML-диаграмм:

Диаграмма вариантов использования (Use Case Diagram) показывает, кто и с чем взаимодействует. Акторы (человечки) связаны линиями с овалами (вариантами использования). Например, «Клиент» связан с «Оформить заказ», «Менеджер» — с «Просмотреть заказы» и «Изменить статус». Эта диаграмма отвечает на вопрос: «Кто что может делать в системе?»

Диаграмма классов (Class Diagram) описывает структуру данных. Класс — прямоугольник с тремя секциями: название, атрибуты, методы. Связи между классами показывают отношения: наследование (пустой треугольник), ассоциация (линия), композиция (закрашенный ромб). Например, класс «Заказ» содержит атрибуты id, дата, статус и связан с классом «Товар» отношением «содержит».

Диаграмма последовательности (Sequence Diagram) показывает взаимодействие объектов во времени. По вертикали — линии жизни объектов, по горизонтали — сообщения между ними. Это ключевая диаграмма для описания интеграций: вы видите, какой запрос уходит от клиента к серверу, что сервер отправляет в базу данных, и какой ответ возвращается.

Практический подход: когда что использовать

Не существует одной «правильной» диаграммы. Выбор зависит от аудитории и задачи:

| Задача | Инструмент | Аудитория | |--------|-----------|-----------| | Описать текущий процесс компании | BPMN | Бизнес, руководство | | Показать, кто какие функции выполняет | Use Case | Заказчик, аналитик | | Описать структуру данных | Class Diagram | Разработчики, архитектор | | Показать взаимодействие систем | Sequence Diagram | Разработчики, DevOps |

На практике вы будете использовать несколько диаграмм одновременно. BPMN-диаграмма бизнес-процесса содержит задачу «Проверить оплату», а Sequence Diagram детализирует, как именно система обращается к платёжному шлюзу.

Типичные ошибки Junior-аналитика

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

Вторая ошибка — отсутствие нотации. Рисовать «как удобно» — плохая идея, потому что через полгода вы сами не поймёте, что имели в виду. Используйте стандартные обозначения BPMN 2.0 и UML 2.5. Даже если заказчику всё равно, разработчики будут вам благодарны.

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

Инструменты для создания диаграмм

Для работы подойдут как специализированные, так и универсальные инструменты. draw.io (бесплатный, работает в браузере) — отличный старт для Junior. Enterprise Architect — профессиональный инструмент с поддержкой всех нотаций UML и BPMN. Miro и Figma подходят для быстрых набросков и обсуждений с командой, но не для финальных спецификаций.

Начните с draw.io: создайте BPMN-диаграмму процесса из вашей текущей работы или учёбы, а затем попробуйте описать тот же процесс через Sequence Diagram. Это упражнение быстро покажет разницу между «что делает бизнес» и «как это работает технически».

Проектирование архитектуры и интеграций: REST, SOAP и асинхронные взаимодействия

Система, которая работает в изоляции, — редкость. Практически каждый проект требует обмена данными с внешними сервисами: платёжными шлюзами, CRM, ERP, государственными порталами. Junior-аналитику не обязательно проектировать архитектуру с нуля, но он обязан понимать, как системы общаются между собой, чтобы грамотно описать интеграции в документации и не пропустить критичные детали.

Три способа, которыми системы разговаривают друг с другом

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

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

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

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

REST API: три принципа взаимодействия

REST (Representational State Transfer) — архитектурный стиль, который стал стандартом для веб-интеграций. Если вы работаете с современными веб-сервисами, с вероятностью 90% вы столкнётесь именно с REST.

Три ключевых принципа, которые нужно знать аналитику:

Ресурсно-ориентированный подход. В REST всё — это ресурс с уникальным адресом (URL). Заказ — это ресурс /orders/123, клиент — ресурс /clients/456. Вы работаете с ресурсами через стандартные HTTP-методы: GET (получить), POST (создать), PUT (обновить целиком), PATCH (частично обновить), DELETE (удалить).

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

Единообразный интерфейс. Все API выглядят одинаково: одинаковые форматы запросов и ответов (обычно JSON), одинаковые коды ошибок (200 — успех, 404 — не найдено, 500 — ошибка сервера).

Когда вы описываете REST-интеграцию в документации, фиксируйте: endpoint (URL), метод HTTP, формат тела запроса, формат ответа, коды ошибок и примеры. Например:

Ответ: 201 Created с телом, содержащим order_id и status.

SOAP: когда нужен строгий контракт

SOAP (Simple Object Access Protocol) — более старый протокол, который до сих пор используется в корпоративных системах, банковских интеграциях и государственных сервисах. Главное отличие от REST: SOAP опирается на строгий контракт — WSDL-файл, который описывает все доступные операции, их параметры и форматы данных.

SOAP использует XML для всех сообщений, что делает их громоздкими, но строго структурированными. Если REST — это разговор на свободные темы, то SOAP — это заполнение официального бланка: каждое поле на своём месте, каждое значение проверяется.

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

Очереди сообщений: асинхронные интеграции

Когда два сервиса не должны ждать друг друга, используются очереди сообщений (message queues): RabbitMQ, Apache Kafka, Amazon SQS. Отправитель кладёт сообщение в очередь и забывает о нём. Получатель забирает сообщение, когда готов.

Пример из жизни: интернет-магазин получает заказ. Система не ждёт, пока складская система обработает запрос — она кладёт сообщение «Новый заказ #123» в очередь и сразу показывает клиенту «Заказ принят». Складская система подхватывает сообщение из очереди через секунду или через минуту — и начинает обработку.

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

Как выбирать протокол интеграции

Не существует универсального ответа «всегда используй REST». Выбор зависит от контекста:

| Критерий | REST | SOAP | Очереди | |----------|------|------|---------| | Нужен мгновенный ответ | Да | Да | Нет | | Строгий контракт обязателен | Нет | Да | Нет | | Высокая нагрузка | Хорошо | Плохо | Отлично | | Корпоративные системы | Редко | Часто | Иногда | | Мобильные клиенты | Идеально | Не подходит | Не подходит |

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

Что Junior-аналитик должен проверить при проектировании интеграции

Прежде чем описать интеграцию в документации, убедитесь, что ответили на пять вопросов: что именно передаётся (структура данных), в каком направлении (односторонняя или двусторонняя), синхронно или асинхронно, что происходит при сбое (retry, dead letter queue, ручная обработка), и как аутентифицируется запрос (токен, сертификат, API-ключ). Если хотя бы на один вопрос нет ответа — вернитесь к архитектору или разработчику, прежде чем фиксировать интеграцию в документе.

Написание технической документации: ТЗ и спецификации для бизнеса и разработчиков

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

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

Бизнес-заказчик читает документацию и хочет видеть: зачем это нужно, что получит пользователь, когда будет готово. Разработчик читает ту же документацию и хочет видеть: какие endpoint вызывать, какую структуру данных использовать, какие граничные случаи обрабатывать. Если вы пишете один документ для всех — он неудобен каждому.

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

Бизнес-спецификация: пишем для заказчика

Бизнес-спецификация отвечает на три вопроса: что будет сделано, зачем это нужно и как проверить, что всё работает.

Структура бизнес-спецификации:

> Бизнес-спецификацию должен понимать человек без технического образования. Если заказчик переспрашивает «а что это значит?» — перепишите.

Техническое задание: пишем для разработчиков

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

Структура ТЗ:

Чек-лист качественной документации

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

Формат и инструменты

Для бизнес-спецификации подойдут Google Docs или Confluence — заказчику удобно комментировать и вносить правки прямо в текст. Для ТЗ лучше использовать Confluence с шаблонами или Notion с базами данных — там удобно связывать требования с задачами в трекере.

Важный принцип: документация должна жить рядом с кодом. Если вы используете Confluence — привязывайте страницы к задачам в Jira. Если используете Notion — связывайте требования с эпиками. Документация, которая лежит отдельно от проекта, быстро устаревает и перестаёт использоваться.

Частая ошибка: писать слишком много или слишком мало

Junior-аналитики часто грешат двумя крайностями. Первая — избыточная детализация: описывать каждую кнопку и каждый цвет интерфейса в ТЗ. Это задача дизайнера, не аналитика. Вторая — недостаточная детализация: писать «система должна корректно обрабатывать заказы» без уточнения, что значит «корректно».

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

Анализ и оптимизация существующих системных решений

Когда вы приходите в проект, система почти наверняка уже существует — и почти наверняка в ней есть проблемы. Медленные запросы, дублирование данных, хрупкие интеграции, бизнес-процессы, которые обросли костылями за годы. Задача системного аналитика — не просто найти проблемы, а предложить конкретные пути решения с оценкой затрат и эффекта. Это навык, который отличает Junior от Middle.

С чего начинать анализ существующей системы

Первый шаг — не лезть в код и не слушать мнения. Начните с документирования текущего состояния. Это называется as-is анализ — фиксация того, как система работает прямо сейчас, безоценочно.

Проведите три вида исследований:

Интервью с пользователями. Спросите, что работает хорошо, что раздражает, какие обходные пути используются. Если сотрудники ведут параллельный Excel-файл «потому что в системе это неудобно» — это сигнал о проблеме в системе.

Анализ метрик и логов. Попросите у разработчиков или DevOps данные: время отклика API, количество ошибок в логах, пиковые нагрузки. Цифры не врут — если 40% запросов к эндпоинту /search выполняются дольше 3 секунд, это конкретная проблема, которую нужно решать.

Маппинг процессов. Нарисуйте текущие бизнес-процессы в BPMN (как мы делали в статье о визуализации). Сравните «как задумано» с «как работает на самом деле». Расхождения — это зоны оптимизации.

Метод выявления узких мест: Value Stream Mapping

Value Stream Mapping (VSM) — метод, который показывает, где в процессе теряется время и ресурсы. Для каждого шага процесса фиксируются два показателя: время обработки (время, которое шаг реально выполняется) и время ожидания (время, которое заявка лежит без движения).

Пример: обработка заказа в интернет-магазине.

| Шаг | Время обработки | Время ожидания | |-----|----------------|----------------| | Приём заказа | 2 мин | 0 | | Проверка оплаты | 1 мин | 45 мин | | Согласование с кладовщиком | 5 мин | 3 часа | | Сборка заказа | 20 мин | 0 | | Передача в доставку | 2 мин | 1 час |

Суммарное время обработки: 30 минут. Суммарное время ожидания: 4 часа 46 минут. Соотношение показывает, что 90% времени заказ просто лежит. Оптимизация ожиданий (автоматическая проверка оплаты вместо ручной, уведомления кладовщику вместо согласования) даст эффект в разы больший, чем ускорение сборки заказа.

Три типа проблем и как их классифицировать

После сбора данных классифицируйте найденные проблемы по трём категориям:

Архитектурные проблемы. Система построена так, что масштабирование невозможно без переписывания. Монолит, в котором все модули связаны жёсткими зависимостями. Единая база данных, которая не выдерживает нагрузку. Эти проблемы решаются долго и дорого, но без них система деградирует.

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

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

Как формулировать рекомендации

Нахождение проблемы — это только половина работы. Вторая половина — предложить решение с оценкой. Каждая рекомендация должна содержать четыре компонента:

Без четвёртого пункта заказчик не сможет принять решение. Рекомендация «нужно переписать систему с нуля» без оценки сроков и бюджета — это не рекомендация, а паника.

Метод приоритизации оптимизаций: матрица усилий и эффекта

Когда у вас десяток проблем и все кажутся важными, используйте матрицу Effort-Impact. По одной оси — усилия на исправление (от низких к высоким), по другой — ожидаемый эффект (от низкого к высокому).

| | Низкий эффект | Высокий эффект | |---|---|---| | Низкие усилия | Сделать в фоне | Сделать первым | | Высокие усилия | Отложить | Запланировать |

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

Типичные ловушки анализа

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

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

Третья ловушка — анализ без действий. Отчёт об анализе, который ложится на полку — пустая трата времени. Каждая рекомендация должна превращаться в задачу в трекере с ответственным и сроком. Если вы не можете проследить, что ваш анализ привёл к конкретным изменениям — значит, процесс анализа работает плохо.

Практический подход: начните с малого

Не пытайтесь проанализировать всю систему за неделю. Выберите один бизнес-процесс или один модуль, проведите as-is анализ, нарисуйте текущее состояние, найдите 2-3 узких места и предложите оптимизации с оценкой. Покажите результат заказчику. Когда вы докажете ценность анализа на маленьком масштабе, вам доверят анализировать более сложные и критичные части системы.

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