Сможете развернуть также, как Дмитрий? Задача отследить поворот и предупредить за 300 и 30 метров, а также перестроить маршрут, если проскочил — это бизнес-контекст или критерии приемки?

Маленькое примечание.
ВИ тоже могут быть представлены на пользовательском уровне в виде пользовательских сценариев

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

Ну я так понял то, что читал :)))

Можно, но попозже, как у компа буду

Итак. Во-первых тут будут две истории. Первая про предупреждения, вторая про перестройку маршрута.

В первой будут критерии приемки типа:
1. При движении по маршруту юзер должен получать два оповещения перед каждым следующим поворотом, за 300 и 30 метров.
1.а. Если следующий поворот наступает ранее 300 метров, юзер оповещается сразу при появлении поворота.

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

С перестройкой маршрута тоже самое. В критериях приемки мы определяем как мы проверим сторю и что все сработало как надо. Но все пишем с точки зрения юзера, т.к. он у нас проводит валидацию и нам важно чтобы, например, не система отправила оповещение, а юзер получил его.

полностью поддерживаю!

Спасибо

Не связанные, но на мой взгляд юк может быть связан с множеством юс

Доклад был об этом хороший https://analystdays.ru/ru/talk/71737

В довольно известной книге Алистера Коберна о юзкейсах есть страничка об истории их возникновения. Главка "Преемственность идей" в начале книги. Не самый такой большой исторический обзор на самом деле.

"В конце 60-х годов Ивар Якобсон, работая над телефонными системами в компании Ericsson, изобрел то, что позднее получило название вариантов использования (use cases). В конце 80-х он представил их специалиставм по объектно-ориентированному программированию. Они получили признание, заполнив брешь в процессе формирования требований. В начале 90-х я прошел курс у Якобсона. Ни он, ни его команда не пользовались моими терминами цель (goal) и неудача (goal failure), однако на самом деле они применяли эти понятия. В нескольких случаях мы с ним не нашли серьезных противоречий между его и моей моделью. Я расширил его модель, чтобы осовременить ее."

А как до 60-х в инженерном деле оформляли правки к системам? Неужели ж не выделяли каких-то специальных методов? И писали просто некие "правки от заказчика". Что-то вроде: "Паровая машина нашего Титаника слишком шумит, пассажиры жалуются", или "Когда водитель до упора нажимает на педаль газа танка, наводчик не должен ударяться лбом о прицел пушки", или "Чтобы подняться на последний этаж нашего небоскреба, посетитель нажимает в лифте здания кнопку с номером 20"?

В общем случае связь между UC и US - многие ко многим

(и спасибо, что вспомнили мой доклад :)

А, например, у математиков как оформляли и оформляют правки и требования к математическим моделям? Особенно, если это большие модели, которые создают большие коллективы и многие годы?

Постановки задачи же есть. Это и есть требования к задаче

Спасибо!

Загуглил. Тут http://systems-analysis.ru/mathmodeling_process.html:

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

Получается, user story - можно сказать, гипотезы, а код на основе user story - это доказательство гипотезы?

я бы не бросалась словами доказательство - проверка гипотезы.

Если обратиться к RUP и Кумскову, то UserStory основа для проектирования модели вариантов использования (UCM). Но сейчас наблюдается тенденция трансформация терминов, что приводит к разночтению вполне однозначныз определений

Вот не могу отделаться от ощущения, что вся теория юзер сторей - это про шашечки, а не ехать

Не у Вас одного такое впечатление ).