Верификация и валидация — два разных процесса проверки, которые отвечают на вопросы «правильно ли мы описали требования» и «те ли требования мы описали». Для аналитика V&V — не формальность перед передачей в разработку, а способ снизить переделки и зафиксировать согласие стейкхолдеров до того, как ошибка уйдёт в код.

1. Суть темы

Несмотря на созвучие, верификация (verification) и валидация (validation) — принципиально разные виды деятельности. Их путают чаще всего потому, что обе «проверяют требования», но с разных сторон.

КритерийВерификация (Verification)Валидация (Validation)
Ключевой вопросПравильно ли мы описали требование?То ли требование мы описали?
ФокусКачество артефакта: форма, структура, согласованность с правиламиСоответствие реальной потребности, цели, ожиданиям стейкхолдера
Объект проверкиСпецификация, модели, связи между артефактамиТребование относительно бизнес-проблемы и ценности
Типичные методыРецензирование, инспекция, чек-листы, трассировка, сверка моделейПрототипы, воркшопы, согласование AC, интервью, sign-off
Участие бизнесаНе обязательно — достаточно команды анализа и разработкиНужен представитель потребности: стейкхолдер, PO или делегат с явным мандатом (см. раздел 2.5)

Классическая формулировка (Барри Бём):

  • Верификация: «Are we building the product right?»
  • Валидация: «Are we building the right product?»

В контексте артефактов требований:

Граница: V&V требований vs V&V продукта

Важно не смешивать проверку документа требований и проверку реализации:

УровеньЧто проверяемПримерыГде в vault
V&V требованийАртефакт: user story, use case, SRS, модельЧек-лист качества, инспекция, согласование AC со стейкхолдеромЭта статья, 02.04.02 Критерии приёмки (Acceptance Criteria)
V&V продукта / инкрементаРаботающая система или её частьUAT, системное тестирование, demo спринта, пилот, A/B00.03 Жизненный цикл ПО и место аналитика (SDLC, STLC), 05.02 Scrum и Kanban (аналитик в Agile)

Demo и UAT в Agile — прежде всего валидация реализации (STLC). Они косвенно уточняют требования: если на demo стейкхолдер говорит «это не то», вы возвращаетесь к артефакту и перезапускаете V&V требований. Пройденный UAT не означает, что исходная спецификация была валидирована — только что конкретный инкремент принят.

В BABOK v3 задачи 7.4 Verify Requirements и 7.5 Validate Requirements относятся к анализу требований; outputs — verified requirement и validated requirement соответственно (см. 00.04 Основные стандарты и своды знаний (BABOK, SEBoK, ISO 29148)). IEEE Std 1012-2016 описывает V&V на всех уровнях жизненного цикла — от требований до приёмки системы; для BA важен ранний этап: артефакты требований (SRS, user story, модели) проходят статическую проверку и согласование до передачи в design/dev — это «левый крюк» V-образной модели (см. 05.01 Waterfall и V-model).

2. Ключевые понятия

2.1 Что проверяет верификация

Верификация отвечает на вопрос: «можно ли этим требованием пользоваться — передать в design/dev/test без доработок формы?» Полный перечень атрибутов качества (корректность, однозначность, полнота, согласованность, прослеживаемость, верифицируемость и др.) — в 02.04.03 Управление качеством требований. Здесь — только то, что задаёт логику V&V:

  • Формальная корректность — требование соответствует правилам документирования, шаблону, нотации; проверяется верификацией (чек-лист, peer review).
  • Предметная корректность — требование отражает реальную потребность; проверяется только валидацией у стейкхолдеров.

Именно из-за этого «корректность» фигурирует и в критериях верификации (ISO/IEC/IEEE 29148:2018), и в списках качества: формальная часть — verify, предметная — validate. Без этого различения первая таблица в разделе кажется противоречивой.

Верифицируемость (verifiability) — у каждого требования должен быть способ проверки: метрика, сценарий или согласованный критерий приёмки. Механизм фиксации на этапе анализа — 02.04.02 Критерии приёмки (Acceptance Criteria); для НФТ особенно критично перевести «быстро» в измеримую форму (см. 08.02 Нефункциональные требования (НФТ) — классификация и стандарты). На этапе анализа достаточно зафиксировать как будем проверять, а не обязательно готовый тест-кейс.

2.2 Техники верификации (кратко)

Детали статического тестирования и формальных инспекций — в 08.03 Тестирование требований (статическое тестирование) и 08.04 Рецензирование и инспекции (техники Фейгана). В контексте V&V требований аналитик чаще всего применяет:

