O libro describe un método para escribir parte dunha declaración de problema, é dicir, o método dos casos de uso.
Que é? Esta é unha descrición do escenario de interacción do usuario co sistema (ou coa empresa). Neste caso, o sistema actúa como unha caixa negra (e iso fai posible dividir a complexa tarefa de deseño en deseñar a interacción e garantir esta interacción). Ao mesmo tempo, introdúcense estándares de notación, que garanten a facilidade de lectura, incluso para os non participantes, e permiten comprobar a integridade e o cumprimento dos obxectivos do interesado.
Exemplo de caso de uso
Como é o escenario, usando o exemplo de autorización no sitio por correo electrónico:
(Sistema) Inicie sesión no sitio web para acceder á súa conta persoal. ~~ (nivel do mar)
Contexto: Un cliente non autorizado inicia sesión no sitio para que o recoñeza e mostre información persoal para el: historial de navegación, historial de compras, número actual de puntos de bonificación, etc., utilizando o correo electrónico como inicio de sesión.
Nivel: obxectivo do usuario
Personaxe principal: cliente (visitante da nosa tenda en liña)
Ámbito: Interacción do cliente co sitio web da tenda en liña
Persoas interesadas e intereses:
- o comerciante quere que se identifique o número máximo de visitantes do sitio para unha maior cobertura de correos persoais,
- o especialista en seguridade quere garantir que non hai casos de acceso non autorizado aos datos persoais do visitante, incluídos os intentos de adiviñar o contrasinal dunha conta ou buscar unha conta cun contrasinal débil,
- o atacante quere acceder aos bonos da vítima,
- os competidores queren deixar comentarios negativos sobre produtos,
- A botnet quere obter a base de clientes da tenda e usar un ataque para que o sitio sexa inoperable.
Condicións previas: o visitante non debe estar autorizado.
Garantías mínimas: o visitante saberá se o intento de autorización foi exitoso ou non.
Garantías de éxito: o visitante está autorizado.
Escenario principal:
- O cliente inicia a autorización.
- O sistema confirma que o cliente non está autorizado e non supera o número de intentos de autorización infrutuosos dunha sesión determinada (buscando un contrasinal débil para varias contas) segundo a "Regra de seguridade núm. 23".
- O sistema aumenta o contador do número de intentos de autorización.
- O sistema mostra un formulario de autorización ao cliente.
- O cliente introduce o seu correo electrónico e contrasinal.
- O sistema confirma a presenza dun cliente con tal correo electrónico no sistema e que o contrasinal coincide e que o número de intentos de inicio de sesión nesta conta non se supera segundo a "Regra de seguridade número 24".
- O sistema autoriza o cliente, engade o historial de navegación e a cesta desta sesión coa última sesión desta conta de cliente.
- O sistema mostra unha mensaxe de autorización correcta e pasa ao paso de guión desde o que se interrompeu o cliente para obter a autorización. Neste caso, os datos da páxina recárganse tendo en conta os datos da conta persoal.
Extensións:
2.a. O cliente xa está autorizado:
2.a.1. O sistema notifica ao cliente o feito da autorización realizada previamente e ofrece interromper o script ou ir ao paso 4, e se o paso 6 se completa con éxito, o paso 7 realízase con aclaración:
2.a.7. O sistema desactoriza o cliente coa conta antiga, autoriza o cliente coa nova conta, mentres que o historial de navegación e o carro desta sesión de interacción permanecen na conta antiga e non se transfiren á nova. A continuación, vai ao paso 8.
2.b O número de intentos de autorización superou o limiar segundo a “Regra de seguridade n.o 23”:
2.b.1 Vaia ao paso 4, tamén se mostra un captcha no formulario de autorización
2.b.6 O sistema confirma a entrada correcta do captcha
2.b.6.1 Captcha introducido incorrectamente:
2.b.6.1.1. o sistema tamén aumenta o contador de intentos de autorización infrutuosos para esta conta
2.b.6.1.2. o sistema mostra unha mensaxe de fallo e volve ao paso 2
6.a. Non se atopou ningunha conta con este correo electrónico:
6.a.1 O sistema mostra unha mensaxe sobre o fallo e ofrece a opción de ir ao paso 2 ou ir ao escenario "Rexistro de usuario" e gardar o correo electrónico introducido.
6.b. O contrasinal da conta con este correo electrónico non coincide co introducido:
6.b.1 O sistema aumenta o contador de intentos de inicio de sesión non exitosos nesta conta.
6.b.2 O sistema mostra unha mensaxe sobre o fallo e ofrece a opción de ir ao escenario "Recuperación de contrasinal" ou ir ao paso 2.
6.c: o contador de intentos de inicio de sesión para esta conta superou o limiar para a "Regra de seguridade número 24".
6.c.1 O sistema mostra unha mensaxe sobre o bloqueo do inicio de sesión na conta durante X minutos e pasa ao paso 2.
Que xenial
Comproba a integridade e o cumprimento dos obxectivos, é dicir, pode darlle requisitos a outro analista para a súa verificación, cometendo menos erros na fase de formulación do problema.
Traballar cun sistema tipo caixa negra permite separar o desenvolvemento e a coordinación co cliente do que se automatizará dos métodos de implementación.
Forma parte do camiño do analista, unha das partes principais da usabilidade. O escenario do usuario define os principais camiños do seu movemento, o que reduce moito a liberdade de elección do deseñador e do cliente e axuda a aumentar a velocidade de desenvolvemento do deseño.
Estou moi satisfeito co lugar da descrición onde se identifican as excepcións a cada paso de interacción. Un sistema de TI completo debe prever algún tipo de manexo de excepcións, algúns manualmente, outros automaticamente (como no exemplo anterior).
A experiencia demostra que un manexo de excepcións mal pensado pode converter facilmente un sistema nun sistema terriblemente inconveniente. Recordo a historia na que na época soviética, para tomar unha decisión, tiñas que obter varias aprobacións de diferentes servizos, e o doloroso que é cando o último servizo di, pero a túa solicitude ten un nome incorrecto ou algún outro erro. puntuación, refacer todo e volver a coordinar todo.
Moitas veces atópome con situacións nas que a lóxica de funcionamento dun sistema que non estaba pensado para excepcións requiría unha reelaboración significativa do sistema. Por iso, a maior parte do traballo do analista gástase no manexo de excepcións.
A notación de texto, a diferenza dos diagramas, permite identificar e cubrir máis excepcións.
Adición ao método dende a práctica
O caso de uso non é unha parte da declaración con prioridade independente, a diferenza da historia do usuario.
No escenario anterior, considere a excepción "6.a. Non se atopou ningunha conta con este correo electrónico." e o seguinte paso "6.a.1 O sistema mostra unha mensaxe de fallo e pasa ao paso 2". Que cousas negativas quedaron entre bastidores? Para o cliente, calquera devolución equivale a que todo o traballo que fixo introducindo datos é tirado a un vertedoiro. (Non é visible no guión!) Que se pode facer? Reconstruír o script para que isto non ocorra. É posible facelo? Podes, como exemplo, mirar o script de autorización de Google.
Optimización de escenarios
O libro fala de formalización, pero di pouco sobre métodos para optimizar tales escenarios.
Pero é posible reforzar o método optimizando escenarios, e o método de formalización de casos de uso permite facelo. En concreto, cómpre pensar en cada excepción que se produza, determinar a causa e reconstruír o script para desfacerse da excepción ou minimizar a viaxe do cliente.
Ao facer un pedido nunha tenda en liña, debes introducir a cidade de entrega. Pode resultar que a tenda non poida entregar mercadorías na cidade escollida polo cliente porque non entrega alí, por restricións de tamaño ou por falta de mercadorías no almacén correspondente.
Se simplemente describimos o escenario de interacción na fase de rexistro, podemos escribir "informar ao cliente de que a entrega é imposible e ofrecernos cambiar a cidade ou o contido do carro" (e moitos analistas novatos detéñense aí). Pero se hai moitos destes casos, entón o escenario pódese optimizar.
O primeiro que debes facer é deixarche escoller só a cidade onde podemos entregar. Cando facer isto? Antes de seleccionar un produto na páxina web (autodetección da cidade vía IP con aclaración).
En segundo lugar, temos que escoller só os bens que podemos entregar ao cliente. Cando facer isto? No momento da selección - na tella do produto e na tarxeta do produto.
Estes dous cambios supoñen un longo camiño para eliminar esta excepción.
Requisitos para medidas e métricas
Ao considerar a tarefa de minimizar o manexo de excepcións, pode establecer unha tarefa de informes (non se describe o caso de uso). Cantas excepcións houbo, en que casos se produciron, máis cantos escenarios entrantes pasaron con éxito.
Pero ai. A experiencia demostrou que os requisitos de informes para escenarios neste formulario non son suficientes; é necesario considerar os requisitos de informes para procesos que se describen principalmente non en forma de caso de uso.
Acceso á Usabilidade
Na nosa práctica, ampliamos o formulario de descrición de casos de uso cunha descrición de atributos específicos de entidades e datos para que o cliente tome unha decisión, o que mellora a usabilidade posterior.
Para o deseño de usabilidade, engadimos unha sección de entrada: mostrar datos.
Nun escenario con autorización, este é o feito de que o cliente está autorizado no sistema. Se o cliente está preautorizado, amosa unha advertencia sobre o cambio do historial de navegación e do carro á nova conta despois da autorización exitosa.
En xeral, esta é unha mostra da información necesaria para o cliente para que poida tomar unha decisión sobre as súas accións posteriores segundo o escenario (pode preguntar se estes datos son suficientes para o cliente, que máis se necesita, que información fai o cliente debe tomar decisións).
Tamén paga a pena dividir a información introducida en campos de entrada se se procesan por separado e coa formación de diferentes excepcións.
No exemplo con autorización do cliente, se separa a información introducida entre o inicio de sesión e o contrasinal, paga a pena cambiar o script de autorización para resaltar as etapas para introducir un inicio de sesión e un contrasinal separados (e isto faise en Yandex, Google, pero non se fai na maioría das tendas en liña).
Alcanzar as transformacións de datos requiridas
Tamén pode extraer os requisitos para os algoritmos de conversión de datos do script.
Exemplos:
- Para tomar a decisión de comprar un produto nunha tenda en liña, o cliente debe coñecer na tarxeta do produto a posibilidade, o custo e o prazo de entrega á súa cidade deste produto (que son calculados polo algoritmo en función da dispoñibilidade do produto en almacéns e parámetros da cadea de subministración).
- Ao introducir unha frase na liña de busca, móstranse ao cliente suxestións de busca segundo o algoritmo (que son xerados polo algoritmo...).
En total
En xeral, despois de ler o libro, desafortunadamente, non está claro como ir desde un analista ata problemas comerciais ata unha especificación técnica formalizada para un desenvolvedor. O libro conta só unha parte do proceso, cos pasos de entrada pouco claros e os seguintes pasos. O caso de uso en si non é a maioría das veces unha declaración completa para o desenvolvedor.
Non obstante, esta é unha moi boa forma de formalizar e procesar escenarios de interacción entre un obxecto e un suxeito, cando a interacción provoca un cambio en algo no suxeito. É un dos poucos métodos de escritura que permite requisitos verificables con puntos de busca de excepcións explícitas.
O libro é unha lectura obrigada para que os analistas comecen a escribir obras de teatro comprobables.
Fonte: www.habr.com