El llibre descriu un mètode per escriure part d'una declaració de problema, és a dir, el mètode de casos d'ús.
Què és això? Aquesta és una descripció de l'escenari d'interacció de l'usuari amb el sistema (o amb l'empresa). En aquest cas, el sistema actua com una caixa negra (i això fa possible dividir la tasca de disseny complexa en dissenyar la interacció i garantir aquesta interacció). Al mateix temps, s'introdueixen estàndards de notació, que garanteixen la facilitat de lectura, fins i tot per als no participants, i permeten algunes comprovacions de la integritat i el compliment dels objectius de la part interessada.
Exemple de cas d'ús
Com es veu l'escenari, utilitzant l'exemple d'autorització al lloc per correu electrònic:
(Sistema) Inicieu sessió al lloc web per accedir al vostre compte personal. ~~ (nivell del mar)
Context: Un client no autoritzat inicia sessió al lloc perquè el lloc el reconegui i mostri informació personal sobre ell: historial de navegació, historial de compres, nombre actual de punts de bonificació, etc., utilitzant el correu electrònic com a inici de sessió.
Nivell: objectiu de l'usuari
Personatge principal: client (visitant de la nostra botiga en línia)
Àmbit: Interacció del client amb el lloc web de la botiga en línia
Actors i interessos:
- el venedor vol que s'identifiqui el nombre màxim de visitants del lloc per a una major cobertura dels enviaments personals,
- l'especialista en seguretat vol assegurar-se que no hi ha casos d'accés no autoritzat a les dades personals del visitant, inclosos els intents d'endevinar la contrasenya d'un compte o cercar un compte amb una contrasenya feble,
- l'atacant vol accedir a les bonificacions de la víctima,
- els competidors volen deixar ressenyes negatives sobre els productes,
- La botnet vol obtenir la base de clients de la botiga i utilitzar un atac per fer el lloc inoperable.
Condicions prèvies: el visitant no ha d'estar autoritzat.
Garanties mínimes: el visitant sabrà si l'intent d'autorització va tenir èxit o no.
Garanties d'èxit: el visitant està autoritzat.
Escenari principal:
- El client inicia l'autorització.
- El sistema confirma que el client no està autoritzat i no supera el nombre d'intents d'autorització fallits d'una sessió determinada (cerca d'una contrasenya feble per a diversos comptes) segons la "Regla de seguretat núm. 23".
- El sistema augmenta el comptador del nombre d'intents d'autorització.
- El sistema mostra un formulari d'autorització al client.
- El client introdueix el seu correu electrònic i contrasenya.
- El sistema confirma la presència d'un client amb aquest correu electrònic al sistema i que la contrasenya coincideix i que el nombre d'intents d'inici de sessió a aquest compte no s'excedeix d'acord amb la "Regla de seguretat núm. 24".
- El sistema autoritza el client, afegeix l'historial de navegació i la cistella d'aquesta sessió amb l'última sessió d'aquest compte de client.
- El sistema mostra un missatge d'autorització correcta i passa al pas de guió des del qual s'ha interromput el client per obtenir l'autorització. En aquest cas, les dades de la pàgina es recarreguen tenint en compte les dades del compte personal.
Extensions:
2.a. El client ja està autoritzat:
2.a.1. El sistema notifica al client el fet de l'autorització prèviament realitzada i ofereix interrompre l'script o passar al pas 4, i si el pas 6 es completa amb èxit, el pas 7 es realitza amb un aclariment:
2.a.7. El sistema desactoritza el client amb el compte antic, autoritza el client amb el compte nou, mentre que l'historial de navegació i el carretó d'aquesta sessió d'interacció romanen al compte antic i no es transfereixen al nou. A continuació, aneu al pas 8.
2.b El nombre d'intents d'autorització ha superat el llindar d'acord amb la “Regla de seguretat núm. 23”:
2.b.1 Aneu al pas 4, també es mostra un captcha al formulari d'autorització
2.b.6 El sistema confirma l'entrada correcta del captcha
2.b.6.1 Captcha introduït incorrectament:
2.b.6.1.1. el sistema també augmenta el comptador d'intents d'autorització infructuosos per a aquest compte
2.b.6.1.2. el sistema mostra un missatge d'error i torna al pas 2
6.a. No s'ha trobat cap compte amb aquest correu electrònic:
6.a.1 El sistema mostra un missatge d'error i ofereix l'opció d'anar al pas 2 o anar a l'escenari "Registre d'usuari" i desar el correu electrònic introduït.
6.b. La contrasenya del compte amb aquest correu electrònic no coincideix amb la introduïda:
6.b.1 El sistema augmenta el comptador d'intents d'inici de sessió infructuosos a aquest compte.
6.b.2 El sistema mostra un missatge sobre la fallada i ofereix l'opció d'anar a l'escenari "Recuperació de la contrasenya" o anar al pas 2.
6.c: el comptador d'intents d'inici de sessió d'aquest compte ha superat el llindar de la "Regla de seguretat núm. 24".
6.c.1 El sistema mostra un missatge sobre el bloqueig de l'inici de sessió del compte durant X minuts i passa al pas 2.
Què genial
Comprova la integritat i el compliment dels objectius, és a dir, podeu donar requisits a un altre analista per a la verificació, fent menys errors en l'etapa de formulació del problema.
Treballar amb un sistema de caixa negra permet separar el desenvolupament i la coordinació amb el client del que s'automatitzarà dels mètodes d'implementació.
Forma part del camí de l'analista, una de les parts principals de la usabilitat. L'escenari de l'usuari defineix els camins principals del seu moviment, la qual cosa redueix molt la llibertat d'elecció del dissenyador i el client i ajuda a augmentar la velocitat de desenvolupament del disseny.
Estic molt satisfet amb el lloc de la descripció on s'identifiquen les excepcions a cada pas d'interacció. Un sistema informàtic complet ha de preveure algun tipus de gestió d'excepcions, algunes manualment, altres automàticament (com a l'exemple anterior).
L'experiència demostra que un maneig d'excepcions mal pensat pot convertir fàcilment un sistema en un sistema terriblement incòmode. Recordo la història quan a l'època soviètica, per prendre una decisió, vau haver d'obtenir diverses aprovacions de diferents serveis, i el dolorós que és quan diu l'últim servei, però la vostra sol·licitud té un nom incorrecte o algun altre error en puntuació, refer-ho tot i tornar-ho a coordinar.
Sovint em trobo amb situacions en què la lògica de funcionament d'un sistema que no estava pensat per a excepcions requeria una reelaboració important del sistema. Per això, la major part del treball de l'analista es gasta en el tractament d'excepcions.
La notació de text, a diferència dels diagrames, permet identificar i cobrir més excepcions.
Addició al mètode des de la pràctica
El cas d'ús no és una part de la declaració amb prioritat independent, a diferència de la història d'usuari.
En l'escenari anterior, considereu l'excepció "6.a. No s'ha trobat cap compte amb aquest correu electrònic." i el següent pas "6.a.1 El sistema mostra un missatge d'error i passa al pas 2". Quines coses negatives van quedar darrere de les escenes? Per al client, qualsevol devolució equival al fet que tota la feina que va fer introduint dades es llença a un abocador. (Simplement no és visible al guió!) Què es pot fer? Reconstruïu l'script perquè això no passi. És possible fer això? Podeu consultar, com a exemple, l'script d'autorització de Google.
Optimització d'escenaris
El llibre parla de la formalització, però diu poc sobre els mètodes per optimitzar aquests escenaris.
Però és possible reforçar el mètode optimitzant escenaris, i el mètode de formalització de casos d'ús permet fer-ho. Concretament, heu de pensar en cada excepció que es produeix, determinar la causa i reconstruir l'script per desfer-se de l'excepció o minimitzar el recorregut del client.
Quan feu una comanda des d'una botiga en línia, heu d'introduir la ciutat de lliurament. Pot resultar que la botiga no pugui lliurar mercaderies a la ciutat escollida pel client perquè no hi lliura, per restriccions de mida, o per manca de mercaderies al magatzem corresponent.
Si descrivim simplement l'escenari d'interacció en l'etapa de registre, podem escriure "informar el client que el lliurament és impossible i oferir-nos canviar la ciutat o el contingut del carretó" (i molts analistes novells s'aturen aquí). Però si hi ha molts d'aquests casos, l'escenari es pot optimitzar.
El primer que has de fer és deixar-te triar només la ciutat on podem lliurar. Quan fer això? Abans de seleccionar un producte a la web (autodetecció de la ciutat via IP amb aclariment).
En segon lloc, hem de triar només els béns que podem lliurar al client. Quan fer això? En el moment de la selecció: a la fitxa del producte i la targeta del producte.
Aquests dos canvis contribueixen molt a eliminar aquesta excepció.
Requisits per a mesures i mètriques
Quan considereu la tasca de minimitzar el maneig d'excepcions, podeu establir una tasca d'informes (no es descriu el cas d'ús). Quantes excepcions hi va haver, en quins casos es van produir, més quants escenaris entrants van passar amb èxit.
Però ai. L'experiència ha demostrat que els requisits d'informes per als escenaris en aquest formulari no són suficients; cal tenir en compte els requisits d'informes per als processos que es descriuen principalment no en forma de cas d'ús.
Accés a la usabilitat
A la nostra pràctica, hem ampliat el formulari de descripció de casos d'ús amb una descripció d'atributs específics d'entitats i dades perquè el client prengui una decisió, la qual cosa millora la usabilitat posterior.
Per al disseny d'usabilitat, hem afegit una secció d'entrada: mostrar dades.
En un escenari amb autorització, aquest és el fet que el client està autoritzat al sistema. Si el client està preautoritzat, mostreu un advertiment sobre com canviar l'historial de navegació i el carretó al compte nou després de l'autorització correcta.
En general, es tracta d'una visualització de la informació necessària per al client perquè pugui prendre una decisió sobre les seves accions posteriors segons l'escenari (es pot preguntar si aquestes dades són suficients per al client, què més es necessita, quina informació fa? el client ha de prendre decisions).
També val la pena dividir la informació introduïda en camps d'entrada si es processen per separat i amb la formació de diferents excepcions.
A l'exemple amb autorització del client, si separeu la informació introduïda en inici de sessió i contrasenya, val la pena canviar l'script d'autorització per destacar les etapes d'introduir un inici de sessió i una contrasenya independents (i això es fa a Yandex, Google, però no es fa a la majoria de botigues en línia).
Assolir les transformacions de dades necessàries
També podeu extreure requisits per als algorismes de conversió de dades de l'script.
Exemples:
- Per prendre la decisió d'adquirir un producte en una botiga en línia, el client ha de conèixer a la targeta del producte la possibilitat, el cost, el termini de lliurament a la seva ciutat d'aquest producte (que es calculen per l'algorisme en funció de la disponibilitat del producte en magatzems i paràmetres de la cadena de subministrament).
- En introduir una frase a la línia de cerca, al client se li mostren suggeriments de cerca segons l'algorisme (que són generats per l'algorisme...).
En total
En general, després de llegir el llibre, malauradament, no està clar com passar des d'un analista fins a problemes empresarials fins a una especificació tècnica formalitzada per a un desenvolupador. El llibre només explica una part del procés, amb els passos d'entrada poc clars i els passos següents poc clars. El cas d'ús en si mateix sovint no és una declaració completa per al desenvolupador.
No obstant això, aquesta és una molt bona manera de formalitzar i processar escenaris d'interacció entre un objecte i un subjecte, quan la interacció provoca un canvi en alguna cosa en el subjecte. És un dels pocs mètodes d'escriptura que permet requisits verificables amb punts de cerca d'excepcions explícits.
El llibre és una lectura obligada perquè els analistes comencin a escriure obres de teatre comprovables.
Font: www.habr.com