Хочете краще зрозуміти, як ваш продукт вирішує проблеми користувачів? Або пояснити команді, які саме сценарії потрібно реалізувати? У такому разі вам знадобиться use case.
Use Case – це опис конкретного сценарію використання продукту або системи з точки зору користувача, що показує, як він досягає своєї цілі за допомогою функціоналу.
У цій статті ми розглянемо, як формулюються use cases, навіщо вони потрібні в бізнесі й розробці, і як створювати їх грамотно та ефективно.
Поняття Use Case
Use Case являє собою техніку взаємодії об’єктів, згідно з певним сценарієм. Зокрема, опис може бути надано і користувацькій вимозі, і системній, і комунікації реальних людей і компаній.
Наприклад, це може бути взаємодія двох людей (під час продажу або купівлі) або людини з програмою.
Use Case використовуються в різних сферах: від розробки ПЗ до формування бізнес-процесів. Головні вимоги – ясність і лаконічність, адже від цього залежить, чи зрозуміють його в принципі.
Якщо говорити узагальнено, то Use Case – це сценарій, що описує взаємодію кількох учасників, яка відбувається з певною метою, наприклад:
- відпуск товару, де здійснюється співпраця між продавцем і покупцем;
- передача інформації електронною поштою – відправник взаємодіє з поштовим клієнтом;
- пошук сторінки браузером (браузер – веб-сервер).
За такого варіанту використання Use Case, як розробка програмного забезпечення, сценарій необхідний для опису взаємодії між користувачем і системою. Власне, у цьому контексті ми й розглядатимемо поняття в нашій статті.
Раніше вимоги до роботи системи встановлювали за допомогою створення окремих функцій, поки в 1990-х рр. Івар Якобсон не запропонував використовувати Use Case як додатковий інструмент визначення функціональності програми. Ідея полягала в тому, щоб вимоги до системи описувалися не за допомогою окремих функцій, а у вигляді опису контексту і послідовності користувацьких дій.
На думку шведського вченого, ця розробка дає змогу відтворити набір вимог, здатний забезпечити повноту взаємодії.
Коли необхідний Use Case
- розробнику, завданням якого стає створення алгоритму подій. У цьому разі сценарій допомагає визначити результат, одержуваний після вчинення тієї чи іншої дії;
- замовнику, який, завдяки простоті та доступності викладу, може робити висновки про те, що мета досягнута, або, навпаки, вимагати внести зміни в сценарій;
- тестувальнику, який проводить перевірку працездатності програми;
- команді проекту, у випадках, коли сценарій має бути узгоджений, але при цьому періодично виникають альтернативні варіанти. Упорядкований опис потоку подій допоможе не
- відступити від основної ідеї;
- іншим учасникам.
Випадки, у яких можуть бути використані сценарії Use Case:
- Для створення якісної специфікації вимог системи. Під час їхнього розроблення застосовується також опис інтерфейсу програми та можливість її інтеграції з іншими.
- Під час здійснення технічної підтримки. У такому разі UseCase допомагає виявити помилку і визначити, на якому етапі вона сталася.
Якщо потрібно дати опис лише частини функціональності системи, взаємодії користувача і програми. Тут на виручку приходить шаблон UseCase, на основі якого і створюється сценарій.
Припустимо, що в основі мобільного застосунку лежить опис користувацького інтерфейсу. Але не враховано низку функцій, виконання яких вимагає створення додаткових сценаріїв із використанням таблички: «Дія користувача – відгук системи» або їх поєднання.
Правила написання Use Case
Кількість елементів Use Case може змінюватися залежно від ступеня складності сценарію. Але, як правило, їхній набір завжди стандартний:
- Актор (actor), тобто користувач. Наприклад, у магазині онлайн акторами виступають і продавці, і покупці, а також компанії, що здійснюють доставку товару або забезпечують надходження платежів.
- Стейкхолдер (stakeholder) – це особа, зацікавлена в отриманні вигоди від роботи сценарію. Якщо продовжити розглядати приклад онлайн-магазину, то в цьому випадку Стейкхолдером може бути платіжна система.
- Primary actor, або первинна дійова особа. Це може бути як фізична, так і юридична особа, яка за допомогою роботи системи досягає своїх цілей. У нашому прикладі, як primary actor ми можемо розглядати фірму-дистриб’ютора, продаж товарів якої здійснюється на платформі онлайн-магазину.
- Передумови та постумови. Інакше кажучи, це фактори, за наявності яких відбувається запуск сценарію, і ті, які виникають після.
- Тригери – елементи, що приводять у дію UseCase.
- Успішний сценарій, тобто той, що відбувається без помилок і непередбачених обставин.
- Альтернативні варіанти. Їх можна охарактеризувати як запасний план, створений на базі основного сценарію, необхідний у разі збоїв у функціонуванні системи.
Послідовність дії при створенні сценаріїв Use Case описана максимально просто і доступно. Як правило, виділяють такі кроки як:
- Визначення користувачів сайту.
- Вибір одного з них.
- Формулювання дій користувача на сайті, які і будуть UseCase.
- Визначення потоку події для кожного зі сценаріїв.
- Опис дій користувача і результату, до якого вони ведуть. Іншими словами, яким має бути відгук системи.
- Створення та додавання інших варіантів розвитку подій у сценарій.
- Вибір інших користувачів і опис UseCase для кожного з них.
Рекомендації зі створення Use Case
Рекомендації зі створення Use Case допомагають правильно описати сценарії взаємодії користувача з системою. Вони дозволяють структурувати процеси, зробити їх зрозумілими для команди і забезпечити ефективну реалізацію проєкту.
Застосовуйте діаграми
Радимо не нехтувати використанням цього графічного інструменту під час розроблення Use Case, оскільки текстовий опис, безумовно, можна зробити повним і вичерпним, але саме діаграма допоможе візуалізувати весь процес.
Крім цього, схематично представлений сценарій дає змогу побачити межі описаних подій, що особливо важливо, коли учасників і варіантів роботи системи досить багато.
Люди -важливий елемент сценарію
У діаграмах Use Case схематично зображені чоловічки називаються суб’єктами. Їхнє призначення – показати роль або об’єкт, що взаємодіє із системою і перебуває за її межами.
Опис цього сценарію – процес досить складний і трудомісткий, але цікавий і перспективний, якщо вкласти в нього велику кількість зусиль і врахувати вимоги функціональності. Це дасть змогу налагодити роботу суб’єктів і поліпшити якість виконання ними своїх завдань.
Якщо ви займаєтеся розробкою системи, робота якої не буде пов’язана або залежна від інших об’єктів, то тоді слід ретельно опрацювати сценарії, пов’язані з потребами людей-суб’єктів.
Ідіть за потоком
Хороший сценарій Use Case – це не тільки короткий і ємний опис, а й створення певної структури, що дає змогу визначити поєднання частин сценаріїв між собою. Способи, за яких здійснюється структурування, називаються стилем сценарію, і вони можуть бути найрізноманітнішими.
Стандартний метод передбачає послідовне виконання численних кроків під час створення сценарію. Але за такого підходу є ризик, що в разі виникнення помилок виконання процесу будь-яка з частин перерветься. На цей випадок припустиме перетворення на модулі, але для відображення картини загалом писати і читати їх потрібно тоді, коли фрагменти сценарію поєднуються між собою.
Іншими словами, Use Case повинен мати основний потік подій і кілька альтернативних. У першому випадку описується послідовність дій і результат, коли сценарій працює без помилок і приводить до наміченої мети. Власне, так найчастіше і відбувається.
Але іноді розробники сценаріїв створюють описи для кількох основних потоків, що негативно відбивається на розумінні споживачем кінцевого результату. Саме тому як основний потік має виступати загальний сценарій процесу.
Помилки під час створення Use Case
На завершення статті коротко розповімо, яких помилок найчастіше припускаються розробники під час створення різних видів Use Case:
- Велика кількість деталей у діаграмі. Іноді під час спроби позначити всі аспекти поведінки системи, розробники перевантажують її зайвими елементами, що заважають зрозуміти основні принципи її функціонування.
- Прив’язка модуля до технічних пристроїв або до способів взаємодії користувачів і варіантів сценарію.
- Опис вимог до функціональності системи без позначення послідовності дій.
- Дається опис тільки дій акторів, а відгуків системи не передбачено.
- Роль ініціатора взаємодії між користувачем і системою віддається останній, хоча має бути з точністю навпаки.
- Текст сценарію не містить опису можливих ситуацій і дій, що тягне за собою недопрацювання у визначенні альтернативних варіантів використання.
- Використання термінів і скорочень, незрозумілих для користувачів і замовників.
- Специфікація атрибутів сценарію і різних операцій проводиться ще до того, як опис усіх можливих варіантів буде завершено.
Сподіваємося, що стаття виявилася корисною для всіх, хто вивчає можливості сценаріїв Use Case. Нехай ваші зусилля будуть продуктивними та корисними!
Висновок
Use case допомагає структурувати вимоги, фокусуючись на тому, як користувач взаємодіє з системою. Це корисно для планування функціоналу, тестування, побудови UI та розробки технічних завдань.
Переваги – чіткість у комунікації між командами, зменшення ризику неправильного розуміння задач, а також краще занурення в реальні потреби користувачів. Use cases економлять час і допомагають створювати продукти, які справді працюють.
