Чи є чітке, але просте та зрозуміле визначення різниці між "випадком використання", "Історією користувача" та "Сценарієм використання"?

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

(наприклад, http://c2.com/cgi-bin/wiki?UserStoryAndUseCaseComppare дуже довгий і важкий для отримання, повний дискусій)

Історія користувача є більш неформальним, доброзичливим і зменшеним варіантом варіанти використання , мінус діаграма UML; зазвичай використовується в ітеративних сценаріях.

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

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

• Історія користувача - це легкий документ, який можна записати на карту (Для того, щоб, як я хочу). Історія користувача не містить усіх деталей, це неформальна підтримка дискусії.
• Випадок використання є важковаговиком документ , який потребує в текстовий документ. Він описує "нормальний потік" кроків та / або дій та "альтернативних потоків", які детально описані. Використовуваний кейс фіксує всі деталі, це формальна специфікація.

За словами Скотта У. Амблера з сценаріїв використання , ці артефакти виглядають як потік Use Case:

Сценарій використання , або сценарій для стислості, описує реальний приклад того , як один або більше людей або організації , які взаємодіють з системою. Вони описують кроки, події та / або дії, які відбуваються під час взаємодії. Сценарії використання можуть бути дуже детальними, вказуючи, як саме хтось працює з користувальницьким інтерфейсом, або на досить високому рівні, описуючи критичні ділові дії, але не вказуючи на їх виконання.

Чесно кажучи, відмінності в потоці Use Case не є кришталево зрозумілими навіть після прочитання цього пункту (останнє речення, можливо, найважливіше):

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

Можливо, я помиляюся, але сценарій використання справді звучить як течія Use Case, але ребрендинг з Agile дотиком.

Немає точного визначення жодного з цих матеріалів. Це все трохи (або багато) варіюється від компанії до компанії та від системи до системи.

Ваша найкраща ставка - знайти приклад для вашого поточного проекту та слідувати за ним.

Якщо ви створюєте нову систему, ви можете знайти визначення різних типів випадків використання для будь-якої системи, яку ви віддаєте перевагу. Просто виберіть шаблон, який, здається, найкраще повідомляє ваші наміри.

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

Історія користувача завжди неформальна і описує потребу користувача. Випадок використання може бути формальним чи неофіційним та описує поведінку системи.

Можливо, є "тек" історії користувачів, те ж саме не стосується випадків використання.

Після завершення історія користувача зазвичай відкидається. Випадки використання можуть зберігатися протягом життєвого циклу виробу.

Обсяг також різний. Історії користувачів зазвичай мають менший обсяг, і, отже, випадок використання містить кілька історій користувача. Змінена вимога до існуючої системи описана в новій історії користувача або оновленій версії випадку використання.

Подібність між історіями користувачів та випадками використання полягає в тому, що обидва вони використовуються для планування та планування.

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

Прикладами історій користувачів є:

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

На найвищому рівні абстрагування Служба використання звучить дуже схоже - Рік закінчення терміну дії картки оновлень клієнта - але тут його заява про функцію, а не мета.

Оскільки деталізація сценаріїв використання випадків визначена, вони стають більш детальними щодо функції та процедури.

Основний сценарій використання випадків після використання має бути таким же результатом, як і в Сторінці користувача - Рік закінчення терміну дії кредитної картки Клієнта оновлений.

Сценарії використання сценаріїв описують поетапно або в тексті, або в діаграмі потоку процесу (не обов'язково UML або BPM - я використовую стандартну міжфункціональну діаграму потоку для ясності та зручності використання непідготовленими споживачами випадків використання.

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

Для обговорення в глибині цієї теми я пропоную прочитати http://c2.com/cgi/wiki?UserStoryAndUseCaseComparing на веб-сайті Alistair Cockburn. Оскільки він підписав маніфест "Agile", людина, яка вигадала Історії користувачів і протягом останніх кількох десятиліть вважається експертом з питань використання, я вважаю, що він є чудовим джерелом для отримання додаткової інформації.

_{Швидка тимчасова примітка : Ця публікація потребує вдосконалення, щоб краще відповісти на питання, наприклад, 1) додаткові деталі повинні бути включені з посилань 2) деякі цитати, можливо, 3) загальна правильність англійської мови 4) загальна якість розповіді 5) тощо. Я буду повернутися до нього. Сміливо вдосконалюйте його самостійно.}

Перегляд їхніх шаблонів може дати цінну інформацію про відмінності між цими термінами.

Використовуйте футляр

Існує кілька шаблонів для випадків використання. Після швидкого пошуку я знайшов 3: 1 , 2 , 3 . Деякі моменти, які вони (іноді розпливчасто) мають спільне, є:

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

6. Розширення - потік програми, коли він відхиляється від потоку сценарію успіху:

   1. Чергові потоки - інші варіанти правильного потоку
   2. Виключення тече - потік подій, коли справи йдуть не так

7. Гарантія успіху (ака. Post post) - стан заявки після того, як все зроблено

Деякі додаткові моменти, які можна включити, - це рівень , мінімальні гарантії , тригер тощо.

Зверху - те, що називається повністю одягненим футляром . Ви можете спростити створення справ із використанням випадкового випадку , використовуючи лише найважливіші точки, наприклад:

1. Назва
2. Актор (и)
3. Послідовність подій

