...

Верификация и валидация требований: 2 задачи из BABOK®Guide

BABOK®Guide на русском, обучение бизнес-анализу, курсы BABOK, авторизованные курсы IIBA россия, обучение BABOK, курсы бизнес-аналитик, бизнес-аналитик обучение курс, разработка ТЗ курсы обучение, требования ТЗ обучение курс, как написать ТЗ курс обучение, спецификация требований в ТЗ и SRS пример курсы, управление ттребованиями, верификация требований, валидация требований, примеры для аналитика, Школа прикладного бизнес-анализа

Чем валидация отличается от верификации, как и когда аналитику выполнять эти проверки требований: рекомендации BABOK®Guide и полезные практики при разработке технического задания (ТЗ) на ПО или SRS.

Верификация требований

Верификация требований – это проверка, что их описание в виде спецификации (SRS) или ТЗ соответствуют отраслевым и организационным стандартам качества, а также пригодны для дальнейшего практического использования Последнее означает, что на основании составленных аналитиком требований ИТ-архитектор сможет выполнить архитектурный проект, разработчик – написать код, UI/UX-дизайнер – реализовать пользовательский интерфейс, а тестировщик – протестировать, как все это работает.

Самый простой и первый способ верифицировать требования – это проверить их на соответствие критериям качественного формулирования:

  • атомарность – в одном требовании изложено только одно требование;
  • полнота – достаточный уровень детализации;
  • согласованность – непротиворечивость с другими требованиями и прочей информацией бизнес-анализа, включая бизнес-правила;
  • краткость – отсутствие лишней информации в описании;
  • понятность – представление в терминах, ясных для стейкхолдеров и в соответствии с глоссарием проекта;
  • однозначность – возможность проверить, удовлетворяет ли решение исходную потребность;
  • реализуемость – осуществимость в рамках проектных ограничений (время и деньги) с приемлемым уровнем риска;
  • тестируемость – возможность проверить выполнение в конкретных количественных показателях, например, SLA 99,99% вместо высокой доступности;
  • приоритезируемость – возможность определить относительную важность и ценность с помощью методов приоритизации, о которых мы писали здесь и здесь.

Также к задаче верификации требований относится проверка правильности описания бизнес-процессов в формальных нотациях моделирования (IDEF0, BPMN, EPC или UML). Речь идет не только о корректном использовании алфавита нотации. Тут же выполняется проверка, насколько разумно использовать выбранные методы и инструменты с учетом дальнейшего применения этих диаграмм и способности стейкхолдеров их понимать.

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

Разработка ТЗ на информационную систему по ГОСТ и SRS

Код курса
TTIS
Ближайшая дата курса
2 декабря, 2024
Продолжительность
16 ак.часов
Стоимость обучения
36 000 руб.

Валидация требований

Валидация требований – это тоже проверка. Однако, в отличие от верификации, она направлена не на форму, а на содержание. Цель валидации требований – убедиться, что все требования стейкхолдеров и требования к решению соответствуют бизнес-требованиям и смогут удовлетворить бизнес-потребности. Этот непрерывный процесс включает следующие действия:

  • выявление предположений, что реализация требования поможет бизнесу и стейкхолдерам получить ожидаемую ценность. Сформулировав такие предположения, аналитик и стейкхолдеры подтверждают или опровергают их.
  • определение измеримых критериев оценки, целевых показателей и метрик, а также их значений, чтобы понять успех изменения после реализации решения, т.е. после перехода от текущего состояния (as is) к желаемому (as to be).
  • оценка соответствия границам и содержанию решения – входит ли требование в scope. Хотя требование может быть полезно конкретному стейкхолдеру, оно может противоречить бизнес-требованиям и/или выходить за рамки решения. В этом случае следует пересмотреть будущее состояние и изменить scope решения или исключить требование. Если вариант решения (дизайн) нельзя проверить на соответствие требованию, то оно отсутствует или неправильно понято. Также возможно, следует изменить сам дизайн.

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

Управление бизнес-анализом: курс для руководителей и ведущих аналитиков

Код курса
BAMP
Ближайшая дата курса
18 ноября, 2024
Продолжительность
8 ак.часов
Стоимость обучения
18 000 руб.

Как связаны верификация и валидация в BABOK®Guide

При том, что верификация и валидация являются проверками, это две разных задачи из одной области знаний BABOK®Guide «Анализ требований и определение дизайна» (Requirements Analysis and Design Definition). Они тесно связаны между собой и, в отличие от многих других задач из BABOK, имеют четкую временную последовательность: хотя валидацию требований можно начать до завершения верификации, но невозможно завершить до нее. BABOK отмечает, что в обеих задачах могут участвовать все категории стейкхолдеров.

В заключение отмечу простое и очень понятное определение, чем валидация отличается от верификации: верификация отвечает на вопрос «Правильно ли записаны требования?», а валидация – на вопрос «А правильные ли требования записаны?».

Чтобы проверить, как вы усвоили материал о работе с требованиями, предлагаю вам открытый интерактивный тест на знание стандартов разработки ТЗ и спецификации требований к ПО. А получить навыки спецификации требований в виде ТЗ и SRS, а также разобраться с управлением их жизненным циклом вам поможет мой авторский курс «Разработка ТЗ на информационную систему».

Проверить уровень своего знакомства с BABOK вы также можете, выполнив на нашем сайте бесплатные тесты по содержанию этого руководства к своду знаний по бизнес-анализу:

Чтобы детально разобраться с содержанием BABOK®Guide на практических примерах, приглашаю вас на курсы нашей Школы прикладного бизнес-анализа в лицензированном учебном центре обучения и повышения квалификации системных и бизнес-аналитиков в Москве:

 

Я даю свое согласие на обработку персональных данных и соглашаюсь с политикой конфиденциальности.

Добавить комментарий