Существует ли точное, но простое и понятное определение различия между «сценарием использования», «пользовательской историей» и «сценарием использования»?

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

(например, http://c2.com/cgi-bin/wiki?UserStoryAndUseCaseComparison очень длинный и трудный для получения, полный обсуждения)

История пользователя - это более неформальная, удобная и уменьшенная версия варианта использования , за исключением диаграммы UML; обычно используется в итерационных сценариях.

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

Для меня самые большие различия между пользовательской историей и вариантом использования:

• Пользовательская история представляет собой легкий документ , который может быть записан на карте (Для того , чтобы, как я хочу). Пользовательская история не охватывает все детали, это неофициальная поддержка обсуждения.
• Вариант использования - это тяжеловесный документ, для которого требуется документ Word. Он описывает «Нормальный поток» шагов и / или действий и «Альтернативные потоки», которые подробно описаны. Вариант использования фиксирует все детали, это формальная спецификация.

По словам Скотта Амблера о сценариях использования , эти артефакты выглядят как поток варианта использования:

Сценарий использования , или сценарий для краткости, описывает реальный пример того , как один или более людей или организации , взаимодействующие с системой. Они описывают шаги, события и / или действия, которые происходят во время взаимодействия. Сценарии использования могут быть очень подробными, с точным указанием того, как кто-то работает с пользовательским интерфейсом, или с достаточно высоким уровнем описания критических бизнес-действий, но не с указанием того, как они выполняются.

Честно говоря, различия с потоком прецедентов не совсем ясны, даже после прочтения этого параграфа (последнее предложение, возможно, самое важное):

Как вы можете себе представить, есть несколько различий между вариантами использования и сценариями. Во-первых, вариант использования обычно относится к общим субъектам, таким как Заказчик, тогда как сценарии обычно относятся к примерам таких субъектов, как Джон Смит и Салли Джонс. Ничто не мешает вам написать общий сценарий, но обычно лучше персонализировать сценарии, чтобы повысить их понятность. Во-вторых, сценарии использования описывают один путь логики, тогда как сценарии использования обычно описывают несколько путей (базовый курс плюс любые подходящие альтернативные пути). В-третьих, в процессах на основе UP случаи использования часто сохраняются в качестве официальной документации, тогда как сценарии часто отбрасываются после того, как они больше не нужны.

Возможно, я ошибаюсь, но сценарий использования действительно звучит как поток сценариев использования, но переименован в Agile Touch.

Там нет точного определения любой из этих вещей. Все меняется немного (или сильно) от компании к компании и от системы к системе.

Лучше всего найти пример, уже существующий для вашего текущего проекта, и следовать ему.

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

Не зацикливайтесь на именах.

Пользовательская история всегда неофициальна и описывает потребности пользователя. Вариант использования может быть формальным или неформальным, и описывает поведение системы.

Можно иметь «технические» пользовательские истории, то же самое нельзя сказать о случаях использования.

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

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

Сходство между пользовательскими историями и вариантами использования состоит в том, что оба они используются для планирования и планирования.

Пользовательская история при разложении на задачи, которые индивидуально назначаются разработчикам, может быть, а может и не быть, более детальной и ограниченной по объему, чем сценарий варианта использования. Пользовательская история о потребностях пользователя - цель или результат их использования в Системе.

Примеры пользовательских историй:

1. Я - Клиент, и я хочу оплатить баланс своего счета онлайн - довольно высокий уровень просмотра
2. Я - Клиент, и я хочу обновить год истечения срока действия моей сохраненной кредитной информации - довольно подробное представление.

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

Поскольку детальность сценариев сценария использования определяется, они становятся больше о функции и процедуре.

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

Сценарии сценариев использования описывают пошаговые инструкции либо в текстовой диаграмме, либо в блок-схеме процесса (необязательно UML или BPM - я использую стандартную межфункциональную блок-схему для ясности и простоты использования неподготовленными потребителями варианта использования.

Суть в том, что пользовательские истории описывают потребности и результаты (что необходимо доставить системе), тогда как сценарии использования описывают взаимодействия между субъектами, необходимыми для достижения цели - И что может пойти не так (сценарии расширения, альтернативы или ошибки) (как пользователь взаимодействует с Система добивается такого результата)

Для более глубокого обсуждения этой темы я предлагаю прочитать http://c2.com/cgi/wiki?UserStoryAndUseCaseComparison на сайте Алистера Кокберна. Поскольку он подписал Agile Manifesto, человека, который придумал User Stories и считался экспертом по Use Case в течение последних двух десятилетий, я думаю, что он является отличным источником для получения дополнительной информации.

_{Быстрое временное примечание : этот пост нуждается в улучшениях, чтобы лучше ответить на вопрос, например, 1) дополнительные ссылки должны быть включены в ссылки 2) некоторые цитаты, возможно, 3) общая правильность английского языка 4) общее качество повествования 5) и т. Д. Я буду вернемся к этому. Не стесняйтесь улучшать это самостоятельно.}