ТехникаЧто даёт в V&V
Peer review / walkthroughБыстрый отлов двусмысленностей и пробелов
Инспекция (Фейган)Формальный протокол дефектов перед baseline
Чек-лист качестваСистемный проход по атрибутам из 02.04.03 Управление качеством требований
Матрица трассировки (RTM)Полнота связей «цель → требование → способ проверки» (концепция: 02.03.04 Трассировка требований (концепция); шаблон: 10.01.15 Шаблон матрицы трассировки)
Сверка моделейНепротиворечивость Use Case и Activity Diagram, BPMN и data flow

Сверка моделей — зона совместной работы BA и SA: аналитик сверяет бизнес-модели (BPMN, use case) с текстом требований; технические диаграммы (sequence, ER) — обычно зона системного аналитика, но BA инициирует проверку и фиксирует найденные расхождения (см. 03.02.01 Диаграмма прецедентов (Use Case Diagram), 06.02.01 Потоки, шлюзы, события).

VUSP (Checklist for the Assessment and Verification of User Stories and Prototypes) — чек-лист из 28 утверждений для сверки user story и прототипа; полезен при работе в формате 04.02 Пользовательские истории (User Stories) и Job Stories и 02.03.03 Спецификация требований (SRS, Use Case, User Story).

На этапе анализа RTM проверяет, что на каждую бизнес-цель есть требования, а у каждого требования — трассировка и способ проверки. Правила атомарности формулировок — в 02.03.03 Спецификация требований (SRS, Use Case, User Story).

2.3 Что проверяет валидация требований

  • Соответствие бизнес-целям и KPI — решает ли требование исходную проблему?
  • Пригодность для пользователей — смогут ли и захотят ли работать с такой функциональностью?
  • Полнота с точки зрения потребности — не упущены ли «само собой разумные» сценарии?
  • Соответствие ожиданиям — совпадает ли описание с mental model стейкхолдера? (см. 01.07 Когнитивные искажения и критическое мышление — согласование легко подменяется confirmation bias)
  • Compliance — для регуляторных требований: покрывает ли формулировка обязательство и есть ли трассировка (см. 08.06 Юридические и регуляторные требования РФ (PCI-DSS))

2.4 Техники валидации требований

ТехникаКогда уместнаWiki
Прототип (throwaway)Нужно «увидеть», прежде чем согласовать текст02.02.04 Прототипирование и UI-UX-исследования
Воркшоп по спецификацииМного стейкхолдеров, нужен общий sign-off02.02.02 Воркшопы, фасилитация и совместные сессии
Согласование ACStory готова к sprint; фиксируем «что примем»02.04.02 Критерии приёмки (Acceptance Criteria)
Интервью / опрос с черновикомУточнение после elicitation: «правильно ли поняли?»02.02.01 Интервьюирование и анкетирование
Прогон use case со стейкхолдеромПроверка альтернативных потоков на реалистичность02.03.03 Спецификация требований (SRS, Use Case, User Story)

Прототип vs AC: прототип валидирует понимание и UX на ранней стадии, когда текст ещё сырой. AC валидируют конкретную поставку — что именно считаем выполненным. Оба — валидация требований, но на разных зрелости артефакта.

Demo, UAT, пилот и A/B — валидация продукта; они дополняют, но не заменяют согласование самого требования до разработки.

2.5 Валидация при отсутствии стейкхолдера и proxy-валидация

На практике бизнес-эксперт не всегда доступен на каждой сессии. Допустимые замены — с явной фиксацией риска:

СитуацияДопустимая заменаЧто зафиксироватьРиск
Agile-команда, PO в роли заказчикаPO валидирует от имени пользователейМандат PO, список делегированных решенийPO навязывает своё видение вместо пользовательского
Эксперт недоступенАсинхронное согласование черновика + дедлайнКанал, версия артефакта, срок ответа «молчание = согласие» или escalationЛожная валидация: формально «ОК», по факту не читали
Регуляторный доменЮрист / compliance-офицер как валидаторСсылка на норму, протокол согласованияФормулировка юридически верна, но неудобна в работе
Только demo как обратная связьВалидация отложена на UAT/demoСтатус «validated by proxy — pending business review»Перекладывание на приёмку; дорогие переделки

Validation by proxy — не отмена валидации, а временная замена с прозрачным статусом. Если proxy-валидация не подтверждена позже — требование возвращается в Draft. Карта стейкхолдеров помогает заранее понять, кто может валидировать и кто должен дать финальный sign-off (см. 02.01.03 Анализ заинтересованных сторон (Stakeholder Map)).

3. Как применяется в работе аналитика

3.1 Пример: одно требование, два типа проверки

