Формат описания функциональных требований в виде пошагового сценария взаимодействия пользователей с системой по пути к цели. Стркутура use case включает: имя сценария, цель, пользователей, предусловия, триггеры, последовательность событий, результат (пост-условия). Основной фокус формата по сравнению с другими - на чётком определении последовательности действий. Эффективно применять при описании требований, в которых большое количество шагов взаимодействий и/или несколько пользователей.

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

Модель описания бизнес-логики продукта, представленная в виде перечня главных объектов системы (сущностей), их взаимосвязей и атрибутов. Правильный выбор сущностей и их взаимосвязей является ключевым фактором для построения масштабируемых, гибких и консистентных продуктов. Популярные типы связей между сущностями: ассоциация, генерализация, композиция, агрегация, абстракция. Для каждой связи определяется тип кратности. Для сущностей могут быть определены её атрибуты.

Формат описания требований к тестированию продуктов в виде пошагового сценария взаимодействия пользователей с системой. Структура test case включает: наименование, предусловия среды / окружения, значения переменных / объектов для тестирования, последовательность событий, ожидаемый результат выполнения, действительный результат выполнения и вердикт. Ожидаемый и действительный результаты могут быть приведены для каждого из шагов сценария, а не для всего тест-кейса в целом.

Карта экранов отображает реализацию user flow продукта при помощи конкретных интерфейсных решений. Карта включает в себя перечень состояний каждого элемента интерфейса и переходы между ними, инициированные пользователем или системой. Хорошая карта экранов собрана при помощи дизайн-системы компании и используется как для постановки требований в разработку, так и в качестве артефакта документации.

Условия готовности представляют собой перечень требований, которые необходимо выполнить, чтобы user story, sprint и/или release считались бы завершенными. Условия готовности могут быть определены свои для каждой роли участников команды. Например, могут включать указание метрик успешности, подготовку маркетинговых материалов, проведение презентации заинтересованым лицам или некоторым клиентам и т.д.