Трассировка требований

Записаться

Здравствуйте, коллеги! Продолжаем с вами изучать область знания по бизнес анализу – BABOK версии 3.0 Управление жизненным циклом требований. На этом занятии мы с вами разберем первую задачу из этой области знания, которая называется Трассировка требования (по-английски «trace requirements»). Это задача 5.1.

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

В чем же состоит, собственно говоря, сам термин «трассировка»? Давайте посмотрим, какое определение дает стандарт BABOK. Трассировка - это возможность отслеживания взаимосвязи между наборами требований и дизайнами от потребности до фактического реализованного решения. Трассировка поддерживает управление изменениями, гарантируя, что источник требования или дизайна может быть определен, и другие связанные требования или проекты, которые потенциально затронуты изменением, известны. То есть, необходимость поддерживать управление изменениями является одним из таких достаточно убедительных доказательств того, что трассировка необходима. На практике, конечно же, это требует времени. Надо об этом совершенно честно сказать, что трассировка и поддержание трассировки в актуальном состоянии требует времени и ресурсов (человеческих и материальных). Поэтому, на практике часто трассируют не всё: трассируют только какие-то определенные виды связи, или только критичные требования, и так далее. Необходимо на этапе определения подходов к бизнес анализу (когда бизнес-аналитик определяется, с какими типами требования он будет работать, с какими атрибутами, какие типы трассировки, какова область трассирования). Поэтому, возможно трассировать не всё, но что-то трассировать необходимо обязательно.

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

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

Я сказал про инструменты - в частности, есть инструменты управления требованиями «репозитории» - это тоже является одним из руководств, необходимых вещей, которые необходимы для того, чтобы осуществлять вот эту трассировку. Инструмент управления требования, или система управления требованиями - многие они уже содержат в себе возможности установления трассировки между различными типами требований (между бизнес требованиями и требованиями заинтересованных сторон, между требованиями заинтересованных сторон и функциональными требованиями, между одним функциональным требованием и другими функциональными требованиями, и так далее). Репозиторий, безусловно, важен. Таким образом, у нас есть требования дизайна и знания бизнес домена, подход к информации, высока вероятность того, что трассировку мы сможем сделать.

Результатом выполнения задачи 5.1 являются трассированые дизайны и требования. Давайте посмотрим, из каких элементов состоит данная задача. Здесь уже есть определенные подробности, которые подсказывают нам, какие бывают виды трассировок. Какие-то виды трассировок я вам уже рассказал, но сейчас мы попробуем их еще подробнее разобрать. Итак, самая простая трассировка – это, наверное, что одно требование происходит из другого - то есть связано с ним, является его детализацией. Например, требования заинтересованной стороны - производное от какого-то бизнес требования. У нас есть какое-то бизнес требование, и требование заинтересованной стороны находится в рамках вот этого бизнес требования. Оно является его средством. Для того, чтобы выполнить это бизнес требование, необходимо выполнить вот это требование заинтересованной стороны. В идеале, если мы выполним все требования заинтересованных сторон, которые вытекают или происходят от этого бизнес требования, бизнес требование будет тоже удовлетворено. Надо стремиться к этому.

Есть еще требования в виде зависимости: когда одно требование зависит от другого. И эта зависимость бывает двух сортов: когда для одного требования необходима реализация также и другого требования (жесткая сцепка), когда не имеет смысла реализовывать требования №1, если не реализовано требование №2. И, наоборот, то есть их либо все, либо ничего, либо вместе, либо никак.

Есть более мягкая связь, когда реализация одного требования усиливает реализацию второго требования. Лучше их делать как-то вместе, и «кумулятивный» эффект, то есть сумма слагаемых больше, чем они по отдельности (по каким-то параметрам) может, просто по удовлетворенности пользователей. Если мы сделаем не один какой-то элемент дизайна, а сразу все вместе, это будет больший эффект, чем мы будем делать их поодиночке. «Происходит от…» зависит, и следующий уровень отношений, который может быть, это – «удовлетворяет» (что этот компонент решения удовлетворяет вот этим функциональным требованием).

Наверняка, вы слышали подобное выражение,что данные функциональные требования реализуются вот этим компонентом решения, или что какой-то компонент решения удовлетворяет вот этому функциональному требованию. То есть это - такие взаимоотношения уже не только между «требованиями-требованиями», а уже между какими-то компонентами решения и требованиями. И, возможно, еще одна связь - это «подтверждает». Например, у нас test-case подтверждает выполнение или реализацию удовлетворения требования.

Такие виды трассировок явно прописаны в своде знаний по бизнес анализу BABOK 3.0.

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

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

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

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

Какие заинтересованные стороны? Достаточно много заинтересованных сторон, все они так или иначе заинтересованы в трассировке. Тестировщику необходимо понимание связей между требованиями для тестирования, для составления тест кейсов. Поставщику необходимо тоже понимать, чтобы своевременно поставлять какие-то компоненты решения. Спонсору необходимо подтвердить, что все так оно и есть. Руководителю проекта, возможно, установление трассировки поменяет какую-то последовательность работы или изменит объем проекта. И так далее. То есть, каждый вид/тип заинтересованной стороны так или иначе включен задачу трассировки требований.

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

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

На этом по задаче 5.1 Трассировка требований - всё. Всего доброго, до свидания.