System Analyst — IT-роли — Арсенал qvib.pro

Превращает требования в техническую спецификацию: контракты API, данные, интеграции.

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

System Analyst превращает бизнес-требования в точную техническую постановку, по которой инженеры строят систему. Если Business Analyst отвечает на «что и зачем нужно бизнесу», то System Analyst — на «как это должно работать технически»: контракты API, модель данных, интеграции, нефункциональные требования. Он стоит между BA/продуктом и разработкой.

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

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

День из жизни

Утро. Берёт требование от BA/продукта, уточняет неоднозначности. Проектирует контракт API: эндпоинты, поля, коды ошибок, валидация. Сверяет с внешними системами, с которыми интегрируемся. День. Описывает модель данных (ER-диаграмма, сущности, связи, ограничения), рисует sequence-диаграмму сценария («кто кого вызывает по шагам»). Фиксирует нефункциональные требования. Согласовывает спецификацию с инженерами на реализуемость. Вечер. Обновляет SRS и спецификацию API, проверяет полноту сценариев (happy path + ошибки + края), готовит вопросы по белым пятнам интеграций.

Ключевые навыки

Hard: проектирование контрактов API (REST/GraphQL, OpenAPI), моделирование данных (ER, нормализация), UML (sequence/activity), интеграции и форматы обмена, нефункциональные требования, SQL, чтение кода. Soft: системное мышление, внимание к деталям и краям, перевод бизнес-языка в технический, согласование с инженерами, точность формулировок.

Артефакты, которые пишет

SRS — системные требования.
Спецификация API — контракты (часто OpenAPI/Swagger).
ER-диаграмма / модель данных — сущности и связи.
Sequence-диаграммы — потоки взаимодействия по шагам. Архитектурный контекст берёт из C4-модели и System Design Doc, решения фиксирует в ADR (группа «Артефакты»).

Как ИИ/вайб-кодинг усиливает роль

Черновик контракта API. Промт: «Ты системный аналитик. По требованию <управление заказами> спроектируй REST-контракт (OpenAPI): эндпоинты, методы, поля запроса/ответа, коды ошибок, валидация. Покрой создание, чтение, отмену.»
Модель данных. Промт: «По описанию домена <…> предложи ER-модель: сущности, атрибуты, связи, ключи, ограничения. Отметь, где нужны индексы и где возможны N+1.»
Sequence-диаграмма. Промт: «Опиши последовательность взаимодействия для сценария <оплата заказа>: клиент → бэкенд → платёжный шлюз → БД, с обработкой ошибок и таймаутов (в нотации, пригодной для PlantUML).»
Проверка полноты. Промт: «Вот спецификация API <…>. Каких сценариев не хватает (ошибки, края, идемпотентность, пагинация, авторизация)? Допиши.»
Нефункциональные требования. Промт: «По фиче <…> предложи список нефункциональных требований: latency, throughput, доступность, лимиты, безопасность данных.»

Путь развития: Junior → Middle → Senior → Lead

Junior SA: детализирует требования и простые контракты под присмотром, рисует диаграммы.
Middle SA: самостоятельно проектирует API и модель данных, описывает интеграции, согласует с инженерами.
Senior SA: ведёт сложные интеграции и доменные модели, влияет на архитектурные решения, наставляет.
Lead SA / переход в Architect: координирует аналитиков и стандарты спецификаций, часто растёт в системного архитектора.

Частые ошибки и как избежать

Контракт без ошибок и краёв. → Описывай коды ошибок, валидацию, идемпотентность, пагинацию, не только happy path.
Модель данных «на сейчас». → Думай о росте, целостности, индексах; продумывай связи и ограничения.
Забыл нефункциональные требования. → Latency/нагрузка/доступность фиксируй явно, иначе всплывут в проде.
Спецификация в вакууме. → Согласуй с инженерами реализуемость и с внешними системами — стыковку.
Двусмысленные формулировки. → Точность важнее красоты: одно прочтение, а не «как поняли».

Что освоить (мини-программа)

Концепции: REST/GraphQL, OpenAPI, моделирование данных и нормализация, UML, нефункциональные требования, идемпотентность, интеграционные паттерны.
Инструменты: Swagger/OpenAPI, draw.io/PlantUML, Postman, SQL-клиент, Confluence.
Почитать: «Software Requirements» К. Вигерс; «Designing Data-Intensive Applications» М. Клеппман (для NFR/данных); REST API guidelines.

Зарплатные ориентиры (RU)

Junior SA: ~100–160 тыс ₽/мес.
Middle SA: ~160–270 тыс ₽/мес.
Senior SA: ~270–400 тыс ₽/мес.

Зависит от грейда, домена, города и года — проверяй актуальное.

Маппинг на агента Laskoff

Прямой mapsTo: analyst. В Quest агент analyst на фазе спеки превращает требования в точную техническую постановку — контракты, модель данных, сценарии — и формулирует проверяемые EARS-требования, по которым engineer строит, а quest-verifier проверяет.

🤖 Промт-персона

Ты — опытный системный аналитик. Помогаешь мне превращать бизнес-требования в точную техническую постановку. Проектируй контракты API (эндпоинты, поля, коды ошибок, валидацию, идемпотентность, пагинацию), модель данных (сущности, связи, ограничения, индексы) и потоки взаимодействия (sequence). Всегда покрывай не только happy path, но и ошибки, края, безопасность и нефункциональные требования (latency, нагрузка, доступность). Формулируй однозначно — одно прочтение. По запросу выдавай OpenAPI/ER/PlantUML-описания. Перед финалом проверяй полноту сценариев и стыковку с внешними системами.