Knjiga opisuje eno metodo za pisanje dela izjave o problemu, in sicer metodo primera uporabe.
Kaj je to? To je opis scenarija interakcije uporabnika s sistemom (ali s podjetjem). V tem primeru sistem deluje kot črna skrinjica (in to omogoča razdelitev kompleksne projektne naloge na načrtovanje interakcije in zagotavljanje te interakcije). Hkrati so uvedeni notni standardi, ki zagotavljajo enostavno branje, tudi za neudeležence, in omogočajo nekatere preglede popolnosti in skladnosti s cilji deležnika.
Primer uporabe
Kako izgleda scenarij na primeru avtorizacije na spletnem mestu po e-pošti:
(Sistem) Za dostop do osebnega računa se prijavite na spletno mesto. ~~ (morska gladina)
Kontekst: Nepooblaščeni odjemalec se prijavi na spletno mesto, tako da ga spletno mesto prepozna in prikaže njegove osebne podatke: zgodovino brskanja, zgodovino nakupov, trenutno število bonus točk itd., pri čemer kot prijavo uporabi e-pošto.
Nivo: cilj uporabnika
Glavna oseba: naročnik (obiskovalec naše spletne trgovine)
Obseg: Interakcija naročnika s spletnim mestom spletne trgovine
Zainteresirane strani in interesi:
- tržnik želi identificirati največje število obiskovalcev spletnega mesta za večjo pokritost osebnih poštnih sporočil,
- varnostni strokovnjak želi zagotoviti, da ni primerov nepooblaščenega dostopa do osebnih podatkov obiskovalca, vključno s poskusi uganjanja gesla za en račun ali iskanja računa s šibkim geslom,
- napadalec želi pridobiti dostop do bonusov žrtve,
- konkurenti želijo pustiti negativne ocene o izdelkih,
- Botnet želi pridobiti bazo strank trgovine in z napadom narediti spletno mesto nedelujoče.
Predpogoji: obiskovalec ne sme biti pooblaščen.
Minimalna jamstva: obiskovalec bo vedel, ali je bil poskus avtorizacije uspešen ali neuspešen.
Garancije za uspeh: obiskovalec je pooblaščen.
Glavni scenarij:
- Stranka sproži avtorizacijo.
- Sistem potrdi, da odjemalec ni pooblaščen in ne preseže števila neuspešnih poskusov avtorizacije iz dane seje (iskanje šibkega gesla za več računov) v skladu z “Varnostnim pravilom št. 23”.
- Sistem poveča števec za število poskusov avtorizacije.
- Sistem odjemalcu prikaže avtorizacijski obrazec.
- Stranka vnese svoj e-poštni naslov in geslo.
- Sistem potrdi prisotnost stranke s takim e-poštnim naslovom v sistemu in da se geslo ujema in število poskusov prijave v ta račun ni preseženo v skladu z “Varnostnim pravilom št. 24”.
- Sistem avtorizira stranko, doda zgodovino brskanja in košarico te seje z zadnjo sejo tega računa stranke.
- Sistem prikaže sporočilo o uspešni avtorizaciji in se premakne na korak skripta, od katerega je bil odjemalec prekinjen zaradi avtorizacije. V tem primeru se podatki na strani ponovno naložijo ob upoštevanju podatkov osebnega računa.
Razširitve:
2.a. Stranka je že pooblaščena:
2.a.1. Sistem obvesti odjemalca o dejstvu predhodno izvedene avtorizacije in ponudi bodisi prekinitev skripta ali prehod na 4. korak, in če je 6. korak uspešno zaključen, se izvede 7. korak s pojasnilom:
2.a.7. Sistem deaktorizira stranko pod starim računom, avtorizira stranko pod novim računom, medtem ko zgodovina brskanja in košarica te interakcijske seje ostaneta v starem računu in se ne preneseta v novega. Nato pojdite na 8. korak.
2.b Število poskusov avtorizacije je preseglo prag v skladu z “Varnostnim pravilom št. 23”:
2.b.1 Pojdite na 4. korak, na avtorizacijskem obrazcu se dodatno prikaže captcha
2.b.6 Sistem potrdi pravilen vnos captcha
2.b.6.1 Captcha vnesena napačno:
2.b.6.1.1. sistem tudi za ta račun poveča števec neuspešnih poskusov avtorizacije
2.b.6.1.2. sistem prikaže sporočilo o napaki in se vrne na 2. korak
6.a. Račun s tem e-poštnim naslovom ni bil najden:
6.a.1 Sistem prikaže sporočilo o napaki in ponudi možnost izbire med korakom 2 ali scenarijem »Registracija uporabnika« in shranjevanjem vnesenega e-poštnega sporočila,
6.b. Geslo za račun s tem e-poštnim naslovom se ne ujema z vnesenim:
6.b.1 Sistem poveča števec neuspešnih poskusov prijave v ta račun.
6.b.2 Sistem prikaže sporočilo o napaki in ponudi možnost izbire med scenarijem »Obnovitev gesla« ali prehodom na 2. korak.
6.c: Števec poskusov prijave za ta račun je presegel prag za »Varnostno pravilo št. 24«.
6.c.1 Sistem prikaže sporočilo o blokiranju prijave v račun za X minut in nadaljuje na 2. korak.
Kaj je super
Preverja popolnost in skladnost s cilji, to pomeni, da lahko drugemu analitiku daste zahteve za preverjanje, pri čemer naredite manj napak v fazi oblikovanja problema.
Delo s sistemom črne skrinjice vam omogoča, da ločite razvoj in usklajevanje s stranko, kaj bo avtomatizirano, od metod implementacije.
Je del analitikove poti, eden glavnih delov uporabnosti. Uporabnikov scenarij definira glavne poti njegovega gibanja, kar močno zmanjša svobodo izbire oblikovalca in naročnika ter pripomore k večji hitrosti razvoja dizajna.
Zelo sem zadovoljen z mestom v opisu, kjer so opredeljene izjeme za vsak korak interakcije. Popoln IT sistem mora zagotoviti nekakšno obravnavo izjem, nekaj ročno, nekaj samodejno (kot v zgornjem primeru).
Izkušnje kažejo, da lahko slabo premišljeno ravnanje z izjemami zlahka spremeni sistem v strašno nepriročen sistem. Spomnim se zgodbe, ko si moral v času Sovjetske zveze, da bi dobil odločbo, pridobiti več soglasij različnih služb, in kako boleče je, ko ti zadnja služba reče - a tvoja prijava je v napačnem imenu ali kakšna druga napaka v ločila, vse ponovite in vse znova uskladite.
Pogosto naletim na situacije, ko je logika delovanja sistema, ki ni bil premišljen za izjeme, zahtevala znatno predelavo sistema. Zaradi tega levji delež analitikovega dela porabi za obravnavo izjem.
Besedilni zapis v nasprotju z diagrami omogoča identifikacijo in pokrivanje več izjem.
Dodatek k metodi iz prakse
Primer uporabe ni neodvisen prednostni del izjave, za razliko od uporabniške zgodbe.
V zgornjem scenariju upoštevajte izjemo »6.a. Noben račun s tem e-poštnim naslovom ni bil najden.« in naslednji korak "6.a.1 Sistem prikaže sporočilo o napaki in nadaljuje na korak 2." Katere negativne stvari so ostale v zakulisju? Vsako vračilo je za naročnika enako, kot da vse delo, ki ga je opravil z vnosom podatkov, vrže na odlagališče. (Samo ni vidno v scenariju!) Kaj je mogoče storiti? Ponovno sestavite skript, da se to ne zgodi. Ali je to mogoče narediti? Lahko - kot primer si oglejte Googlov avtorizacijski skript.
Optimizacija scenarijev
Knjiga govori o formalizaciji, malo pa govori o metodah za optimizacijo takšnih scenarijev.
Toda metodo je mogoče okrepiti z optimizacijo scenarijev, metoda formalizacije primera uporabe pa to omogoča. Natančneje, razmisliti morate o vsaki izjemi, ki se pojavi, ugotoviti vzrok in znova zgraditi skript, da se znebite izjeme ali minimizirate pot stranke.
Pri oddaji naročila v spletni trgovini morate vnesti mesto dostave. Lahko se izkaže, da trgovina ne more dostaviti blaga v mesto, ki ga je izbrala stranka, ker tja ne dostavlja zaradi omejitev glede velikosti ali zaradi pomanjkanja blaga v ustreznem skladišču.
Če preprosto opišemo scenarij interakcije na stopnji registracije, lahko napišemo "obvestite stranko, da je dostava nemogoča, in ponudite spremembo mesta ali vsebine vozička" (in mnogi analitiki začetniki se tam ustavijo). Če pa je takih primerov veliko, potem je scenarij mogoče optimizirati.
Prva stvar, ki jo morate storiti, je, da izberete samo mesto, kamor lahko dostavimo. Kdaj to narediti? Pred izbiro izdelka na spletnem mestu (samodejno zaznavanje mesta prek IP z razjasnitvijo).
Drugič, izbirati moramo le med blagom, ki ga lahko dostavimo naročniku. Kdaj to narediti? V trenutku izbire - na ploščici izdelka in kartici izdelka.
Ti dve spremembi močno prispevata k odpravi te izjeme.
Zahteve za meritve in metrike
Ko razmišljate o nalogi minimiziranja obravnavanja izjem, lahko nastavite nalogo poročanja (primer uporabe ni opisan). Koliko izjem je bilo, v katerih primerih so se zgodile in koliko dohodnih scenarijev je bilo uspešno opravljenih.
Ampak žal. Izkušnje so pokazale, da zahteve za poročanje scenarijev v tej obliki niso dovolj, treba je upoštevati zahteve poročanja za procese, ki so opisani predvsem ne v obliki primera uporabe.
Dostop do uporabnosti
V naši praksi smo obrazec za opis primera uporabe razširili z opisom specifičnih atributov entitet in podatkov za odločitev naročnika, kar povečuje kasnejšo uporabnost.
Za uporabno zasnovo smo dodali razdelek za vnos - prikaz podatkov.
V scenariju z avtorizacijo je to dejstvo, da je stranka pooblaščena v sistemu. Če je odjemalec predhodno avtoriziran, po uspešni avtorizaciji prikaži opozorilo o preklopu zgodovine navigacije in vozička na nov račun.
Na splošno je to prikaz potrebnih informacij za stranko, da se lahko odloči o svojih nadaljnjih dejanjih glede na scenarij (lahko vprašate, ali so ti podatki dovolj za stranko, kaj še potrebuje, katere informacije stranka mora sprejemati odločitve).
Prav tako je vredno razdeliti vnesene podatke v vnosna polja, če se obdelujejo ločeno in z oblikovanjem različnih izjem.
V primeru z avtorizacijo odjemalca, če vnesene podatke ločite na prijavo in geslo, potem je vredno spremeniti avtorizacijski skript, da označite faze vnosa ločene prijave in ločenega gesla (in to se naredi v Yandexu, Googlu, vendar ni v večini spletnih trgovin).
Doseganje zahtevanih transformacij podatkov
Iz skripta lahko izvlečete tudi zahteve za algoritme za pretvorbo podatkov.
Primeri:
- Za odločitev o nakupu izdelka v spletni trgovini mora stranka na kartici izdelka poznati možnost, stroške, čas dostave tega izdelka v svoje mesto (ki jih izračuna algoritem na podlagi razpoložljivosti izdelka v skladišča in parametri dobavne verige).
- Pri vnosu besedne zveze v iskalno vrstico se odjemalcu prikažejo iskalni predlogi po algoritmu (ki jih algoritem generira ...).
Skupno
Na splošno po branju knjige žal ni jasno, kako iti vso pot od analitika do poslovnih problemov do formalizirane tehnične specifikacije za razvijalca. Knjiga opisuje le del postopka, pri čemer so koraki vnosa nejasni in naslednji koraki nejasni. Sam primer uporabe največkrat ni popolna izjava za razvijalca.
Kljub temu je to zelo dober način za formalizacijo in obdelavo scenarijev interakcije med objektom in subjektom, ko interakcija povzroči spremembo nečesa v subjektu. Je ena redkih metod pisanja, ki omogoča preverljive zahteve z eksplicitnimi iskalnimi točkami izjem.
Knjiga je obvezno branje za analitike, da začnejo pisati preizkusne igre.
Vir: www.habr.com