смотря как их писать)

В моей голове так:
1. User Story больше, чем Use case. У меня в сторях бывает и по 10 вариантов использования, и больше.
2. User Story - про пользу, которую получит заказчик. Если пилить варианты использования без привязки к User Story, то может оказаться так, что "Мы строили-строили, но никто не пользуется, потому что непонятно, зачем это вообще нужно было".

Нет никакой "теории юзер сторей". Есть артефакт пользовательского уровня, который включает в себя как часть бизнес-требований, так и часть функциональных. Все вместе они обеспечивают и бизнес-контекст и девелоперам с тестерами понятно че делать и че проверять. Всё:)

Как не пиши, если нет имплементации на реализацию и систему, то шашечки чистой воды. Если имплементируют на реализацию и систему, то уже часть пакета документов. Они не включают, не должны по крайней мере, они линкуются к требованиям, как бизнес, так и системным.

Вы сейчас переусложняете довольно простую вещь. Это опасный путь:)

В RUP есть Стори? Ссылочку на страницу!

Они не про пользу, истории и сценарии не польза. Это то как сторона сможет взаимодействовть. Какое отражение пользы-не пользы? Нет там этого. В сторях и кейсах.

в контексте математического моделирования использование RUP- это всё-таки смешивание кислого со сладким. Да, по прежнему есть модель предметной области (даже совпадающая по RUP), но требования - как условия накладываемые на математическую модель будут служить гипотезами для проверки, а не требуемыми вариантами использования.

Сторя только про пользу и ничего кроме пользы. Юз кейс - про минимально полезное действие.  Звучит созвучно, но не тождественно

RUP содержит в себе описание всех важных процессов для моделирования. Стоит читать без предвзятого снисхождения )

а зачем обращаться к Кумскову?

Химик и практик разработки ПО Вигерс имеет большой подтверждённый опыт работы в ИТ и собственные значимые наработки на этой основе в области инженерии требований к ПО

Химик и практик системной инженерии Левенчук имеет большой подтверждённый опыт работы в бизнесе и ИТ и собственные значимые наработки на этой основе в области системной инженерии и инженерии бизнеса

Химик-теоретик Кумсков только обучает, не участвуя в промышленных проектах разработки ПО, насколько я вижу

В RUP есть сценарии

Главное отличие imho в следующем. Юзкейс прорабатывается заранее кем-то в роли аналитика и потом передаётся в разработку как самоценное требование, полностью готовое к реализации. Юзер стори в первоначальном виде (я, как кто-то, хочу чего-то, чтобы что-то) – это начальная точка для обсуждения в команде разработки. Команда в процессе обсуждения сама принимает множество решений о том, как это требование уточнить и реализовать. Юзер стори без такого обсуждения не имеет ценности. Все остальные различия, возможно, вытекают из этого.

А можно пример, а то я запутался. Никогда в стори не видел value. Его из бизнес требования получают. С учетом что не про agile (там стори и есть BR вроде). Или мы не про value, а про другую пользу?

А я вот думал, что use case - это вариант использования (системы). То есть "система" подразумевается.  Соответственно в ВИ должно быть какое-то взаимодействие с системой.
А user story - это просто формат записи пользовательского требования. Аналог ears на более высоком уровне

Юз кейсы не требования, они линкуется к требованию. Для верификации или валидации, не помню точно.

Интересно, что эта дискуссия возникла сразу в нескольких местах. Если юзкейс не требование, то что это?

Вот и я про это

Сценарий, и он соотносится к требованию, для дальнешей верификации или валидации требования и его реализации. Он рядом с требованием, но он не требование.

Иногда юз кейс возникает до требования. Но он не является требованием.