Предпредистория

Информация об User story доступна здесь.

Если коротко, типовой формой пользовательской истории является:

"Как <роль>, я хочу <цель/пожелание>, что позволит <выгоды>"

Предисловие

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

"<Роль>, для <требование бизнеса> использует <требование к системе>"

Лично мне такой вид более нагляден и, опираясь на него, мне проще формулировать пользовательские истории. Приведу пример, оставив для наглядности квадратные скобки: <Пользователь раздела инвстиции>, для <фиксирования факта регистрации отчета о выпуске акций государственным органом> использует <Кнопку "Отчет об итогах выпуска акций зарегистрирован", что переводит эмиссию в статус "Зарегистрировано" и предлагает ввести дату регистрации отчёта>.

Для возможности создания трассировок так же хотелось бы дополнить данную формулу префиксом и уникальным номером:

"<Префикс><Номер>. <Роль>, для <требование бизнеса> использует <требование к системе>"

Теперь я создаю несколько абстрактных требований.

US 1.1. Роль1, для ТБ1 использует ТС1

US 1.2. Роль1, для ТБ1 использует ТС2

US 1.3. Роль2, для ТБ2 использует ТС3

US 1.4. Роль3, для ТБ1 использует ТС4

US 1.5. Роль3, для ТБ2 использует ТС5

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

Предложенный вариант

Для удобной фильтрации я предлагаю вести данный список пользовательских историй в екселевской таблице:


(вложение)

Вопрос:

Имеет ли такой подход право на существование? Учитывя, что я просто записывал поток мыслей, в логике могут быть косяки, но мне интересна сама суть..
И практика использования..

Право на существование имеет все, что помогает достигать цели, имхо.
Я пока не уловил основной цели, кроме удобных возможностей фильтрации (но это скорее средство достижения какой-то не озвученной цели)
А если US заменить на UC, и ТБ на  UC, то получится что-то вроде
UС 1.1. Роль1, для UC1 использует ТС1
UС 1.2. Роль1, для UC1 использует ТС2
что-то это мне напоминает

Прошу простить, если не в тему, но есть мнение, что UserStory по большому счету являются не требованиями, а именно трассировкой требований определенных видов друг на друга. А способ конечно имеет право на существование, если он решает ваши задач.

да, по скти так, если у вас не маленький проект. и да - user sory это отличная трассировка
Просто хотелось бы комментарии из практики, + - и тп услышать...