В 2011 году я узнал о существовании книги «A Guide to the Business Analysis Body of Knowledge. V2”, в простонародье - BABOK. Я тщательно изучил ее, сдал экзамен, начал проводить BABOK Study Group и тренинги. Я все лучше и лучше понимал заложенные в ней принципы, задачи, техники. А главное – терминологию. В 2015г. меня постиг сильный удар – вышла новая 3-я версия BABOK. А значит нужно было понять и принять новый взгляд на бизнес-анализ. Нельзя сказать, что поменялось все, но, когда термины и задачи бизнес-аналитика впечатаны в память, переучивание требует некоторого времени. Сегодня я веду тренинги по BABOK v.3 и хотел бы прояснить некоторые термины, с которыми часто возникает путаница или недопонимание.
Первая часть будет посвященная терминам: требование, дизайн, бизнес-аналитическая информация и архитектура требований.
Требование
Одно из ключевых изменений в BABOK v.3 – переосмысление термина «требования». Во второй версии использовалось определение из стандарта IEEE 610.12−1990:
«Требование это:
Условие или возможность, необходимые заинтересованному лицу для решения проблемы или достижения цели.
Подлежащее выполнению условие или способность, которыми должно обладать решение или его компонент для соответствия контракту, стандарту, спецификации или другому формальному документу.
Документированное представление условия или возможности в соответствии с п.п. 1 или 2.»
В третьей версии авторы пришли к более изящному и краткому определению: «Требование — это пригодное для использования представление потребности. Требования сосредоточены на понимании того, какая ценность может быть получена в результате выполнения требования». Проще говоря, требование отвечает на вопросы «для чего/зачем?» и «что?». И тут нельзя не согласиться – потребности у заинтересованных лиц существует в реальности, а требование – лишь попытка их описать/зафиксировать.
Дизайн
Новый термин в BABOK v.3 – Дизайн. И речь идет не только о пользовательском интерфейсе. Определение звучит так: «Дизайн — это пригодное для использования представление решения. Дизайн фокусируется на понимании того, каким образом решение сможет приносить пользу если будет реализовано». Другими словами, дизайн – ответ на вопрос «как должна/может быть удовлетворена потребность?» или коротко – «как?».
Из этого можно сделать вывод, что они идут в паре. Если мы не ответим на вопрос «как?», то не сможем определить решение. Если мы будем создавать решение без ответа на вопросы «для чего?» и «что», то сделаем не то, что нужно нашим заинтересованным лицам.
Граница между требованиями и дизайном
При этом отмечается, что граница между этими двумя терминами зачастую размытая. Чуть позже я продемонстрирую это.
В BABOK v.3 вы можете найти примеры требований и дизайна:
Требование: Видеть данные о продажах за шесть месяцев по нескольким подразделениям в одном представлении.
Дизайн: прототип дашборда с информацией о продажах.
Требование: Сократить время обработки сообщения о проблеме от клиента
Дизайн: модель нового бизнес-процесса, обеспечивающего сокращение времени обработки
Требование: Решение должно поддерживать мультиязычность (украинский, русский и английский язык).
Дизайн: Прототип с экранными формами на всех требуемых языках.
Примеры достаточно наглядные. Но вернемся к первому из них. Посмотрим внимательнее на требование «Видеть данные о продажах за шесть месяцев по нескольким подразделениям в одном представлении». И зададим излюбленный вопрос бизнес-аналитиков – «Зачем?». Ответы могут быть разными. Один из вариантов: «Чтобы следить за выполнением планов подразделениями и распределять премии». И тут оказывается, что высказывание «Видеть данные о продажах …» - это не требование, а дизайн. Это ответ на вопрос «как мы хотим следить за выполнением планов подразделениями». Это и был обещанный пример нечеткой границы между требованиями и дизайном.
Бизнес-аналитическая информация
Перейдем к третьему термину «бизнес-аналитическая информация». Казалось бы, если у нас есть требования и дизайн, то что еще нужно. Бизнес-аналитик выявляет, документирует, моделирует требования и дизайн. Но если задуматься, то кроме требований и дизайна есть еще и промежуточные результаты работы бизнес-аналитика – заметки с семинаров по требованиям, вопросы и ответы с интервью, предположения, риски и т.д.
В BABOK есть два таких вспомогательных термина описывающие результаты работы бизнес-аналитика: рабочий продукт (work product) и продукт/объект поставки (deliverable).
Рабочий продукт – это документ, либо набор записей или диаграмм, используемых бизнес-аналитиком в процессе разработки требований. То есть это промежуточные результаты работы бизнес-аналитика.
Продукт/объект поставки - любой уникальный и проверяемый рабочий продукт или услуга, которые сторона обязалась поставить. В случае бизнес-аналитика – это документ, который он обязался подготовить: спецификация требований, прототип, словарь данных и т.д.
Термин «бизнес-аналитическая информация» включает в себя не только информацию, являющуюся результатом бизнес-анализа (рабочие продукты и продукты/объекты поставки), но и исходную информацию, которая поступает на вход бизнес-анализа. То есть, бизнес-аналитическая информация – это вся та информация, которой оперирует бизнес-аналитик.
Архитектура требований
И вишенка на торте – термин «Архитектура требований».
Для того, чтобы лучше его понять, нам придется рассмотреть еще 2 понятия: точка зрения и представление требований (далее – представление).
Требования мы всегда готовим для кого-то. Т.е. нам важно понимать какую информацию, на каком уровне детализации и для кого мы готовим. Точка зрения — это набор соглашений, определяющих какую информацию нам нужно предоставить некоторой группе заинтересованных лиц. В рамках точки зрения мы определяем: какие модели и с использованием каких нотаций нужно создать, какие атрибуты указать, какие отношения зафиксировать. Если мы возьмем, например, шаблоны документов RUP (Rational Unified Process) или 34 ГОСТ, то обнаружим, что они определяют некоторый набор этих точек зрения.
Когда мы возьмем имеющиеся у нас требования и дизайн и оформим их в соответствии с соглашением (некоторой точкой зрения), то получим представление.
Набор всех представлений - это архитектура требований.
Это можно записать в виде формул:
Набор соглашений + группа заинтересованных лиц=Точка зрения
Точка зрения + требования = Представление
Представление 1 + … + Представление N = Архитектура требований
Пример: Мы договорились с заинтересованными лицами на проекте, что нам нужны:
Точка зрения №1 – Информация для спонсора: шаблон с секцией для высокоуровневых бизнес-требования, секцией для высокоуровневых функциональных и нефункциональных требований, шаблон для описания бизнес-процессов и выбранная нотация.
Точка зрения №2 – Информация для разработчиков и тестировщиков: шаблон с секциями для детальных функциональных и нефункциональных требований
Точка зрения №3 – Информация для разработчиков баз данных: шаблоны словарей данных, шаблоны моделей данных
Оформив имеющиеся у нас требования в соответствии с этими точками зрения мы получим набор представлений, которые в совокупности являются архитектурой требований. Это может быть один документ с разделами или это могут быть отдельные документы, но рассматриваем мы их в совокупности.
Детальнее с этими и другими терминами из BABOK, задачами и техниками бизнес-анализа вы можете познакомиться на нашем "Комплексном онлайн тренинги по бизнес-анализу". Тренинг также позволит вам на практике разобрать ряд ключевых техник в рамках выполнения учебного проекта. Тренинг одобрен IIBA и дает участникам 35 PD hours (35 часов профессионального развития).
Спасибо большое за статью, очень нагладно получилось. Мне почему-то хочется добавить к понятию 'архитектура' связи между элементами представлений (трассирование, принаджежность типу или некоторой общности итд). Не знаю, насколько это методологически верно