Справи використання були створені та популяризовані Іваром Якобсоном наприкінці 80-х на початку 90-х. Пізніше інші люди також внесли свій внесок у його творчість (одним з таких людей є Алістер Кокберн, автор " Написання справ про ефективне використання" ). Якщо перефразовувати випадки використання Мартіна Фаулера, можна використовувати текстові та UML-діаграми, але їх найбільше значення лежить у тексті цього тексту. Вони найкращі, коли вони не великі і їх легко читати.

Історія користувача _{(ака. Особливість)}

Історія користувача - невелика історія, яка описує певну особливість. Існує загальна модель написання історії користувача, яка є:

Як певний тип користувача,
я хочу щось
зробити, щоб з якоїсь причини .

Крім того, історія користувача може мати критерії прийняття .

Як ви бачите, цей шаблон набагато менший, ніж у випадку використання. Історії користувачів зазвичай асоціюються з областю scrum / agile / xp розробки програмного забезпечення. Вони призначені для написання на невеликих ділянках поверхні, наприклад, після приміток та / або на дошках скрабів. Там їм (як правило) задаються точкові значення, які орієнтовно орієнтуються на те, скільки зусиль потрібно вкласти у цю історію користувача ^ref .

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

Незалежно : розповіді можуть бути передані в будь-якому порядку.
Переговорний : деталі того, що є в історії, створюються спільно програмістами та замовником під час розробки.
Цінні : клієнти або користувачі програмного забезпечення функціональність вважають цінною.
Оціночне : програмісти можуть прийти з розумною оцінкою для побудови історії
Малий : розповіді слід будувати за невелику кількість часу, як правило, це стосується людей-днів. Звичайно, ви повинні мати можливість скласти кілька сюжетів за одну ітерацію.
Тестируемость : ви повинні мати змогу писати тести, щоб перевірити, чи програмне забезпечення для цієї історії працює правильно.

Сценарій використання

Сценарій використання слідує шаблону GWT, який означає "Дано-Коли-Потім", наприклад:

Сценарій : назва
Дано : конкретний факт
І : ще один конкретний факт (може бути необов'язковим)
Коли : якась подія трапляється
Тоді : трапляється якась інша подія

Сценарії використання пов'язані з розвитком поведінки. Це звучить дуже схоже на тест. Мартін Фаулер у своєму дописі на блозі розповідає про історію та міркування щодо сценаріїв використання. Ось важлива частина:

Даються частина описує стан світу , перш ніж почати поведінку якої потрібно вказати в цьому сценарії. Ви можете подумати про це як про передумови тесту.
Розділ " коли " - це та поведінка, яку ви вказуєте.
Нарешті, тодішній розділ описує зміни, які ви очікуєте через задану поведінку.

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

Хоча стиль Given-When-then є симптоматичним для BDD, основна ідея досить поширена при написанні тестів або специфікації на прикладі. Мецарос описує модель як чотирифазний тест. Його чотири фази - Налаштування (Дано), Вправа (Коли), Перевірка (Тоді) та Тередаун. Білл Уейк придумав формулювання як «Упорядкувати, діяти», «затвердити».

Довідники для подальшого вивчення:

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

Я не знайомий з історією користувачів, але коли я вивчив це кілька років тому:

Справа використання - головне завдання.
Сценарії користувачів - це різні способи виконання завдання. Отже, у кожному випадку використання є один або кілька сценаріїв. Справа використання - це конспект, сценарії користувача - це каталог всіх можливих випадків цього абстрактного завдання.

Отже:
Використовуйте випадок A: Користувач автентифікується за допомогою id та пароля.

Сценарії:
1. Ідентифікатор розпізнається, пароль правильний. (сценарій "сонячного дня")
2. Ідентифікатор розпізнається, пароль невірний.
3. Ідентифікатор розпізнається, пароль не вводиться втретє.
4. Ідентифікатор не розпізнається.

Я завжди думав про використання випадків як спосіб визначення вимог в розповідний спосіб для клієнта в їхніх термінах. без / вище / якщо вище, якщо клієнт каже "Але що робити, якщо вони спробують увійти між півночі та одним, коли система не працює?", ми виявили ще один сценарій завдання аутентифікації та деякі додаткові вимоги.

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

Випадок використання - з точки зору розробника. Це точно і повно. Він повинен відповідати всім вимогам клієнтів.

"Випадок використання" та "Історія користувача" однакові в тому сенсі, що вони представляють "вимоги" замовника.

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

Історія користувача - це відправний момент у створенні інструменту, який підтримує комп'ютер, який дозволить кінцевому користувачеві щось зробити, і зазвичай починається з простого речення з того, хто, що, чому ("Як я закриваю програму, я хочу щоб було запропоновано зберегти все, що змінилося після останнього збереження, щоб я міг зберегти корисну роботу та відкинути помилкову роботу. "). Потім цю історію користувача потрібно перетворити на випадок використання, який розробники використовують для створення програми, а тестери - для проведення тестування.

З точки зору тесту QA, вони не перевіряють "історії користувачів", а "випадки використання", тобто вони перевіряють функціональність програмного забезпечення.

Метою сценарію використання є відображення суті взаємодії користувача з вашою системою щодо досягнення мети, не заглиблюючись у деталі системних дій чи власне проектування. Основна увага приділяється користувачеві, а не системі.

... Use Case також включає заяви про те, що робитиме система, тоді як сценарій використання уникатиме цього обговорення.

Ви ще не визначилися, як збираєтесь це реалізувати.

З сайту product-arts .