Взгляд на их шаблоны может дать ценную информацию о различиях между этими терминами.

Случай использования

Есть несколько шаблонов для вариантов использования. Я нашел 3 после быстрого поиска: 1 , 2 , 3 . Вот некоторые общие черты, которые они (иногда смутно):

1. Название варианта использования / название
2. Описание - краткий текст, описывающий область применения.
3. Актер (ы) / Основной актер - лицо (лица), которые взаимодействуют с этим конкретным вариантом использования.
4. Предварительное условие - все, что этот вариант использования может принять за истину до начала своего жизненного цикла.
5. Сценарий успеха - последовательность шагов, описывающая правильное прохождение событий, которые происходят.

6. Расширения - поток приложения, когда он отклоняется от потока сценария успеха:

   1. Альтернативные потоки - другие варианты правильного потока
   2. Потоки исключений - поток событий, когда что-то идет не так

7. Гарантия успеха (ака. Почтовое условие) - состояние заявки после того, как все сделано

Некоторые дополнительные пункты, которые могут быть включены: Уровень , Минимальные гарантии , Триггер и т. Д.

Выше это то, что называется полностью одетый вариант использования . Вы можете упростить создание прецедентов, используя случайные прецеденты , используя только самые важные моменты, например:

1. заглавие
2. Актер (ы)
3. Цепочка событий

Варианты использования были созданы и популяризированы Иваром Якобсоном в конце 80-х начале 90-х годов. Позже другие люди также внесли свой вклад в его работу (одним из таких людей является Алистер Кокберн, который является автором « Написание сценариев эффективного использования» ). Чтобы перефразировать Мартин Фаулер случаи использования могут использовать текст и диаграммы UML, но их наибольшее значение лежит в тексте этого. Они лучше, когда они не большие и легко читаемые.

Пользовательская история _{(aka. Feature)}

Пользовательская история - небольшая история, которая описывает определенную функцию. Существует общая схема написания пользовательской истории:

Как определенный тип пользователя,
я хочу сделать что-то,
чтобы по какой-то причине .

Кроме того, пользовательская история может иметь критерии приемлемости .

Как видите, этот шаблон гораздо меньше, чем в случае использования. Пользовательские истории обычно связаны с областью разработки программного обеспечения scrum / agile / xp. Они предназначены для написания на небольших участках поверхности, таких как заметки после записи, и / или на досках. Там они (обычно) приведены значения точек , которые приближаются , сколько усилия должны быть инвестированы в эту истории пользователя ^исх .

Билл Уэйк разработал мнемонику INVEST, чтобы описать, какими качествами должна обладать хорошая пользовательская история, и я позаимствую краткое изложение этого Мартина Фаулера со своего веб-сайта :

