Шаблон BRD&SRS

BRD&SRS - это документ, объединяющий основные аспекты разработки, включая описание целей проекта, его историю, потребности и ценности, заинтересованных стейкхолдеров, границы проекта и ограничения, функциональные и нефункциональные требования, а также ключевые вопросы и проблемы.

1. MAIN GOAL. Тут нам необходимо описать назначение продукта/разработки.
2. Предыстория и краткое изложение сути проекта.
3. Формулировка потребностей и ценность проекта/BACCM canvas. В этом разделе мы фиксируем потребности, которые удовлетворяются с помощью разработки, и ценности, которые принесет данная разработка. Эффективно использовать в сочетании с BACCM Canvas.

1. Цель проекта по SMART. Хорошо сформулированная цель позволит определить направление работы и установить конкретные критерии для оценки успеха.

2. Стейкхолдеры продукта. Указываем внутренних и внешних участников проекта. Хорошей практикой является создание матрицы стейкхолдеров или сделать анализ стейкхолдеров с помощью mindmap.

   

3. Границы проекта и ограничения. Определяем границы разработки, ответственность команды (за какие этапы разработки ПО отвечает команда) и ограничения, включая бизнес-правила и регуляторные требования. Будет гораздо легче проанализировать требования и ограничения от регуляторов, если в предыдущем пункте мы сделали mindmap стейкхолдеров.

4. Функциональные требования и фичи. В данном разделе описываем функционал разрабатываемого продукта. Я предпочитаю описывать их в формате user story с указанием роли пользователя в системе. “Как покупатель, я хочу иметь возможность заказать товар в пункт выдачи.”, “Как администратор пункта выдачи, я хочу иметь возможность отсканировать QR пользователя для получения подробной информации о его товарах. Данный подход хорошо сочетается с матрицей прав, в которой мы явно укажем какие пользователи у нас есть и какие у них права в для работы с системой. Но можно описать ФТ в формате USE CASE. Также можно зафиксировать диаграмму прецедентов, чтобы не забыть или не потерять часть функционала разработки.

5. Требования к интерфейсу. Указываем требования к дизайну и пользовательскому интерфейсу. Указываем мастхев UI элементы и взаимодействие с ними. ТЗ дизайнеру описывается следующим образом. Мы передаем ему список ФТ и отражаем способ взаимодействия пользователя с данными фичами. Например, мы передаем список ФТ для регистрации и элементы дизайна. Для процесса регистрации это будут input поля и формы ввода данных и кнопка подтверждения регистрации.

6. Нефункциональные требования. Это свойства, которыми должна обладать система. Приведу примеры основных видов требований.

• Безопасность
• Способность архитектуру к масштабированию. Указываем, должна ли архитектура быть способна к масштабированию или это конечное решение. Указываем данное требования в случаях, если хотим выпустить потенциально классную фичу, которую будем дорабатывать и развивать.
• Поддерживаемые устройства и ОС.
• Поддерживаемые протоколы и технологии.
• Интуитивно понятный интерфейс для пользователя.
• Производительность. Поддержка оптимального уровня производительности. Это может заполнить архитектор или разработчик.
  • RPS. Запросы в секунду: кол-во запросов в день/кол-во секунд в день
  • Пропускная способность: узнаем средний размер json запросов и ответов и умножаем на RPS. То есть (запрос 200 байт + ответ 200 байт) * rps = кбайт/сек
  • Отношение записи к чтению: считаем кол-во чтений и записей в базе данных и делим кол-во операций чтения на операции записи.
  • Размер хранилища: умножаем сложенные элементы записи на предполагаемое кол-во операций за год.
• Языки и локализация. Указываем, какие языки должно поддерживать ПО.
• Сохранение и продолжительность хранения данных. Например, требования хранить данные о пользователях 5 лет.