• User Story vs Use Case

    User Story vs Use Case

User Story vs Use Case

Сучасні Agile-команди можуть описувати вимоги до програмного забезпечення за допомогою історії користувача та сценарію використання. User Story vs Use Case: яка різниця між цими підходами, чи можна обійтися без одного з вищенаведених артефактів?

Use Case

У програмній та системній інженерії фраза Use Case має два значення:

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

Use Case є структурованим, регламентованим і передбачає як мінімум двох учасників процесу: систему, яку ми плануємо розробляти, і користувача цієї системи.

Сценарії використання, як правило, об’ємні та ґрунтовні, адже описуючи їх, ви описуєте канву системи – те, як вона буде взаємодіяти з користувачем або іншою системою, реагувати на кожну дію.

Дуже зручно, що в Use Case можна:

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

Основна задача при написанні Use Case – надати максимально повну інформацію про сценарій.

Use Case обов’язково має містити в собі таку інформацію:

  • Хто використовує систему?
  • Що користувач хоче зробити?
  • Яка мета користувача?
  • Які кроки виконує користувач для виконання конкретної задачі?
  • Як система має реагувати на конкретну дію?

В Use Case не потрібно писати:

  • Особливості реалізації, тобто технічні деталі.
  • Відомості про інтерфейси користувача або екрани.

Зверніть увагу: якщо від вас вимагають будь-якої прив’язки до графічних елементів, це вже не класичний Use Case.

Бізнес і користувач можуть мати різні цілі. Задля їх задоволення ми маємо Business Case та Use Case. У Business Case відбувається фокусування на цінностях, перевагах та припущеннях, які ми маємо перевірити за допомогою Use Cases. У випадку зі сценаріями використання ми говоримо про перевірену інформацію, вимоги, процес – все те, що передбачає вимірюваний досяжний результат.

Як писати класичний Use Case

Перш за все, кожен Use Case повинен мати унікальний номер. Мають бути:

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

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

Переваги сценаріїв використання

  1. Це хороший спосіб комунікації між членами команди. Ми чітко формулюємо вимоги та формуємо площину для дискусії.
  2. UC заохочують спільну згоду щодо системних вимог.
  3. Вони надають можливість не відходячи від основного сценарію прописати альтернативи та виключення. Тобто ми одразу закриваємо всю специфіку реалізації.
  4. Use Cases дозволяють подивитися, що знаходиться за їх межами.
  5. Сценарії використання допомагають в трансформації ручних процесів в автоматичні.

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

Вигоди використання Use Cases для розробників:

  1. Команда розуміє бізнес-процеси.
  2. Розробники розуміють поведінкові шаблони та контекст, щоб надалі створити на основі Use Cases вимоги нижчого рівня.
  3. Відбувається пріоритезація робіт залежно від цінності, актуальності та мети виконання.

Переваги для тестувальника:

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

Недоліки Use Case

  1. Сценарії використання не є об’єктно орієнтованими. Вони орієнтовані на користувача. Для суто технічних і глибоко технологічних проєктів писати їх недоцільно – ви тільки марно витратите час та кошти.
  2. Відсутні правила та формальні вимоги до того, як використовувати Use Cases, хто може їх розширювати, хто є акторами. Це доволі гнучка структура.
  3. Не всі системи мають акторів, тобто не всі системи мають можливість ідентифікувати користувача як такого. У результаті ми отримуємо конфлікт, адже нам необхідно показати взаємодію двох систем за допомогою підходу, який орієнтований на користувача.
  4. Use Cases засновані на підході Waterfall – вони виникли саме в цій методиці розробки.

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

User Story

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

Зазвичай у підході Agile User Story – це менша частина епіку. Вони містять в собі три функції:

  • роль (<role>);
  • мета (<goal>);
  • цінність (<benefit>).

У класичному вигляді історія користувача не має передумов та результатів. Ми пишемо про те, як має працювати система для того, щоб задовольнити потреби користувача. Розглянемо приклад такої User Story:

As a <role>
I want <goal>
so that <benefit>

Переваги використання User Story

  1. Чітка гранулярна артикуляція – описується конкретна вимога користувача. Ми говоримо про те, що конкретний користувач хоче саме в цей момент і для чого.
  2. Краща взаємодія всіх учасників процесу. Адже ми говоримо, з одного боку, з позиції користувача, з другого – з позиції бізнесу, а з третього – мова йде про потенційну реалізацію.
  3. Можливість зменшувати ризики проєкту в контексті:
    • нечіткості визначення, адже є обмеження критеріями приймання (acceptance criteria);
    • гнучкості, адже переробити одну маленьку User Story значно простіше, ніж переписати великий Use Case.
  4. User Story – це вибір Agile-команд. Це максимальна гнучкість і повноцінна реакція на те, що ми отримаємо в результаті.

Недоліки User Story

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

User Story vs Use Case: що використовувати?

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

User Story концентрується на результатах та перевагах того, що вона описує, а Use Case – на тому, як буде функціонувати система, як вона буде взаємодіяти з кінцевим користувачем. Рішення, що саме використовувати, залишається за вами й залежить від особливостей конкретного проєкту та продукту.

Більше про User Story чи Use Casе ви можете дізнатися на курсі Business Analysis Intensive Online, а відпрацювати на практиці побудову Use Case ви можете на курсі UML: Unified Modeling Language.

Sign up for our newsletter
Get the latest info with our monthly newsletter