Школа
системного анализа
и проектирования
+7 499 350 7710
Расписание
Все курсы
Компаниям
База знаний
О школе
✆
Systems Education
Школа системного анализа
и проектирования
+7 499 350 7710
☰ База знаний
в телеграм-канале школы SE
Читать канал школы
Анонсы статей и вебинаров

Промт-инжиниринг для аналитиков по фреймворку КОМПОЗИТОР

Автор: Алина Богачёва

Аннотация

Системные и бизнес‑аналитики ежедневно пишут десятки требований, юскейсов и спецификаций. На каждый документ уходит 2–3 часа: собрать факты, договориться об уровне детализации, причесать стиль. Акроним КОМПОЗИТОР превращает ChatGPT, GigaChat, Deepseek и другие чат-боты на основе больших языковых моделей из капризного собеседника в штатного аналитика: он раскладывает промт на 10 чётких блоков, которые добавляются итерациями, или «слоями», и автоматически устраняют типичные ошибки — размытые формулировки, «галлюцинации» и несогласованность. Час на настройку шаблона экономит 6–7 часов в первом же спринте и до 78 000 рублей на блоке из 12 похожих задач.

Введение: почему эта статья важна

ИИ‑ассистенты уже умеют помогать в аналитических задачах, но «из коробки» они отвечают обтекаемо: теряют роли, смешивают контексты, выдают лишние допущения. Для системных и бизнес‑аналитиков, работающих со сложными процессами, такое «творчество» оборачивается десятками доработок и риском пропустить критичные детали.
  1. Сложный домен требует точности. Ошибка в формулировке превращается в потенциальный дефект. Нужен промт, который заранее удерживает рамки.
  2. Большинство готовых фреймворков англоязычны. Акронимы вроде PROMPT или FEARS звучат умно, но плохо ложатся в русскоязычную практику и забываются через пару дней.
  3. Промт можно улучшать итерациями. Часто мы бросаемся писать идеальный запрос целиком, а потом переделываем. Гораздо продуктивнее начать с ядра и постепенно наращивать детали, проверяя, как ИИ корректирует ответ.
Именно поэтому мы предлагаем фреймворк «КОМПОЗИТОР» — русскоязычную мнемонику, которая:
  • делит промт на логически завершённые блоки («Кто ты», «Обстановка», «Миссия» и т.д.),
  • усиливает результат пошагово: сначала ядро «К-О-М» (промт «Кто ты — Обстановка — Миссия»), затем уточняющие слои в середине промта «П‑О‑З‑И» (промт «Позитивный пример — Отрицательный пример — Зона работы — Инспекция»), потом финальный аккорд «Т-О-Р» (промт «Тон — Окружение — Результат»).
  • позволяет быстро адаптировать один и тот же шаблон под разные типы артефактов — от user story до BPMN‑процесса.
В этой статье мы расскажем, как пройти путь от первого «сырого» запроса («первый блин — комом») до выверенного промта, который минимизирует итерации, делает ответы ИИ предсказуемыми и фиксирует нужный формат выдачи. Всё это — через визуализации: блины, робот‑повар в космосе, удар молота Тора и, конечно, реальный кейс из практики аналитиков — про заявку от клиента на возврат заказа.

Глоссарий

Термины, связанные с ИИ
Термины, связанные с кейсом системного анализа

Глава 1. Что скрывается за буквами «КОМПОЗИТОР»

«КОМПОЗИТОР» — это не только человек с партитурой, но и мнемоника, которая помогает системным и бизнес‑аналитикам «сочинять» точные промты. Каждая буква отвечает за один логический блок запроса. В совокупности они задают три уровня управления ответом ИИ: ядро, тон и контроль качества.
1.1. Ядро: «К-О-М» — основа, без которой ничего не сыграет
Методичка

