У книзі описано один метод написання частини постановки задачі, а саме метод use case.
Що це таке? Це опис сценарію взаємодії користувача із системою (або з бізнесом). Система при цьому постає як чорна скринька (і це дає можливість розділити складне завдання проектування на проектування взаємодії та забезпечення цієї взаємодії). При цьому вводяться стандарти нотації, що забезпечує простоту прочитання у тому числі не учасникам, та дозволяє робити деякі перевірки на повноту та відповідність цілям стейкхолдера.
Приклад use case
Як виглядає сценарій, на прикладі авторизації на сайті через email:
(Системний) Авторизуватися на сайті для доступу до особистого кабінету. ~~ (рівень моря)
Контекст: Не авторизований клієнт авторизується на сайті, щоб сайт його дізнався та показував персональну для нього інформацію: історію переглядів, покупок, поточну кількість бонусних балів тощо, використовуючи email як логін.
рівень: мета користувача
Основна дійова особа: клієнт (відвідувач нашого інтернет-магазину)
Область дії: Взаємодія клієнта із сайтом інтернет-магазину
Зацікавлені особи та інтереси:
- маркетолог хоче, щоб максимальна кількість відвідувачів сайту була ідентифікована для більшого охоплення персональних розсилок,
- спеціаліст безпеки хоче, щоб не було випадків несанкціонованого доступу до персональних даних відвідувача, включаючи спроби підбору пароля для одного облікового запису або пошуку облікового запису зі слабким паролем,
- зловмисник хоче отримати доступ до бонусів жертви,
- конкуренти хочуть залишити негативні відгуки на товари,
- ботнет хоче отримати базу клієнтів магазину і за допомогою атаки досягти непрацездатності сайту.
Передумови: відвідувач має бути не авторизований.
Мінімальні гарантії: відвідувач дізнається факт успішної чи неуспішної спроби авторизації.
Гарантії успіху: відвідувач авторизований.
Основний сценарій:
- Клієнт запускає авторизацію.
- Система підтверджує, що клієнт не авторизований і не перевищення кількості неуспішних спроб авторизації з даної сесії (пошук слабкого пароля у багатьох облікових записів) за «Правилом безпеки №23».
- Система збільшує лічильник кількості спроб авторизації.
- Система відображає клієнту форму авторизації.
- Клієнт вводить email та пароль.
- Система підтверджує наявність клієнта з таким email у системі та збіг пароля та не перевищення кількості спроб входу в даний аккаунт за «Правилом безпеки №24».
- Система авторизує клієнта, додає історію перегляду та кошик даного сеансу з останнім сеансом цього облікового запису клієнта.
- Система відображає повідомлення про успішність авторизації і переходить на крок сценарію, з якого клієнт перервався на авторизацію. При цьому дані на сторінці перевантажуються з урахуванням персональних даних облікового запису.
Розширення:
2.а. Клієнт вже авторизований:
2.а.1. Система повідомляє клієнта про факт здійсненої раніше авторизації та пропонує або перервати сценарій, або перейти до кроку 4, при цьому якщо крок 6 успішно пройдено, то крок 7 виконується з уточненням:
2.а.7. Система деакторизує клієнта під старим акаунтом, авторизує клієнта під новим акаунтом, при цьому історія перегляду та кошик даного сеансу взаємодії залишається в старому акаунті, новий не переходить. Далі перехід до кроку 8.
2.б Кількість спроб авторизації перевищила поріг за «Правилом безпеки №23»:
2.б.1 Перехід до кроку 4, на формі авторизації додатково відображається капча
2.б.6 Система підтверджує коректне введення капчі
2.б.6.1 Капча введена неправильно:
2.б.6.1.1. система збільшує лічильник неуспішних спроб авторизації та під даний обліковий запис
2.б.6.1.2. система відображає повідомлення про неуспішність та повертається до кроку 2
6.а. Облікового запису з цим email не виявлено:
6.а.1 Система показує повідомлення про неуспішність і пропонує на вибір, або переход до кроку 2, або перехід до сценарію «Реєстрація користувача» із збереженням введеного email,
6.б. Пароль від облікового запису з цим email не збігається з введеним:
6.б.1 Система збільшує лічильник неуспішних спроб входу до цього облікового запису.
6.б.2 Система відображає повідомлення про неуспішність і пропонує на вибір або перехід до сценарію «Відновлення пароля» або перехід до кроку 2.
6.в: Лічильник спроб входу до цього облікового запису перевищив поріг за «Правилом безпеки №24».
6.в.1 Система відображає повідомлення про блокування входу до облікового запису протягом X хвилин і переходить до кроку 2.
Що здорово
Перевірки на повноту та відповідність цілям, тобто можна віддавати вимоги на перевірку іншому аналітику, припускаючи менше помилок на стадії постановки завдання.
Робота з системою типу чорний ящик дозволяє розділити вироблення та узгодження із замовником того, а що ж буде автоматизовано від способів реалізації.
Є частиною шляху аналітика, однією з основних частин із юзабіліті. Сценарій користувача задає основні шляхи його руху, що сильно зменшує свободу вибору для дизайнера та замовника та сприяє збільшенню швидкості вироблення дизайну.
Дуже тішить у описі місце, де виявляються винятки кожного кроку взаємодії. Цілісна ІТ система повинна передбачати ту чи іншу обробку винятків, частину в ручному режимі, частину в автоматичному (як у прикладі вище).
Досвід показує, що не продумана обробка винятків може легко перетворити систему на незручну систему. Згадується історія, коли в совкові часи для отримання рішення потрібно було отримати кілька погоджень різних служб і як же боляче, коли остання служба каже — а у вас заява не на те ім'я чи ще якась помилка в перепинанні, переробляйте все і переузгоджуйте все.
Часто стикаюся з ситуаціями, коли не продумана для винятків логіка роботи система вимагала значної ситуації цієї системи. Через це левова частка робіт аналітика витрачається на обробку винятків.
Нотація як тексту, на відміну діаграм, дозволяє виявити і охопити більше винятків.
Доповнення до методу з практики
Use case не є незалежно пріорітізується частиною постановки, на відміну від user story.
У зазначеному сценарії розглянемо виняток “6.а. Обліковий запис з цим email не виявлено.” та наступний крок “6.а.1 Система показує повідомлення про неуспішність і переходить до кроку 2”. Що із негативного залишилося за кадром? Для клієнта будь-яке повернення рівносильне тому, що вся праця що він зробив вводячи дані викидається на звалище. (У сценарії цього просто так не видно!) Що можна зробити? Перебудувати сценарій так, щоб цього не виникало. Чи можна це зробити? Можна, наприклад, подивіться на сценарій авторизації в Google.
Оптимізація сценарію
Книга розповідає про формалізацію, але мало розповідає про методи оптимізації таких сценаріїв.
Але можливо посилити метод за допомогою оптимізації сценаріїв та спосіб формалізації use case дозволяє це зробити. Конкретно, над кожним винятком, що виникає, потрібно подумати, визначити причину і перебудувати сценарій так, щоб позбутися винятку або мінімізувати шлях клієнта.
В оформленні замовлення інтернет-магазину необхідно ввести місто доставки. Може так виявитися, що для обраного клієнтом міста магазин не може доставити товар тому, що не робить туди доставку, через габаритні обмеження або відсутність товару на відповідному складі.
Якщо просто описувати сценарій взаємодії на стадії оформлення, то можна записати "повідомити клієнта про неможливість доставки і запропонувати змінити місто або склад кошика" (і багато аналітиків-початківців на цьому зупиняються). Але якщо таких випадків досить багато, можна оптимізувати сценарій.
Перше, що потрібно зробити, потрібно давати вибрати тільки те місто, куди ми можемо зробити доставку. Коли це робити? Перед моментом вибору товару на сайті (автовизначення міста через IP з уточненням).
Друге — треба давати вибір лише товару, який ми можемо доставити клієнту. Коли це робити? У момент вибору – на плитці товарів та картці товару.
Ці дві зміни значно практично позбавляють цього винятку.
Вимоги на вимірювання та метрики
Розглядаючи задачу мінімізації обробки винятків, можна поставити завдання на звітність (не описується use case). Як багато було винятків, у яких випадках вони виникали плюс як багато сценаріїв пройшло успішно від вхідних.
Але нажаль. Досвід показав, що вимог на звітність до сценаріїв у вигляді недостатньо, потрібно розглядати вимоги у звітності на процеси, які описуються переважно над вигляді use case.
Вихід на Usability
У нашій практиці ми розширили форму опису use case описом конкретних атрибутів сутностей та даних для ухвалення рішення клієнтом, що посилює подальше юзабіліті.
Для проектування юзабіліті ми додали вхідний розділ — дані, що відображаються.
У сценарії з авторизацією це факт авторизації клієнта в системі. Якщо клієнт попередньо авторизований, то відображатиме попередження про перемикання історії навігації та кошика на новий обліковий запис після успішності авторизації.
У загальному випадку це відображення потрібної інформації для клієнта, щоб він міг приймати рішення про свої подальші дії за сценарієм (можна запитати, чи достатньо клієнту цих даних, що ще потрібно, яка інформація потрібна для прийняття рішень клієнту).
Так само варто розділяти інформацію, що вводиться, на поля введення, якщо їх обробка відбувається роздільно і з формуванням різних винятків.
У прикладі з авторизацією клієнта, якщо виділити введену інформацію на логін і пароль, варто змінити сценарію авторизації з виділенням етапів введення окремо логіна і окремо пароля (і це зроблено в Yandex, Google, але не зроблено в більшості інтернет-магазинів).
Вихід на необхідні перетворення даних
Зі сценарію так само можна витягнути вимоги до алгоритмів перетворення даних.
приклади:
- Клієнту для ухвалення рішення про купівлю товару в інтернет-магазині на картці товару потрібно знати можливість, вартість, терміни доставки в місто даного товару (які обчислюються алгоритмом за фактом наявності товару на складах і параметрів ланцюжків поставок).
- При введенні фрази у пошуковий рядок клієнту за алгоритмом показуються пошукові підказки (які формуються алгоритмом…).
Разом
Загалом, після прочитання книги, на жаль, не зрозуміло, як пройти весь шлях аналітика від бізнес-проблем до формалізованого ТЗ для розробника. У книзі розповідається лише частина процесу з неясно сформульованими вхідними та неясно показаними подальшими кроками. Сам по собі use case повною постановкою для розробника найчастіше не є.
Тим не менш, це дуже хороший спосіб формалізації та обробки сценаріїв взаємодії об'єкта та суб'єкта, коли при взаємодії виникає зміна чогось у суб'єкті. Є одним з небагатьох способів запису, що допускають вимоги, що перевіряються з явними точками пошуку винятків.
Книга обов'язкова для прочитання аналітиками, щоб вони почали писати постановки, що перевіряються.
Джерело: habr.com