Подтверждение требований

Записаться

Здравствуйте, коллеги! Мы продолжаем изучать область знания Управление жизненным циклом требований и сейчас рассмотрим задачу 5.5 Подтверждение требований. Мы уже подробно рассмотрели все остальные четыре задачи этой области знания, связанные с трассировкой требований (установлением связи между требованиями и другими артефактами с компонентами решения), поддержанием требований в актуальности, в корректном состоянии, пригодными для повторного использования. Мы рассмотрели такую интересную задачу, как «приоритизация требований», когда у нас с вами много требований – какие бывают базисы (основы для приоритизации).

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

Задача 5.5, которой мы сегодня будем заниматься, посвящена подтверждению (утверждению) требований (по-английски это approve). Давайте посмотрим на назначение этой задачи. Суть в том, что необходимо получить одобрение для продолжения работы по бизнес-анализу или по разработке решения (получение согласия и утверждение требований дизайна для продолжения работ по бизнес-анализу). В этом состоит предназначение данной задачи.

Здесь есть некоторый момент, который необходимо учесть. С одной стороны, у нас есть валидация требований, которая свидетельствует, что данное требование приносит ценность. Если ценность даже привнесена – надо ли с этим требованием работать дальше? BABOK разделяет эти две вещи. Требование верифицированное, проверенное, корректное, непротиворечивое, полное, лаконичное, удовлетворяет нашим критериям качества. Оно валидировано – соответствует целям и задачам нашего проекта, приносит ценности. Но таких требований тоже может быть достаточно много. Есть еще третья задача в этом ряду – подтверждение требований (что с ними необходимо дальше работать).

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

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

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

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

Давайте посмотрим, как на практике происходит подтверждение требований. Я буду употреблять термин «утверждение». Во-первых, мы должны обязательно проговорить схему, порядок утверждения, потому что эта схема очень сильно отличается в разных компаниях. В каждой компании есть своя система принятия решений: кто, в какой последовательности, кто за кем это делает. Это не просто означает подтвердить требование у одной заинтересованной стороны. Скорее всего – это некоторое множество.

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

Необходимо четко понимать, кто за что отвечает. Это можно реализовать с помощью такого инструмента, как матрица ответственности (кто разрабатывает, кто согласовывает, кто информирует, кто отвечает).

Мы должны четко понимать, – что является результатом подтверждения. Очень часто в самом начале надо договориться – мы будем подписывать документ физически, или это некоторое письмо в электронной почте, или некоторые устные, высказанные на совещании и зафиксированные в протоколе слова «да, согласен» – что является результатом? Об этом тоже необходимо договориться, чтобы не возникло потом расхождений («Меня неправильно поняли, на самом деле требования не утверждены, ими еще необходимо заниматься»). Или есть такой анекдот: «Мы думали, что ТЗ – это не техническое задание, а точка зрения, а их у нас несколько».

Давайте посмотрим на то, кто участвует в задаче «Подтверждение требований»:

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

Рекомендуемые методы в задаче 5.5.

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

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

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

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

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

На этом по задаче 5.5 «Подтверждение требований» всё.

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

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

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

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