Основы профессии Системный аналитик

Курс охватывает ключевые компетенции системного аналитика: от сбора требований до проектирования интеграций. Вы изучите методологии разработки, языки моделирования и технические аспекты взаимодействия систем.

1. Введение в системный анализ: роль специалиста и жизненный цикл разработки ПО (SDLC)

Введение в системный анализ: роль специалиста и жизненный цикл разработки ПО (SDLC)

Добро пожаловать в курс «Основы профессии Системный аналитик». Это первая статья, с которой начнется ваше погружение в одну из самых востребованных профессий в IT. Мы разберем, кто такой системный аналитик, почему без него сложно создать качественный продукт и как устроен процесс разработки программного обеспечения.

Кто такой системный аналитик?

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

Вам нужен архитектор. Человек, который выслушает ваши мечты, переведет их на язык чертежей, схем и точных расчетов, понятных строителям.

В мире IT системный аналитик (System Analyst) — это и есть тот самый архитектор. Это специалист, который выступает связующим звеном между бизнесом (заказчиком) и командой разработки (программистами, тестировщиками).

!Системный аналитик как мост между бизнесом и разработкой

Основная задача аналитика

Главная цель системного аналитика — устранить неопределенность. Бизнес часто формулирует задачи абстрактно: «Мы хотим увеличить продажи» или «Нам нужно удобное приложение». Разработчикам же нужны четкие инструкции: какие данные сохранять, какие кнопки рисовать, как система должна реагировать на ошибки.

