Kniha popisuje jednu metódu na písanie časti výpisu problému, konkrétne metódu prípadu použitia.
Čo to je? Toto je popis scenára interakcie používateľa so systémom (alebo s podnikom). V tomto prípade systém funguje ako čierna skrinka (a to umožňuje rozdeliť komplexnú úlohu návrhu na návrh interakcie a zabezpečenie tejto interakcie). Zároveň sa zavádzajú štandardy notácie, ktoré zabezpečujú ľahké čítanie, a to aj pre nezúčastnených, a umožňujú niektoré kontroly úplnosti a súladu s cieľmi zainteresovanej strany.
Príklad použitia
Ako vyzerá scenár na príklade autorizácie na stránke prostredníctvom e-mailu:
(Systém) Ak chcete získať prístup k svojmu osobnému účtu, prihláste sa na webovú stránku. ~~ (hladina mora)
Kontext: Neautorizovaný klient sa prihlási na stránku tak, aby ho stránka spoznala a zobrazila mu osobné informácie: históriu prehliadania, históriu nákupov, aktuálny počet bonusových bodov atď., pričom ako prihlasovací údaj použije email.
úroveň: užívateľský cieľ
Hlavná postava: klient (návštevník nášho internetového obchodu)
Rozsah: Interakcia klienta s webovou stránkou internetového obchodu
Zainteresované strany a záujmy:
- marketingový špecialista chce, aby bol identifikovaný maximálny počet návštevníkov stránky, aby bolo možné lepšie pokryť osobnú korešpondenciu,
- bezpečnostný špecialista chce zabezpečiť, aby nedochádzalo k prípadom neoprávneného prístupu k osobným údajom návštevníka, vrátane pokusov uhádnuť heslo k jednému účtu alebo vyhľadať účet so slabým heslom,
- útočník chce získať prístup k bonusom obete,
- konkurenti chcú zanechať negatívne recenzie na produkty,
- Botnet chce získať zákaznícku základňu obchodu a pomocou útoku znefunkčniť stránku.
Predpoklady: návštevník nesmie byť oprávnený.
Minimálne záruky: návštevník bude vedieť, či bol pokus o autorizáciu úspešný alebo neúspešný.
Záruky úspechu: návštevník je oprávnený.
Hlavný scenár:
- Klient spustí autorizáciu.
- Systém potvrdí, že klient nie je autorizovaný a neprekročí počet neúspešných pokusov o autorizáciu z danej relácie (hľadanie slabého hesla pre viacero účtov) podľa „Bezpečnostného pravidla č. 23“.
- Systém zvýši počítadlo počtu pokusov o autorizáciu.
- Systém zobrazí klientovi autorizačný formulár.
- Klient zadá svoj email a heslo.
- Systém potvrdí prítomnosť klienta s takýmto emailom v systéme a zhodu hesla a neprekročí počet pokusov o prihlásenie k tomuto účtu podľa „Bezpečnostného pravidla č. 24“.
- Systém autorizuje klienta, pridáva históriu prehliadania a košík tejto relácie s poslednou reláciou tohto klientskeho účtu.
- Systém zobrazí správu o úspešnosti autorizácie a prejde na krok skriptu, z ktorého bol klient prerušený kvôli autorizácii. V tomto prípade sa údaje na stránke znova načítajú s prihliadnutím na údaje osobného účtu.
Rozšírenia:
2.a. Klient už má autorizáciu:
2.a.1. Systém upozorní klienta na skutočnosť predtým vykonanej autorizácie a ponúkne mu buď prerušenie skriptu alebo prechod na krok 4, a ak je krok 6 úspešne dokončený, vykoná sa krok 7 s objasnením:
2.a.7. Systém deaktorizuje klienta pod starým účtom, autorizuje klienta pod novým účtom, pričom história prehliadania a košík tejto interakcie ostávajú v starom účte a neprenášajú sa na nový. Ďalej prejdite na krok 8.
2.b Počet pokusov o autorizáciu prekročil hranicu podľa „Bezpečnostného pravidla č. 23“:
2.b.1 Prejdite na krok 4, na autorizačnom formulári sa dodatočne zobrazí captcha
2.b.6 Systém potvrdí správne zadanie captcha
2.b.6.1 Captcha zadaný nesprávne:
2.b.6.1.1. systém zvyšuje počítadlo neúspešných pokusov o autorizáciu aj pre tento účet
2.b.6.1.2. systém zobrazí chybovú správu a vráti sa na krok 2
6.a. Nebol nájdený žiadny účet s týmto e-mailom:
6.a.1 Systém zobrazí správu o zlyhaní a ponúkne možnosť prejsť na krok 2 alebo prejsť na scenár „Registrácia používateľa“ a uložiť zadaný e-mail,
6.b. Heslo účtu s týmto e-mailom sa nezhoduje so zadaným heslom:
6.b.1 Systém zvýši počítadlo neúspešných pokusov o prihlásenie do tohto účtu.
6.b.2 Systém zobrazí správu o zlyhaní a ponúkne možnosť prejsť na scenár „Obnovenie hesla“ alebo prejsť na krok 2.
6.c: Počítadlo pokusov o prihlásenie pre tento účet prekročilo prah pre „Bezpečnostné pravidlo č. 24“.
6.c.1 Systém zobrazí správu o zablokovaní prihlásenia k účtu na X minút a prejde na krok 2.
Čo je skvelé
Kontroluje úplnosť a súlad s cieľmi, to znamená, že môžete zadať požiadavky na overenie inému analytikovi, čím sa vo fáze formulovania problému dopustíte menšieho počtu chýb.
Práca so systémom typu black box umožňuje oddeliť vývoj a koordináciu so zákazníkom toho, čo bude automatizované, od metód implementácie.
Je to súčasť cesty analytika, jedna z hlavných častí použiteľnosti. Scenár užívateľa definuje hlavné cesty jeho pohybu, čo značne znižuje slobodu výberu pre dizajnéra a zákazníka a pomáha zvyšovať rýchlosť vývoja dizajnu.
Som veľmi spokojný s miestom v popise, kde sú uvedené výnimky z každého kroku interakcie. Kompletný IT systém musí zabezpečiť určitý druh spracovania výnimiek, niektoré manuálne, niektoré automaticky (ako v príklade vyššie).
Skúsenosti ukazujú, že zle premyslené spracovanie výnimiek môže ľahko zmeniť systém na strašne nepohodlný systém. Spomínam si na príbeh, keď ste v sovietskych časoch, aby ste dostali rozhodnutie, museli získať niekoľko súhlasov od rôznych služieb, a aké bolestivé je, keď posledná služba hovorí - ale vaša žiadosť je v nesprávnom mene alebo iná chyba v interpunkciu, všetko zopakujte a znova skoordinujte.
Často sa stretávam so situáciami, kedy si prevádzková logika systému, ktorý nebol domyslený na výnimky, vyžadovala výrazné prepracovanie systému. Z tohto dôvodu sa leví podiel práce analytika vynakladá na riešenie výnimiek.
Textový zápis, na rozdiel od diagramov, umožňuje identifikovať a pokryť viac výnimiek.
Dodatok k metóde z praxe
Prípad použitia nie je na rozdiel od príbehu používateľa samostatnou prioritnou časťou vyhlásenia.
Vo vyššie uvedenom scenári zvážte výnimku „6.a. Nebol nájdený žiadny účet s týmto e-mailom.“ a ďalší krok „6.a.1 Systém zobrazí správu o poruche a prejde na krok 2.“ Aké negatívne veci zostali v zákulisí? Pre klienta sa akákoľvek návratnosť rovná faktu, že všetku prácu, ktorú vykonal pri zadávaní údajov, vyhodí na skládku. (V scenári to jednoducho nie je vidieť!) Čo sa dá urobiť? Prestavte skript, aby sa to nestalo. Je to možné? Môžete sa napríklad pozrieť na autorizačný skript Google.
Optimalizácia scenára
Kniha hovorí o formalizácii, ale hovorí len málo o metódach optimalizácie takýchto scenárov.
Je však možné posilniť metódu optimalizáciou scenárov a metóda formalizácie prípadov použitia to umožňuje. Konkrétne musíte myslieť na každú výnimku, ktorá sa vyskytne, určiť príčinu a prebudovať skript, aby ste sa zbavili výnimky alebo minimalizovali cestu zákazníka.
Pri zadávaní objednávky z internetového obchodu musíte zadať mesto doručenia. Môže sa stať, že predajňa nemôže dodať tovar do mesta, ktoré si klient vybral, pretože tam nedoručuje, z dôvodu obmedzenia veľkosti alebo z dôvodu nedostatku tovaru v príslušnom sklade.
Ak jednoducho opíšeme scenár interakcie vo fáze registrácie, môžeme napísať „informujte klienta, že doručenie nie je možné, a ponúknite mu zmenu mesta alebo obsahu košíka“ (a veľa začínajúcich analytikov sa tam zastaví). Ak je však takýchto prípadov veľa, scenár možno optimalizovať.
Prvá vec, ktorú musíte urobiť, je nechať si vybrať iba mesto, do ktorého môžeme doručiť. Kedy to urobiť? Pred výberom produktu na webovej stránke (autodetekcia mesta cez IP s upresnením).
Po druhé, musíme dať na výber len tovar, ktorý vieme klientovi dodať. Kedy to urobiť? V momente výberu - na dlaždici produktu a karte produktu.
Tieto dve zmeny smerujú k odstráneniu tejto výnimky.
Požiadavky na merania a metriky
Pri zvažovaní úlohy minimalizácie spracovania výnimiek môžete nastaviť úlohu hlásenia (prípad použitia nie je popísaný). Koľko výnimiek bolo, v akých prípadoch sa vyskytli, plus koľko prichádzajúcich scenárov úspešne prešlo.
Ale žiaľ. Skúsenosti ukázali, že požiadavky na reportovanie scenárov v tejto forme nestačia, je potrebné zvážiť požiadavky na reportovanie pre procesy, ktoré sú popísané prevažne nie vo forme prípadu použitia.
Prístup k použiteľnosti
V našej praxi sme rozšírili formulár popisu prípadu použitia o popis konkrétnych atribútov entít a údajov, aby sa klient mohol rozhodnúť, čo zvyšuje následnú použiteľnosť.
Pre návrh použiteľnosti sme pridali vstupnú sekciu – zobrazenie údajov.
V scenári s autorizáciou je to skutočnosť, že klient je autorizovaný v systéme. Ak je klient predautorizovaný, zobrazí sa po úspešnej autorizácii upozornenie na prepnutie histórie navigácie a košíka do nového účtu.
Vo všeobecnosti ide o zobrazenie potrebných informácií pre klienta, aby sa mohol rozhodnúť o svojom ďalšom postupe podľa scenára (môžete sa opýtať, či tieto údaje klientovi stačia, čo ešte potrebuje, aké informácie robia klient sa musí rozhodovať).
Tiež stojí za to rozdeliť zadané informácie do vstupných polí, ak sa spracúvajú samostatne a s tvorbou rôznych výnimiek.
Ak v príklade s autorizáciou klienta rozdelíte zadané informácie na prihlasovacie meno a heslo, potom sa oplatí zmeniť autorizačný skript, aby sa zvýraznili fázy zadávania samostatného prihlasovacieho mena a samostatného hesla (a to sa robí v Yandex, Google, ale nerobí vo väčšine internetových obchodov).
Dosiahnutie požadovaných transformácií údajov
Zo skriptu môžete tiež extrahovať požiadavky na algoritmy konverzie údajov.
Príklady:
- Aby sa klient mohol rozhodnúť kúpiť produkt v internetovom obchode, potrebuje na produktovej karte poznať možnosť, cenu, dodaciu lehotu tohto produktu do jeho mesta (ktoré sú vypočítané algoritmom na základe dostupnosti produktu v sklady a parametre dodávateľského reťazca).
- Pri zadávaní frázy do vyhľadávacieho riadku sa klientovi zobrazia návrhy vyhľadávania podľa algoritmu (ktoré sú generované algoritmom...).
Celkom
Vo všeobecnosti, po prečítaní knihy, žiaľ, nie je jasné, ako prejsť od analytika cez obchodné problémy až po formalizovanú technickú špecifikáciu pre vývojárov. Kniha hovorí len o časti procesu, pričom nie sú jasné vstupné kroky a nejasné ďalšie kroky. Samotný prípad použitia väčšinou nie je úplným vyjadrením vývojára.
Napriek tomu je to veľmi dobrý spôsob, ako formalizovať a spracovať scenáre interakcie medzi objektom a subjektom, keď interakcia spôsobí zmenu niečoho v subjekte. Je to jedna z mála metód zápisu, ktorá umožňuje overiteľné požiadavky s explicitnými bodmi vyhľadávania výnimiek.
Analytici si túto knihu musia prečítať, aby mohli začať písať testovateľné hry.
Zdroj: hab.com