Требования в проектах бизнес-аналитики (BI)
Коротко Системы бизнес-аналитики (business intelligence, BI) и аналитические системы превращают большие объёмы данных в информацию для принятия решений. Вигерс и Битти советуют выявлять требования к ним, отталкиваясь от решений, которые людям нужно принимать, а не от отчётов или полей данных, которые люди просят.
По материалам: К. Вигерс, Дж. Битти, «Разработка требований к программному обеспечению», 3-е изд., гл. 25.
На этой странице
Главные идеи#
Чем отличаются такие проекты#
- Отдельных функций, которые нужно приоритизировать, мало; ценность — в более качественных решениях.
- Пользователи часто не могут заранее сказать, что им нужно, особенно если никогда не видели аналитики сложнее электронных таблиц. Когда возможности открываются небольшими порциями, пользователи постепенно понимают свои потребности, поэтому таким проектам подходит инкрементная поставка.
- Каждый ответ порождает новые вопросы, поэтому система постоянно развивается.
Три связанных компонента#
Авторы описывают аналитику как три части, каждая из которых может вести к другим: данные (источники, хранение, управление, извлечение), анализ (преобразования и вычисления) и использование информации (доставка, формат, гибкость). Пользователь может начать с данных, а затем понять, что нужен другой анализ или другой источник.
От описания прошлого к прогнозам#
Со ссылкой на Пател и Тейлора (Patel, Taylor), а также Дэвенпорта (Davenport) авторы описывают спектр от простого к сложному: стандартные отчёты о прошлом, нерегламентированные (ad hoc) запросы, оповещения, статистический анализ закономерностей, прогнозирование и оптимизация, предиктивные модели и сценарии «что если». Организации, которые только начинают работать с аналитикой, начинают с простого конца.
Начинайте с решений#
По подходу Тейлора, в центре которого стоят решения: 1. Опишите бизнес-решения, которые будет поддерживать информация. 2. Свяжите каждое решение с бизнес-целями. 3. Разложите каждое решение на вопросы, на которые нужно ответить, включая вопросы, на которые нужно ответить раньше других. 4. Определите, как аналитика поможет на них ответить.
Хорошая формулировка решения так же однозначна, как хорошее требование: кто что решает, как часто и на каком основании. Когда кто-то просит конкретный отчёт или список полей, спросите: «Что вы будете решать с его помощью?» — и двигайтесь в обратном направлении. Общий порядок работы: приоритизировать по решениям, затем определить, как будет использоваться информация, затем потребности в данных, затем аналитические операции.
Использование информации#
Для людей укажите способ доставки (электронная почта, портал, мобильное устройство), формат (отчёт, дашборд, необработанные данные) и то, насколько пользователи могут с информацией работать — от личной копии до самостоятельных нерегламентированных запросов. Для систем аналитику можно встроить в приложение, чтобы оно принимало решения автоматически. Авторы показывают и силу, и этические риски такого подхода и описывают системы автоматической торговли, которые продали акции через несколько секунд после ложного сообщения в социальной сети и тем самым запустили продажи у других автоматических продавцов. Задайте ограничения на то, что может сделать автоматическое решение, если оно ошибочно.
Требования к данным#
Для больших данных авторы приводят три признака по Фрэнксу (Franks): объём, скорость и сложность. Структурированные данные укладываются в обычные модели «сущность — связь» и словари данных. Неструктурированные данные (голосовая почта, свободный текст) требуют анализа в контексте: одно и то же слово в разных текстах может значить очень разные вещи. Полуструктурированные данные (электронные письма, изображения с метаданными) находятся посередине. Вопросы, которые стоит задать (в адаптации по Брейсу (Brijs)): - Источники: какие объекты и атрибуты, как получить к ним доступ, насколько вероятно, что источник изменится, нужно ли переносить историю. - Хранение: текущий объём и ожидаемый рост, срок хранения, безопасность. - Управление: структура, преобразования для объединения источников, правила архивирования и удаления, целостность. - Извлечение: требуемая скорость; в реальном времени или пакетно и как часто.
Требования к анализу#
Лица, принимающие решения, часто заранее не знают, что искать, поэтому закладывайте исследовательские запросы и инструменты «что если», а не только заранее заданные отчёты. Спрашивайте о временных горизонтах: какие выводы нужны о прошлом, какие немедленные действия — в настоящем, какие прогнозы — о будущем? Для сложных вычислений авторы предлагают шаблон формулы Уитхолла (Withall): опишите вычисляемое значение, формулу, переменные и откуда берутся их значения, а также требуемое время отклика.
Пример#
«Мастерская», вымышленная сеть веломастерских, записывает свою первую формулировку решения: «Каждый месяц владелец решает, сколько механиков ставить в смену в каждой мастерской на каждый день недели, исходя из записей, клиентов без записи и среднего времени ремонта». - Вопросы: в какие дни недели запись переполнена? Сколько длится ремонт каждого типа? Сколько клиентов без записи приходит в день? - Данные: система бронирования, карточки заказов (тип ремонта, время начала и окончания) и журнал клиентов без записи на стойке приёма. - Использование: ежемесячный дашборд для владельца и еженедельное оповещение управляющим, когда записей больше, чем позволяют мощности.
Чек-лист#
- Каждое требование трассируется к сформулированному бизнес-решению.
- В формулировках решений указано, кто решает, что, как часто и на каком основании.
- Для каждой группы пользователей заданы способ доставки, формат и гибкость.
- Получены ответы на вопросы об источниках, хранении, управлении и извлечении данных.
- Учтены исследовательские потребности и сценарии «что если», а не только фиксированные отчёты.
- Для автоматических решений заданы ограничения на ущерб, который может нанести ошибка.
- Первый релиз небольшой, и пользователи могут задать следующие вопросы.
Источники и что почитать#
- K. Wiegers, J. Beatty. Software Requirements, 3rd ed. Microsoft Press, 2013. Рус. изд.: К. Вигерс, Дж. Битти. Разработка требований к программному обеспечению, 3-е изд. М.: Русская редакция; СПб.: БХВ-Петербург, 2014. Гл. 25 (включая ссылки авторов на работы Тейлора, Пател и Тейлора, Дэвенпорта, Фрэнкса, Брейса и Уитхолла).