Урок 01.01: Что такое системный анализ

Цель урока

Понять суть системного анализа, разобрать понятие «система» на конкретных примерах, определить место системного анализа в ИТ-проектах и научиться разграничивать роли бизнес-аналитика (БА) и системного аналитика (СА) через реальные рабочие кейсы.

Ключевые понятия

• Система — совокупность взаимосвязанных элементов, объединённых для достижения общей цели и образующих целостность, которая обладает свойствами, отсутствующими у каждого элемента по отдельности (эмерджентность)
• Системный анализ — научно-прикладная методология исследования и проектирования сложных систем, основанная на рассмотрении объекта как единого целого с учётом всех внутренних и внешних связей
• Системный аналитик (СА / SA) — специалист, который переводит бизнес-потребности на язык технических требований и выступает мостом между заинтересованными сторонами (бизнесом) и командой разработки
• Бизнес-аналитик (БА / BA) — специалист, который изучает бизнес-процессы, выявляет проблемы и формулирует бизнес-потребности, отвечая на вопрос «ЧТО нужно сделать, чтобы достичь цели бизнеса?»
• Эмерджентность — свойство системы, которое возникает только при взаимодействии её частей и не сводится к сумме свойств отдельных элементов
• AS-IS / TO-BE — модели текущего («как есть») и целевого («как будет») состояния системы

---

1. Понятие «Система»: глубинный разбор

1.1. Определение из теории систем

В системном анализе система — это не просто «набор компонентов». Это целостный объект, в котором:

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

Формула системы:

Система = Элементы + Связи + Цель + Границы

1.2. Пример 1: Банкомат (ATM) как система

Рассмотрим обычный банкомат. На первый взгляд это просто «железный ящик с деньгами». С точки зрения системного анализа это сложная система.

Элемент системы	Описание
Аппаратная часть	Дисплей, клавиатура / сенсорный экран, купюроприёмник, диспенсер наличных, ридер карт, принтер чеков, сейфовый модуль
Программное обеспечение	Операционная система (обычно Windows Embedded / Linux), прикладное ПО банкомата, модуль связи с банком
Сетевые компоненты	GSM-модуль / Ethernet-адаптер, VPN-туннель к процессинговому центру
Человеческие элементы	Пользователь (клиент), инкассатор, техник, служба мониторинга, сотрудник колл-центра

Связи между элементами:

• Пользователь → вставляет карту → ридер отправляет данные в ПО → ПО запрашивает авторизацию банка → банк проверяет PIN и баланс → ПО даёт команду диспенсеру → диспенсер выдаёт купюры → принтер печатает чек.

Эмерджентное свойство: Ни один компонент банкомата по отдельности не способен «выдать деньги клиенту» — это возникает только при слаженной работе всех элементов: карта должна быть считана, ПИН-код — проверен, баланс — подтверждён, купюры — отсчитаны и выданы. Это и есть эмерджентность: свойство всей системы, не сводимое к свойствам частей.

Границы системы: Банкомат как система включает в себя сам аппарат и программный модуль на его стороне. Внешняя среда (надсистема) — это банковская процессинговая система, которая обрабатывает запросы авторизации. Когда аналитик проектирует банкомат, он чётко определяет: «Что внутри системы? А что снаружи и является внешним сервисом?».

1.3. Пример 2: Интернет-магазин как система

Возьмём типичный интернет-магазин (например, условный «Ozon» или «Wildberries»).

Элемент	Описание
Frontend	Веб-сайт (каталог, корзина, личный кабинет) + мобильное приложение
Backend	API-шлюз, сервис товаров, сервис корзины, сервис заказов, сервис оплаты, сервис доставки
База данных	PostgreSQL — каталог товаров, MySQL — заказы, Redis — корзина и сессии
Интеграции	Платёжный шлюз (Сбербанк / ЮKassa), служба доставки (СДЭК / Почта России), CRM (AmoCRM), E-mail-провайдер (SendGrid)
Стейкхолдеры	Покупатель, продавец, администратор магазина, курьер, служба поддержки

Взаимодействие элементов: Покупатель заходит на сайт → фронтенд загружает каталог из API → API запрашивает товары из БД → покупатель добавляет товары в корзину (данные хранятся в Redis) → оформляет заказ → сервис заказов резервирует товар → сервис оплаты отправляет запрос в платёжный шлюз → при успехе — сервис доставки создаёт заявку в СДЭК.

