Область знания. Управление ЖЦ требований

Записаться

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

Сегодня мы приступаем к изучению области знаний, которая называется Управление жизненным циклом требований. Напомню, что в BABOK существует шесть областей знания, и две из них непосредственно связаны с требованиями: это – Управление жизненным циклом требований и Анализ требований и определение дизайна (Requirements Analysis and Design Definition).

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

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

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

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

Можем взять требования в качестве объекта, и проследить его жизненный цикл. И это является одним из важных вызовов для бизнес-аналитика - именно описать жизненный цикл требования (требование выявлено, специфицировано, обсуждено, верифицировано, валидировано, и так далее). BABOK предлагает свое видение этого жизненного цикла, которое можно проследить по всему своду знаний (если собрать все статусы и требования – проследить, как один статус превращается в другой и построить схему жизненного цикла). Но в реальности в каждой организации есть своя система, и у каждой крупной компании есть своя схема жизненного цикла. Как требования, или какой-то документ, который содержит требования, он переходит из одного состояния в другое, кто может это делать, и так далее.

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

Давайте посмотрим на те задачи, которые присутствуют в данной области знаний. Напомню, что каждая область знаний, коих в BABOK шесть, состоит (в среднем) из пяти задач по бизнес-анализу, общее количество — 30, среднее количество задач в одной области — 5. Эта область знания является средней, в ней именно пять задач по бизнес-анализу. Давайте разберемся, какие они.

Первая задача – это трассировка требований. Что такое трассировка? Трассировка (трассирование требований, «trace») – это установление каких-то связей между некоторыми сущностями, с которыми работает аналитик. Это могут быть не только требования. Мы можем с вами связать одно требование (функциональное) с другим функциональным требованием. И эта связь может быть разного свойства: если мы реализуем требование №1, то лучше будет реализовать и требование №2 – вместе мы достигнем большего эффекта. Это один тип связей. Или, например, другой, жесткий тип связей, когда мы не можем сделать требование №1 без реализации требования №2. Или, например, когда есть какое-то требование заинтересованной стороны (заинтересованного лица), и оно следует из какого-то более верхнеуровневого бизнес-требования, а, соответственно, функциональные требования следуют из требований заинтересованного лица, происходят от него. Таким образом, получается «цепочка». В общем, трассировка – это некое установление связей между сущностями. Не только с требованиями, мы можем сказать, что данное требование связано с неким компонентом решения, а этот некий компонент решения реализован в таком-то релизе, и так далее, вплоть до того, в каком модуле это требование реализовано. Можно сделать и такую трассировку.

Когда мы с вами будем обсуждать задачу 5.1, мы с вами будем подробно обсуждать типы связей, которые могут быть между требованиями и не только требованиями, о том, зачем это нужно. Например, что делать, если у вас поменялась заинтересованная сторона? Нужно поставить на пересмотр все требования, которые пошли от этой заинтересованной стороны. Допустим, у вас было зафиксировано 200 требований, а требований от этой заинтересованной стороны было 10. Соответственно, если меняется заинтересованная сторона, вы должны как минимум актуализировать или подтвердить необходимость этих требований. А ведь к этим требованиям заинтересованной стороны подвязаны функциональные требования, и, возможно, нефункциональные. Соответственно, это – целая цепочка. Без трассировки отследить это будет трудно, и это может привести к перерасходу трудозатрат – вы будете делать совершенно ненужную работу. Таким образом, трассировка может вам сильно облегчить жизнь, и об этом мы поговорим, когда будем обсуждать задачу 5.1.

Задача 5.2 – поддержание требований. По-английски перевод достаточно неоднозначен: «maintaining requirements», то есть это – и поддержание его в актуальном состоянии, и поддержание корректности требований, и подготовка требований для последующего повторного использования. Что это означает на практике? Представьте, что у вас несколько сотен требований, и вы (в репозитории где-то записаны, и между ними установлены трассировки, и так далее), и вы ещё так далее вливаете некоторое количество требований, и у вас нарушается целостность, например, какие-то требования противоречат друг с другом, или у вас нарушается какая-то логика в этих требованиях. Вот это называется «поддержание требований». На практике это некоторый регулярный процесс, регулярные процедуры. Об этом мы поговорим, когда будем обсуждать задачу 5.2 Поддержание требований.

Следующая задача, которую мы будем разбирать сегодня, в рамках обсуждения этой области знаний, это задача 5.3 Приоритизация требований, или ранжирование требований. В общем, это некоторое упорядочивание требований. Это одна из очень важных вещей, без которых не обходится ни один проект, ни одна активность по бизнес анализу, потому, что требований много, но какими заниматься в первую очередь? Какими можно заниматься позже, а какие можно вообще оставить на резерв, и если мы их вообще не сделаем, в принципе, ничего страшного не случится. Это всё про приоритизацию.

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

Задача 5.4 Оценка изменения требований. Каждый, кто участвовал в проектах, знает, что меняются и требования, и задачи, и заинтересованные стороны постоянно выдвигают что-то новое, меняется бизнес окружение, конкуренты не дают расслабиться, и так далее. В любом случае есть какие-то изменения требований и то, как подойти к оценке этих изменений. Есть некоторый запрос на оценку изменений. Мы поговорим о том, что надо обязательно фиксировать, на что нужно обращать внимание, когда есть некоторый запрос на изменение: кто автор, как влияет изменение на бюджет, сроки, трудозатраты, и тому подобное. Вот об этом мы поговорим в задаче «оценка изменения требований».

Следующая важная задача, которая содержится в этой области знания управления жизненным циклом требований – это «подтверждение требований». По-английски это «approve». Это можно перевести по-разному: это может быть и согласование, и утверждение, и одобрение. Соответственно, когда бизнес аналитик вырабатывает какой-то подход к бизнес анализу, один из самых важных пунктов, который он должен понять – это роли и полномочия заинтересованных сторон. И бизнес аналитик, и руководитель проекта – они должны четко понимать, кто уполномочен согласовывать, утверждать, в какие сроки это происходит, какова процедура, и так далее. Мы с вами все эти правила специфицировали в нашем подходе к управлению бизнес-анализом, или к управлению информацией по бизнес-анализу, в этом наборе методологических документов, которые разрабатывались в области знания «планирование и мониторинг бизнес-анализа» (где мы разрабатывали разные подходы). И одним из компонентов является определение того, как происходит это одобрение, утверждение, согласование – и так далее. Здесь, опираясь на этот подход, аналитик должен получить подтверждение требований – что с ними необходимо и можно работать в дальнейшем. На вход поступают верифицированные – корректные требования. В этой задаче по бизнес-анализу происходит, собственно говоря, подтверждение требований.

Таким образом, подводя итог: область знаний Управление жизненным циклом требований» Здесь мы уже не занимаемся специфицированием требований, они у нас уже в том или ином виде есть, здесь мы начинаем с ними жить. Они начинают «жить» и претерпевать какие-то определенные изменения. Добавляются новые требования, необходимо установить с ними связь – это и есть задача трассировки. Необходимо поддерживать актуальность существующих требований, допустим, привнесение новых – это поддержание требований. Требований много, и у нас постоянно что-то меняется, и необходимо всё время управлять приоритетами этих требований: что важнее, что надо поставить вперед, что можно сделать немного позднее. Это задача 5.3 Приоритизация требований. А задача 5.4 Оценка изменения требований - это когда у нас что-то меняется, нам необходимо переоценить требования с точки зрения времени, с точки зрения возможных сложностей, и так далее. Ну и, наконец, задача 5.5 – это Подтверждение требований, когда мы получаем некоторое формальное одобрение некой совокупности требований и возможность работать с ней дальше.

Таким образом, по области знания Управление жизненным циклом требований - всё. Всего доброго, до свидания.