Основы анализа требований
ERD — Entity Relationship; SQL — SQL для аналитики, SQL; миграции — Пакетная работа. Полная таблица — о разделе.
Эта статья — первая остановка в разделе "Аналитика" — термины, исследование, модели, формулировки. Без этой базы дальнейшие главы кажутся разрозненными.
Как читать: пройдите демо ниже, затем определения. Уже знакомы с ролями BA/SA — к Профессиональная аналитика или Формализация и управление требованиями. Если в формулировках всплывают классы, API или "как это станет кодом" — Код — о разделе, проектирование сущности.
Основы анализа требований
Как работает аналитик?
Play ITЗагрузка интерактивного демо…
Что такое анализ?
Как мы помним, слово анализ пришло из греческого языка - "analysis", в переводе "разложение", "разбор". Поэтому технически, это процесс разбора чего-либо на части, но в профессиональной сфере (особенно в управлении проектами IT) это целенаправленное исследование с целью понимания, улучшения и проектирования.
У этого понятия есть широкий смысл - метод познания, при котором объект (система, процесс, проблема) мысленно или практически расчленяется на составляющие, чтобы понять их взаимосвязи, выявить закономерности, обнаружить узкие места и сформулировать решения.
А в контексте IT анализ — мост между реальным миром и цифровым решением — что нужно бизнесу, какие процессы и правила уже есть, что мешает работе. Пример: "автоматизировать приём заказов" — сначала as-is (кто принимает заказ, склад, скидки, возвраты), потом модель to-be в системе.
Аналитика
Аналитика же - это активное выявление, структурирование и трансформирование знаний. Она включает в себя сбор информации, моделирование, формализацию, проверку согласованности и прогнозирование последствий изменений.
Аналитика — это систематический процесс сбора, обработки, анализа и интерпретации данных с целью выявления закономерностей, тенденций, причинно-следственных связей и получения обоснованных выводов для поддержки принятия решений.
В профессиональной среде аналитика делится на несколько ключевых направлений в зависимости от целей и используемых методов:
- Описательная аналитика (Descriptive Analytics): Отвечает на вопрос "Что произошло?". Использует исторические данные для формирования отчетов, дашбордов и KPI. Примеры — оборот за квартал, количество ошибок в системе, посещаемость сайта.
- Диагностическая аналитика (Diagnostic Analytics): Отвечает на вопрос "Почему это произошло?". Включает углубленный анализ данных для поиска корневых причин событий. Методы — drill-down, корреляционный анализ, поиск аномалий.
- Прогнозная аналитика (Predictive Analytics): Отвечает на вопрос "Что произойдет?". Использует статистические модели и алгоритмы машинного обучения для предсказания будущих событий на основе исторических данных. Примеры — прогноз оттока клиентов, нагрузка на серверы, вероятность сбоя оборудования.
- Предписывающая аналитика (Prescriptive Analytics): Отвечает на вопрос "Что нужно сделать?". Предлагает оптимальные варианты действий для достижения желаемого результата или предотвращения негативных сценариев. Часто использует методы оптимизации и симуляции.
Анализ часто путают с диагностикой или контролем, но его цель найти проблему, онять её корни, контекст и возможные пути решения. Без понимания нельзя создать эффективное решение. Мой брат мне приводил хороший пример в сфере строительства, когда строители строго выполняют по документации, и могут не понимать, почему в этом месте должен быть углон на столько-то градусов, а уровень выше на 3 сантиметра. Ошиблись на сантиметр - здание рухнет. И роль аналитики аналогичная - если ошибся аналитик, система либо не заработает, либо будет работать не так, как нужно.
В зависимости от фокуса выделяют:
- бизнес-анализ - изучение целей, процессов и потребностей организации;
- системный анализ - исследование возможностей и ограничений технических систем;
- функциональный анализ - определение, что система должна делать;
- анализ требований - формализация ожиданий от продукта;
- процессный анализ - моделирование и оптимизация рабочих потоков.
Исследование
Исследование - это целенаправленный процесс сбора, изучения и интерпретации информации для понимания предмета, выявления проблем и поиска решений. В аналитике исследование — это систематическое изучение бизнес-контекста, процессов, данных и требований с использованием интервью, документации, наблюдения и аналитических техник.
Мы уже изучали "объекты", и "сущности". Они очень важны для аналитиков. Это любой элемент реального или цифрового мира, который можно выделить и описать. В бизнес-анализе это человек (клиент, сотрудник), документ (договор, заявка), система (CRM, ERP), событие (оформление заказа, оплата). В моделировании это сущность в ERD/UML, которая имеет атрибуты (свойства) и участвует во взаимодействиях.
А что такое взаимосвязь? Это логическая или функциональная связь между объектами, процессами или данными. Показывает, как элементы влияют друг на друга. К примеру, клиент делает заказ, заказ содержит товары. Без понимания взаимосвязей невозможно построить корректную модель системы.
Закономерность
Закономерность - это повторяющаяся, предсказуемая связь между явлениями или данными, которая позволяет обобщать, прогнозировать и принимать решения. К примеру, 80% отказов клиентов происходят при ожидании ответа более 3 минут - это закономерность, которая указывает на проблему в сервисе. Аналитик ищет закономерности в данных, процессах и поведении пользователей, чтобы выявить скрытые правила системы.
Узкое место - это элемент процесса или системы, который ограничивает общую производительность и становится причиной задержек, ошибок или перегрузки. К примеру, все заявки проходят через одного менеджера на согласовании - это и есть узкое место. Выявление узких мест — одна из ключевых задач аналитики при оптимизации процессов.
Основные понятия
Формулирование - это процесс точного, однозначного и понятного выражения мысли, требования или правила. В аналитике важно не просто понять, что нужно бизнесу, но и сформулировать это так, чтобы разработчики, тестировщики и заказчики понимали одинаково.
Решение - это вариант действия, направленный на устранение проблемы или достижение цели. Это может быть предложенная стратегия по изменению процесса, автоматизации, реорганизации данных, внедрения новой логики. Аналитик не всегда принимает решение, но оценивает альтернативы и предлагает обоснованный вариант.
Пять шагов анализа требований
Классическая цепочка от неизвестного к проверенным требованиям (инженерия требований + BABOK):
- Определить scope — границы изменения, стейкхолдеры, источники информации.
- Найти болевые точки — симптомы vs первопричины; избегать готовых "решений в голове" заказчика.
- Выявить корневые причины — синтез данных интервью, процессов, метрик.
- Сформулировать требования — что должно измениться, чтобы убрать причину боли.
- Проверить (validate) — полнота, выполнимость, приоритет, однозначность, связь с тестами; итеративно на всём ЖЦ.
Моделирование (текст, BPMN и др., таблицы, матрицы) на шагах 2–4 упрощает сложное для команды и QA. Формализация и RM — в Формализация и управление требованиями.
Стоимость дефекта по фазам ЖЦ
Ошибка в требованиях, которую не поймали рано, дорожает к эксплуатации. Ориентиры из практики (порядок величин, не абсолют):
| Фаза обнаружения | Относительная стоимость исправления |
|---|---|
| Elicitation / анализ | ×1 (база) |
| Проектирование | до ×20 |
| Разработка | до ×20 |
| Тестирование | ×40–60 |
| Эксплуатация / prod | ×100 и выше |
Статическая проверка ТЗ на этапе анализа — самый дешёвый способ закрыть дыры в проверяемости. Техники — в 7.05 / основы тестирования.
Свойства качественных требований
Требование пригодно для разработки и тестирования, когда по нему можно однозначно понять что строим и как проверить результат. Ниже — практический чек-лист (согласован с Karl Wiegers, ISTQB и базовым курсом по тестированию).
| Свойство | Смысл | Пример проблемы |
|---|---|---|
| Полнота | Описаны все нужные случаи, включая ошибки и исключения | "Система валидирует email" — но не сказано, что при неверном формате |
| Непротиворечивость | Два требования не конфликтуют | В одном месте "скидка 10 %", в другом "скидки нет" |
| Однозначность | Одна трактовка у аналитика, разработчика и QA | "Быстрая загрузка" без цифры |
| Проверяемость | Можно написать тест-кейс с объективным ожиданием | "Удобный интерфейс" без критериев |
| Выполнимость | Реализуемо в срок и на доступном стеке | Требование "в реальном времени на 1 млн RPS" без обоснования |
| Прослеживаемость | Есть ID, связь с бизнес-целью и тестами | Нельзя понять, откуда взялось правило |
| Ранжирование | Важность, стабильность, срочность зафиксированы | Все задачи "критичные" |
| Корректный уровень | Бизнес-правило отделено от UI-деталей | В BRD прописан цвет кнопки |
| Адресат — система | Формулировка про поведение приложения | "Пользователь должен помнить пароль" |
Типичные замечания QA: нет негативных сценариев, нет критериев приёмки.
Техники статической проверки требований — в основах тестирования; формализация требований — в Формализация и управление требованиями; виды проверок при реализации — Проверка и валидация.
Процесс - это упорядоченная последовательность действий, направленных на достижение определённого результата. Процесс имеет участников (роли), шаги (задачи), входы и выходы, а также правила и условия переходов.
Структурирование - это приведение разрозненной, хаотичной информации в упорядоченный, логичный и понятный вид. Это может быть преобразование устных рассказов менеджера в таблицу требований, группировка функций по модулям системы, построение дерева процессов.
Выявление - это процесс обнаружения скрытых, неочевидных или несформулированных элементов — требований, проблем, правил, исключений. Часто заказчики сами не знают, что им нужно. Аналитик "выявляет" это через вопросы, анализ данных, сравнение с лучшими практиками.
Трансформирование — преобразование информации из одной формы в другую без потери смысла: устное → BPMN, пожелание → user story с критериями приёмки.
Не путайте — аналитика требований и аналитика данных
| Требования (этот раздел) | Данные | |
|---|---|---|
| Когда | До и во время изменения системы | Когда система уже собирает события |
| Результат | ТЗ, модели, backlog | Отчёты, метрики, дашборды |
| Углубление | Формализация и управление требованиями, Артефакты аналитической деятельности | Как переводить бизнес-задачи на язык данных, 3.11 |
Что дальше
| Цель | Статья |
|---|---|
| Профессия и техники | Профессиональная аналитика |
| BA / SA | Роль бизнес-аналитика в проекте, Роль системного аналитика в разработке |
| Требования | Формализация и управление требованиями |
| Карта раздела | intro |
Практика формулировок
Слабый вход от заказчика:
"Нужно улучшить работу с заявками."
Рабочий вход для аналитики:
"Нужно сократить среднее время обработки заявки с 2 дней до 8 часов в течение квартала. Приоритет - региональные отделы с нагрузкой выше 500 заявок в неделю."
Во втором варианте сразу появляются измеримость, срок, контур пользователей и приоритет. Это ускоряет переход от разговора к требованиям.
Частые ошибки новичка
-
Подмена цели решением
Формулировка "нужен дашборд" задает инструмент, но не бизнес-эффект. -
Отсутствие роли пользователя
Без роли непонятно, кто выполняет действие и какие права доступа нужны. -
Игнорирование исключений
Базовый сценарий описан, альтернативные ветки пропущены, и система ломается на реальных кейсах. -
Непроверяемые критерии
Слова "удобно", "быстро", "качественно" без чисел и условий не подходят для QA и приемки.
В подборках
Статья входит в тематические подборки и блок "С чего начать?" на главной. Соседние шаги того же маршрута:
Системная аналитика — Основы бизнеса для IT-специалиста, Аналитика — о разделе, BPMN-движки Camunda и Flowable, Программные платформы, Корпоративное ПО, Платформенные решения в бизнесе.