Принципы формирования документации проекта

Вся требуемая функциональность должна быть описана в виде пользовательских историй. Для этого требуется бизнес-аналитик, который совместно с командой дизайна будет фиксировать разрабатываемую функциональность и пользовательские сценарии 
в виде User Story, сгруппированные по эпикам, которые в свою очередь должны быть сгруппированы по ролям пользователей сервиса.Для разработки непосредственно задачей является сформированная 
и описанная по шагам User Story.

Роль представляет собой совокупность пользователей с схожими обязанностями и целями, с которыми он приходит к использованию сервиса.
Роль может диктоваться:
1. Должностными инструкциями (прям прописанный реестр обязанностей на рабочем месте);
2. Рабочими целями и обязанностями, не зафиксированными 
в должностных инструкциях;
3. Периодически или разово возникающими потребностями (в таком случае термин «роль»меняется на «сегмент»).
Для документации роль является совокупностью пользовательских сценариев.Документ, описывающий состав ролей и их укрупненные обязанности называется ролевой моделью и служит базой для создания дальнейшей документации.

Эпик — это укрупненная функциональность системы, представляющая собою отдельный модуль, внутри которого может быть вложено множество пользовательских сценариев. По факту это дополнительная группирующая сущность, когда пользовательских сценариев становится много. Для небольших (до 5-10 пользовательских сценариев на роль) систем описание эпиков не требуется.

Соответственно для сокращения наименования страницы 
в документации конкретной User Story даётся сокращенное наименование, которое можно описать как сценарий.

Далее непосредственно по шагам описывается выполнение пользовательского сценария.

Критерии приёмки описывают конкретные действия в интерфейсе 
и отдельные UI-элементы экранных форм (кнопки, и состояния и т.д.) 
с целью приёмки итоговой реализации. Для упрощения работы с критериями приёмки с целью описания элементов интерфейса предлагается использовать ссылки на макеты в Figma (UI-kit или актуализированная документация состояния продукта).

Описанная функциональность должна поддерживаться в актуальном виде и обновляться при согласовании новых сценариев или же при согласовании корректировки старых.<aside> Описанные сценарии должны согласовываться оунером при участии менеджера команды дизайна, бизнес-аналитика, менеджера разработки.
</aside> Для поддержания документации предлагается использовать инструментарий Confluence.

При разработке функциональности рекомендуется создать сводную таблицу (бэклог) User Story, состоящую из следующих столбцов:

1. Наименование User Story с ссылкой на страницу с полноценным описанием;
2. Приоритет реализации User Story (низкий, средний, высокий, наивысший);
3. Релиз / спринт, в рамках которого планируется реализовать User Story;
4. Статус описания User Story со стороны аналитики:

5. Статус создания артефактов дизайна для User Story:

6. Статус разработки User Story (не перечисляются, так как зависят 
от конкретной команды разработки, однако идеально настроить автообновление статуса в Confluence в зависимости от изменения статуса в Jira);
7. Наименование задачи на разработку с ссылкой в Jira.

Рекомендуется вести отдельный документ, в котором будут фиксироваться принятые решения в рамках проекта. Например, упрощение какой-то функциональности, изменение приоритета и т.д. При этом фиксировать, когда было принято решение, кем (желательно указать полный состав согласовавших), по какой причине и область влияния.

Бизнес-функциональные требования формируются из пожеланий бизнес-заказчика и не привязываются к конкретным эпикам или User Story. Это «сырой» продукт, который далее ляжет в основу полноценного ТЗ, в котором BN (Business Needs — потребности бизнеса) будут разложены на эпики. Аналогично User Story рекомендуется не указывать UI-элементы в БФТ (если, конечно, нет каких-либо специфичных ограничений), чтобы не ограничивать решение дизайнера, которое довольно сильно может измениться по результатам предварительных исследований.По сути в БФТ указываются требования, сгруппированные по модулям предполагаемого решения.

Техническое задание составляется до начала работ над планируемой для реализации функциональностью, либо пишется параллельно 
с процессом первоначальных исследований.

Техническое задание должно содержать в себе:
1. Ролевую модель;
2. Верхнеуровневое описание эпиков (модулей системы), в рамках которых планируется реализовывать пользовательские сценарии;
3. Этапы разработки (если есть ограничение по реализации MVP 
и последующих очередей сдачи — особенно актуально для проектов, связанных с госконтрактами);
4. Платформы, для которых разрабатывается сервис;
5. Ограничения по версии ОС (например, для Android не ниже API 6.0), 
а для web-решений ещё и список браузеров и их версий, которые должен поддерживать интерфейс;
6. Ограничения о технике, в которой пользователи будут взаимодействовать с интерфейсом (например, разрешение экрана не менее 1280х720);
7. Соответствие стандартам доступности, если такие ограничения накладываются (ссылка на ГОСТ, на WCAG актуальной версии или прямое перечисление, например, «Размер шрифта должен быть не менее 16pt»);
8. Стек разработки;
9. Технические ограничения, связанные со стеком разработки.

Вместе перечисления конкретных решений рекомендуется указать, что приёмка должна проводиться согласно критериям приёмки, которые описываются и согласовываются согласно принципам выше.