Как специфицировать отчёты и дашборды
Коротко Отчёты и дашборды — одни из самых востребованных и при этом хуже всего специфицированных частей бизнес-систем. Вигерс и Битти дают набор вопросов, шаблон спецификации отчёта и метод для дашбордов, который начинается с решений, которые должен принимать пользователь.
По материалам: К. Вигерс, Дж. Битти, «Разработка требований к программному обеспечению», 3-е изд., гл. 13.
На этой странице
Главные идеи#
Отчёт — это требования плюс дизайн#
В отчёте трудно отделить то, что он содержит, от того, как он выглядит, поэтому Вигерс и Битти специфицируют и то и другое вместе: содержание и его организацию (требования) и макет (дизайн).
Четыре вопроса перед началом#
- Какие отчёты используются сегодня? Это кандидаты на перенос в новую систему.
- Какие существующие отчёты нужно изменить? Это шанс исправить то, что не нравится пользователям.
- Какие отчёты формируются, но не используются? Это кандидаты на удаление.
- Каким стандартам подразделения, компании или государства должны соответствовать отчёты?
Вопросы по каждому отчёту#
Контекст и использование: название отчёта; его бизнес-назначение и решения, которые принимаются с его помощью (не только «что показать», но и «что люди будут с этим делать»); запускается ли он по запросу или автоматически и что его запускает; типичный и максимальный объём; нужен ли поверх него дашборд; куда идёт результат (экран, печать, экспорт, архив); ограничения безопасности и конфиденциальности.
Содержание: источники данных и критерии отбора; параметры, которые может задать пользователь; вычисления; сортировка, разрывы страниц и итоги; что показывать, если данных не нашлось; нужен ли доступ к исходным данным для произвольных запросов; может ли этот отчёт стать шаблоном для семейства похожих.
Шесть привычек хорошего анализа отчётов#
- Предлагайте альтернативы — например, сортировку, перестановку столбцов или сводное представление с детализацией (drill-down) — вместо того чтобы буквально копировать первый запрос.
- Находите источники данных рано. Запрос на отчёт часто вскрывает неизвестные требования к сбору данных или доступу к ним.
- Закладывайте рост. Макет, который работает для 10 строк, может сломаться на 100, и придётся переходить с книжной ориентации на альбомную или транспонировать таблицу.
- Ищите сходство. Несколько почти одинаковых запросов часто закрывает один параметризованный отчёт.
- Отличайте статическое от динамического. Снимок на определённый момент — не то же самое, что живое представление.
- Делайте прототипы. Покажите макет или похожий существующий отчёт, заполненный реалистичными тестовыми данными.
Дашборды#
Дашборд объединяет несколько показателей в одном сводном представлении. Вигерс и Битти сравнивают его с экраном биржевого трейдера: новичку он кажется хаосом, эксперт считывает его мгновенно. Их метод расширяет метод для отчётов:
- Определите решения, которые пользователь принимает с помощью дашборда. Они задают способ представления, а не наоборот.
- Определите источник данных для каждого элемента и то, как часто эти данные меняются.
- Выберите визуализацию для каждого набора данных: таблица, интерактивная электронная таблица, текст, столбчатая диаграмма, круговая диаграмма, линейный график или видео.
- Определите макет и относительный размер элементов.
- Специфицируйте каждый элемент как маленький отчёт по тому же шаблону.
Вопросы, характерные именно для дашбордов: как и как часто обновляются динамические данные (и сдвигается ли временное окно); какие параметры, например диапазон дат, может менять пользователь; условное форматирование, например цвета светофора, — всегда с нецветовой альтернативой для пользователей с нарушениями цветового зрения; можно ли разворачивать, сворачивать или закрывать элементы; сохраняются ли личные настройки между сеансами; переключение между таблицей и диаграммой; переход от сводки к подробностям.
Расставить стикеры на доске — быстрый способ прототипировать макет дашборда до начала любой дизайнерской работы.
Как применять#
- Проведите инвентаризацию существующих отчётов по четырём вопросам и решите, что оставить, изменить или убрать.
- Для каждого отчёта начинайте с решения, которое он поддерживает. Если никто не может назвать такое решение, поставьте отчёт под сомнение.
- Заполните шаблон спецификации ниже, пропуская то, что неприменимо.
- Проследите каждое поле до источника данных и до словаря данных.
- Проверьте макет на реалистичных и больших объёмах данных.
- Для дашбордов сначала перечислите решения, затем элементы, затем макет, затем спецификацию каждого элемента.
- Прежде чем браться за дизайн, проверьте прототип с пользователями.
Шаблон#
# Спецификация отчёта: <название отчёта>
- ID — уникальный идентификатор отчёта
- Заголовок — текст, расположение, показываются ли параметры запуска
- Назначение — бизнес-назначение и решения, которые принимаются с помощью отчёта
- Приоритет — относительная важность
- Пользователи — классы пользователей, которые получают или запускают отчёт
- Источники данных — системы, таблицы или потоки данных
- Использование — статический или динамический; периодичность; триггер; получатели; способ доставки
- Своевременность — допустимое время отклика; насколько свежими должны быть данные
- Макет — ориентация, формат страницы, настройки диаграмм
- Колонтитулы — номера страниц, время формирования, источник данных, диапазон дат, примечания об исключениях, гриф конфиденциальности, фирменный стиль
- Тело — критерии отбора, поля, заголовки и числовые форматы, обработка переполнения, вычисления, сортировка, фильтр, группировка и промежуточные итоги, разрывы страниц
- Конец отчёта — маркер или итоговая строка
- Интерактивность — детализация, ссылки на связанные отчёты, сохранённые параметры
- Безопасность — кто может запускать или видеть отчёт, ограничения на уровне строк или полей
Пример#
В «Мастерской» (вымышленной сети веломастерских) владелец просит «отчёт по всем ремонтам». Аналитик спрашивает, какое решение этот отчёт поддерживает. Ответ: каждый понедельник владелец решает, каких механиков перебросить между мастерскими. Так запрос превращается в еженедельный отчёт о загрузке: открытые ремонты по каждой мастерской, сгруппированные по статусу, со средним числом дней ожидания запчастей. Отчёт формируется автоматически каждый понедельник в 07:00 и приходит по электронной почте владельцу и управляющим мастерских. Мастерские, где запчастей ждут больше заданного числа ремонтов, выделяются — и цветом, и символом.
Затем управляющие мастерских просят дашборд. Их решение ежедневное: какие ремонты нужно поторопить сегодня. Аналитик раскладывает стикеры для трёх элементов (ремонты со сроком сегодня, запчасти, которые поставщик задерживает, готовые ремонты, за которыми ещё не пришли), согласует расположение с двумя управляющими и специфицирует каждый элемент как мини-отчёт.
Источники и что почитать#
- K. Wiegers, J. Beatty. Software Requirements, 3rd ed. Microsoft Press, 2013. Рус. изд.: К. Вигерс, Дж. Битти. Разработка требований к программному обеспечению, 3-е изд. М.: Русская редакция; СПб.: БХВ-Петербург, 2014. Гл. 13 (спецификации отчётов; дашборды).