Моделирование границ · Конспекты по бизнес-анализу

Что это#

Руководство BABOK® рассматривает модели границ (scope models) как основу, чтобы очертить работу по бизнес-анализу и проект. Границы — это никогда не просто список функций. В них входит и то, что вы сознательно оставляете за рамками, и стороны, с которыми решение имеет дело.

Учебные материалы по бизнес-анализу перечисляют обычные формы:

Контекстная диаграмма (context diagram): диаграмма потоков данных верхнего уровня. Всё решение изображено одним процессом; вокруг него — внешние сущности, с которыми оно обменивается данными.
События: то, на что решение должно реагировать. Внешние события приходят извне (запрос клиента, сообщение от партнёра). Временные события наступают по времени (ежемесячная уплата налогов). Для каждого события спросите, какой процесс нужен, чтобы полностью его обработать.
Функции (features): услуги решения, которые удовлетворяют одну или несколько потребностей заинтересованных сторон. Функции формулируются на высоком уровне и позже детализируются в функциональные и нефункциональные требования. Они удобны для ранней приоритизации.
Диаграмма вариантов использования: варианты использования, связи между ними и действующие лица, которые с ними взаимодействуют.
Модель бизнес-процесса: показывает, где в работе решение начинается и где заканчивается.

Вигерс и Битти дают практические советы. Выберите одно представление, а не рисуйте все сразу. Контекстная диаграмма показывает систему одним кругом, внешние сущности — прямоугольниками, потоки — стрелками и намеренно скрывает то, что внутри. Отсутствие тоже несёт информацию: сущность, которой нет на диаграмме, — та, с которой система не имеет дела. Когда системы связаны косвенно, через общие данные, более широкую картину показывает карта экосистемы (ecosystem map). Ещё они советуют явно перечислять ограничения и исключения, чтобы один и тот же спор не возобновлялся каждый месяц.

Леффингуэлл и Уидриг делают определение границы шагом анализа проблемы: разделите мир на систему и то, что с ней взаимодействует. Всё внешнее, что взаимодействует с системой, — действующее лицо (actor), и поиск действующих лиц — ключевой шаг анализа.

Когда применять#

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

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

Как это делать#

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

Пример#

«Мастерская», вымышленная сеть веломастерских, определяет границы релиза 1 своей системы обслуживания клиентов. Контекстная диаграмма в виде таблицы:

Внешняя сущность	В систему	Из системы
Клиент	Запрос на бронь, отмена	Подтверждение брони, сообщения о статусе
Сотрудники стойки приёма	Записи клиентов, пришедших без брони, приём велосипедов	Расписание на день
Механик	Обновления статуса, израсходованные запчасти	Список заказов
Управляющий мастерской	Утверждения заказов запчастей	Отчёты об остатках и опозданиях
Поставщик запчастей	Подтверждения поставки	Заказы запчастей
Провайдер рассылок	Отчёты о доставке	SMS и электронные письма

Внешняя сущность
Система обслуживания клиентов (релиз 1)

Рис. 1. Контекстная диаграмма релиза 1, построенная по таблице выше. Бухгалтерской системы на ней нет намеренно. Нотация: контекстная диаграмма (потоки данных в систему и из неё)

Показать текстом

На диаграмме те же потоки, что в таблице выше: что каждая внешняя сущность отправляет в систему и что получает из неё.

Список событий:

Событие	Тип	Требуемая реакция
Клиент запрашивает время	Внешнее	Предложить свободное время, подтвердить бронь
Механик завершает ремонт	Внешнее	Сообщить клиенту, что велосипед готов
Поставщик подтверждает дату поставки	Внешнее	Обновить ожидаемую дату завершения
Конец каждого рабочего дня	Временное	Отправить напоминания о завтрашних записях
Первый день месяца	Временное	Сформировать отчёт о расходе запчастей

Граница релиза 1:

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

Бухгалтерской системы на диаграмме нет намеренно. Владелец подтвердил, что выставление счетов остаётся в существующем инструменте, и это закрыло вопрос, который поднимался на каждой встрече.

Частые ошибки#

Внутреннее устройство на контекстной диаграмме → оставьте в центре один процесс; детали — в других моделях.
Нет списка того, что за границами → записывайте исключения, как советуют Вигерс и Битти.
Смешение уровней → разделяйте концепцию продукта, границы проекта и границы релиза.
Забытые временные события → спросите, что должно происходить в определённое время каждый день, месяц или год.
Модель границ вместо спецификации → это рамка, а не детали.
Все нотации сразу → выберите ту, которую ваши заинтересованные стороны читают легче всего.
Моделирование границ в одиночку → граница, которую не согласовали заинтересованные стороны, — не граница.

Шаблон#

Шаблон

Границы чего: <работы по бизнес-анализу / решение / релиз>
Цель: <одно предложение>

| Внешняя сущность | В систему | Из системы |
|---|---|---|

| Событие | Внешнее / временное | Требуемая реакция |
|---|---|---|

Входит в границы: <функция>, <функция>
Позже: <функция>
За границами: <элемент> (причина: <почему>)
Допущения и ограничения: <список>
Согласовали: <роли>, <дата>

Чек-лист#

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

Источники и что почитать#

IIBA. A Guide to the Business Analysis Body of Knowledge (BABOK® Guide), version 3. International Institute of Business Analysis, 2015. Рус. изд.: Руководство к своду знаний по бизнес-анализу (Руководство BABOK®), версия 3.0. Техника 10.41 «Моделирование границ».
Учебные материалы по бизнес-анализу, модуль «Управление жизненным циклом требований» (формы моделей границ).
K. Wiegers, J. Beatty. Software Requirements, 3rd ed. Microsoft Press, 2013. Рус. изд.: К. Вигерс, Дж. Битти. Разработка требований к программному обеспечению, 3-е изд. М.: Русская редакция; СПб.: БХВ-Петербург, 2014. Гл. 5 (контекстная диаграмма, карта экосистемы, ограничения и исключения).
D. Leffingwell, D. Widrig. Managing Software Requirements: A Unified Approach. Addison-Wesley, 2000. Рус. изд.: Д. Леффингуэлл, Д. Уидриг. Принципы работы с требованиями к программному обеспечению. Унифицированный подход. М.: Вильямс, 2002 (анализ проблемы: граница системы и действующие лица).