Почему вам нужно подумать о глоссарии и словаре даных
Не важно какую систему вы разрабатываете, вы всегда будете работать с данными. Данные будут появляться в системе в виде справочников, заносится конечными пользователями, приходить от других систем – поставщиков данных. Данные будут отображаться пользователям на разном уровне детализации: на уровне одной сущности при просмотре или редактировании, в агрегированном виде в пользовательском отчете или в виде выгрузки для другой системы. Вы будете говорить о сущностях и их атрибутах еще на уровне обсуждения границ системы, определяя какую часть предметной области должна охватить будущая система и какую информацию она будет хранить. О данных вы будете говорить с представителями бизнеса, и с разработчиками, и с тестировщиками, и со службой поддержки.
Количество терминов, понятий и логических взаимосвязей растет пропорционально расширению функциональности и контекста использования системы. В таких условиях устное согласование терминологии или разрозненные записи в различных документах уже не гарантируют корректного понимания требований.
Даже в четко прописанных требованиях могут возникать проблемы с интерпретацией терминов. Например, в разных предметных областях, странах и даже подразделениях одной компании одно и то же слово может обозначать разные понятия. Без единого понимания терминов и их контекста системы стейкхолдеры будут постоянно сталкиваться с путаницей и неправильным трактованием, что приведет к переработкам, увеличению затрат и рискам конфликтов. Аналогично отсутствие требований к данным вызовет сложности на этапе разработки интерфейсов, проектирования хранилища данных и тестирования.
Именно поэтому глоссарий и словарь данных становятся критически важными артефактами. Они обеспечивают единое информационное поле для всех, кто вовлечен в разработку: от бизнес-аналитиков и архитекторов до разработчиков, тестировщиков и представителей заказчика.
Проблемы, возникающие при отсутствии глоссария и словаря данных
Если на вашем проекте отсутствует глоссарий и словарь данных, то ваша команда может столкнуться со следующими последствиями:
Неправильное понимание требований. Участники команды могут по-разному интерпретировать одни и те же термины, что сказывается на качестве реализованного решения.
Увеличение времени на уточнение деталей. Из-за отсутствия прописанных требований к данным команде придется тратить значительное время на уточнения и согласования.
Усложнение поддержки системы. Без четкой документации новые члены команды сталкиваются с трудностями при изучении системы, особенно если она сложная и многоуровневая.
Цель данной статьи — помочь разобраться в том, как правильно организовать глоссарий и словарь данных, чтобы они стали не просто формальными документами, а инструментами, упрощающими работу команды разработки. Мы рассмотрим основные отличия глоссария от словаря данных, и какие существуют подходы к их созданию.
Глоссарий и словарь данных. Что это и чем они отличаются?
Что такое глоссарий?
Глоссарий — это список терминов, специфичных для предметной области или проекта, с объяснением этих терминов. Основная задача глоссария — обеспечить единое понимание ключевых понятий всеми участниками проекта.
Глоссарий, как правило, фокусируется на терминах, отражающих домен проекта (например, что такое «заказ», «клиент», «сделка», «кредитный лимит» и т.д. Глоссарий задает общий язык, снижая риск неправильной интерпретации требований.
Что такое словарь данных?
Словарь данных — это более технический документ, описывающий требования к данным, их структуре и взаимоотношениям. Если глоссарий даёт понятия о том, что такое, например, «Клиент» как бизнес-сущность, то словарь данных будет включать детальное описание, какие именно поля (атрибуты) характеризуют «Клиента», их тип, формат, ограничения.
Словарь данных тесно связан с проектированием физической модели данных и формализацией требований к хранению, преобразованию и выводу информации. Он помогает разработчикам и архитекторам корректно спроектировать базы данных, API, интеграции и пользовательские интерфейсы.
Глоссарий vs Словарь данных: когда и что использовать
Глоссарий и словарь данных, хотя и тесно связаны, служат разным целям. Их роль можно сравнить с двумя уровнями понимания системы:
Уровень предметной области (глоссарий):
Цель: Согласовать терминологию, дать общее понимание сущностей, процессов и ролей.
Тип информации: концептуальное описание терминов, без технических деталей.
Целевая аудитория: Все участники проекта — от представителей бизнеса до команды разработки.
Пример: Определение, что такое «идентификационный код» в контексте данной системы или организации.
Уровень технических данных (словарь данных):
Цель: Определить требования к данным, обеспечить ясность в том, какие структуры, поля и форматы должны быть использованы.
Тип информации: Техническое описание атрибутов данных, схем, таблиц, форматов, ограничений.
Целевая аудитория: Архитекторы, разработчики, тестировщики, которые непосредственно работают проектируют, создают и тестируют.
Пример: Конкретная спецификация для поля «User_ID».
На ранних этапах анализа, когда доменная область только проясняется, удобнее работать с глоссарием. Он помогает понять, какие ключевые понятия важны для бизнеса и как они определены. На более поздних стадиях, когда глоссарий может быть включен в структуру словаря данных. Особенно если вы используете подход централизованного словаря данных.
Если проект относительно небольшой и не предполагает сложных связей данных, глоссария может быть достаточно. Если система сложная, проект предполагает создание хранилища данных, есть множественные интеграции с внешними источниками, словарь данных становится незаменимым инструментом.
Таким образом, глоссарий и словарь данных — это два взаимодополняющих артефакта, которые вместе позволяют сначала создать общую логику понимания домена, а затем формализовать её в конкретных структурах и правилах работы с данными.
Глоссарий (Glossary)
Глоссарий — это один из первых артефактов, который необходимо создать при описании требований к ИТ-решению. Он выступает в роли «точки опоры» для всех участников, обеспечивая единое понимание терминов и понятий. Структура глоссария может быть следующей:
Термин
Развернутое определение термина
Синонимы
Примеры использования (Иногда полезно дополнять определения примерами из реального контекста бизнеса или пользовательских сценариев, чтобы убрать неоднозначность).
Создавать глоссарий желательно уже на ранних стадиях проекта, когда бизнес-аналитик начинает погружение в предметную область проекта и специфику контекста клиента. Можно попробовать переиспользовать глоссарий с предыдущего похожего проекта. Ну а если с данным клиентом мы уже работали, то самое время поискать глоссарий с предыдущего проекта.
Рекомендации по созданию глоссария
Централизованный единый глоссарий на проект
BABOK рекомендует определить контактное лицо, ответственное за поддержку и распространение глоссария в ходе инициативы. Централизованное ведение глоссария – отличная идея. Если у каждого участника проекта или группы стейкхолдеров будет свой глоссарий, то положительного эффекта мы не получим.
Определения должны быть ясными и немногословными
Глоссарий – документ для всех. Используйте простой и ясный язык без избыточной технической терминологии (если это не термины, которые вы как раз и определяете). Каждое определение должно быть максимально лаконичным, но при этом понятным и недвусмысленным.
Аббревиатуры должны сопровождаться расшифровкой
Аббревиатуры могут и сами служить терминами, которые мы раскрываем в глоссарии. Но в любом случае не предполагайте, что читатель способен на лету расшифровать даже самую распространенную на ваш взгляд аббревиатуру.
Доступность для всех участников проекта
Все участники проекта (представители заказчика, проектная команда, служба поддержки) должны знать о существовании глоссария и иметь к нему доступ на чтение, а кто-то и на редактирование. Размещение глоссария в общедоступном месте (корпоративная Wiki-система, репозиторий, портал проекта) и использование удобных средств поиска (алфавитный указатель, теги) значительно упростит работу.
Согласованность с доменной областью
Определения должны соответствовать реальному бизнес-контексту. При работе над глоссарием полезно привлекать представителей заказчика или профильных экспертов, чтобы быть уверенными, что термины отражают актуальную картинку, и мы не придумываем «велосипед».
Актуальность и обновляемость
Глоссарий — это «живой» документ, его необходимо регулярно актуализировать. По мере изменений в требованиях или при появлении новых понятий термины должны своевременно обновляться.
Пример структуры глоссария
Термин | Определение | Синоним | Пример использования |
Административно-территориальная единица | Единица территориального деления страны, имеющая установленные границы, административный центр и определенный уровень местного самоуправления. В Украине к административно-территориальным единицам относятся области, районы, города, громады, сёла и посёлки. | АТЕ, Территориальная единица, Административная единица | - Киев является отдельной административно-территориальной единицей со специальным статусом. - В рамках административно-территориальной реформы были укрупнены районы. |
КОАТУУ | Классификатор объектов административно-территориального устройства Украины – система кодов, используемая для однозначной идентификации административно-территориальных единиц страны. КОАТУУ применяется в официальных документах, государственной статистике, реестрах и базах данных. | Классификатор АТЕ, Справочник КОАТУУ | - Код населённого пункта согласно КОАТУУ необходим для заполнения официальных документов. - В обновлённом КОАТУУ учтены изменения административного деления после реформы децентрализации. |
Код из ЕГРПОУ | Уникальный идентификационный номер юридического лица или физического лица-предпринимателя, присваиваемый при регистрации в Едином государственном реестре предприятий и организаций Украины (ЕГРПОУ). Используется для ведения финансовых операций, налогового учёта и других юридических процессов. | Код ЕГРПОУ, Идентификационный код предприятия | - Для заключения договора необходимо указать код из ЕГРПОУ компании. - Налоговая служба проверила информацию по коду из ЕГРПОУ. |
РНКУПН | Регистрационный номер учётной карточки плательщика налогов – индивидуальный номер, присваиваемый физическому лицу для ведения налогового учёта в Украине. Также известен как «идентификационный номер». Используется в налоговых декларациях, банковских операциях и других финансовых документах. | ИНН, Идентификационный код, Налоговый номер | - Для открытия счёта в банке необходимо предоставить РНКОПП. - Физическое лицо может отказаться от получения РНКОПП по религиозным убеждениям. |
Словарь данных (Data Dictionary)
Словарь данных — это техника для описания требований к данным, которыми будет оперировать система. Команде разработки необходимо понимать, какие данные будут использоваться, какими они могут быть, как данные связаны между собой и какие правила к ним применяются. Если глоссарий призван обеспечить единство бизнес-терминов, то словарь данных служит каркасом, связывающим функциональные требований с конкретными полями на интерфейсе, таблицами в базе данных, полями в API и т.д.
Децентрализованный словарь данных
Наиболее простой способ создания словаря данных – это описания требований к привязке к конкретному Use Case или User Story.
Предположим, у нас есть функция «Регистрация учетной записи», она же Sign Up. Нам нужно сказать разработчикам, какие поля необходимо отобразить на экранной форме. Перечислять их в каждом критерии приемки или в теле Use Case не очень удобно. Лучше описать их отдельно в табличном виде, а из критерия приемки или шага Use Case сослаться на эту таблицу.
Для каждого атрибута мы можем определить:
Название
Признак «Обязательный/не обязательный». Например, после «пароль» для учетной записи – обязательное, а поле «дата рождения» - не обязательное.
Тип поля: целое число, действительное число, строка, дата, дата+время, значение из словаря и т.д.
Дополнительные требования в зависимости от типа поля
Для целого числа может задано минимальное и максимальное значение, для действительного дополнительно нужно указать максимальное количество символов после запятой.
Для строки – минимальную и максимальную длину. Также можно определить перечень допустимых символов: только латиница, только кириллица, кириллица + ряд символов («.», «,», «-», «;» и т.д.)
Для даты – формат: дд.мм.рррр, мм.дд.рррр, дд.мм и т.д.
Для поля, возможные значения которого задаются словарем – либо перечисление возможных значений либо ссылка на сам словарь, который может быть описано отдельно.
Значение по умолчанию
Доступность для редактирования:
Доступно
Не доступно
Доступно, если выполняется некоторое условие. Например, для поля «дата блокировки»: доступно, если состояние учетной записи – «Заблокировано».
Ссылка на дополнительные требования к полю (если мы не хотим эти бизнес-правила описывать отдельно или хотим лишний раз обратить внимание, что они должны применяться)
Для поля «Пароль» - значение маскируются звездочками
Для поля «Дата подачи заявления» - не больше текущей даты.
Для поля «Пароль» - ссылка на список бизнес-правил к паролю.
Если мы говорим о функции поиска, то нам нужно определить:
требования к атрибутам поиска
требования к результатам поиска.
Требования к атрибутам поиска можно задать в таком же формате, как они заданы для полей сущности выше. А вот требования к результатам поиска можно описать просто в виде перечня атрибутов, которые будут отображаться. Например, для функции поиска учетных записей в результатах должны отображаться:
ФИО
E-mail
Состояние
Дата создания
Дата и время последнего входа
Дата блокировки
Также для каждого атрибута вы можете прописать, поддерживается ли по нему операция поиска, фильтрации, группировки, сортировки.
Пример структуры словаря данных
Преимущества и недостатки децентрализованного словаря данных
Децентрализованный словарь данных позволит вам:
Не забывать о требованиях к данным.
Отделить требования к данным от функциональных требований
Использование общей структуры позволит повысить полноту требований. Если есть поле «значение по умолчанию», то уже сложнее не указать это требование.
Адаптировать структуру для разных функций.
А теперь ключевой недостаток. Предположим, у вас есть сущность организация и у нее есть атрибут «Название». На разных интерфейсных формах оно может называться по-разному: «Название», «Организация», «Полное название». Как понять, что это все еще одно поле и требования к нему должны быть одинаковые?
Аналогично, если у вас отдельный словарь для операции «Создание организации» и «Редактирование организации», как проследить, что требования к полям в одном и другом словаре одинаковые. А ведь функции, которые позволяют изменять атрибуты сущности могут относиться даже к разным подсистемам. Как поддержать консистентность требований к данным? И тут мы приходим к централизованному словарю данных! О нем в следующей статье.
Новости и статьи по бизнес-анализу:
Comments