Ответ
Требования, как правило, оформлялись в виде комбинации следующих артефактов, что обеспечивало четкое понимание задачи всеми участниками (разработчиками, тестировщиками, аналитиками).
Основные форматы:
-
User Stories (Пользовательские истории) в Jira/YouTrack:
- Следовали шаблону: Как [роль], я хочу [возможность], чтобы [выгода].
- Обязательно содержали Критерии приемки (Acceptance Criteria — AC) — четкий список условий, при которых история считается выполненной.
-
Технические спецификации и документация:
- API: Спецификации в OpenAPI (Swagger).
- Базы данных: ER-диаграммы, описание миграций.
- Бизнес-логика: Детальные страницы в Confluence или Notion с описанием процессов, edge-кейсов и бизнес-правил.
-
Дизайн-макеты:
- Мокапы интерфейсов из Figma, Adobe XD или Sketch, часто с интерактивными прототипами.
Пример User Story с критериями приемки:
Задача: FILTER-101
Заголовок: Фильтрация товаров по цене
Как покупатель,
Я хочу иметь возможность фильтровать товары по диапазону цен,
Чтобы быстро находить товары, соответствующие моему бюджету.
Критерии приемки (AC):
- Поле фильтра "Цена от" и "Цена до" отображается в боковой панели.
- При вводе значений и нажатии кнопки "Применить" список товаров обновляется без перезагрузки страницы (AJAX).
- Если поле "Цена до" пустое, фильтр работает как "от N и выше".
- Валидация: поля принимают только положительные числа.
- При некорректном вводе отображается текстовая подсказка об ошибке.Для сложных интеграций или процессов дополнительно использовались sequence-диаграммы (UML) и BPMN-диаграммы. Конкретный набор артефактов зависел от зрелости процессов в команде и сложности задачи.