Перейти к основному содержимому

Формализация и управление требованиями

ОБЯЗАТЕЛЬНОДЛЯ НОВИЧКОВ
Аналитику Архитектору Руководителю Техническому писателю
Теория данных (раздел 3)

ERD — Entity Relationship; SQL — SQL для аналитики, SQL; миграции — Пакетная работа. Полная таблица — о разделе.

Центральная статья раздела: сбор, классификация, управление изменениями, приоритизация, оценка. После Основы анализа требований–Профессиональная аналитика — обязательна для всех аналитических ролей.

Если формулировку нельзя проверить тестом или демо — это ещё идея, не требование.

Формализация и управление требованиями​

Требование — проверяемая договорённость о том, что система делает или каким качеством обладает.

  • бизнес — ЗАЧЕМ;
  • функциональные — ЧТО;
  • нефункциональные (NFR) — КАК ХОРОШО.

Что такое требование?​

В контексте разработки программного обеспечения и управления ИТ-проектами требование — это формализованное, проверяемое и однозначное описание потребности, ожидания или ограничения, предъявляемого к продукту, системе, процессу или его компонентам. Требование служит основой для проектирования, реализации, тестирования и сопровождения решения. Оно отражает то, что должно быть сделано, а не как это должно быть сделано.

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

Не следует путать требование с пожеланием, идеей или задачей. Пожелание ("Хотелось бы, чтобы система работала быстрее") — это неформальное выражение потребности и не является требованием до тех пор, пока оно не будет уточнено, измерено и формализовано ("Система должна обрабатывать 10 000 запросов в секунду при задержке не более 200 мс").

Управление требованиями​

Управление требованиями (Requirements Management, RM) — это систематическая дисциплина, охватывающая полный жизненный цикл требований: от их выявления до реализации и последующей поддержки. Она включает в себя процессы планирования, сбора, анализа, спецификации, верификации, валидации, отслеживания и контроля изменений.

Главная цель управления требованиями — обеспечить, чтобы система, в итоге реализованная, соответствовала реальным потребностям заинтересованных сторон, а также чтобы все требования были прослеживаемы, согласованы, реализуемы, тестируемы и приоритизированы.

В практической работе управление требованиями предотвращает такие типичные проблемы, как:

  • упущенные или недопонятые функции,
  • избыточные или противоречивые требования,
  • "размытые" цели проекта,
  • постоянные изменения без контроля,
  • несоответствие конечного продукта ожиданиям заказчика.

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

Планирование и мониторинг бизнес-анализа (BABOK)​

До elicitation BA формирует план работы в области Planning and Monitoring. Пять типовых задач:

ЗадачаРезультат
Планирование подхода к BAМетоды, артефакты, график, ожидаемые deliverables
План взаимодействия со стейкхолдерамиРоли, частота коммуникаций, каналы, RACI по согласованиям
План governance BAКак принимаются решения по требованиям, приоритетам и изменениям
План управления информацией BAГде хранятся артефакты, версии, доступ, retention
Оценка эффективности BAСравнение факт vs план: успели ли analysis activities ускорить внедрение ценности

План подхода согласуют с PM и спонсором: он задаёт глубину анализа (lean backlog vs полный SRS) и инструменты — см. Инструменты аналитика. Коммуникации со стейкхолдерами — в Взаимодействие аналитика с командой.

Классификация требований по BABOK​

Согласно Business Analysis Body of Knowledge (BABOK v3) — международному стандарту в области бизнес-анализа, — требования делятся на четыре категории:

  1. Бизнес-требования (Business Requirements)
    Отражают стратегические цели и высокий уровень результатов, которых организация стремится достичь. Формулируются на уровне компании или подразделения. Пример: "Сократить время обработки заказов на 30 % за счёт автоматизации складских операций".

  2. Требования заинтересованных сторон (Stakeholder Requirements)
    Описывают потребности отдельных групп или лиц, чьи интересы затрагивает система. Эти требования служат мостом между бизнес-целями и технической реализацией. Пример: "Оператор склада должен видеть статус каждого заказа в реальном времени".

  3. Требования к решению (Solution Requirements)
    Детализируют характеристики самого продукта или системы. Подразделяются на:

    • функциональные (что система делает),
    • нефункциональные (как хорошо она это делает — производительность, безопасность, удобство и т.д.).

  4. Переходные требования (Transition Requirements)
    Временные условия, необходимые для перехода от текущего состояния к будущему. Актуальны только в процессе внедрения. Пример: "Система должна поддерживать параллельную работу со старой и новой платформой в течение трёх месяцев".

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

