Plantilla Casos Uso
Plantilla Casos Uso
Plantilla Casos Uso
para
<Projecto>
Preparado by <author>
<organización>
Control de cambios
Nombre Fecha Motivo del cambio Versión
Copyright © 2004 by Karl E. Wiegers. Permission is granted to use, modify, and distribute this document.
Casos de uso para <project> Página 1
3.1. Actores
Un actor es la persona o entidad externa al sistema de software que especifica quién interactúa
recíprocamente con el sistema y ejecuta casos del uso para completar las tareas. Diversos actores a menudo
corresponden a diversas clases de usuarios, o roles, identificando a la comunidad cliente que utilizará el
producto. Nombre el actor que iniciará este caso del uso y a cualquier otro actor que participe para
completar el caso del uso.
Casos de uso para <project> Página 2
3.3. Description
Suministre una breve descripción de la razón y resultados de este caso de uso, o una descripción de alto
nivel de la secuencia de acciones y del resultado de ejecutar el caso del uso.
3.4. Pre-condiciones
Liste cualquier actividad que ser llevada a cabo, o cualquier condición verdadera, que exista antes que el
caso de uso inicie. Enumere cada pre-condición. Ejemplos:
1. La identidad del usuario ha sido autenticada
2. El usuario del computador tiene suficiente memoria disponible lanzar la tarea.
3.5. Post-condiciones
Describe el estado del sistema tras la finalización de la ejecución del caso de uso. Enumere cada post-
condición.
1. El documento final contiene únicamente tags validos de HTML5
2. El precio del ítem en la base de datos ha sido actualizado al Nuevo valor ingresado.
3.8. Excepciones
Describa cualquier condición de error anticipada que pudiera ocurrir durante la ejecución del caso de uso y
defina cómo el sistema debe responder a dichas condiciones. También, describa cómo el sistema debe
responder si la ejecución del caso del uso falla por una cierta razón inesperada. Si los resultados del caso
de uso terminan en un cambio permanente en el estado de una base de datos o del mundo exterior, se debe
indicar como el cambio puede ser deshecho, terminado correctamente, terminado parcialmente con un
estado conocido, o termina en un estado indeterminado como resultado de la excepción ocurrida. Enumere
cada flujo alternativo en la forma “X.Y.E.Z”, donde “X” corresponde a la identificación del caso del uso,
“Y” indica el flujo normal (0) o alternativo (>0) durante la cual esta excepción podría ocurrir, “E” indica
Casos de uso para <project> Página 3
una excepción, y “Z” es un número de serie para las excepciones. Por ejemplo “5.0.E.2” indicaría la
segunda excepción para el flujo normal del caso de uso número 5.
3.9. Includes
Incluya cualquier otro caso del uso que sea incluido (“invocado") por este caso de uso. La funcionalidad
común que aparece en múltiples casos de uso se puede separar en un caso de uso separado para que sea
incluidos (“invocado”) por los casos que necesiten de esa funcionalidad común.
3.10. Prioridad
Indique la prioridad relativa de implementar la funcionalidad requerida para permitir que este caso de uso
sea ejecutado. El esquema de la prioridad usado debe ser lo mismo que es usado en la especificación de
requisitos del software.
Estime que el número de veces que este caso de uso deberá ser ejecutado por los actores para cierta unidad
de tiempo apropiada.
3.14. Supuestos
Enumere cualquier supuesto que pudo haber sido hecho en el análisis que llevó a cabo para aceptar este
caso de uso en la descripción de producto y a escribir la descripción del caso del uso.
Actores:
Descripción:
Activador del caso de uso:
Pre-condiciones: 1.
Post-condiciones: 1.
Flujo Normal: Paso ACTOR SISTEMA
1.
2.
3.
4.
5.
6.
7.
8.
Prioridad:
Frecuencia de Uso:
Reglas del negocio:
Requerimientos especiales:
Nro.
Supuestos:
1.
Notas y Problemas: