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

Записаться

Здравствуйте, коллеги!

Продолжаем с вами изучение области знаний по бизнес-анализу BABOK версии 3.0, который называется Управление жизненным циклом требований. Мы уже с вами подробно рассмотрели задачу 5.1 Трассировка требований, в которой я рассказывал о том, как важно устанавливать связь между требованиями и дизайнером решений и какими-то компонентами решения и так далее для того, чтобы обеспечить управление изменениями требований. Вот задача 5.2, она посвящена такой интересной теме, которая называется Поддержание требований. Давайте разберемся, что же такое «поддержание». По-английски «поддержание» - maintain я перевел как поддержание, хотя, в принципе, можно перевести по разному.

То есть это и:

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

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

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

В принципе исходя из формальной точки зрения эти задачи приоритезация, трассировка требований и поддержания на требования могут выполняться параллельно. При выполнении задачи 5.2 Поддержание требований, мы с вами используем подход к управлению информацией. Поскольку необходимо понимать то, как мы собственно храним требования, как мы управляем нашей информацией по бизнес-анализу. Что же является у нас с вами результатом выполнения данной задачи? Это требования дизайна, но уже с модификатором, который называется Поддержаный (Maintained). Есть это требование поддержание дизайна. Давайте посмотрим, что же, какие элементы BABOK рекомендует, на что обращать внимание при решении данной задачи.

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

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

Поддержание атрибутов требования (про этом мы с вами, наверное, ещё ни в задаче 5.1, ни в задачи 5.2 не говорили. Вообще, у требования существует достаточно много атрибутов. Требования могут быть такие, что система моделирования бизнес-процессов должна поддерживать нотацию BPMN 2.0.

Допустим вот такое требование, в принципе, обоснованно. Но у этого требования могут быть другие атрибуты:

• Автор требования, кто заявил требование;
• Когда оно заявлено;
• Приоритет этого требования;
• Сложности у требования;
• Трудозатраты на реализацию требований;
• Ответственный, который занимается данным требованием и так далее.

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

Соответственно само требование может и не поменяться. Нам необходимо, чтобы система так и продолжала нам обеспечивать возможность рисовать в BPMN, используя нотацию BPMN 2.0.

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

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

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

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

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

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

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

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

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

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

Итак, поддержание требований, скажем так, в целом, поддержание атрибутов и повторное использование требований - это три такие вещи, которыми надо заниматься при выполнении задачи 5.2 Поддержание требований.

Давайте посмотрим, какие заинтересованные стороны BABOK предлагает задействовать в данной задаче.

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

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

3. Операционная поддержка. Мы привлекаем для подтверждения.

4. Регулятор, возможно, при поддержании требования может высказать что-то соответствует или не соответствует стандартным. Соответственно, у нас какой-то требование может перестать быть актуальным. Его выводим из эксплуатации, предположим, или оставляем его в репозитории для последующего какого-то использования временно.

5. Тестировщик тоже может быть задействован в выполнении данной задачи.

Давайте посмотрим на те методы, которые BABOK рекомендует для использования при решении задачи 5.2 Поддержание требований:

1. Это анализ бизнес-правил.

2. Диаграмма потоков данных. Тоже такой интересный метод. Когда мы выявляем какие-то схожие потоки для поддержания актуальности и целостности требований.

3. Функциональная декомпозиция, когда мы проводим некоторое связывание компонента и требования.

4. Моделирование процессов, для поддержания соответствия между процессами требованиями.

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

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

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

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

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

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

Всего доброго, удачи, до свидания!