Чому вам потрібно подумати про глосарій та словник даних
Неважливо, яку систему ви розробляєте – ви завжди працюватимете з даними. Дані з’являтимуться в системі у вигляді довідників, вноситимуться кінцевими користувачами, надходитимуть від інших систем – постачальників даних. Дані відображатимуться користувачам на різних рівнях деталізації:
як окрема сутність при перегляді або редагуванні,
в агрегованому вигляді у звітах,
у форматі вивантаження для інших систем.
Вже на етапі обговорення границь системи ви визначатимете, яку частину предметної області вона повинна охопити і яку інформацію зберігатиме. Ви говоритимете про дані з бізнес-замовниками, розробниками, тестувальниками та службою підтримки.
Кількість термінів, понять і логічних взаємозв’язків зростає пропорційно розширенню функціональності та контексту використання системи. В таких умовах усні домовленості або розрізнені записи в різних документах вже не гарантують коректного розуміння вимог. Навіть у чітко прописаних вимогах можуть виникати проблеми з інтерпретацією термінів. Наприклад, у різних предметних областях, країнах або навіть підрозділах однієї компанії одне й те ж слово може мати різні значення. Без єдиного розуміння термінів і їхнього контексту стейкхолдери постійно стикатимуться з плутаниною, що призведе до переробок, збільшення витрат і ризиків конфліктів. Аналогічно, відсутність вимог до даних ускладнить розробку інтерфейсів, проєктування сховища даних та тестування.
Саме тому глосарій і словник даних стають критично важливими артефактами. Вони забезпечують єдине інформаційне поле для всіх учасників розробки: від бізнес-аналітиків і архітекторів до розробників, тестувальників та представників замовника.
Проблеми, що виникають при відсутності глосарія та словника даних
Якщо у вашому проєкті відсутній глосарій і словник даних, команда може зіткнутися з такими проблемами:
Неправильне розуміння вимог. Учасники команди можуть по-різному інтерпретувати одні й ті ж терміни, що позначиться на якості реалізованого рішення.
Збільшення часу на уточнення деталей. Без прописаних вимог до даних команда витрачатиме більше часу на узгодження і виправлення неточностей.
Ускладнення підтримки системи. Без чіткої документації нові члени команди матимуть труднощі із вивченням системи, особливо якщо вона складна і багаторівнева.
Метою цієї статті є допомогти розібратися, як правильно організувати глосарій і словник даних, щоб вони стали не просто формальними документами, а корисними інструментами для команди розробки. Ми розглянемо відмінності між глосарієм і словником даних, а також підходи до їх створення.
Глосарій і словник даних: що це таке і чим вони відрізняються?
Що таке глосарій?
Глосарій — це список термінів, специфічних для предметної області або проєкту, з поясненням їхніх значень. Його основна мета — забезпечити єдине розуміння ключових понять усіма учасниками проєкту.
Зазвичай глосарій містить терміни, що описують бізнес-домен проєкту. Наприклад:
Що таке "замовлення", "клієнт", "угода", "кредитний ліміт" тощо.
Глосарій встановлює спільну мову для команди, зменшуючи ризики неправильного трактування вимог.
Що таке словник даних?
Словник даних — це більш технічний документ, що описує вимоги до даних, їх структуру та взаємозв’язки.
Якщо глосарій пояснює, що таке "Клієнт" як бізнес-сутність, то словник даних включає детальний опис:
Які саме поля характеризують "Клієнта"
Типи даних (рядок, число, дата тощо)
Формати і обмеження (наприклад, довжина номера телефону, чи є поле обов’язковим для заповнення)
Словник даних допомагає розробникам і архітекторам коректно проєктувати бази даних, API, інтеграції та інтерфейси.
Глосарій vs. Словник даних: коли і що використовувати?
Глосарій і словник даних, хоч і тісно пов'язані, призначені для різних цілей. Їх роль можна порівняти з двома рівнями розуміння системи:
Документ | Глосарій | Словник даних |
Рівень | Рівень предметної області | Рівень технічних даних |
Призначення | Служить для уніфікації термінології | Визначає структуру і вимоги до даних |
Рівень деталізації | Включає концептуальні описи, без технічних деталей | Містить технічні характеристики полів, форматів, обмежень |
Цільова аудиторія | Орієнтований на всю команду (бізнес-аналітиків, замовників, розробників) | Орієнтований на розробників, архітекторів, тестувальників |
Приклад | "ідентифікаційний код" це унікальний ідентифікатор .... | Поле "User_ID", тип – integer, мінімальне значення – 1000 |
На ранніх етапах аналізу проєкту зручніше працювати з глосарієм, щоб визначити ключові поняття. На більш пізніх етапах глосарій можна інтегрувати у словник даних, особливо якщо система складна і має багато інтеграцій.
Якщо проект відносно невеликий і не передбачає складних зв'язків даних, то глосарія може бути достатньо. Якщо система складна, проект передбачає створення сховища даних, є множинні інтеграції із зовнішніми джерелами, словник даних стає незамінним інструментом.
Таким чином, глосарій і словник даних — це два артефакти, що взаємодоповнюють, які разом дозволяють спочатку створити загальну логіку розуміння домену, а потім формалізувати її в конкретних структурах і правилах роботи з даними.
Глосарій (Glossary)
Глосарій - це один із перших артефактів, який необхідно створити при описі вимог до ІТ-рішення. Він виступає у ролі «точки опори» всім учасників, забезпечуючи єдине розуміння термінів і понять. Структура глосарію може бути такою:
Термін
Розгорнуте визначення
Синоніми
Приклади використання (Іноді корисно доповнювати визначення прикладами з реального контексту бізнесу або сценаріїв користувача, щоб прибрати неоднозначність).
Створювати глосарій бажано вже на ранніх стадіях проекту, коли бізнес-аналітик починає занурюватися в предметну галузь проекту та специфіку контексту клієнта. Можна спробувати перевикористовувати глосарій із попереднього схожого проекту. Ну а якщо з цим клієнтом ми вже працювали, саме час пошукати глосарій з попереднього проекту.
Рекомендації по створенню глосарія
Єдиний централізований глосарій на весь проєкт
BABOK рекомендує визначити контактну особу, відповідальну за підтримку та розповсюдження глосарію в ході ініціативи. Централізоване ведення глосарію – чудова ідея. Якщо кожен учасник проекту або групи стейкхолдерів матиме свій глосарій, то позитивного ефекту ми не отримаємо.
Визначення мають бути ясними та небагатослівними
Глосарій – це документ для всіх. Використовуйте просту і ясну мову без надмірної технічної термінології (якщо це не терміни, які ви якраз і визначаєте). Кожне визначення має бути максимально лаконічним, але зрозумілим і недвозначним.
Абревіатури повинні супроводжуватись розшифровкою
Абревіатури можуть самі служити термінами, які ми розкриваємо в глосарії. Але в жодному разі не припускайте, що читач здатний на льоту розшифрувати навіть найпоширенішу на вашу думку абревіатуру.
Доступність для всіх учасників проекту
Усі учасники проекту (представники замовника, проектна команда, служба підтримки) повинні знати про існування глосарію та мати до нього доступ на читання, а хтось і на редагування. Розміщення глосарію у загальнодоступному місці (корпоративна Wiki-система, репозиторій, портал проекту) та використання зручних засобів пошуку (алфавітний покажчик, теги) значно спростить роботу.
Узгодженість із доменною областю
Визначення мають відповідати реальному бізнес-контексту. Працюючи над глосарієм корисно залучати представників замовника чи профільних експертів, щоб бути впевненими, що терміни відображають актуальну картинку, і ми не вигадуємо «велосипед».
Актуальність та оновлюваність
Глосарій - це "живий" документ, його необхідно регулярно актуалізувати. У міру змін у вимогах або з появою нових понять терміни мають своєчасно оновлюватися.
Приклад структури глосарію
Термін | Розгорнуте визначення | Синоніми | Приклади використання |
Адміністративно-територіальна одиниця | Одиниця територіального поділу країни, яка має встановлені межі, адміністративний центр та певний рівень місцевого самоврядування. В Україні до адміністративно-територіальних одиниць належать області, райони, міста, громади, села та селища. | АТО, Територіальна одиниця, Адміністративна одиниця | - Київ є окремою адміністративно-територіальною одиницею зі спеціальним статусом. - У межах адміністративно-територіальної реформи було укрупнено райони. |
Код ЄДРПОУ | Унікальний ідентифікаційний номер юридичної особи або фізичної особи-підприємця, який присвоюється при реєстрації в Єдиному державному реєстрі підприємств та організацій України (ЄДРПОУ) | ЄДРПОУ, Ідентифікаційний код підприємства | - Для укладення договору потрібно вказати код з ЄДРПОУ компанії. - Податкова служба перевірила інформацію за кодом з ЄДРПОУ. |
РНКОПП | Реєстраційний номер облікової картки платника податків – індивідуальний номер, що присвоюється фізичній особі для ведення податкового обліку в Україні. | ІПН, Ідентифікаційний код, Податковий номер, Ідентифікаційний номер | - Для відкриття рахунку в банку потрібно надати РНКОПП. - Фізична особа може відмовитися від отримання РНКОПП через релігійні переконання. |
Словник даних (Data Dictionary)
Словник даних - це техніка для опису вимог до даних, якими оперуватиме система. Команді розробки необхідно розуміти, які дані будуть використовуватися, якими вони можуть бути, як дані пов'язані між собою і які правила до них застосовуються. Якщо глосарій покликаний забезпечити єдність бізнес-термінів, то словник даних служить каркасом, що пов'язує функціональні вимоги з конкретними полями на інтерфейсі, таблицями в базі даних, полями в API і т.д.
Децентралізований словник даних
Найпростіший спосіб створення словника даних - це опис вимог до прив'язки до конкретного Use Case або User Store.
Припустимо, ми маємо функцію «Реєстрація облікового запису», вона ж Sign Up. Нам потрібно сказати розробникам, які поля потрібно відобразити на екранній формі. Перераховувати їх у кожному критерії приймання чи тілі Use Case не дуже зручно. Краще описати їх окремо в табличному вигляді, а з критерію приймання або кроку Use Case послатися на цю таблицю.
Для кожного атрибута ми можемо визначити:
Назву
Ознаку «Обов’язковий/не обов’язковий». Наприклад, поле «пароль» для облікового запису – обов’язкове, а поле «дата народження» – не обов’язкове.
Тип поля: ціле число, дійсне число, рядок, дата, дата+час, значення зі словника тощо.
Додаткові вимоги залежно від типу поля
Для цілого числа може бути задано мінімальне і максимальне значення, для дійсного – додатково потрібно вказати максимальну кількість символів після коми.
Для рядка – мінімальну і максимальну довжину. Також можна визначити перелік допустимих символів: тільки латиниця, тільки кирилиця, кирилиця + ряд символів («.», «,», «-», «;» тощо).
Для дати – формат: дд.мм.рррр, мм.дд.рррр, дд.мм тощо.
Для поля, можливі значення якого задаються словником – або перелік можливих значень, або посилання на сам словник, який може бути описаний окремо.
Значення за замовчуванням
Доступність для редагування:
Доступно
Не доступно
Доступно, якщо виконується певна умова. Наприклад, для поля «дата блокування»: доступно, якщо стан облікового запису – «Заблоковано».
Посилання на додаткові вимоги до поля (якщо ми не хочемо описувати ці бізнес-правила окремо або хочемо зайвий раз звернути увагу, що вони мають застосовуватися):
Для поля «Пароль» – значення маскуються зірочками.
Для поля «Дата подання заяви» – не більше за поточну дату.
Для поля «Пароль» – посилання на список бізнес-правил до пароля.
Якщо ми говоримо про функцію пошуку, то нам потрібно визначити:
Вимоги до атрибутів пошуку
Вимоги до результатів пошуку
Вимоги до атрибутів пошуку можна задати у такому ж форматі, як вони задані для полів сутності вище. А ось вимоги до результатів пошуку можна описати просто у вигляді переліку атрибутів, які будуть відображатися. Наприклад, для функції пошуку облікових записів у результатах мають відображатися:
ПІБ
E-mail
Стан
Дата створення
Дата і час останнього входу
Дата блокування
Також для кожного атрибута можна прописати, чи підтримується для нього операція пошуку, фільтрації, групування, сортування.
Приклад структури словника даних
Переваги та недоліки децентралізованого словника даних
Децентралізований словник даних дозволить вам:
Не забувати про вимоги до даних.
Відокремити вимоги до даних від функціональних вимог
Використання загальної структури дозволить збільшити повноту вимог. Якщо є поле «за замовчуванням», то вже складніше не вказати цю вимогу.
Адаптувати структуру для різних функцій.
А тепер ключовий недолік. Припустимо, у вас є суть організації і має атрибут «Назва». На різних інтерфейсних формах може називатися по-різному: «Назва», «Організація», «Повна назва». Як зрозуміти, що це все ще одне поле та вимоги до нього мають бути однакові.
Аналогічно, якщо у вас окремий словник для операції "Створення організації" та "Редагування організації", як простежити, що вимоги до полів в одному та іншому словнику однакові. Адже функції, які дозволяють змінювати атрибути сутності, можуть ставитися навіть до різних підсистем. Як підтримати консистентність вимог щодо даних? І тут ми приходимо до централізованого словника даних! Про нього у наступній статті.
Новини та статті з бізнес-аналізу:
Comments