Описание статусов и атрибутов требования в соответствии с BABOK 3.0

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

Начнём с определения термина «статус». Вот что говорит про статус Википедия:

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

В принципе, понятно что имеется ввиду, но интересует статус именно требования. Глоссарий BABOK 3.0 не содержит определения термина «статус требования», но в задаче по бизнес-анализу 3.4 «Планирование управления информацией по бизнес-анализу» приводится пример определения термина «статус требования» (здесь и далее синим шрифтом выделен переведенный на русский язык текст BABOK 3.0):

Статус (требования): указывает состояние требования, независимо от того, предлагается оно, принято, проверено, отложено, отменено или выполнено.

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

В подготовительных материалах к экзамену CBAP в соответствии с требованиями BABOK 2.0 содержалась вот такая схема статусов требований:

Статусы требований BABOK 2.0

С выходом новой версии BABOK 3.0 данная схема потеряла свою актуальность и чтобы понять новую систему статусов (и атрибутов) требования, которую предлагает BABOK 3.0, придётся проштудировать весь свод знаний, и особенно области знаний «Описание анализа требований и дизайна» и «Управление жизненным циклом требований».

Специфицировано и смоделировано

И специфицировано, и смоделировано (specified and modelled). Да, да, именно так. Практически два статуса в одном.

Специфицированные и смоделированные требования получаются в результате выполнения задачи по бизнес-анализу 7.1 «Спецификация и моделирование требований», входом для которой являются любые результаты выявления (elicatation), а выходом — любая комбинация требований и\или дизайна требований в форме текста, матриц и диаграмм. Свод знаний весьма широко трактует «результаты выявления» – фактически это может быть любая информация, полученная аналитиком. С точки зрения жизненного цикла требования – это, фактически, рождение требования.

Однако, в своде знаний содержится и некоторая непоследовательность. В глоссарии приводится ещё один статус требования, который должен был бы находиться ещё раньше по жизненному циклу:

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

Очевидно, что заявленное требование появляется раньше, чем специфицированное\смоделированное. Но, в BABOK 3.0 нет задачи, входом или выходом которой является требование с пометкой «заявленное».

Верифицировано (проверено)

После того, как требование специфицировано, его надо проверить (верифицировать). Про верифицированное требование глоссарий BABOK утверждает следующее:

Верифицированное (verified) требование: требование, которое было рассмотрено и определено как правильное, соответствует стандартам или руководящим принципам и находится на приемлемом уровне детализации.

Верифицированные требования получаются в результате выполнения задачи по бизнес-анализу 7.2 «Верификация требований», входом для которой являются специфицированные и смоделированные требования (результаты задачи 7.1).

Валидировано (подтверждено)

После того, как требование проверено на корректность\правильность, его надо подтвердить. Про валидированное требование глоссарий BABOK говорит следующее:

Подтвержденное (validated) требование: требование, которое было рассмотрено и определено для поддержки предоставления ожидаемых выгод и находится в пределах скоупа (области решения).

 

Валидированные требования получаются в результате выполнения задачи по бизнес-анализу 7.3 «Валидация требований», входом для которой являются верифицированные требования (результаты задачи 7.2).

Утверждено (approved)

 Утверждению требований в BABOK 3.0 посвящена отдельная задача по бизнес-анализу 5.5 «Утверждение требований». И в этом вопросе BABOK однозначен – утверждено может быть только проверенное (verified) требование.


Промежуточный итог

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

  • Специфицировано и смоделировано (specified and modelled)
  • Верифицировано (verified)
  • Валидировано (validated)
  • Утверждено (approved)

 Переход между этими статусами чётко определён в BABOK, получается небольшая, но вполне логичная схема. Кому-то может и её хватить для работы. Но давайте посмотрим, какие ещё состояния требования описывает BABOK.

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


Приоритет

Входом для задачи по бизнес-анализу 5.3 «Приоритизация требований» являются любые требования в виде текста, матриц или диаграмм, готовые к приоритезации. Но является ли «приоритет» требования статусом или же это отдельный, самостоятельный атрибут?

Ответ на это можно найти в описании задачи по бизнес-анализу 3.4 «Планирование управления информацией по бизнес-анализу». На странице 45 приведен примерный перечень атрибутов требования:

  • автор
  • уровень сложности
  • источник
  • стабильность
  • приоритет
  • статус
  • и т.д.

 

Таким образом, согласно BABOK, приоритет требования – это отдельный от статуса атрибут требования. Приоритет можно присвоить требованию с любым статусом, главное, чтобы оно было готово для приоритезации. Подтверждением того, что приоритет является самостоятельным атрибутом, согласно BABOK 3.0 является то, что одним из входов задачи по бизнес-анализу 7.5 «Определение параметров дизайна» (Define Design Options) являются подтвержденные (validated) и проиритизированные (prioritiezed) требования.

Трассировано

Что же такое – «трассировка требований»? BABOK утверждает следующее:

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

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

 

В общем, практически все результаты бизнес-анализа могут быть трассированы. Трассировке требований посвящена отдельная задача по бизнес-анализу 5.1  «Трассировка требований».

 

Аллоцировано (распределено)

В BABOK 3.0 появилась новая задача по бизнес-анализу 7.5 «Определение параметров дизайна» (Define Design Options), которая вобрала в себя несколько задач, существовавших в BABOK 2.0, в том числе задачу 7.2 «Аллокация требований» (Allocate Requirements).

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

Глоссарий BABOK содержит следующее определение аллокации:

Распределение (allocation) требований: процесс назначения требований, которые должны быть реализованы конкретными компонентами решения.

Однако ни на входе, ни на выходе какой-либо задачи по бизнес-анализу нет требований с пометкой «аллоцировано» (allocated).

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

 

Поддержано в актуальности (maintained)

Ввиду отсутствия официального перевода BABOK на русский язык, я перевёл термин maintained как «поддержано в актуальности». Вот как раскрывает содержание термина свод знаний:

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

Результатом выполнения задачи 5.2 «Поддержка требований в актуальности» по бизнес-анализу являются требования, которые:

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


Прожуточный итог

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

  • Приоритезировано (prioritiezed)
  • Трассировано (traced)
  • Поддержано в актальности (maintained)
  • Аллоцировано (allocated)

 


 

Выводы

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

  • Специфицировано и смоделировано (specified and modelled)
  • Верифицировано (verified)
  • Валидировано (validated)
  • Утверждено (approved)

Помимо статусов, свод знаний содержит набор важных атрибутов требования, связанных со статусами:

  • Приоритезировано (prioritiezed)
  • Трассировано (traced)
  • Поддержано в актальности (maintained)
  • Аллоцировано (allocated)

Можно, конечно, воплотить приведенную схему статусов и атрибутов требования «как есть» и работать по ней, но лучше будет всё-таки адаптировать схему под нужды вашей организации.

Успехов в бизнес-анализе в общем, и в управлении требованиями в частности!

P.S. Если Вас интересуют темы управления требованиями, бизнес-анализа или BABOK, Вы всегда можете заказать у меня корпоративный тренинг. Пишите автору: olegburko@outlook.com

 

Статусы и атрибуты требования в BABOK 3.0
Яндекс.Метрика Рейтинг@Mail.ru