Типы требований в IT-практике​

В инженерной среде, особенно в разработке ПО, чаще используют более прикладную классификацию, ориентированную на техническую реализацию:

  • Функциональные требования
    Описывают поведение системы: какие действия она должна выполнять в ответ на определённые входные данные или события. Пример: "При нажатии кнопки "Отправить" система должна валидировать форму и отправить данные на сервер". Как это выглядит в коде — Проверка и валидация.

  • Нефункциональные требования (NFR)
    Задают качественные характеристики системы — производительность, масштабируемость, надёжность, безопасность, удобство использования, совместимость и т.п. Пример: "Система должна поддерживать до 10 000 одновременных пользователей без падения производительности".

  • Переходные требования
    Как и в BABOK, это временные условия, необходимые для миграции, обучения, интеграции или отката. Пример: "Данные из устаревшей CRM-системы должны быть перенесены в новую без потерь".

Для технических специалистов понимание различий между функциональными и нефункциональными требованиями критически важно: первые определяют логику работы, вторые — границы допустимого поведения. Игнорирование NFR часто приводит к тому, что система "работает", но "не масштабируется", "не защищена" или "непригодна в эксплуатации".

Управление требованиями​

Процессы управления требованиями​

Управление требованиями — непрерывный цикл. В инженерной практике его часто описывают четырьмя процессами (плюс планирование):

  1. Планирование управления требованиями — RMP — методы, трассировка, change workflow, роли.
  2. Разработка (development) — elicitation → анализ и спецификация (RDD / backlog) — структурирование, уточнение, документирование так, чтобы разработчик понял что строить.
  3. Проверка (verification) — внутренний контроль качества формулировок — полнота, непротиворечивость, связь с планом разработки; участие QA на ревью — Основы анализа требований.
  4. Валидация (validation) — формальное принятие стейкхолдерами — UAT, подписанные протоколы, "требования выполнены".
  5. Управление изменениями (RCM) — единый контур с change control проекта: запрос → impact analysis → утверждение → обновление RTM и тестов.
План управления требованиями — минимум

RMP фиксирует планирование и отслеживание каждого требования; управление конфигурацией документов; структуру прослеживаемости (бизнес-цель → требование → задача → тест); процесс приоритизации (см. таблицу ниже).

Эти процессы итеративны — в Agile refinement и validation идут каждый спринт.

План управления требованиями (RMP)​

План управления требованиями — это документ, регламентирующий подход к работе с требованиями в конкретном проекте. Он определяет процедуры обработки. В типичный RMP входят:

  • Подход к определению и документированию требований (форматы, шаблоны, инструменты).
  • Методы сбора и анализа (например, интервью, прототипирование).
  • Критерии качества требований (SMART, INVEST и др.).
  • Процедура приоритизации (MoSCoW, value/cost/риск — см. таблицу ниже).
  • Стратегия отслеживания (traceability matrix).
  • Процесс управления изменениями (change control board, workflow).
  • Роли и ответственности (часто в виде матрицы RACI).

Наличие RMP особенно важно в крупных, сложных или регулируемых проектах (например, в банковской сфере, здравоохранении), где отсутствие контроля над требованиями чревато юридическими и финансовыми рисками.

Матрица RACI в контексте требований​

Матрица RACI — инструмент распределения ролей в процессе работы с требованиями. Для каждого артефакта или действия определяются:

  • R (Responsible) — кто выполняет работу (например, бизнес-аналитик составляет спецификацию),
  • A (Accountable) — кто несёт окончательную ответственность за результат (часто product owner или руководитель проекта),
  • C (Consulted) — кто предоставляет экспертную информацию (разработчик, архитектор, юрист),
  • I (Informed) — кто должен быть проинформирован о результате (тестировщики, поддержка).

