ВІГЕРСОПЕДІЯ – Коли варіантів використання (Use Cases) недостатньо

Попри те, що варіанти використання (use cases) є цінними для багатьох проєктів, іноді аналіз подій є більш ефективною технікою виявлення вимог.

Я завжди був палким прихильником варіантів використання (use cases) коли зрозумів наскільки це цінний інструмент у виявленні вимог. Варіанти використання дозволяють учасникам виявлення вимог перевести фокус з продукту та його функцій на дослідження того, що користувачам потрібно робити з продуктом. Таким чином цей акцент, орієнтований на використання, (usage-centric emphasis) призводить до розуміння необхідних можливостей та характеристик рішення.

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

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

Таке ненависне самообслуговування 

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

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

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

БА справді може дослідити варіант використання “Придбання Продуктів” разом з деякими представниками покупців, щоб дізнатися, як вони уявляють взаємодію із системою для покупки одного або декількох продуктів. Це буде величезний, високо складний варіант використання! Існує багато не обов’язкових дій-відгалужень на шляху до покупки, які може зустріти користувач, що називаються альтернативними потоками (alternative flows). Також існує багато можливих винятків (exceptions), речей, які можуть піти не так і перешкодити досягненню мети. Ми добре знаємо це з практики користування системами самообслуговування. Крім того, дослідження того, як покупець уявляє собі придбання продуктів, не надасть достатньо інформації для визначення всієї функціональності системи самообслуговування, а надасть лише видиму для клієнта частину функціональності. Чи є кращий спосіб зрозуміти вимоги до такого продукту?

Події самообслуговування

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

Бізнес-подія: Хтось або щось (користувачі не обов’язково є людьми) ззовні запитує послугу від системи. Запит часто спричиняє виконання варіанту використання (use case). Покупець, який вирішує придбати деякі товари за допомогою системи самообслуговування, ініціює бізнес-подію.

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

Часова подія: Досягається заздалегідь встановлений час, або пройшов вказаний часовий інтервал з моменту попередньої події або з моменту, коли система перебувала у певному стані. Припустимо, ви поклали невідсканований товар у вашу сумку. Система самообслуговування нагадає вам спочатку відсканувати його. Якщо ви не відсканували товар протягом певної кількості секунд, пристрій призупинить процес оформлення покупки і подасть сигнал про допомогу або виконає інші дії.

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

• Система виявляє покупця поруч

• Покупець сканує свою картку лояльності

• Покупець вказує, що використовує свою власну сумку

• Покупець сканує штрих-код товару

• Покупець сканує товар, який необхідно зважити

• Система виявляє розбіжність ваги в сумці

• Покупець сканує купон

• Покупець хоче розрахуватися готівкою

• Протягом X секунд не відбувається жодна дія з боку покупця

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

Репрезентація знань про події

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

Рис. 1.  Зразок частини таблиці подій-відповідей

Дослідіть кожну подію на можливі виняткові умови (exceptions). Що, якщо покупець сканує штрих-код товару, але товар не знайдено в базі даних системи? Це траплялося зі мною. Що, якщо покупець помічає, що ціна, відображена після сканування, не відповідає ціні, зазначеній на ціннику або в рекламі? Набір вимог повинен передбачати якнайбільше винятків та визначати, як система повинна виявляти, реагувати та намагатися відновитися після кожного з них.

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

Додатково до цього текстового представлення подій системи, часто корисно намалювати діаграму переходу станів (state-transition diagram; також можливі назви –  statechart, state machine diagrams), щоб показати різні можливі стани системи та комбінації подій та умов, які призводять до переходу з одного стану в інший.

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

Користувачі не будуть знати все

Навіть якщо БА ефективно співпрацює з відповідними представниками визначених класів користувачів, вони не отримають всю інформацію про вимоги, яку вони потребують для повного визначення продукту. Клієнт, напевно, не подумає сказати БА: “Якщо система самообслуговування виявить, що в моїй сумці є товар, який ще не відскановано, вона повинна повідомити про проблему.” Так само клієнт не скаже: “Якщо в пристрої менше 99 центів, він не повинен надати мені можливість розрахуватися готівкою в разі необхідності видати здачу.” БА додає багато цінності, заповнюючи подібні прогалини.

Розгляньте час очікування, такі як подія “Протягом X хвилин не відбувається жодна дія з боку покупця”. Час очікування в сутності є негативною тимчасовою подією. Система визначає, що нічого не відбулося протягом певного періоду часу або з моменту попередньої події і повинна діяти відповідно. Представник покупця під час обговорення виявлення вимог ймовірно не скаже: “Якщо я нічого не роблю протягом певного часу, система повинна запитати, чи я ще тут чи щось подібне.”

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

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

Доповнюючі техніки

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

Виникає питання: старанний БА повинен використовувати варіанти використання чи аналіз подій? Подумайте про характер вашого продукту. Чи можете ви визначити кілька класів користувачів, які хочуть досягти різноманітних цілей, взаємодіючи з рішенням? Можливо, розпочніть з аналізу варіантів використання. Або чи включає продукт обмежену кількість складних взаємодій, з використанням апаратних компонентів та багато чого іншого, що користувач не бачить безпосередньо? Аналіз подій є кращим вибором. Ці два підходи не виключають один одного. Ви можете почати з дослідження варіантів використання, а потім побудувати окремий, простий список подій. Порівняйте і побачите, чи ви щось пропустили.

Розробники не реалізують варіанти використання, користувацькі історії або списки подій. Вони реалізують фрагменти функціоналу, які змушують рішення вести себе певним чином, коли відбуваються певні речі. Пам’ятайте, що як з використанням варіантів використання, так і з аналізом подій БА повинен проникнути на глибинний рівень деталей у відповідний момент, визначаючи конкретний функціонал, який розробники реалізують.

Наприклад, останній рядок на рисунку 1 говорить, що система завершує сесію. Що включає в себе завершення сесії? Комусь потрібно визначити ці деталі. Якщо ця інформація в кінцевому підсумку не включена у вимоги, не дивуйтеся тому, що команда розробників реалізує в результаті.

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

Оригінальна стаття – When Use Cases Aren’t Enough, переклад – Марина Хоменко, ревью – Іван Вільчавський. Зображення від Карла Вігерса з оригінальної статті.