Эмерджентное свойство: Свойство «возможность купить товар онлайн, не выходя из дома» не принадлежит ни одному модулю по отдельности. База данных «не знает», что такое покупка. Фронтенд без бэкенда — просто картинки. Только соединение всех модулей рождает интернет-магазин как сервис.

AS-IS и TO-BE для интернет-магазина:

• AS-IS: Заказы принимаются по телефону, менеджер вручную проверяет наличие, выписывает счёт в Excel.
• TO-BE: Автоматизированный интернет-магазин с онлайн-оплатой, автоматическим резервированием и интеграцией со службой доставки.

Задача аналитика — описать оба состояния и проложить мост между ними.

1.4. Свойства системы (краткий чек-лист для аналитика)

Свойство	Вопрос, который должен задать аналитик
Целостность	Можно ли выделить систему как единый объект?
Связность	Как элементы влияют друг на друга?
Эмерджентность	Появляется ли новое свойство при объединении?
Иерархичность	В какую надсистему входит система? Есть ли подсистемы?
Открытость	Система обменивается данными с внешней средой?
Адаптивность	Может ли система подстраиваться под изменения?

---

2. Определение системного анализа

Системный анализ — это методология исследования сложных объектов, которая:

1. Рассматривает объект как систему (а не как разрозненные части);
2. Изучает внутренние и внешние связи системы;
3. Выявляет проблемы и узкие места;
4. Формулирует требования к новой или изменяемой системе (TO-BE);
5. Обеспечивает прослеживаемость (traceability) от бизнес-целей до конкретных технических решений.

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

2.1. Место системного анализа в жизненном цикле проекта

┌──────────────────┐
│  Бизнес-анализ   │ ← Что бизнесу нужно?
│  (идея, кейс)    │
└────────┬─────────┘
         ↓
┌──────────────────┐
│ Системный анализ │ ← Как это реализовать технически?
│  (требования,    │
│   спецификация)  │
└────────┬─────────┘
         ↓
┌──────────────────┐
│   Разработка     │ ← Кодирование
└────────┬─────────┘
         ↓
┌──────────────────┐
│  Тестирование    │ ← Верификация и валидация
└──────────────────┘

---

3. Задачи системного аналитика

Системный аналитик решает широкий спектр задач. Вот полный перечень с пояснениями:

Анализ и исследование

• Анализ предметной области — погружение в бизнес-логику проекта (например, как работает расчёт доставки в интернет-магазине)
• Сбор и выявление требований — проведение интервью, анкетирование, изучение документов
• Моделирование бизнес-процессов (AS-IS / TO-BE) — описание текущих и целевых процессов в BPMN / нотации потоков работ
• Анализ рисков и ограничений — выявление технических, временных и бизнес-ограничений

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

• Функциональная декомпозиция — разбиение большой системы на модули и компоненты
• Разработка Use Case / User Stories — описание сценариев использования системы
• Проектирование API-контрактов — спецификация эндпоинтов (REST / gRPC) в OpenAPI
• Проектирование модели данных — ER-диаграммы, Data Dictionary, DDL-скрипты
• Разработка прототипов интерфейсов — wireframes (совместно с UX/UI-дизайнером)

Коммуникация

• Мост между бизнесом и IT — перевод бизнес-требований на язык разработчиков
• Фасилитация воркшопов — организация совместных сессий с заказчиком и командой
• Согласование требований — защита решений перед заказчиком и архитектором

Сопровождение

• Уточнение требований в процессе разработки (Agile-циклы)
• Ревью тест-кейсов — проверка, что тесты покрывают все требования
• Приёмка (UAT) — помощь заказчику в приёмочном тестировании
• Ведение матрицы трассировки — связь требования → дизайн → код → тест

---

4. Системный аналитик vs Бизнес-аналитик: полное сравнение

4.1. Базовая таблица различий

Критерий	Бизнес-аналитик (БА)	Системный аналитик (СА)
Основной вопрос	«Зачем и что делаем?»	«Как именно сделаем?»
Уровень абстракции	Бизнес-процессы, стратегия	Система, архитектура, данные
Продукт работы	Concept Document, Business Case, User Story Map	SRS, API-контракт, UML-диаграммы, SQL-скрипты
С кем общается	Заказчик, Product Owner, стейкхолдеры	Архитектор, разработчики, QA
Глубина технических знаний	Средняя (понимает ограничения)	Высокая (может обсуждать детали реализации)
Инструменты	Miro, Visio, Confluence, Excel	Draw.io / PlantUML, Swagger, DBeaver, Postman
Результат	Бизнес-требования (BRD)	Системные требования (SRS)
Фокус	Проблема бизнеса	Решение системы

