DOCUMENTAR CASOS DE USO.

1. ENCABEZADO
1.1. Identificador del caso de uso
Cada caso de uso tiene un único identificador numérico, también se pueden agrupar de
forma jerárquica usando otras notaciones como X.Y o combinar un código numérico con
un código alfabético como RF1, RNF1, etc.
1.2. Nombre del caso de uso
El nombre debe ser conciso, debe estar orientado al resultado del caso de uso. Debe
reflejar las tareas que el usuario necesita llevar a cabo para usar el sistema. El nombre
debe llevar un verbo pues es una acción. Ejemplo.
1. Generar orden de compra
2. Registrar PIN.
1.3. Registro Histórico
1.3.1 Creado Por.
En esa parte se pone el nombre de la persona “Autor” de ese caso de uso.
1.3.2 Fecha de creación
En esta parte se pone la fecha de creación inicial del caso de uso.
1.3.3 Actualizado Por.
Se pone el nombre de la persona que realizo la última actualización, también se
pueden conservar los nombres de las personas que actualizaron previamente el
caso de uso.
1.3.4 Fecha de actualización.
Se escribe la fecha de la última actualización.
2. DEFINICIÓN DE LOS CASOS DE USO.
2.1. Actores
En esta parte se ubican los nombres de los actores implicados en el caso de uso, tenga
en cuenta que en un caso de uso o un conjunto de ellos pueden interactuar uno o
muchos actores.
2.2. Trigger o Disparador.
Identifica el evento que inicia el caso de uso. Podría ser un evento de negocios externos
o de sucesos del sistema que hace que el caso de uso pueda empezar, también podría
ser el primer paso en el flujo normal.
2.3. Descripción
Proporcionar una breve descripción de la razón y los resultados del caso de uso, o una
descripción de alto nivel de la secuencia de acciones y los resultados de la ejecución del
caso de uso.
2.4. Precondiciones
Lista todas las actividades que deben ser tenidas en cuenta o todas las condiciones que
deben ser cumplidas, antes de que el caso de uso empiece. Las precondiciones deben
ser numeradas.
1. 1. El usuario debe autenticar su identidad.
2.5. Postcondiciones
Describen el estado del sistema una vez terminada la ejecución del caso de uso. Deben
ir numeradas.
1. El articulo queda registrado en la base de datos.
2. El precio del artículo queda actualizado en la base de datos.
2.6. Escenarios
2.6.1 Flujo norma de eventos.
Provee una descripción detallada de las acciones del usuario y las respuestas del
sistema durante la ejecución normal del caso de uso, son las condiciones
 esperadas cuando el caso de uso se ejecuta sin contratiempos, Esta secuencia de
diálogo en última instancia conduce a lograr el objetivo expuesto en el nombre y la
descripción de casos de uso. Esta descripción puede ser escrita como una
respuesta a la pregunta hipotética: ¿Cómo se pueden hacer cumplir las tareas que
sugiere el nombre del caso de uso?. Para lograr una buena conformación del flujo
normal se recomienda numerar las acciones de los usuarios y las respuestas del
sistema a manera de pasos para llegar a la meta del caso de uso.
2.6.2 Flujos alternos.
Documenta los escenarios que pueden ocurrir cuando el caso de uso no puede
ser ejecutado completamente. Se enumeran igual que el flujo normal de eventos
con las acciones del usuario y las respuestas del sistema.
2.7. Puntos de extensión.
Es donde se establece en qué momento, del hilo de ejecución del caso de uso se va a
extender a otro.
2.8. Excepciones.
Describir las condiciones de error que podrían ocurrir durante la ejecución del caso de
uso y define cómo el sistema es responder a esas condiciones. Además, se describe
cómo el sistema ha de responder si la ejecución de casos de uso falla por alguna razón
imprevista. Las excepciones se pueden identificar en términos de una 4 tupla, de la
forma “X.Y.E.Z”, donde X es el identificador del caso de uso, Y indica el flujo normal si
es (0) o alternativo si es mayor que (0), E indica excepción y Z es el numero de
secuencia de las excepciones. Por ejemplo. 4.0.E.1 significa que el caso de uso 4, en su
flujo normal presenta una excepción y que dicha excepción es la número 1.
2.9. Includes
Lista de todos los casos de uso de que son incluidos, llamados por el presente caso de
uso.
2.10. Prioridad.
En esta parte se indica la prioridad relativa de la implementación de la funcionalidad del
caso de uso, puede usar una escala de 3 valores como alto, medio y bajo aun cuando
usar escalas más amplias podría ayudar a mejorar la priorización y trazabilidad de los
casos de uso.
2.11. Frecuencia de uso
Estimar el número de veces en que el caso de uso se llevará a cabo por los actores,
debe indicarse alguna unidad de tiempo.
2.12. Reglas de negocio.
Lista todas las reglas de negocio que influencian el caso de uso.
2.13. Requerimientos especiales
Se incluyen los requisitos adicionales, tales como los requisitos no funcionales que
pueden necesitar para el caso de uso, que se abordarán durante el diseño o
implementación de él. Estos pueden incluir requisitos de rendimiento u otros atributos de
calidad.
2.14. Supuestos
Liste las suposiciones que se hicieron en el análisis de requerimientos que llevaron a
plantear el caso de uso.
2.15. Notas y pendientes.
Lista de cualquier comentario adicional sobre el caso de uso o cualquier cuestión que
quedara abierta o por determinar que debe ser resuelta. Identificar quién va a resolver
cada una, la fecha de vencimiento, y cuál será el resultado esperado.
Es donde se establece en qué momento, del hilo de ejecución del caso de uso se va a
extender a otro. Por causas extraordinarias.
 PLANTILLA PARA DOCUMENTACIÓN DE CASOS DE USO.
A continuación se presenta una plantilla base para la documentación de casos de uso.

EJEMPLO DE REQUERIMIENTO, DIAGRAMA DE CASO DE USO Y

DOCUMENTACIÓN.

Ejemplo de requerimiento
Requerimiento: el sistema debe registrar pagos con los siguientes medios de pago efectivo,
cheque, tarjeta debito y tarjeta crédito.
Ejemplo de plantilla para documentar caso de uso que refleja el requerimiento.