Начинайте любой запрос с «К-О-М». Представьте, что вы хотите быстро уговорить друга посмотреть с вами фильм и рассказываете только суть: герой, ситуация, цель. Всё остальное — детализация.
1.2. Фокусировка: «-П-О-» — примеры, которые направляют
Два коротких примера экономят абзацы инструкций. Главное — выбрать ошибку, способную испортить результат (например, бесконечный цикл в BPMN).
1.3. Безопасная сцена: «-З-И-» — охрана периметра
1.4. Финальный аккорд: «-Т-О-Р» — ставим точку громко
1.5. Как запомнить порядок
  1. К‑О‑М — как «первый блин комом»: стартуем с роли, контекста и цели.
  2. П‑О — «Покажи‑Ошибись»: хороший и плохой варианты.
  3. З‑И — «Зона работы — Инспекция»: ограничиваем и проверяем.
  4. Т-О-Р— удар молота: закрепляем стиль, адресата и формат.
Через эту последовательность промт растёт «слоями». Вы можете остановиться на «К-О-М», получить быстрый черновик, а затем наращивать детали до полноформатного «КОМПОЗИТОР» — ровно столько, сколько требует задача. В следующих главах мы увидим, как это работает на практике: сначала попробуем «комом», а потом будем улучшать промт, добавляя каждый новый слой и наблюдая, как ИИ эволюционирует от «сырого теста» к «готовому продукту».

Глава 2. Начинаем с промта «Кто ты? — Обстановка — Миссия»: «первый блин — КОМом»

2.1 Три блина — три «К-О-М»-сцены
Метафора

Для того чтобы проверить рецепт, достаточно трёх блинчиков. Точно так же для отработки структуры промта нам нужны три короткие сцены — разный Кто, разная Обстановка, одна Миссия.
Вывод: даже без дополнительных блоков промта одно только «КОМ» радикально меняет советы ChatGPT — потому что меняются роль и контекст.
2.2 Перенос на анализ: промт «Кто ты — Обстановка — Миссия» для BA/SA‑кейса
Мы возьмём типовую совместную задачу бизнес‑ и системного аналитика — формулировку use case «Оформление возврата товара».
Промт «Кто ты — Обстановка — Миссия»

Кто ты? Ты — системный и бизнес‑аналитик в одной роли, отвечающий за описание процессов e‑commerce.
Обстановка: Стартовая discovery‑фаза проекта «Возврат товара»; есть стенограммы пользовательских интервью, диаграмма классов, диаграмма состояний возврата, SLA‑таблица.
Миссия: Составь первоначальный юскейс «Оформление возврата» по шаблону Кокберна, без диаграмм, только текст.
Ответ ИИ

Юскейс: Оформление возврата
Primary Actor: Клиент
Scope: E‑commerce система …

Основной сценарий:
1. Клиент инициирует запрос возврата…
2. Система запрашивает номер заказа…
3. …

Расширения:
1a. Клиент не помнит номер заказа … система предлагает поиск по email
3a. Срок возврата истёк … система уведомляет об отказе
Типичные проблемы, если использовать только промт «Кто ты — Обстановка — Миссия»:
  • Слишком общий стиль: нет ссылок на реальные SLA, статусы или роли службы поддержки.
  • Игнорирует ограничения (например, существующий API OMS).
  • Нет формата вывода: Markdown‑список придётся вручную переносить в Confluence‑шаблон.
  • Отсутствуют критерии проверки — ИИ «полагается на слово».
2.3 Плюсы и минусы промта «К-О-М»
Итого: «К-О-М» (промт «Кто ты — Обстановка — Миссия») — быстрый способ получить черновик, но без дальнейших слоёв фреймворка «КОМПОЗИТОР» ответ останется тем самым «первым блином». В следующей главе мы «ударим молотом Тора» — добавим промт Т-О-Р («Тон — Окружение — Результат») и посмотрим, как сразу исчезнет половина проблем.

Глава 3. Завершаем промтом «Т-О-Р» («Тон — Окружение — Результат»): как положить «молот Тора» на стол

Мы вынесли эту часть промта сразу после начала, так как можно использовать только две части фреймворка:
  • начало — «К-О-М» (промт «Кто ты — Обстановка — Миссия»)
  • конец — Т-О-Р («Тон — Окружение — Результат»)
И результат уже может быть завершённым. Но для сложных промтов понадобятся детали из «середины» фреймворка — о них расскажем в следующей главе.
Образ

Молот Мьёльнир громко бьёт по наковальне — хаос превращается в форму.

