Hable sobre la descripción de requisitos - casos de uso
Vale la pena mencionar que, aunque RUP se considera un proceso de gestión de software pesado, cada vez más desarrolladores de software están comenzando a adoptar métodos ágiles para responder a los requisitos cambiantes. Sin embargo, como forma de describir los requisitos, el concepto y la metodología de los casos de uso todavía nos ayudan a analizar los requisitos.
Desde la perspectiva de la expresión, los casos de uso están más orientados a objetos y al diseño que los diagramas de secuencia, diagramas de flujo y otros métodos de expresión de demanda. A menudo, los casos de uso son más fáciles de aceptar para personas sin formación profesional. Los casos de uso se pueden utilizar como una forma de establecer requisitos para los usuarios o partes externas.
Los casos de uso son una forma de describir requisitos. Los casos de uso describen la respuesta del sistema a las solicitudes de los actores en diferentes condiciones. Los casos de uso generalmente realizan solicitudes al sistema a través de un participante (¿quién?), y el sistema ejecuta una determinada secuencia de comportamientos (¿cómo las satisface el sistema?) en función de la solicitud del participante (¿qué hacer?) y bajo diferentes condiciones. Cada secuencia de comportamiento puede denominarse escenario y un caso de uso contiene múltiples escenarios. Un escenario también puede denominarse instancia de un caso de uso.
Los casos de uso formales deben incluir: nombre del caso de uso, descripción general, alcance, nivel, participantes principales, personal e intereses relacionados con el proyecto, requisitos previos, garantías mínimas, garantías de éxito, eventos desencadenantes, principales escenarios de éxito, escenarios extendidos y Información relacionada, etc.
El significado de cada componente es el siguiente:
Los casos de uso se pueden utilizar para diferentes propósitos, por ejemplo:
Los diferentes propósitos de escritura conducen al énfasis en El proceso de escritura de casos de uso es diferente.
Diferentes situaciones de equipo también pueden conducir a diferentes casos de uso. Por ejemplo, en un equipo de proyecto de desarrollo grande, la descripción debe basarse estrictamente en ejemplos de casos de uso, mientras que en un equipo de proyecto pequeño con comunicación frecuente, se puede utilizar un método de descripción relativamente simple.
Los componentes mencionados anteriormente son más comunes. De hecho, el formato de un caso de uso no es estático y la información que contiene se puede agregar o reducir si es necesario. ¿Qué información debería incluirse en un caso de uso específico? Hay diferentes escuelas. Aquellos que estén interesados pueden consultar la información relevante, pero no entraré en ello aquí.
En una palabra: Su caso de uso no es mi caso de uso, sólo el caso de uso apropiado es el mejor.
Las ideas principales de este artículo provienen de "Escribir casos de uso eficaces" de Alistair Cockburn. Quienes estén interesados pueden leer el texto original.
Los casos de uso se utilizan para expresar requisitos, pero hay dos puntos a tener en cuenta:
El nombre del caso de uso se utiliza para identificar un caso de uso y es fácil de resumir y leer.
Regla: Utilizar frases verbo-objeto en voz activa para describir.
En general, se recomienda utilizar frases verbo-objeto de voz activa para describir el propósito del caso de uso. Tales como: "Buscar producto", "Agregar al carrito de compras". En algunos casos, si necesita expresar un caso de uso con mayor precisión, puede modificarlo agregando atributos, como "El usuario borra el carrito" y "El administrador borra el carrito".
Reglas: Describe a los jugadores principales.
La descripción del caso de uso debe describir a los participantes principales. Por ejemplo, puede utilizar "pagar el pedido" (para los participantes principales) en lugar de "cobrar la tarifa del pedido" (para el sistema). .
El alcance del caso de uso puede brindarnos una base básica sobre los límites del sistema y los requisitos de discusión. Diferentes alcances de diseño pueden conducir a diferentes actores y escenarios que debemos discutir. En pocas palabras, se trata de definir un alcance para el sistema que estamos discutiendo y determinar los límites de nuestra discusión.
Por ejemplo, analizaremos el comportamiento de pedido de un usuario. Si el alcance es toda la empresa, el personal relevante del proyecto son los usuarios y proveedores de servicios externos (como entrega urgente, etc.). Sin embargo, si el alcance es el sistema, el personal relevante del proyecto también debe incluirse. administradores de sistemas y personal de servicio al cliente dentro de la empresa.
Entonces, al escribir casos de uso, debemos determinar cuál es el alcance de nuestros casos de uso, para que podamos tener una * * * comprensión de los temas discutidos en los casos de uso.
Al analizar el alcance del diseño de los casos de uso, primero es necesario determinar el alcance funcional del sistema. Cockburn recomienda una lista interna/externa para determinar el alcance de la funcionalidad para escribir casos de uso efectivos.
Los beneficios de determinar el alcance funcional son obvios. Por ejemplo, ya existe un sistema de pedidos de impresión fuera del sistema. Sin distinguir claramente el alcance funcional del sistema, algunos desarrolladores pueden diseñar e implementar la funcionalidad de pedidos de impresión. De hecho, estas funciones no requieren diseño.
Después de definir el alcance funcional, también se puede confirmar el ejecutor del sistema. En el ejemplo anterior, el sistema de orden de impresión actuará como ejecutor secundario para el caso de uso de "orden de impresión".
Una vez determinado el alcance funcional, se completa el alcance del diseño. El alcance del diseño se refiere a los límites y objetos que analizamos al escribir casos de uso. Cuando decimos alcance en casos de uso, nos referimos al alcance de diseño (no al alcance funcional) a menos que se indique lo contrario.
Veamos un ejemplo. ECom planea construir un sistema ESys, que incluya varios subsistemas como ESubSys.
Si analizamos los casos de uso con ECom como alcance del diseño, nos preocupa lo que los usuarios quieren de la empresa y de qué forma la empresa satisface los requisitos del usuario. Si hay empresas externas, también es necesario considerar cuál es el negocio entre las empresas externas.
Si analizamos casos de uso con ESys como alcance de diseño, estamos más preocupados por la solicitud del usuario al sistema y la respuesta del sistema a la solicitud. Al mismo tiempo, si se utiliza ESys como alcance, los empleados dentro de la empresa también se convierten en los ejecutores de los casos de uso, y también debemos considerar las solicitudes de los empleados para el sistema.
Determinar el alcance del caso de uso puede ayudarnos a saber cuál es el problema que queremos discutir, definir el alcance de nuestra discusión y darle al caso de uso un entorno de lenguaje.
Regla: El alcance del diseño es un nombre distinguido simple.
El alcance del caso de uso debe ser un sustantivo simple y describir brevemente los límites del alcance de la discusión del caso de uso. Por ejemplo, el rango del ejemplo anterior se puede representar directamente mediante "ECom", "ESys" y "ESubSys".
El ejecutor principal es la persona o cosa entre el personal relacionado con el sistema que solicita la respuesta del sistema. El ejecutor principal es el iniciador de las solicitudes del sistema, pero es posible que no esté directamente relacionado con el sistema operativo.
En un caso, el ejecutor maestro opera el sistema a través de otro operador del sistema. Por ejemplo, un cliente llama al servicio de atención al cliente por un pedido inusual. Los clientes no realizan consultas directamente a través del sistema.
Otra situación es activar la tarea a una hora fija. Si el cliente quiere que el sistema realice una tarea de forma regular, el responsable final de ejecutar el sistema es el propio sistema.
Aunque es importante identificar al ejecutor principal, a veces el ejecutor principal no es tan importante.
Al escribir casos de uso, determine el ejecutor principal y clasifique completamente los requisitos del sistema desde la perspectiva del ejecutor. También podemos diseñar la interacción del sistema en función de las características del ejecutor principal. A continuación se muestra un resumen de los ejecutores principales:
En la mayoría de los casos, después de comenzar a escribir casos de uso, el ejecutor principal se vuelve menos importante. Por ejemplo, cuando diseñamos casos de uso para consultar pedidos, no hay una diferencia especial entre los casos de uso para consultar pedidos, ya sean administradores, gerentes, servicio al cliente o incluso otros puestos de la empresa. En este momento, no importa quién sea el ejecutor principal.
Regla: El ejecutor principal de un caso de uso puede ser el ejecutor o el rol de ejecutor.
En el escenario anterior, describiremos algunos de los actores clave y crearemos una "tabla de mapeo de roles y actores". En el caso de uso anterior, hemos descrito administradores, gerentes, etc. Pasar a un rol operativo: Gerente de pedidos. Cuando describimos casos de uso, podemos pensar en los actores como actores principales.
La descripción general se utiliza principalmente para describir los objetivos del caso de uso, es decir, lo que el usuario necesita lograr.
Regla: Utilizar descripción en lenguaje natural.
Intenta utilizar un lenguaje natural para explicar qué harán los usuarios cuando quieran completar sus objetivos.
Regla: Describe lo que se logra con el caso de uso, no los pasos del sistema.
Siempre que esté claro lo que se debe lograr en el caso de uso, no es necesario describir los pasos del sistema ni el proceso operativo específico del usuario.
Por ejemplo, "Después de que el usuario selecciona un producto para comprar, puede agregar el producto al carrito de compras y luego enviar el pedido en el carrito de compras. El usuario también puede comprar el producto seleccionado directamente sin agregarlo al carrito de compras. "No es necesario que la descripción general describa operaciones específicas del sistema y no hay una descripción de los detalles de operación del sistema, como "haga clic en el botón para agregar al carrito de compras".
El personal relacionado con el proyecto se refiere a participantes que tienen intereses específicos en el sistema. La persona relevante no tiene por qué ser una persona, sino que también puede ser un sistema externo, una organización, etc.
Por lo tanto, es posible convertirse en una parte interesada del proyecto:
Director ejecutivo
El ejecutor principal es la persona relevante que inicia la ejecución del caso de uso.
Ejecutor auxiliar
Ejecutor auxiliar es un ejecutor externo que sirve a la ejecución del sistema diseñado. El actor auxiliar puede ser otro sistema o una persona u organización. Por ejemplo, la impresora imprime varias facturas para el sistema. Otro ejemplo es la empresa de entrega urgente, que proporciona servicios de entrega urgente e información logística al sistema.
Ejecutores internos
Los ejecutores internos son personal relevante dentro del sistema que presta atención a los intereses del sistema.
Diseñar sistemas
El propio sistema diseñado a veces tiene beneficios específicos para sí mismo.
Para el personal relevante, hay varios puntos que deben explicarse:
Reglas: el personal y los intereses relevantes se escriben en forma de una lista correspondiente.
Utilice ":ltinterests>" para describir personas relevantes y sus intereses.
En el proceso de redacción de casos de uso, a veces describimos las necesidades de un usuario (como un usuario que compra bienes), a veces describimos una función específica de un sistema (como un usuario que inicia sesión) y a veces describimos un proceso (como el inicio de sesión de un usuario, el proceso de compra y obtención de bienes). Al escribir casos de uso, conocer la ubicación de los casos de uso nos resulta muy útil para escribir y comprender los casos de uso.
Dividimos la jerarquía de casos de uso en tres niveles, desde el nivel general al subnivel: esquema, objetivos del usuario y subfunciones.
Los objetivos de usuario se refieren a los objetivos que los actores clave esperan alcanzar al utilizar el sistema. Los objetivos del usuario son el foco de nuestra redacción de casos de uso. Los objetivos del usuario describen lo que el ejecutante principal "hace" a través del sistema y qué beneficios obtendrá el usuario después de hacerlo.
El objetivo del usuario debe ser que el ejecutor principal realice un proceso de obtención de beneficios del sistema. Por lo tanto, los objetivos que no se pueden lograr en una sola ejecución, o las necesidades de las que los usuarios no pueden obtener beneficios, no pueden denominarse objetivos de usuario.
Por ejemplo, al comprar un producto, pasan varios días desde que se realiza el pedido hasta la entrega urgente, por lo que no se puede considerar un objetivo del usuario. Por poner otro ejemplo, los usuarios no obtienen ningún beneficio después de iniciar sesión, por lo que no pueden denominarse objetivos de usuario. La operación del pedido del usuario se puede utilizar como objetivo del usuario.
La jerarquía de resumen puede contener múltiples objetivos de usuario. El ciclo de ejecución del objetivo de resumen es más largo que el ciclo de ejecución del objetivo de usuario, que puede ser de unos pocos días, meses o incluso más. Los objetivos resumidos tienen tres propósitos:
El nivel subfuncional es lo que lograrán los objetivos del usuario durante la ejecución. Por ejemplo, un inicio de sesión, una impresión de pedido, etc. También es posible que varios usuarios objetivos * * * utilicen una subfunción, como buscar productos, buscar pedidos, etc.
La existencia de casos de uso de subfunciones tiene como objetivo aumentar la legibilidad de los casos de uso objetivo del usuario. En el proceso de escritura real, no diseñe casos de uso de subfunciones a menos que sea absolutamente necesario.
Regla: Solo hay tres opciones en la jerarquía: Resumen, Objetivo del usuario y Subfunción.
Un caso de uso solo puede estar en uno de tres niveles: resumen, objetivo de usuario y subfunción.
Las condiciones previas son condiciones que esperamos que se cumplan antes de que se ejecute un caso de uso. Es posible que esta condición no se verifique ni se analice durante la redacción del caso de uso. Por ejemplo, "realizar un pedido" debe basarse en el requisito previo "el usuario ha iniciado sesión".
Regla: Una precondición debe ser una condición que esperamos que tenga éxito antes de que se ejecute el caso de uso.
Evita que se escriban condiciones innecesarias en condiciones previas. Por ejemplo, la cancelación de un pedido no depende del éxito del pedido del usuario. De hecho, los usuarios pueden cancelar pedidos fallidos (como errores de pago). Es necesario verificar las condiciones para el éxito del pedido en el caso de uso y tomar medidas en caso de falla.
La garantía mínima es asegurar que el caso de uso se ejecutará independientemente del éxito o el fracaso. Aunque, independientemente de si el caso de uso se ejecuta con éxito o no, siempre se ejecutará la garantía mínima. La garantía mínima tiene más que ver con la protección de intereses proporcionada a las personas relacionadas con el caso de uso cuando el caso de uso no se ejecuta. Puede haber múltiples garantías mínimas.
Un ejemplo común de garantía mínima es "el sistema registrará la ejecución del usuario". Incluso si falla la ejecución del caso de uso, las acciones del usuario se registrarán en el registro.
La garantía de éxito se refiere a la garantía de beneficio que los usuarios pueden obtener después de que el caso de uso se ejecute con éxito. Que se puedan garantizar los intereses del personal relevante es una condición para la ejecución exitosa de un caso de uso. Puede haber múltiples garantías de éxito.
Por ejemplo, en el caso de uso de realizar un pedido, el usuario debe asegurarse de que "el pedido se crea y se envía en segundo plano para su procesamiento".
El evento desencadenante se refiere a". el evento iniciado por el caso de uso y el caso de uso será desencadenado por Los eventos se ejecutan paso a paso.
Regla: Activar un evento es la primera acción para interactuar con el sistema.
Tomemos como ejemplo el caso de uso de usuarios que realizan pedidos. Una vez que el usuario decide comprar el producto, lo busca en el sistema y realiza un pedido. Entonces "el usuario decide comprar el producto" no se puede utilizar como evento desencadenante del caso de uso. De hecho, la interacción más sistemática del usuario comienza con la "búsqueda de bienes", por lo que "el usuario busca bienes" es el evento desencadenante del caso de uso.
Cuando hablamos de la interacción del usuario con un sistema, también debemos ser conscientes del alcance del sistema del que estamos hablando. Especialmente cuando el ejecutor principal no opera directamente el sistema de software, el alcance del sistema debe estar claramente definido. Por ejemplo, en el escenario de "el usuario llama al administrador de cuentas para realizar un pedido", el alcance de nuestro sistema no puede limitarse al alcance del sistema de software, es el alcance del sistema o el alcance de la empresa. Entonces, "el usuario llama al administrador de cuentas" es el primer paso para interactuar con nuestro sistema, por lo que puede ser un "evento desencadenante".
El principal escenario de éxito es un caso de uso que comienza con un evento desencadenante, se ejecuta paso a paso y termina con un conjunto de pasos que satisfacen los intereses del caso de uso.
El principal escenario de éxito debe incluir la siguiente información:
Debe haber algunas reglas simples para implementar estos pasos:
Regla: use sintaxis simple.
Utiliza estructuras gramaticales simples:
Por ejemplo:
Regla: Describe con precisión las transiciones entre los intérpretes.
Los pasos de ejecución deben describir con precisión el cambio entre ejecutores durante la ejecución de los pasos. Por ejemplo, "el usuario llama al representante del cliente", podemos saber que el paso se ha cambiado del usuario al representante del cliente.
Pero a veces puede no aparecer en la sentencia si el ejecutor lo tiene claro. Por ejemplo, "el usuario ingresa la contraseña", también podemos saber que el ejecutor de este paso ha cambiado del usuario al sistema. No tenemos que utilizar la descripción redundante "el usuario ingresa la contraseña en el sistema".
Regla: Describe pasos desde fuera del sistema.
No debe considerarse desde dentro del sistema, ni enteramente desde la perspectiva del sistema. En cambio, estos pasos deben describirse desde fuera del sistema.
Si los pasos se describen desde dentro del sistema, se pueden escribir como:
Si estos pasos se describen fuera del sistema, se expresan como:
Reglas: indican que el proceso avanza.
Algunos pequeños pasos solo pueden completar unas pocas tareas y, a veces, estas tareas no describen bien el progreso del proceso. Por ejemplo, "El usuario hizo clic en el botón Aceptar". Este paso no describe del todo el proceso de seguir adelante. El verdadero propósito del usuario es iniciar sesión en el sistema. Cuando el usuario inicia sesión en el sistema, los pasos del caso de uso pueden continuar ejecutándose.
Regla: Mostrar la intención del ejecutante, no la acción.
El ejecutor generalmente realiza una acción a través del sistema operativo y es fácil confundir la acción del usuario con la intención del ejecutor al describir casos de uso.
Por ejemplo:
1. El sistema requiere que el usuario ingrese información de identidad.
2. El usuario ingresa el nombre de usuario y contraseña.
3. El usuario hace clic en el botón "Aceptar".
4. El sistema confirma la información de identidad del usuario.
......
Demasiados casos de uso describen la interfaz operativa del sistema y las acciones del usuario, como "requerir que el usuario ingrese información de identidad", que no es solo una acción interactiva, sino también la intención del ejecutor.
Podemos reducir el número de pasos que describen las acciones del usuario y cambiar el ejemplo a:
Reglas: contienen un conjunto razonable de actividades.
Al describir los pasos, no es necesario incluir una actividad en cada paso. Si lo desea, algunas actividades se pueden combinar en un solo paso.
Por ejemplo:
Este paso también se puede describir en dos pasos:
La descripción del caso de uso es simple y efectiva y, a veces, no está limitada. a un método específico. De hecho, muchos equipos de desarrollo han formado sus propios estándares para escribir casos de uso.
Regla: Los pasos describen escenarios de éxito, no posibles fracasos.
Los pasos del escenario de éxito principal describen los pasos hacia el éxito. Por ejemplo:
Si los pasos están escritos así, continuaremos considerando "si el juicio es correcto..." y "si el juicio falla...". Sin embargo, los pasos fallidos no se reflejan en los pasos del escenario principal de éxito. Por lo tanto, es necesario cambiar los pasos a
¿Qué debo hacer si falla la verificación del sistema? Esta información se describe en la extensión. Se explicará en detalle a continuación y no se ampliará aquí.
Reglas: Se pueden añadir límites de tiempo cuando los pasos no se ejecutan de forma consecutiva.
En la mayoría de los casos, estos pasos son graduales. En cierto modo, se puede describir de la siguiente manera:
Regla: Un paso puede involucrar a varias personas relevantes.
En ocasiones necesitamos iniciar una acción de ejecución de un sistema a otro, la cual se puede escribir como:
Regla: Puedes repetir uno o más pasos.
En ocasiones los usuarios realizan uno o más pasos repetidamente, por lo que es necesario proporcionar alguna descripción de dichos pasos. Por ejemplo:
La extensión es una rama del escenario de éxito principal, que se refiere a las diferentes acciones que el escenario de éxito principal completará bajo algunas otras condiciones. Tenga en cuenta que se utiliza "extensión" en lugar de "excepción" o "error". De hecho, la extensión incluye dos situaciones posibles: éxito y fracaso. La lógica básica es que si el sistema... (detecta un incidente) cuando se ejecuta el escenario principal de éxito, entonces... (hace algo).
Los escenarios comunes donde las extensiones son posibles son los siguientes:
Después de que ocurren estos escenarios, debemos describir cómo se manejan estos escenarios en la extensión y luego regresar al escenario de éxito principal o salir del caso de uso.
La extensión es para el escenario de éxito principal, por lo que cuando escribimos la extensión, necesitamos usar números para representar la relación correspondiente de la extensión:
Los escenarios de éxito principales son como siguiente:
Expandir de la siguiente manera:
Si es una expansión que puede activarse con cada paso, se puede representar con "*", como por ejemplo:
O si algunos pasos desencadenan * * * condiciones, puede agregar Representado por pasos, como:
Regla: describe condiciones extendidas desde la perspectiva de la detección del sistema.
Las condiciones extendidas deben ser condiciones que el sistema pueda detectar, no lo que sucedió. Por ejemplo, si un usuario olvida su contraseña, es imposible que el sistema detecte que el usuario tiene una contraseña o por otros motivos. Desde la perspectiva de la detección del sistema, el sistema solo puede detectar que el usuario ingresó una contraseña incorrecta o que se agotó el tiempo de espera para la entrada del usuario.
Normas: Condiciones de ampliación de fusiones racionalizadas.
De hecho, no es necesario enumerar todos los escenarios posibles de condiciones extendidas. Dentro de un rango razonable, podemos combinar algunas condiciones extendidas en elementos equivalentes. Hay dos criterios para juzgar la equivalencia:
Por ejemplo, en el paso de ingreso de la contraseña, el usuario puede olvidar ingresar la contraseña incorrectamente, o ingresar manualmente el error u otras posibilidades, estas son situaciones que no se pueden detectar. por el sistema. Primero, traduzca estas condiciones en algo que el sistema pueda probar: La contraseña se ingresó incorrectamente. Después de la conversión, todas las condiciones se pueden combinar en una.
Echemos un vistazo a las condiciones que el sistema puede completar, como entrada de contraseña incorrecta, nombre de usuario incorrecto, nombre de usuario inexistente, etc. El procesamiento de nuestro sistema es "avisar que el nombre de usuario o contraseña es incorrecto o no existe". En este momento, puede combinar las condiciones en "El sistema detecta que el nombre de usuario o la contraseña se ingresaron incorrectamente".
En otro caso, si la extensión se ha descrito completamente en casos de uso de bajo nivel (como el nivel subfuncional), entonces la descripción redundante puede no repetirse en casos de uso de alto nivel (como nivel de objetivo del usuario). Por ejemplo, en el caso de uso de nivel subfuncional "Guardar datos", se han descrito completamente varias condiciones extendidas que pueden ocurrir durante el proceso de guardar, por lo que no es necesario describirlas en su caso de uso principal.
-
Los casos de uso también se pueden representar mediante diagramas de casos de uso. Este artículo analiza principalmente la descripción de un requisito a través del enfoque y la composición de los casos de uso, por lo que no presentaré diagramas de casos de uso. Los lectores interesados pueden consultar otros materiales para su propia comprensión.
En el mundo actual, donde se recomienda cada vez más el desarrollo ágil, los casos de uso, un modelo de expresión y análisis de requisitos relativamente “pesados”, se utilizan cada vez menos. Cuando estudiamos el enfoque y los métodos de análisis de los casos de uso, muchas de sus ideas aún pueden usarse como referencia en nuestro análisis de requisitos diario.