Пример для функционального требования:

  • R: бизнес-аналитик,
  • A: product owner,
  • C: архитектор и ведущий разработчик,
  • I: команда QA и технический писатель.

Чёткое распределение ролей снижает риск "серых зон" ответственности и ускоряет согласование.

Критерии приоритизации (BABOK)​

Перед финальным ранжированием BA оценивает требование по бизнес-соображениям (часто комбинируют несколько):

КритерийВопрос
Ценность (value)Какую выгоду принесёт реализация?
Стоимость (cost)Сколько effort и денег потребуется?
РискЧто случится, если не сделать или сделать неправильно?
СложностьНасколько трудно реализовать и сопровождать?
Вероятность успехаЕсть ли зависимости, блокеры, неизвестные?
Согласие стейкхолдеровЕдиное ли видение приоритета?
Срочность (urgency)Есть ли жёсткий дедлайн (регулятор, сезон, контракт)?

MoSCoW и RICE — удобные шаблоны поверх этих критериев; подробнее — в Роль бизнес-аналитика в проекте и 7.02.

Жизненный цикл требования​

Ключевые фазы​

Требование проходит несколько фаз, образующих его жизненный цикл:

  1. Выявление потребностей — понимание проблемы или возможности.
  2. Формулирование — перевод потребности в текст требования.
  3. Анализ и приоритизация — оценка реализуемости, стоимости, влияния.
  4. Согласование и утверждение — валидация с заинтересованными сторонами.
  5. Реализация — разработка и тестирование по требованию.
  6. Верификация и валидация — проверка соответствия.
  7. Поддержка и изменение — обновление при изменении контекста.
  8. Архивирование или утилизация — когда требование устаревает.

Каждый этап сопровождается метаданными — дата создания, автор, статус, версия, связи с другими требованиями и задачами.

Сбор требований​

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

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

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

  1. Интервью (Interviews) - это беседа аналитика с заинтересованными лицами (заказчиками, пользователями, экспертами) с целью выявления потребностей, проблем и ожиданий. Его нужно использовать на старте проекта, когда нужно глубоко погрузиться в предметную область, или когда участники не могут сформулировать требования сами. К примеру, аналитик встречается с менеджером по продажам и спрашивает "Как вы сейчас обрабатываете заказы? Что вызывает сложности? Что бы вы хотели автоматизировать?", но это в самом начале. Если же проект уже работает, и задача более узкая, могут быть более простые или наоборот, сложные интервью.
  2. Анкетирование / Опросы (Questionnaires & Surveys) - это сбор информации от большой группы людей с помощью структурированных вопросов (онлайн или на бумаге). Использовать, когда нужно собрать мнения от многих пользователей или получить статистику, приоритеты, наболевшее. К примеру, опрос клиентов о том, какой функцией в личном кабинете пользуются, какую хотели бы видеть.
  3. Мозговой штурм (Brainstorming) - групповая сессия, где участники генерируют идеи без критики, чтобы найти нестандартные решения или выявить скрытые потребности. Использовать для поиска инноваций, когда нужно "взболтать" мышление команды, или на этапе генерации идей для нового продукта. К примеру, можно всей командой из 10 человек собраться и за 45 минут сгенерировать 50 идей, как улучшить текущую ситуацию.
  4. Наблюдение (Observation / Job Shadowing) - аналитик наблюдает, как пользователи выполняют задачи в реальной обстановке, чтобы выявить неочевидные проблемы и реальные процессы (а не те, что "на бумаге"). Используется, когда пользователи не могут точно описать свою работу, или когда есть подозрение, что процессы "в теории" и "на практике" отличаются. Пример - аналитик целый день сидит рядом с оператором колл-центра и видит, что тот 10 раз копирует данные из одного окна в другое, а это можно автоматизировать, к примеру, автозаполнением.
  5. Анализ документов (Document Analysis) - изучение существующих документов — регламентов, инструкций, отчётов, спецификаций, писем, чатов — для выявления скрытых требований и правил. На самом деле, это крупнейший вариант. Используется, когда есть наследие в виде старых систем или процессов, или для понимания юридических, финансовых, нормативных требований. Аналитик может читать договора, законы, копаться в архивах или запрашивать что-то ещё, и находить нужное для работы.
  6. Ролевые игры / Сценарии использования (Use Кейсы / User Stories / Role Playing) - это моделирование ситуаций взаимодействия пользователя с системой для выявления шагов, условий, исключений и ожидаемых результатов. Используется для описания функциональных требований, в Agile Scrum проектах (через User Story) и чтобы "прожить" сценарий, найти в нём дыры и уязвимости.
  7. Прототипирование (Prototyping) - создание упрощённой модели интерфейса или процесса (бумажной, цифровой, интерактивной), чтобы визуализировать требования и получить обратную связь ДО разработки. Использовать в тех случаях, когда сложно описать словами, для согласования с пользователями, и чтобы избежать дорогостоящих переделок. Самый простой пример - кликабельный макет формы заказа.
  8. Фокус-группы (Focus Groups) - групповое обсуждение с целевой аудиторией под руководством модератора для сбора мнений, реакций, идей. Используется для оценки восприятия нового продукта или функции, для сбора эмоциональной обратной связи. Результаты могут сказать о многом.
  9. Семинары требований (Requirements Workshops, JAD / СРТ — совместная разработка требований) — организованная сессия с участием всех ключевых стейкхолдеров для совместного определения, приоритизации и согласования требований. Использовать, когда нужно быстро согласовать много сторон, для сложных или конфликтных проектов. На таких сессиях часто вскрывают пересекающиеся требования, которые не видны при поочерёдных интервью.