4.2. Ключевые отличия в мышлении

Ситуация	Мыслит БА	Мыслит СА
Заказчик говорит: «Нужна отчётность»	«Какие метрики важны для бизнеса? Кто будет смотреть отчёты? Как часто?»	«Из каких источников берутся данные? Как часто обновляются? Какой формат выгрузки? Сколько записей?»
Заказчик говорит: «Интеграция с 1С»	«Какие данные нужно передавать? Какой бизнес-процесс автоматизируем?»	«Какой протокол (REST / SOAP / FILE)? Какая схема данных? Как обрабатывать ошибки? Как часто синхронизация?»
Заказчик говорит: «Мобильное приложение»	«Кто целевая аудитория? Какой функционал нужен на старте? Какая модель монетизации?»	«iOS / Android / Cross-platform? Какой API нужен? Кеширование? Оффлайн-режим? Push-уведомления?»

4.3. Где проходит граница?

Граница между БА и СА размыта и сильно зависит от размера компании:

• В стартапах и маленьких командах (до 10–15 человек): БА и СА — один человек (обобщённый «аналитик»). Он и с бизнесом говорит, и API рисует.
• В средних компаниях (50–200 человек): БА работает «снаружи» (с бизнесом), СА — «внутри» (с IT). БА отдаёт СА бэклог User Stories, СА детализирует их до технических задач.
• В крупных компаниях и корпорациях: БА работает на уровне направлений и стратегии, СА привязан к конкретной команде разработки. Может быть несколько СА на одного БА.

---

5. Реальные рабочие кейсы: пересечение и разделение БА и СА

Кейс 1. «Электронный документооборот для логистической компании»

Контекст: Крупная транспортная компания внедряет систему электронного документооборота (ЭДО) для замены бумажных накладных.

Роль БА:

• Проводит интервью с начальниками отделов: «Какие документы сейчас используются? Какие проблемы с бумажным документооборотом? Какой процесс согласования?»
• Описывает AS-IS процесс: «Водитель привозит бумажную накладную → диспетчер проверяет → относит в бухгалтерию → бухгалтер вводит в 1С → подписывает у руководителя».
• Формулирует бизнес-потребность: «Сократить время обработки накладной с 2 дней до 2 часов».

Роль СА:

• Получает от БА описание бизнес-процесса и бизнес-требования.
• Проектирует интеграцию с 1С: «API 1С будет отдавать данные по REST, формат JSON, аутентификация по OAuth 2.0».
• Описывает Use Case «Подписание документа ЭЦП»: актёр — руководитель, пред-условие — документ загружен, основной поток — выбор документа → нажатие «Подписать» → вызов КриптоПро → сохранение статуса.
• Строит ER-диаграмму: сущности «Документ», «Статус», «Пользователь», «ЭЦП».

Пересечение: БА и СА совместно участвуют в воркшопе по моделированию TO-BE процесса. БА рисует процесс в BPMN «как будет», СА сразу отмечает, какие шаги потребуют технических доработок (интеграция, новый сервис, доработка БД).

Разделение: БА заканчивает работу на этапе утверждения бизнес-требований. СА продолжает — пишет SRS, согласует API-контракты с разработчиком 1С, участвует в ревью тест-кейсов.

---

Кейс 2. «Мобильное приложение для сети кофеен»

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

Роль БА:

• Изучает конкурентов (Starbucks, Coffee House) — какие функции есть у них.
• Опрашивает администраторов кофеен: «Какие проблемы с текущей картой лояльности (пластиковые карты)?».
• Составляет User Story Map: эпосы «Регистрация», «Предзаказ», «Оплата», «Баллы».
• Приоритизирует функции на MVP: «Предзаказ и оплата — MUST HAVE, программа лояльности — SHOULD HAVE, отзывы — COULD HAVE».

Роль СА:

• Разрабатывает архитектуру интеграции: мобильное приложение → API-шлюз → сервис заказов + сервис лояльности + платёжный шлюз + R-Keeper (кассовая система кофейни).
• Описывает OpenAPI-контракт для эндпоинта POST /api/v1/orders.
• Проектирует БД: таблицы users, orders, order_items, loyalty_points, menu.
• Пишет Sequence Diagram для сценария «Оплата заказа бонусами»: пользователь → приложение → сервис заказов → сервис лояльности (проверка баллов) → платёжный шлюз.

