Анализ интерфейсов · Конспекты по бизнес-анализу

Что это#

Интерфейс — это связь между двумя компонентами, которая позволяет им обмениваться информацией. Руководство BABOK® описывает анализ интерфейсов как проработку деталей информации, которой обмениваются компоненты решения или которая пересекает его границу. Анализ проясняет границы системы и даёт контекст для выявления более детальных требований заинтересованных сторон, чтобы решение покрывало всё, что ему нужно.

Список типов интерфейсов в Руководстве BABOK шире, чем «интеграции систем»:

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

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

Техника применяется широко. В опросе бизнес-аналитиков Украины 2020 года Гобов и Гученко (Gobov, Huchenko) обнаружили, что анализ интерфейсов входит в число самых распространённых техник выявления (elicitation), уступая только интервью и анализу документов.

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

Руководство BABOK применяет технику в задачах «Проведение выявления», «Оценка изменений требований» (поиск интерфейсов, которые затрагивает изменение) и «Спецификация и моделирование требований» (определение и валидация входов и выходов решения). Применяйте её, когда:

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

Сильные стороны техники: она рано выявляет функциональные требования, помогает распределить требования по решению и удерживает анализ на том, что пересекает границу, а не на всём, что внутри. Её ограничение — тот же фокус: о внутреннем устройстве решения она говорит мало. Сочетайте её с моделями процессов, данных и вариантов использования.

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

Проведите границу. Начните с контекстной диаграммы или модели границ и перечислите все внешние стороны.
Найдите интерфейсы по типам: пользователи, внешние люди, процессы, системы, API, устройства. Спросите каждую заинтересованную сторону: «Что вы отправляете, получаете или просматриваете?»
Назначьте ответственных с обеих сторон каждого интерфейса.
Опишите каждый интерфейс: назначение, направление, триггер и частота, содержание (со ссылкой на словарь данных), объём, формат или канал, правила проверки, обработка ошибок, безопасность и уровни сервиса.
Проверьте содержание, проведя реальный случай через интерфейс от начала до конца.
Зафиксируйте зависимости и риски: что, если другая сторона недоступна, опаздывает или меняет формат?
Согласуйте описания с ответственными с обеих сторон, утвердите их базовую версию и держите под управлением изменениями.
Используйте перечень повторно для анализа влияния при каждом новом запросе на изменение.

Пример#

«Мастерская» (вымышленная сеть веломастерских) перечисляет интерфейсы планируемой системы записи и ремонта:

ID	Интерфейс	Тип	Направление	Содержание	Триггер / частота	Ответственный (другая сторона)	Открытые вопросы
`I-01`	Страницы онлайн-записи	Пользовательский интерфейс	От клиента к системе	Запрос на бронь	По запросу	Владелец продукта	Сначала мобильная версия?
`I-02`	Шлюз сообщений	Система	От системы к клиенту	Подтверждение брони, сообщения о статусе	При смене статуса	Сервис рассылки сообщений	Отчёты о доставке? Стоимость одного сообщения?
`I-03`	Заказ у поставщика запчастей	Система или процесс	В обе стороны	Заказ запчастей, накладная	Ежедневно до крайнего срока приёма заказов у поставщика	Поставщик запчастей	API, файл или портал?
`I-04`	Планшет в мастерской	Пользовательский интерфейс	От механика к системе	Ход ремонта, нужные запчасти	Во время ремонта	Управляющие мастерскими	Работает без сети?
`I-05`	Платёжный терминал	Устройство	В обе стороны	Сумма платежа, результат	При выдаче	Платёжный провайдер	Нужна интеграция или хватит ручного ввода?
`I-06`	Выгрузка в бухгалтерию	Интерфейс данных	От системы в бухгалтерию	Сводка продаж за день	Каждую ночь	Бухгалтер	Формат и время закрытия дня

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

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

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

Чек-лист#

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

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

IIBA. A Guide to the Business Analysis Body of Knowledge (BABOK® Guide), version 3. International Institute of Business Analysis, 2015. Рус. изд.: Руководство к своду знаний по бизнес-анализу (Руководство BABOK®), версия 3.0. Техника 10.24 «Анализ интерфейсов».
Watermark Learning. BABOK v3 Study Tables. 2016 (учебное пособие к Руководству BABOK). Техника 10.24.
D. Gobov, I. Huchenko. State of Business Analysis in Ukraine 2020. DataArt, 2020.