Het boek beschrijft één methode voor het schrijven van een deel van een probleemstelling, namelijk de use case-methode.
Wat het is? Dit is een beschrijving van het gebruikersinteractiescenario met het systeem (of met het bedrijf). In dit geval fungeert het systeem als een black box (en dit maakt het mogelijk om de complexe ontwerpopgave op te delen in het ontwerpen van interactie en het borgen van deze interactie). Tegelijkertijd worden notatiestandaarden geïntroduceerd, die het leesgemak garanderen, ook voor niet-deelnemers, en enkele controles mogelijk maken op volledigheid en naleving van de doelstellingen van de belanghebbende.
Gebruiksvoorbeeld
Hoe het scenario eruit ziet, aan de hand van het voorbeeld van autorisatie op de site via e-mail:
(Systeem) Log in op de website om toegang te krijgen tot uw persoonlijke account. ~~ (zeeniveau)
Context: Een ongeautoriseerde klant logt in op de site zodat de site hem herkent en persoonlijke informatie voor hem toont: browsegeschiedenis, aankoopgeschiedenis, huidig aantal bonuspunten, enz., waarbij e-mail als login wordt gebruikt.
level: gebruikersdoel
Hoofdpersoon: klant (bezoeker van onze online winkel)
Domein: Klantinteractie met de website van de online winkel
Stakeholders en belangen:
- de marketeer wil dat het maximale aantal sitebezoekers wordt geïdentificeerd voor een grotere dekking van persoonlijke mailings,
- de beveiligingsspecialist ervoor wil zorgen dat er geen sprake is van ongeoorloofde toegang tot de persoonsgegevens van de bezoeker, waaronder pogingen om het wachtwoord van één account te raden of te zoeken naar een account met een zwak wachtwoord,
- de aanvaller wil toegang krijgen tot de bonussen van het slachtoffer,
- concurrenten willen negatieve recensies over producten achterlaten,
- Het botnet wil het klantenbestand van de winkel overnemen en met een aanval de site onbruikbaar maken.
Randvoorwaarden: de bezoeker mag geen toestemming hebben.
Minimale garanties: de bezoeker weet of de autorisatiepoging succesvol of niet succesvol was.
Garanties voor succes: de bezoeker is geautoriseerd.
Hoofdscenario:
- De klant initieert autorisatie.
- Het systeem bevestigt dat de cliënt niet geautoriseerd is en overschrijdt niet het aantal mislukte autorisatiepogingen van een bepaalde sessie (zoeken naar een zwak wachtwoord voor meerdere accounts) volgens “Veiligheidsregel nr. 23”.
- Het systeem verhoogt de teller voor het aantal autorisatiepogingen.
- Het systeem toont een autorisatieformulier aan de klant.
- De klant voert zijn e-mailadres en wachtwoord in.
- Het systeem bevestigt de aanwezigheid van een klant met een dergelijk e-mailadres in het systeem en dat het wachtwoord overeenkomt en dat het aantal inlogpogingen op dit account niet wordt overschreden volgens “Veiligheidsregel nr. 24”.
- Het systeem autoriseert de klant, voegt de browsegeschiedenis en het winkelmandje van deze sessie toe aan de laatste sessie van dit klantaccount.
- Het systeem geeft een bericht weer dat de autorisatie is geslaagd en gaat naar de scriptstap waar de client werd onderbroken voor autorisatie. In dit geval worden de gegevens op de pagina opnieuw geladen, rekening houdend met de persoonlijke accountgegevens.
Extensies:
2.a. De klant is al geautoriseerd:
2.a.1. Het systeem informeert de klant over het feit van de eerder uitgevoerde autorisatie en biedt aan om het script te onderbreken of naar stap 4 te gaan, en als stap 6 met succes is voltooid, wordt stap 7 met verduidelijking uitgevoerd:
2.a.7. Het systeem deactiveert de klant onder het oude account en autoriseert de klant onder het nieuwe account, terwijl de browsegeschiedenis en het winkelwagentje van deze interactiesessie in het oude account blijven en niet worden overgedragen naar het nieuwe account. Ga vervolgens naar stap 8.
2.b Het aantal autorisatiepogingen heeft de drempel overschreden volgens “Veiligheidsregel nr. 23”:
2.b.1 Ga naar stap 4, op het machtigingsformulier wordt bovendien een captcha weergegeven
2.b.6 Het systeem bevestigt dat de captcha correct is ingevoerd
2.b.6.1 Captcha verkeerd ingevoerd:
2.b.6.1.1. het systeem verhoogt ook de teller van mislukte autorisatiepogingen voor dit account
2.b.6.1.2. het systeem geeft een foutmelding weer en keert terug naar stap 2
6.a. Er is geen account met dit e-mailadres gevonden:
6.a.1 Het systeem geeft een bericht weer over een fout en biedt de keuze om naar stap 2 te gaan of naar het scenario “Gebruikersregistratie” te gaan en de ingevoerde e-mail op te slaan,
6.b. Het wachtwoord voor het account met dit e-mailadres komt niet overeen met het ingevoerde wachtwoord:
6.b.1 Het systeem verhoogt de teller van mislukte inlogpogingen op dit account.
6.b.2 Het systeem geeft een bericht weer over een fout en biedt de keuze om naar het scenario “Wachtwoordherstel” te gaan of naar stap 2 te gaan.
6.c: De teller van de inlogpogingen voor dit account heeft de drempel voor “Beveiligingsregel nr. 24” overschreden.
6.c.1 Het systeem geeft een bericht weer over het blokkeren van accountaanmelding gedurende X minuten en gaat verder met stap 2.
Wat is geweldig
Controleert op volledigheid en naleving van doelstellingen, dat wil zeggen dat u ter verificatie eisen aan een andere analist kunt geven, waardoor u minder fouten maakt in de fase van probleemformulering.
Door te werken met een black box systeem kun je de ontwikkeling en afstemming met de klant van wat geautomatiseerd gaat worden scheiden van de implementatiemethodieken.
Het maakt deel uit van het pad van de analist, een van de belangrijkste onderdelen van bruikbaarheid. Het scenario van de gebruiker definieert de hoofdlijnen van zijn beweging, wat de keuzevrijheid voor de ontwerper en de klant aanzienlijk beperkt en de snelheid van de ontwerpontwikkeling helpt verhogen.
Ik ben erg blij met de plaats in de beschrijving waar uitzonderingen op elke interactiestap worden geïdentificeerd. Een compleet IT-systeem moet voorzien in een of andere vorm van afhandeling van uitzonderingen, sommige handmatig, sommige automatisch (zoals in het bovenstaande voorbeeld).
De ervaring leert dat slecht doordachte uitzonderingsafhandeling een systeem gemakkelijk in een vreselijk onhandig systeem kan veranderen. Ik herinner me het verhaal toen je in de Sovjettijd, om een beslissing te krijgen, verschillende goedkeuringen van verschillende diensten moest krijgen, en hoe pijnlijk het is als de laatste dienst zegt: maar je aanvraag staat op de verkeerde naam of er is een andere fout in interpunctie, alles opnieuw doen en alles opnieuw coördineren.
Ik kom vaak situaties tegen waarin de werkingslogica van een systeem dat niet op uitzonderingen was afgestemd, een aanzienlijke herwerking van het systeem vereiste. Hierdoor wordt het leeuwendeel van het werk van de analist besteed aan het afhandelen van uitzonderingen.
Door tekstnotatie, in tegenstelling tot diagrammen, kunnen meer uitzonderingen worden geïdentificeerd en afgedekt.
Aanvulling op de werkwijze uit de praktijk
De use case is geen onafhankelijk geprioriteerd onderdeel van de verklaring, in tegenstelling tot het gebruikersverhaal.
Overweeg in het bovenstaande scenario uitzondering “6.a. Er is geen account met dit e-mailadres gevonden.” en de volgende stap “6.a.1 Het systeem geeft een foutmelding weer en gaat door naar stap 2.” Welke negatieve dingen bleven achter de schermen? Voor de klant komt elke opbrengst neer op het feit dat al het werk dat hij heeft gedaan bij het invoeren van gegevens op een stortplaats wordt gegooid. (Het is gewoon niet zichtbaar in het script!) Wat kan er gedaan worden? Herbouw het script zodat dit niet gebeurt. Is het mogelijk om dit te doen? Je kunt bijvoorbeeld naar het autorisatiescript van Google kijken.
Scenario-optimalisatie
Het boek spreekt over formalisering, maar zegt weinig over methoden om dergelijke scenario's te optimaliseren.
Maar het is mogelijk om de methode te versterken door scenario’s te optimaliseren, en de use case-formalisatiemethode maakt dit mogelijk. Concreet moet u nadenken over elke uitzondering die zich voordoet, de oorzaak vaststellen en het script opnieuw opbouwen om van de uitzondering af te komen of de klantreis te minimaliseren.
Wanneer u een bestelling plaatst in een online winkel, moet u de plaats van levering invoeren. Het kan blijken dat de winkel de goederen niet kan leveren in de door de klant gekozen stad, omdat deze daar niet levert vanwege groottebeperkingen of vanwege een gebrek aan goederen in het bijbehorende magazijn.
Als we eenvoudigweg het interactiescenario in de registratiefase beschrijven, kunnen we schrijven "de klant informeren dat levering onmogelijk is en aanbieden om de stad of de inhoud van de winkelwagen te veranderen" (en veel beginnende analisten stoppen daar). Maar als er veel van dergelijke gevallen zijn, kan het scenario worden geoptimaliseerd.
Het eerste dat u hoeft te doen, is u alleen de stad laten kiezen waar we kunnen bezorgen. Wanneer moet u dit doen? Voordat u een product op de website selecteert (autodetectie van de stad via IP met verduidelijking).
Ten tweede hoeven we alleen een keuze te geven uit de goederen die we aan de klant kunnen leveren. Wanneer moet u dit doen? Op het moment van selectie - op de producttegel en productkaart.
Deze twee veranderingen zijn een grote stap in de richting van het elimineren van deze uitzondering.
Vereisten voor metingen en statistieken
Wanneer u de taak overweegt om de afhandeling van uitzonderingen te minimaliseren, kunt u een rapportagetaak instellen (gebruiksscenario wordt niet beschreven). Hoeveel uitzonderingen waren er, in welke gevallen deze zich voordeden, plus hoeveel binnenkomende scenario's met succes werden afgehandeld.
Maar helaas. De ervaring heeft geleerd dat rapportagevereisten voor scenario's in deze vorm niet voldoende zijn; het is noodzakelijk om rapportagevereisten te overwegen voor processen die voornamelijk niet in de vorm van een use case worden beschreven.
Toegang tot bruikbaarheid
In onze praktijk hebben we het use case-beschrijvingsformulier uitgebreid met een beschrijving van specifieke kenmerken van entiteiten en gegevens, zodat de klant een beslissing kan nemen, wat de latere bruikbaarheid vergroot.
Voor bruikbaarheidsontwerp hebben we een invoersectie toegevoegd: gegevens weergeven.
In een scenario met autorisatie is dit het feit dat de cliënt geautoriseerd is in het systeem. Als de klant vooraf is geautoriseerd, geeft u na succesvolle autorisatie een waarschuwing weer over het overschakelen van de navigatiegeschiedenis en het winkelwagentje naar het nieuwe account.
Over het algemeen is dit een weergave van de benodigde informatie voor de cliënt zodat hij volgens het scenario een beslissing kan nemen over zijn verdere handelen (je kunt vragen of deze gegevens voldoende zijn voor de cliënt, wat er nog meer nodig is, welke informatie de cliënt moet beslissingen nemen).
Het is ook de moeite waard om de ingevoerde informatie in invoervelden te verdelen als deze afzonderlijk worden verwerkt en met de vorming van verschillende uitzonderingen.
Als u in het voorbeeld met klantautorisatie de ingevoerde informatie scheidt in login en wachtwoord, is het de moeite waard om het autorisatiescript te wijzigen om de fasen van het invoeren van een afzonderlijke login en een afzonderlijk wachtwoord te markeren (en dit gebeurt in Yandex, Google, maar niet gedaan in de meeste online winkels).
Het realiseren van de benodigde datatransformaties
U kunt ook vereisten voor algoritmen voor gegevensconversie uit het script halen.
Voorbeelden:
- Om een beslissing te nemen om een product in een online winkel te kopen, moet de klant op de productkaart de mogelijkheid, kosten en levertijd van dit product in zijn stad weten (die door het algoritme worden berekend op basis van de beschikbaarheid van het product in magazijnen en supply chain-parameters).
- Bij het invoeren van een zin in de zoekregel krijgt de klant zoeksuggesties te zien volgens het algoritme (die worden gegenereerd door het algoritme...).
In totaal
Over het algemeen is het na het lezen van het boek helaas niet duidelijk hoe je helemaal van een analist via zakelijke problemen naar een geformaliseerde technische specificatie voor een ontwikkelaar kunt gaan. Het boek vertelt slechts een deel van het proces, waarbij de invoerstappen onduidelijk zijn en de volgende stappen onduidelijk. De use case zelf is meestal geen volledige verklaring voor de ontwikkelaar.
Niettemin is dit een zeer goede manier om scenario's van interactie tussen een object en een subject te formaliseren en te verwerken, wanneer de interactie een verandering in iets in het subject veroorzaakt. Het is een van de weinige schrijfmethoden die verifieerbare vereisten mogelijk maken met expliciete zoekpunten voor uitzonderingen.
Het boek is een must-read voor analisten die willen beginnen met het schrijven van testbare toneelstukken.
Bron: www.habr.com