Системный аналитик переводит бизнес-задачу в точные правила работы IT-системы: данные, статусы, API, ошибки и критерии приёмки. SkillStat показывает зарплату, спрос и навыки.
Как ещё называют системного аналитика
В вакансиях и поисковых запросах роль называют по-разному. Смотрите не только на название, а на содержание: требования, API, данные, интеграции, статусы, ошибки и критерии приёмки.
Системный аналитик находится в верхней части спроса SkillStat: это роль, без которой сложные цифровые сервисы быстро тонут в недосказанных требованиях, спорных статусах и несогласованных интеграциях. Высокий текущий спрос стоит читать как признак устойчивой потребности, а не как доказательство резкого рыночного скачка. Для вывода о динамике важны график спроса, сглаженный ряд и состав вакансий, а не одна дневная точка.
Системный аналитик нужен там, где общей идеи уже недостаточно для разработки. Он не пересказывает пожелание бизнеса, а разбирает поведение будущего решения: кто запускает действие, какие поля обязательны, что происходит с данными, какой статус увидит пользователь и как система должна ответить на ошибку.
Например, запрос "добавить оплату частями" для него не заканчивается названием функции. Нужно понять, кто может выбрать такой способ оплаты, какие суммы доступны, что делать при отказе банка, когда заказ считается оплаченным, какие данные уйдут в учёт и как тестировщик проверит результат.
На выходе команда получает проверяемую модель изменения: сценарии, статусы, правила обработки, API, интеграции, ошибки и критерии приёмки. По этой модели разработчик пишет код, тестировщик проверяет поведение, а заказчик понимает, что именно будет сделано.
От бизнес-аналитика системного аналитика отличает техническая глубина. Бизнес-аналитик выясняет, что нужно изменить в процессе и зачем. Системный аналитик отвечает за следующий слой: как это изменение должно работать в приложении, данных, обменах, правах доступа, проверках и отказах.
Числовые метрики показывают вакансии Москвы и Московской области. Описание роли, задач и навыков относится к профессии в целом.
Актуальный срез по вакансиям, зарплате, спросу и динамике найма для системного аналитика в Москве и МО.
Системный аналитик в IT переводит задачу в точные правила работы приложения, сервиса или внутренней системы. Его работа находится между заказчиком, разработкой, тестированием, архитектурой и смежными командами: одни объясняют, зачем нужно изменение, другие должны понять, как его реализовать и проверить.
Главная ценность роли не в том, чтобы оформить документ. Документ важен только как носитель решения. Сильный результат появляется, когда команда одинаково понимает поведение системы в каждом сценарии: при успешном действии, пустом поле, повторном запросе, ошибке внешнего сервиса, отмене операции или изменении статуса.
Поэтому системный аналитик работает не только с текстом требований. Он разбирает данные, интерфейсы, API, права доступа, интеграции, очереди, справочники, отчёты и ограничения уже работающей системы. Чем дороже ошибка в этих правилах, тем важнее специалист, который найдёт неясность до разработки.
В профессию часто приходят из тестирования, поддержки, внедрения, разработки и смежной аналитики. Такой опыт помогает видеть, где в требованиях спрятана будущая поломка: неучтённый статус, двусмысленное поле, забытый отказ внешнего сервиса или правило, которое участники понимают по-разному.
Точное поведение информационной системы между сценариями, данными и интеграциями
Поля, статусы, ошибки, API, правила проверки, обмены и критерии приёмки
Банки, финтех, логистика, телеком, маркетплейсы и внутренние сервисы
Системный аналитик подключается, когда общая цель уже есть, но для реализации не хватает точности. Он разбирает, какие действия выполняет приложение, какие данные нужны на каждом шаге и какие варианты поведения нельзя оставлять на догадку.
На выходе команда получает не просто документ, а проверяемую модель: сценарии, статусы, требования к данным, описание интеграций, критерии приёмки и спорные места, которые были сняты до разработки.
Если правила описаны расплывчато, ошибка обычно всплывает уже в коде, тестировании или после запуска. Сильный аналитик снижает эту цену заранее: он находит нестыковки до того, как команда потратила время на неверную реализацию.
Системный анализ в IT - это разбор будущего или существующего решения как системы: сценариев, данных, состояний, ролей, интеграций, ошибок, ограничений и правил взаимодействия. Его цель - превратить идею изменения в проверяемую модель, по которой разработчики могут реализовать решение, тестировщики - проверить, а заказчик - понять ожидаемое поведение.
Аналитик разбирает, кто запускает действие, какие шаги проходят успешно, где появляются исключения и кто должен принять решение в спорной точке.
В требованиях фиксируются поля, обязательность, статусы, переходы, проверки, ограничения и правила, которые нельзя оставлять на устную договорённость.
Отдельно описываются запросы, ответы, события, повторы, таймауты и поведение при отказе соседней системы, чтобы команда не додумывала это уже в коде.
Обычно системный аналитик получает не готовую техническую инструкцию, а задачу с большим числом недоговорённостей. Его рабочий процесс строится вокруг последовательного уточнения: от цели изменения к сценариям, данным, интеграциям, ошибкам и проверяемому результату.
Выясняет цель изменения, ограничения, участников, зависимые приложения и места, где прежнее поведение уже не подходит.
Описывает основной путь, исключения, статусы, ошибки, ручные действия и условия, при которых сценарий должен остановиться.
Определяет поля, форматы, правила проверки, ответы API и связи между приложениями, чтобы техническая часть не осталась устной.
Сводит заказчика, разработку, тестирование и смежные команды к одной трактовке поведения до начала или во время реализации.
Сверяет результат с требованиями, уточняет расхождения и помогает закрыть вопросы перед выпуском изменения пользователям.
Эти роли часто встречаются рядом, но отвечают за разные вопросы. Системный аналитик ближе всего к устройству поведения IT-системы: данным, API, статусам, ошибкам и интеграциям. Бизнес-аналитик сильнее держит процесс и цель изменения, продуктовый аналитик — метрики и пользовательское поведение, архитектор — устройство решения и технические границы.
Поведение IT-системы
Требования, сценарии, статусы, API-контракты, интеграции, ошибки и критерии приёмки.
Бизнес-процесс и целевое изменение
AS-IS/TO-BE, бизнес-требования, описание процесса, ограничения и согласование цели с участниками.
Метрики и поведение пользователей
Метрики, воронки, сегменты, гипотезы, эксперименты и выводы о том, что меняется в продукте.
Ландшафт систем и технические границы
Компоненты, интеграционные контуры, ограничения, архитектурные решения и принципы развития системы.
Решение под задачу заказчика
Целевая схема решения, интеграции, ограничения внедрения, presale-аргументы и согласование с архитектурой.
Проверка реализации
Тест-кейсы, чек-листы, дефекты, регрессия и проверка того, что система работает по требованиям.
Понятная документация для пользователей и команд
Пользовательские инструкции, API-документация, справка, release notes и структура знаний.
Код серверной логики
Реализация API, бизнес-логики, работы с базой данных, интеграций и технических ограничений в коде.
Ценность, приоритеты и backlog
Backlog, roadmap, приоритизация, критерии ценности и решение, какие задачи команда делает дальше.
Работодатели ждут от системного аналитика не просто аккуратного документа, а способности превратить размытый запрос в точную постановку для разработки. Обычно смотрят на умение работать с SQL, REST API, Swagger, Postman, BPMN, UML, Jira и Confluence. Эти инструменты важны не сами по себе: через них кандидат показывает, что умеет читать данные, описывать обмены, фиксировать сценарии и проверять, хватит ли требований для реализации.
Сильный кандидат умеет задавать неприятные, но нужные вопросы: что делать при пустом поле, кто отвечает за повторный запрос, как изменится статус при отказе внешнего сервиса, где хранится результат и что увидит пользователь. Для работодателя это важнее красивой схемы, потому что такие вопросы заранее находят будущие ошибки.
Плюсом считается опыт рядом с разработкой, тестированием, поддержкой или внедрением. Он помогает понимать, как требования превращаются в код, проверки, выпуск и сопровождение. На собеседованиях часто просят разобрать интеграцию, описать сущности, предложить критерии приёмки или найти пробелы в постановке. Хороший ответ показывает не заученные термины, а последовательную логику анализа.
Рынок ориентирован на опытных специалистов.
Столько требований работодатели обычно собирают в одной позиции по этой роли.
Соответствие рассчитано по стеку из 645 вакансий — это не реклама, а совпадение со спросом работодателей.
Системный аналитик не обязан быть разработчиком, но должен понимать, как требование превращается в поведение системы. База роли — не один инструмент, а связка требований, сценариев, данных, API, интеграций, схем и коммуникации с командой.
Функциональные и нефункциональные требования, ограничения, бизнес-правила, критерии приёмки, SRS, user story и умение отличать пожелание от проверяемого условия.
Основной путь, альтернативные и негативные сценарии, жизненный цикл заявки или заказа, разрешённые переходы, ошибки и правила, которые не дают системе уйти в противоречивое состояние.
Сущности, поля, обязательность, справочники, связи, ограничения, SQL-запросы, data mapping и проверка того, что разные системы одинаково понимают одно и то же поле.
REST, SOAP, HTTP-методы, коды ответов, JSON/XML, OpenAPI, Swagger, Postman, контракты, ошибки и договорённости между командами.
События, очереди, Kafka, RabbitMQ, producer, consumer, повторная обработка, таймауты, порядок сообщений, дубли и идемпотентность.
BPMN для процесса, UML sequence для вызовов, state diagram для статусов, activity diagram для алгоритма, ERD для данных и C4 для границ системы.
Jira, Confluence, Miro, Figma, Swagger UI, Postman, draw.io, Git или wiki-система команды. Важно не знание кнопок, а способность оставить понятный артефакт.
Клиент-серверная архитектура, базы данных, авторизация, роли доступа, логи, окружения, интеграционные ошибки и базовое понимание того, как разработчик будет реализовывать требование.
Умение задавать уточняющие вопросы, фиксировать решения, объяснять ограничения, не прятать противоречия и договаривать заказчика, разработку, QA и архитекторов до одной версии поведения.
Результат работы системного аналитика - не один большой документ, а набор материалов, которые снимают разные виды неопределённости. Хороший артефакт помогает команде понять поведение, проверить реализацию и не возвращаться к тем же вопросам после старта разработки.
Фиксирует поведение системы, требования, ограничения, роли, сценарии и правила, когда задача крупная или затрагивает несколько команд.
Описывает потребность пользователя и ценность изменения в продуктовой разработке, но сама по себе не заменяет технические детали.
Показывает, при каких условиях задача считается готовой. Критерий должен быть проверяемым, иначе команда снова уйдёт в трактовки.
Разбирает сценарий взаимодействия пользователя с системой: цель, шаги, альтернативы, исключения и ожидаемый результат.
Показывает процесс, участников, шлюзы, события и ответственность. Особенно полезна для согласований, внутренних процессов и автоматизации.
Показывает, как пользователь, frontend, backend, база данных и внешние сервисы обмениваются вызовами во времени.
Описывает жизненный цикл сущности: какие статусы возможны, кто меняет состояние и какие переходы запрещены.
Фиксирует сущности, атрибуты, связи и ограничения. Это помогает обсуждать данные конкретно, а не общими словами.
Описывает контракт API: методы, параметры, тела запросов, ответы, ошибки и форматы данных для интеграций.
Собирает ошибки, коды, сообщения и действия системы, чтобы отказные сценарии не всплывали только на тестировании.
Показывает соответствие полей между системами при обменах, миграциях и интеграциях, где легко потерять смысл данных.
Для системного аналитика API - это не просто техническое слово из вакансии. Через API проходят данные, ошибки, статусы, повторы и договорённости между командами, поэтому слабое описание интеграции быстро превращается в дефект.
REST чаще встречается в современных HTTP-интеграциях, SOAP - в корпоративных и старых системах. Аналитик должен понимать формат запроса, ответа, ошибки и ограничения контракта.
Эти инструменты помогают читать и согласовывать контракт API: методы, параметры, обязательные поля, примеры ответов и отказные сценарии.
Postman полезен, чтобы проверить пример запроса, увидеть фактический ответ сервиса и быстрее найти расхождение между описанием и поведением.
В синхронном сценарии система ждёт ответ сразу. В асинхронном передаёт событие или сообщение, и аналитику нужно отдельно описать ожидание, повтор и обработку задержки.
Очереди и брокеры появляются там, где события обрабатываются не сразу. В требованиях нужны producer, consumer, состав события, повторная обработка и поведение при дубле.
Аналитик описывает, сколько ждать ответ, когда повторять запрос и почему повтор не должен создать дубль платежа, заявки или записи.
Недостаточно написать, что сервис вернёт ошибку. Нужно указать код, сообщение, действие системы, видимость для пользователя и следующий шаг команды поддержки.
Схема нужна не для украшения требований, а для снятия конкретной неясности. Сильный аналитик выбирает нотацию под задачу: процесс, последовательность вызовов, статусную модель, структуру данных или границы системы.
Подходит для бизнес-процесса, участников, шлюзов, событий и ответственности. Помогает увидеть, где процесс разветвляется или останавливается.
Нужна для цепочки вызовов между пользователем, frontend, backend, базой данных и внешними сервисами.
Помогает описать алгоритм или поток действий, когда важно показать порядок шагов и условия перехода.
Используется для статусов сущности: заявки, заказа, платежа, обращения или документа.
Полезна для структуры доменной модели, если нужно обсудить сущности, атрибуты и связи ближе к разработке.
Показывает сущности, атрибуты, связи и кардинальность. Особенно важна при проектировании данных и интеграциях.
Может пригодиться, если аналитик работает ближе к архитектуре и должен показать границы системы, внешних участников и крупные компоненты.
Смежные роли, с которыми системный аналитик часто пересекается в работе или из которых можно перейти в системный анализ.
Рост зарплаты начинается там, где аналитик перестаёт быть оформителем требований и становится источником технической ясности. Ему доверяют интеграции через API, модели данных, спорные состояния, правила отказа, зависимости между командами и решения, где ошибка в одном условии может затронуть расчёты, платежи, склад, отчётность или клиентский сценарий. Чем меньше переделок после старта разработки, тем выше рыночная ценность такого специалиста.
На вилку также влияет зрелость команды. В сильной инженерной среде аналитик ближе к архитектуре, тестированию и выпуску изменений, поэтому его вклад виден в скорости и качестве реализации. В слабой среде профессия может быть сведена к переписыванию пожеланий в задачи, и тогда доход ограничивает не навык, а узкий доступ к реальным решениям.
Спрос на системного аналитика лучше читать как сочетание объёма найма, ранга профессии в общей выборке и устойчивости вакансий во времени. Виджеты выше дают быстрый срез рынка, а график ниже помогает понять, насколько этот спрос поддерживается от месяца к месяцу.
Спрос на системных аналитиков держится на простой причине: цифровые сервисы редко работают изолированно. Клиентское действие запускает проверки, обмены с внешними поставщиками, обновление статусов, запись в базы, уведомления и отчётность. Если эту логику никто не собирает заранее, команда начинает обнаруживать противоречия уже в разработке, тестировании или после выпуска.
Особенно заметна потребность в банках, финтехе, логистике, телеком-проектах, маркетплейсах и внутренних сервисах с большим числом зависимостей. Там ошибка в формулировке может означать неверный расчёт, остановку операции, ручную обработку заявок или цепочку исправлений между несколькими командами.
Работодателю нужен специалист, который умеет не только писать требования, но и находить недосказанность до того, как она станет дефектом. Поэтому устойчивее выглядят кандидаты с технической базой, опытом чтения API, пониманием данных и привычкой описывать не только хороший сценарий, но и отказы, повторы, ограничения и спорные состояния.
Динамику спроса нужно читать по нескольким слоям: текущий активный срез показывает, что открыто сейчас, график показывает историю, а сглаженный ряд помогает не переоценивать один день. Поэтому рыночный вывод должен опираться не на отдельную точку, а на ряд, состав работодателей и размер выборки.
Этот срез показывает, в каком формате работодатели чаще всего открывают вакансии по профессии: удалённо, гибридно или с полной привязкой к офису.
Медианы по уровням без достаточной зарплатной выборки не показаны. Для таких грейдов ниже описана зона ответственности, а не точная зарплатная вилка.
На старте специалист обычно помогает старшим аналитикам: собирает вопросы, оформляет сценарии, уточняет поля, учится читать API и проверять требования на полноту. Главная задача уровня — перестать путать аккуратную запись с реальным пониманием поведения.
На среднем уровне аналитик самостоятельно ведёт задачи: разбирает сценарии, описывает данные и обмены, согласует спорные условия и сопровождает разработку до результата. От него ждут не только документа, но и уверенного снятия неясности.
Senior берёт более сложные домены, несколько команд и высокую цену ошибки. Он видит, где изменение заденет соседние процессы, заранее поднимает риски и помогает принимать решения по устройству будущей реализации.
Дальше рост идёт в руководящее аналитическое направление, архитектурное влияние, наставничество и стандарты требований. На этом уровне важно не только самому писать сильные постановки, но и повышать качество системного анализа у всей команды.
Здесь аналитик разбирает расчёты, проверки, статусы заявок, платежные операции и обмены с внешними участниками. Ошибка в требовании быстро превращается в финансовый или операционный риск.
В этих сферах много событий, очередей обработки, личных кабинетов, складских или тарифных правил. Системный аналитик помогает связать действия пользователя с тем, что должно произойти в соседних приложениях.
Во внутренних решениях специалист работает с учётом, согласованиями, справочниками, правами доступа и старыми правилами. Его ценность особенно заметна, когда новая функция должна встроиться в уже работающий процесс без ручных обходов.
Практический путь входа в профессию: что освоить сначала, как собрать рабочую базу и на чём быстрее всего набирается прикладная уверенность.
Разобраться с ролью системного аналитика, SDLC, видами требований, стейкхолдерами и базовым словарём IT: система, сервис, сущность, статус, сценарий, ошибка.
Писать ТЗ, SRS, пользовательские истории, критерии приёмки, сценарии использования и маппинг данных. Проверять, можно ли по этим материалам разработать и протестировать задачу без догадок.
Собрать портфолио из 2–3 кейсов, пройти тестовые задания, подготовить ответы на интервью и искать позицию начинающего системного аналитика или переход из QA, поддержки, внедрения либо бизнес-анализа.
Сопоставили программы с реальным стеком из 645 вакансий — оценка соответствия рассчитана автоматически, это не реклама.
Соответствие — доля ключевых навыков из вакансий, которые охватывает программа курса
В системный анализ редко входят только через теорию. Чаще помогает опыт рядом с продуктом, пользователями, требованиями, ошибками, внедрением или кодом. Важно не прежнее название должности, а способность показать, что вы умеете разбирать поведение системы до правил.
Тестировщик уже видит сценарии, дефекты, пограничные случаи и цену неясных требований. Для перехода нужно усилить SQL, API, нотации, постановку требований и научиться описывать решение до разработки, а не только проверять после.
Поддержка хорошо знает реальные ошибки пользователей, права доступа, логи, статусы и обходные процессы. Следующий шаг — перейти от разбора инцидента к описанию правила, которое предотвратит повтор проблемы.
Консультанты и внедренцы понимают процессы, справочники, учёт, роли и ограничения корпоративных систем. Для системного анализа нужно добавить API, интеграции, модели данных и более точное описание отказных сценариев.
Бизнес-аналитик уже умеет работать с процессом и стейкхолдерами. Переход в системный анализ требует большей технической глубины: данных, API, статусов, ошибок, интеграционных сценариев и критериев приёмки.
Разработчик понимает реализацию и ограничения кода, но должен научиться раньше выходить в постановку: задавать вопросы, фиксировать правила, согласовывать поведение и писать требования для всей команды, а не только для себя.
Project manager, product manager или Product Owner видят цели, сроки, приоритеты и ожидания заказчика. Для перехода нужно опуститься на уровень системного поведения: поля, статусы, API, данные, ошибки и проверяемые критерии.
Портфолио системного аналитика должно показывать ход мысли, а не набор красивых схем. Важно объяснить, какая была неясность, какие вопросы вы задали, какие альтернативы отбросили и как команда могла бы реализовать задачу без догадок.
Контекст, сценарии, API-контракт, примеры запросов и ответов, ошибки, повторы, таймауты и критерии приёмки.
Статусы, переходы, роли, запрещённые действия, state diagram и правила, которые не позволяют системе уйти в противоречивое состояние.
ERD, поля, связи, ограничения, примеры SQL и объяснение, почему такая модель данных подходит выбранному сценарию.
Найденные пробелы, вопросы к заказчику, уточнения, новая версия требований и критерии, по которым можно проверить результат.
Событие, producer, consumer, идемпотентность, повторная обработка, ошибки и наблюдаемость проблемного обмена.
На интервью проверяют не заученный список нотаций, а способность уточнять требование и доводить его до реализуемого поведения. Часто дают небольшой кейс и смотрят, какие вопросы кандидат задаёт первым.
Как уточнить задачу, если заказчик говорит только: нужно автоматизировать согласование или добавить интеграцию.
Чем отличаются методы, как описать запрос и ответ, что делать с ошибками, обязательными полями и неверным форматом.
Почему повторный запрос не должен создать дубль и как это отразить в требованиях к операции.
Что делать, если внешний сервис не ответил, вернул 500 или обработал событие с задержкой.
Когда использовать BPMN, когда диаграмму последовательности, когда диаграмму состояний и почему одна схема не решает все задачи.
Как построить модель сущностей, чем отличается связь 1:N от N:N и где появляются ограничения данных.
Как сформулировать критерии так, чтобы тестировщик мог проверить задачу, а разработчик не додумывал ожидаемый результат.
Как найти отсутствующий статус, неописанную ошибку, спорное поле или правило, которое разные команды понимают по-разному.
Сертификаты могут помочь структурировать знания, но не заменяют практику. Для системного аналитика важнее показать, что он умеет разбирать требования, API, данные, схемы и ошибки на реальных кейсах.
Полезен для требований и requirements engineering: виды требований, качество формулировок, управление изменениями и проверка полноты.
Ближе к бизнес-анализу, но помогает системному аналитику лучше понимать стейкхолдеров, ценность изменения и границу задачи.
Здесь важнее не бейдж, а умение выбрать правильную схему под задачу и объяснить её команде без лишней формальности.
Практические навыки обычно ценятся сильнее сертификата: показать запрос, контракт, ошибку и проверку поведения полезнее, чем просто указать курс.
Для начинающего специалиста убедительнее выглядят 2-3 аккуратных кейса с требованиями, схемами, API, вопросами и критериями приёмки.
Системный анализ сохраняет ценность там, где цифровые решения зависят от данных, интеграций, статусов, отказов и нескольких команд. Чем дороже ошибка в требованиях, тем важнее специалист, который убирает двусмысленность до реализации.
ИИ ускоряет черновики требований, сводки встреч и поиск пробелов, но не заменяет ответственность за смысл, границы решения и согласование между людьми с разными интересами.
Системный анализ становится более техническим. Команды всё чаще ждут от аналитика не только текст требований, но и понимание данных, событий, очередей сообщений, API, ошибок и ограничений платформы. Это не превращает специалиста в разработчика, но требует уверенно разговаривать с инженерной командой и видеть последствия формулировки для реализации.
Вторая заметная перемена — рост требований к компактности артефактов. Длинный документ сам по себе больше не считается сильным результатом. Ценится постановка, которая быстро показывает сценарии, спорные условия, данные, договорённости между приложениями и критерии готовности. Чем меньше команда тратит времени на расшифровку, тем выше качество аналитики.
ИИ будет ускорять черновики, расшифровку встреч, поиск противоречий и первые варианты схем. Но главный навык останется человеческим: понять, какое поведение действительно нужно бизнесу, договорить участников, выбрать границу решения и принять ответственность за последствия изменения.
Подходит тем, кому интересно разбирать сложное поведение до проверяемых правил, а не останавливаться на уровне общей идеи. В этой профессии важны терпение к неоднозначности, спокойствие в спорных обсуждениях и желание докапываться до причины будущей ошибки.
Он уточняет задачу, описывает основной и ошибочные сценарии, фиксирует данные и API, согласует спорные условия, готовит критерии приёмки и помогает разработке с тестированием одинаково понять ожидаемое поведение.
Актуальную зарплату лучше смотреть в карточках SkillStat на странице: они берут данные из активных вакансий и показывают медиану, выборку и источник расчёта. На доход сильнее всего влияют интеграции, данные, сложность домена и самостоятельность.
Да, хотя бы на уровне чтения данных, проверки гипотез и понимания сущностей. SQL помогает не описывать данные вслепую и быстрее находить расхождения между требованием и фактическим состоянием системы.
Писать боевой код обычно не требуется. Но полезно понимать клиент-серверную архитектуру, форматы данных, логику API, ошибки, очереди и базовые скрипты, чтобы разговаривать с разработкой предметно.
При опыте в QA, поддержке, внедрении или бизнес-анализе первый переход может занять несколько месяцев плотной практики. С нуля обычно нужно больше времени, потому что приходится одновременно собирать IT-базу, требования и портфолио.
Бизнес-аналитик уточняет, что нужно изменить в процессе и зачем. Системный аналитик описывает, как это изменение должно работать в приложении, данных, интеграциях и ошибках.
Продуктовый аналитик смотрит на метрики, поведение пользователей, эксперименты и влияние изменений на продукт. Системный аналитик описывает, как само изменение должно работать в системе: поля, статусы, API, ошибки и обмены.
Системный аналитик обычно описывает поведение конкретного изменения или части системы. Системный архитектор отвечает шире: за компоненты, границы систем, интеграционный ландшафт, устойчивость и долгосрочные архитектурные решения.
QA проверяет, что реализация работает по требованиям. Системный аналитик помогает сформулировать эти требования заранее: сценарии, ограничения, ошибки, статусы, данные и критерии готовности.
Асинхронная интеграция означает, что система не ждёт немедленный ответ, а передаёт событие или сообщение для последующей обработки. В требованиях нужно описать задержку, повтор, ошибку, дубли и итоговое состояние.
Идемпотентность означает, что повтор одного и того же запроса не создаёт новый побочный эффект. Например, повторная отправка операции не должна дважды создать платёж, заказ или заявку.
Системный аналитик объясняет команде, как должна работать IT-система. Он переводит бизнес-задачу в правила для разработки: сценарии, данные, статусы, ошибки, интеграции и критерии проверки.
Acceptance criteria - это проверяемые условия, по которым команда понимает, что задача готова. Хороший критерий описывает ожидаемое поведение, данные, ошибки и результат так, чтобы его можно было проверить без устных пояснений.
Data mapping показывает, как поля одной системы соответствуют полям другой системы. Он нужен при интеграциях, миграциях и обменах, чтобы команда не потеряла смысл данных между источником и получателем.
SRS, или Software Requirements Specification, - это спецификация требований к программной системе. В ней фиксируют функции, ограничения, сценарии, данные, интерфейсы, ошибки и критерии качества для более крупной задачи или продукта.
State diagram, или диаграмма состояний, показывает жизненный цикл сущности: какие статусы есть у заявки, заказа или платежа, какие переходы разрешены и какие действия должны быть запрещены.
Use case описывает сценарий взаимодействия пользователя или внешней системы с продуктом: цель, участников, основной путь, альтернативы, исключения и ожидаемый результат.