BSA · экзамен · тренажёр

Обследование → Проектирование → Разработка → Тестирование → Внедрение → Сопровождение.

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

ИТ-аналитик, архитектор, разработчик, тестировщик, специалист внедрения/сопровождения, менеджер, DevOps, технический писатель.

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

Сбор и формализация требований, перевод бизнес-языка на технический, поддержка разработки и тестирования, помощь в приёмке.

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

Декомпозиция — процесс разделения целого на части; позволяет рассматривать сложную систему как совокупность взаимосвязанных подсистем.

Цели: упростить понимание, распараллелить работы, снизить риск ошибок, оценить трудозатраты.

Функциональная, объектная (компонентная), структурная, темпоральная (событийная).

• Функциональная — что система должна делать.
• Объектная/компонентная — из каких частей состоит.
• Структурная — деление по выбранному критерию.
• Темпоральная/событийная — по этапам или событиям во времени.

Подчинённость · Единственность критерия · Целостность (полнота + взаимное непересечение).

• Подчинённость — сверху вниз, от корня.
• Единственность критерия — на одном уровне делим по одному и тому же критерию.
• Полнота — подсистемы в сумме покрывают верхний уровень.
• Непересечение — элементы не входят одновременно в две группы.

7 ± 2. Если больше — переходим к табличной/каталожной форме.

Правило связано с пределом «оперативной памяти» человека (Миллер). На нулевом уровне всегда сама система, без разбиения.

Список терминов и понятий проекта с однозначной трактовкой; ведётся с самого начала и на протяжении всего проекта.

Спасает от путаницы, когда одно понятие зовут по-разному («стейкхолдер» = «заинтересованная сторона») или одним словом — разные понятия («счёт» как лицевой и как балансовый). Хранят историю изменений и источник.

Структурированный список НПА, регламентов, статей, интервью, опытов конкурентов, к которым команда возвращается по мере необходимости.

Параметры: источник, адрес, приоритет, актуальность/легитимность, дата ввода/окончания, кто добавил, отметка об изучении, заметки.

Каталог — трёхбуквенный мнемоник (STA, INF); элементы — XXXYYYYY (3 буквы каталога + уникальный номер).

Например, st00200 — стейкхолдер №200. Цель — устойчивый идентификатор, переживающий любые переименования.

Надсистема — то, частью чего является наша система. Смежная — другая подсистема той же надсистемы.

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

1) Корень → 2) выбор критериев → 3) разбиение по каждому → 4) проверка правил → 5) выбор лучшего варианта → 6) повтор для подсистем → 7) останов на достаточном уровне.

Останавливаемся, когда дальнейшая детализация не нужна тем, кто будет работать с элементами.

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

Цитата Тома Гилба: «Стейкхолдеров всегда на одного больше, чем вы знаете, а у тех, кого знаете, минимум на одну потребность больше, чем вам сейчас известно».

Выгодоприобретатели · пользователи · взаимодействующие стороны · конкуренты · регуляторы · команда сопровождения · команда разработки/внедрения.

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

Группа стейкхолдеров с одинаковыми функциями в системе. Не путать «пользователей» как роль, если есть разные группы (клиент, продавец, бухгалтер).

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

Идентификатор, ФИО (если есть), контакты, организация, должность, локация, роль, масштабируемость, ответственность, полномочия, опыт, дата добавления.

Для маленького проекта достаточно 2–4 атрибутов, чтобы разложить по луковичной диаграмме и определить роли.

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

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

«Кто платит? Кто пользуется? С кем взаимодействует? Кто конкуренты? Какие регуляторы? Кто поддерживает? Кто данные готовит?»

Это семь классов вопросов под семь групп стейкхолдеров.

Не рекомендуется, если разные группы выполняют разные функции.

Иначе теряется специфика — у клиента, мастера и менеджера разные потребности и проблемы. Размытое название = нечёткие требования.

