Los casos de uso son una forma de describir cómo un actor interactúa con un sistema para alcanzar un objetivo. Dentro de los requerimientos, ayudan a organizar funciones desde la perspectiva de quienes usan el sistema o se comunican con él.
Un caso de uso no es solo un diagrama. También puede incluir una descripción textual con objetivo, actores, precondiciones, flujo principal, flujos alternativos, excepciones y resultado esperado.
En este tema veremos una introducción a los casos de uso y su relación con requerimientos, sin profundizar en todos los detalles que corresponden a un curso específico de casos de uso.
Un caso de uso describe una interacción entre un actor y el sistema para lograr un resultado de valor.
Ejemplos de casos de uso:
Un actor es una persona, sistema externo, dispositivo u organización que interactúa con el sistema. El actor está fuera del sistema, pero participa en el logro de un objetivo.
Ejemplos:
El actor no siempre es una persona. Puede ser otro sistema que envía o recibe información.
Todo caso de uso debe tener un objetivo claro. El objetivo indica qué resultado busca obtener el actor.
| Actor | Caso de uso | Objetivo |
|---|---|---|
| Cliente | Consultar estado de reclamo | Conocer el avance del reclamo sin llamar a atención al cliente. |
| Vendedor | Registrar pedido | Guardar una solicitud de compra de un cliente. |
| Supervisor | Aprobar descuento | Autorizar una condición comercial fuera del límite habitual. |
Los casos de uso se relacionan con requerimientos funcionales porque describen comportamientos que el sistema debe ofrecer.
Un requerimiento funcional puede expresarse de forma breve:
Un caso de uso puede ampliar esa función indicando actor, objetivo, pasos, reglas y excepciones. Por eso, el caso de uso es útil cuando una función requiere más detalle de interacción.
Una especificación simple de caso de uso puede incluir:
No siempre hace falta usar todos los campos. El nivel de detalle debe responder a la complejidad del caso.
El flujo principal describe la interacción normal entre actor y sistema.
Ejemplo para consultar reclamo:
El flujo debe mostrar responsabilidades del actor y del sistema de manera clara.
Los casos de uso también deben contemplar variantes y errores.
Para la consulta de reclamo:
Esto evita especificar solo el caso ideal.
Las precondiciones indican qué debe cumplirse antes de iniciar el caso de uso. Las postcondiciones indican qué debe quedar cumplido al finalizar.
Ejemplo para registrar pedido:
Estas condiciones ayudan a delimitar el comportamiento esperado.
Los casos de uso suelen representarse mediante diagramas, especialmente en UML. Un diagrama muestra actores, casos de uso y relaciones generales.
Sin embargo, el diagrama por sí solo no explica el detalle de los flujos. Por ejemplo, un óvalo llamado "Registrar pedido" no dice qué datos se ingresan, qué validaciones existen ni qué ocurre si no hay stock.
Historias de usuario y casos de uso pueden convivir. No son exactamente lo mismo.
| Historia de usuario | Caso de uso |
|---|---|
| Expresa una necesidad breve desde un rol y un beneficio. | Describe una interacción más estructurada entre actor y sistema. |
| Es útil para conversaciones ágiles y priorización. | Es útil para detallar flujos, alternativas y excepciones. |
| Necesita criterios de aceptación para completarse. | Incluye flujo principal, alternativos, precondiciones y postcondiciones. |
Un caso de uso puede incluir varios escenarios. El flujo principal es un escenario exitoso típico. Cada flujo alternativo o excepción puede verse como otro escenario.
Ejemplo:
Esta relación ayuda a derivar pruebas y criterios de aceptación.
No todos los casos de uso requieren una especificación extensa. El detalle depende de la complejidad y el riesgo.
Conviene detallar más cuando:
En funciones simples, una historia con criterios de aceptación puede ser suficiente.
| Nombre | Registrar reclamo |
|---|---|
| Actor principal | Operador de atención |
| Objetivo | Registrar formalmente un reclamo recibido de un cliente. |
| Precondición | El operador inició sesión y tiene permiso para registrar reclamos. |
| Flujo principal | El operador identifica al cliente, ingresa motivo y descripción, selecciona canal de ingreso y confirma el registro. El sistema asigna número único y estado abierto. |
| Alternativo | Si el cliente no existe, el operador puede registrar datos mínimos del cliente antes de crear el reclamo. |
| Excepción | Si falta motivo o descripción, el sistema no permite guardar el reclamo. |
| Postcondición | El reclamo queda registrado y disponible para asignación. |
Los casos de uso son una buena base para pruebas de aceptación, porque describen flujos que pueden verificarse.
Del caso de uso "Registrar reclamo" pueden derivarse pruebas como:
Esto mejora la trazabilidad entre requerimientos y verificación.
Los casos de uso son útiles, pero no cubren todo.
Sus límites incluyen:
Deben usarse cuando aportan claridad, no por obligación documental.
Al introducir casos de uso, suelen aparecer estos errores:
Algunas buenas prácticas son:
Los casos de uso son una herramienta útil para organizar y describir interacciones entre actores y sistema. Ayudan a comprender objetivos, flujos, variantes y excepciones dentro de los requerimientos funcionales.
En este curso los presentamos como una introducción, porque su estudio detallado requiere un tratamiento propio. Lo importante aquí es entender cuándo ayudan y cómo se conectan con requerimientos, escenarios y pruebas.
En el próximo tema comenzaremos el análisis de requerimientos: clasificación, refinamiento y consistencia de la información obtenida durante la elicitación.