Cartea descrie o metodă de scriere a unei părți a unei declarații de problemă, și anume metoda cazului de utilizare.
Ce este? Aceasta este o descriere a scenariului de interacțiune a utilizatorului cu sistemul (sau cu afacerea). În acest caz, sistemul acționează ca o cutie neagră (și acest lucru face posibilă împărțirea sarcinii complexe de proiectare în proiectarea interacțiunii și asigurarea acestei interacțiuni). În același timp, sunt introduse standarde de notație, care asigură ușurința de citire, inclusiv pentru neparticipanți, și permite unele verificări pentru exhaustivitatea și conformitatea cu obiectivele părții interesate.
Exemplu de caz de utilizare
Cum arată scenariul, folosind exemplul de autorizare pe site prin e-mail:
(Sistem) Conectați-vă la site-ul web pentru a vă accesa contul personal. ~~ (nivelul mării)
Context: Un client neautorizat se conectează pe site astfel încât site-ul să-l recunoască și să arate informații personale pentru el: istoric de navigare, istoric de achiziții, numărul curent de puncte bonus etc., folosind e-mailul ca logare.
nivel: scopul utilizatorului
Personaj principal: client (vizitator al magazinului nostru online)
Domeniu de aplicare: Interacțiunea clientului cu site-ul magazinului online
Părți interesate și interese:
- agentul de marketing dorește să fie identificat numărul maxim de vizitatori ai site-ului pentru o acoperire mai mare a e-mailurilor personale,
- specialistul în securitate dorește să se asigure că nu există cazuri de acces neautorizat la datele personale ale vizitatorului, inclusiv încercări de a ghici parola pentru un cont sau de a căuta un cont cu o parolă slabă,
- atacatorul dorește să obțină acces la bonusurile victimei,
- concurenții doresc să lase recenzii negative asupra produselor,
- Rețeaua bot dorește să obțină baza de clienți a magazinului și să folosească un atac pentru a face site-ul inoperabil.
Conditii preliminare: vizitatorul nu trebuie să fie autorizat.
Garantii minime: vizitatorul va ști dacă încercarea de autorizare a fost reușită sau nereușită.
Garanții de succes: vizitatorul este autorizat.
Scenariul principal:
- Clientul inițiază autorizarea.
- Sistemul confirmă că clientul nu este autorizat și nu depășește numărul de încercări de autorizare nereușite dintr-o anumită sesiune (căutarea unei parole slabe pentru mai multe conturi) conform „Regula de securitate nr. 23”.
- Sistemul mărește contorul pentru numărul de încercări de autorizare.
- Sistemul afișează clientului un formular de autorizare.
- Clientul își introduce adresa de e-mail și parola.
- Sistemul confirmă prezența unui client cu un astfel de e-mail în sistem și că parola se potrivește și numărul de încercări de conectare la acest cont nu este depășit conform „Regula de securitate nr. 24”.
- Sistemul autorizează clientul, adaugă istoricul de navigare și coșul acestei sesiuni cu ultima sesiune a acestui cont de client.
- Sistemul afișează un mesaj de autorizare de succes și trece la pasul de script de la care clientul a fost întrerupt pentru autorizare. În acest caz, datele de pe pagină sunt reîncărcate ținând cont de datele contului personal.
Extensii:
2.a. Clientul este deja autorizat:
2.a.1. Sistemul anunță clientul cu privire la autorizarea efectuată anterior și oferă fie să întrerupă scriptul, fie să treacă la pasul 4, iar dacă pasul 6 este finalizat cu succes, atunci pasul 7 este efectuat cu clarificare:
2.a.7. Sistemul dezactorizează clientul sub vechiul cont, autorizează clientul sub noul cont, în timp ce istoricul de navigare și coșul acestei sesiuni de interacțiune rămân în vechiul cont și nu se transferă în cel nou. Apoi, treceți la pasul 8.
2.b Numărul de încercări de autorizare a depășit pragul conform „Regula de securitate nr. 23”:
2.b.1 Treceți la pasul 4, un captcha este afișat suplimentar pe formularul de autorizare
2.b.6 Sistemul confirmă introducerea corectă a captcha
2.b.6.1 Captcha introdus incorect:
2.b.6.1.1. sistemul mărește contorul încercărilor de autorizare nereușite și pentru acest cont
2.b.6.1.2. sistemul afișează un mesaj de eroare și revine la pasul 2
6.a. Nu a fost găsit niciun cont cu acest e-mail:
6.a.1 Sistemul afișează un mesaj despre eșec și oferă posibilitatea de a merge la pasul 2 sau de a merge la scenariul „Înregistrare utilizator” și de a salva e-mailul introdus,
6.b. Parola pentru contul cu acest e-mail nu se potrivește cu cea introdusă:
6.b.1 Sistemul mărește contorul încercărilor de conectare nereușite la acest cont.
6.b.2 Sistemul afișează un mesaj despre eșec și oferă opțiunea de a merge la scenariul „Recuperare parolă” sau de a merge la pasul 2.
6.c: Contorul de încercări de conectare pentru acest cont a depășit pragul pentru „Regula de securitate nr. 24”.
6.c.1 Sistemul afișează un mesaj despre blocarea contului de conectare timp de X minute și trece la pasul 2.
Ce e grozav
Verifică completitatea și conformitatea cu obiectivele, adică puteți da cerințe unui alt analist pentru verificare, făcând mai puține greșeli în etapa formulării problemei.
Lucrul cu un sistem cutie neagră vă permite să separați dezvoltarea și coordonarea cu clientul a ceea ce va fi automatizat de metodele de implementare.
Face parte din calea analistului, una dintre principalele părți ale utilizabilității. Scenariul utilizatorului definește principalele căi ale mișcării sale, ceea ce reduce foarte mult libertatea de alegere a designerului și a clientului și ajută la creșterea vitezei de dezvoltare a designului.
Sunt foarte mulțumit de locul din descriere în care sunt identificate excepții de la fiecare pas de interacțiune. Un sistem IT complet trebuie să prevadă un fel de tratare a excepțiilor, unele manual, altele automat (ca în exemplul de mai sus).
Experiența arată că gestionarea greșită a excepțiilor poate transforma cu ușurință un sistem într-un sistem teribil de incomod. Îmi amintesc povestea când în vremea sovietică, pentru a lua o decizie, trebuia să obții mai multe aprobări de la diferite servicii și cât de dureros este când ultimul serviciu spune - dar cererea ta are un nume greșit sau o altă greșeală în punctuația, reface totul și re-coordonează totul.
Întâlnesc adesea situații în care logica de funcționare a unui sistem care nu a fost gândit pentru excepții necesita o reelaborare semnificativă a sistemului. Din acest motiv, partea leului din munca analistului este cheltuită pentru gestionarea excepțiilor.
Notarea textului, spre deosebire de diagrame, permite identificarea și acoperirea mai multor excepții.
Adăugarea metodei din practică
Cazul de utilizare nu este o parte a declarației cu prioritate independentă, spre deosebire de povestea utilizatorului.
În scenariul de mai sus, luați în considerare excepția „6.a. Nu a fost găsit niciun cont cu acest e-mail.” și următorul pas „6.a.1 Sistemul afișează un mesaj de eroare și trece la pasul 2.” Ce lucruri negative au rămas în culise? Pentru client, orice returnare echivalează cu faptul că toată munca pe care a făcut-o introducând date este aruncată într-o groapă de gunoi. (Nu este vizibil în scenariu!) Ce se poate face? Reconstruiți scriptul pentru ca acest lucru să nu se întâmple. Este posibil să faci asta? Puteți - de exemplu, să vă uitați la scriptul de autorizare Google.
Optimizarea scenariilor
Cartea vorbește despre formalizare, dar spune puțin despre metodele de optimizare a unor astfel de scenarii.
Dar este posibilă consolidarea metodei prin optimizarea scenariilor, iar metoda de formalizare a cazurilor de utilizare permite acest lucru. Mai exact, trebuie să vă gândiți la fiecare excepție care apare, să determinați cauza și să reconstruiți scriptul astfel încât să scăpați de excepție sau să minimizați călătoria clientului.
Când plasați o comandă dintr-un magazin online, trebuie să introduceți orașul de livrare. Se poate dovedi ca magazinul sa nu poata livra marfa in orasul ales de client pentru ca nu livreaza acolo, din cauza restrictiilor de dimensiune, sau din lipsa de marfa in depozitul corespunzator.
Dacă pur și simplu descriem scenariul de interacțiune în etapa de înregistrare, putem scrie „informați clientul că livrarea este imposibilă și oferiți să schimbați orașul sau conținutul căruciorului” (și mulți analiști începători se opresc aici). Dar dacă există o mulțime de astfel de cazuri, atunci scenariul poate fi optimizat.
Primul lucru pe care trebuie să-l faci este să te lași să alegi doar orașul în care putem livra. Când să faci asta? Înainte de a selecta un produs pe site (autodetecția orașului prin IP cu clarificare).
În al doilea rând, trebuie să dăm de ales doar mărfurile pe care le putem livra clientului. Când să faci asta? În momentul selecției - pe placa de produs și cardul produsului.
Aceste două modificări merg în mare măsură spre eliminarea acestei excepții.
Cerințe pentru măsurători și metrici
Când luați în considerare sarcina de minimizare a gestionării excepțiilor, puteți seta o sarcină de raportare (cazul de utilizare nu este descris). Câte excepții au existat, în ce cazuri au apărut, plus câte scenarii primite au trecut cu succes.
Dar vai! Experiența a arătat că cerințele de raportare pentru scenariile în această formă nu sunt suficiente; este necesar să se ia în considerare cerințele de raportare pentru procesele care sunt descrise în principal nu sub forma unui caz de utilizare.
Acces la Utilizabilitate
În practica noastră, am extins formularul de descriere a cazurilor de utilizare cu o descriere a atributelor specifice ale entităților și a datelor pentru ca clientul să ia o decizie, ceea ce îmbunătățește utilizarea ulterioară.
Pentru designul de utilizare, am adăugat o secțiune de intrare - afișare date.
Într-un scenariu cu autorizare, acesta este faptul că clientul este autorizat în sistem. Dacă clientul este preautorizat, atunci afișați un avertisment despre trecerea istoricului de navigare și a coșului la noul cont după autorizarea cu succes.
În general, aceasta este o afișare a informațiilor necesare pentru client, astfel încât acesta să poată lua o decizie cu privire la acțiunile sale ulterioare în funcție de scenariu (puteți întreba dacă aceste date sunt suficiente pentru client, ce mai este nevoie, ce informații fac nevoia clientului de a lua decizii).
De asemenea, merită împărțirea informațiilor introduse în câmpuri de intrare dacă acestea sunt procesate separat și cu formarea de diferite excepții.
În exemplul cu autorizarea clientului, dacă separați informațiile introduse în autentificare și parolă, atunci merită să schimbați scriptul de autorizare pentru a evidenția etapele de introducere a unui login separat și a unei parole separate (și acest lucru se face în Yandex, Google, dar nu se face în majoritatea magazinelor online).
Atingerea transformărilor de date necesare
De asemenea, puteți extrage cerințele pentru algoritmii de conversie a datelor din script.
Exemple:
- Pentru a lua decizia de a achiziționa un produs dintr-un magazin online, clientul trebuie să cunoască pe cardul produsului posibilitatea, costul, timpul de livrare în orașul său a acestui produs (care sunt calculate de algoritm pe baza disponibilității produsului în depozite și parametrii lanțului de aprovizionare).
- La introducerea unei fraze în linia de căutare, clientului i se arată sugestii de căutare conform algoritmului (care sunt generate de algoritm...).
În total
În general, după ce ai citit cartea, din păcate, nu este clar cum să mergi de la un analist la probleme de afaceri la o specificație tehnică oficializată pentru un dezvoltator. Cartea spune doar o parte a procesului, cu pașii de intrare neclari și pașii următori neclari. Cazul de utilizare în sine nu este cel mai adesea o declarație completă pentru dezvoltator.
Cu toate acestea, aceasta este o modalitate foarte bună de a formaliza și procesa scenarii de interacțiune între un obiect și un subiect, atunci când interacțiunea provoacă o schimbare a ceva în subiect. Este una dintre puținele metode de scriere care permite cerințe verificabile cu puncte de căutare explicite cu excepții.
Cartea este o citire obligatorie pentru ca analiștii să înceapă să scrie piese testabile.
Sursa: www.habr.com