Бизнес-анализ в IT
2025-06-12 12:05

Требования к данным: чем они круты и как с ними работать (ч. 2)

Бизнес-анализ
В первой части, напомню, мы вели речь о том, что такое требования к данных и с чего начинать работу с ними.

4) Второй ключевой компонент требований к данным — словарь данных (data dictionary, data glossary). В целом, нам и модели бы уже хватило, чтобы оказать серьезную помощь и себе, и команде разработки. Но если позволяет время, словарь данных будет огненным дополнением.
Словарь данных нагляднее всего оформить в виде таблички. В этой табличке я рекомендую указывать следующие вещи для каждой сущности данных:
  • Атрибуты (их названия).
  • Описание каждого атрибута человеческим языком, т. е. пояснение, что данный атрибут значит с точки зрения информации в системе.
  • Обязателен ли данный атрибут для каждого экземпляра сущности данных? Проще говоря, может ли атрибут остаться пустым. Если в терминах аналогии с Excel-файлом выше, то могут ли быть строки на вкладке, посвященной текущей сущности, где данная ячейка будет пустой?
  • Какой у атрибута тип данных? Например, целое число, дробное число, текст (произвольный или в рамках более узкого формата), изображение, видео, логический (да/нет), перечисление (одно из заранее известного набора значений), дата и т. п. Далее на примере мы рассмотрим некоторые из этих типов.
  • Дополнительные детали: специфики формата, источник данных и пр. — все, что вам может показаться полезным продумать и указать.
Вот словарь данных для нашего примера, плюс пояснения интересных моментов по ходу:
Обязательность:
  • Почему Картинка не обязательна? Пообщавшись с ЗЛ, мы определили, что не у всех Товаров может быть изображение, если админ такое не добавляет при создании Товара. Естественно, подобное нужно будет обыграть на уровне поведенческих требований: как отобразить карточку Товара без картинки.
  • Остальные атрибуты ни в какой ситуации не могут быть пустыми: Кем внесено — очевидно не может быть пустым, а Наименование, Описание и Цена согласованы с заказчиком как обязательные (что означает, что при создании Товара соответствующие поля будут обязательными для заполнения).
Типы данных:
  • Кем внесено — указано как Пользователь. Этот тот подход, который я люблю применять, когда мы ведем речь про увязывающие атрибуты. Так мы показываем, что это отсылка на какого-то Пользователя — на объект класса Пользователь.
Дополнительные детали:
Чаще всего тут описывают специфики формата. Причем те специфики, которые нам важно будет учитывать в поведенческих требованиях.
  • Для Изображения указаны тип файла и его максимальный вес. Это обязательно найдет отражение в том, что система позволит или не позволит добавить в качестве картинки админу при создании Товара. Можно было также указать и иные параметры — размеры и пропорции, например — но конкретно в данном примере никаких ограничений в этом плане нет (т. е. система должна будет уметь принимать и впихивать в карточку при отображении Товара изображения любого размера и пропорций).
  • Кем внесено — специфик формата нет. Это просто отсылка на того админа, который создал Товар.
  • Для текстовых атрибутов указана максимальная длина. Это означает, что система не позволит ввести при создании Товара текст большей длины. Если бы таких ограничений не было (как с позиции того, что позволять пользователям вводить при создании Товара, так и того, как потом текст любого размера показать в их списке и на карточках), то и данные специфики мы бы не обсуждали с ЗЛ и не приводили бы тут.
  • Аналогичный подход и для Цены, которая в виде дробного числа. Мы обсудили и договорились с ЗЛ, что цена не может быть ниже 0,01 и выше 1000,00, плюс указывается при этом с двумя знаками после запятой. Т. е. админам нельзя будет указывать цену вне этого интервала при создании Товара. Подобные ограничения могут быть актуальными для чисел, дат, времени и всего того, что может иметь минимальные и максимальные значения.
