Сбор требований — фундамент, на котором держится весь проект. Неверный сбор требований может стоить проекту много денег и времени.

Вот подход, который спасает от бесконечных правок и «я не это имел в виду».

Шаг 0: Подготовка и погружение (Самое важное!)

Прежде чем задать первый вопрос:

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

2. Найди всех, кто «в теме».
Ключевые стейкхолдеры (заинтересованные лица): бизнес-заказчик, будущие пользователи, технические специалисты, поддержка, юристы. У каждого — своя правда.

3. Выучи язык бизнеса.
Говори с финансистами о KPI и ROI, с поддержкой — о нагрузке, с пользователем — о простоте.

Какие бывают требования?

1. Бизнес-требования (Зачем?) — Цели верхнего уровня.
Пример: «Увеличить долю повторных продаж на 15% в следующем квартале».

2. Пользовательские требования (Что?) — Что должны делать пользователи в системе.
Пример: «Возможность оформить возврат товара в личном кабинете за 3 клика».

3. Функциональные требования (Как?) — Конкретные функции системы.
Пример: «Система должна отправлять email-подтверждение при создании возврата».

4. Нефункциональные требования (Каким образом?) — Свойства системы: скорость, безопасность, надёжность.
Пример: «95% страниц кабинета должны загружаться менее чем за 2 секунды при 1000 одновременных пользователей». Часто про них забывают, а потом система «падает».

Как собирать? Инструментарий аналитика

Нет одного волшебного метода. Использую комбинацию:

- Интервью (основа) — Готовь вопросы заранее, но будь готов/а уйти вглубь. Спрашивай «почему?» до тех пор, пока не докопаешься до истинной потребности.

- Воркшопы (мозговые штурмы) — Когда нужно собрать разных людей и быстро набросать процессы или идеи. Идеально использовать доску (Miro, Mural и др).

- Анализ существующих данных и документов — Что уже есть? Старые системы, отчёты в Excel, письма поддержки, документация — кладезь информации.

📝 Правила фиксации: чтобы поняли все и не было двоякого толкования

- Пиши просто и однозначно. Не «Система должна быстро работать», а «Операция поиска клиента по номеру телефона должна выполняться ≤ 1 секунды».

- Используй стандартные шаблоны (User Stories, Use Cases, диаграммы процессов BPMN). Это как общий язык для команды.

Плохие сигналы (того, что всё пошло не так)

- «Это и так очевидно» (ничего не очевидно).

- Заказчик говорит только в абстракциях («дружелюбный интерфейс») и не может привести пример.

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

- Техническая команда не задаёт уточняющих вопросов (значит, они что-то додумывают сами).

Итог: Идеальных требований не бывает

Задача аналитика — не записать каждую мелочь под диктовку, а выявить истинные потребности, договориться о приоритетах и зафиксировать договорённости так, чтобы и бизнес, и разработка поняли друг друга.

Ваш успех — это не когда вы сдали «в точности как в ТЗ», а когда решили бизнес-задачу и пользователи стали работать эффективнее.

Роскошный архитектурный минимум для аналитика: понимать систему в целом и не бояться «богов»-архитекторов

Сложность: ★★☆ | Время чтения: 11 мин

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

🔗 Читать статью

Чек-лист: 30 API-терминов, которые спрашивают на собеседовании на позицию системного аналитика

1. API (Application Programming Interface)
2. REST API (Representational State Transfer)
3. HTTP-методы запросов
4. Эндпоинты
5. Коды ответов
6. Ограничение частоты запросов (Rate Limiting)
7. Полезная нагрузка (Payload)
8. Заголовки (Headers)
9. Аутентификация
10. Авторизация
11. Пагинация
12. Кэширование
13. OAuth
14. JWT Token
15. API Gateway
16. API Keys
17. Basic Authentication
18. Bearer Tokens
19. CORS
20. Webhooks
21. OpenAPI
22. API Versioning (Версионирование API)
23. Content Negotiation
24. Query Parameters
25. Path Parameters
26. API Documentation
27. API Monitoring
28. Throttling
29. Circuit Breaker
30. Idempotency (Идемпотентность)

Сегодня у нас подборка материалов по сбору требований

- Определение требований: что это такое и как его применять?
- Требования к ПО на пальцах

- Бизнес-требования. Назначение
- Документ бизнес-требований: Что это такое и как его составить [+5 шаблонов]
- Сбор и формирование бизнес-требований для сайта интернет-магазина
- Бизнес-функциональные требования (БФТ): особенности работы и реализации