В промте: слой Т-О-Р («Тон — Окружение — Результат») задаёт тон ответа, адресата и формат, превращая черновик «К-О-М» в готовый артефакт, который можно сразу вставить в Confluence или Jira.
3.1 Расшифровка «Т-О-Р»
3.2 Апгрейд BA/SA‑промта: добавляем «Т-О-Р»
Промт «Кто ты — Обстановка — Миссия» + «Тон — Окружение — Результат»

Кто ты? Ты — системный и бизнес‑аналитик в одной роли, отвечающий за описание процессов e‑commerce.
Обстановка: Стартовая discovery‑фаза проекта «Возврат товара»; есть стенограммы пользовательских интервью, диаграмма классов, диаграмма состояний возврата, SLA‑таблица.
Миссия: Составь первоначальный юскейс «Оформление возврата» по шаблону Кокберна, без диаграмм, только текст.

Тон: деловой, лаконичный, каждое действие с новой строки.
Окружение: читатели — продукт‑оунер и команда разработки.
Результат: выведи результат в таблицу с колонками: Шаг, Актор, Действие, ID альтернативного потока
Ответ ИИ (фрагмент)
3.3 Ответы ИИ до и после «удара молота»
3.4 Что изменилось — короткие выводы
  • Минус две итерации ревью. Роли и формат заданы сразу, продукт‑оунер вчитался без вопросов.
  • Ноль ручного форматирования. Таблица Confluence вставляется «как есть».
  • Уменьшение когнитивной нагрузки. Тон единообразен, не нужно причесывать стиль под гайдлайн.
Ключевая мысль: слой Т-О-Р («Тон — Окружение — Результат») — это не «косметика», а механика доставки ценности. Он фокусирует ответ под конкретных читателей и избавляет вас от ручных правок.

В следующей главе мы подключим П‑О‑З‑И (промт «Позитивный пример — Отрицательный пример — Зона работы — Инспекция»), чтобы ассистент учился на примерах, соблюдал границы задачи и сам проверял качество результата.

Глава 4.Нарастающее улучшение: подключаем «П‑О‑З‑И» (промт «Позитивный пример — Отрицательный пример — Зона работы — Инспекция»)

Задача главы

Показать, как поочерёдное добавление четырёх новых блоков превращает «хороший» промт уровня К-О-М + Т-О-Р (промты «Кто ты — Обстановка — Миссия» + «Тон — Окружение — Результат») в «безошибочный» промт уровня КОМПОЗИТОР.
Посмотрим на фрагмент ответа ИИ, который он дал на предыдущем шаге:
Что заметили
  • Шаг 2 оформлен чётко — будущий позитивный пример.
  • Далее идёт общий текст: «Система проверяет, если всё ок— возврат…» — это идеальный негативный пример.
4.1 Шаг 1 — добавляем Позитив и Отрицание
Что делаем

Добавляем фрагмент ответа, который максимально похож на желаемый результат, и антипример, на который не стоит ориентироваться
Добавляем «Позитивный пример» и «Отрицательный пример»

Позитивный пример идеального шага основного сценария:
«Система проверяет право на возврат, сверяя дату заказа и статус "Delivered" в OMS (не более 14 дней)».

Отрицательный пример — «Система проверяет, если всё ок — возврат, иначе — отказ». Избегай размытых формулировок.
Новый ответ ИИ (фрагмент)
Выявленные проблемы
  • Появился несуществующий статус «Picked‑Up»
  • Создан Service Desk‑тикет — в исходных данных такого сервиса нет.
→ нужен блок, который ограничит воображение модели.
4.2 Шаг 2 — вводим Зону работы
Решаем проблему предыдущего этапа

Добавляем рамки, в которых модель должна генерировать ответ, для того чтобы ограничить её воображение.
Добавляем «З» — «Зону работы»

Зона работы: используй только факты из интервью и источников: UML‑классы ReturnRequest, Payment, Customer, диаграмма состояний возврата, SLA‑таблица. Запрещено придумывать новые статусы и связи. Если требуемых данных не хватает — укажи TODO со ссылкой на отсутствующий объект.
Новый ответ ИИ (фрагмент)
Новая проблема
  • Возникла петля: шаг 5 отправляет процесс назад к шагу 2 без шлюза — классическая логическая ошибка.
  • → добавляем блок самопроверки.