Аналитик выполняет следующие функции:

  • Выявление требований: общается с заказчиком, чтобы понять, что именно нужно сделать.
  • Анализ и систематизация: превращает хаотичные пожелания в структурированную логику.
  • Документирование: описывает требования так, чтобы они были понятны и бизнесу, и программистам.
  • Сопровождение: отвечает на вопросы команды в процессе разработки.

    • Жизненный цикл разработки ПО (SDLC)

    Чтобы понять, когда именно в работу вступает аналитик, нужно разобраться, как вообще создаются программы. Этот процесс называется SDLC (Software Development Life Cycle) — жизненный цикл разработки программного обеспечения.

    Это путь, который проходит любой IT-продукт от идеи до момента, когда его перестают использовать. SDLC состоит из нескольких этапов.

    !Этапы жизненного цикла разработки ПО (SDLC)

    Этап 1: Сбор и анализ требований (Analysis)

    Это «звездный час» системного аналитика. На этом этапе решается, что мы будем создавать.

    * Что происходит: Аналитик проводит интервью с заказчиком, изучает конкурентов, погружается в предметную область. * Результат: Готовый список требований и техническое задание (ТЗ). Если на этом этапе допустить ошибку, исправить её в будущем будет очень дорого.

    В системном анализе часто используют формулу оценки времени выполнения задач, например, метод PERT, чтобы дать бизнесу ориентировочные сроки:

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

    Этап 2: Проектирование (Design)

    Здесь аналитик (часто совместно с архитектором системы) решает, как система будет работать.

    * Что происходит: Создаются макеты экранов, описываются структуры баз данных, рисуются схемы взаимодействия систем (например, как интернет-магазин общается с платежной системой). * Результат: Проектная документация, схемы, прототипы интерфейсов.

    Этап 3: Разработка (Development)

    В игру вступают программисты. Они пишут код, опираясь на документы, которые подготовил аналитик.

    * Роль аналитика: Он не пишет код, но он всегда рядом. Разработчики постоянно задают уточняющие вопросы: «А что делать, если пользователь ввел неверный пароль?» или «Где хранить историю заказов?». Аналитик должен оперативно давать ответы.

    Этап 4: Тестирование (Testing)

    Когда код написан, его нужно проверить. Этим занимаются тестировщики (QA-инженеры).

    Роль аналитика: Аналитик помогает тестировщикам понять, как должна* работать система. Он также может участвовать в приемке продукта, проверяя, соответствует ли результат изначальным требованиям бизнеса.

    Этап 5: Внедрение и поддержка (Deployment & Maintenance)

    Продукт передается пользователям. Но работа на этом не заканчивается.

    * Что происходит: Пользователи начинают работать с программой, находят ошибки или просят добавить новые функции. * Роль аналитика: Анализ ошибок, сбор обратной связи и формирование требований для обновлений (возврат к первому этапу).

    Методологии разработки: Waterfall и Agile

    Жизненный цикл SDLC может быть организован по-разному. Существует два основных подхода к управлению этим процессом.

    Waterfall (Каскадная модель)

    Это классический подход, похожий на водопад: вода течет только вниз, нельзя вернуться назад, пока не пройдешь текущий порог.

  • Сначала пишем все требования.
  • Потом все проектируем.
  • Потом все программируем.

    • > «Семь раз отмерь, один раз отрежь» — идеальный девиз для Waterfall.

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

    Agile (Гибкая методология)

    Современный подход, который разбивает разработку на короткие циклы (спринты), обычно по 2-3 недели.

  • Спланировали маленькую часть.
  • Сделали.
  • Показали заказчику.
  • Получили обратную связь и скорректировали планы.

    • !Визуальное сравнение методологий Waterfall и Agile

    В Agile роль аналитика становится еще более динамичной: требования могут меняться прямо в процессе работы, и нужно уметь быстро адаптировать документацию.

    Резюме

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

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

    2. Работа с требованиями: выявление, классификация, документирование и управление изменениями

    Работа с требованиями: выявление, классификация, документирование и управление изменениями

    В предыдущей статье мы рассмотрели жизненный цикл разработки ПО (SDLC) и определили, что этап Анализа является фундаментом для всего проекта. Если на этом этапе заложить «кривой» фундамент, здание проекта рухнет, сколько бы усилий ни прикладывали разработчики и тестировщики.

    Сегодня мы погрузимся в самую суть работы системного аналитика — работу с требованиями. Мы разберем, что это такое, какими они бывают, как их добывать из голов заказчиков и как описывать так, чтобы вас поняли однозначно.

    Что такое требование?

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

    Но на практике требование — это договоренность. Это зафиксированное обещание того, что система будет делать. Если требование не записано, его не существует. Если оно записано двусмысленно, считайте, что вы подбросили монетку: реализуют ли его верно или нет.

    Пирамида требований: Классификация

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

    !Иерархия требований от общих целей бизнеса до конкретных технических деталей.

    1. Бизнес-требования (Business Requirements)

    Это вершина пирамиды. Они отвечают на вопрос «Зачем?». Зачем нам вообще нужен этот проект? Какую проблему бизнеса мы решаем?

    * Пример: «Сократить время обработки заказа на 20%» или «Выйти на рынок доставки еды в новом регионе». * Кто источник: Заказчик, топ-менеджмент, инвесторы.

    2. Пользовательские требования (User Requirements)

    Это средний уровень. Они отвечают на вопрос «Что делает пользователь?». Как именно пользователь будет взаимодействовать с системой, чтобы достичь бизнес-целей?

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

    3. Системные требования (System Requirements)

    Это основание пирамиды, самый детальный уровень. Они отвечают на вопрос «Что делает система?». Здесь мы переводим желания пользователей на язык функций.

    Системные требования делятся на две критически важные категории:

    #### А. Функциональные требования (Functional Requirements) Описывают поведение системы. Что она должна делать. * Пример: «Система должна отправлять SMS-уведомление клиенту при смене статуса заказа». * Пример: «При нажатии кнопки "Купить" товар должен добавляться в корзину».

    #### Б. Нефункциональные требования (Non-functional Requirements) Описывают свойства системы или ограничения. Как система должна работать. Их часто называют «атрибутами качества». * Пример: «Время загрузки страницы не должно превышать 2 секунд» (Производительность). * Пример: «Система должна поддерживать 10 000 одновременных пользователей» (Масштабируемость). * Пример: «Пароли должны храниться в зашифрованном виде» (Безопасность).

    > Запомните простое правило: Функциональные требования — это глаголы (рассчитать, сохранить, отправить). Нефункциональные — это прилагательные и наречия (быстро, безопасно, надежно).

    Выявление требований (Elicitation)

    Требования редко лежат на поверхности. Заказчик часто сам не знает, чего хочет, или говорит решениями («Хочу блокчейн!»), а не проблемами. Задача аналитика — быть детективом.

    Основные техники сбора требований:

  • Интервью: Беседа один на один. Самый популярный метод. Позволяет глубоко копать, но требует времени.
  • Анкетирование: Хорошо подходит, когда пользователей много и они географически распределены.
  • Мозговой штурм (Brainstorming): Групповая встреча для генерации идей.
  • Наблюдение (Job Shadowing): Аналитик садится рядом с пользователем и смотрит, как тот работает. Часто выясняется, что реальный процесс отличается от того, что написано в инструкциях.
  • Анализ документации: Изучение регламентов, законов или документации к старой системе.

    • Документирование требований

    Собранную информацию нужно записать. Устные договоренности в IT не работают. Существует несколько форматов документирования.

    Спецификация требований (SRS — Software Requirements Specification)

    Это большой, формальный документ, где описано всё. Часто используется в Waterfall-проектах. Это «библия» проекта.

    User Stories (Пользовательские истории)

    Популярный формат в Agile. Это короткое описание потребности с точки зрения пользователя. Строится по шаблону:

    > Как <роль пользователя>, я хочу <действие/функция>, чтобы <ценность/причина>.

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

    Use Cases (Варианты использования)

    Сценарий взаимодействия пользователя и системы. Описывает пошаговый алгоритм.

    Структура Use Case:

  • Название: Оформление заказа.
  • Актер: Покупатель.
  • Предусловия: Пользователь авторизован, корзина не пуста.
  • Основной поток:
    • 1. Пользователь нажимает «Оформить». 2. Система запрашивает адрес. 3. Пользователь вводит адрес. 4. Система рассчитывает доставку.
  • Постусловия: Заказ создан, статус «Новый».

    • Приоритизация требований

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

    Для этого часто используются скоринговые модели. Одна из популярных — формула RICE.

    Где: * — итоговый балл приоритета (чем выше, тем важнее задача). * (Reach) — охват. Скольких пользователей это затронет за определенный период? (Например, 1000 человек в месяц). * (Impact) — влияние. Насколько сильно это улучшит опыт пользователя? (Обычно шкала: 3 — массовое влияние, 0.25 — минимальное). * (Confidence) — уверенность. Насколько мы уверены в наших оценках охвата и влияния? (В процентах, например, 100% — есть твердые данные, 50% — «пальцем в небо»). * (Effort) — трудозатраты. Сколько времени команды (в человеко-месяцах или неделях) нужно на реализацию.

    Эта формула позволяет перевести эмоциональное «Хочу это срочно!» в сухой язык цифр.

    Управление изменениями и трассировка

    Требования меняются. Это закон. Бизнес передумал, вышел новый закон, конкуренты выпустили фичу. Аналитик должен управлять этим хаосом.

    Матрица трассировки (Traceability Matrix)

    Это инструмент, который связывает требования между собой и с другими артефактами (кодом, тестами).

    Представьте таблицу, где: * Столбец А: ID Бизнес-требования. * Столбец Б: ID Функционального требования. * Столбец В: ID Тест-кейса.

    !Матрица трассировки помогает отследить, покрыто ли каждое требование тестами и кодом.

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

    Критерии качества требований

    Плохое требование: «Система должна работать хорошо». Хорошее требование должно соответствовать критериям качества. Часто используют мнемонику INVEST (для User Stories) или набор характеристик:

  • Единичность (Atomicity): Одно требование — одна мысль.
  • Полнота (Completeness): Описаны все условия.
  • Непротиворечивость (Consistency): Не конфликтует с другими требованиями.
  • Проверяемость (Testability): Можно написать тест, который скажет «Да» или «Нет».

    • Резюме

  • Требования делятся на уровни: Бизнес (зачем?), Пользовательские (кто?), Системные (что и как?).
  • Системные требования бывают функциональными (действия) и нефункциональными (свойства).
  • Для выявления используйте интервью, наблюдение и анализ документов.
  • Для документирования выбирайте формат, подходящий команде: SRS, User Stories или Use Cases.
  • Используйте формулы вроде RICE для обоснованной приоритизации.
  • Управляйте изменениями с помощью матрицы трассировки, чтобы не потерять контроль над проектом.

    • В следующей статье мы перейдем к практике и разберем, как моделировать процессы с помощью нотации BPMN.

    3. Визуальное моделирование: построение диаграмм в нотациях UML и BPMN

    Визуальное моделирование: построение диаграмм в нотациях UML и BPMN

    В предыдущих статьях мы научились выявлять и описывать требования словами. Мы знаем, что такое User Story и как составить техническое задание. Но представьте, что вам нужно объяснить иностранцу, как пройти в библиотеку, не зная его языка. Вы начнете рисовать карту.

    В IT происходит то же самое. Текст, каким бы подробным он ни был, часто воспринимается двусмысленно. Огромные полотна текста утомляют мозг, и важные детали теряются. Здесь на помощь приходит визуальное моделирование.

    Сегодня мы изучим два главных языка чертежей в мире системного анализа: UML и BPMN.

    Зачем рисовать диаграммы?

    Человеческий мозг обрабатывает визуальную информацию в 60 000 раз быстрее, чем текст. Диаграмма позволяет увидеть систему целиком, «с высоты птичьего полета», и заметить логические дыры, которые невидны в тексте.

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

    где — цикломатическая сложность (количество независимых путей через код или схему), — количество ребер (стрелок/переходов) на графе, — количество узлов (действий/блоков), а — количество связных компонентов (обычно равно 1 для одной программы). Чем выше это число, тем сложнее логика и тем выше риск ошибок. Визуализация помогает увидеть эти «узлы» и упростить их.

    UML: Унифицированный язык моделирования

    UML (Unified Modeling Language) — это стандарт в мире разработки ПО. Это набор графических обозначений для создания абстрактной модели системы. UML был создан программистами для программистов (и аналитиков), чтобы проектировать архитектуру приложения.

    В UML существует 14 типов диаграмм, но системному аналитику в 90% случаев нужны только три из них.

    1. Диаграмма вариантов использования (Use Case Diagram)

    С этой диаграммой мы косвенно знакомились, когда обсуждали требования. Она показывает, кто (Actor) и что (Use Case) может делать в системе. Это «оглавление» вашего проекта.

    Основные элементы: * Актер (Actor): Человечек, обозначающий роль пользователя или внешнюю систему. * Вариант использования (Use Case): Овал с глаголом, обозначающий функцию (например, «Оформить заказ»). * Связь: Линия, соединяющая актера и овал.

    !Пример диаграммы вариантов использования для интернет-магазина.

    2. Диаграмма последовательности (Sequence Diagram)

    Это самая популярная диаграмма для описания интеграций. Она показывает, как объекты взаимодействуют друг с другом во времени.

    Если Use Case говорит «Пользователь платит», то Sequence Diagram показывает как именно: «Пользователь нажал кнопку -> Браузер отправил запрос на сервер -> Сервер проверил баланс в Базе Данных -> База ответила ОК -> Сервер вернул успех».

    Основные элементы: * Жизненная линия (Lifeline): Вертикальная пунктирная линия, идущая от участника (квадратика сверху) вниз. Время течет сверху вниз. * Сообщение (Message): Горизонтальная стрелка от одной линии к другой. Сплошная стрелка — вызов, пунктирная — ответ.

    3. Диаграмма деятельности (Activity Diagram)

    Она похожа на классическую блок-схему, которую многие видели в школе на уроках информатики. Используется для описания алгоритмов и сложной логики с условиями.

    Основные элементы: * Начало: Черный круг. * Действие: Прямоугольник с закругленными краями. * Решение (Decision): Ромб, из которого выходят стрелки «Да» и «Нет». * Конец: Черный круг в белой окантовке.

    BPMN: Моделирование бизнес-процессов

    Если UML фокусируется на системе (классы, объекты, сообщения), то BPMN (Business Process Model and Notation) фокусируется на бизнесе и людях. Эта нотация понятна не только айтишникам, но и менеджерам, бухгалтерам и руководителям.

    BPMN описывает процесс как последовательность шагов, выполняемых разными участниками.

    Ключевые элементы BPMN

    BPMN оперирует четырьмя основными категориями объектов.

    #### 1. Объекты потока (Flow Objects) Это основные кирпичики процесса: * События (Events): Кружки. То, что случается. Бывают стартовые (тонкий круг), промежуточные (двойной круг) и конечные (жирный круг). * Действия (Activities): Прямоугольники с закругленными углами. То, что нужно сделать (например, «Подписать договор»). * Шлюзы (Gateways): Ромбы. Развилки процесса.

    #### 2. Соединяющие объекты (Connecting Objects) * Поток управления (Sequence Flow): Сплошная стрелка. Показывает порядок действий. * Поток сообщений (Message Flow): Пунктирная стрелка. Показывает передачу информации между разными организациями или отделами.

    #### 3. Зоны ответственности (Swimlanes) Чтобы показать, кто выполняет действие, используются «бассейны» (Pools) и «дорожки» (Lanes).

    * Пул (Pool): Обозначает организацию или процесс целиком (например, «Компания А»). * Дорожка (Lane): Подразделение внутри пула (например, «Отдел продаж», «Склад», «Бухгалтерия»).

    !Пример BPMN диаграммы с использованием дорожек для разделения ответственности.

    Логика шлюзов (Gateways)

    Самая частая ошибка новичков — неправильное использование ромбов (шлюзов). Рассмотрим два основных типа:

  • Эксклюзивный шлюз (XOR): Обозначается пустым ромбом или ромбом с крестиком «X». Поток может пойти только по одному пути.
    • Пример:* Клиент платит либо картой, либо наличными. Нельзя выбрать оба варианта сразу.

  • Параллельный шлюз (AND): Обозначается ромбом с плюсом «+». Поток разделяется на несколько параллельных путей, которые выполняются одновременно.
    • Пример: При оформлении сотрудника нужно одновременно* подготовить рабочее место И оформить пропуск.

    UML или BPMN: Что выбрать?

    Начинающие аналитики часто путаются, какую нотацию использовать. Давайте разграничим их зоны ответственности.

    | Характеристика | BPMN | UML (Activity/Sequence) | | :--- | :--- | :--- | | Цель | Описать бизнес-процесс (как работают люди и компания) | Описать работу ПО (как работает код и система) | | Читатель | Бизнес, менеджеры, заказчик | Разработчики, архитекторы | | Детализация | «Отправить счет» (один кубик) | «Сформировать JSON, вызвать API, получить ответ 200 OK» | | Фокус | Кто и что делает | Как система это реализует |

    > Золотое правило: Если вы описываете регламент работы отдела бухгалтерии — берите BPMN. Если вы проектируете модуль расчета зарплаты внутри программы — берите UML.

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

    Вам не нужны карандаш и бумага. Существует множество инструментов для моделирования:

  • Draw.io (diagrams.net): Бесплатный, работает в браузере. Идеален для новичков.
  • Camunda Modeler: Профессиональный инструмент для BPMN. Позволяет создавать исполняемые схемы (которые можно загрузить в движок и запустить).
  • Enterprise Architect: Мощный «комбайн» для корпоративных архитекторов. Сложный, но функциональный.
  • PlantUML / Mermaid: Инструменты для тех, кто любит писать код. Вы пишете текст, а программа сама генерирует картинку. Это называется «Diagram as Code».

    • Резюме

  • Визуализация необходима для борьбы со сложностью и устранения недопонимания.
  • UML — это язык для проектирования программного обеспечения. Используйте Use Case для границ системы и Sequence для описания взаимодействий.
  • BPMN — это язык для описания бизнес-процессов. Используйте его, чтобы показать, как люди и отделы взаимодействуют друг с другом.
  • Используйте дорожки (Lanes) в BPMN, чтобы четко разграничить ответственность.
  • Выбирайте нотацию исходя из задачи: для бизнеса — BPMN, для разработчиков — UML.

    • В следующей статье мы перейдем от картинок к структурированному тексту и разберем, как описывать взаимодействие систем через API.

    4. Проектирование интеграций и архитектуры: основы REST API, SOAP, JSON и XML

    Проектирование интеграций и архитектуры: основы REST API, SOAP, JSON и XML

    В предыдущей статье мы научились рисовать диаграммы последовательности (Sequence Diagrams) в UML. Мы чертили стрелки от одной системы к другой и подписывали их: «Запрос данных», «Ответ сервера». Но что на самом деле «летит» по этим стрелкам? На каком языке общаются программы?

    Сегодня мы переходим от картинок к «железу». Мы разберем, как именно системы интегрируются друг с другом, что такое API, почему JSON победил XML (почти) и в чем разница между REST и SOAP.

    Что такое API?

    Представьте, что вы пришли в ресторан. Вы (Клиент) хотите заказать стейк, который находится на кухне (Сервер). Вы не можете просто ворваться на кухню и начать жарить мясо. Вам нужен посредник, который примет ваш заказ, передаст его повару по правилам и принесет результат.

    Этот официант и есть API (Application Programming Interface) — программный интерфейс приложения.

    !Метафора API как официанта в ресторане, связывающего клиента и кухню.

    В мире IT, API — это набор правил и инструментов, который позволяет одной программе обращаться к другой. Когда вы нажимаете кнопку «Войти через Google» на сайте, этот сайт использует API Google, чтобы проверить, кто вы.

    Языки общения: Форматы данных

    Чтобы официант понял заказ, он должен быть сделан на понятном языке. В интеграциях этот «язык» называется форматом обмена данными. Два самых популярных формата — это XML и JSON.

    XML (eXtensible Markup Language)

    Это «ветеран» интеграций. XML похож на HTML: у него есть открывающие и закрывающие теги. Он очень строгий, структурированный и надежный, но при этом громоздкий.

    Пример описания студента на XML:

    Особенности XML: * Читаемость: Понятен человеку, но много лишних символов (тегов). * Валидация: Имеет мощные инструменты проверки структуры (XSD-схемы). * Избыточность: Занимает много места при передаче.

    JSON (JavaScript Object Notation)

    Это современный стандарт. Он пришел из языка JavaScript, но сейчас используется везде. JSON лаконичен: вместо тегов здесь фигурные скобки и пары «ключ-значение».

    Тот же студент на JSON:

    Особенности JSON: * Легкость: Меньше символов — быстрее передача. * Структура: Поддерживает вложенность и массивы (списки). * Популярность: Стандарт де-факто для веб-разработки и мобильных приложений.

    Математика передачи данных

    Системный аналитик должен понимать, почему JSON часто предпочтительнее для мобильных сетей. Давайте оценим объем передаваемых данных. Размер сообщения можно приблизительно рассчитать по формуле:

    где — общий размер сообщения (Size), — полезные данные (Data, сам текст «Иван Иванов»), а — метаданные (Metadata, теги, скобки, кавычки).

    В XML значение (метаданные) очень велико, так как каждое поле нужно обернуть в два тега. В JSON метаданных значительно меньше. При передаче миллионов записей эта разница экономит гигабайты трафика.

    Архитектурные стили: SOAP и REST

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

    SOAP (Simple Object Access Protocol)

    Это протокол. Строгий, тяжеловесный, но очень надежный. Он использует только XML.

    Представьте, что вы отправляете ценную бандероль. Вы заполняете кучу бланков, опись вложения, страхуете посылку, получаете трек-номер. Это SOAP. У каждого сообщения есть «конверт» (Envelope), «заголовок» (Header) и «тело» (Body).

    Где используется: Банковский сектор, государственные услуги, крупные корпоративные системы (Enterprise), где важна безопасность и транзакционность.

    REST (Representational State Transfer)

    Это не протокол, а архитектурный стиль. Это набор рекомендаций. REST проще, гибче и легче. Он может использовать XML, но в 99% случаев работает с JSON.

    REST построен на принципах работы самого интернета (протокола HTTP). В REST все строится вокруг Ресурсов.

    #### Основные принципы REST API:

  • Ресурс и URL: Каждая сущность (пользователь, товар, заказ) имеет свой уникальный адрес.
    • * https://api.shop.com/users — список всех пользователей. * https://api.shop.com/users/42 — конкретный пользователь с ID 42.

  • HTTP Методы (Глаголы): Чтобы сказать системе, что мы хотим сделать с ресурсом, мы используем методы протокола HTTP. Это похоже на CRUD (Create, Read, Update, Delete).

    • | Метод HTTP | Аналог в CRUD | Описание | | :--- | :--- | :--- | | GET | Read | Получить данные. (Пример: Открыть страницу товара) | | POST | Create | Создать новый ресурс. (Пример: Оформить заказ) | | PUT / PATCH | Update | Обновить данные. (Пример: Изменить адрес доставки) | | DELETE | Delete | Удалить ресурс. (Пример: Удалить товар из корзины) |

  • Коды ответов (Status Codes): Сервер всегда сообщает, как прошла операция, с помощью трехзначного числа.

    • * 2xx (Успех): * 200 OK — Все хорошо, вот ваши данные. * 201 Created — Успешно создано (например, новый пользователь). * 4xx (Ошибка клиента): * 400 Bad Request — Вы передали кривые данные. * 401 Unauthorized — Вы не представились (нужен логин/пароль). * 403 Forbidden — Вам сюда нельзя (нет прав). * 404 Not Found — Такого ресурса не существует. * 5xx (Ошибка сервера): * 500 Internal Server Error — На сервере что-то сломалось, клиент не виноват.

    !Процесс получения данных о пользователе через REST API.

    Задача системного аналитика при проектировании API

    Аналитик не пишет код API, но он проектирует контракт. Контракт — это договоренность о том, как API будет работать.

    Что должен описать аналитик:

  • Метод и URL: Например, POST /api/v1/orders.
  • Входные данные (Request): Какие поля нужно отправить? Какие из них обязательные? Какой у них тип данных (строка, число, дата)?
  • Выходные данные (Response): Что вернет сервер в случае успеха? А в случае ошибки?
  • Примеры: Пример JSON-запроса и JSON-ответа.

    • Для документирования REST API часто используют стандарт OpenAPI (Swagger). Это специальный формат, который позволяет автоматически генерировать красивую документацию, где можно нажать кнопку «Try it out» и отправить реальный запрос.

    Сравнение SOAP и REST

    | Характеристика | SOAP | REST | | :--- | :--- | :--- | | Тип | Протокол | Архитектурный стиль | | Формат данных | Только XML | JSON, XML, HTML, Text | | Сложность | Высокая | Низкая | | Безопасность | Встроена (WS-Security) | Зависит от реализации (HTTPS, OAuth) | | Кэширование | Сложно | Легко (средствами HTTP) |

    Резюме

  • API — это интерфейс для взаимодействия программ.
  • JSON — легкий и популярный формат данных, XML — строгий и тяжелый.
  • REST — самый популярный стиль для веб-сервисов, использующий методы HTTP (GET, POST, PUT, DELETE).
  • SOAP — протокол для сложных корпоративных систем с повышенными требованиями к надежности.
  • Задача аналитика — описать структуру запросов и ответов, а также обработку ошибок (коды 4xx и 5xx).

    • В следующей статье мы спустимся еще глубже и разберем, где и как хранятся данные. Мы поговорим о Базах данных и языке SQL.

    5. Работа с данными и документацией: основы SQL и написание технических заданий

    Работа с данными и документацией: основы SQL и написание технических заданий

    В предыдущей статье мы разобрали, как системы общаются друг с другом через API, используя форматы JSON и XML. Мы выяснили, что данные «летают» между серверами. Но где эти данные «живут», когда они никуда не летят? И как описать всю систему целиком, чтобы разработчики собрали именно то, что нужно?

    Сегодня мы затронем два важнейших навыка системного аналитика: умение работать с Базами Данных (SQL) и умение писать Технические Задания (ТЗ).

    Хранение данных: Реляционные базы данных

    Представьте огромный картотечный шкаф в библиотеке. Чтобы найти книгу, вам нужно знать, в каком ящике она лежит. В мире IT таким шкафом является База Данных (БД).

    Существует много видов баз данных, но стандартом для большинства бизнес-систем остаются реляционные базы данных (от англ. relation — отношение, связь). Самые популярные из них: PostgreSQL, MySQL, Oracle, MS SQL Server.

    Как устроена реляционная БД?

    В основе реляционной базы лежит таблица. Это очень похоже на Excel, но с более строгими правилами.

  • Таблица (Table): Хранит данные об объектах одного типа (например, таблица Users — пользователи, таблица Orders — заказы).
  • Столбец (Column/Field): Атрибут объекта (Имя, Email, Дата рождения). У каждого столбца есть строгий тип данных: число, строка, дата.
  • Строка (Row/Record): Конкретная запись (Пользователь Иван Иванов).

    • Первичные и внешние ключи

    Чтобы базы данных работали быстро и не путались, используются уникальные идентификаторы.

    * Primary Key (PK, Первичный ключ): Уникальный номер записи в таблице. Например, UserID = 101. Двух пользователей с одинаковым ID быть не может. * Foreign Key (FK, Внешний ключ): Ссылка на первичный ключ другой таблицы. Именно так создаются связи.

    !Связь между таблицами клиентов и заказов через внешний ключ.

    Язык SQL: Как разговаривать с базой данных

    Аналитику редко приходится создавать таблицы (это работа администраторов БД или разработчиков), но аналитик обязан уметь читать данные. Для этого используется язык SQL (Structured Query Language).

    Самая главная команда для аналитика — это SELECT. Она позволяет выбрать данные из таблицы.

    Анатомия простого запроса

    Представим, что мы хотим получить список email-адресов всех активных пользователей.

    Разберем по словам: * SELECT name, email — покажи мне только колонки «имя» и «email». * FROM users — ищи в таблице «пользователи». * WHERE status = 'active' — фильтр: бери только тех, у кого статус «активный».

    Объединение таблиц (JOIN)

    Данные редко лежат в одной таблице. Информация о клиенте — в одной, о его заказах — в другой. Чтобы собрать их вместе, используется оператор JOIN.

    Существует несколько видов объединений, но аналитику чаще всего нужны два:

  • INNER JOIN: Вернет только те записи, которые есть в обеих таблицах. (Покажет только тех клиентов, которые сделали хотя бы один заказ).
  • LEFT JOIN: Вернет все записи из левой таблицы и подставит данные из правой, если они есть. (Покажет всех клиентов, даже если они ничего не заказывали — напротив заказов будет пустота).

    • Проектирование данных: ER-диаграммы

    Прежде чем создавать таблицы, аналитик должен спроектировать структуру данных. Для этого используются ER-диаграммы (Entity-Relationship) — диаграммы «Сущность-Связь».

    На этапе проектирования важно определить типы связей между сущностями:

    * Один-к-одному (1:1): У одного гражданина один паспорт. * Один-ко-многим (1:M): У одного клиента много заказов. * Многие-ко-многим (M:M): Один студент посещает много курсов, и на одном курсе учится много студентов.

    Оценка объема базы данных

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

    где: * (Size) — итоговый размер таблицы в байтах. * (Row Size) — средний размер одной строки в байтах (сумма длин всех колонок). * (Number of rows) — прогнозируемое количество строк (записей). * (Index overhead) — коэффициент накладных расходов на индексы (обычно от 0.3 до 0.5, то есть индексы занимают 30-50% дополнительного места).

    Эта формула помогает заранее понять, хватит ли нам стандартного сервера или нужно заказывать дорогое хранилище.

    Техническое задание (ТЗ): Главный документ проекта

    Мы научились собирать требования, рисовать диаграммы, проектировать API и базы данных. Теперь все это нужно собрать в единый документ — Техническое задание (ТЗ) или Спецификацию требований.

    ТЗ — это закон для разработчика. Если в ТЗ не написано, что кнопка должна быть красной, разработчик имеет право сделать её серой.

    Структура идеального ТЗ

    В разных компаниях используют разные шаблоны (например, ГОСТ 34 или IEEE 830), но логическая структура всегда похожа.

    #### 1. Глоссарий (Термины и определения) Словарь проекта. Чтобы все понимали, что такое «Лид», «Транзакция» или «Валидация» одинаково.

    #### 2. Общее описание (Введение) Контекст задачи. Какую бизнес-проблему мы решаем? Кто пользователи системы?

    #### 3. Бизнес-процессы (AS IS и TO BE) Здесь мы вставляем наши BPMN-диаграммы, которые изучили ранее. Показываем, как процесс работает сейчас и как будет работать после внедрения системы.

    #### 4. Функциональные требования Самый объемный раздел. Здесь описывается каждая функция системы. Часто группируется по ролям пользователей или экранам интерфейса.

    > Совет: Используйте ссылки на макеты экранов (Figma) и описывайте логику каждого поля: «Поле 'Телефон' — обязательное, маска ввода +7 (XXX)...».

    #### 5. Модель данных и Интеграции Сюда идут ER-диаграммы и описание методов API (Swagger/OpenAPI), о которых мы говорили в прошлых статьях.

    #### 6. Нефункциональные требования Безопасность, производительность, надежность.

    Критерии качества документации

    Хорошее ТЗ должно обладать свойством недвусмысленности. Фразы вроде «система должна работать быстро» или «интерфейс должен быть интуитивно понятным» — это мусор. Они не поддаются проверке.

    Правильный подход: * ~~Система должна работать быстро.~~ * Время отклика сервера на запрос поиска не должно превышать 500 мс при нагрузке 1000 пользователей.

    Жизненный цикл документации

    Работа над ТЗ не заканчивается после того, как вы поставили точку. Документация живет вместе с проектом.

  • Draft (Черновик): Аналитик набрасывает структуру.
  • Review (Рецензирование): Ведущий аналитик или архитектор проверяет логику.
  • Approval (Согласование): Заказчик подтверждает, что это именно то, что ему нужно.
  • Development (Разработка): Программисты пишут код по ТЗ. Часто на этом этапе всплывают детали, и ТЗ приходится уточнять.
  • Actualization (Актуализация): Если в коде что-то изменили, это обязательно нужно отразить в документации.

    • !Процесс поддержания документации в актуальном состоянии.

    Резюме курса

    В этой серии статей мы прошли путь от понимания роли аналитика до написания технического задания.

  • Мы узнали, что аналитик — это мост между бизнесом и IT.
  • Научились выявлять требования и отличать «хотелки» от реальных задач.
  • Освоили визуализацию через UML и BPMN.
  • Разобрали архитектуру: REST API, JSON и интеграции.
  • Поняли, как хранятся данные в SQL-базах и как оформить все знания в Техническое задание.

    • Эти пять навыков составляют «скелет» профессии. Дальше вас ждет наращивание «мышц»: изучение конкретных инструментов (Jira, Confluence, Postman), углубление в архитектуру микросервисов и развитие Soft Skills для переговоров с заказчиками.