Требование: «Система должна отправлять клиенту email с подтверждением заказа в течение 10 секунд после оплаты».

flowchart TD
    A["Требование:<br/>Email подтверждения<br/>за 10 сек после оплаты"]
    
    B["ВЕРИФИКАЦИЯ<br/>форма артефакта"]
    C["ВАЛИДАЦИЯ<br/>смысл и ценность"]
    
    B --> B1["Однозначно?"]
    B --> B2["Измеримо?"]
    B --> B3["Согласовано с другими?"]
    B --> B4["Есть ID и трассировка?"]
    
    C --> C1["Email или push?"]
    C --> C2["10 сек — достаточно?"]
    C --> C3["Покрывает цель<br/>'мгновенно информировать'?"]
    
    style A fill:#ffe6e6,stroke:#333,stroke-width:2px
    style B fill:#e6f3ff,stroke:#333,stroke-width:1px
    style C fill:#e6ffe6,stroke:#333,stroke-width:1px
  • Верификация: формулировка измерима, атомарна, не противоречит соседним требованиям (например, «только одно уведомление»), имеет ID.
  • Валидация: нужен ли email; достаточно ли 10 секунд для бизнес-цели; закрывает ли это KPI «информировать клиента сразу после оплаты».

Мини-кейс: возврат после demo. Story про email-уведомление прошла verify и proxy-валидацию через PO. На demo спринта заказчик: «Клиенты жалуются на спам — нужен push в приложении, не email». Требование возвращается в Draft: перезапускается валидация (интервью с поддержкой), затем verify обновлённой формулировки. Статус Validated снимается до нового sign-off.

3.2 Роли, ответственность и sign-off

V&V — не абстрактный процесс, а распределённая ответственность. На типовом проекте:

ДействиеКто выполняетКто утверждает (sign-off)
Первичная верификация (чек-лист, трассировка)Автор требования (BA)—
Peer review / walkthroughВторой BA, SA, иногда dev/testModerator фиксирует замечания
Формальная инспекцияНазначенный инспектор + командаModerator, протокол дефектов
Сверка моделей (техн.)SABA принимает решение по расхождениям в тексте
Валидация смыслаBA фасилитируетСтейкхолдер / PO / делегат
Quality Gateway (см. ниже)Владелец шлюза (обычно lead BA или RM)Пропуск / возврат на доработку
BaselinePM / RM по процессу проектаChange control после baseline

Sign-off — явное согласие валидатора: «это то, что нам нужно» (протокол встречи, комментарий в трекере, статус в ALM). Validated в 02.05.05 Жизненный цикл требования — статус артефакта после успешной валидации; sign-off — конкретное действие человека. Требование может быть Validated без формального sign-off на бумаге (Agile), но не наоборот: подпись без проверки смысла — ложная валидация.

3.3 V&V в жизненном цикле требования

Процесс итеративный и привязан к статусам (подробнее — 02.05.05 Жизненный цикл требования):

flowchart LR
    D["Draft"] --> R["Reviewed<br/>(verified)"]
    R --> V["Validated"]
    V --> G["Quality Gateway"]
    G --> B["Baselined"]
    B --> C["Changed"]
    C --> D
Статус / этапЧто произошлоКто ответственен
Draft → Reviewed (verified)Верификация: форма, трассировка, чек-листBA + peer review
Reviewed → ValidatedВалидация: согласование смысла, AC, sign-offBA фасилитирует, стейкхолдер утверждает
Validated → Gateway → BaselinedФинальный фильтр перед baselineВладелец Quality Gateway

Reviewed (verified) и Validated — два последовательных статуса: сначала форма, потом смысл. Quality Gateway — не третья проверка «с нуля», а формальный рубеж перед baseline: владелец шлюза (lead BA, requirements manager) подтверждает, что требование уже verified и validated, и только тогда включает его в baseline. Если на Gateway найден дефект формы — возврат в Reviewed; если проблема в смысле — в Validated или Draft.

Этап потокаДействие V&VТипичный результат
После elicitationПервичная валидация («мы правильно поняли?»)Уточнённые формулировки
При документированииВерификация по чек-листуVerified requirement
Peer review / инспекцияФормальная верификацияПротокол дефектов, статус Reviewed
Согласование со стейкхолдеромВалидацияValidated requirement, sign-off
Перед baselineQuality GatewayТребование в спецификации (Baselined)
Change requestПовторная V&V delta (см. 02.05.02 Управление изменениями (Change Control Board))Обновлённый статус