«Пригодное для практического использования представление потребности или решения» — описание поведения системы, её свойств, характеристик и ограничений.

Бизнес-требования · бизнес-правила · пользовательские · внешние интерфейсы · ограничения · системные · функциональные · нефункциональные · атрибуты качества.

• Бизнес-требование — высокоуровневая бизнес-цель организации.
• Пользовательское — что пользователь хочет делать с системой.
• Функциональное — поведение системы в конкретных условиях.
• НФТ — свойства/особенности/ограничения системы.

Иерархически и горизонтально. Бизнес-требования рождают пользовательские, те — функциональные. НФТ привязываются к ФТ.

Поэтому при изменении одного уровня надо проверять связанные. Эта связность — основа трассировки требований.

as is — как есть сейчас. to be — как должно стать после внедрения.

Сначала рисуем as is (выявляем проблемы), потом to be (формулируем решение), потом — порядок перехода.

Диаграмма «чёрного ящика»: показывает систему и её окружение — внешние сущности и потоки данных между ними.

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

Сама система (овал) · внешние сущности (прямоугольники: пользователи, организации, смежные системы) · стрелки потоков данных с подписями.

У каждой внешней сущности должен быть хотя бы один входящий или исходящий поток.

Протоколы передачи и интерфейсы взаимодействия — это уровень реализации, а контекстная диаграмма — уровень бизнес-понимания.

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

Это первый артефакт, который рисуют после стейкхолдеров: помогает не упустить ни одну внешнюю сторону.

Анализ документации · контекста · подобных систем · глоссарий · интервью · фокус-группы · опрос · семинар · мозговой штурм · прототипирование · моделирование БП.

Техника выявления потребностей и боли через личное общение, задавание вопросов и документирование ответов.

Самый применяемый метод. Требует подготовки: знать стейкхолдеров, домен, проблемы.

Опрос/анкетирование — систематический сбор ответов на одинаковые вопросы у большой группы; интервью — глубокое общение с одним.

Опрос даёт ширину (статистика), интервью — глубину (нюансы и эмоции).

Техника, где участники играют роли стейкхолдеров для совместного понимания проблем и поиска решений.

Полезна, чтобы проверить гипотезы аналитика о потребностях и функциях ролей.

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

Цель — сгенерировать как можно больше идей и выбрать лучшее. Критика идей запрещена на этапе генерации.

Групповое мероприятие для достижения цели и выработки согласия по выбранному вопросу.

В отличие от штурма, фокус не на генерации идей, а на принятии решения по существующим вариантам.

Документ с бизнес-требованиями: проблемы, окружение, возможности, бизнес-цели, границы, метрики успеха.

Может называться по-разному: BRD, Vision, Видение, Задание, ТЗ. Подробно — глава 5 Вигерса.

1. Проблемы, для которых строится система;
2. Окружение, предусловия, ситуация;
3. Возможности для решения;
4. Бизнес-цели;
5. (Доп.) задачи, иерархия проблем, основные функции;
6. Границы системы;
7. Критерии и метрики успеха.

После первой итерации почти всегда оказывается, что что-то непонятно или появились новые вопросы.

Передавать «непонятное» дальше — гарантировать переделку. Лучше потратить ещё один цикл и вернуться с уточнениями.

Часть реального мира, рассматриваемая в определённых пределах: всё, что влияет на систему, находится под её влиянием или способствует её пониманию.

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

Подчёркиваем существительные и пары «существительное — глагол» / «существительное — отглагольное существительное». Часто встречающиеся существительные с действиями — кандидаты в сущности.

Каждая сущность должна быть целостной и логически отделённой.

1. Выделение кандидатов в сущности;
2. Выделение сущностей;
3. Определение ключевых атрибутов;
4. Определение связей;
5. Сопоставление атрибутов с сущностями;
6. Назначение ключей и нормализация;
7. Завершение и проверка.

Процесс итеративный — повторяется до согласия с бизнесом.

