Boken beskriver én metode for å skrive en del av en problemstilling, nemlig use case-metoden.
Hva det er? Dette er en beskrivelse av brukerinteraksjonsscenariet med systemet (eller med virksomheten). I dette tilfellet fungerer systemet som en svart boks (og dette gjør det mulig å dele opp den komplekse designoppgaven i å designe interaksjon og sikre denne interaksjonen). Samtidig introduseres notasjonsstandarder, som sikrer enkel lesing, også for ikke-deltakere, og åpner for noen kontroller for fullstendighet og samsvar med målene til interessenten.
Bruk case eksempel
Hvordan scenariet ser ut, ved å bruke eksemplet med autorisasjon på et nettsted via e-post:
(System) Logg inn på nettstedet for å få tilgang til din personlige konto. ~~ (havnivå)
Kontekst: En uautorisert klient logger inn på siden slik at siden gjenkjenner ham og viser personlig informasjon for ham: nettleserhistorikk, kjøpshistorikk, nåværende antall bonuspoeng osv., ved å bruke e-post som pålogging.
nivå: brukermål
Hovedperson: klient (besøkende av vår nettbutikk)
Omfang: Kundeinteraksjon med nettbutikkens nettsted
Interessenter og interesser:
- markedsføreren ønsker at det maksimale antallet besøkende på nettstedet skal identifiseres for større dekning av personlige utsendelser,
- sikkerhetsspesialisten ønsker å sikre at det ikke er tilfeller av uautorisert tilgang til besøkendes personlige data, inkludert forsøk på å gjette passordet for én konto eller søke etter en konto med et svakt passord,
- angriperen ønsker å få tilgang til offerets bonuser,
- konkurrenter ønsker å legge igjen negative anmeldelser på produkter,
- Botnettet ønsker å få tak i butikkens kundebase og bruke et angrep for å gjøre nettstedet ubrukelig.
Forutsetninger: besøkende må ikke være autorisert.
Minimumsgarantier: besøkende vil vite om autorisasjonsforsøket var vellykket eller mislykket.
Garantier for suksess: den besøkende er autorisert.
Hovedscenario:
- Klienten initierer autorisasjon.
- Systemet bekrefter at klienten ikke er autorisert og ikke overskrider antall mislykkede autorisasjonsforsøk fra en gitt økt (søker etter et svakt passord for flere kontoer) i henhold til "Sikkerhetsregel nr. 23".
- Systemet øker telleren for antall autorisasjonsforsøk.
- Systemet viser et autorisasjonsskjema til klienten.
- Klienten skriver inn sin e-post og passord.
- Systemet bekrefter tilstedeværelsen av en klient med en slik e-post i systemet og at passordet samsvarer og antall påloggingsforsøk til denne kontoen ikke overskrides i henhold til "Sikkerhetsregel nr. 24".
- Systemet autoriserer klienten, legger til nettleserhistorikken og kurven for denne økten med den siste økten av denne klientkontoen.
- Systemet viser en melding om suksess for godkjenning og går til skripttrinnet som klienten ble avbrutt fra for godkjenning. I dette tilfellet blir dataene på siden lastet inn på nytt under hensyntagen til de personlige kontodataene.
Utvidelser:
2.a. Kunden er allerede autorisert:
2.a.1. Systemet varsler klienten om den tidligere utførte autorisasjonen og tilbyr å enten avbryte skriptet eller gå til trinn 4, og hvis trinn 6 er fullført, utføres trinn 7 med avklaring:
2.a.7. Systemet deaktoriserer klienten under den gamle kontoen, autoriserer klienten under den nye kontoen, mens nettleserloggen og handlekurven for denne interaksjonsøkten forblir i den gamle kontoen og overføres ikke til den nye. Gå deretter til trinn 8.
2.b Antall autorisasjonsforsøk har overskredet terskelen i henhold til "Sikkerhetsregel nr. 23":
2.b.1 Gå til trinn 4, en captcha vises i tillegg på autorisasjonsskjemaet
2.b.6 Systemet bekrefter korrekt captcha-inntasting
2.b.6.1 Captcha angitt feil:
2.b.6.1.1. systemet øker telleren for mislykkede autorisasjonsforsøk også for denne kontoen
2.b.6.1.2. systemet viser en feilmelding og går tilbake til trinn 2
6.a. Ingen konto med denne e-postadressen ble funnet:
6.a.1 Systemet viser en melding om feil og tilbyr et valg om enten å gå til trinn 2 eller gå til "Brukerregistrering"-scenariet og lagre den angitte e-posten,
6.b. Passordet for kontoen med denne e-posten samsvarer ikke med det som er angitt:
6.b.1 Systemet øker telleren for mislykkede påloggingsforsøk til denne kontoen.
6.b.2 Systemet viser en melding om feil og tilbyr et valg om enten å gå til "Passordgjenoppretting"-scenariet eller gå til trinn 2.
6.c: Telleren for påloggingsforsøk for denne kontoen har overskredet terskelen for «Sikkerhetsregel nr. 24».
6.c.1 Systemet viser en melding om blokkering av kontopålogging i X minutter og går videre til trinn 2.
Hva er flott
Sjekker for fullstendighet og overholdelse av mål, det vil si at du kan stille krav til en annen analytiker for verifisering, og gjøre færre feil på stadiet av problemformuleringen.
Å jobbe med et black box-system lar deg skille utviklingen og koordineringen med kunden av hva som skal automatiseres fra implementeringsmetodene.
Det er en del av analytikerens vei, en av hoveddelene av brukervennlighet. Brukerens scenario definerer hovedveiene for hans bevegelse, noe som i stor grad reduserer valgfriheten for designeren og kunden og bidrar til å øke hastigheten på designutviklingen.
Jeg er veldig fornøyd med stedet i beskrivelsen hvor unntak fra hvert interaksjonstrinn er identifisert. Et komplett IT-system må sørge for en eller annen form for unntakshåndtering, noen manuelt, noen automatisk (som i eksempelet ovenfor).
Erfaring viser at lite gjennomtenkt unntakshåndtering lett kan gjøre et system til et fryktelig upraktisk system. Jeg husker historien da du i sovjettiden, for å få en avgjørelse, måtte få flere godkjenninger fra forskjellige tjenester, og hvor vondt det er når den siste tjenesten sier - men søknaden din er i feil navn eller en annen feil i tegnsetting, gjør om alt og koordiner alt på nytt.
Jeg kommer ofte over situasjoner der driftslogikken til et system som ikke var gjennomtenkt for unntak krevde betydelig omarbeiding av systemet. På grunn av dette blir brorparten av analytikerens arbeid brukt på unntakshåndtering.
Tekstnotasjon, i motsetning til diagrammer, gjør at flere unntak kan identifiseres og dekkes.
Tillegg til metoden fra praksis
Brukstilfellet er ikke en uavhengig prioritert del av utsagnet, i motsetning til brukerhistorien.
I scenariet ovenfor, vurder unntaket "6.a. Ingen konto med denne e-postadressen ble funnet." og neste trinn "6.a.1 Systemet viser en feilmelding og fortsetter til trinn 2." Hvilke negative ting ble igjen bak kulissene? For klienten er enhver retur ensbetydende med at alt arbeidet han gjorde med å legge inn data blir kastet på et deponi. (Det er bare ikke synlig i manuset!) Hva kan gjøres? Bygg skriptet på nytt slik at dette ikke skjer. Er det mulig å gjøre dette? Du kan som et eksempel se på Googles autorisasjonsskript.
Scenariooptimalisering
Boken snakker om formalisering, men sier lite om metoder for å optimalisere slike scenarier.
Men det er mulig å styrke metoden ved å optimalisere scenarier, og use case-formaliseringsmetoden lar dette gjøres. Spesifikt må du tenke på hvert unntak som oppstår, finne årsaken og gjenoppbygge skriptet for å bli kvitt unntaket eller minimere kundereisen.
Når du legger inn en bestilling fra en nettbutikk, må du angi leveringsbyen. Det kan vise seg at butikken ikke kan levere varer til den byen kunden har valgt fordi den ikke leverer der, på grunn av størrelsesbegrensninger, eller på grunn av mangel på varer på det tilsvarende lageret.
Hvis vi ganske enkelt beskriver scenariet for interaksjon på registreringsstadiet, kan vi skrive "informere klienten om at levering er umulig og tilby å endre byen eller innholdet i handlekurven" (og mange nybegynnere analytikere stopper der). Men hvis det er mange slike tilfeller, kan scenarioet optimaliseres.
Det første du må gjøre er å la deg velge bare byen der vi kan levere. Når skal man gjøre dette? Før du velger et produkt på nettstedet (autodeteksjon av byen via IP med avklaring).
For det andre må vi kun velge de varene vi kan levere til kunden. Når skal man gjøre dette? I valgøyeblikket - på produktflisen og produktkortet.
Disse to endringene går langt mot å eliminere dette unntaket.
Krav til målinger og beregninger
Når du vurderer oppgaven med å minimere unntakshåndtering, kan du sette en rapporteringsoppgave (brukstilfelle er ikke beskrevet). Hvor mange unntak det var, i hvilke tilfeller de oppstod, pluss hvor mange innkommende scenarier som ble bestått.
Men akk. Erfaringsmessig er rapporteringskrav for scenarier i denne formen ikke nok, det er nødvendig å vurdere rapporteringskrav for prosesser som er beskrevet hovedsakelig ikke i form av en use case.
Tilgang til brukervennlighet
I vår praksis har vi utvidet skjemaet for brukstilfellebeskrivelse med en beskrivelse av spesifikke attributter til enheter og data for at klienten skal kunne ta en beslutning, noe som øker den senere brukervennligheten.
For brukervennlighetsdesign la vi til en inngangsseksjon - visningsdata.
I et scenario med autorisasjon er dette det faktum at klienten er autorisert i systemet. Hvis klienten er forhåndsautorisert, viser du en advarsel om å bytte navigasjonshistorikk og handlekurv til den nye kontoen etter vellykket godkjenning.
Generelt er dette en visning av nødvendig informasjon for klienten slik at han kan ta en beslutning om sine videre handlinger i henhold til scenariet (du kan spørre om disse dataene er nok for klienten, hva annet er nødvendig, hvilken informasjon gjør klienten må ta avgjørelser).
Det er også verdt å dele opp den angitte informasjonen i inndatafelt hvis de behandles separat og med dannelse av forskjellige unntak.
I eksemplet med klientautorisasjon, hvis du skiller den angitte informasjonen inn i pålogging og passord, er det verdt å endre autorisasjonsskriptet for å markere stadiene for å angi en separat pålogging og et eget passord (og dette gjøres i Yandex, Google, men ikke gjort i de fleste nettbutikker).
Nå de nødvendige datatransformasjonene
Du kan også trekke ut krav til datakonverteringsalgoritmer fra skriptet.
Eksempler:
- For å ta en beslutning om å kjøpe et produkt i en nettbutikk, må kunden vite på produktkortet muligheten, kostnaden, leveringstiden til byen hans for dette produktet (som beregnes av algoritmen basert på tilgjengeligheten til produktet i lagre og forsyningskjedeparametere).
- Når du skriver inn en frase i søkelinjen, får klienten søkeforslag i henhold til algoritmen (som genereres av algoritmen...).
Totalt
Generelt, etter å ha lest boken, er det dessverre ikke klart hvordan man skal gå hele veien fra en analytiker til forretningsproblemer til en formalisert teknisk spesifikasjon for en utvikler. Boken forteller bare en del av prosessen, med input-trinnene uklare og de neste trinnene uklare. Selve use casen er som oftest ikke en fullstendig uttalelse for utvikleren.
Likevel er dette en veldig god måte å formalisere og bearbeide scenarier for interaksjon mellom et objekt og et subjekt, når interaksjonen forårsaker en endring i noe i subjektet. Det er en av få skrivemetoder som tillater verifiserbare krav med eksplisitte unntakssøkepunkter.
Boken er et must-lese for analytikere for å begynne å skrive testbare skuespill.
Kilde: www.habr.com