Описание статусов и атрибутов требования в соответствии с BABOK 3.0
Сегодня я предлагаю рассмотреть такую важную вещь, как статусы требований.
Начнём с определения термина «статус». Вот что говорит про статус Википедия:
Статус (лат. Status — состояние, положение) — абстрактное многозначное слово (термин), в общем смысле обозначающий совокупность стабильных значений параметров объекта или субъекта. С упрощённой точки зрения статус объекта или субъекта — это его состояние либо позиция, ранг в любой иерархии, структуре, системе, времени и ином.
В принципе, понятно что имеется ввиду, но интересует статус именно требования. Глоссарий BABOK 3.0 не содержит определения термина «статус требования», но в задаче по бизнес-анализу 3.4 «Планирование управления информацией по бизнес-анализу» приводится пример определения термина «статус требования» (здесь и далее синим шрифтом выделен переведенный на русский язык текст BABOK 3.0):
Статус (требования): указывает состояние требования, независимо от того, предлагается оно, принято, проверено, отложено, отменено или выполнено.
Вообще, в своде знаний уделяется значительное место обсуждению требований, в том числе их статусам, но, к сожалению, внятной и однозначной схемы статусов требований не приводится.
В подготовительных материалах к экзамену CBAP в соответствии с требованиями 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.ru@gmail.com