- Как писать функциональные требования
- Алгоритм описания функциональных требований к системе в формате Use Case

- Нефункциональные требования к программному обеспечению.

Недостатки микросервисной архитектуры

Микросервисная архитектура (MSA) — подход, когда система разбивается на небольшие независимые сервисы.
У MSA есть недостатки, которые важно учитывать при проектировании.

1️⃣ Сложность управления распределёнными транзакциями

В монолите транзакции управляются на уровне БД (ACID). В MSA данные распределены, и обеспечение согласованности требует сложных решений.

➡️ Пример:
заказ оформлен, платёж прошёл, но товар не списался — пользователь заплатил за несуществующий товар.

Практики:
🔹 Saga-паттерны: реализуют оркестрацию или хореографию транзакций с локальными шагами и компенсациями
🔹 Outbox-паттерн: позволяет гарантировать отправку событий в шину сообщений после успешной локальной транзакции

2️⃣ Задержки из-за сетевых вызовов

Межсервисные вызовы (HTTP, gRPC и тд) добавляют сетевые задержки, что может привести к ухудшению UX.

➡️ Пример:
открытие страницы профиля пользователя требует вызовов к 10 сервисам — итого 1+ секунда задержки.

Практики:
🔹Кеширование на уровне API Gateway или Edge Cache
🔹 Асинхронная обработка через сообщения и очереди

3️⃣ Оверхеды мониторинга и трассировки

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

➡️ Пример:
пользователь видит ошибку при оформлении заказа — неизвестно, виноват Cart, Orders или Payments.

Практики:
🔹 Distributed Tracing (Jaeger, Zipkin, OpenTelemetry)
🔹 Централизованные логи (ELK Stack, Loki)
🔹 Метрики и алерты (Prometheus + Grafana)

4️⃣ Сложность тестирования и развёртывания

Каждый сервис может иметь свою БД, конфигурацию и зависимости. Интеграционное тестирование всей системы требует поднятия множества сервисов.

➡️ Пример:
тест Cart Service требует запуска Users, Products и Discounts — иначе тесты падают.

Практики:
🔹Контракты (Contract Testing): Pact, Spring Cloud Contract
🔹 Mock-сервисы и виртуализация (WireMock, Hoverfly)
🔹 Изолированные сценарии на уровне эндпоинтов

5️⃣ Дублирование данных и согласованность

Каждый сервис хранит свою копию данных → возможны расхождения.

➡️ Пример:
пользователь обновил email, но в Order History отображается старый адрес.

Практики:
🔹Event Sourcing и CQRS: разделяют чтение и запись и обеспечивают последовательность событий
🔹 Change Data Capture (CDC): синхронизирует данные между БД через Kafka Connect или Debezium

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

Это ключевой момент на любом проекте. Еще до начала разработки нужно понять, что конкретно нам нужно разрабатывать и нужно ли вообще.

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

Сохраняйте, чтобы не потерять!

В сегодняшнем посте рассмотрим то, как происходит взаимодействие аналитика с разработкой.

Эту информацию всегда спрашивают на собеседовании и в целом она будет полезна и начинающим аналитикам

При взаимодействии с разработчиками важно:

1️⃣ Описать требования понятно и качественно

2️⃣Собраться с разработкой на обсуждение требований

3️⃣Получить от них обратную связь и внести правки, если возникли какие-то уточнения в процессе обсуждения

4️⃣В процессе разработки быть на связи, отвечать на уточняющие вопросы, если такие будут.

Важно уметь расположить команду к себе, чтобы к вам спокойно могли подходить с вопросами

Конкретно на собеседовании важно рассказать следующее:

1️⃣Сколько разработчиков в команде и каких

2️⃣Какие артефакты готовили для разработчиков

3️⃣В каком виде ставили задачи

4️⃣Как обсуждали и оценивали задачи с разработчиками

5️⃣Как контролировали выполнение и консультировали в процессе

6️⃣Как осуществляли приемку

Курсы по системной аналитике по цене двух чашек кофе — analystquick.tech

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

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

Для примера решил взять UML Sequence диаграмму, которая используется повсеместно.

Промпт был следующий: "Создай мне гайд на тему UML Sequence диаграммы с учетом того, что мои знания в UML на уровне новичка"

Ссылка на гайд от ИИ Analyst Quick по теме UML Sequence

Что касается курса, ИИ сделал курс, состоящий из трех модулей:

Модуль 1: Введение в мир UML и визуализации взаимодействий
1. Что такое UML и зачем он аналитику?
2. Sequence диаграмма: Суть и аналогии из жизни
3. Базовые элементы диаграммы: Акторы, Линии жизни, Сообщения
4. Инструменты для рисования: от простых до профессиональных

Модуль 2: Строим первый сценарий взаимодействия
1. Простой поток: Успешная авторизация пользователя
2. Ветвление логики: Операция с проверкой условий (Alt/Opt)
3. Циклы и повторения: Загрузка списка товаров с пагинацией
4. Асинхронное взаимодействие и таймауты

Модуль 3: Sequence диаграммы в контексте современного IT
1. Моделирование REST API вызова
2. Диаграмма для событийной архитектуры (Kafka-like)
3. Паттерн BFF (Backend For Frontend) на Sequence диаграмме
4. Взаимодействие с внешними системами и ошибки

Модуль 4: От диаграммы к требованиям и дизайну
1. Реверс-инжиниринг: Составление диаграммы по описанию бизнес-процесса
2. Sequence диаграмма как часть спецификации API
3. Выявление нефункциональных требований через диаграмму
4. Оптимизация дизайна системы на основе диаграммы
5. Итоговый проект: Диаграмма для микросервисного сценария

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

Хочется отметить, что аналогичные курсы по UML стоят от 5-6 тысяч рублей, а на analystquick.tech покупая подписку всего за 650 рублей вы получаете ВСЕ доступные материалы.

Пять советов, которые помогут не утонуть в документах и выжать из них максимум:

1. Составьте список источников заранее. До того, как открыть первый документ, определите, что именно вы ищете. Запросите у заказчика перечень материалов с кратким описанием каждого.

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

3. Фиксируйте выдержки и гипотезы. Заводите рабочий документ или таблицу, куда выписываете ключевые требования, термины, противоречия и вопросы. Это станет основой для дальнейшего обсуждения с экспертами.

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

5. Проверяйте актуальность. Смотрите на даты, версии, отметки о введении в действие. Если документ старый, отметьте его как «требующий валидации» и проверьте информацию у экспертов.

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

Spec Driven Development

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

Так родилась идея, что на вход нужно давать более конкретные описания, а после контролировать действия агента. В итоге пришли к флоу:

Описываем хотелки —> Проектируем —> Декомпозируем —> Реализуем

Что-то знакомое? Почти как с людьми, только с агентами. Назвали подход Spec Driven Development.
Пока это лишь общая концепция, а не что-то конкретное. Нет единой терминологии, общих правил, принятых практик.

Наиболее популярные инструменты:
• SpecKit — от гитхаба
• Kiro — от амазона
• OpenSpec — опенсорс

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

Про реализацию SDD в SpecKitl: часть 1, часть 2.

​​📑 Требования в Agile: полный гайд с работающими практиками

Автор- Сергей Прощаев, Tech Lead и руководитель направления Java | Kotlin разработки в FinTech:

"Сегодня хочу поговорить о теме, которая, казалось бы, лежит на поверхности, но именно в ней чаще всего тонут проекты и страдает разработка. О работе с требованиями. Точнее — о том, почему их нельзя «собрать» раз и навсегда и почему Agile‑требования ничем принципиально не отличаются от любых других, как бы их ни называли."

Читать статью

Умеет ли LLM работать с бизнес-процессами?

Интересные материалы на темы: автоматизация бизнес-процессов и генерация BPMN-диаграмм через ИИ.

📍Внедрение ИИ в бизнес: где он реально окупается и как автоматизировать бизнес-процессы Прикладная статья с систематизацией сценариев, где ИИ работает успешно и где не стоит спешить с его применением.

📍Сравнение LLM по навыку анализа бизнес-процессов Статья с результатами исследования, которое автор делал для того чтобы выбрать "лучшую" LLM для конкретной коммерческой платформы и в итоге решил опубликовать. Есть интересная сравнительная таблица разных инструментов.

📍Говорят ли LLM на языке BPMN? Оценка их возможностей моделирования процессов на основе качественных метрик Большая переводная статья с результатами исследования. В исследовании представлена систематическая оценка пяти инструментов на основе LLM, предназначенных для генерации моделей BPMN из текстовых описаний процессов. Читается сложно, написано в академическом стиле, но может быть интересно тем, кто в поиске инструмента для генерации диаграмм.

📍Пост в канале “Системный сдвиг”, где автор поделился промптом для генерации BPMN.

📍Подборка о работе с процессами Еще одна подборка об управлении процессами в этом канале, может быть полезна, если вам интересна эта тема.