Bogen beskriver én metode til at skrive en del af en problemformulering, nemlig use case-metoden.
Hvad er det? Dette er en beskrivelse af brugerinteraktionsscenariet med systemet (eller med virksomheden). I dette tilfælde fungerer systemet som en sort boks (og dette gør det muligt at opdele den komplekse designopgave i at designe interaktion og sikre denne interaktion). Samtidig indføres notationsstandarder, som sikrer let læsning, også for ikke-deltagere, og giver mulighed for nogle kontroller for fuldstændighed og overensstemmelse med interessentens mål.
Eksempel på et eksempel
Sådan ser scenariet ud ved at bruge eksemplet med autorisation på webstedet via e-mail:
(System) Log ind på hjemmesiden for at få adgang til din personlige konto. ~~ (havniveau)
Sammenhæng: En uautoriseret klient logger ind på siden, så siden genkender ham og viser personlige oplysninger for ham: browserhistorik, købshistorik, aktuelt antal bonuspoint osv., ved hjælp af e-mail som login.
niveau: brugermål
Hovedperson: klient (besøgende i vores online butik)
Omfang: Kundeinteraktion med netbutikkens hjemmeside
Interessenter og interesser:
- marketingmedarbejderen ønsker, at det maksimale antal besøgende på webstedet skal identificeres for større dækning af personlige forsendelser,
- sikkerhedsspecialisten ønsker at sikre, at der ikke er tilfælde af uautoriseret adgang til den besøgendes personlige data, herunder forsøg på at gætte adgangskoden til én konto eller søge efter en konto med en svag adgangskode,
- angriberen ønsker at få adgang til ofrets bonusser,
- konkurrenter ønsker at give negative anmeldelser på produkter,
- Botnettet ønsker at skaffe butikkens kundebase og bruge et angreb til at gøre webstedet ubrugeligt.
Forudsætninger: den besøgende må ikke være autoriseret.
Minimumsgarantier: den besøgende vil vide, om godkendelsesforsøget var vellykket eller mislykket.
Garanti for succes: den besøgende er autoriseret.
Hovedscenarie:
- Klienten iværksætter autorisation.
- Systemet bekræfter, at klienten ikke er autoriseret og ikke overstiger antallet af mislykkede godkendelsesforsøg fra en given session (søgning efter en svag adgangskode for flere konti) i henhold til "Sikkerhedsregel nr. 23".
- Systemet øger tælleren for antallet af godkendelsesforsøg.
- Systemet viser en autorisationsformular til klienten.
- Klienten indtaster sin e-mail og adgangskode.
- Systemet bekræfter tilstedeværelsen af en klient med en sådan e-mail i systemet, og at adgangskoden matcher og antallet af loginforsøg til denne konto ikke overskrides i henhold til "Sikkerhedsregel nr. 24".
- Systemet autoriserer klienten, tilføjer browserhistorikken og kurven for denne session med den sidste session på denne klientkonto.
- Systemet viser en meddelelse om succesfuld godkendelse og går til det scripttrin, hvorfra klienten blev afbrudt for godkendelse. I dette tilfælde genindlæses dataene på siden under hensyntagen til de personlige kontodata.
Udvidelser:
2.a. Klienten er allerede autoriseret:
2.a.1. Systemet underretter klienten om den tidligere udførte autorisation og tilbyder enten at afbryde scriptet eller gå til trin 4, og hvis trin 6 er gennemført, udføres trin 7 med afklaring:
2.a.7. Systemet deaktoriserer klienten under den gamle konto, autoriserer klienten under den nye konto, mens browserhistorikken og vognen for denne interaktionssession forbliver på den gamle konto og overføres ikke til den nye. Gå derefter til trin 8.
2.b Antallet af godkendelsesforsøg har overskredet tærsklen i henhold til "Sikkerhedsregel nr. 23":
2.b.1 Gå til trin 4, en captcha vises desuden på autorisationsformularen
2.b.6 Systemet bekræfter korrekt captcha-indtastning
2.b.6.1 Captcha indtastet forkert:
2.b.6.1.1. systemet øger tælleren for mislykkede godkendelsesforsøg også for denne konto
2.b.6.1.2. systemet viser en fejlmeddelelse og vender tilbage til trin 2
6.a. Der blev ikke fundet nogen konto med denne e-mail:
6.a.1 Systemet viser en meddelelse om fejl og tilbyder et valg mellem enten at gå til trin 2 eller gå til "Brugerregistrering"-scenariet og gemme den indtastede e-mail,
6.b. Adgangskoden til kontoen med denne e-mail stemmer ikke overens med den indtastede:
6.b.1 Systemet øger tælleren for mislykkede loginforsøg til denne konto.
6.b.2 Systemet viser en meddelelse om fejl og tilbyder et valg mellem enten at gå til "Password Recovery"-scenariet eller gå til trin 2.
6.c: Tælleren for loginforsøg for denne konto har overskredet tærsklen for "Sikkerhedsregel nr. 24."
6.c.1 Systemet viser en meddelelse om blokering af kontologin i X minutter og fortsætter til trin 2.
Hvad er fantastisk
Kontrollerer for fuldstændighed og overholdelse af mål, det vil sige, at du kan stille krav til en anden analytiker til verifikation og lave færre fejl på problemformuleringsstadiet.
At arbejde med et black box-system giver dig mulighed for at adskille udviklingen og koordineringen med kunden af, hvad der vil blive automatiseret, fra implementeringsmetoderne.
Det er en del af analytikerens vej, en af de vigtigste dele af brugervenlighed. Brugerens scenarie definerer hovedvejene i hans bevægelse, hvilket i høj grad reducerer valgfriheden for designeren og kunden og hjælper med at øge hastigheden af designudviklingen.
Jeg er meget tilfreds med det sted i beskrivelsen, hvor undtagelser fra hvert interaktionstrin er identificeret. Et komplet it-system skal sørge for en form for undtagelseshåndtering, nogle manuelt, nogle automatisk (som i eksemplet ovenfor).
Erfaring viser, at ugennemtænkt undtagelseshåndtering nemt kan gøre et system til et frygteligt ubelejligt system. Jeg husker historien, da man i sovjettiden, for at få en afgørelse, skulle have flere godkendelser fra forskellige tjenester, og hvor smertefuldt det er, når den sidste tjeneste siger - men din ansøgning er i det forkerte navn eller en anden fejl i tegnsætning, lav alt om og koordiner alt igen.
Jeg støder ofte på situationer, hvor driftslogikken i et system, der ikke var gennemtænkt for undtagelser, krævede betydelig omarbejdning af systemet. På grund af dette bruges broderparten af analytikerens arbejde på undtagelseshåndtering.
Tekstnotation, i modsætning til diagrammer, tillader flere undtagelser at blive identificeret og dækket.
Tilføjelse til metoden fra praksis
Use casen er ikke en selvstændigt prioriteret del af redegørelsen, i modsætning til brugerhistorien.
I ovenstående scenarie skal du overveje undtagelsen "6.a. Der blev ikke fundet nogen konto med denne e-mail." og næste trin "6.a.1 Systemet viser en fejlmeddelelse og fortsætter til trin 2." Hvilke negative ting blev efterladt bag kulisserne? For kunden er ethvert afkast ensbetydende med, at alt det arbejde, han har udført med at indtaste data, bliver smidt på en losseplads. (Det er bare ikke synligt i manuskriptet!) Hvad kan man gøre? Genopbyg scriptet, så dette ikke sker. Er det muligt at gøre dette? Du kan - som et eksempel, se på Googles autorisationsscript.
Scenario optimering
Bogen taler om formalisering, men siger lidt om metoder til at optimere sådanne scenarier.
Men det er muligt at styrke metoden ved at optimere scenarier, og use case-formaliseringsmetoden gør det muligt. Specifikt skal du tænke over hver undtagelse, der opstår, bestemme årsagen og genopbygge scriptet for at slippe af med undtagelsen eller minimere kunderejsen.
Når du afgiver en ordre fra en netbutik, skal du indtaste leveringsbyen. Det kan vise sig, at butikken ikke kan levere varer til den by, kunden har valgt, fordi den ikke leverer der, på grund af størrelsesbegrænsninger eller på grund af mangel på varer på det tilsvarende lager.
Hvis vi blot beskriver scenariet for interaktion på registreringsstadiet, kan vi skrive "informere kunden om, at levering er umulig og tilbyde at ændre byen eller indholdet af vognen" (og mange nybegyndere analytikere stopper der). Men hvis der er mange af sådanne tilfælde, så kan scenariet optimeres.
Det første du skal gøre er at lade dig vælge kun den by, hvor vi kan levere. Hvornår skal man gøre dette? Før du vælger et produkt på hjemmesiden (autodetektion af byen via IP med afklaring).
For det andet skal vi kun vælge de varer, som vi kan levere til kunden. Hvornår skal man gøre dette? I valgøjeblikket - på produktflisen og produktkortet.
Disse to ændringer går langt i retning af at eliminere denne undtagelse.
Krav til målinger og metrik
Når du overvejer opgaven med at minimere undtagelseshåndtering, kan du indstille en rapporteringsopgave (use case er ikke beskrevet). Hvor mange undtagelser var der, i hvilke tilfælde de forekom, plus hvor mange indkommende scenarier bestod med succes.
Men ak. Erfaringsmæssigt er rapporteringskrav til scenarier i denne form ikke nok, det er nødvendigt at overveje rapporteringskrav for processer, der hovedsageligt er beskrevet ikke i form af en use case.
Adgang til Usability
I vores praksis har vi udvidet use case-beskrivelsesskemaet med en beskrivelse af specifikke attributter ved enheder og data, som kunden kan træffe en beslutning, hvilket øger den efterfølgende anvendelighed.
For brugervenligt design tilføjede vi en input sektion - display data.
I et scenarie med autorisation er dette det faktum, at klienten er autoriseret i systemet. Hvis klienten er forhåndsautoriseret, skal du vise en advarsel om at skifte navigationshistorikken og vognen til den nye konto efter vellykket godkendelse.
Generelt er dette en visning af den nødvendige information til klienten, så han kan træffe en beslutning om sine videre handlinger i henhold til scenariet (du kan spørge, om disse data er nok for klienten, hvad der ellers er nødvendigt, hvilke oplysninger gør kundens behov for at træffe beslutninger).
Det er også værd at opdele de indtastede oplysninger i inputfelter, hvis de behandles separat og med dannelse af forskellige undtagelser.
I eksemplet med klientautorisation, hvis du adskiller de indtastede oplysninger i login og adgangskode, så er det værd at ændre autorisationsscriptet for at fremhæve stadierne af indtastning af et separat login og en separat adgangskode (og dette gøres i Yandex, Google, men ikke gjort i de fleste netbutikker).
At nå de nødvendige datatransformationer
Du kan også udtrække krav til datakonverteringsalgoritmer fra scriptet.
Eksempler:
- For at træffe en beslutning om at købe et produkt i en onlinebutik skal kunden på produktkortet kende muligheden, prisen, leveringstiden til hans by for dette produkt (som beregnes af algoritmen baseret på tilgængeligheden af produktet i lagre og forsyningskædeparametre).
- Når du indtaster en sætning i søgelinjen, får klienten vist søgeforslag i henhold til algoritmen (som genereres af algoritmen...).
I alt
Generelt, efter at have læst bogen, er det desværre ikke klart, hvordan man går hele vejen fra en analytiker til forretningsproblemer til en formaliseret teknisk specifikation for en udvikler. Bogen fortæller kun en del af processen, hvor inputtrinnene er uklare og de næste trin uklare. Selve use casen er oftest ikke en komplet erklæring for udvikleren.
Ikke desto mindre er dette en meget god måde at formalisere og bearbejde scenarier for interaktion mellem et objekt og et subjekt, når interaktionen forårsager en ændring i noget i subjektet. Det er en af de få skrivemetoder, der tillader kontrollerbare krav med eksplicitte undtagelsessøgepunkter.
Bogen er et must-read for analytikere for at begynde at skrive testbare skuespil.
Kilde: www.habr.com