Knygoje aprašomas vienas problemos teiginio dalies rašymo būdas, būtent naudojimo atvejo metodas.
Kas tai yra? Tai vartotojo sąveikos su sistema (arba su įmone) scenarijaus aprašymas. Šiuo atveju sistema veikia kaip juodoji dėžė (ir tai leidžia sudėtingą projektavimo užduotį padalinti į sąveikos projektavimą ir šios sąveikos užtikrinimą). Kartu įvedami žymėjimo standartai, užtikrinantys skaitymo patogumą, taip pat ir nedalyvaujantiems asmenims bei leidžiantys tam tikrus patikrinimus, ar jie yra išsamūs ir atitinka suinteresuoto asmens tikslus.
Naudokite atvejo pavyzdį
Kaip atrodo scenarijus, naudojant autorizavimo svetainėje pavyzdį el. paštu:
(Sistema) Prisijunkite prie svetainės, kad pasiektumėte savo asmeninę paskyrą. ~~ (jūros lygis)
Kontekstas: Neteisėtas klientas prisijungia prie svetainės, kad svetainė jį atpažintų ir parodytų jam asmeninę informaciją: naršymo istoriją, pirkinių istoriją, esamą premijos taškų skaičių ir kt., kaip prisijungimą naudodamas el.
Lygis: naudotojo tikslas
Pagrindinis veikėjas: klientas (mūsų internetinės parduotuvės lankytojas)
Taikymo sritis: Kliento sąveika su internetinės parduotuvės svetaine
Suinteresuotosios šalys ir interesai:
- rinkodaros specialistas nori, kad būtų nustatytas maksimalus svetainės lankytojų skaičius, kad būtų geriau aprėpti asmeniniai laiškai,
- saugos specialistas nori užtikrinti, kad nebūtų neteisėtos prieigos prie lankytojo asmens duomenų atvejų, įskaitant bandymus atspėti vienos paskyros slaptažodį arba ieškoti paskyros su silpnu slaptažodžiu,
- užpuolikas nori gauti aukos premijas,
- konkurentai nori palikti neigiamus atsiliepimus apie produktus,
- Botnetas nori gauti parduotuvės klientų bazę ir panaudoti ataką, kad svetainė neveiktų.
Prielaidos: lankytojas neturi būti įgaliotas.
Minimalios garantijos: lankytojas žinos, ar autorizavimo bandymas buvo sėkmingas, ar nesėkmingas.
Sėkmės garantijos: lankytojas yra įgaliotas.
Pagrindinis scenarijus:
- Klientas inicijuoja autorizaciją.
- Sistema patvirtina, kad klientas nėra įgaliotas ir neviršija nesėkmingų autorizavimo bandymų per tam tikrą seansą (ieškant kelių paskyrų silpno slaptažodžio) skaičiaus pagal „Saugos taisyklę Nr. 23“.
- Sistema padidina autorizavimo bandymų skaičiaus skaitiklį.
- Sistema klientui parodo autorizacijos formą.
- Klientas įveda savo el. pašto adresą ir slaptažodį.
- Sistema patvirtina, kad sistemoje yra klientas, turintis tokį el. pašto adresą ir kad slaptažodis sutampa bei bandymų prisijungti prie šios paskyros skaičius nėra viršytas pagal „Saugos taisyklę Nr. 24“.
- Sistema autorizuoja klientą, prideda naršymo istoriją ir šios sesijos krepšelį su paskutine šios kliento paskyros sesija.
- Sistema parodo sėkmingą autorizavimo pranešimą ir pereina prie scenarijaus veiksmo, nuo kurio klientas buvo nutrauktas autorizacijai gauti. Tokiu atveju puslapyje esantys duomenys įkeliami iš naujo, atsižvelgiant į asmeninės paskyros duomenis.
Plėtiniai:
2.a. Klientas jau įgaliotas:
2.a.1. Sistema praneša klientui apie anksčiau atlikto autorizavimo faktą ir siūlo arba nutraukti scenarijų, arba pereiti prie 4 žingsnio, o jei 6 veiksmas sėkmingai baigtas, 7 veiksmas atliekamas su patikslinimu:
2.a.7. Sistema deaktyvuoja klientą pagal seną paskyrą, įgalioja klientą pagal naują paskyrą, o šios sąveikos seanso naršymo istorija ir krepšelis lieka senojoje paskyroje ir neperkeliami į naują. Tada pereikite prie 8 veiksmo.
2.b Autorizacijos bandymų skaičius viršijo slenkstį pagal „Saugos taisyklę Nr. 23“:
2.b.1 Eikite į 4 veiksmą, leidimo formoje papildomai rodoma captcha
2.b.6 Sistema patvirtina teisingą captcha įvedimą
2.b.6.1 „Captcha“ įvesta neteisingai:
2.b.6.1.1. sistema padidina ir šios paskyros nesėkmingų autorizavimo bandymų skaičių
2.b.6.1.2. sistema parodo gedimo pranešimą ir grįžta į 2 veiksmą
6.a. Nerasta jokia paskyra su šiuo el. pašto adresu:
6.a.1 Sistema parodo pranešimą apie gedimą ir siūlo pasirinkti arba pereiti prie 2 veiksmo, arba pereiti prie „Vartotojo registracijos“ scenarijaus ir išsaugoti įvestą el.
6.b. Paskyros su šiuo el. paštu slaptažodis neatitinka įvesto:
6.b.1 Sistema padidina nesėkmingų bandymų prisijungti prie šios paskyros skaitiklį.
6.b.2 Sistema parodo pranešimą apie gedimą ir siūlo pasirinkti, ar pereiti prie „Slaptažodžio atkūrimo“ scenarijaus arba pereiti prie 2 veiksmo.
6.c: šios paskyros prisijungimo bandymų skaitiklis viršijo „Saugos taisyklės Nr. 24“ slenkstį.
6.c.1 Sistema X minutes rodo pranešimą apie prisijungimo prie paskyros blokavimą ir pereina prie 2 veiksmo.
Kas puiku
Tikrinama, ar jie yra išsamūs ir ar laikomasi tikslų, tai yra, galite pateikti reikalavimus kitam analitikui patikrinti, taip padarydami mažiau klaidų problemos formulavimo etape.
Darbas su juodosios dėžės sistema leidžia atskirti kūrimą ir derinimą su klientu to, kas bus automatizuota, nuo įgyvendinimo metodų.
Tai yra analitiko kelio dalis, viena pagrindinių naudojimo patogumo dalių. Vartotojo scenarijus nusako pagrindinius jo judėjimo kelius, o tai labai sumažina dizainerio ir užsakovo pasirinkimo laisvę bei padeda padidinti dizaino kūrimo greitį.
Labai džiaugiuosi ta vieta aprašyme, kurioje nurodytos kiekvieno sąveikos žingsnio išimtys. Visa IT sistema turi numatyti tam tikrą išimčių tvarkymą, kai kurias rankiniu būdu, kai kurias automatiškai (kaip aukščiau pateiktame pavyzdyje).
Patirtis rodo, kad neapgalvotas išimčių tvarkymas gali lengvai paversti sistemą siaubingai nepatogia sistema. Prisimenu istoriją, kai sovietmečiu, norint priimti sprendimą, reikėjo gauti kelis patvirtinimus iš skirtingų tarnybų, ir kaip skaudu, kai paskutinėje tarnyboje sakoma - bet tavo prašymas neteisingu pavadinimu ar kita klaida skyrybos ženklus, viską perdaryti ir viską iš naujo suderinti.
Dažnai susiduriu su situacijomis, kai dėl neapgalvotos išimčių sistemos veikimo logikos reikėjo gerokai pertvarkyti sistemą. Dėl šios priežasties liūto dalis analitiko darbo išleidžiama išimčių tvarkymui.
Teksto žymėjimas, priešingai nei diagramos, leidžia nustatyti ir aprėpti daugiau išimčių.
Metodo papildymas iš praktikos
Naudojimo atvejis nėra atskirai prioritetinė teiginio dalis, skirtingai nei vartotojo istorija.
Pirmiau pateiktame scenarijuje apsvarstykite išimtį „6.a. Nerasta jokia paskyra su šiuo el. paštu. ir kitą veiksmą „6.a.1 Sistema parodo gedimo pranešimą ir pereina prie 2 veiksmo“. Kokie neigiami dalykai liko už kadro? Klientui bet kokia grąža prilygsta tam, kad visas darbas, kurį jis atliko įvesdamas duomenis, išmetamas į sąvartyną. (Tai tiesiog nematoma scenarijuje!) Ką galima padaryti? Perkurkite scenarijų, kad taip nenutiktų. Ar įmanoma tai padaryti? Kaip pavyzdį galite pažvelgti į „Google“ autorizacijos scenarijų.
Scenarijaus optimizavimas
Knygoje kalbama apie formalizavimą, tačiau mažai kalbama apie tokių scenarijų optimizavimo metodus.
Tačiau metodą galima sustiprinti optimizuojant scenarijus, o naudojimo atvejų formalizavimo metodas leidžia tai padaryti. Tiksliau, turite apgalvoti kiekvieną pasitaikančią išimtį, nustatyti priežastį ir iš naujo sukurti scenarijų, kad pašalintumėte išimtis arba sumažintumėte kliento kelionę.
Pateikdami užsakymą iš internetinės parduotuvės, turite įvesti pristatymo miestą. Gali pasirodyti, kad parduotuvė negali pristatyti prekių į kliento pasirinktą miestą, nes ten nepristato, dėl dydžio apribojimų, arba dėl prekių trūkumo atitinkamame sandėlyje.
Jei tiesiog aprašome sąveikos scenarijų registracijos etape, galime parašyti „informuoti klientą, kad pristatymas neįmanomas ir pasiūlyti pakeisti miestą ar krepšelio turinį“ (ir daugelis pradedančiųjų analitikų sustoja). Bet jei tokių atvejų daug, tuomet scenarijų galima optimizuoti.
Pirmas dalykas, kurį reikia padaryti, tai leisti pasirinkti tik miestą, kuriame galime pristatyti. Kada tai daryti? Prieš pasirenkant produktą svetainėje (automatinis miesto aptikimas per IP su patikslinimu).
Antra, turime duoti pasirinkti tik tas prekes, kurias galime pristatyti klientui. Kada tai daryti? Pasirinkimo momentu - ant prekės plytelės ir prekės kortelės.
Šie du pakeitimai labai padeda panaikinti šią išimtį.
Reikalavimai matavimams ir metrikoms
Svarstydami užduotį sumažinti išimčių tvarkymą, galite nustatyti ataskaitų teikimo užduotį (naudojimo atvejis neaprašytas). Kiek buvo išimčių, kokiais atvejais jos įvyko, be to, kiek gaunamų scenarijų sėkmingai praėjo.
Bet deja. Patirtis parodė, kad šios formos scenarijų ataskaitų teikimo reikalavimų nepakanka; būtina atsižvelgti į ataskaitų teikimo reikalavimus procesams, kurie aprašomi daugiausia ne naudojimo atvejo forma.
Prieiga prie naudojimo galimybių
Savo praktikoje mes išplėtėme naudojimo atvejo aprašymo formą su konkrečių objektų atributų ir duomenų aprašymu, kad klientas galėtų priimti sprendimą, o tai pagerina vėlesnį naudojimą.
Patogumo dizainui pridėjome įvesties skiltį – rodyti duomenis.
Scenarijuje su įgaliojimu tai yra faktas, kad klientas yra įgaliotas sistemoje. Jei klientas yra iš anksto įgaliotas, tada po sėkmingo autorizavimo rodyti įspėjimą apie naršymo istorijos ir krepšelio perjungimą į naują paskyrą.
Apskritai tai yra reikalingos informacijos atvaizdavimas klientui, kad jis pagal scenarijų galėtų apsispręsti dėl savo tolesnių veiksmų (galima paklausti ar klientui šių duomenų pakanka, ko dar reikia, kokia informacija klientas turi priimti sprendimus).
Taip pat verta suskirstyti įvestą informaciją į įvesties laukus, jei jie apdorojami atskirai ir formuojant skirtingas išimtis.
Kliento autorizavimo pavyzdyje, jei įvestą informaciją atskiriate į prisijungimo vardą ir slaptažodį, tuomet verta pakeisti autorizavimo scenarijų, kad būtų paryškinti atskiro prisijungimo vardo ir atskiro slaptažodžio įvedimo etapai (ir tai daroma „Yandex“, „Google“, bet nedaroma daugumoje internetinių parduotuvių).
Reikiamų duomenų transformacijų pasiekimas
Taip pat iš scenarijaus galite išskirti reikalavimus duomenų konvertavimo algoritmams.
Pavyzdžiai:
- Klientas, norėdamas apsispręsti pirkti prekę internetinėje parduotuvėje, turi prekės kortelėje žinoti šios prekės galimybę, kainą, pristatymo į jo miestą laiką (kurie apskaičiuojami pagal algoritmą pagal prekės prieinamumą šalyje). sandėliai ir tiekimo grandinės parametrai).
- Įvedus frazę į paieškos eilutę, klientui pagal algoritmą rodomi paieškos pasiūlymai (kurie generuojami algoritmo...).
Iš viso
Apskritai perskaičius knygą, deja, neaišku, kaip nueiti visą kelią nuo analitiko iki verslo problemų iki formalizuotos techninės specifikacijos kūrėjui. Knygoje pasakojama tik dalis proceso, o įvesties žingsniai neaiškūs, o kiti – neaiškūs. Pats naudojimo atvejis dažniausiai nėra išsamus kūrėjo teiginys.
Nepaisant to, tai labai geras būdas formalizuoti ir apdoroti objekto ir subjekto sąveikos scenarijus, kai dėl sąveikos kažkas pasikeičia subjekte. Tai vienas iš nedaugelio rašymo būdų, leidžiančių patikrinti reikalavimus su aiškiais išimčių paieškos taškais.
Knygą privalo perskaityti analitikai, norintys pradėti rašyti patikrinamas pjeses.
Šaltinis: www.habr.com