4.3 Шаг 3 — включаем Инспекцию
Решаем проблему предыдущего этапа

Добавляем чек-лист, по которому система должна сама себя проверить перед выводом ответа пользователю.
Добавляем «И» — «Инспекцию»

Инспекция. Перед финальным ответом проверь:
  • Все шаги нумеруются по порядку без петель.
  • Каждый Alt Flow ссылается на существующий шаг.
  • У каждого шага есть Actor и System Action.
Если условие не выполнено — исправь ответ, затем выведи.
Финальный ответ ИИ (фрагмент)
4.4 Итого: эволюция промта
Главный результат: всего три коротких улучшения в середине промта  —  и мы перешли от «приемлемого» черновика к «готовому» артефакту, который можно сразу вложить в Confluence без дополнительного ревью.

Глава 5. Многоразовый промт: один шаблон

5.1 Шаблон, который не меняется
После шага 4 у нас появился промт фреймворка КОМПОЗИТОР. Он уже содержит:
  • роль, контекст и миссию;
  • позитивный и отрицательный примеры;
  • жёсткие границы данных (интервью + журнал событий за 6 месяцев);
  • чек‑лист самопроверки, тон, целевую аудиторию и формат вывода.
Теперь этот шаблон можно использовать для создания остальных юскейсов на проекте с теми же исходными данными (интервью + журнал событий за 6 месяцев)
Промт по фреймворку КОМПОЗИТОР

Кто ты? Ты — системный и бизнес‑аналитик в одной роли, отвечающий за описание процессов e‑commerce.
Обстановка: Стартовая discovery‑фаза проекта «Возврат товара»; есть стенограммы пользовательских интервью, диаграмма классов, диаграмма состояний возврата, SLA‑таблица.
Миссия: Составь юскейс «Оформление возврата» по шаблону Кокберна, без диаграмм, только текст.

Позитивный пример идеального шага основного сценария:
«Система проверяет право на возврат, сверяя дату заказа и статус "Delivered" в OMS (не более 14 дней)».
Отрицательный пример — «Система проверяет, если всё ок — возврат, иначе — отказ». Избегай размытых формулировок.
Зона работы: используй только факты из интервью и источников: UML‑классы ReturnRequest, Payment, Customer, диаграмма состояний возврата, SLA‑таблица. Запрещено придумывать новые статусы и связи. Если требуемых данных не хватает — укажи TODO со ссылкой на отсутствующий объект. Допустимые статусы доставки: «Delivered», «Returned».
Инспекция. Перед финальным ответом проверь:
  • Все шаги нумеруются по порядку без петель.
  • Каждый Alt Flow ссылается на существующий шаг.
  • У каждого шага есть Actor и System Action.
Если условие не выполнено — исправь ответ, затем выведи.

Тон: деловой, лаконичный, каждое действие с новой строки.
Окружение: читатели — продукт‑оунер и команда разработки.
Результат: выведи результат в таблицу с колонками: Шаг, Актор, Действие, ID альтернативного потока
Единственное, что меняем от задачи к задаче — строку М (Миссия). Всё остальное остаётся неизменным.
5.2 Пример 1.Юскейс «Инициировать возврат»
М (миссия): «Составь юскейс „Инициировать возврат“ по шаблону Кокберна».
Ответ ИИ (фрагмент)
Результат: Вся нумерация ровная, ни одного придуманного статуса.
5.3 Пример 2. Юскейс «Получить ярлык возврата»
М (миссия): «Составь юскейс „Получить ярлык возврата“ по шаблону Кокберна».
Ответ ИИ (фрагмент)
Результат: ни одной «галлюцинации»: сервисы и эндпоинты совпадают с журналами вызовов.
5.4 Пример 3. Юскейс «Отказать в возврате»
М (миссия): «Составь юскейс „Отказать в возврате“ по шаблону Кокберна».
Ответ ИИ (фрагмент)
Результат: Снова без пропусков и петель — чек‑лист «Инспекции» удерживает логику.
5.5 Что даёт многоразовый промт
5.6 Вывод главы
  • Один тщательно собранный промт масштабируется на любые под‑задачи внутри проекта «Возврат v2».
  • Качество держится без ручного микроменеджмента: примеры, зона и инспекция автоматически «выправляют» ответ.
  • Скорость растёт линейно: чем больше юскейсов, тем выше экономия. На десятке похожих требований мы выигрываем рабочий день аналитика каждую неделю.
