Прибейте меня, я веду проект с нуля. Часть 3🍑 В прошлых частях мы разобрали, с чего начинается работа аналитика и как зафиксировать бизнес-требования. Теперь переходим к следующему этапу — АНАЛитике описанию системы.

Если BRS отвечает на вопрос "что хочет бизнес?", то SRS — это уже про "как это должно работать?".

Что такое SRS и зачем он вообще нужен?🤔 System Requirements Specification — это документ, который связывает бизнес-требования с технической реализацией. Он описывает, как должна работать система: какие у неё функции, ограничения, интеграции, сценарии работы пользователей.

Он нужен для того, чтобы: 😕 Разработчики понимали, как должна работать система. 🐈Аналитик мог завести user story и сформировать понятные задачи. 🙄 Бизнес видел, как его хотелка будет работать.

Что должно быть в SRS?💡 1⃣ Как должна работать система. 2⃣ Какие у неё функции, ограничения и интеграции. 3⃣ Как с ней взаимодействуют пользователи.

У вас этот документ может называться по другому, но суть всегда одна: SRS — это инструкция для разработки.

В следующей части более подробно разберём, чем SRS отличается от BRS и какие ошибки чаще всего допускают аналитики при их написании.

📽Если этот пост соберёт 30 реакций, дропну шаблон, который сам использую в работе. IT АНАЛитика