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

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

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

Что входит в навык

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

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

Кому и зачем это нужно

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

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

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

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

Учебный пример: поле, которое бывает пустым

Учебная ситуация. Мобильное приложение программы лояльности отправляет на сервер анкету клиента. Поле «дата рождения» необязательное: если клиент его не заполнил, приложение передаёт значение null. Контракт API описан в формате OpenAPI 3.0, и в схеме у поля стоит type: string вместе с пометкой nullable: true. Всё работает.

Через год команда решает перевести описание на более новую версию формата и меняет в начале файла openapi: 3.0.3 на openapi: 3.1.0. Остальной текст не трогают. После выкладки часть клиентов не может сохранить анкету: сервер отвечает ошибкой проверки данных. Причина в том, как изменились сами правила описания схем.

В спецификации OpenAPI 3.0.3 объект Schema — расширенное подмножество черновика JSON Schema Wright Draft 00; тип там задаётся только строкой («Multiple types via an array are not supported»), а пустое значение разрешает отдельное поле nullable со значением по умолчанию false. В OpenAPI 3.1.0 от 15 февраля 2021 года объект Schema стал надмножеством JSON Schema Draft 2020-12, и поля nullable в нём больше нет. Так же устроена и версия 3.2.0 2025 года. Проверка по правилам JSON Schema не знает слова nullable и просто его пропускает, а от схемы остаётся type: string, то есть null больше не допускается.

Инициатива OpenAPI в руководстве по переходу с 3.0 на 3.1 называет ещё две такие замены. Вместо nullable: true пишут type: ["string", "null"]. Поле exclusiveMinimum раньше было флагом true или false при minimum, а теперь само содержит число: вместо пары minimum: 7 и exclusiveMinimum: true пишут exclusiveMinimum: 7. Одиночный example внутри схемы уступает место списку examples.

Для навыка из этой истории следуют три вывода. Контракт — такой же код, и смена версии формата требует ревью, а не замены одной строки. Тестировщику полезно держать отдельную проверку на null для каждого необязательного поля. А менеджеру проекта стоит закладывать время на миграцию описания API, даже если «функциональность не меняется».

В каком порядке осваивать

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

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

Третий шаг — данные и SQL. Достаточно уметь спроектировать несколько таблиц, связать их и написать запрос с объединением и группировкой. Четвёртый — HTTP и API: методы, коды ответов, формат JSON, чтение и составление описания в OpenAPI. Здесь помогает Postman или Swagger Editor, где можно сразу отправить запрос и посмотреть ответ.

Если нужна программа с практикой по всем этим этапам, на онлайн-курсе Skillbox «Системный аналитик + ИИ» за восемь месяцев собирают девять артефактов на одном сквозном кейсе: спецификацию, ER-диаграмму, SQL-запросы, схемы процессов, диаграммы последовательности, пользовательские истории, документацию OpenAPI и тест-кейсы.

Упражнения и частые ошибки

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

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

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

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

Если упражнения даются легко, потому что вы уже работаете с процессами, следующая ступень — интеграции и документация API. Для этого подойдёт онлайн-курс «Системный аналитик PRO» Нетологии: он рассчитан на тех, у кого уже есть опыт в аналитике или разработке, а в программе есть проектирование API, хранилища данных и моделирование процессов.

Как навык влияет на доход

Отдельной надбавки «за системный анализ» в вакансиях обычно нет. Навык влияет на доход иначе: он расширяет круг задач, которые человеку можно поручить, и открывает переход в соседние роли. Тестировщик, который пишет спецификации и тестирует API, может претендовать на позиции с интеграционным тестированием. Разработчик, способный сам разобрать требования, чаще получает задачи целиком, а не по готовому техническому заданию.

Ориентир по переходу в аналитику дают реальные зарплаты из анкет в калькуляторе Хабр Карьеры (Россия без фильтра по городу, данные на сентябрь 2026 года). Медиана зарплаты системного аналитика уровня Middle — 196 666 ₽, рассчитана по 1 208 анкетам. У инженера по ручному тестированию того же уровня медиана 142 666 ₽ по 783 анкетам. Это данные о фактических зарплатах, а не предложения работодателей, и разница отражает разные профессии, а не цену одного навыка. Чтобы перейти из тестирования в аналитику, одних знаний нотаций мало: нужны опыт общения с заказчиком и работы, которые можно показать.

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

Как выбрать обучение

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

Для самостоятельного темпа подойдёт онлайн-курс Eduson Academy «Системный аналитик с нуля до PRO + ИИ»: восемь месяцев без жёстких сроков, четыре блока — требования и сценарии, процессы и данные (BPMN, UML, EPC, IDEF, SQL), архитектура и интеграции (REST, SOAP, очереди сообщений), технический контекст с Git, Linux и DevOps. Практика построена на кейсах вроде перевода денег через приложение.

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

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