Таким образом, потраченный час на сборку полного КОМПОЗИТОР‑промта окупается после первых же трёх‑четырёх юскейсов и остаётся полезным на всём протяжении discovery‑фазы.

Глава 6. Экономика внедрения:
«КОМПОЗИТОР» vs ручная работа без ИИ

В предыдущих главах мы сравнивали разные уровни промтов. Здесь рассмотрим самый привычный для команд сценарий — документы пишутся целиком вручную, ИИ вообще не используется. Именно с такой «нулевой» базы и имеет смысл считать выгоду от шаблона «КОМПОЗИТОР».
6.1 Метрики, на которые смотрим
6.2 До и после внедрения фреймворка «КОМПОЗИТОР»
(в рублях и часах)
Экономия в часах:
2,5 ч → 0,33 ч (20 мин)
  • 2,5 ч — усреднённый опыт команд: 1,5 ч пишет аналитик, ещё час уходит на комментарии и правки.
  • 0,33 ч (20 мин) — фактическое время, чтобы подставить одну новую строку «Миссия» в готовый шаблон, запустить ИИ и просмотреть таблицу.
Экономия в деньгах
Для оценки возьмём среднюю ставку аналитика и тим-лида, который проверяет работу — 3 000 руб./ч

Экономия на одном юскейсе:
(2,5 − 0,33) ч × 3 000 руб./ч ≈ 6 500 руб.

Если в discovery‑фазе «Возврат v2» мы оформили 12 юскейсов:
6 500 руб. × 12  = 78 000 руб. чистой экономии только на писательском труде, не считая снижения количества багов.
6.3 Как внедрять ИИ с фреймворком «КОМПОЗИТОР» в процесс
  1. Выберите пилот. Подойдёт блок задач, где паттерны повторяются. Такое место в бэклоге часто называют «фича‑банк» — список будущих функций (features), из которого команда регулярно «достаёт» работу.
  2. Зафиксируйте шаблон. Создайте страницу с промтом, созданным по фреймворку КОМПОЗИТОР. Единственное поле, которое меняет аналитик — Миссия.
  3. Автоматизируйте чек‑лист с «Инспекцией».
  • Сохраните ответы ИИ в .md‑файлах репозитория.
  • Добавьте git pre‑commit‑скрипт (например, на Python), который:
  • проверяет, что таблица содержит нужные колонки
  • убеждается, что нумерация шагов 1, 2, 3... без пропусков;
  • если есть петли или пропущенные колонки — отклоняет commit, и pull‑request не попадёт в review.
  • Такое правило держит качество даже тогда, когда шаблоном пользуются разные люди.
4. Проведите 30‑минутный мастер‑класс. Дайте три примера миссий (например, инициировать возврат, получить ярлык, отказать в возврате). Пусть участники вставят их в шаблон и увидят одинаково чистый результат.
5. Проверьте эффекты через спринт. Сравните фактический Lead Time и число ревью‑кругов с данными из § 6.1. Если время не упало минимум на 50 % — посмотрите, не забыт ли в промте блок «З» (Зона работы) или «И» (Инспекция). Именно их отсутствие чаще всего даёт скачок ошибок.
6.4 Когда внедрение шаблона не окупится
  • Уникальная одноразовая задача. Экономия повторяемости отсутствует.
  • Новый домен без данных. Если нет ни расшифровок интервью с заказчиками, ни созданных артефактов, то нечего положить в «Зону работы», и ИИ будет фантазировать.
  • Среда без wiki или git. Вы теряете бонусы от блока «Результат» (формат) и проверки pre‑commit.
Или можно прибегнуть к простому правилу: есть минимум три схожие задачи — шаблон окупится.
6.5 Главные выводы
  • Фреймворк «КОМПОЗИТОР» — это управляемое сокращение затрат: время падает в 5‑7 раз, деньги — на десятки тысяч рублей уже в первом спринте.
  • Экономия достигается не «магией ИИ», а системной рамкой: примеры, зона, инспекция.
  • Чем больше повторяющихся юскейсов, тем сильнее кумулятивный эффект: один раз собрали — дальше лишь подставляете новую миссию.