У Пользователя детализация атрибутов нехитрая, но давайте глянем на дополнительные детали. В них пояснено, что эти данные будут поступать в систему не самым очевидным путем, т. е. не вноситься через UI пользователями системы. Сделана пометка касательно источника данных, чтобы разработчикам было понятно, как эти данные должны в системе появиться. Иного описания в этой колонке нет, т. к. в нашем примере это и не нужно. В более сложном примере тут могли бы быть специфичные форматы Логина и Пароля (например, отсылка на существующий в мире формат электронных адресов, а для пароля — описание того, какими могут быть пароли в контексте политики безопасности компании).
Типы данных:
  • Тип оплаты указан как Перечисление. Этот тот тип данных, который я рекомендую применять, когда атрибут может принимать одно из заранее предсказуемых значений. Т. е. не любое число из интервала или текст произвольного вида, а, как в нашем варианте, Наличные или Карта. Естественно, с точки зрения UI системы собирать эту информацию мы будем не текстовым полем, а радиокнопками, выпадающими списками или чем-то аналогичным.
  • Товары — по аналогии с тем, что мы рассматривали ранее, это отсылка на экземпляры Товаров, плюс тут указан символ массива, чтобы показать, что таких отсылок может быть несколько.
Дополнительные детали:
  • Мы пояснили, что Итоговая стоимость а) рассчитывается системой (т. е. это не та информация, которая вносится ручками пользователей) и б) на момент создания Заказа. Последнее и есть в принципе причина выделения такого атрибута. В момент создания заказа цены Товаров могут быть одними (и на их базе и нужно посчитать стоимость заказа и зафиксировать ее — “записать в эксельку”). Через 5 минут после создания Заказа цены могут измениться, поэтому просто отсылка на Товар и его текущую цену в данном случае не будет работать. Плюс мы сразу тут привели формулу расчета, чтобы она была зафиксирована в некоем центральном месте в документации.
  • Для Типа оплаты мы описали набор возможных значений. Это необходимо — с учетом того, что у нас это перечисление.
Заметьте, что сделав эту работу (проработав словарь данных) мы также в явном виде задумались о и проработали вагон и тележку нюансов: в частности, обязательность и особенности формата многих вещей, что по итогу выльется в важные требования к тому, как собирать эту информацию на формах, плюс как её корректно отображать при просмотре. Без явного фокуса на словаре данных предсказать судьбу подобных требований сложно: аналитик мог бы и учесть такие вещи, но непонятно, насколько запоздало и полно — тут уже как планеты в небе выстроятся.
Не пересекаем грань: по аналогии с моделью данных, в словаре данных мы стараемся не лезть в область технических решений. В чем это выражается:
а) Типы данных, как вы могли заметить, у нас “человеческие”. Например, Текст (а не Char (100)) или Целое число (а не Int (32)). В “технические” типы данных они превратятся в их физической реализации, когда она будет понятна.
б) Увязка сущностей между собой также идет довольно абстрактно. Если бы я проектировал реляционную базу данных, то, например, из Товара я бы сослался на Пользователя как его автора через какой-нибудь UserID. Но я не проектирую базу данных, и, напоминаю, не знаю, будет ли она в принципе и какие в целевом хранилище данных вообще будут использоваться способы связей.
в) Ограничения формата для атрибутов привязаны к поведению, а не к хранению. Т. е., например, адрес доставки имеет максимум 200 символов именно потому, что мы по какой-то причине не хотим позволять пользователю писать больше (чтобы не распылялся, чтобы мы могли комфортно показать это при отображении и т. п.) Мы не рассматриваем тут причину вида “Ну надо же как-то в базе данных ограничить эту текстовую строку в целях хранения”. Меня не волнуют аргументы реализации — а точнее, волнуют (вспоминаем такое качество требований, как feasibility), но не в виде того аспекта, о котором я в силах задуматься сам и поставить команде разработки на вход — я получу это в виде фидбэка от команды в момент обсуждения требований.
Что ещё полезного даёт словарь данных: это единое место, которое позволит не сбиться при проработке требований к поведению. Как могло бы быть без него: в момент проработки формы создания Заказа (User Story по созданию заказа) я мог думать в терминах “дорогой стейкхолдер, давай прикинем, что тут юзеру надо указать и как именно он будет это делать”; впоследствии, в момент проработки редактирования заказа — заново аналогичная работа; прорабатывая отображение заказа для админа — ровно аналогично (”давай думать, что мы тут полезного покажем”). Это прямо рассадник для неконсистентности требований: там что-то собрали с юзера, а тут не показали; собирая с юзера инфу, подумали о том, что это не обязательно для указания, а при показе инфы не подумали, что она может быть пустой, и т. п. Имея центральный словарь данных, наша работа не просто сильно облегчается, но и резко понижается шанс подобных ошибок. У вас всегда в одном месте есть информация о том, может ли параметр быть пустым, какого он типа и формата, как он рассчитывается и пр.
5) И хоть с требованиями к данным мы закончили, опишу вкратце, как я рекомендую требования к данным учитывать в контексте иных требований, и выделю два ключевых момента:
а) Многое из того, что мы продумали, делая эту работу, является бизнес-правилами (а точнее имеет бизнес-правила в качестве источника информации). Какие важные бизнес-правила мы можем выделить из нашей работы над данными выше?
  • Покупатель может оформить заказ на не более, чем 5 товаров единовременно.
  • Цены в Интернет-магазине указываются дробным числом с двумя разрядами.
  • Максимальная цена товара в Интернет-магазине: 1000,00 руб.
  • Интернет-магазин принимает два типа оплаты: наличный расчет и оплата картой.