Плоский список требований и измеримые цели​

Длинный перечень пунктов "система должна…" удобен как чек-лист и основа для контракта, но у него есть слабые места:

  • пункты оторваны от контекста — не видно, как сценарии связаны между собой;
  • приоритизация по номеру строки ломает целостный бизнес-сценарий;
  • чем больше читателей, тем больше разных интерпретаций одной формулировки;
  • список создаёт иллюзию полноты, хотя скрытые требования всплывают позже.

Практичный приём — список держать как подсказку, а для ключевых целей задавать вопрос "зачем?" до измеримых бизнес-результатов (срок, объём, конверсия, SLA). Тогда приёмочные тесты и критерии готовности опираются на цели, а не на сотни разрозненных строк.

ПодходПлюсМинус
Только список в Excel/ConfluenceКонтроль объёма, договорСлабая связь с поведением пользователя
User Story / Use Case + список NFRКонтекст и прослеживаемостьДороже вести актуальным
Измеримые цели + короткий бэклогФокус на ценностиНужна дисциплина формулировок

Ограничения прототипирования​

Прототип (макет, кликабельный wireframe, throwaway-код) ускоряет согласование UI и снижает риск "не то поняли". Он не заменяет полноценный анализ требований:

  • заказчик может принять внешний вид за готовый продукт;
  • менеджмент недооценивает срок до production-качества;
  • разработчики тянут прототипный код в релиз "чтобы не выбрасывать" — риск техдолга (4.06/115, культура кода);
  • прототип хорошо проверяет экраны, но слабо — сложную бизнес-логику, пакетные процессы и интеграции;
  • прототип не отвечает на вопрос "какие были исходные требования", если их не зафиксировали отдельно.

Правило: прототип сопровождают явной пометкой цели (уточнить UX / проверить риск / демо инвестору) и решением — выбросить или эволюционировать с тестами. См. throwaway и evolutionary.

Формулирование требований​

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

Качественное требование должно обладать следующими свойствами (часто обобщаемыми под акронимом SMART или CARS):

  • Понятность (Clarity) — отсутствие двусмысленностей, жаргона без пояснений, расплывчатых формулировок вроде "интуитивный интерфейс".
  • Полнота (Completeness) — все необходимые условия и контексты явно указаны.
  • Непротиворечивость (Consistency) — требование не вступает в конфликт с другими.
  • Проверяемость (Testability) — по требованию можно составить тест-кейс или сценарий верификации.
  • Реализуемость (Feasibility) — требование технически достижимо в рамках заданных ограничений.
  • Проследимость (Traceability) — возможность связать требование с бизнес-целью и с итоговой реализацией.

Пример неудачной формулировки:

"Система должна быть быстрой".

Пример корректной:

"При 95-м процентиле нагрузки (до 5000 одновременных сессий) время ответа на запрос авторизации не должно превышать 300 мс".

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

