USE CASE для бізнес-аналітика
- Oleh Voroniak
- 18 січ.
- Читати 4 хв
Як і навіщо писати Use Cases.
Створення ефективних Use Cases (далі використовуються терміни «варіанти використання», «сценарії», «юзкейси») — це обов'язковий навик для будь-якого аналітика. У деяких випадках без описаних сценаріїв працювати набагато складніше, ніж із ними.
Наступні нотатки будуть корисними для початківців бізнес-аналітиків, системних аналітиків, а також студентів.
Що таке Use Case?
На співбесіді можна почути таке визначення: «Це UML-діаграма з чоловічками й овалами». Давайте розберемося, що це таке, і розглянемо кілька простих прикладів.
Use Case описує сценарій взаємодії учасників (зазвичай користувача та системи). Учасників може бути 2 або більше. Користувачем може бути як людина, так і інша система.
Мені подобається визначення з книги Алістера Коберна (рекомендую її всім аналітикам): «Варіант використання фіксує угоду між учасниками системи про її поведінку. Він описує поведінку системи у відповідь на запит одного з учасників, який називається основною дійовою особою, у різних умовах».
У реальному житті зустрічаються такі назви: варіанти використання, юзкейс, сценарій, прецедент, сценарій використання.
Текст чи діаграма/схема?
Який формат опису кращий: текстовий чи діаграма? Вибір залежить від вас і вашої команди. На початку своєї роботи я використовувала діаграми або діаграми з текстовим описом. Зараз я віддаю перевагу текстовому опису сценаріїв. Ось чому:
Такий формат зрозуміліший для замовників (вони частіше погоджують і читають текстові описи).
Текст легше та швидше редагувати, ніж діаграми.
Звісно, якщо у вашому проєкті є очевидні переваги використання діаграм, їх потрібно застосовувати.
Кому й коли потрібні сценарії?
1. Розробникам. Зручно, коли складна вимога описана за допомогою основного та альтернативного потоку подій. Усе чітко: хто, коли, що викликає і що отримує в результаті. У моєму останньому проєкті менеджер надавав перевагу мінімальному опису та максимуму спілкування, але для кількох складних сценаріїв розробники самі просили докладні описи, і юзкейси виявилися ідеальними.
2. Замовникам. Описано людською мовою, замовник може підтвердити, що це саме те, чого він очікує, або виправити.
3. Тестувальникам. Це майже готовий тест-кейс.
4. Усьому проєктному колективу. Якщо сценарій потрібно узгодити, а під час кожної наради звучать різні версії, допоможе суворо описаний потік подій.
5. Іншим учасникам процесу.
Коли вони потрібні?
Для якісної, повної специфікації вимог, яка містить модель даних, опис інтерфейсу, інтеграції з іншими системами й юзкейси.
Для підтримки системи (щоб знайти помилку або зрозуміти, що пішло не так).
Якщо потрібно описати якусь частину функціональності, роботи користувача з інтерфейсом, etc. у вигляді сценарію. Тоді ви можете взяти шаблон юзкейсу за основу та використати його для опису сценарію. Наприклад, основу вимог до вашого мобільного додатку складає опис інтерфейсу користувача. Але виконання деяких функцій має багато нюансів, які потрібно додатково описати за допомогою таблички: "дія - відгук системи", або навіть поєднати таку табличку зі сценарієм.
Як їх описувати?
Розглянемо два приклади.
Приклад 1. Розблокувати обліковий запис користувача (простий короткий приклад).
Дійові особи: Адміністратор, Система. Мета: Змінити статус облікового запису користувача на «активний». Передумова: Обліковий запис користувача не активний. Успішний сценарій:
Адміністратор вибирає користувача та активує «Розблокувати».
Система переключає обліковий запис користувача у статус «активний», і надсилає повідомлення (тут можна послатися на текст повідомлення зі списку повідомлень, див. примітку нижче) користувачеві на email (якщо User Account → email не порожньо).
Результат: Обліковий запис змінено на статус «активний».
Приклад 2. Авторизація користувача.
Дійові особи: Користувач, Система. Мета:
Користувач: авторизуватись у системі та почати роботу.
Система: ідентифікувати користувача та його права.
Успішний сценарій:
Користувач запускає систему. Система відкриває сесію користувача, пропонує ввести логін та пароль.
Користувач вводить логін та пароль.
Система перевіряє логін та пароль.
Система створює запис в історії авторизацій (IP-адреса користувача, логін, дата, робоча станція).
Система видає користувачеві повідомлення щодо успішної авторизації (посилання на повідомлення).
Результат: Користувач успішно авторизується та починає роботу.
Розширення:
*а Немає доступу до БД.Система видає повідомлення (посилання повідомлення). Результат: користувач не може увійти.
1а У налаштуваннях безпеки для цієї IP адреси існує заборона на вхід до системи.Результат: форма логіна не надається, система видає повідомлення користувачу (посилання на повідомлення).
2а Користувач вибирає: «нагадати пароль». Викликається сценарій «нагадати пароль».
3а Користувач із введеними логіном та паролем не знайдено.Результат: відмова в авторизації. Система видає повідомлення (посилання повідомлення). Перехід крок 2.
3б Кількість невдалих спроб авторизуватися досягла максимального, встановленого в налаштуваннях.Результат: користувач не може увійти.
Видається повідомлення: (посилання повідомлення).
Вхід з IP-адреси Користувача заблоковано на час, встановлений у налаштуваннях.
Важливі моменти:
— Очевидно, якщо Приклад 1 можна було безболісно описати простим текстом, то Приклад 2 набагато краще сприймається у вигляді сценарію. Але якщо у вас вся функціональність описана у вигляді юзкейсів, то краще описувати юзкейс навіть дуже прості сценарії, з пари кроків. Нехай ваша специфікація буде у єдиному стилі.
— Використовуйте мінімальну кількість слів та пунктів, необхідних для однозначного розуміння сценарію. Якщо юзкейс виходить занадто довгий, можливо, краще розбити його на кілька. З дуже довгими сценаріями, з великою кількістю розширень працювати вкрай незручно.
— Якщо у двох і більше сценаріях повторюється однаковий набір кроків, є сенс винести ці кроки до окремого сценарію, і посилатися на них. Документ буде легшим. А якщо щось у цих кроках зміниться, достатньо буде змінити в одному місці.
— Список повідомлень, які система видає користувачеві, стандартні тексти електронних листів тощо. зручно розмістити у єдиному місці у документі, і посилатися потрібний пункт із різних юзкейсів, т.к. повідомлення у сценаріях часто дублюються.
— Перечитайте документ зі сценаріями перед тим, як віддавати його розробникам або замовникам. Найкраще навіть кілька разів. Завжди є моменти, які можна описати лаконічніше, або виявляються якісь невідповідності. Або випадкові копіпасти. Поважайте час та голови інших людей.
— До речі, про копіпасти. Незаповнену табличку для опису юзкейсу є сенс копіпастити.
— Як видно з прикладів вище, розширення кроку номер 1 вказується в розділі «Розширення» як 1а, 1б, і т.д. Розширення *а — це загальне розширення сценарію, немає конкретному.
Правильних та корисних вам сценаріїв! Запитання, приклади, пропозиції, коментарі вітаються. Дякую за увагу.
Під час написання статті я використовувала матеріали з книги Алістера Коберна «Сучасні методи опису функціональних вимог до систем».
Джерело:
Comentários