ESPECIFICACIÓN DE CASO DE USO

[escriba nombre del caso de uso]

Revisiones
Versión Fecha Descripción Autor
1.0

2
Tabla de Contenidos
1. Caso de Uso 4
1.1 Descripción breve 4

2. Flujo de Eventos 4
2.1 Flujo básico 4
2.2 Flujos alternativos 4
2.2.1 Primer flujo alternativo 4
2.2.1.1 Un sub flujo alternativo 4
2.2.2 Segundo flujo alternativo 5

3. Requerimientos Especiales 5
3.1 Primer Requerimiento Especial 5
3.2 Segundo Requerimiento Especial 5

4. Condiciones Previas 5
4.1 Condición Previa 1 5
4.2 Condición Previa 2 5

5. Condiciones Posteriores 5
5.1 Condición Posterior 1 5
5.2 Condición Posterior 2 5

6. Puntos de Extensión 5
6.1 Nombre del Punto de Extensión 6

3
1. Caso de Uso
1.1 Descripción breve
[Describir brevemente el propósito del caso de uso en un único párrafo. Se puede incorporar uno o más
diagramas UML para identificar los flujos de manera global]

[Diagrama UML global de apoyo]

2. Flujo de Eventos
2.1 Flujo básico
[El caso de uso comienza cuando el actor hace algo. Un actor siempre inicia Casos de uso. El caso de uso
debe describir qué hace el actor y qué hace el sistema en respuesta. Debe redactarse en forma de un
diálogo entre el actor y el sistema.
El caso de uso debe describir lo que sucede dentro del sistema, pero no cómo o por qué. Si se intercambia
información, sea específico acerca de lo que se transmite de ida y vuelta. Por ejemplo, no es muy
esclarecedor decir que el Actor ingresa la información del cliente. Es mejor decir que el Actor ingresa el
nombre y la dirección del cliente. Un Glosario de términos suele ser útil para mantener la complejidad del
caso de uso manejable; es posible que desee definir aspectos como la información del cliente allí para
evitar que el caso de uso se ahogue en los detalles.
Se pueden presentar alternativas simples dentro del texto del caso de uso. Si solo se requieren unas pocas
frases para describir lo que sucede cuando hay una alternativa, hágalo directamente dentro de la sección
Flujo de eventos. Si los flujos alternativos son más complejos, use una sección separada para describirlos.
Por ejemplo, una subsección de flujo alternativo explica cómo describir alternativas más complejas.
Una imagen a veces vale más que mil palabras, aunque no hay sustituto para una prosa limpia y clara. Si
mejora la claridad, puede pegar representaciones gráficas de interfaces de usuario, flujos de procesos u
otras figuras en el caso de uso. Si un diagrama de flujo es útil para presentar un proceso de decisión
complejo, utilícelo. De manera similar, para el comportamiento dependiente del estado, un diagrama de
transición de estado a menudo aclara el comportamiento de un sistema mejor que las páginas y páginas
de texto. Utilice el medio de presentación adecuado para su problema, pero tenga cuidado con el uso de
terminología, anotaciones o figuras que su audiencia puede no entender. Recuerde que su propósito es
aclarar, no oscurecer.
Alternativamente, los diagramas de actividad UML se pueden usar para documentar el flujo. Un ejemplo
teórico se muestra a continuación.]

[ Diagrama(s) UML de apoyo]

2.2 Flujos alternativos

2.2.1 Primer flujo alternativo
[Piense en las subsecciones de flujo alternativo como el comportamiento alternativo: cada flujo
alternativo representa un comportamiento alternativo, muchas veces debido a excepciones que ocurren
en el flujo principal. Pueden ser el tiempo que sea necesario para describir los eventos asociados con el
comportamiento alternativo. Cuando termina un flujo alternativo, los eventos del flujo principal de
eventos se reanudan a menos que se indique lo contrario.]

2.2.1.1 Un sub flujo alternativo

[Los flujos alternativos pueden, a su vez, desglosarse en subsecciones si mejora la claridad.]

4
2.2.2 Segundo flujo alternativo
[Puede haber, y lo más probable será, una cantidad de flujos alternativos en un caso de uso. Mantenga
cada alternativa separada para mejorar la claridad. El uso de flujos alternativos mejora la legibilidad del
caso de uso, así como también evita que los casos de uso se descompongan en jerarquías de casos de uso.
Tenga en cuenta que los casos de uso son solo descripciones textuales, y su propósito principal es
documentar el comportamiento de un sistema de una manera clara, concisa y comprensible.]

3. Requerimientos Especiales
[Un requisito especial es típicamente un requisito no funcional que es específico de un caso de uso, pero
no se especifica de forma fácil o natural en el texto del flujo de eventos del caso de uso. Entre los
ejemplos de requisitos especiales se incluyen los requisitos legales y reglamentarios, los estándares de
aplicación y los atributos de calidad del sistema que se construirá, incluidos los requisitos de usabilidad,
fiabilidad, rendimiento o compatibilidad. Además, otros requisitos, tales como sistemas operativos y
entornos, requisitos de compatibilidad y restricciones de diseño, deben ser capturados en esta sección.]
3.1 Primer Requerimiento Especial
[Redactar aquí]

3.2 Segundo Requerimiento Especial

[Redactar aquí]

4. Condiciones Previas
[Una condición previa de un caso de uso es el estado del sistema que debe estar presente antes de que se
lleve a cabo un caso de uso.]
4.1 Condición Previa 1
[Redactar aquí]

4.2 Condición Previa 2

[Redactar aquí]

5. Condiciones Posteriores
[Una condición posterior a un caso de uso es una lista de posibles estados en los que el sistema puede
estar inmediatamente después de que un caso de uso haya finalizado].
5.1 Condición Posterior 1
[Redactar aquí]

5.2 Condición Posterior 2

[Redactar aquí]

5
6. Puntos de Extensión
[Puntos de Extensión del caso de uso]
6.1 Nombre del Punto de Extensión
[Definición de la ubicación del punto de extensión en el flujo de eventos.]