Как писать требования и документацию к проекту. Полный гайд с шаблоном документации и примерами заполнения
1. MAIN GOAL.
Здесь нам необходимо описать назначение продукта/разработки.
2. Предыстория и краткое изложение сути проекта.
3. Формулировка потребностей и ценность проекта/BACCM Canvas.
В этом разделе мы фиксируем потребности, что удовлетворяются с помощью разработки и ценности, которые принесет данная разработка. Эффективно использовать в сочетании с BACCM Canvas.
4. Цель проекта по SMART.
Хорошо сформулированная цель позволит определить направление работы и установить конкретные критерии для оценки успеха.
5. Стейкхолдеры продукта.
Указываем внутренних и внешних участников проекта. Хорошей практикой является создание матрицы стейкхолдеров или сделать анализ стейкхолдеров с помощью mindmap.
6. Границы проекта и ограничения.
Определяем границы разработки, ответственность команды (за какие этапы разработки ПО отвечает команда) и ограничения, включая бизнес-правила и регуляторные требования. Будет гораздо легче проанализировать требования и ограничения от регуляторов, если в предыдущем пункте мы сделали mindmap стейкхолдеров.
7. Функциональные требования и фичи.
В данном разделе описываем функционал разрабатываемого продукта. Я предпочитаю описывать их в формате user story с указанием роли пользователя в системе: «Как покупатель, я хочу иметь возможность заказать товар в пункт выдачи», «Как администратор пункта выдачи я хочу иметь возможность отсканировать QR пользователя для получения подробной информации о его товарах»
Данный подход хорошо сочетается с матрицей прав, в которой мы явно укажем, какие пользователи у нас есть и какие у них права для работы с системой. Но можно описать ФТ в формате USE CASE. Также можно зафиксировать диаграмму прецедентов, чтобы не забыть или не потерять часть функционала разработки.
8. Требования к интерфейсу.
Указываем требования к дизайну и пользовательскому интерфейсу. Указываем мастхев UI элементы и взаимодействие с ними.
ТЗ дизайнеру описывается следующим образом. Мы передаем ему список ФТ и отражаем способ взаимодействия пользователя с данными фичами. Например, мы передаем список ФТ для регистрации и элементы дизайна. Для процесса регистрации это будут input поля и формы ввода данных, а также кнопка подтверждения регистрации.
9. Нефункциональные требования.
Это свойства, которыми должна обладать система. Приведу примеры основных видов требований.
Безопасность. Фиксируем использование защитных протоколов и подходов. Обычно у безопасников есть требования к ПО.
Способность архитектуры к масштабированию. Указываем, должна ли архитектура быть способна к масштабированию или это конечное решение. Указываем данное требование в случаях, если хотим выпустить потенциально классную фичу, которую будем дорабатывать и развивать.
Поддерживаемые устройства и ОС.
Поддерживаемые протоколы и технологии.
Производительность. Поддержка оптимального уровня производительности. Это может заполнить архитектор или разработчик.
— RPS. Запросы в секунду: кол-во запросов в день/кол-во секунд в день.
— Пропускная способность: узнаём размер JSON запросов и ответов (берём данные из контракта API) и умножаем на RPS. Пример: (запрос 200 байт + ответ 200 байт) * rps = кбайт/сек.
— Отношение записи к чтению: считаем кол-во чтений и записей в базе данных для выполнения одного полного сценария использования и делим кол-во операций чтения на операции записи.
— Размер хранилища: умножаем сложенные элементы записи на предполагаемое кол-во операций за год.Языки и локализация. Указываем, какие языки должно поддерживать ПО.
Сохранение и продолжительность хранения данных. Например, требования хранить данные о пользователях 5 лет.
SLI. Уровень доступности. SLI — оценка работы сервиса в данный момент. SLO — договор о поддержании уровня доступности, цель которой необходимо придерживаться. SLA — уровень доступности, за нарушение которой наступают последствия, санкции.
Версионирование ПО. Ведение учёта версий и поддерживаемого этими версиями функционала. Например, данная фича должна работать на ПО версии не ниже 1.3.
НФТ можно также указывать в виде user story.
Как пользователь, я хочу, чтобы сервис был доступен 99,9% времени с 10 до 20 каждый день.
10. Матрица прав.
В матрице прав указываем, какие виды пользователей есть в системе, и какие права/возможности взаимодействия с системой им стоит выдать.
11. Вопросы и проблемные моменты
Указываем нюансы, которые необходимо учесть при разработке или раскатке ПО в прод.
