Il libro descrive un metodo per scrivere parte di una dichiarazione di problema, vale a dire il metodo dei casi d'uso.
Cos'è? Questa è una descrizione dello scenario di interazione dell'utente con il sistema (o con l'azienda). In questo caso, il sistema agisce come una scatola nera (e ciò rende possibile dividere il complesso compito di progettazione in progettare l'interazione e garantire tale interazione). Allo stesso tempo, vengono introdotti standard di notazione, che garantiscono facilità di lettura, anche per i non partecipanti, e consentono alcuni controlli di completezza e rispetto degli obiettivi dello stakeholder.
Esempio di caso d'uso
Ecco come appare lo scenario, utilizzando l'esempio dell'autorizzazione su un sito tramite e-mail:
(Sistema) Accedi al sito web per accedere al tuo account personale. ~~ (livello del mare)
Contesto: Un cliente non autorizzato accede al sito in modo che il sito lo riconosca e gli mostri informazioni personali: cronologia di navigazione, cronologia degli acquisti, numero attuale di punti bonus, ecc., utilizzando l'e-mail come login.
livello: obiettivo dell'utente
Personaggio principale: cliente (visitatore del nostro negozio online)
Scopo: Interazione del cliente con il sito web del negozio online
Stakeholder e interessi:
- il marketer desidera che venga identificato il numero massimo di visitatori del sito per una maggiore copertura degli invii personali,
- lo specialista della sicurezza vuole garantire che non si verifichino casi di accesso non autorizzato ai dati personali del visitatore, inclusi tentativi di indovinare la password di un account o di cercare un account con una password debole,
- l’aggressore vuole avere accesso ai bonus della vittima,
- i concorrenti vogliono lasciare recensioni negative sui prodotti,
- La botnet vuole impossessarsi della base clienti del negozio e utilizzare un attacco per rendere inutilizzabile il sito.
Precondizioni: il visitatore non deve essere autorizzato.
Garanzie minime: il visitatore saprà se il tentativo di autorizzazione è andato a buon fine o meno.
Garanzie di successo: il visitatore è autorizzato.
Scenario principale:
- Il client avvia l'autorizzazione.
- Il sistema conferma che il client non è autorizzato e non supera il numero di tentativi di autorizzazione non riusciti da una determinata sessione (ricerca di una password debole per più account) secondo la “Regola di sicurezza n. 23”.
- Il sistema incrementa il contatore del numero di tentativi di autorizzazione.
- Il sistema visualizza un modulo di autorizzazione al cliente.
- Il cliente inserisce la sua email e la password.
- Il sistema conferma la presenza di un cliente con tale e-mail nel sistema e che la password corrisponde e il numero di tentativi di accesso a questo account non viene superato secondo la "Regola di sicurezza n. 24".
- Il sistema autorizza il cliente, aggiunge la cronologia di navigazione e il carrello di questa sessione con l'ultima sessione di questo account cliente.
- Il sistema visualizza un messaggio di autorizzazione riuscita e passa all'istruzione di script dalla quale il client è stato interrotto per l'autorizzazione. In questo caso, i dati sulla pagina vengono ricaricati tenendo conto dei dati dell'account personale.
Estensioni:
2.a. Il cliente è già autorizzato:
2.a.1. Il sistema notifica al cliente l'autorizzazione precedentemente eseguita e offre di interrompere lo script o di passare al passaggio 4 e, se il passaggio 6 viene completato con successo, il passaggio 7 viene eseguito con chiarimenti:
2.a.7. Il sistema disattiva il cliente con il vecchio account, autorizza il cliente con il nuovo account, mentre la cronologia di navigazione e il carrello di questa sessione di interazione rimangono nel vecchio account e non vengono trasferiti a quello nuovo. Successivamente, vai al passaggio 8.
2.b Il numero di tentativi di autorizzazione ha superato la soglia prevista dalla “Regola di Sicurezza N°23”:
2.b.1 Andare al passaggio 4, sul modulo di autorizzazione verrà inoltre visualizzato un captcha
2.b.6 Il sistema conferma il corretto inserimento del captcha
2.b.6.1 Captcha inserito in modo errato:
2.b.6.1.1. anche per questo account il sistema incrementa il contatore dei tentativi di autorizzazione falliti
2.b.6.1.2. il sistema visualizza un messaggio di errore e torna al passaggio 2
6.a. Non è stato trovato alcun account con questa email:
6.a.1 Il sistema visualizza un messaggio di errore e offre la possibilità di scegliere se andare al passaggio 2 o andare allo scenario "Registrazione utente" e salvare l'e-mail inserita,
6.b. La password dell'account con questa email non corrisponde a quella inserita:
6.b.1 Il sistema incrementa il contatore dei tentativi di accesso non riusciti a questo account.
6.b.2 Il sistema visualizza un messaggio di errore e offre la possibilità di passare allo scenario "Recupero password" o al passaggio 2.
6.c: Il contatore dei tentativi di accesso per questo account ha superato la soglia della "Regola di sicurezza n. 24".
6.c.1 Il sistema visualizza un messaggio relativo al blocco dell'accesso all'account per X minuti e procede al passaggio 2.
Ciò che è fantastico
Controlla la completezza e il rispetto degli obiettivi, ovvero puoi fornire i requisiti a un altro analista per la verifica, commettendo meno errori nella fase di formulazione del problema.
Lavorare con un sistema a scatola nera permette di separare lo sviluppo e il coordinamento con il cliente di ciò che verrà automatizzato dalle modalità di implementazione.
Fa parte del percorso dell'analista, una delle parti principali dell'usabilità. Lo scenario dell'utente definisce i percorsi principali del suo movimento, il che riduce notevolmente la libertà di scelta del progettista e del cliente e aiuta ad aumentare la velocità di sviluppo del progetto.
Sono molto soddisfatto del punto nella descrizione in cui vengono identificate le eccezioni a ciascuna fase di interazione. Un sistema IT completo deve prevedere una sorta di gestione delle eccezioni, alcune manualmente, altre automaticamente (come nell'esempio sopra).
L'esperienza dimostra che una gestione delle eccezioni sconsiderata può facilmente trasformare un sistema in un sistema terribilmente scomodo. Ricordo la storia in cui in epoca sovietica, per prendere una decisione, dovevi ottenere diverse approvazioni da diversi servizi, e quanto è doloroso quando l'ultimo servizio dice - ma la tua domanda ha il nome sbagliato o qualche altro errore punteggiatura, rifare tutto e ri-coordinare tutto.
Mi imbatto spesso in situazioni in cui la logica di funzionamento di un sistema che non è stato pensato per le eccezioni richiedeva una rielaborazione significativa del sistema. Per questo motivo, la maggior parte del lavoro dell'analista viene spesa nella gestione delle eccezioni.
La notazione del testo, a differenza dei diagrammi, consente di identificare e coprire più eccezioni.
Aggiunta al metodo dalla pratica
Il caso d'uso non è una parte della dichiarazione a cui viene assegnata una priorità indipendente, a differenza della user story.
Nello scenario sopra, considerare l'eccezione “6.a. Non è stato trovato alcun account con questa email." e il passaggio successivo “6.a.1 Il sistema visualizza un messaggio di errore e procede al passaggio 2.” Quali cose negative sono rimaste dietro le quinte? Per il cliente, qualsiasi rendimento equivale al fatto che tutto il lavoro svolto per l'inserimento dei dati viene gettato in una discarica. (Semplicemente non è visibile nella sceneggiatura!) Cosa si può fare? Ricostruisci lo script in modo che ciò non accada. È possibile farlo? Puoi, ad esempio, guardare lo script di autorizzazione di Google.
Ottimizzazione dello scenario
Il libro parla di formalizzazione, ma dice poco sui metodi per ottimizzare tali scenari.
Ma è possibile rafforzare il metodo ottimizzando gli scenari, e il metodo di formalizzazione dei casi d’uso consente di farlo. Nello specifico, è necessario pensare a ogni eccezione che si verifica, determinarne la causa e ricostruire lo script in modo da eliminare l'eccezione o ridurre al minimo il percorso del cliente.
Quando effettui un ordine da un negozio online, devi inserire la città di consegna. Può succedere che il negozio non possa consegnare la merce nella città scelta dal cliente perché non effettua la consegna lì, a causa di limiti di dimensione o per mancanza di merce nel magazzino corrispondente.
Se descriviamo semplicemente lo scenario di interazione in fase di registrazione, possiamo scrivere “informa il cliente che la consegna è impossibile e offri di cambiare la città o il contenuto del carrello” (e molti analisti alle prime armi si fermano qui). Ma se i casi simili sono numerosi, lo scenario può essere ottimizzato.
La prima cosa che devi fare è farti scegliere solo la città in cui possiamo consegnare. Quando farlo? Prima di selezionare un prodotto sul sito (rilevamento automatico della città tramite IP con chiarimento).
In secondo luogo, dobbiamo dare la possibilità di scegliere solo la merce che possiamo consegnare al cliente. Quando farlo? Al momento della selezione - sul riquadro del prodotto e sulla scheda prodotto.
Queste due modifiche contribuiscono notevolmente all’eliminazione di questa eccezione.
Requisiti per misurazioni e metriche
Quando si considera l'attività di minimizzazione della gestione delle eccezioni, è possibile impostare un'attività di reporting (il caso d'uso non è descritto). Quante eccezioni ci sono state, in quali casi si sono verificate e quanti scenari in entrata sono stati superati con successo.
Ma ahimè. L’esperienza ha dimostrato che i requisiti di rendicontazione per gli scenari in questa forma non sono sufficienti; è necessario considerare i requisiti di rendicontazione per i processi che sono descritti principalmente non sotto forma di caso d’uso.
Accesso all'usabilità
Nella nostra pratica, abbiamo ampliato il modulo di descrizione del caso d'uso con una descrizione di attributi specifici di entità e dati affinché il cliente possa prendere una decisione, il che migliora la successiva usabilità.
Per la progettazione dell'usabilità, abbiamo aggiunto una sezione di input: visualizzazione dei dati.
In uno scenario con autorizzazione, questo è il fatto che il client è autorizzato nel sistema. Se il cliente è pre-autorizzato, verrà visualizzato un avviso relativo al passaggio della cronologia di navigazione e del carrello al nuovo account dopo aver effettuato con successo l'autorizzazione.
In generale, si tratta di una visualizzazione delle informazioni necessarie per il cliente in modo che possa prendere una decisione sulle sue ulteriori azioni in base allo scenario (puoi chiedere se questi dati sono sufficienti per il cliente, cos'altro è necessario, quali informazioni servono il cliente ha bisogno di prendere decisioni).
Vale anche la pena dividere le informazioni inserite in campi di input se vengono elaborate separatamente e con la formazione di diverse eccezioni.
Nell'esempio con l'autorizzazione del cliente, se separi le informazioni inserite in login e password, vale la pena modificare lo script di autorizzazione per evidenziare le fasi di immissione di un login separato e di una password separata (e questo viene fatto in Yandex, Google, ma non fatto nella maggior parte dei negozi online).
Raggiungere le trasformazioni dei dati richieste
È inoltre possibile estrarre dallo script i requisiti per gli algoritmi di conversione dei dati.
Esempi:
- Per decidere di acquistare un prodotto in un negozio online, il cliente deve conoscere sulla scheda prodotto la possibilità, il costo, i tempi di consegna di questo prodotto nella sua città (che vengono calcolati dall'algoritmo in base alla disponibilità del prodotto in magazzini e parametri della catena di fornitura).
- Quando si inserisce una frase nella riga di ricerca, al cliente vengono mostrati i suggerimenti di ricerca secondo l'algoritmo (che vengono generati dall'algoritmo...).
In totale
In generale, dopo aver letto il libro, purtroppo, non è chiaro come passare dall'analista ai problemi aziendali alla specifica tecnica formalizzata per uno sviluppatore. Il libro racconta solo una parte del processo, con i passaggi di input poco chiari e i passaggi successivi poco chiari. Il caso d'uso stesso molto spesso non è una dichiarazione completa per lo sviluppatore.
Tuttavia, questo è un ottimo modo per formalizzare ed elaborare scenari di interazione tra un oggetto e un soggetto, quando l'interazione provoca un cambiamento in qualcosa nel soggetto. È uno dei pochi metodi di scrittura che consente requisiti verificabili con punti di ricerca di eccezioni esplicite.
Il libro è una lettura obbligata per gli analisti che vogliono iniziare a scrivere opere teatrali verificabili.
Fonte: habr.com