Boken beskriver en metod för att skriva en del av en problemformulering, nämligen use case-metoden.
Vad det är? Detta är en beskrivning av användarinteraktionsscenariot med systemet (eller med verksamheten). I det här fallet fungerar systemet som en svart låda (och detta gör det möjligt att dela upp den komplexa designuppgiften i att designa interaktion och säkerställa denna interaktion). Samtidigt införs notationsstandarder, vilket säkerställer enkel läsning, även för icke-deltagare, och möjliggör vissa kontroller av fullständighet och överensstämmelse med intressentens mål.
Användningsexempel
Hur scenariot ser ut, med exemplet med auktorisering på webbplatsen via e-post:
(System) Logga in på webbplatsen för att komma åt ditt personliga konto. ~~ (havsnivå)
Sammanhang: En obehörig klient loggar in på sajten så att sajten känner igen honom och visar personlig information för honom: webbhistorik, köphistorik, aktuellt antal bonuspoäng etc., med e-post som inloggning.
nivå: användarmål
Huvudkaraktär: kund (besökare av vår webbutik)
Omfattning: Kundinteraktion med webbutikens webbplats
Intressenter och intressen:
- marknadsföraren vill att det maximala antalet webbplatsbesökare ska identifieras för större täckning av personliga utskick,
- säkerhetsspecialisten vill säkerställa att det inte finns några fall av obehörig åtkomst till besökarens personuppgifter, inklusive försök att gissa lösenordet för ett konto eller söka efter ett konto med ett svagt lösenord,
- angriparen vill få tillgång till offrets bonusar,
- konkurrenter vill lämna negativa recensioner på produkter,
- Botnätet vill skaffa butikens kundbas och använda en attack för att göra webbplatsen inoperabel.
Förutsättningar: besökaren får inte vara auktoriserad.
Minsta garantier: besökaren kommer att veta om auktoriseringsförsöket lyckades eller misslyckades.
Garanti för framgång: besökaren är auktoriserad.
Huvudscenario:
- Kunden initierar auktorisering.
- Systemet bekräftar att klienten inte är auktoriserad och inte överskrider antalet misslyckade auktoriseringsförsök från en given session (sökning efter ett svagt lösenord för flera konton) enligt "Säkerhetsregel nr 23".
- Systemet ökar räknaren för antalet auktoriseringsförsök.
- Systemet visar ett behörighetsformulär för kunden.
- Klienten anger sin e-postadress och sitt lösenord.
- Systemet bekräftar närvaron av en klient med sådan e-post i systemet och att lösenordet matchar och antalet inloggningsförsök till detta konto inte överskrids enligt "Säkerhetsregel nr 24".
- Systemet auktoriserar kunden, lägger till webbhistoriken och korgen för denna session med den sista sessionen för detta kundkonto.
- Systemet visar ett meddelande om framgång för auktorisering och går till skriptsteget från vilket klienten avbröts för auktorisering. I det här fallet laddas uppgifterna på sidan om med hänsyn till de personliga kontouppgifterna.
Tillägg:
2.a. Kunden är redan auktoriserad:
2.a.1. Systemet meddelar kunden om faktumet av den tidigare utförda auktoriseringen och erbjuder sig att antingen avbryta skriptet eller gå till steg 4, och om steg 6 har slutförts framgångsrikt, utförs steg 7 med förtydligande:
2.a.7. Systemet avaktiverar klienten under det gamla kontot, auktoriserar klienten under det nya kontot, medan webbhistoriken och varukorgen för denna interaktionssession finns kvar i det gamla kontot och överförs inte till det nya. Gå sedan till steg 8.
2.b Antalet auktoriseringsförsök har överskridit tröskeln enligt "Säkerhetsregel nr 23":
2.b.1 Gå till steg 4, en captcha visas dessutom på auktoriseringsformuläret
2.b.6 Systemet bekräftar korrekt captcha-inmatning
2.b.6.1 Captcha har angetts felaktigt:
2.b.6.1.1. systemet ökar räknaren för misslyckade auktoriseringsförsök även för detta konto
2.b.6.1.2. systemet visar ett felmeddelande och återgår till steg 2
6.a. Inget konto med denna e-postadress hittades:
6.a.1 Systemet visar ett meddelande om fel och erbjuder ett val att antingen gå till steg 2 eller gå till scenariot "Användarregistrering" och spara den inmatade e-posten,
6.b. Lösenordet för kontot med denna e-postadress stämmer inte överens med det angivna:
6.b.1 Systemet ökar räknaren för misslyckade inloggningsförsök till detta konto.
6.b.2 Systemet visar ett meddelande om fel och erbjuder ett val mellan att antingen gå till scenariot "Lösenordsåterställning" eller gå till steg 2.
6.c: Räknaren för inloggningsförsök för detta konto har överskridit tröskeln för "Säkerhetsregel nr 24."
6.c.1 Systemet visar ett meddelande om blockering av kontoinloggning i X minuter och fortsätter till steg 2.
Vad är bra
Kontrollerar fullständighet och överensstämmelse med mål, det vill säga du kan ge krav till en annan analytiker för verifiering, gör färre misstag i problemformuleringsstadiet.
Genom att arbeta med ett black box-system kan du separera utvecklingen och samordningen med kunden av vad som ska automatiseras från implementeringsmetoderna.
Det är en del av analytikerns väg, en av de viktigaste delarna av användbarhet. Användarens scenario definierar huvudvägarna för hans rörelse, vilket kraftigt minskar valfriheten för designern och kunden och hjälper till att öka hastigheten i designutvecklingen.
Jag är mycket nöjd med platsen i beskrivningen där undantag från varje interaktionssteg identifieras. Ett komplett IT-system måste ge någon form av undantagshantering, en del manuellt, en del automatiskt (som i exemplet ovan).
Erfarenheten visar att ogenomtänkt undantagshantering lätt kan göra ett system till ett fruktansvärt obekvämt system. Jag minns historien när man på sovjettiden, för att få ett beslut, var tvungen att få flera godkännanden från olika tjänster, och hur smärtsamt det är när den sista tjänsten säger - men din ansökan är i fel namn eller något annat fel i skiljetecken, gör om allt och samordna om allt.
Jag stöter ofta på situationer där driftlogiken i ett system som inte var genomtänkt för undantag krävde betydande omarbetning av systemet. På grund av detta läggs lejonparten av analytikerns arbete på undantagshantering.
Textnotation, i motsats till diagram, gör att fler undantag kan identifieras och täckas.
Tillägg till metoden från praktiken
Användningsfallet är inte en självständigt prioriterad del av uttalandet, till skillnad från användarberättelsen.
I scenariot ovan, överväg undantaget "6.a. Inget konto med denna e-postadress hittades." och nästa steg "6.a.1 Systemet visar ett felmeddelande och fortsätter till steg 2." Vilka negativa saker lämnades bakom kulisserna? För kunden är varje retur detsamma som att allt arbete han gjort med att lägga in data slängs på en soptipp. (Det syns bara inte i manuset!) Vad kan göras? Bygg om skriptet så att detta inte händer. Är det möjligt att göra detta? Du kan - som ett exempel, titta på Googles auktoriseringsskript.
Scenariooptimering
Boken talar om formalisering, men säger lite om metoder för att optimera sådana scenarier.
Men det är möjligt att stärka metoden genom att optimera scenarier, och användningsfallsformaliseringsmetoden gör att detta kan göras. Specifikt måste du tänka på varje undantag som inträffar, fastställa orsaken och bygga om skriptet för att bli av med undantaget eller minimera kundresan.
När du gör en beställning från en webbutik måste du ange leveransstad. Det kan visa sig att butiken inte kan leverera varor till den stad som kunden valt på grund av att den inte levererar dit, på grund av storleksbegränsningar eller på grund av brist på varor i motsvarande lager.
Om vi helt enkelt beskriver interaktionsscenariot vid registreringsstadiet kan vi skriva "informera kunden om att leverans är omöjlig och erbjuda att byta stad eller innehållet i vagnen" (och många nybörjaranalytiker stannar där). Men om det finns många sådana fall kan scenariot optimeras.
Det första du behöver göra är att låta dig välja endast den stad där vi kan leverera. När ska man göra detta? Innan du väljer en produkt på webbplatsen (automatisk upptäckt av staden via IP med förtydligande).
För det andra behöver vi endast välja de varor som vi kan leverera till kunden. När ska man göra detta? Vid urvalsögonblicket - på produktbrickan och produktkortet.
Dessa två ändringar går långt för att eliminera detta undantag.
Krav på mått och mått
När du överväger uppgiften att minimera undantagshanteringen kan du ställa in en rapporteringsuppgift (användningsfall beskrivs inte). Hur många undantag det fanns, i vilka fall de inträffade, plus hur många inkommande scenarier som lyckades.
Men ändå. Erfarenheten har visat att rapporteringskrav för scenarier i denna form inte räcker, utan det är nödvändigt att överväga rapporteringskrav för processer som beskrivs huvudsakligen inte i form av ett use case.
Tillgång till användbarhet
I vår praktik har vi utökat formuläret för beskrivning av användningsfall med en beskrivning av specifika attribut för enheter och data för kunden att fatta ett beslut, vilket förbättrar efterföljande användbarhet.
För användbarhetsdesign lade vi till en ingångssektion - visa data.
I ett scenario med behörighet är detta det faktum att klienten är auktoriserad i systemet. Om klienten är förauktoriserad, visa en varning om att byta navigeringshistorik och vagn till det nya kontot efter framgångsrik auktorisering.
I allmänhet är detta en visning av den nödvändiga informationen för klienten så att han kan fatta ett beslut om sina fortsatta handlingar enligt scenariot (du kan fråga om dessa uppgifter räcker för klienten, vad mer behövs, vilken information gör kunden behöver fatta beslut).
Det är också värt att dela upp den inmatade informationen i inmatningsfält om de behandlas separat och med olika undantag.
I exemplet med klientauktorisering, om du separerar den angivna informationen i inloggning och lösenord, är det värt att ändra auktoriseringsskriptet för att markera stadierna för att ange en separat inloggning och ett separat lösenord (och detta görs i Yandex, Google, men görs inte i de flesta nätbutiker).
Att nå de nödvändiga datatransformationerna
Du kan också extrahera krav för datakonverteringsalgoritmer från skriptet.
Exempel:
- För att fatta ett beslut om att köpa en produkt i en onlinebutik måste kunden på produktkortet veta möjligheten, kostnaden, leveranstiden till sin stad för denna produkt (som beräknas av algoritmen baserat på produktens tillgänglighet i lager och försörjningskedjans parametrar).
- När en fras skrivs in i sökraden visas klienten sökförslag enligt algoritmen (som genereras av algoritmen...).
Totalt
I allmänhet, efter att ha läst boken, är det tyvärr inte klart hur man ska gå hela vägen från en analytiker till affärsproblem till en formaliserad teknisk specifikation för en utvecklare. Boken berättar bara en del av processen, med inmatningsstegen otydliga och nästa steg otydliga. Användningsfallet i sig är oftast inte ett komplett uttalande för utvecklaren.
Ändå är detta ett mycket bra sätt att formalisera och bearbeta scenarier för interaktion mellan ett objekt och ett subjekt, när interaktionen orsakar en förändring av något i subjektet. Det är en av få skrivmetoder som tillåter verifierbara krav med explicita undantagssökningspunkter.
Boken är ett måste att läsa för analytiker för att börja skriva testbara pjäser.
Källa: will.com