Как мы создали шаблон функциональных требований

Конспект статьи. Автор оригинала: Татьяна Цикунова и Елизавета Маркова (МТС)

Системные аналитики МТС рассказывают, как сделали единый шаблон функциональных требований для фронтовой функциональности. Раньше каждый писал по-своему, и тестировщикам и разработчикам приходилось разбираться в разных форматах. ГОСТы показались перегруженными, а UML покрывает лишь отдельные диаграммы.

Структура шаблона

• Точки входа — как пользователь попадает в функциональность, со скриншотами и ссылками на смежные фичи.
• Бизнес-требования — суть в двух предложениях, обоснование, границы и роли, ограничения, схемы AS-IS/TO-BE, макеты, НФТ.
• Сценарии использования — пошаговое взаимодействие пользователя, фронта и бэка с предусловиями, основным и альтернативными потоками. Это основа для тест-кейсов. Основной сценарий — не больше примерно девяти шагов, иначе его стоит дробить.
• Архитектура — обязательная sequence-диаграмма (можно в PlantUML) и список API-методов.
• Дизайн — таблица экранных форм: макет, элементы, логика поведения.

Описание полей

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

Организация и выводы

Головная страница в Confluence собирает части через вкладки и включение страниц, под каждым блоком — ссылки на задачи в Jira. Шаблон адаптируют под команды и развивают по обратной связи от аналитиков, тестировщиков и разработчиков. Авторы честно говорят о компромиссе между подробностью документации и скоростью её подготовки.