Заключение

ИИ‑ассистент может быть либо бесполезным собеседником, либо настоящим коллегой — всё решает промт.

Фреймворк «КОМПОЗИТОР» переводит работу чат-ботом из импровизации в технологию:
  1. К-О-М (промт «Кто ты — Обстановка — Миссия»)даёт прочный каркас роли, контекста и цели.
  2. П‑О‑З‑И (промт «Позитивный пример — Отрицательный пример — Зона работы — Инспекция») вводят обучение на примерах, защиту от «галлюцинаций» и самопроверку.
  3. Т-О-Р («Тон — Окружение — Результат») фиксирует стиль, адресата и формат, превращая черновик в готовый артефакт.

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

Приложение A. Фреймворк «КОМПОЗИТОР» для копирования

Инструкция: скопируйте и заменяйте только содержимое после двоеточий.
  • Если задача маленькая — оставьте «К-О-М».
  • Если нужна точность — добавляйте блоки по порядку до полного фреймворка «КОМПОЗИТОР», основываясь на ответах ИИ
  • Если важен формат вывода, но допустима креативность — используйте «К-О-М» + «Т-О-Р»
Промт по фреймворку КОМПОЗИТОР

Кто ты? Ты — … (роль ИИ или человека).
Обстановка: … (контекст, история, фаза проекта).
Миссия: … (чёткая цель/артефакт, например: «Составь юскейс ...»).

Позитивный пример: "…"(пример идеального фрагмента).
Отрицательный пример: "…"(пример плохого фрагмента).

Зона работы: Используй только … (источники, допускаемые данные). Не придумывай … Если требуемых данных нет, укажи TODO со ссылкой на объект.
Инспекция: Перед ответом проверь:
  • [ ] … (чек‑лист нумерации, ссылок, петель).
Если условие не выполнено — исправь ответ, затем выведи.

Тон: … (тон: деловой, дружелюбный, gdb и т.д.).
Окружение: … (для кого пишем: разработчики, CEO).
Результат: Выведи результат в … (таблица Confluence, JSON, PlantUML и пр.).

Приложение Б. Фреймворк «КОМПОЗИТОР» для запоминания

  • Инструкция: Распечатайте таблицу или добавьте на видное место на экране — одного взгляда хватит, чтобы вспомнить порядок блоков и видеть сквозной пример.

Об авторе

■ Другие статьи по теме Архитектура

Автор: Денис Бесков
■ Статья. Контекстная диаграмма
Автор: Дилара Валитова
■ Статья. Основы применения UML. Кто и как его использует
Автор: Михаил Максимов
■ Статья. Чем полезен ArchiMate аналитику?
Автор: Юрий Куприянов
■ Статья. Скрытая работа аналитика по проектированию систем
Автор: Анна Вичугова
■ Статья. Что такое архитектура информационных систем и как её проектировать
Автор: Дмитрий Пахомов
■ Статья. Проектирование эффективной системы кэширования
Автор: Дмитрий Голых
■ Статья. Микросервисная архитектура
[Перевод] Лав Шарма, Алекс Сюй
■ Статья. The Architect's Blueprint: 10 архитектурных стилей программного обеспечения и их паттерны
Автор: Влад Хононов
■ [Перевод книги] Влад Хононов. Что такое предметно-ориентированное проектирование?
Автор: Мартин Клеппман
■ [Перевод книги] Мартин Клеппман. Проектирование высоконагруженных приложений. Избранные главы
Автор: Марк Ричардс Перевод под редакцией Дмитрия Дудкина
■ [Перевод книги] Паттерны архитектуры программного обеспечения. Марк Ричардс
Автор: Иэн Гортон
■ [Перевод книги] Иэн Гортон. Основы масштабируемых систем. Избранные главы
Авторы: Гай Харрисон, Эндрю Маршал, Чарльз Кастер
■ [Перевод книги] Архитектура распределённых транзакционных приложений. Гай Харрисон, Эндрю Маршал, Чарльз Кастер
Показать еще

■ Другие статьи по теме Интеграция