1:1, 1:М, М:1, М:М.

М:М в реляционной модели разворачивают через промежуточную сущность с двумя внешними ключами.

Create · Read · Update · Delete. Проверяем, что для каждой сущности определено, кто и при каких условиях выполняет каждую из 4 операций.

Если для сущности нет роли «чтения» — возможно, сущность лишняя. Если запрещено удаление — это сознательное решение (например, «перевод в архив»).

Описание данных в бизнес-терминах + техническое описание (типы, форматы, ограничения, привязки к НСИ, безопасность).

Один из способов ведения метаданных.

• Глоссарий: термины и бизнес-понятия, универсален для предметной области, атомарные понятия.
• Словарь данных: + типы, размерности, структура, ограничения; специфичен для конкретной системы; может содержать составные элементы.

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

Цель — минимизация избыточности и аномалий обновления.

• Концептуальная — основные сущности и связи; делает аналитик.
• Логическая — сущности, атрибуты, ключи, связи; делает аналитик с архитектором/разработчиком.
• Физическая — таблицы, индексы, СУБД-специфика; делает разработчик/архитектор.

Диаграмма «сущность — связь», визуализирующая модель данных предметной области.

Модель — упрощённое описание действительности, позволяющее исследовать или обрабатывать объект.

Перевод в архив (флаг is_archived) или указание периода действия (даты начала/окончания актуальности).

Так сохраняем историю и не теряем связи (например, услуги уволенного мастера).

Последовательность действий, ограниченная началом и окончанием и направленная на получение заданного результата (продукта/услуги).

• Цель/выход — ради чего процесс выполняется.
• Владелец — отвечает за результат (негрупповая роль).
• Исполнители — выполняют шаги.
• Вход — ресурсы, преобразуемые в результат.
• Начало и окончание — события-триггеры.
• Применяемые ресурсы — справочники, не меняющиеся в процессе.
• Шаги — последовательность действий.

Основные (добавляют ценность) и обеспечивающие (поддерживающие, без прямой ценности).

Сначала рассматриваем основные, потом обеспечивающие. Внутри — самые важные/значимые в первую очередь.

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

БП по ролям превращается в банальный список обязанностей и теряет смысл сквозной цепочки.

Business Process Model and Notation — графическая нотация для моделирования бизнес-процессов.

Стандарт OMG, общепринят, читаем для бизнеса и разработчиков.

Process · Collaboration (сообщения) · Choreography (последовательность взаимодействий) · Conversation (верхний уровень).

Самая частая — Process Diagram (процесс).

• Event — событие (старт/конец/промежуточное).
• Activity — действие/задача.
• Gateway — шлюз (развилка/слияние).
• Flow — поток (управления/сообщений).
• Data — данные.
• Artefact — артефакт (комментарий, группа).
• Pool/Swimlane — пул и дорожка для разделения участников.

Исполняемые могут реально запускаться в Camunda/Bizagi/Business Studio — нужны строгие правила. Неисполняемые — для обсуждения; команды используют минимальный набор элементов.

1. Выполнение бизнес-требований;
2. Решение проблем ключевых стейкхолдеров;
3. Выполнение функций ролей системы.

Краткая формулировка ценности для пользователя и описание функциональности, помещающаяся на стикере.

US — не полное требование, а отправная точка для обсуждения. Применяется в Agile/Scrum.

Как [роль], я хочу/могу [действие], чтобы [получить выгоду].

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

Заголовок · тело (Как…я хочу…чтобы…) · критерии приёмки · тестовые сценарии.

Условия, при которых US считается выполненной. Формат Given–When–Then: учитывая [предусловие], когда [действие], тогда [результат].

Card (помещается на карточке) · Conversation (обсуждение) · Confirmation (подтверждение пользователем и командой).

Independent · Negotiable · Valuable · Estimable · Small · Testable.

Критерии качества хорошей пользовательской истории.