Декомпозиция задач​

Декомпозиция — это разбиение сложного требования или функциональности на более мелкие, управляемые компоненты. Это необходимо для планирования, оценки и распределения работ.

Существует два основных подхода:

  1. Вертикальная декомпозиция
    Разбивает функциональность по уровням абстракции: от высокоуровневого пользовательского сценария к детальным шагам реализации. Например:

    • Уровень 1: "Пользователь может оформить заказ".
    • Уровень 2: "Выбор товара → добавление в корзину → ввод данных доставки → оплата".
    • Уровень 3: "Валидация email-адреса при вводе контактных данных".

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

  2. Горизонтальная декомпозиция
    Разделяет задачу по технологическим слоям — UI, бизнес-логика, база данных, интеграции и т.д. Например:

    • UI-часть: форма оформления заказа,
    • Логика: расчёт итоговой суммы,
    • БД: сохранение заказа в таблицу orders,
    • Интеграция: отправка уведомления в CRM.

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

В современной практике предпочтение отдаётся вертикальной декомпозиции, особенно в Agile-средах, поскольку она поддерживает принцип инкрементальной ценности.

Оценка объёма работ​

Оценка — это прогноз ресурсов (время, усилия, стоимость), необходимых для реализации требований. Точность оценки критически влияет на реалистичность графика и бюджета проекта.

Что оценивается?​

  • Трудозатраты (человеко-часы, человеко-дни),
  • Техническая сложность,
  • Риски (неопределённость, зависимости, интеграции),
  • Необходимость дополнительных исследований (spike’и).

Методы оценки​

  1. Аналоговая (по схожим задачам) — используется историческая статистика.
  2. Параметрическая — расчёт по формуле (например, "1 экран = 20 человеко-часов").
  3. Экспертная — мнение опытных разработчиков.
  4. Planning Poker / Story Points — относительная оценка в безразмерных единицах, часто применяемая в Scrum.
  5. T-shirt sizing (S/M/L/XL) — грубая категоризация по сложности на ранних этапах.

Алгоритм оценки (рекомендуемый)​

  1. Разбить требование на задачи (по вертикали!).
  2. Уточнить неопределённости (провести spike при необходимости).
  3. Выбрать метод оценки, соответствующий стадии проекта.
  4. Включить буфер на риски (10–30 % в зависимости от новизны).
  5. Утвердить оценку с командой (коллективная ответственность повышает точность).
  6. Зафиксировать допущения и ограничения, на которых строилась оценка.

Оценка — это прогноз. Чем больше неопределённости, тем шире должен быть диапазон (например, 16–24 часа вместо "20 часов").

Верификация и валидация​

Часто эти термины путают, но их различие принципиально:

  • Верификация (Verification) — "делаем ли мы продукт правильно?"
    Проверка, что требования и реализация соответствуют внутренним стандартам, спецификациям и техническим критериям.
    Инструменты:

    • Definition of Ready (DoR) — критерии готовности требования к разработке (полное, понятное, оценено, имеет acceptance criteria),
    • Definition of Done (DoD) — критерии завершения задачи (код написан, покрыт тестами, задокументирован, прошёл ревью),
    • Ревью требований — коллегиальный анализ спецификации на полноту и качество.

  • Валидация (Validation) — "делаем ли мы правильный продукт?"
    Подтверждение, что реализованное решение действительно решает проблему заказчика.
    Инструменты:

    • Согласование с заинтересованными сторонами,
    • Три Amigo — совместная сессия аналитика, разработчика и тестировщика для обсуждения acceptance criteria,
    • User Acceptance Testing (UAT) — тестирование конечными пользователями в реальных условиях,
    • Демонстрации функционала — регулярные показы работающего продукта.

Верификация — внутренний контроль качества; валидация — подтверждение соответствия бизнес-нуждам.

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

Передача — это налаживание контекста. Эффективная передача включает:

  • Презентацию требования на планировании (grooming/planning session),
  • Обсуждение acceptance criteria с участием всех ролей (Три Amigo),
  • Демонстрацию прототипов или макетов (если есть),
  • Пояснение бизнес-ценности — зачем это нужно заказчику,
  • Фиксацию открытых вопросов и сроков их закрытия.

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