Автоматический перевод Google под редакцией Артема Стукалова и Дениса Бескова
■ [Перевод книги] Введение в API. Мини-курс и книга Брайана Кукси
Автор: Анна Вичугова
■ Статья. Технологии интеграции: Общая БД, Файловый обмен, SOAP/REST
Автор: Анна Вичугова
■ Статья. Технологии интеграции: GraphQL, gRPC, WebSocket, webhook, брокеры
Автор: Елена Бенкен
■ Статья. REST API и Postman
Автор: Елена Бенкен
■ Статья. Применение SOAP при интеграции систем
Автор: Андрей Бураков
■ Статья. REST, что же ты такое?
Автор: Геннадий Круглов
■ Статья. Доменно-ориентированный подход к интеграции
Автор: Зоя Степчева
■ Статья. Что такое rabbitMQ? Топология, объекты и атрибуты
Редакторы: Валерий Зубаиров, Денис Бесков Вёрстка: Софья Должанская
■ Книга. Введение в Apache Kafka для системных аналитиков и проектировщиков интеграций
Показать еще

■ Другие статьи на тему Базы данных

Автор: Александр Чернов
■ Статья. Как построить модель данных и модель систем на основе анализа компонентной модели предприятия
Автор: Марина Зенкова
■ Статья. Технология проектирования хранилищ данных Data Vault 2.0
Автор: Дарья Колесова
■ Статья. Стриминговые фреймворки: Apache Flink
Автор: Марина Зенкова
■ Статья. Хранилища данных. Обзор технологий и подходов к проектированию
Авторы: Александр Кротов, Наталья Носенко
■ Статья. Как получить информацию о структуре БД для документации
Автор: Дарья Колесова
■ Статья. Как выбрать СУБД для работы с большими данными?
Автор: Адександр Кротов, Наталья Носенко
■ Статья. Универсальные структуры в реляционных базах данных
Автор: Анна Крх
■ Статья. Приемы масштабирования баз данных и повышения производительности систем
Автор: Алекс Сюй
■ Статья. Разбираемся в типах баз данных
Автор: Джо Рис, Мэтт Хоусли. Перевод в редакции Софьи Должанской
■ [Перевод книги] Джо Рис, Мэтт Хоусли. Основы инженерии данных
Авторы: Манос Атанасулис, Стратос Идреос и Деннис Шаша
■ [Перевод книги] М. Атанасулис, С. Идреос, Д. Шаша. Структуры данных для высоконагруженных приложений
Показать еще

■ Другие статьи на тему User Stories и Use Cases

Автор: Анна Абрамова
■ Статья. Use Cases. Что это такое и зачем они нужны?
Авторы: Анна Вичугова, Анна Гасраталиева
■ Статья. Алгоритм описания функциональных требований к системе в формате Use Case
Автор: Татьяна Арсланова
■ Статья. Как разработать критерии приёмки для User Story
Авторы: Анна Вичугова, Анна Гасраталиева
■ Статья. DoR, DoD, AC: критерии готовности и критерии приёмки

■ Другие статьи на тему Требований

Автор: Пол Ральф (перевод)
■ [Перевод Статья]. Иллюзия требований при разработке программного обеспечения
Автор: Денис Богданов, Михаил Максимов
■ Статья. Постановка задачи на реализацию: зачем и как
Автор: Евгений Галактионов
■ Статья. Отчёты как источник функциональных требований и проектных решений
Автор: Денис Бесков
■ Статья. Как задавать требования к ВНЕШНЕМУ качеству ПО в цифрах?
Автор: Юрий Куприянов
■ Статья. Требования не меняются, это мы их недовыявили
Автор: Юрий Куприянов
■ Статья. Стоп-слова как маркер проблем в требованиях
Автор: Алексей Краснов
■ Статья. Требования к информационной безопасности: кого вовлекать в выявление?
Автор: Василий Баракин
■ Статья. Как разработать ТЗ по ГОСТ
Русский перевод под редактурой Анны Гасраталиевой и Дениса Бескова
■ [Перевод книги] Руководство по разработке и управлению требованиями при создании авиационных бортовых встраиваемых систем реального времени
Показать еще

■ Другие статьи на тему Бизнес-анализ