• + Маленькие тестируемые куски, понятный бизнесу язык, фокус на пользе.
• − Требуют контекст и видение целого, не дают полную документацию для реализации, не подходят для длительного хранения.

Краткими · простыми · ценными · атомарными (одна функция) · бизнесовыми (без техдеталей).

Описание взаимодействия участников с системой для достижения цели основного действующего лица.

UC отвечает не «ЧТО хочет делать», а «ЗАЧЕМ, с какой целью».

US — краткая ценностная формулировка; UC — подробное описание сценария взаимодействия с шагами, потоками, предусловиями и постусловиями.

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

• Главный актор (Primary) — получает бизнес-ценность, инициатор; не обязан сам участвовать.
• Участник — все, кто заинтересован во взаимодействии.

• Чёрный ящик — только внешние действия.
• Полупрозрачный — понятно, что внутри, без техдеталей.
• Прозрачный — детали внутреннего поведения.

• Предусловие — что должно быть истинно до старта UC (не входит в шаги).
• Триггер — событие, запускающее UC.
• Постусловие — что истинно после завершения; делится на минимальные гарантии и гарантии успеха.

Основной (главный, успешный) · альтернативный (другие пути к цели) · исключительный (когда цель недостижима).

Шаги основного — сквозная нумерация. Альтернативные/исключительные — с привязкой к шагу основного, через цифро-буквенную нумерацию.

• include — общая часть, включаемая в несколько UC; не обязана быть самодостаточной.
• extend — необязательное расширение существующего UC; базовый UC должен оставаться функциональным без расширения.

1. Бизнес-понятия, без технических подробностей.
2. Ограничивай границы достижением цели.
3. Простые предложения: кто-что-делает.
4. Один шаг = все данные в одном направлении.
5. «Система подтверждает», а не «проверяет».
6. Сложные взаимодействия — к 4 шагам транзакции.
7. UI/НФТ/бизнес-правила — отдельно, в UC только ссылки.

Ряд состояний (статусов), которые проходит экземпляр сущности под влиянием действий или условий.

Реализуется атрибутом «Статус». Подробнее статусные модели разбираются в BSA10.

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

Например, в «Слот обслуживания» не пишут ФИО мастера, а указывают employee_id из справочника «Сотрудники». Справочники проектируются раньше основных сущностей.

1. Назначение;
2. Атрибуты с описанием;
3. Связи (ER/диаграмма классов);
4. Действия (операции) над экземпляром;
5. Роли и права доступа;
6. Жизненный цикл и статусы;
7. Визуализация (UI);
8. Интеграция;
9. Отчёты, мониторинг.

Мнемонику, наименование (рус), описание, тип, обязательность, значение по умолчанию, длину, комментарии.

Не добавляй атрибуты «на всякий случай» — только если уверен в их необходимости.

Системное имя атрибута/сущности, под которым она идентифицируется в коде.

Самый устойчивый идентификатор: даже название может измениться, мнемоника обычно нет.

Структурная UML-диаграмма, показывающая иерархию классов: атрибуты, методы, связи между классами.

Применяется для документации, визуализации и прямого/обратного проектирования.

1. Не конкретные объекты, а классы (обобщения).
2. Существительные из текстов, US, UC, отчётов — кандидаты в сущности или атрибуты.
3. Глаголы — операции.
4. Не плодить лишних сущностей.

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

CRUD + подтверждения и откаты, форму визуализации, интеграцию, историю, архив, расчёты, побочные эффекты в других объектах.

Если для объекта нет роли, читающей его, — возможно, объект лишний.

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

Пример: удаление мастера ⇒ удаление его слотов ⇒ потеря записи клиента. Решение — пометка «архив» или каскадная корректировка с уведомлением.

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

Альтернатива — диапазон valid_from/valid_to. Без таких полей — потеря истории.

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

Описывается диаграммой переходов состояний или таблицей. Для разработчиков нужно: исходное состояние, инициатор, действие, условия/проверки, целевое состояние.

