Инженерия требований

Как специфицировать отчёты и дашборды

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

По материалам: К. Вигерс, Дж. Битти, «Разработка требований к программному обеспечению», 3-е изд., гл. 13.

На этой странице

Главные идеи#

Отчёт — это требования плюс дизайн#

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

Четыре вопроса перед началом#

  1. Какие отчёты используются сегодня? Это кандидаты на перенос в новую систему.
  2. Какие существующие отчёты нужно изменить? Это шанс исправить то, что не нравится пользователям.
  3. Какие отчёты формируются, но не используются? Это кандидаты на удаление.
  4. Каким стандартам подразделения, компании или государства должны соответствовать отчёты?

Вопросы по каждому отчёту#

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

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

Шесть привычек хорошего анализа отчётов#

  • Предлагайте альтернативы — например, сортировку, перестановку столбцов или сводное представление с детализацией (drill-down) — вместо того чтобы буквально копировать первый запрос.
  • Находите источники данных рано. Запрос на отчёт часто вскрывает неизвестные требования к сбору данных или доступу к ним.
  • Закладывайте рост. Макет, который работает для 10 строк, может сломаться на 100, и придётся переходить с книжной ориентации на альбомную или транспонировать таблицу.
  • Ищите сходство. Несколько почти одинаковых запросов часто закрывает один параметризованный отчёт.
  • Отличайте статическое от динамического. Снимок на определённый момент — не то же самое, что живое представление.
  • Делайте прототипы. Покажите макет или похожий существующий отчёт, заполненный реалистичными тестовыми данными.

Дашборды#

Дашборд объединяет несколько показателей в одном сводном представлении. Вигерс и Битти сравнивают его с экраном биржевого трейдера: новичку он кажется хаосом, эксперт считывает его мгновенно. Их метод расширяет метод для отчётов:

  1. Определите решения, которые пользователь принимает с помощью дашборда. Они задают способ представления, а не наоборот.
  2. Определите источник данных для каждого элемента и то, как часто эти данные меняются.
  3. Выберите визуализацию для каждого набора данных: таблица, интерактивная электронная таблица, текст, столбчатая диаграмма, круговая диаграмма, линейный график или видео.
  4. Определите макет и относительный размер элементов.
  5. Специфицируйте каждый элемент как маленький отчёт по тому же шаблону.

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

Расставить стикеры на доске — быстрый способ прототипировать макет дашборда до начала любой дизайнерской работы.

Как применять#

  1. Проведите инвентаризацию существующих отчётов по четырём вопросам и решите, что оставить, изменить или убрать.
  2. Для каждого отчёта начинайте с решения, которое он поддерживает. Если никто не может назвать такое решение, поставьте отчёт под сомнение.
  3. Заполните шаблон спецификации ниже, пропуская то, что неприменимо.
  4. Проследите каждое поле до источника данных и до словаря данных.
  5. Проверьте макет на реалистичных и больших объёмах данных.
  6. Для дашбордов сначала перечислите решения, затем элементы, затем макет, затем спецификацию каждого элемента.
  7. Прежде чем браться за дизайн, проверьте прототип с пользователями.

Шаблон#

Шаблон
# Спецификация отчёта: <название отчёта>

- ID — уникальный идентификатор отчёта
- Заголовок — текст, расположение, показываются ли параметры запуска
- Назначение — бизнес-назначение и решения, которые принимаются с помощью отчёта
- Приоритет — относительная важность
- Пользователи — классы пользователей, которые получают или запускают отчёт
- Источники данных — системы, таблицы или потоки данных
- Использование — статический или динамический; периодичность; триггер; получатели; способ доставки
- Своевременность — допустимое время отклика; насколько свежими должны быть данные
- Макет — ориентация, формат страницы, настройки диаграмм
- Колонтитулы — номера страниц, время формирования, источник данных, диапазон дат, примечания об исключениях, гриф конфиденциальности, фирменный стиль
- Тело — критерии отбора, поля, заголовки и числовые форматы, обработка переполнения, вычисления, сортировка, фильтр, группировка и промежуточные итоги, разрывы страниц
- Конец отчёта — маркер или итоговая строка
- Интерактивность — детализация, ссылки на связанные отчёты, сохранённые параметры
- Безопасность — кто может запускать или видеть отчёт, ограничения на уровне строк или полей

Пример#

В «Мастерской» (вымышленной сети веломастерских) владелец просит «отчёт по всем ремонтам». Аналитик спрашивает, какое решение этот отчёт поддерживает. Ответ: каждый понедельник владелец решает, каких механиков перебросить между мастерскими. Так запрос превращается в еженедельный отчёт о загрузке: открытые ремонты по каждой мастерской, сгруппированные по статусу, со средним числом дней ожидания запчастей. Отчёт формируется автоматически каждый понедельник в 07:00 и приходит по электронной почте владельцу и управляющим мастерских. Мастерские, где запчастей ждут больше заданного числа ремонтов, выделяются — и цветом, и символом.

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

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

  • K. Wiegers, J. Beatty. Software Requirements, 3rd ed. Microsoft Press, 2013. Рус. изд.: К. Вигерс, Дж. Битти. Разработка требований к программному обеспечению, 3-е изд. М.: Русская редакция; СПб.: БХВ-Петербург, 2014. Гл. 13 (спецификации отчётов; дашборды).