Пересечение: На этапе приоритизации MVP БА аргументирует «почему MUST», а СА оценивает «сколько это стоит в часах разработки» и «есть ли технические риски». Они вместе решают, что войдёт в спринт 1.

Разделение: БА продолжает работать с маркетингом по программе лояльности (правила начисления баллов, маркетинговые акции). СА проектирует техническую реализацию начисления баллов (триггеры, scheduled jobs, консистентность данных). Заказчик общается с БА; разработчики — с СА.

---

Кейс 3. «Миграция банковской системы с монолита на микросервисы»

Контекст: Банк с 20-летним legacy-монолитом на COBOL принимает решение поэтапно переезжать на микросервисную архитектуру (Java / Spring Boot + Kafka + Kubernetes).

Роль БА:

• Проводит сессии с бизнес-подразделениями (кредитный департамент, депозитный, валютный контроль): «Какие отчёты вы сейчас получаете из системы? Какие бизнес-правила нужно сохранить? Какой функционал критичен для бизнеса?».
• Описывает бизнес-процесс «Выдача кредита» целиком — от заявки до выдачи денег.
• Приоритизирует, какой функционал переезжает в первую очередь («low-hanging fruit»).

Роль СА:

• Анализирует legacy-код (с помощью статического анализа и reverse engineering): какие модули, какие таблицы, какие интеграции.
• Проектирует декомпозицию на микросервисы: «Сервис кредитных заявок», «Сервис принятия решений (Decision Engine)», «Сервис платежей», «Сервис клиентов».
• Определяет контракты между микросервисами: «Сервис А публикует событие CreditApplicationSubmitted в Kafka → Сервис Б подписывается и запускает скоринг».
• Описывает стратегию миграции данных (strangler fig pattern) и план обратной совместимости (versioned API).

Пересечение: БА и СА вместе анализируют бизнес-правила: БА описывает правило «Если сумма кредита > 1 млн и нет залога — требуется одобрение кредитного комитета», а СА переводит это в техническую спецификацию — проверка в Decision Engine, вызов внешнего workflow (Camunda BPM), уведомление в Telegram комитета.

Разделение: БА работает на уровне бизнеса — собирает требования от 5 департаментов, согласует сроки миграции с бизнес-заказчиками. СА работает на уровне архитектуры — проводит ADR (Architecture Decision Records), описывает схему данных для каждого микросервиса, согласует API-контракты с командами разработки. БА никогда не смотрит в legacy-код, СА почти никогда не общается напрямую с кредитным инспектором.

---

6. Ключевой вывод: паттерн взаимодействия БА и СА

БА и СА не конкуренты и не взаимозаменяемые роли. Это два звена одной цепи:

Заказчик -> (бизнес-потребность) -> БА -> (бизнес-требование) -> СА -> (системное требование) -> Разработчик

• БА отвечает на вопрос «ЧТО?» — что ценно для бизнеса, какую проблему решаем.
• СА отвечает на вопрос «КАК?» — как это технически реализовать, из каких компонентов, по каким протоколам.

На практике хороший СА понимает бизнес-контекст (без этого невозможно спроектировать адекватное решение), а хороший БА понимает технические ограничения (чтобы не обещать заказчику невозможного).

---

Вопросы для самопроверки

1. Назовите 5 признаков любой системы. Примените их к банкомату.
2. В чём проявляется эмерджентность интернет-магазина? Приведите пример свойства, которого нет ни у одного модуля по отдельности.
3. На какой вопрос отвечает БА (бизнес-аналитик), а на какой — СА (системный аналитик)?
4. В каком случае роли БА и СА может выполнять один человек? При каких условиях их обязательно разделяют?
5. По кейсу «Электронный документооборот»: как бы изменилась работа аналитиков, если бы компания выбрала SaaS-решение вместо кастомной разработки?
6. Придумайте собственный гипотетический проект и распределите зоны ответственности БА и СА.

---

Дополнительные материалы

• Книга: «Системное мышление» — Донелла Медоуз (Donella H. Meadows, «Thinking in Systems»)
• Книга: «Software Requirements» — Karl Wiegers, Joy Beatty (классика по работе с требованиями)
• Стандарт: ISO/IEC/IEEE 29148 — Systems and software engineering — Life cycle processes — Requirements engineering
• Инструмент: Draw.io / diagrams.net — бесплатное построение диаграмм любой сложности
• Чек-лист для начинающего аналитика: https://requirements.com/