Создание требования (для Поставщика)

Требование — это запись в реестре, которая описывает требование потребителя к определенной характеристике качества данных. Если требование связано с проверкой качества данных в MWS Data Test, статус выполнения проверки отслеживается в реестре.

MWS Data предоставляет инструменты для создания и работы с требованиями. Ниже приведена пошаговая инструкция по созданию требования для роли Поставщик.

Шаг 1. Запуск мастера создания требования

Перейдите на вкладку «Реестр требований DQ».
Нажмите кнопку «Создать требование». Откроется модальное окно мастера создания требования.
Выберите роль: «Поставщик».
Выберите продукт из выпадающего списка.
Нажмите «Создать требование».

Шаг 2. Заполнение формы создания требования

Откроется форма с обязательными и необязательными полями. Рассмотрим блоки полей подробно.

Блок описания назначения требования

Краткое описание (обязательное) — краткое название или описание требования.
Полное описание (необязательное) — подробное описание правила качества данных.
Критичное требование (обязательный выбор):
- «Да» — если требование сформулировано другой командой и известно влияние ошибок на процессы заказчика.
- «Нет» — если требование техническое или создано для внутреннего контроля.
  ⚠️ Если выбрано «Нет», поле «Влияние на потребителей» становится необязательным, а блок SLA скрывается.
Влияние на потребителей (обязательное, если требование критичное) — опишите, как ошибки повлияют на потребителей данных.
Показатель качества данных (необязательное) — выберите подходящий показатель:
- Точность (Accuracy)
- Полнота (Completeness)
- Актуальность (Timeliness/Relevance)
- Уникальность (Uniqueness)

Блок SLA (целевое пороговое значение)

⚠️ Отображается только для критичных требований.

Целевое значение (SLO), % (обязательное) — процент, при котором данные считаются качественными.
Пример: 95.
🔹 Должен быть реалистичным и достижимым.
Срок исправления (RTO), часы (обязательное) — время на устранение отклонения от SLO.
Пример: 32.
🔹 Учитывайте критичность данных и возможности команды.
Инструкция при ошибке (необязательное) — ссылка на документ с порядком действий при нарушении SLO.
🔹 Убедитесь, что ссылка доступна и инструкция подробна.
Jira-проект для регистрации инцидентов (необязательное) — код проекта в Jira.
Пример: DATA-QUALITY.
🔹 Убедитесь, что код согласован и доступен для участников.

Блок Поставщик

Продукт — значение зафиксировано (установлено ранее).
Группа эксплуатации (обязательное) — название аварийной команды в ITSM-системе.
Пример: «Аварийная команда Foris».
Контактные лица (обязательное):
1. Нажмите «+».
2. Выберите сотрудника из списка.
  🔹 Убедитесь, что контакты актуальны.

Блок Проверка

Система реализации проверки (обязательное) — название ПО для мониторинга.
Если проверка без DQ, выберите «Превентивный контроль».
Название проверки (необязательное) — техническое название проверки.
Для превентивного контроля не заполняется.
Задача в Jira на реализацию проверки (необязательное) — ссылка на задачу по автоматизации.
Система-источник (обязательное) — введите ID Platform Instance из Каталога данных и выберите из списка.
База (обязательное) — название базы данных для проверки.
Схема (необязательное) — название схемы (выберите из списка).
Таблица (обязательное) — название таблицы (выберите из списка).
Атрибут (необязательное) — название атрибута (если требование касается одного поля).
Термин (необязательное) — термин из Каталога данных (выберите из списка).
Периодичность запуска (обязательное):
- По расписанию — если проверка запускается по расписанию.
- По триггеру — если проверка в рамках другого процесса (например, ETL).
Получатели алертов (необязательное) — выберите из списка лиц для уведомлений о неудачных проверках.

Шаг 3. Сохранение требования

Если все обязательные поля заполнены корректно, кнопка «Сохранить» станет активной.
Нажмите её, чтобы создать требование.

Если поле не заполнено или заполнено с ошибками, оно подсветится ошибкой с подсказкой:
«Заполните обязательное поле».

Если в "Система реализации проверки" был выбран DQ Neo, статус последнего выполнения проверки будет отслеживаться на главной странице Реестра.

Итог

Требование создано в статусе Черновик.

После создания вы можете:

Найти его в общем списке требований.
Внести изменения.
Опубликовать требование.

Чтобы опубликовать требование:

Перейдите на страницу требования.
Нажмите кнопку «Опубликовать».
После публикации статус изменится на «Активно», и требование будет готово к использованию.

Важно:

Редактирование после публикации возможно только через процедуру согласования изменений Потребителями.
Требование можно архивировать при необходимости.

Обязательные и необязательные поля

Поле/блок	Обязательность	Описание
Блок описания назначения
Краткое описание	✅ Обязательное	Краткое название или описание
Полное описание	❌ Необязательное	Детальное описание
Критичное требование	✅ Обязательный выбор	«Да» или «Нет»
Влияние на потребителей	✅ Условно обязательное	Обязательно, если требование критичное
Показатель качества данных	❌ Необязательное	Выбор из списка показателей
Блок SLA
Целевое значение (SLO)	✅ Обязательное	% качества данных
Срок исправления (RTO)	✅ Обязательное	Время на исправление (часы)
Инструкция при ошибке	❌ Необязательное	Ссылка на документ
Jira-проект	❌ Необязательное	Код проекта
Блок Поставщик
Продукт	🔒 Фиксированное	Установлено автоматически
Группа эксплуатации	✅ Обязательное	Название команды в ITSM
Контактные лица	✅ Обязательное	Ответственные сотрудники
Блок Проверка
Система реализации проверки	✅ Обязательное	ПО для мониторинга
Название проверки	❌ Необязательное	Техническое название
Задача в Jira	❌ Необязательное	Ссылка на задачу
Система-источник	✅ Обязательное	ID из Каталога данных
База	✅ Обязательное	Название БД
Схема	❌ Необязательное	Название схемы
Таблица	✅ Обязательное	Название таблицы
Атрибут	❌ Необязательное	Название атрибута
Термин	❌ Необязательное	Термин из Каталога
Периодичность запуска	✅ Обязательное	По расписанию или триггеру
Получатели алертов	❌ Необязательное	Список для уведомлений

Создание требования (для Потребителя)

Процесс создания требования для Потребителя полностью аналогичен процессу для Поставщика, за исключением выбора роли на первом шаге.

Отличие в Шаге 1:

В модальном окне мастера создания требования выберите роль: «Потребитель».

Все последующие шаги (2-3) идентичны созданию требования для Поставщика:

Заполнение блока описания назначения требования
Заполнение блока SLA (для критичных требований)
Заполнение блока Потребитель (аналогично блоку Поставщик)
Заполнение блока Проверка
Сохранение требования

После выбора роли Потребитель дальнейший процесс не отличается от описанного выше для Поставщика.