Прибейте меня, я веду проект с нуля. Часть 2🍑

В прошлой части мы разобрали, с чего вообще начинается работа аналитика, на новом проекте.

Если выжили после этого этапа, самое время поговорить про финальный бизнес-документ, который зафиксирует все требования, границы и договорённости, чтобы потом не оказалось, что «мы вообще-то хотели другое».

Когда всё обсудили, уточнили и вроде даже договорились — надо не просто держать это в голове или чатах, а оформить в структурированный документ, чтобы:

🙄 Бизнес понимал, что получит в итоге.
😿 Команда работала без сюрпризов, зная границы проекта и его объём.
💩 Не получилось «ой, а давайте ещё вот это добавим» за неделю до релиза.

Что такое BRS и зачем он нужен?
📌 BRS (Business Requirements Specification) — документ, который фиксирует ожидания бизнеса от проекта. Это базовая точка, которая не даёт проекту разрастись и превратиться в снежный ком неопределённости скатиться в говно.

Что должно быть в BRS?
🔤 Цель проекта — какую проблему решаем?
🔤 Область применения — кто будет пользоваться системой и как?
🔤 Границы проекта — что делаем, а что не делаем?
🔤 Ключевые бизнес-правила — ограничения, регуляторные требования, KPI.
🔤 Функциональные требования — какие возможности должна дать система бизнесу?
🔤 Нефункциональные требования — интеграции, производительность, ограничения.

Важно понимать, что BRS — это не технический документ. Здесь нет API, БД или схем архитектуры. Это про что и зачем, а как — это уже будем разбирать позже.

Что дальше?
BRS — это только первый шаг. Дальше его нужно детализировать и перевести в конкретные требования для разработки. В следующей части поговорим про SRS и как превратить бизнес-требования в рабочую спецификацию без боли.

Прикрепил к посту свой шаблон BRS, пользуйтесь.

А как у вас фиксируют договорённости с бизнесом? Делитесь в комментах! 🤔

IT АНАЛитика