Попробуйте изменить запрос или используйте термин из навигации.
01 / START
Что делать при получении задачи
Начинайте не с решения, а с контекста: какую проблему решаем, кто получает ценность, какие ограничения уже известны и как будет измеряться результат.
- Зафиксировать бизнес-цель.Понять проблему, ожидаемый эффект и критерии успеха.
- Собрать контекст.Документация, интервью, текущий процесс, ограничения.
- Смоделировать сценарии.Happy path, альтернативы, ошибки и исключения.
- Спроектировать поведение системы.Данные, интеграции, роли, правила и NFR.
- Согласовать требования.Разработка, QA, бизнес и владельцы смежных систем.
- Сопроводить реализацию.Change-анализ, ответы команде, приемка и актуализация.
«Что изменится для бизнеса или пользователя, если мы реализуем эту задачу?»
02 / OUTPUT
Артефакты системного анализа
Артефакт нужен не ради документа, а чтобы убрать неоднозначность между участниками проекта.
03 / REQUIREMENTS
Виды требований
Функциональные
Что система должна делать: сценарии, расчеты, валидация, CRUD, интеграции и бизнес-правила.
Нефункциональные
Как система должна работать: производительность, доступность, безопасность, масштабируемость, наблюдаемость.
Качественное требование
- однозначно и атомарно;
- связано с бизнес-целью;
- реализуемо и приоритизировано;
- имеет измеримые критерии приемки;
- не противоречит другим требованиям;
- учитывает ошибочные и альтернативные сценарии.
04 / CHANGE
Жизненный цикл требований и Change Management
- Baseline — зафиксируйте согласованную версию объема;
- Change request — отделяйте изменение от уточнения;
- Impact analysis — оцените UI, API, данные, процессы, тесты, сроки и миграции;
- Decision — фиксируйте автора, дату, причину и выбранный вариант;
- Communication — обновляйте связанные артефакты и заинтересованных участников.
05 / TRACE
Трассировка требований
Минимальная цепочка позволяет понять, зачем существует требование и как подтвердить его реализацию.
Требование без цели — кандидат на удаление. Требование без критерия проверки — источник споров на приемке.
06 / NFR
NFR catalog: что нельзя забыть
p95/p99 latency, throughput, payload
SLA/SLO, деградация, окна работ
рост нагрузки, горизонтальное масштабирование
retry, idempotency, recovery
auth, access, audit, secrets
retention, RPO/RTO, backup, deletion
logs, metrics, traces, alerts
keyboard, contrast, assistive tech
«Система должна работать быстро» — не NFR. «p95 ответа GET /orders ≤ 400 ms при 300 RPS» — проверяемое требование.
07 / PEOPLE
Стейкхолдеры
Определите, кто принимает решения, кто пользуется системой, кто реализует изменения и кто владеет зависимостями.
заказчик, product owner, руководство
конечные пользователи и администраторы
разработчики, QA, DevOps
архитекторы, DBA, security, владельцы интеграций
Используйте матрицу «влияние × интерес» и заранее определяйте формат коммуникации для каждой группы.
08 / EXPERIENCE
UX/UI принципы для аналитика
09 / DISCOVERY
Методы сбора информации
10 / DISCOVERY
Discovery, Impact Mapping и Story Mapping
До фиксации решения полезно разделить проблему, ожидаемый эффект и конкретную реализацию. Это снижает риск качественно описать ненужную функцию.
Если обсуждение сразу начинается с «сделаем кнопку / очередь / микросервис», вернитесь к цели, актору, текущему сценарию и измеримому результату.
11 / SCENARIO
Use Cases
Use Case полезен, когда важна последовательность взаимодействия и варианты поведения системы.
Пользователь оформляет заказ → система валидирует корзину → резервирует остатки → создаёт заказ → запускает оплату. Если остаток изменился, система возвращает конфликт и предлагает обновить корзину.
12 / STORY
User Stories
INVEST: Independent · Negotiable · Valuable · Estimable · Small · Testable.
When он подтверждает заказ
Then система создаёт заказ и показывает его номер
13 / ACCEPT
Acceptance Criteria и BDD
Критерии приемки описывают наблюдаемое поведение системы, а не способ реализации.
Given заказ находится в статусе awaiting_payment
And платежный метод доступен
When пользователь подтверждает оплату
Then платеж создается один раз
And заказ переходит в paid
And публикуется событие OrderPaid
- позитивный сценарий;
- альтернативы и ошибки;
- границы данных;
- повторный запрос / idempotency;
- права доступа;
- наблюдаемый результат и side effects.
14 / PROCESS
BPMN
- Task — единица работы;
- Event — начало, конец, таймер, сообщение;
- Gateway — ветвление и синхронизация;
- Sequence Flow — порядок выполнения;
- Pool / Lane — участники и ответственность.
15 / DMN
DMN и бизнес-правила
DMN удобно применять, когда результат определяется набором правил: тариф, лимит, eligibility, скидка, маршрут согласования.
| Сумма | Risk | Решение |
|---|---|---|
| < 100 000 | Low | Auto approve |
| ≥ 100 000 | Low | Manager review |
| Any | High | Security review |
BPMN отвечает на «какой процесс», DMN — «по какому правилу принято решение».
16 / MODEL
UML / C4: какую диаграмму выбрать
17 / ESTIMATE
Техники оценки задач
командная относительная оценка story points
быстрая грубая оценка XS → XL
группировка задач относительно друг друга
optimistic / likely / pessimistic
18 / CONTRACT
API как контракт
Для аналитика API — это формализованный контракт между потребителем и поставщиком данных.
200 OK
{
"id": 123,
"status": "paid"
}
19 / API DESIGN
Проектирование API: чеклист контракта
URI, идентификаторы, связи
methods, commands, side effects
required, nullable, formats, examples
stable code, message, details
pagination, filter, sort
compatibility, deprecation, versioning
auth, scopes, rate limits
request-id, correlation-id, tracing
Для операций с риском повторной доставки явно определите поведение повторного запроса и ключ идемпотентности.
20 / ACCESS
Authentication, Authorization, OAuth/OIDC
Authentication
Подтверждает, кто выполняет действие: session, token, MFA, federation.
- OIDC — identity layer поверх OAuth 2.0;
- access token — доступ к API;
- refresh token — обновление доступа;
- JWT — формат токена, а не протокол авторизации.
Authorization
Определяет, что разрешено.
- RBAC — доступ через роли;
- ABAC — правила по атрибутам;
- Scopes — границы полномочий токена;
- resource ownership — доступ к конкретным объектам.
21 / REST
REST
REST опирается на ресурсы, единообразный интерфейс и отсутствие серверного состояния сессии между запросами.
22 / SOAP
SOAP
SOAP использует XML-сообщения и формальный контракт WSDL. Чаще встречается в enterprise-интеграциях с требованиями к WS-* стандартам.
| Критерий | SOAP | REST |
|---|---|---|
| Контракт | WSDL | OpenAPI / договоренность |
| Формат | XML | JSON, XML и др. |
| Transport | HTTP, SMTP и др. | обычно HTTP |
| Enterprise security | WS-Security | TLS + OAuth/JWT |
23 / GRAPH
GraphQL
Клиент описывает требуемую структуру ответа. Схема строго типизирована и служит контрактом.
user(id: "789") {
name
posts(limit: 5) { title }
}
}
24 / INTEGRATE
Паттерны интеграций
Сначала определите требования к latency, объему, гарантии доставки, порядку, повторной обработке и допустимой связности систем.
25 / EVENTS
Очереди, Kafka и Event-Driven
Что фиксировать в контракте
- event name и бизнес-смысл;
- schema + version;
- key / partitioning;
- producer / consumers;
- ordering requirements;
- retention.
Что происходит при ошибке
- delivery semantics;
- retry/backoff;
- dead-letter queue;
- duplicate handling;
- poison message;
- replay strategy.
eventId: 01J...
occurredAt: 2026-08-12T12:30:00Z
aggregateId: order-123
version: 2
payload: { ... }
26 / RELIABILITY
Reliability patterns
ограничивает ожидание зависимости
повторяет только временные ошибки
повтор не создает двойной эффект
прерывает лавину вызовов
согласует запись данных и публикацию события
координирует распределенную бизнес-транзакцию
изолирует необрабатываемые сообщения
находит и чинит расхождения постфактум
27 / CHANNELS
Webhooks, polling и файловый обмен
- Webhook: подпись/HMAC, timestamp, retry policy, idempotency, ответ 2xx;
- Polling: interval, cursor/watermark, rate limit, delta updates;
- File/SFTP: naming, encoding, schema, delimiter, checksum, atomic upload, archive;
- Batch: cut-off time, partial failure, reprocessing, reconciliation report.
28 / SERVICES
Микросервисная архитектура
Что дает
- независимое масштабирование;
- изолированные релизы;
- явные границы ответственности;
- технологическая автономность.
Что усложняет
- сетевые ошибки и задержки;
- распределенные транзакции;
- наблюдаемость и трассировку;
- совместимость контрактов.
Для небольшого продукта модульный монолит часто проще и дешевле эксплуатации.
29 / DOMAIN
Domain-Driven Design
30 / DATA
Базы данных
1NF — атомарность; 2NF — отсутствие частичных зависимостей; 3NF — отсутствие транзитивных зависимостей. Денормализация применяется осознанно ради чтения и производительности.
31 / CONSISTENCY
Транзакции и согласованность данных
Всегда спрашивайте: что увидит пользователь при гонке изменений, повторе команды, задержке события или частичном падении контура?
32 / CACHE
Кэширование
приложение само читает/обновляет cache
сколько допустима устаревшая информация
когда и кто удаляет старое значение
какие параметры влияют на результат
Требование «добавить Redis» недостаточно: нужно определить источник истины, допустимую stale-версию, поведение при cache miss и стратегию инвалидации.
33 / MODEL
Моделирование данных + SQL
Создайте несколько сущностей, добавьте атрибуты и получите безопасно нормализованный черновик `CREATE TABLE`.
-- Добавьте хотя бы одну сущность
34 / FLOW
Kanban vs Scrum
Scrum
- фиксированные спринты;
- цель спринта и backlog;
- роли и регулярные события;
- изменения контролируются внутри итерации.
Kanban
- непрерывный поток;
- WIP limits;
- управление lead/cycle time;
- приоритет можно менять по мере освобождения capacity.
35 / DELIVERY
CI/CD
Аналитику важно понимать среды, quality gates, конфигурации, миграции, feature flags и обратимость релиза — это влияет на требования и критерии приемки.
36 / VERIFY
Стратегия тестирования и приемки
Ревью требований разработчиком и QA до реализации дешевле, чем исправление неоднозначности после релиза.
37 / OBSERVE
Observability: logs, metrics, traces
Logs
что произошло; structured fields, severity, context.
Metrics
сколько и насколько быстро; rate, errors, duration, saturation.
Traces
где потрачено время в распределенном запросе.
- correlation/request ID проходит через весь контур;
- PII и секреты не попадают в логи;
- есть бизнес-метрики результата, а не только CPU/RAM;
- alert связан с действием, а не просто с графиком.
38 / OPERATE
Релиз, миграции и эксплуатация
старые consumers продолжают работать
plan, validation, rollback
контролируемое включение функции
что можно откатить и за сколько
что делает support при инциденте
кто отвечает после релиза
39 / DECIDE
Decision Tree: какой процесс подойдет
Можно ли планировать работу короткими итерациями с регулярной обратной связью?
40 / SECURITY
Security requirements и OWASP Top 10:2025
Безопасность должна появляться в требованиях до разработки: модель доступа, чувствительные данные, аудит, угрозы и поведение при ошибках.
Для критичных сценариев используйте STRIDE/attack scenarios: актив → доверительная граница → угроза → контроль → способ проверки.
41 / CHECK
Security checklist
42 / MEASURE
Метрики продукта и процесса
Для значимой функции заранее определите, каким сигналом после релиза вы проверите, что проблема действительно решена.
43 / ANTI-PATTERNS
Типичные ошибки аналитика
- Сразу проектировать решениеСначала сформулируйте проблему и ценность.
- Игнорировать NFRПроизводительность, безопасность и наблюдаемость должны быть частью требований.
- Описывать только happy pathДобавляйте ошибки, повторы, таймауты и edge cases.
- Терять трассируемостьСвязывайте цель → сценарий → требование → тест.
- Менять требования молчаИзменение должно иметь автора, причину, влияние и историю.
44 / TEMPLATE
Шаблоны документов
45 / GENERATE
Генератор документов
46 / COMMUNICATE
Шаблоны сообщений
47 / webhook и ошибки API в машиночитаемом виде. Актуальная опубликованная версия спецификации — 3.2.0.
Swagger / OpenAPI
OpenAPI описывает операции, параметры, схемы, ответы и ошибки REST API в машиночитаемом виде.
48 / DECIDE
ADR и журнал решений
Архитектурное решение полезно фиксировать вместе с контекстом, альтернативами и последствиями — иначе через несколько месяцев останется только «так исторически сложилось».
Status: Accepted
Context: ...
Decision: Kafka topic orders.events.v2
Alternatives: REST callback, RabbitMQ
Consequences: eventual consistency, replay support
49 / GROW
Карьерный путь аналитика
сбор и документирование требований
самостоятельное проектирование решений
архитектурные компромиссы и сложные контуры
практика анализа, стандарты и менторство
50 / SKILLS
Карта компетенций
Отметьте освоенные навыки. Состояние хранится только в `localStorage` этого браузера.
51 / QUIZ
Проверка знаний
Analyst Workbench
Не только читать — применять
Инструменты ниже работают локально в браузере и помогают быстро проверить формулировку, подготовить acceptance criteria, оценить SLA и риски, а также собрать трассировку решения.
52 / TOOL
Requirement Quality Checker
53 / TOOL
Acceptance Criteria Builder
Given ... When ... Then ...
54 / TOOL
SLA / Availability Calculator
55 / TOOL
Three-point / PERT Calculator
56 / TOOL
HTTP Status Reference
57 / TOOL
Risk Matrix
58 / TOOL
Traceability Matrix Builder
| Goal | Requirement | Acceptance / Test |
|---|
59 / TOOLS
Быстрые инструменты
60 / REQUEST
API tester
Тестер выполняет запрос из браузера. Целевой API должен разрешать CORS. Секретные токены сюда вводить не следует.
Ответ появится здесь…
61 / NOTES
Заметки аналитика
Заметки не уходят на сервер и сохраняются только в браузере.
62 / READY
Чеклист анализа требований
63 / GLOSSARY
Глоссарий
- Артефакт
- Рабочий продукт анализа: документ, модель, схема, контракт.
- Стейкхолдер
- Заинтересованная сторона, влияющая на решение или испытывающая его влияние.
- Use Case
- Сценарий взаимодействия актора с системой.
- User Story
- Короткое описание ценности с точки зрения роли.
- BPMN
- Нотация моделирования бизнес-процессов.
- REST
- Архитектурный стиль для сетевых API.
- DDD
- Проектирование вокруг предметной области и ее языка.
- CI/CD
- Автоматизация интеграции, проверок и поставки изменений.
- ACID
- Свойства транзакций: atomicity, consistency, isolation, durability.
- ADR
- Architecture Decision Record — короткая фиксация контекста, решения и последствий.
- API Contract
- Формальное соглашение о запросах, ответах, ошибках и ограничениях взаимодействия.
- Backoff
- Увеличение задержки между повторными попытками.
- Bounded Context
- Граница, внутри которой модель и язык домена имеют однозначный смысл.
- CDC
- Change Data Capture — поток изменений из источника данных.
- Circuit Breaker
- Паттерн временного прекращения вызовов нестабильной зависимости.
- Correlation ID
- Идентификатор для трассировки одного бизнес-запроса через несколько систем.
- DLQ
- Dead Letter Queue — очередь сообщений, которые не удалось корректно обработать.
- Eventual Consistency
- Модель, допускающая временное расхождение состояний между компонентами.
- Idempotency
- Свойство операции, при котором повтор не создает дополнительный бизнес-эффект.
- NFR
- Нефункциональное требование: производительность, доступность, безопасность и другие свойства качества.
- Outbox
- Паттерн надежной публикации события вместе с транзакцией изменения данных.
- RPO
- Допустимый объем потери данных, выраженный во времени.
- RTO
- Допустимое время восстановления сервиса.
- Saga
- Паттерн координации распределенной бизнес-транзакции через шаги и компенсации.
- SLA
- Договорный уровень сервиса.
- SLO
- Целевой показатель качества сервиса.
- Traceability
- Связь требования с целью, сценарием, реализацией и проверкой.
- Webhook
- HTTP callback, отправляемый источником при наступлении события.
64 / LINKS