Таблица «Роль × Объект × CRUD», где для каждой ячейки указаны условия (например, «только своя запись»).

Права на функцию = совокупность прав на CRUD для нужных объектов.

1. Операцию и её привязку (до/после);
2. Проверяемые атрибуты;
3. Описание проверки;
4. Критичность;
5. Сообщение об ошибке и куда вывести;
6. Что делать (прервать, продолжить, изменить статус, залогировать).

Подтверждение/откат, сортировка, фильтр, поиск, форма визуализации (список/карточка), логирование, отправка сообщений.

1. Форм-фактор (мобильный, ПК, киоск);
2. Тип приложения (маркетплейс, корп., игра);
3. Способ управления (мышь, клавиатура, голос);
4. Локализация (язык, часовой пояс);
5. Спец. возможности (доступность, контраст).

Взаимодействие пользователя в роли с системой в рамках целевой задачи.

Например, для клиента барбершопа целевая задача — бронирование услуги (а регистрация — обеспечивающая).

Экран делят на фреймы; типичные: список экземпляров, карточка одного, связанные сущности.

Поиск, фильтрация, сортировка. Указывают: поля, точность совпадения, сохранение фильтра/сортировки.

• Wireframe — низкая детализация, скелет.
• Mockup — высокая детализация, статичный визуал.
• Prototype — интерактивный, кликабельный.

Инструменты: Balsamiq (wireframe), Figma (mockup/prototype). Допустимы и эскизы от руки.

Чтобы при переключении ролей человек не учил интерфейс заново.

Особенно важно для смежных функций: «чтение» и «корректировка» одних и тех же данных.

Тип контрола (поле, чекбокс, список), маска, обязательность, валидация, сообщения, поведение по умолчанию, условия активности.

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

Их также называют атрибутами качества.

Run time (время выполнения) и design time (время разработки).

• Run time: доступность, надёжность, долговечность, масштабируемость, удобство использования, безопасность, производительность, ограничения.
• Design time: повторяемость, расширяемость, портируемость, совместимость, обслуживаемость, локализация, тестируемость.

ФТ: «система формирует список свободных слотов». НФТ: «… не более чем за 10 секунд при 1000 одновременных пользователей».

НФТ всегда измеряемы, имеют границу или порог. ФТ описывают факт действия.

Скорость отклика и пропускная способность системы при заданной нагрузке.

• Кол-во зарегистрированных пользователей;
• Кол-во одновременно работающих;
• Пиковые периоды;
• Контролируемые операции и их время отклика.

• Доступность — доля времени, когда система готова к работе (например, 99% с 9:00 до 21:00).
• Надёжность — корректное функционирование без отказов; включает время восстановления после сбоя и допустимую потерю данных.

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

Обычно описывается в виде волн внедрения, регионов, числа точек обслуживания.

Разделение прав доступа, защита данных, аудит. Часто формулируется как «доступ к функции X — только роли Y».

Архитектор — за решение. Аналитик — за сбор и формулирование требований, на основании которых архитектор принимает решение.

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

Аналитик взаимодействует с заказчиком, безопасниками, архитектором, тестировщиками.

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

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

Бизнес-требования · требования заинтересованных сторон · функциональные · нефункциональные.

Каждому типу назначают трёхбуквенный префикс (например, BRD, STK, FRD, NFR).

Буквенно-цифровой постоянной длины: BRD000017 (а не BRD17).

Постоянная длина важна для сортировок и поиска.

• Состояние: даты, статус, приоритет, версия, спринт.
• Описание: название, текст, ссылка на материалы, метод проверки, источник, связи.
• Ответственные: текущий исполнитель и др.

Управление требованиями: DOORS, ArchiMate, СУТр. Управление задачами: Jira, WEEEK, Trello, Confluence.

Проверка соответствия реального поведения программы её ожидаемому поведению.

