<Nombre de proyecto>

Especificación de caso de uso: <Nombre de caso de uso>

 

Versión <1.0>

 

[Nota: la siguiente plantilla se proporciona para utilizarla con Rational Unified Process. Se incluye texto encerrado entre corchetes y que se muestra en cursivas azules (style=InfoBlue) para proporcionar orientación al autor y debe suprimirse antes de publicar el documento. Un párrafo que se entre después de este estilo se establecerá automáticamente como normal (style=Body Text).]

 

 

 


Historial de revisiones

Fecha

Versión

Descripción

Autor

<dd/mmm/aa>

<x.x>

<detalles>

<nombre>

 

 

 

 

 

 

 

 

 

 

 

 

 


Tabla de contenido

1.          Nombre de caso de uso 

1.1      Breve descripción     

2.          Flujo de sucesos

2.1      Flujo básico     

2.2      Flujos alternativos     

2.2.1       < Primer flujo alternativo >      

2.2.2       < Segundo flujo alternativo >      

3.          Requisitos especiales

3.1      < Primer requisito especial >     

4.          Condiciones previas    

4.1      < Condición previa uno >     

5.          Condiciones posteriores    

5.1      < Condición posterior uno >     

6.          Puntos de ampliación

6.1      <Nombre de punto de ampliación>     


Especificación de caso de uso: <Nombre de caso de uso>

1.                  Nombre de caso de uso

[La siguiente plantilla se proporciona para una especificación de caso de uso, que contiene las propiedades textuales del caso de uso.  Este documento se utiliza con una herramienta de gestión de requisitos, como Rational RequisitePro, para especificar y marcar los requisitos dentro de las propiedades de caso de uso.

Los diagramas de caso de uso se pueden desarrollar en una herramienta de modelado visual, como Rational Rose.  Se puede generar un informe de caso de uso (con todas las propiedades) con Rational SoDA. Para obtener más información, consulte las guías de la herramienta en Rational Unified Process.]

1.1               Descripción breve

[La descripción transmite brevemente el propósito del caso de uso.  Un único párrafo será suficiente para esta descripción.]

2.                  Flujo de sucesos

2.1               Flujo básico

[Este caso de uso se inicia cuando el actor hace algo.  Un actor siempre inicia los casos de uso.  El caso de uso describe lo que hace el actor y lo que hace el sistema en respuesta.  Es necesario expresarlo en forma de un diálogo entre el actor y el sistema.

El caso de uso describe lo que sucede dentro del sistema, pero no cómo ni porqué.  Si se intercambia información, sea específico sobre lo que se pasa de un lado a otro.  Por ejemplo, no es muy clarificador decir que el actor entra información del cliente. Es mejor decir que el actor entra el nombre y la dirección del cliente. Un Glosario de términos es con frecuencia útil para mantener manejable la complejidad del caso de uso. Es posible que desee definir objetos como la información del cliente ahí para evitar que el caso de uso se inunde con detalles.

Las alternativas simples se pueden presentar en el texto del caso de uso. Si sólo ocupa unas cuantas frases describir lo que sucede cuando existe una alternativa, hágalo directamente en la sección Flujo de sucesos.  Si el flujo alternativo es más complejo, utilice una sección separada para describirlo. Por ejemplo, una subsección Flujo alternativo explica cómo describir alternativas más complejas.

A veces una imagen vale más que mil palabras, aunque no existe ningún sustituto a una prosa clara y ordenada. Si mejora la claridad, no dude en pegar en el caso de uso imágenes gráficas de las interfaces de usuario, flujos de proceso u otras imágenes. Si un diagrama de flujo es útil para presentar un proceso de decisión complejo, no deje de utilizarlo.  De forma similar, para comportamiento dependiente del estado, un diagrama de transición de estado a menudo clarifica el comportamiento de un sistema mejor que muchas páginas de texto. Utilice el soporte de presentación correcto para el problema, pero tenga cuidado de no utilizar terminología, anotaciones o figuras que es posible que la audiencia no entienda.  Recuerde que el propósito es clarificar, no oscurecer.]

2.2               Flujos alternativos

2.2.1          < Primer flujo alternativo >

[Las alternativas más complejas se describen en una sección separada, a la que se hace referencia en la subsección Flujo básico de la sección Flujo de sucesos.  Piense en las subsecciones Flujo alternativo como comportamiento alternativo - cada flujo alternativo representa comportamiento alternativo normalmente debido a excepciones que se producen en el flujo principal. Pueden ser necesarios para describir los sucesos asociados con el comportamiento alternativo. Cuando finaliza un flujo alternativo, se reanudan los sucesos del flujo principal de sucesos.]

2.2.1.1     < Subflujo alternativo >

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

2.2.2          < Segundo flujo alternativo >

[Puede que exista, y muy probablemente existirá, una serie de flujos alternativos en un caso de uso. Mantenga separados los flujos alternativos a fin de mejorar la claridad. La utilización de flujos alternativos mejora la legibilidad del caso de uso. Los flujos alternativos también impiden que los casos de uso se descompongan en jerarquías de casos de uso. Tenga en cuenta que los casos de uso son simplemente descripciones textuales y que su  propósito principal es documentar el comportamiento de un sistema de una forma clara, concisa y comprensible.]

3.                  Requisitos especiales

[Un requisito especial es normalmente un requisito no funcional que es específico de un caso de uso, pero no se especifica fácilmente o naturalmente en el texto del flujo de sucesos del caso de uso. Los ejemplos de requisitos especiales incluyen los requisitos legales o normativos, los estándares de aplicación y atributos de calidad del sistema que se creará, que incluyen los requisitos de utilización, fiabilidad, rendimiento o capacidad de soporte. Adicionalmente, se deben capturar en esta sección otros requisitos, como por ejemplo requisitos de sistemas operativos y entornos, de compatibilidad y restricciones de diseño.]

3.1               < Primer requisito especial >

 

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 realice un caso de uso.]

4.1               < Condición previa uno >

 

5.                  Condiciones posteriores

[Una condición posterior de un caso de uso es una lista de estados posibles en los que puede estar el sistema inmediatamente después de que haya finalizado un caso de uso.]

5.1               < Condición posterior uno >

 

6.                  Puntos de ampliación

[Puntos de ampliación del caso de uso.]

6.1               <Nombre del punto de ampliación>

[Definición de la ubicación del punto de ampliación en el flujo de sucesos.]