En el libro "Métodos modernos para describir los requisitos funcionales de los sistemas", Alistair Coburn describió un método para escribir una parte de la declaración del problema, a saber, el método del caso de uso.
Que es esto Esta es una descripción de un escenario de interacción del usuario con un sistema (o empresa). El sistema al mismo tiempo actúa como una caja negra (y esto hace posible dividir la compleja tarea de diseño en diseñar la interacción y asegurar esta interacción). Al mismo tiempo, se introducen estándares de notación, lo que garantiza la facilidad de lectura, incluso para los no participantes, y le permite hacer algunas verificaciones para verificar la integridad y el 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 para acceder a su cuenta personal. ~~ (nivel del mar)
Contexto: un cliente no autorizado está autorizado en el sitio para que el sitio lo reconozca y muestre información personal: historial de navegación, compras, el número actual de puntos de bonificación, etc., utilizando el correo electrónico como inicio de sesión.
Nivel: objetivo del usuario
Actor principal: cliente (visitante de nuestra tienda en línea)
Alcance: interacción del cliente con el sitio web de la tienda en línea
Partes interesadas e intereses:
- el vendedor quiere que se identifique el número máximo de visitantes del sitio para llegar mejor a los boletines personales,
- un especialista en seguridad quiere evitar el acceso no autorizado a los datos personales del visitante, incluidos los intentos de seleccionar una contraseña para una cuenta o buscar una cuenta con una contraseña débil,
- un atacante quiere obtener acceso a bonos de víctimas,
- los competidores quieren dejar comentarios negativos sobre los productos,
- la red de bots quiere obtener la base de clientes de la tienda y usar el ataque para que el sitio no funcione.
Condiciones previas: el visitante no debe iniciar sesión.
Garantías mínimas: el visitante descubrirá el hecho de un intento de inicio de sesión exitoso o fallido.
Garantías de éxito: el visitante está autorizado.
El 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 de autorización fallidos de esta sesión (busque una contraseña débil para muchas 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 ingresa el correo electrónico y la contraseña.
- El sistema confirma la presencia de un cliente con dicho correo electrónico en el sistema y la contraseña coincide y no excede el número de intentos de ingresar a esta cuenta de acuerdo con la Regla de Seguridad No. 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 de autorización y continúa con el paso del script desde el cual el cliente interrumpió para obtener la autorización. En este caso, los datos de la página se sobrecargan teniendo en cuenta los datos personales de la cuenta.
Extensiones:
2.a. El cliente ya está autorizado:
2.a.1. El sistema notifica al cliente el hecho de la autorización realizada anteriormente y sugiere abortar el script o continuar con el paso 4, mientras que si el paso 6 se completó con éxito, el paso 7 se lleva a cabo con la aclaración:
2.a.7. El sistema desactiva el cliente en la cuenta anterior, autoriza al cliente en la cuenta nueva, mientras que el historial de navegación y la cesta de esta sesión de interacción permanecen en la cuenta anterior, no entran en la nueva. A continuación, vaya al paso 8.
2.b El número de intentos de autorización excedió el umbral bajo "Regla de seguridad No. 23":
2.b.1 Vaya al paso 4, el captcha se muestra adicionalmente en el formulario de autorización
2.b.6 El sistema confirma la entrada correcta de captcha
2.b.6.1 Captcha ingresado incorrectamente:
2.b.6.1.1. el sistema también aumenta el contador de intentos fallidos de inicio de sesión para esta cuenta
2.b.6.1.2. el sistema muestra un mensaje de falla y vuelve al paso 2
6.a. No se encontró ninguna cuenta con este correo electrónico:
6.a.1 El sistema muestra un mensaje sobre la falla y ofrece la opción de una transición al paso 2 o una transición a la secuencia de comandos "Registro de usuario" con 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 ingresar a esta cuenta.
6.b.2 El sistema muestra un mensaje de error y ofrece elegir una transición al escenario "Recuperación de contraseña" o una transición al paso 2.
6.c: El contador de intentos de ingresar a esta cuenta ha excedido el umbral bajo "Regla de seguridad No. 24".
6.v.1 El sistema muestra un mensaje sobre el bloqueo de la entrada a 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 dar los requisitos de verificación a otro analista, lo que permite menos errores en la etapa de configuración de la tarea.
Trabajar con un sistema como una caja negra le permite compartir el desarrollo y la coordinación con el cliente de lo que se automatizará a partir de los métodos de implementación.
Es parte del camino del analista, una de las partes principales de la usabilidad. El guión del usuario establece los caminos principales para su movimiento, lo que reduce en gran medida la libertad de elección para el diseñador y el cliente y ayuda a aumentar la velocidad del desarrollo del diseño.
Es muy agradable en la descripción del lugar donde se revelan las excepciones de cada paso de interacción. Un sistema de TI holístico debe proporcionar uno u otro manejo de excepciones, parte en modo manual, parte en automático (como en el ejemplo anterior).
La experiencia ha demostrado que el manejo de excepciones mal pensado puede convertir fácilmente un sistema en un sistema terriblemente inconveniente. Recuerdo una historia cuando en la época soviética se necesitaban varias aprobaciones de diferentes servicios para tomar una decisión, y duele cuando el último servicio dice: y tienes un nombre incorrecto o algún otro error en la puntuación, rehaces todo y reconcilias todo.
A menudo me encuentro con situaciones en las que una lógica del sistema que no fue pensada para excepciones requería una alteración significativa de este sistema. Debido a esto, la mayor parte del trabajo del analista se gasta en el manejo de excepciones.
La notación de texto, a diferencia de los diagramas, le permite identificar y cubrir más excepciones.
Adición al método de práctica.
El caso de uso no es una parte de la producción con prioridad independiente, a diferencia de una historia de usuario.
En este escenario, 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 error y continúa con el paso 2". ¿Qué hay de lo negativo que queda detrás de escena? Para el cliente, cualquier devolución es equivalente al hecho de que todo el trabajo que ha realizado ingresando los datos se arroja al vertedero. (¡Esto simplemente no es visible en el script!) ¿Qué se puede hacer? Reconstruya el script para que esto no ocurra. ¿Se puede hacer esto? Puede, como ejemplo, mirar el script de autorización en Google.
Optimización de escenarios
El libro habla sobre la formalización, pero habla poco sobre los métodos de optimización para tales escenarios.
Pero es posible fortalecer el método optimizando scripts, y el método de formalización de casos de uso lo permite. Específicamente, para cada excepción que ocurra, debe pensar en ello, determinar la causa y reconstruir el script para deshacerse de la excepción o minimizar la ruta del cliente.
Al ordenar la tienda en línea, debe ingresar la ciudad de entrega. Puede resultar que para una ciudad elegida por el cliente, la tienda no puede entregar los productos porque no entrega allí, debido a restricciones generales o debido a la falta de productos en el almacén correspondiente.
Si simplemente describe el escenario de interacción en la etapa de diseño, puede escribir "informar al cliente sobre la imposibilidad de entrega y ofrecer cambiar la ciudad o la composición de la cesta" (y muchos analistas novatos se detienen en esto). Pero si hay muchos de estos casos, puede optimizar el escenario.
Lo primero que debe hacer es dar solo la ciudad donde podemos hacer la entrega. Cuando hacerlo Antes del momento de elegir un producto en el sitio (autodetección de la ciudad a través de ip con especificación).
En segundo lugar, debe elegir solo los productos que podemos entregar al cliente. Cuando hacerlo En el momento de la selección: en la ficha de productos y en la tarjeta de producto.
Estos dos cambios eliminan significativamente esta excepción.
Medición y requisitos métricos
Teniendo en cuenta la tarea de minimizar el manejo de excepciones, puede asignar la tarea a la presentación de informes (no se describe el caso de uso). Cuántas excepciones hubo, en qué casos ocurrieron, más cuántos escenarios tuvieron éxito de los entrantes.
Pero por desgracia. La experiencia ha demostrado que los requisitos de informes para escenarios en este formulario no son suficientes, debe considerar los requisitos de informes para los procesos que se describen principalmente no en forma de un caso de uso.
Acceso de usabilidad
En nuestra práctica, hemos ampliado la descripción de la descripción del caso de uso con la descripción de atributos específicos de entidades y datos para la toma de decisiones por parte del cliente, lo que mejora la usabilidad posterior.
Para el diseño de usabilidad, agregamos una sección de entrada: los datos mostrados.
En un escenario de autorización, este es un hecho de autorización del cliente en el sistema. Si el cliente está preautorizado, muestre una advertencia sobre cómo cambiar el historial de navegación y la cesta a la nueva cuenta después de una autorización exitosa.
En el caso general, este es un mapeo de la información necesaria para el cliente para que pueda tomar una decisión sobre sus acciones adicionales de acuerdo con el escenario (uno puede preguntar si el cliente tiene suficientes datos, qué más se necesita, qué información se necesita para que el cliente tome decisiones).
También vale la pena dividir la información de entrada en los campos de entrada si su procesamiento se produce por separado y con la formación de varias excepciones.
En el ejemplo con autorización del cliente, si resalta la información ingresada con un nombre de usuario y una contraseña, debe cambiar la secuencia de comandos de autorización con los pasos separados para ingresar un nombre de usuario y contraseña por separado (y esto se hace en Yandex, Google, pero no en la mayoría de las tiendas en línea).
Acceso a las conversiones de datos requeridas.
Los requisitos para los algoritmos de transformación de datos también se pueden extraer del script.
Ejemplos:
- Para tomar una decisión sobre la compra de un producto en una tienda en línea, un cliente debe conocer la posibilidad, el costo y el tiempo de entrega de este producto a su ciudad (que se calculan mediante el algoritmo sobre el hecho de la disponibilidad de bienes en los almacenes y los parámetros de la cadena de suministro).
- Cuando se ingresa una frase en la cadena de búsqueda, el algoritmo muestra al cliente las sugerencias de búsqueda (que están formadas por el algoritmo ...).
Total
En general, después de leer el libro, desafortunadamente, no está claro cómo pasar del analista a los problemas comerciales y los conocimientos tradicionales formalizados para el desarrollador. El libro cuenta solo una parte del proceso con los pasos entrantes y los pasos mostrados con claridad. Por sí solo, el caso de uso no suele ser una declaración completa para el desarrollador.
Sin embargo, esta es una muy buena forma de formalizar y procesar escenarios de la interacción de 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 excepción explícitos.
Los analistas deben leer el libro para que comiencen a escribir producciones verificables.