Поддержка в ходе разработки​

Реализация редко идёт строго по изначальному описанию. Возникают вопросы:

  • "А что делать, если поле пустое?"
  • "Какой статус считать "завершённым"?"
  • "Как обрабатывать ошибку интеграции?"

Аналитик обязан:

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

Это неотъемлемая часть цикла управления требованиями.

Спецификация требований к программному обеспечению (SRS)​

Software Requirements Specification (SRS) — это формальный документ, описывающий функциональные и нефункциональные требования к системе, её внешнее поведение, ограничения и взаимодействие с окружением. SRS служит основой для проектирования, разработки, тестирования и приёмки продукта.

Хотя в Agile-средах SRS часто заменяется на гибкие артефакты (бэклог, пользовательские истории), в регулируемых отраслях (медицина, авиация, финансы) и при разработке сложных систем SRS остаётся обязательным элементом жизненного цикла.

Стандартная структура SRS​

  1. Введение

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

  2. Общее описание

    • Перспектива продукта (как он вписывается в экосистему),
    • Классы пользователей и характеристики,
    • Ограничения (технические, юридические, временные),
    • Предположения и зависимости,
    • Диаграммы контекста (например, диаграмма потоков данных или Use Case overview).

  3. Функциональные требования

    • Организуются по подсистемам, модулям или пользовательским ролям,
    • Каждое требование имеет уникальный идентификатор (например, FR-101),
    • Описывается триггер, входные данные, поведение системы, выходные данные, ошибочные сценарии.

  4. Нефункциональные требования

    • Группируются по категориям — производительность, безопасность, надёжность, удобство использования, совместимость, масштабируемость и т.д.,
    • Формулируются количественно, где возможно — RTO (время до снова работающего сервиса), RPO (допустимая потеря данных, например "не более 15 минут транзакций"), доступность (uptime), время реакции на инцидент. Для систем с БД эти метрики связывают с резервным копированием и журналами СУБД — см. восстановление после сбоя.

  5. Внешние интерфейсы

    • Пользовательские интерфейсы (описание или ссылка на макеты),
    • Аппаратные интерфейсы,
    • Программные интерфейсы (API, протоколы, форматы данных),
    • Коммуникационные интерфейсы (сетевые протоколы, порты).

  6. Приложения

    • Глоссарий,
    • Диаграммы,
    • Примеры данных,
    • Матрица прослеживаемости (если включена в SRS).

SRS не должен содержать решений архитектуры, алгоритмов или деталей реализации — только что система должна делать, а не как.

Типичные ошибки при формулировании и управлении требованиями​

  1. Расплывчатость и неоднозначность
    Использование субъективных формулировок — "удобный", "быстрый", "интуитивный". Такие требования невозможно проверить.

  2. Отсутствие измеримости в нефункциональных требованиях
    "Система должна быть надёжной" — бессмысленно без указания метрик — MTBF, допустимое время простоя, RTO/RPO.

  3. Игнорирование контекста использования
    Требование описано без учёта сценариев, ролей пользователей или исключительных ситуаций.

  4. Смешение уровней абстракции
    В одном документе — стратегические цели и детали UI-элементов — это нарушает структуру и усложняет управление.

  5. Отсутствие прослеживаемости
    Невозможно понять, какое требование реализовано в каком коде или покрыто каким тестом — это ведёт к "утерянным" функциям и регрессиям.

  6. Недооценка нефункциональных требований
    Часто рассматриваются как "второстепенные", хотя именно они определяют эксплуатационную пригодность системы.

  7. Отсутствие версионирования и контроля изменений
    Без фиксации изменений невозможно восстановить причинно-следственные связи при сбоях или спорах.

Почему участники проекта не работают с едиными требованиями?​