Зачем нам выделять такие формулировки и называть их непонятным ругательством “бизнес-правила”? Об этом можно почитать тут и тут — надеюсь, убедитесь, что работать с бизнес-правилами — это + 100 к крутости.
б) Из любых поведенческих требований (т. е. из критериев приемки для юзер сторей, детализаций юз кейсов и т. п.) вам нужно теперь трассироваться (ссылаться) на словарь данных в тех местах, где поведение работает с информацией. Без этого теряется смысл части работы, которую мы тут проделали. Что имеется в виду:
  • Внесите LDM и словарь данных рядышком в вашу документацию (например, в раздел “Требования к данным” вашей SRS или на отдельную страничку в вашу Confluence для проекта).
  • Описывая поведение системы, ссылайтесь туда, причем максимально точно, если инструмент позволяет, чтобы разработчики понимали, какие именно данные вы собираете с пользователей или отображаете им.
US01 Создание товара

Как админ, я хочу иметь возможность добавить в систему товар, чтобы он стал доступен для заказа покупателям

Критерии приемки:

1) Просматривая список товаров, я могу открыть форму добавления нового товара.
2) Для добавления нового товара я должен указать следующие его параметры:
  • Название (ссылка на атрибут Наименование для Товара)
  • Система не позволяет мне указать текст больше максимальной длины (описано по ссылке на атрибут)
  • Описание (ссылка на атрибут Описание для Товара)
  • Система не позволяет мне указать текст больше максимальной длины (описано по ссылке на атрибут)
  • Цена (ссылка на атрибут Цена для Товара)
  • При попытке указать цену вне возможного интервала (описано по ссылке на атрибут) система кричит мне об этом.
3) Если я не указал какие-либо из этих параметров и пытаюсь добавить товар, система ругается на меня.
4) Я также могу добавить картинку для товара (ссылка на атрибут Изображение для Товара)
  • Система позволяет мне добавить изображения только указанного формата (описано по ссылке на атрибут).
  • При попытке добавить файл с изображением, превышающий максимальный вес (описано по ссылке на атрибут), система орет на меня матом.