El libro describe un método para escribir parte del planteamiento de un problema, concretamente el método de casos de uso.
¿Lo que es? Esta es una descripción del escenario de interacción del usuario con el sistema (o con la empresa). En este caso, el sistema actúa como una caja negra (y esto permite dividir la compleja tarea de diseño en diseñar interacción y garantizar esta interacción). Al mismo tiempo, se introducen estándares de notación, lo que garantiza una fácil lectura, incluso para los no participantes, y permite realizar algunas comprobaciones de su integridad y cumplimiento de los objetivos de las partes interesadas.
Ejemplo de caso de uso
Cómo se ve el escenario, usando el ejemplo de autorización en el sitio por correo electrónico:
(Sistema) Inicie sesión en el sitio web para acceder a su cuenta personal. ~~ (nivel del mar)
Contexto: Un cliente no autorizado inicia sesión en el sitio para que el sitio lo reconozca y le muestre información personal: historial de navegación, historial de compras, número actual de puntos de bonificación, etc., utilizando el correo electrónico como inicio de sesión.
Nivel: objetivo del usuario
Protagonista: cliente (visitante de nuestra tienda online)
Alcance: Interacción del cliente con el sitio web de la tienda online.
Partes interesadas e intereses:
- el especialista en marketing quiere identificar el número máximo de visitantes del sitio para una mayor cobertura de los correos personales,
- el especialista en seguridad quiere asegurarse de que no haya casos de acceso no autorizado a los datos personales del visitante, incluidos intentos de adivinar la contraseña de una cuenta o buscar una cuenta con una contraseña débil,
- el atacante quiere obtener acceso a las bonificaciones de la víctima,
- los competidores quieren dejar críticas negativas sobre los productos,
- La botnet quiere obtener la base de clientes de la tienda y utilizar un ataque para dejar el sitio inoperable.
Condiciones previas: el visitante no debe estar autorizado.
Garantías mínimas: el visitante sabrá si el intento de autorización fue exitoso o no.
Garantías de éxito: el visitante está autorizado.
Escenario principal:
- El cliente inicia la autorización.
- El sistema confirma que el cliente no está autorizado y no excede el número de intentos fallidos de autorización de una sesión determinada (buscando una contraseña débil para múltiples cuentas) de acuerdo con la “Regla de Seguridad No. 23”.
- El sistema aumenta el contador del número de intentos de autorización.
- El sistema muestra un formulario de autorización al cliente.
- El cliente introduce su correo electrónico y contraseña.
- El sistema confirma la presencia de un cliente con dicho correo electrónico en el sistema y que la contraseña coincide y que no se excede el número de intentos de inicio de sesión en esta cuenta de acuerdo con la "Regla de seguridad n.° 24".
- El sistema autoriza al cliente, agrega el historial de navegación y la cesta de esta sesión con la última sesión de esta cuenta de cliente.
- El sistema muestra un mensaje de autorización exitosa y pasa al paso del guión desde el cual se interrumpió al cliente para obtener autorización. En este caso, los datos de la página se recargan teniendo en cuenta los datos de la cuenta personal.
Extensiones:
2.a. El cliente ya está autorizado:
2.a.1. El sistema notifica al cliente sobre el hecho de la autorización realizada previamente y ofrece interrumpir el script o ir al paso 4, y si el paso 6 se completa con éxito, entonces se realiza el paso 7 con una aclaración:
2.a.7. El sistema desactoriza al cliente con la cuenta anterior, autoriza al cliente con la cuenta nueva, mientras que el historial de navegación y el carrito de esta sesión de interacción permanecen en la cuenta anterior y no se transfieren a la nueva. A continuación, vaya al paso 8.
2.b El número de intentos de autorización ha superado el umbral según la “Regla de Seguridad N° 23”:
2.b.1 Vaya al paso 4, además se muestra un captcha en el formulario de autorización
2.b.6 El sistema confirma la entrada correcta del captcha
2.b.6.1 Captcha ingresado incorrectamente:
2.b.6.1.1. el sistema también aumenta el contador de intentos de autorización fallidos para esta cuenta
2.b.6.1.2. el sistema muestra un mensaje de error y regresa al paso 2
6.a. No se encontró ninguna cuenta con este correo electrónico:
6.a.1 El sistema muestra un mensaje sobre falla y ofrece la opción de ir al paso 2 o ir al escenario "Registro de usuario" y guardar el correo electrónico ingresado.
6.b. La contraseña de la cuenta con este correo electrónico no coincide con la ingresada:
6.b.1 El sistema aumenta el contador de intentos fallidos de inicio de sesión en esta cuenta.
6.b.2 El sistema muestra un mensaje sobre falla y ofrece la opción de ir al escenario "Recuperación de contraseña" o al paso 2.
6.c: El contador de intentos de inicio de sesión para esta cuenta superó el umbral de la "Regla de seguridad n.º 24".
6.c.1 El sistema muestra un mensaje sobre el bloqueo de inicio de sesión de la cuenta durante X minutos y continúa con el paso 2.
que es genial
Verifica la integridad y el cumplimiento de los objetivos, es decir, puede enviar los requisitos a otro analista para que los verifique, cometiendo menos errores en la etapa de formulación del problema.
Trabajar con un sistema de caja negra permite separar el desarrollo y la coordinación con el cliente de lo que se automatizará de los métodos de implementación.
Es parte del camino del analista, una de las partes principales de la usabilidad. El escenario del usuario define las principales rutas de su movimiento, lo que reduce en gran medida la libertad de elección del diseñador y del cliente y ayuda a aumentar la velocidad de desarrollo del diseño.
Estoy muy satisfecho con el lugar en la descripción donde se identifican las excepciones a cada paso de interacción. Un sistema de TI completo debe prever algún tipo de manejo de excepciones, algunas manualmente y otras automáticamente (como en el ejemplo anterior).
La experiencia demuestra que un manejo de excepciones mal pensado puede convertir fácilmente un sistema en un sistema terriblemente inconveniente. Recuerdo la historia cuando en la época soviética, para tomar una decisión, era necesario obtener varias aprobaciones de diferentes servicios, y lo doloroso que es cuando el último servicio dice: pero su solicitud tiene el nombre equivocado o algún otro error en puntuación, rehacer todo y volver a coordinar todo.
A menudo me encuentro con situaciones en las que la lógica operativa de un sistema que no estaba pensado para excepciones requería una reelaboración importante del sistema. Debido a esto, la mayor parte del trabajo del analista se dedica al manejo de excepciones.
La notación de texto, a diferencia de los diagramas, permite identificar y cubrir más excepciones.
Adición al método de la práctica.
El caso de uso no es una parte priorizada de forma independiente de la declaración, a diferencia de la historia de usuario.
En el escenario anterior, considere la excepción “6.a. No se encontró ninguna cuenta con este correo electrónico”. y el siguiente paso “6.a.1 El sistema muestra un mensaje de falla y continúa con el paso 2”. ¿Qué cosas negativas quedaron detrás de escena? Para el cliente, cualquier devolución equivale a que todo el trabajo que realizó ingresando datos sea arrojado a un vertedero. (¡Simplemente no es visible en el guión!) ¿Qué se puede hacer? Reconstruya el script para que esto no suceda. ¿Es posible hacer esto? Puede, como ejemplo, mirar el script de autorización de Google.
Optimización de escenarios
El libro habla de formalización, pero dice poco sobre métodos para optimizar tales escenarios.
Pero es posible fortalecer el método optimizando escenarios, y el método de formalización de casos de uso permite hacerlo. Específicamente, debe pensar en cada excepción que ocurre, determinar la causa y reconstruir el script para eliminar la excepción o minimizar el recorrido del cliente.
Al realizar un pedido en una tienda online, deberás introducir la ciudad de entrega. Puede resultar que la tienda no pueda entregar la mercancía en la ciudad elegida por el cliente porque no entrega allí, por restricciones de tamaño, o por falta de mercancía en el almacén correspondiente.
Si simplemente describimos el escenario de interacción en la etapa de registro, podemos escribir "informar al cliente que la entrega es imposible y ofrecerle cambiar la ciudad o el contenido del carrito" (y muchos analistas novatos se detienen ahí). Pero si hay muchos casos de este tipo, entonces el escenario se puede optimizar.
Lo primero que debe hacer es permitirle elegir solo la ciudad donde podemos realizar la entrega. ¿Cuándo hacer esto? Antes de seleccionar un producto en el sitio web (autodetección de la ciudad vía IP con aclaración).
En segundo lugar, debemos permitir elegir únicamente los productos que podemos entregar al cliente. ¿Cuándo hacer esto? En el momento de la selección, en el mosaico del producto y en la ficha del producto.
Estos dos cambios contribuyen en gran medida a eliminar esta excepción.
Requisitos para medidas y métricas.
Al considerar la tarea de minimizar el manejo de excepciones, puede establecer una tarea de informes (el caso de uso no se describe). Cuántas excepciones hubo, en qué casos ocurrieron y cuántos escenarios entrantes pasaron con éxito.
Pero Ay. La experiencia ha demostrado que los requisitos de presentación de informes para escenarios en esta forma no son suficientes; es necesario considerar los requisitos de presentación de informes para procesos que se describen principalmente no en forma de caso de uso.
Acceso a la Usabilidad
En nuestra práctica, hemos ampliado el formulario de descripción de casos de uso con una descripción de atributos específicos de entidades y datos para que el cliente tome una decisión, lo que mejora la usabilidad posterior.
Para el diseño de usabilidad, agregamos una sección de entrada: mostrar datos.
En un escenario con autorización, es el hecho de que el cliente está autorizado en el sistema. Si el cliente tiene autorización previa, se muestra una advertencia sobre cómo cambiar el historial de navegación y el carrito a la nueva cuenta después de una autorización exitosa.
En general, esta es una visualización de la información necesaria para que el cliente pueda tomar una decisión sobre sus acciones futuras según el escenario (puede preguntar si estos datos son suficientes para el cliente, qué más se necesita, qué información necesita el cliente necesita tomar decisiones).
También vale la pena dividir la información ingresada en campos de entrada si se procesan por separado y con la formación de diferentes excepciones.
En el ejemplo con autorización del cliente, si separa la información ingresada en nombre de usuario y contraseña, entonces vale la pena cambiar el script de autorización para resaltar las etapas para ingresar un nombre de usuario y una contraseña por separado (y esto se hace en Yandex, Google, pero no se hace en la mayoría de las tiendas en línea).
Alcanzar las transformaciones de datos requeridas
También puede extraer los requisitos para los algoritmos de conversión de datos del script.
Ejemplos:
- Para tomar la decisión de comprar un producto en una tienda online, el cliente necesita conocer en la ficha del producto la posibilidad, el costo y el tiempo de entrega a su ciudad de este producto (que se calculan mediante un algoritmo en función de la disponibilidad del producto en almacenes y parámetros de la cadena de suministro).
- Al introducir una frase en la línea de búsqueda, al cliente se le muestran sugerencias de búsqueda según el algoritmo (que son generadas por el algoritmo...).
En total
En general, después de leer el libro, desafortunadamente, no está claro cómo pasar de un analista a problemas comerciales y a una especificación técnica formalizada para un desarrollador. El libro cuenta sólo una parte del proceso, con los pasos de entrada poco claros y los siguientes pasos poco claros. El caso de uso en sí no suele ser una declaración completa para el desarrollador.
Sin embargo, esta es una muy buena manera de formalizar y procesar escenarios de interacción entre un objeto y un sujeto, cuando la interacción provoca un cambio en algo en el sujeto. Es uno de los pocos métodos de escritura que permite requisitos verificables con puntos de búsqueda de excepciones explícitos.
El libro es una lectura obligada para que los analistas comiencen a escribir obras comprobables.
Fuente: habr.com