Несогласованность возникает из-за системных причин:

  1. Фрагментация источников
    Требования хранятся в разных местах — в Confluence, Jira, Excel, устных договорённостях, email’ах. Единого источника истины нет.

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

  3. Разные представления о приоритетах
    Бизнес ценит скорость вывода на рынок, разработка — техническое качество, тестирование — покрытие. Без согласованного подхода к приоритизации возникает конфликт.

  4. Изменения без контроля
    Заказчик вносит правки напрямую разработчику, минуя аналитика — документация устаревает, команда работает по разным версиям.

  5. Отсутствие вовлечения технических специалистов на ранних этапах
    Архитектор или ведущий разработчик не участвует в анализе — требования оказываются технически неосуществимыми или избыточно сложными.

  6. Культура "догоняющего" документирования
    Требования оформляются постфактум, "чтобы закрыть процесс", а не как инструмент работы. В этом случае документ становится формальностью.

Подходы к документированию требований​

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

1. Классический (водопадный) подход​

  • Используется полная, детализированная SRS до начала разработки.
  • Подходит для проектов с фиксированным объёмом, чёткими границами, высокими требованиями к документации (например, госзаказы, embedded-системы).
  • Плюсы — полнота, юридическая защищённость, чёткие границы.
  • Минусы: негибкость, высокая стоимость изменений.

2. Agile-подход (на основе пользовательских историй)​

  • Требования фиксируются как краткие истории — "Как [роль], я хочу [функция], чтобы [цель]".
  • Детализация происходит по мере надобности (just-in-time).
  • Acceptance criteria и примеры (Given/When/Then) заменяют формальную спецификацию.
  • Плюсы — гибкость, фокус на ценности, быстрая обратная связь.
  • Минусы: риск потери контекста, сложность в регулируемых средах.

3. Гибридный подход​

  • Комбинирует SRS для ключевых модулей (например, ядра системы, интеграций) и пользовательские истории для итеративных улучшений.
  • Часто применяется в enterprise-разработке.
  • Используются living documents: спецификации, обновляемые в процессе разработки и синхронизированные с бэклогом.

4. Model-Based Requirements Engineering (MBRE)​

  • Требования выражаются в виде моделей — диаграмм BPMN, UML, SysML.
  • Поддерживает автоматическую генерацию тестов, прослеживаемость и анализ полноты.
  • Требует специализированных инструментов (Enterprise Architect, IBM Rhapsody и др.).

5. Specification by Example (SBE)​

  • Требования формулируются через конкретные примеры поведения.
  • Формат: "Если пользователь вводит email без @, система показывает ошибку: "Некорректный формат email"".
  • Легко трансформируется в автоматизированные acceptance-тесты (например, с помощью Cucumber).

Аналитик в Agile​

СобытиеЗадача аналитика
RefinementAC, зависимости, готовность к спринту
СпринтУточнения, фиксация решений в Jira/Confluence
ChangeОценка влияния, согласование scope

Definition of Ready (пример): роль, цель, AC, нет блокеров по ИБ/юристам. Подробнее — Документация в процессах.

Пример превращения идеи в требование​

Исходная фраза стейкхолдера: "Нужен более удобный поиск по клиентам".

Путь формализации:

  1. Уточнение цели: зачем менять поиск и какая метрика страдает.
  2. Выделение сценариев — поиск по ФИО, телефону, email, номеру договора.
  3. Формулирование функциональных требований:
    • система ищет по частичному совпадению;
    • результаты сортируются по релевантности;
    • есть фильтр по статусу клиента.
  4. Формулирование NFR:
    • 95-й перцентиль ответа до 700 мс;
    • поддержка 300 одновременных запросов.
  5. Добавление acceptance criteria в формате Given-When-Then.
  6. Привязка к тестам и задачам разработки.

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

Минимальный набор полей для карточки требования​

  • Идентификатор и версия.
  • Источник и владелец требования.
  • Бизнес-ценность и связанная цель.
  • Описание поведения и критерии приёмки.
  • Статус и приоритет.
  • Связи с задачами, тестами, документами и рисками.

Анти паттерны в управлении требованиями​

  • Устные договорённости без фиксации в источнике истины.
  • Изменения в обход процесса impact analysis.
  • Смешение бизнес-целей, UX-деталей и API в одном пункте.
  • Отсутствие ответственности за актуальность артефакта.
  • Прослеживаемость "на словах", без ссылок на тесты и реализацию.

Перекрёстные ссылки для практики​

Дальше — Артефакты аналитической деятельности, Документация аналитика, Взаимодействие аналитика с командой.

Содержание