Quality Gateway (Сьюзан и Джеймс Робертсон) — формальный фильтр: каждое требование проходит проверку качества перед попаданием в baseline. Шлюз не заменяет verify и validate, а гарантирует, что оба пройдены; отклонённые требования возвращаются на доработку, не «заражая» спецификацию.

3.4 V&V в Agile

Definition of Ready (DoR) — смешанный шлюз; разведите критерии:

Критерий DoRТип проверки
Story имеет ID, трассировку к epic/целиVerify
AC сформулированы и измеримыVerify
Нет блокирующих зависимостейVerify
PO подтвердил ценность и приоритетValidate
Команда понимает scope и может оценитьValidate (понимание)

Definition of Done (DoD) — на стороне реализации; включает прохождение AC, что связано с валидацией инкремента, не заменяя валидацию формулировки story до разработки.

Shift-left — перенос verify/validate на этап требований, а не «проверим на UAT» (см. 05.01 Waterfall и V-model, 00.03 Жизненный цикл ПО и место аналитика (SDLC, STLC), 05.04 DevOps и непрерывная поставка — влияние на анализ — автоматические проверки спецификаций и контрактов в CI).

3.5 Конфликты, метрики и повторная V&V

Верификация выявляет несогласованность между требованиями; разрешение конфликта — отдельная работа: приоритизация (02.03.02 Приоритизация требований (MoSCoW, WSJF, Кано)), согласование зависимостей (02.05.01 Управление зависимостями между требованиями), change control (02.05.02 Управление изменениями (Change Control Board)). Триггер повторной V&V — не календарь, а новая версия артефакта: change request, delta после demo, уточнение scope.

Полезные метрики процесса (см. 08.01 Метрики и KPI процесса анализа): дефекты на ревью на 100 требований, доля требований, вернувшихся из Validated в Draft, время цикла verify→validate, повторная V&V после change request.

3.6 V&V и AI-компоненты (мост)

Классические определения V&V сохраняются и для систем с AI: меняются критерии приёмки и верифицируемость (oracle problem, drift). Детали — в 11.09 Мониторинг и оценка качества LLM-решений и 11.07 Практические кейсы применения LLM в анализе; LLM могут ассистировать статической верификации текста требований, но не снимают валидацию со стейкхолдеров.

4. Типовые ошибки и ограничения

  • Верификация без валидации — требования идеально оформлены, но решают не ту проблему.
  • Валидация без верификации — «все согласны», но внутри противоречия и разночтения.
  • Валидация «в кабинете» — аналитик решает за пользователя, без показа артефакта.
  • Proxy без мандата — PO или делегат валидирует без полномочий; формально Validated, фактически — риск.
  • UAT вместо валидации требований — «приняли на приёмке» трактуется как «требования были верными с самого начала».
  • Разовое V&V — одна проверка в начале; каждая новая версия требует повторного прохода.
  • AC как формальность — без согласованных критериев валидация сводится к «нравится / не нравится» (см. 02.04.02 Критерии приёмки (Acceptance Criteria)).
  • НФТ без verifiability — «удобный интерфейс» без метрик не проходит ни verify, ни validate осмысленно.
  • Gateway как второй verify — повторная проверка формы вместо подтверждения, что verify и validate уже пройдены.
  • Игнорирование compliance — регуляторное требование не трассировано к проверке (см. 08.06 Юридические и регуляторные требования РФ (PCI-DSS)).

Связи с другими разделами базы

До V&V (контекст и вход):

Во время V&V (инструменты и соседи):

После V&V (жизненный цикл и контроль):

Методологии и стандарты:

Источники и дополнительные материалы

Книги и стандарты

  • BABOK v3 — A Guide to the Business Analysis Body of Knowledge® (IIBA). Главы 7.4 Verify Requirements, 7.5 Validate Requirements. Glossary IIBA
  • Карл Вигерс, Джой Битти — «Разработка требований к программному обеспечению» (Software Requirements), 3-е изд., Microsoft Press, 2013. Гл. 15 «Валидация требований», гл. 17 «Верификация требований»
  • Сьюзан Робертсон, Джеймс Робертсон — «Mastering the Requirements Process», 2-е изд., Addison-Wesley, 2006. Гл. 11 «Quality Gateway»
  • Барри Бём — «Software Engineering Economics», Prentice Hall, 1981
  • Dean Leffingwell, Don Widrig — «Managing Software Requirements: A Use Case Approach», 2-е изд., Addison-Wesley, 2003
  • ISO/IEC/IEEE 29148:2018 — Systems and software engineering — Life cycle processes — Requirements engineering. IEEE catalog
  • IEEE Std 1012-2016 — IEEE Standard for System, Software, and Hardware Verification and Validation. IEEE catalog

Статьи