Продолжаем публиковать путеводитель по бизнес-анализу. Простую карту, по которой сможет пройти любой: начинающий аналитик, тестировщик, проджект или просто любознательный человек, которому нужно понять, как устроены системы. В прошлых статьях этой серии уже много и подробно написано про диаграммы, вопросы к заказчику, UX, базы данных… настало время API.
С вами снова бизнес-аналитик, который умеет превращать хаос требований в работающие базы. На этот раз говорим про логическую модель данных. Ту самая, на которой обычно всё и начинает идти не по плану. Если вы уже сталкивались с таблицами, которые «вроде бы работают, но никто не понимает как», то вам сюда. Объясняем почти на пальцах и с примерами. Вы поймете, даже если все кажется сложным! Полезно аналитикам, архитекторам, всем, кто проектирует под что-то большее, чем «лишь бы завелось».
Сегодня вторник, а значит, мы с бизнес-аналитиком Юлией Чугуновой разбираем архитектуру данных – от бизнес-сущностей до связей в БД (базе данных). Учимся переводить требования в структуру таблиц, разбираем, как избежать «костылей» в базе и почему ошибки в данных дороже багов. И главное – учимся строить реляционные модели, которые не развалятся при масштабировании.
В первой части мы учились слушать заказчика и вытаскивать из «у меня что-то не так» конкретные проблемы. Во второй – собирали разрозненные мнения команды в систему и ставили SMART-цели.
Теперь настало время документирования. Потому что даже самые гениальные идеи превращаются в хаос, если их не зафиксировать. В этой части разберём: BRD, SRS и Backlog, функциональные и нефункциональные требования. А еще попробуем превратить расплывчатое «хочу что-то про лояльность» в чёткие требования.