Независимо : истории могут быть доставлены в любом порядке. По
договоренности : детали того, что находится в истории, совместно создаются программистами и заказчиками в процессе разработки.
Ценно : функциональность рассматривается как ценная для клиентов или пользователей программного обеспечения.
Оценка : программисты могут придумать разумную оценку для построения истории.
Маленький : истории должны быть построены за небольшое время, обычно за несколько человеко-дней. Конечно, вы должны быть в состоянии построить несколько историй за одну итерацию.
Тестируемый : вы должны быть в состоянии написать тесты, чтобы убедиться, что программное обеспечение для этой истории работает правильно.

Сценарий использования

Сценарий использования следует шаблону GWT, который обозначает Given-When-Then, например:

Сценарий : название
Дано : конкретный факт
И : еще один конкретный факт (может быть необязательным)
Когда : происходит какое-то событие
Затем : происходит другое событие

Сценарии использования связаны с управляемой поведением разработкой. Звучит очень похоже на тест. Мартин Фаулер в своем блоге рассказывает историю и причины использования сценариев. Вот важная часть:

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

Сценарии использования могут быть использованы для написания теста для вашего приложения. Процитирую последний абзац поста Мартина:

Хотя стиль Given-When-Then является симптоматическим для BDD, основная идея довольно распространена при написании тестов или спецификации на примере. Месарош описывает модель как четырехфазный тест. Его четыре фазы: настройка (дано), упражнение (когда), проверка (затем) и разборка. Билл Уэйк придумал формулировку «Аранжировать, действовать, утверждать».

Рекомендации для дальнейшего изучения:

Страницы Википедии для варианта использования , пользовательской истории , сценария использования
Блоги Мартина Фаулера по варианту использования , пользовательской истории , сценарию использования

Я не знаком с User Story, но когда я изучил это несколько лет назад:

Вариант использования - главная задача.
Сценарии пользователя - это различные способы выполнения этой задачи. Таким образом, каждый вариант использования имеет один или несколько сценариев. Вариант использования - это абстракция, сценарии пользователя - это каталог всех возможных экземпляров этой абстрактной задачи.

Итак:
Вариант использования A: Пользователь аутентифицируется с помощью идентификатора и пароля.

Сценарии:
1. Идентификатор распознан, пароль верный. (сценарий «солнечный день»)
2. Идентификатор распознан, пароль неверный.
3. Идентификатор распознан, неверный пароль в третий раз.
4. Идентификатор не распознан.

Я всегда думал о вариантах использования как о способе определения требований в описательной форме для клиента в их терминах. С учетом вышеизложенного, если клиент говорит: «Но что, если он попытается войти в систему между полуночью и часом, когда система не работает?», мы обнаружили другой сценарий для задачи аутентификации и некоторые дополнительные требования.

Пользовательская история с точки зрения клиента, иногда она неверна или неполна. Он может не учитывать производительность, обработку ошибок или что-либо еще в бэкэнде.

Вариант использования - с точки зрения разработчика. Это точно и полно. Он должен отвечать всем требованиям клиентов.

«Вариант использования» и «пользовательская история» одинаковы в том смысле, что они представляют «требования» клиента.

Вариант использования - это способ использования системы в каждом случае, обычно представляемый как взаимодействие между субъектом и системой или между системами.

Пользовательская история - это отправная точка в пути к созданию инструмента с помощью компьютера, который позволит конечному пользователю что-то сделать, и обычно начинается с простого предложения с использованием: кто, что, почему («Как пользователь, закрывающий приложение, я хочу мне будет предложено сохранить все, что изменилось с момента последнего сохранения, чтобы я мог сохранить полезную работу и отказаться от ошибочной работы. "). Затем эту пользовательскую историю необходимо развить в сценарий использования, который разработчики используют для создания приложения, и тестеры для проведения тестирования.

С точки зрения QA Tester, они тестируют не «пользовательские истории», а «варианты использования», то есть тестируют функциональность программного обеспечения.

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

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

Вы еще не определили, как вы собираетесь это реализовать.

С сайта product-arts .