Я думаю, что важно различать активность и обозначения. Как сказано выше, ранее не было никакой структуры, и поэтому каждое требование было набором строк. Варианты использования определяют цели, конкретных участников, могут включать в себя другой вариант использования или расширяться другим вариантом использования, и они могут быть даже параметризованы. Это позволяет в значительной степени устранить дублирование в этих документах с длинными требованиями. Но речь идет только о нотации, варианты использования как таковые не сопровождаются какими-либо другими действиями, чтобы выявить требования, кроме более старой техники. С другой стороны, пользовательские истории без явных письменных сценариев еще короче в обозначениях. Интересная вещь случается, когда вы пишете сценарии для пользовательских историй, как в случае с Cucumber, чем у вас есть на самом деле больше, чтобы написать и более хрупкое описание, как в случае использования, но важно то, что пользовательские истории предлагают различную активность. Вместо того, чтобы пытаться охватить сценарии заранее, вы пишете их по запросу, постепенно и итеративно, что означает, что вы можете лучше справляться с изменением требований. Однако удалить дубликаты из пользовательских историй довольно сложно, а шаблон сценариев «Предоставлено, когда» заменяет функциональный характер сценариев использования на конечные машины.