Цель: подтвердить соответствие или выявить несоответствие; найти ошибки до пользователей. Тестирование не гарантирует качество, а оценивает его.

• Ошибка (error) — действие человека, ведущее к неправильному результату.
• Отказ (failure) — отклонение поведения системы от ожидаемого.
• Дефект (defect) — изъян в коде/системе, который при выполнении может привести к отказу.

1. Идентификатор;
2. Краткое название;
3. Приоритет;
4. Предусловие;
5. Шаги выполнения;
6. Ожидаемый результат (ОР);
7. Постусловие (восстановление);
8. Фактический результат (ФР).

Позитивный — корректные данные, ожидаем успешное выполнение. Негативный — некорректные/граничные данные, ожидаем обработку ошибки.

• Repeatable — кейс должен давать одинаковый результат при повторных запусках.
• Independent / Atomic — кейс не зависит от других кейсов и проверяет одну ситуацию.

1. Идентификатор;
2. Краткое описание (что/где/когда);
3. Предусловие;
4. Шаги воспроизведения;
5. Ожидаемый и фактический результат;
6. Постусловие;
7. Окружение (ОС, браузер, разрешение);
8. Приоритет и важность;
9. Скриншоты, логи, материалы.

Лучше других знает, как должна работать система, поэтому может составлять качественные тест-кейсы и оценивать ФР.

Установка связей между системами для единого информационного пространства и поддержки сквозных бизнес-процессов.

1. Выявление потребности (что передавать);
2. Атрибуты качества (как передавать — НФТ);
3. Выбор систем (мастер/получатель);
4. Маппинг данных;
5. Выбор стиля интеграции;
6. Журналирование;
7. Описание ошибок;
8. Разработка вызовов;
9. Интеграционное тестирование.

Аналитик обычно ведёт шаги 1–7.

1. Объёмы и количество данных;
2. Сроки и частота передачи;
3. Форматы и схемы данных, бизнес-логика;
4. Своевременность (синхронность/асинхронность);
5. Маппинг.

• Синхронная: отправитель ждёт ответ, не делая других дел (оплата по карте).
• Асинхронная: отправил и работает дальше, ответ — потом (отчёты, события).

Мастер-система — источник истины по данным. Получатель — потребитель этих данных.

Один и тот же объект может быть мастером в одной интеграции и получателем в другой.

Общая БД · обмен файлами · обмен сообщениями · удалённый вызов процедур (RPC).

• + Согласованность, единый язык (SQL), частый обмен.
• − Сложная общая схема, риск блокировок, сильная связность приложений (изменение схемы влияет на всех).

• + Слабая связность, простота реализации.
• − Низкая частота, рассинхронизация, контроль уникальности имён, сообщения о доставке.

Форматы: CSV, XML, JSON, YAML.

• + Частый обмен, асинхронность, слабая связность, разные способы доставки (точка-точка, broadcast).
• − Возможные задержки, сложность тестирования и отладки, нужны механизмы преобразования.

• + Интеграция функциональности, инкапсуляция данных, разные интерфейсы, поддержка транзакций.
• − Сильная связность, сбой одной системы тянет всех, кто на ней.

Технологии: SOAP, REST.

Сопоставление полей между двумя сторонами интеграции с учётом типов, размерностей, обязательности и преобразований.

Например, ФИО — единое поле в одной системе и три отдельных в другой; денежные суммы — округления.

Архитектор, но на основании критериев интеграции, собранных аналитиком.

Representational State Transfer — архитектурный стиль для взаимодействия систем по сети, предложенный Роем Филдингом в 2000 году.

Системы, удовлетворяющие принципам REST, называются RESTful. REST — не протокол, а набор ограничений.

1. Клиент-серверная архитектура — разделение ответственности.
2. Stateless — сервер не хранит сессию между запросами.
3. Кэширование — ответы могут кэшироваться.
4. Единообразие интерфейса (HATEOAS) — сервер возвращает ресурс + связи + допустимые действия.
5. Слоистая архитектура (Layered system) — клиент не знает, через сколько слоёв идёт запрос.
6. Code on demand — передача исполняемого кода (необязательная).

