Kniha popisuje jednu metodu zápisu části výpisu problému, a to metodu use case.
co to je? Toto je popis scénáře interakce uživatele se systémem (nebo s firmou). V tomto případě se systém chová jako černá skříňka (a to umožňuje rozdělit složitý úkol návrhu na interakci návrhu a zajištění této interakce). Současně jsou zavedeny standardy notace, které zajišťují snadnou čitelnost, a to i pro nezúčastněné, a umožňují některé kontroly úplnosti a souladu s cíli zainteresované strany.
Příklad použití
Jak scénář vypadá na příkladu autorizace na webu prostřednictvím e-mailu:
(Systém) Přihlaste se na webovou stránku pro přístup ke svému osobnímu účtu. ~~ (hladina moře)
Kontext: Neautorizovaný klient se přihlásí na stránku tak, aby ho stránka poznala a zobrazila pro něj osobní údaje: historii prohlížení, historii nákupů, aktuální počet bonusových bodů atd., a to pomocí emailu jako přihlašovacího jména.
Úroveň: uživatelský cíl
Hlavní postava: klient (návštěvník našeho internetového obchodu)
Rozsah: Interakce klienta s webem internetového obchodu
Zúčastněné strany a zájmy:
- obchodník chce, aby byl identifikován maximální počet návštěvníků webu, aby bylo možné lépe pokrýt osobní korespondenci,
- bezpečnostní specialista chce zajistit, aby nedocházelo k případům neoprávněného přístupu k osobním údajům návštěvníka, včetně pokusů uhodnout heslo k jednomu účtu nebo vyhledat účet se slabým heslem,
- útočník chce získat přístup k bonusům oběti,
- konkurenti chtějí zanechat negativní recenze na produkty,
- Botnet chce získat zákaznickou základnu obchodu a pomocí útoku znemožnit provoz webu.
Předpoklady: návštěvník nesmí být pověřen.
Minimální záruky: návštěvník bude vědět, zda byl pokus o autorizaci úspěšný nebo neúspěšný.
Záruky úspěchu: návštěvník je oprávněn.
Hlavní scénář:
- Klient zahájí autorizaci.
- Systém potvrdí, že klient není autorizován a nepřekročí počet neúspěšných pokusů o autorizaci z dané relace (hledání slabého hesla pro více účtů) podle „Bezpečnostního pravidla č. 23“.
- Systém zvýší počítadlo počtu pokusů o autorizaci.
- Systém zobrazí klientovi autorizační formulář.
- Klient zadá svůj email a heslo.
- Systém potvrdí přítomnost klienta takovým emailem v systému a shodu hesla a nepřekročí počet pokusů o přihlášení k tomuto účtu dle „Bezpečnostního pravidla č. 24“.
- Systém autorizuje klienta, přidá historii procházení a košík této relace s poslední relací tohoto klientského účtu.
- Systém zobrazí zprávu o úspěšné autorizaci a přejde ke kroku skriptu, ve kterém byl klient přerušen kvůli autorizaci. V tomto případě se údaje na stránce znovu načtou s přihlédnutím k údajům osobního účtu.
Rozšíření:
2.a. Klient je již autorizován:
2.a.1. Systém upozorní klienta na skutečnost dříve provedené autorizace a nabídne buď přerušení skriptu, nebo přechod na krok 4, a pokud je krok 6 úspěšně dokončen, provede se krok 7 s vysvětlením:
2.a.7. Systém deaktorizuje klienta pod starým účtem, autorizuje klienta pod novým účtem, přičemž historie prohlížení a košík této interakční relace zůstanou ve starém účtu a nepřenesou se na nový. Dále přejděte ke kroku 8.
2.b Počet pokusů o autorizaci překročil prahovou hodnotu podle „Bezpečnostního pravidla č. 23“:
2.b.1 Přejděte na krok 4, na autorizačním formuláři se navíc zobrazí captcha
2.b.6 Systém potvrdí správné zadání captcha
2.b.6.1 Captcha zadán nesprávně:
2.b.6.1.1. systém zvyšuje počítadlo neúspěšných pokusů o autorizaci i pro tento účet
2.b.6.1.2. systém zobrazí chybovou zprávu a vrátí se ke kroku 2
6.a. Nebyl nalezen žádný účet s tímto e-mailem:
6.a.1 Systém zobrazí zprávu o selhání a nabídne volbu, zda přejít na krok 2 nebo přejít na scénář „Registrace uživatele“ a uložit zadaný e-mail,
6.b. Heslo k účtu s tímto e-mailem neodpovídá zadanému:
6.b.1 Systém zvyšuje počítadlo neúspěšných pokusů o přihlášení k tomuto účtu.
6.b.2 Systém zobrazí zprávu o selhání a nabídne volbu, zda přejít na scénář „Obnovení hesla“ nebo přejít na krok 2.
6.c: Čítač pokusů o přihlášení pro tento účet překročil prahovou hodnotu pro „bezpečnostní pravidlo č. 24“.
6.c.1 Systém zobrazí zprávu o zablokování přihlášení k účtu po dobu X minut a přejde ke kroku 2.
Co je skvělé
Kontroly úplnosti a souladu s cíli, to znamená, že můžete zadat požadavky jinému analytikovi k ověření, čímž se ve fázi formulace problému dopustíte méně chyb.
Práce se systémem černé skříňky umožňuje oddělit vývoj a koordinaci se zákazníkem toho, co bude automatizováno, od metod implementace.
Je to součást cesty analytika, jedna z hlavních částí použitelnosti. Uživatelský scénář definuje hlavní cesty jeho pohybu, což značně omezuje svobodu volby pro designéra i zákazníka a pomáhá zvýšit rychlost vývoje designu.
Jsem velmi spokojen s místem v popisu, kde jsou identifikovány výjimky pro každý krok interakce. Kompletní IT systém musí zajišťovat určitý druh zpracování výjimek, některé ručně, některé automaticky (jako v příkladu výše).
Zkušenosti ukazují, že špatně promyšlené zacházení s výjimkami může ze systému snadno udělat strašně nepohodlný systém. Pamatuji si příběh, kdy jste v sovětských dobách, abyste dostali rozhodnutí, museli získat několik schválení od různých služeb, a jak bolestivé to je, když poslední služba říká - ale vaše žádost je na špatné jméno nebo jiná chyba v interpunkci, vše předělat a znovu vše zkoordinovat.
Často se setkávám se situacemi, kdy provozní logika systému, která nebyla domyšlena na výjimky, vyžadovala výrazné přepracování systému. Z tohoto důvodu je lví podíl práce analytika vynaložen na zpracování výjimek.
Textový zápis, na rozdíl od diagramů, umožňuje identifikovat a pokrýt více výjimek.
Doplnění metody z praxe
Na rozdíl od uživatelského příběhu není případ použití samostatně upřednostňovanou částí prohlášení.
Ve výše uvedeném scénáři zvažte výjimku „6.a. Nebyl nalezen žádný účet s tímto e-mailem.“ a další krok „6.a.1 Systém zobrazí chybovou zprávu a přejde ke kroku 2.“ Jaké negativní věci zůstaly v zákulisí? Pro klienta se jakákoliv návratnost rovná faktu, že veškerá práce, kterou odvedl se zadáváním dat, je odhozena na skládku. (Ve skriptu to prostě není vidět!) Co se dá dělat? Znovu vytvořte skript, aby se to nestalo. Je to možné? Můžete - jako příklad se podívat na autorizační skript Google.
Optimalizace scénáře
Kniha hovoří o formalizaci, ale říká málo o metodách optimalizace takových scénářů.
Metodu je však možné posílit optimalizací scénářů a metoda formalizace případu užití to umožňuje. Konkrétně musíte přemýšlet o každé výjimce, která nastane, určit příčinu a znovu vytvořit skript, abyste se zbavili výjimky nebo minimalizovali cestu zákazníka.
Při zadávání objednávky z internetového obchodu musíte zadat město doručení. Může se stát, že obchod nemůže dodat zboží do města zvoleného klientem, protože tam nedoručuje, z důvodu omezení velikosti nebo z důvodu nedostatku zboží v odpovídajícím skladu.
Pokud jednoduše popíšeme scénář interakce ve fázi registrace, můžeme napsat „informujte klienta, že doručení není možné, a nabídněte mu změnu města nebo obsahu košíku“ (a mnoho začínajících analytiků se nad tím zastaví). Pokud je ale takových případů hodně, pak lze scénář optimalizovat.
První věc, kterou musíte udělat, je nechat si vybrat pouze město, kam můžeme doručit. Kdy to udělat? Před výběrem produktu na webu (autodetekce města přes IP s upřesněním).
Za druhé, musíme dát na výběr pouze zboží, které můžeme klientovi dodat. Kdy to udělat? V okamžiku výběru - na dlaždici produktu a kartě produktu.
Tyto dvě změny jdou dlouhou cestou k odstranění této výjimky.
Požadavky na měření a metriky
Při zvažování úkolu minimalizace zpracování výjimek můžete nastavit úkol hlášení (případ použití není popsán). Kolik výjimek bylo, v jakých případech k nim došlo a kolik úspěšně prošlo příchozími scénáři.
Ale bohužel. Zkušenosti ukázaly, že požadavky na reportování scénářů v této podobě nestačí, je nutné zvážit požadavky na reportování pro procesy, které jsou popsány převážně nikoli formou use case.
Přístup k použitelnosti
V naší praxi jsme formulář pro popis případu užití rozšířili o popis konkrétních atributů entit a dat, aby se klient mohl rozhodnout, což zvyšuje následnou použitelnost.
Pro návrh použitelnosti jsme přidali vstupní sekci – zobrazení dat.
Ve scénáři s autorizací se jedná o skutečnost, že klient je v systému autorizován. Pokud je klient předautorizován, zobrazí se po úspěšné autorizaci upozornění na přepnutí historie navigace a košíku na nový účet.
Obecně se jedná o zobrazení potřebných informací pro klienta, aby se mohl rozhodnout o svém dalším postupu podle scénáře (můžete se zeptat, zda klientovi tyto údaje stačí, co ještě potřebuje, jaké informace dělají klient se musí rozhodovat).
Vyplatí se také rozdělit zadané informace do vstupních polí, pokud jsou zpracovávány samostatně a s tvorbou různých výjimek.
V příkladu s autorizací klienta, pokud oddělíte zadané informace na přihlašovací jméno a heslo, pak stojí za to změnit autorizační skript, aby se zvýraznily fáze zadávání samostatného přihlašovacího jména a samostatného hesla (a to se provádí v Yandex, Google, ale neprovádí většina internetových obchodů).
Dosažení požadovaných transformací dat
Ze skriptu můžete také extrahovat požadavky na algoritmy převodu dat.
Příklady:
- Pro rozhodnutí o koupi produktu v internetovém obchodě potřebuje klient na produktové kartě znát možnost, cenu, dodací lhůtu tohoto produktu do jeho města (které jsou vypočítány algoritmem na základě dostupnosti produktu v sklady a parametry dodavatelského řetězce).
- Při zadávání fráze do vyhledávacího řádku se klientovi zobrazí návrhy vyhledávání podle algoritmu (které jsou generovány algoritmem...).
Celkem
Obecně po přečtení knihy bohužel není jasné, jak se dostat od analytika přes obchodní problémy až k formalizované technické specifikaci pro vývojáře. Kniha popisuje pouze část procesu, přičemž vstupní kroky nejsou jasné a další kroky jsou nejasné. Samotný případ použití většinou není úplným prohlášením pro vývojáře.
Přesto je to velmi dobrý způsob, jak formalizovat a zpracovat scénáře interakce mezi objektem a subjektem, kdy interakce způsobí změnu něčeho v subjektu. Je to jedna z mála metod zápisu, která umožňuje ověřitelné požadavky s explicitními body vyhledávání výjimek.
Kniha je pro analytiky povinnou četbou, aby mohli začít psát testovatelné hry.
Zdroj: www.habr.com