Без заголовка

Не все так просто. Use cases и user stories, конечно, различаются -- но они про функциональные требования. А головная боль при работе с требованиями во многом идет от нефункциональных требований, и много-много практик как раз завязано на обеспечение нефункциональных требований. Заметим, что в языке URN два подъязыка -- один про use cases, а другой про goals. Это не случайно. Но это уже другая история, про содержание, а не про форму. Я же сейчас про форму, моделирование метода. При работе с требованиями крайне важна инкрементальность, порождение при добавлении или вычеркивании какого-то элементарного требования волны изменений во всех остальных моделях. Это "интерактивное программирование", о котором я несколько раз писал. Это rocket science на сегодняшний день, и именно это нужно будет проработать. Issue trackers именно от этой группы описаний. Но фишка в том, что есть и другие группы описаний требований, и их упускать из виду тоже нельзя.