Сервер в каждом запросе получает всё необходимое для обработки и не сохраняет состояние клиента у себя.

Состояние держит клиент (например, в токене авторизации). Это упрощает горизонтальное масштабирование.

• GET — получить ресурс или коллекцию;
• POST — создать новый ресурс;
• PUT — обновить ресурс целиком (по ID);
• DELETE — удалить ресурс по ID.

Дополнительно: PATCH — частичное обновление.

В https://21-school.ru/blog: https:// — scheme/транспорт, 21-school.ru — host/сервер, blog — ресурс/объект.

Application Programming Interface — описание способа взаимодействия программных систем.

API — это контракт. Содержит: операцию, входные данные, выходные данные, описание ошибок.

1. Синтаксис запроса и ответа;
2. Примеры запроса и ответа;
3. Описание входных и выходных параметров.

XML (язык разметки), JSON (текстовый формат обмена), Binary (бинарный).

В REST чаще всего JSON.

1. Идентификатор поля (название.поле);
2. Бизнесовое наименование/описание;
3. Тип данных;
4. Размерность;
5. Обязательность (может различаться у отправителя/получателя);
6. Комментарии и преобразования.

Получатель должен валидировать сообщение и при несоответствии сообщать отправителю об ошибке (формат, обязательность, наличие в справочнике, логика).

Также сообщения о недоступности системы-получателя. Описание ошибок — задача аналитика.

Свойство, при котором повторный вызов даёт тот же результат, что и однократный. Идемпотентны: GET, PUT, DELETE. Не идемпотентен: POST.

Simple Object Access Protocol — стандартизированный протокол обмена структурированными сообщениями в формате XML (с 1998 года, стандарт W3C).

• SOAP — протокол со строгим стандартом, формат XML, формальные описания (WSDL).
• REST — архитектурный стиль, не привязан к формату, договоренности на каждом проекте.

SOAP более «жёсткий», REST более гибкий.

• Стандартизация W3C — общие правила.
• Однозначность по стандарту.
• Готовые библиотеки во многих языках.
• Встроенная обработка ошибок (fault).

Тяжёлые библиотеки и большие сообщения — на мобильных и при нестабильном интернете не всегда подходят.

• XML — язык разметки документов; используется для сообщений и описаний.
• XSD — язык описания структуры XML-документа (типы, обязательность, размерность).
• WSDL — язык описания веб-сервисов: операции, сообщения, адрес.

• Code-first — сначала код, потом из него генерируются документы.
• Contract-first — сначала документы (WSDL/XSD), потом из них генерируется код.

Часто на интеграции: первая система — Code-first, остальные — Contract-first.

• <types> / <schema> — описание типов данных.
• <message> — определение сообщений.
• <portType> — операции (методы) сервиса.
• <binding> — привязка к транспорту.
• <service> / <port> — точка доступа (endpoint).

До трёх: input, output и fault (ошибка).

Часто описывают только input/output, но fault — стандартный механизм для возврата ошибки.

• <sequence> — элементы должны идти в указанном порядке.
• minOccurs — минимальное число повторений (по умолчанию 1, то есть обязательный).
• maxOccurs — максимальное число (по умолчанию 1).
• maxOccurs="unbounded" — без верхнего предела.

Элемент обязателен, если minOccurs ≥ 1; необязателен, если minOccurs="0".

Сложный (составной) тип данных в XSD: содержит вложенные элементы и/или атрибуты.

Часто внутри объявляют <sequence>, чтобы зафиксировать порядок дочерних элементов.

• < → <
• > → >
• & → &
• " → "
• ' → '

По стандарту W3C — ISO 8601 (например, 2026-04-26). Привычное «dd.mm.yyyy» стандартом не предусмотрено.

