Требования к данным: инструкция для тех, кто не хочет переделывать

1️⃣Начинай с контекстной диаграммы
Потоки данных туда и обратно — это то, что нужно уточнять первым. Что входит? Что выходит? Какие сущности за этим стоят?

2️⃣Выделяй ключевые сущности
Любое важное существительное — кандидат в структуру данных:
Заказ, Сотрудник, Отчёт, Продукт, Поставщик.

3️⃣Словарь данных — не опция
Для каждой сущности:
🔚Название
🔚Тип (string, int, bool, object…)
🔚Длина / формат
🔚Обязательность
🔚Допустимые значения

{
"orderId": "123-XYZ", // string, обязательное
"date": "2024-10-01", // ISO date, обязательное
"isApproved": false // boolean, опционально
}

4️⃣Используй диаграмму сущность–связь (ERD)
ERD помогает связать сущности и понять бизнес-структуру, даже если у вас не будет базы данных.
🔚Визуально ➡️ понятнее
🔚У клиента ➡️ меньше вопросов
🔚У команды ➡️ меньше сюрпризов

5️⃣Матрица CRUD спасает
Создай таблицу, где по строкам — юзкейсы, по столбцам — сущности. В ячейках: C-Create, R-Read, U-Update, D-Delete.
🔣 Это помогает понять:
🔚где что создаётся
🔚кто чем управляет,
🔚не забыли ли вы важный use case

6️⃣Определяй требования к отчётам и интерфейсам
🔚Какие данные нужны?
🔚Откуда они берутся?
🔚Как часто обновляются?
🔚Какие фильтры нужны?
🔚Какой формат вывода?
Каждый отчёт = мини-интерфейс для принятия решений.

7️⃣Показывай прототипы отчетов/интерфейсов
Лучший способ собрать фидбек — показать, как это будет выглядеть. Пусть даже руками в Excel или прототипом в Миро.

🔣 Хорошо определённые данные — половина успеха проекта. Нечёткие поля, плавающие форматы и "а там разберёмся" — всегда аукнутся багами, недопониманием и переделками.

#навыкАналитика #требования #проектирование #IT