Автор: Борис Романов
■ Статья. Роль аналитика в разработке сложных информационных систем
Автор: Алина Богачёва
■ Статья. ЛЮСТРА: Методика разработки бизнес-требований в проекте по автоматизации бизнес-процессов
Автор: Анна Вичугова
■ Статья. Использование DFD: как описать движение данных в бизнес-процессах
Автор: Георгий Савельев
■ Статья. Бизнес-требования. Назначение и форма
Автор: Георгий Савельев
■ Статья. Как разработать бизнес-требования?
Автор: Анна Вичугова
■ Статья. Как начать моделировать бизнес-процессы в BPMN
Автор: Фёдор Литовко
■ Статья. Один пример и три нотации: сравниваем BPMN, EPC и DMN
Автор: Денис Бесков
■ Статья. Недостатки классического подхода к бизнес-анализу и проектированию информационных систем
Показать еще

■ Другие статьи на тему Профессия и трудоустройство

Автор: Денис Бесков
■ Руководство для начинающего системного аналитика
Автор: Борис Романов
■ Статья. Роль аналитика в разработке сложных информационных систем
Автор: Денис Бесков
■ Статья. Кто такой системный аналитик? Профессия, требования, зарплата
Автор: Денис Бесков
■ Статья. Как стать системным аналитиком? 4 способа входа в профессию
Автор: Денис Бесков
■ Статья. Как ИТ-аналитику написать хорошее резюме: 11 рекомендаций
Автор: Анна Вичугова
■ Статья. Кто такой бизнес-аналитик и как им стать?
Автор: Михаил Максимов
■ Статья. Как стать архитектором в ИТ, если ты аналитик?
Автор: Алексей Журавлёв
■ Статья. Как вести себя на собеседовании, чтобы получить хороший оффер?
Наталья Подкина
■ Отзывы выпускников. Как стать бизнес-аналитиком
Автор: Мария Щекочихина
■ Статья. Как аналитику быстро освоиться на новом проекте
Автор: Денис Бесков
■ Статья. Remote Analyst. Первые шаги и частые вопросы
Автор: Денис Бесков
■ Статья. Как выполнить тестовое задание на вакансию ИТ-аналитика
Глоссарий Системного аналитика информационных систем для бизнеса
Показать еще

■ Другие статьи на тему Проектное управление

Автор: Александр Турханов
■ Статья. Как понятие проекта раздулось до полной потери смысла и что с этим делать. Часть 3
Автор: Александр Турханов
■ Статья. Как понятие проекта раздулось до полной потери смысла и что с этим делать. Часть 2
Автор: Александр Турханов
■ Статья. Как понятие проекта раздулось до полной потери смысла и что с этим делать. Часть 1
Автор: Александр Кварцхава
■ Статья. Внедрение ERP-систем. Цели и проблемы внедрения

■ Другие статьи на тему Менеджмент и архитектура предприятия

Автор: Александр Кварцхава
■ Статья. Данные как основа цифрового менеджмента
Автор: Александр Чернов
■ Статья. Как построить модель данных и модель систем на основе анализа компонентной модели предприятия
Статья на основе вебинара Сергея Нужненко
■ Статья. Тренды IT-сферы: Agile и культура инноваций
Автор: Александр Чернов
■ Статья. Применение архитектурного подхода в информатизации
Автор: Александр Кварцхава
■ Статья. Проблемы управления бизнес-архитектурой компании
Автор: Александр Чернов
■ Статья. Тренды в ИТ-сфере. Информатизация и цифровизация
Автор: Александр Кварцхава
■ Статья. Как грамотно построить стратегический менеджмент
Автор: Александр Кварцхава
■ Статья. Стратегический менеджмент и проблемы, с ним связанные
Автор: Александр Кварцхава
■ Статья. В стране слепых и зрячий будет полубогом. О важности стратегического менеджмента
Показать еще

■ Другие статьи на тему Дизайн интерфейсов и исследования

Автор: Алексей Копылов
■ Статья. Как оценить качество интерфейса?
Автор: Алексей Копылов
■ Статья. Плохой дизайн и к чему он приводит
Автор: Алексей Копылов
■ Статья. Введение в пользовательские интерфейсы