Уникальный URI-идентификатор, позволяющий различать одинаково названные элементы из разных схем.

Объявляется атрибутом xmlns или xmlns:prefix. Например, xmlns:ns="http://example.com/pet".

URL, по которому доступен сервис; описан в WSDL внутри <service> / <port> в атрибуте location.

1. Каталог источников информации, глоссарий (BSA00);
2. Каталог стейкхолдеров, луковичная диаграмма (BSA01);
3. Роли AS-IS, контекстная диаграмма (BSA02);
4. BRD/Vision (BSA03);
5. Сущности, CRUD-матрица, словарь данных, логическая ER (BSA04–05);
6. Декомпозиция БП, BPMN-диаграммы (BSA06);
7. User Stories с критериями приёмки (BSA07);
8. Use Cases с потоками (BSA08);
9. Описание объектов, диаграмма классов (BSA09);
10. CRUD-функционал, статусы, ролевая модель (BSA10);
11. Wireframes, описание контролей (BSA11);
12. НФТ — атрибуты качества (BSA12);
13. Управление требованиями, тест-кейсы, дефекты (BSA13);
14. Описание интеграций — потоков данных, маппинг (BSA14);
15. API-описания (REST/SOAP) — BSA15–16.

Business Analysis Body of Knowledge — руководство к своду знаний по бизнес-анализу от IIBA.

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

• Карл Вигерс, Джой Битти. Разработка требований к программному обеспечению (3-е изд.).
• BABOK v3. Руководство IIBA.
• Алистер Коберн. Современные методы описания функциональных требований.
• Мартин Фаулер. UML. Основы.
• Майк Кон / Джефф Паттон. Пользовательские истории.
• Бобби Вульф, Грегор Хоп. Шаблоны интеграции корпоративных приложений.
• Владимир Репин. Моделирование бизнес-процессов в нотации BPMN.

Пользовательское — что хочет пользователь («забронировать слот»). Функциональное — как именно система это делает («формирует список свободных слотов и сохраняет выбранный с привязкой к мастеру»).

• US — короткая ценностная карточка, для бэклога; «как…я хочу…чтобы».
• UC — детальный сценарий взаимодействия с шагами, потоками, предусловиями и постусловиями.

• ER — модель данных предметной области: сущности и связи, фокус на структуре хранения.
• Class diagram — UML-структура: атрибуты + методы + наследование, ближе к коду.

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

Изменения в контракте без согласования = поломки на стороне получателя.

Обязан: 1–7 (потребность, НФТ, мастер/получатель, маппинг, стиль, журналирование, ошибки). Может: 8–9 (вызовы и интеграционное тестирование) — при наличии знаний.

• REST — мобильные клиенты, веб, гибкие изменения, слабая связанность, JSON.
• SOAP — корпоративные/банковские/государственные интеграции, строгая стандартизация, транзакции, формальные контракты.

Связь между требованиями разных уровней: бизнес → пользовательское → функциональное → тест-кейс → дефект.

Позволяет понять, ради какой бизнес-цели делается каждое FT, и, наоборот, проверить, что бизнес-цель полностью покрыта.

Удаление часто опасно (теряется история и связи). Архивирование — компромисс: запись недоступна для новых операций, но видна для старых.

Один кейс = одна проверка. Облегчает диагностику: понятно, что именно сломалось.

1. Не вести глоссарий и каталог источников.
2. Называть всех «пользователями».
3. Пропускать НФТ.
4. Включать в UC технические детали и UI.
5. Делать декомпозицию по разным критериям на одном уровне.
6. Игнорировать обработку ошибок в интеграциях.
7. Удалять данные вместо архивирования.
8. Не описывать предусловия и постусловия в UC.

1. Участник вводит запрос и передаёт данные;
2. Система подтверждает (валидирует);
3. Система изменяет данные;
4. Система выдаёт результат.

К этому шаблону сводят сложные взаимодействия.