D'Buch beschreift eng Method fir en Deel vun enger Problemausso ze schreiwen, nämlech d'Benotzungsfallmethod.
Wat ass et? Dëst ass eng Beschreiwung vum Benotzerinteraktiounsszenario mam System (oder mam Geschäft). An dësem Fall, Akten de System als schwaarz Këscht (an dëst mécht et méiglech der komplex Design Aufgab opzedeelen Interaktioun Design an assuréieren dës Interaktioun). Zur selwechter Zäit ginn d'Notatiounsnormen agefouert, wat d'Liichtegkeet garantéiert, och fir Net-Participanten, an erlaabt e puer Kontrollen fir Vollständegkeet an Konformitéit mat den Ziler vum Akteuren.
Benotzen Fall Beispill
Wéi de Szenario ausgesäit, mam Beispill vun der Autorisatioun um Site per E-Mail:
(System) Mellt Iech op d'Websäit fir op Äre perséinleche Kont ze kommen. ~~ (Mieresspigel)
Kontext: En onerlaabten Client loggt sech op de Site un, fir datt de Site hien erkennt a perséinlech Informatioune fir hien weist: Consultatiounsgeschicht, Akafsgeschicht, aktuell Zuel vu Bonuspunkten, etc., benotzt E-Mail als Login.
Niveau: Benotzer Zil
Haaptcharakter: Client (Besucher vun eisem Online Store)
Ëmfang: Client Interaktioun mat der Online Store Websäit
Interessenten an Interessen:
- de Vermarkter wëll datt d'maximal Unzuel vun de Besucher vum Site identifizéiert gëtt fir méi Ofdeckung vu perséinleche Mailings,
- de Sécherheetsspezialist wëll sécherstellen datt et keng Fäll vun onerlaabten Zougang zu de perséinlechen Donnéeën vum Besucher gëtt, och Versuche fir d'Passwuert fir ee Kont ze roden oder e Kont mat engem schwaache Passwuert ze sichen,
- den Ugräifer wëll Zougang zu de Bonus vum Affer kréien,
- Konkurrenten wëllen negativ Kritiken iwwer Produkter hannerloossen,
- De Botnet wëll d'Clientsbasis vum Buttek kréien an en Attack benotzen fir de Site inoperabel ze maachen.
Viraussetzunge: de Visiteur däerf net autoriséiert ginn.
Minimum Garantien: de Visiteur wäert wëssen, ob d'Autorisatioun Versuch war erfollegräich oder net erfollegräich.
Garantie fir Erfolleg: de Visiteur ass autoriséiert.
Haaptszenario:
- De Client initiéiert Autorisatioun.
- De System bestätegt datt de Client net autoriséiert ass an net d'Zuel vun erfollegräichen Autorisatiounsversuche vun enger bestëmmter Sessioun iwwerschreift (Sich no engem schwaache Passwuert fir verschidde Konten) no "Sécherheetsregel Nr. 23".
- De System erhéicht de Konter fir d'Zuel vun den Autorisatiounsversich.
- De System weist en Autorisatiounsform un de Client.
- De Client gitt seng E-Mail a Passwuert.
- De System bestätegt d'Präsenz vun engem Client mat esou enger E-Mail am System an datt d'Passwuert entsprécht an d'Zuel vun de Loginversuche fir dëse Kont net iwwerschratt gëtt no "Sécherheetsregel Nr. 24".
- De System autoriséiert de Client, füügt d'Browsergeschicht an de Kuerf vun dëser Sessioun mat der leschter Sessioun vun dësem Client Kont.
- De System weist eng Autorisatioun Erfolleg Message a plënnert op de Skript Schrëtt aus deem de Client fir Autorisatioun ënnerbrach gouf. An dësem Fall ginn d'Donnéeën op der Säit nei gelueden andeems Dir de perséinleche Kontdaten berücksichtegt.
Erweiderung:
2.a. De Client ass schonn autoriséiert:
2.a.1. De System informéiert de Client iwwer d'Tatsaach vun der virdru gemaacher Autorisatioun a proposéiert entweder de Skript ze ënnerbriechen oder op de Schrëtt 4 ze goen, a wann de Schrëtt 6 erfollegräich ofgeschloss ass, da gëtt de Schrëtt 7 mat Klärung gemaach:
2.a.7. De System deaktoriséiert de Client ënner dem ale Kont, autoriséiert de Client ënner dem neie Kont, während d'Browsergeschicht an de Weenchen vun dëser Interaktiounssitzung am ale Kont bleiwen an net op den neien transferéieren. Als nächst gitt op Schrëtt 8.
2.b D'Zuel vun den Autorisatiounsversich huet d'Schwell no "Security Rule No. 23" iwwerschratt:
2.b.1 Gitt op Schrëtt 4, e Captcha gëtt zousätzlech op der Autorisatiounsform ugewisen
2.b.6 De System confirméiert richteg Captcha Entrée
2.b.6.1 Captcha falsch aginn:
2.b.6.1.1. de System vergréissert de Konter vun Mëssgléckt Autorisatioun Versich fir dëse Kont och
2.b.6.1.2. de System weist eng Feelermeldung an geet zréck op Schrëtt 2
6.a. Kee Kont mat dëser E-Mail gouf fonnt:
6.a.1 De System weist e Message iwwer Versoen a bitt e Choix fir entweder op Schrëtt 2 ze goen oder an de "Benotzerregistrierung" Szenario ze goen an déi aginn E-Mail ze späicheren,
6.b. D'Passwuert fir de Kont mat dëser E-Mail entsprécht net deem aginn:
6.b.1 De System vergréissert de Konter vun Mëssgléckt Login Versich op dëse Kont.
6.b.2 De System weist e Message iwwer Versoen a bitt e Choix fir entweder op de "Passwuert Erhuelung" Szenario ze goen oder op Schrëtt 2 ze goen.
6.c: De Login Versuch Konter fir dëse Kont huet d'Schwell fir "Sécherheetsregel Nr. 24" iwwerschratt.
6.c.1 De System weist e Message iwwer d'Blockéierung vun de Konto Login fir X Minutten a geet op Schrëtt 2 weider.
Wat ass super
Iwwerpréift fir Vollständegkeet an Konformitéit mat Ziler, dat ass, Dir kënnt Ufuerderunge fir en aneren Analyst fir d'Verifizéierung ginn, manner Feeler an der Phase vun der Problemformuléierung maachen.
Schafft mat engem schwaarze Këschtsystem erlaabt Iech d'Entwécklung an d'Koordinatioun mam Client ze trennen wat vun den Ëmsetzungsmethoden automatiséiert gëtt.
Et ass en Deel vum Analyst Wee, ee vun den Haaptdeeler vun der Benotzerfrëndlechkeet. De Szenario vum Benotzer definéiert d'Haaptweeër vu senger Bewegung, wat d'Wielfräiheet fir den Designer an de Client staark reduzéiert an hëlleft d'Geschwindegkeet vun der Designentwécklung ze erhéijen.
Ech si ganz zefridden mat der Plaz an der Beschreiwung wou Ausnahmen op all Interaktiounsschrëtt identifizéiert ginn. E komplette IT-System muss eng Aart vun Ausnahmshandhabung ubidden, e puer manuell, e puer automatesch (wéi am Beispill hei uewen).
D'Erfahrung weist datt e schlecht duerchduechten Ausnahmenhandhabung e System ganz einfach an e schrecklech onbequem System ka verwandelen. Ech erënnere mech un d'Geschicht wéi Dir an der Sowjetzäit, fir eng Entscheedung ze kréien, e puer Genehmegunge vu verschiddene Servicer musste kréien, a wéi schmerzhaft et ass wann de leschte Service seet - awer Är Uwendung ass am falschen Numm oder en anere Feeler an Punktuéierung, alles nei maachen an alles nei koordinéieren.
Ech kommen dacks op Situatiounen, wou d'Betribslogik vun engem System, deen net fir Ausnahmen geduecht war, bedeitend Ëmaarbechtung vum System erfuerdert. Dofir gëtt de Léiw vun der Aarbecht vum Analyst un Ausnahmshandhabung ausginn.
Textnotatioun, am Géigesaz zu Diagrammer, erlaabt méi Ausnahmen z'identifizéieren an ze iwwerdecken.
Zousätzlech zu der Method aus Praxis
De Benotzungsfall ass net en onofhängeg prioritéierten Deel vun der Ausso, am Géigesaz zu der Benotzergeschicht.
Am uewe genannte Szenario betruecht d'Ausnam "6.a. Kee Kont mat dëser E-Mail gouf fonnt." an de nächste Schrëtt "6.a.1 De System weist e Feelermeldung a geet op Schrëtt 2." Wéi eng negativ Saachen sinn hannert de Kulisse gelooss? Fir de Client ass all Retour der Tatsaach gläich datt all d'Aarbecht, déi hien gemaach huet fir d'Donnéeën anzeginn, an d'Deponie geheit. (Et ass just net am Skript ze gesinn!) Wat kann gemaach ginn? De Skript nei opbauen fir datt dëst net geschitt. Ass et méiglech dëst ze maachen? Dir kënnt - als Beispill, de Google Autorisatiounsskript kucken.
Szenario Optimisatioun
D'Buch schwätzt iwwer Formaliséierung, awer seet wéineg iwwer Methoden fir sou Szenarien ze optimiséieren.
Awer et ass méiglech d'Methode ze stäerken andeems se Szenarien optimiséieren, an d'Benotzungsfallsformaliséierungsmethod erlaabt dëst ze maachen. Besonnesch musst Dir iwwer all Ausnam nodenken, déi geschitt, d'Ursaach bestëmmen, an de Skript nei opzebauen fir d'Ausnam ze läschen oder d'Clienterees ze minimiséieren.
Wann Dir eng Bestellung vun engem Online-Geschäft maacht, musst Dir d'Liwwerstad aginn. Et kann sech erausstellen datt de Buttek keng Wueren an d'Stad liwwert, déi vum Client gewielt gëtt, well et net do liwwert, wéinst Gréisstbeschränkungen oder wéinst dem Mangel u Wueren am entspriechende Lager.
Wa mir einfach den Szenario vun der Interaktioun an der Aschreiwungsphase beschreiwen, kënne mir schreiwen "de Client informéieren datt d'Liwwerung onméiglech ass a bidden d'Stad oder d'Inhalter vum Weenchen z'änneren" (a vill Ufänger Analysten stoppen do). Awer wann et vill esou Fäll ass, da kann de Szenario optimiséiert ginn.
Dat éischt wat Dir maache musst ass Iech nëmmen d'Stad ze wielen wou mir kënne liwweren. Wéini dëst ze maachen? Virun engem Produkt op der Websäit auswielen (Autodetektioun vun der Stad iwwer IP mat Klärung).
Zweetens musse mir nëmmen e Choix vun de Wueren ginn, déi mir dem Client liwwere kënnen. Wéini dëst ze maachen? Am Moment vun der Auswiel - op de Produit Fliesen an Produit Kaart.
Dës zwou Ännerungen ginn e laange Wee fir dës Ausnam ze eliminéieren.
Ufuerderunge fir Miessunge a Metriken
Wann Dir d'Aufgab berücksichtegt fir d'Ausnahmshandhabung ze minimiséieren, kënnt Dir eng Berichterstattung setzen (Benotzungsfall ass net beschriwwen). Wéi vill Ausnahmen et waren, a wéi enge Fäll si geschitt sinn, plus wéi vill erakommen Szenarie erfollegräich passéiert sinn.
Awer leider. D'Erfahrung huet gewisen datt Berichterfuerderunge fir Szenarien an dëser Form net genuch sinn; et ass néideg Berichterfuerderunge fir Prozesser ze berücksichtegen déi haaptsächlech net a Form vun engem Benotzungsfall beschriwwe ginn.
Zougang zu Benotzerfrëndlechkeet
An eiser Praxis hu mir d'Benotzungsfallbeschreiwungsform erweidert mat enger Beschreiwung vu spezifesche Attributer vun Entitéiten an Daten fir de Client eng Entscheedung ze treffen, wat d'spéider Benotzerfrëndlechkeet verbessert.
Fir Benotzerfrëndlechkeet Design hu mir eng Input Sektioun bäigefüügt - Displaydaten.
An engem Szenario mat Autorisatioun ass dëst de Fakt datt de Client am System autoriséiert ass. Wann de Client viraus autoriséiert ass, weist dann eng Warnung iwwer d'Verännerung vun der Navigatiounsgeschicht an de Weenchen op den neie Kont no der erfollegräicher Autorisatioun.
Am Allgemengen ass dëst eng Affichage vun der néideger Informatioun fir de Client, fir datt hien eng Decisioun iwwer seng weider Handlungen no dem Szenario kann huelen (Dir kënnt froen ob dës Donnéeën genuch fir de Client sinn, wat soss gebraucht gëtt, wat Informatioun mécht de Client muss Entscheedungen treffen).
Et ass och derwäert déi aginn Informatioun an Inputfelder opzedeelen wann se separat veraarbecht ginn a mat der Bildung vu verschiddenen Ausnahmen.
Am Beispill mat Client Autorisatioun, wann Dir déi aginn Informatioun a Login a Passwuert trennt, ass et derwäert d'Autorisatiounsskript z'änneren fir d'Etappe vun engem getrennten Login an e separat Passwuert z'erhéijen (an dat gëtt gemaach Yandex, Google, awer net an de meeschte Online Geschäfter gemaach).
Erreechen déi erfuerderlech Datentransformatiounen
Dir kënnt och Ufuerderunge fir Datekonversiounsalgorithmen aus dem Skript extrahéieren.
Beispiller:
- Fir eng Entscheedung ze treffen fir e Produkt an engem Online-Geschäft ze kafen, muss de Client op der Produktkaart d'Méiglechkeet, d'Käschte, d'Liwwerzäit a senger Stad vun dësem Produkt wëssen (déi vum Algorithmus berechent ginn op Basis vun der Disponibilitéit vum Produkt an Lagerhaiser a Versuergungskettenparameter).
- Wann Dir e Saz an d'Sichlinn agitt, kritt de Client Sichsuggestiounen no dem Algorithmus (déi vum Algorithmus generéiert ginn ...).
Total
Am Allgemengen, nodeems Dir d'Buch gelies hutt, ass et leider net kloer wéi een de ganze Wee vun engem Analyst bis zu Geschäftsproblemer op eng formaliséiert technesch Spezifizéierung fir en Entwéckler geet. D'Buch erzielt nëmmen en Deel vum Prozess, mat den Input Schrëtt onkloer an déi nächst Schrëtt onkloer. De Benotzungsfall selwer ass meeschtens net eng komplett Ausso fir den Entwéckler.
Trotzdem ass dëst e ganz gudde Wee fir Szenarie vun der Interaktioun tëscht engem Objet an engem Sujet ze formaliséieren an ze veraarbecht, wann d'Interaktioun eng Ännerung an eppes am Thema verursaacht. Et ass eng vun de wéinege Schreifmethoden déi verifizéierbar Ufuerderunge mat explizit Ausnam Sichpunkte erlaabt.
D'Buch ass e Must-Lies fir Analysten fir unzefänken testbar Spiller ze schreiwen.
Source: will.com