Guía para La Redacción de Casos de Uso

Guía para la redacción de casos de uso
Tabla de contenidos
1. 1.Descripción
1. 1.1.Introducción
2. 2.Características
1. 2.1.Características
2. 2.2.Ventajas
3. 2.3.Limitaciones
3. 3.Buenas prácticas y recomendaciones de uso
4. 4.Ejemplos
5. 5.Enlaces externos
 Área: Ingeniería de requisitos
 Carácter del recurso: Recomendado
Descripción
Introducción
En ingeniería del software, un caso de uso es una técnica para la captura de requisitos potenciales de
un nuevo sistema o una actualización de software. Cada caso de uso proporciona uno o más
escenarios que indican cómo debería interactuar el sistema con el usuario o con otro sistema para
conseguir un objetivo específico. Normalmente, en los casos de usos se evita el empleo de jergas
técnicas, prefiriendo en su lugar un lenguaje más cercano al usuario final. En ocasiones, se utiliza a
usuarios sin experiencia junto a los analistas para el desarrollo de casos de uso.
En otras palabras, un caso de uso es una secuencia de interacciones que se desarrollarán entre un
sistema y sus actores en respuesta a un evento que inicia un actor principal sobre el propio sistema.
Los diagramas de casos de uso sirven para especificar la comunicación y el comportamiento de un
sistema mediante su interacción con los usuarios y/u otros sistemas. O lo que es igual, un diagrama
que muestra la relación entre los actores y los casos de uso en un sistema. Una relación es una
conexión entre los elementos del modelo, por ejemplo la especialización y la generalización son
relaciones. Los diagramas de casos de uso se utilizan para ilustrar los requerimientos del sistema al
mostrar cómo reacciona a eventos que se producen en su ámbito o en él mismo
Características
Características
Los casos de uso evitan típicamente la jerga técnica, prefiriendo la lengua del usuario final o del
experto del campo del saber al que se va a aplicar. Los casos del uso son a menudo elaborados en
colaboración por los analistas de requerimientos y los clientes.
Cada caso de uso se centra en describir cómo alcanzar una única meta o tarea de negocio. Desde una
perspectiva tradicional de la ingeniería de software, un caso de uso describe una característica del
sistema. Para la mayoría de proyectos de software, esto significa que quizás a veces es necesario
especificar diez o centenares de casos de uso para definir completamente el nuevo sistema. El grado
de la formalidad de un proyecto particular del software y de la etapa del proyecto influenciará el nivel
del detalle requerido en cada caso de uso.
Los casos de uso pretenden ser herramientas simples para describir el comportamiento del software o
de los sistemas. Un caso de uso contiene una descripción textual de todas las maneras que los actores
previstos podrían trabajar con el software o el sistema. Los casos de uso no describen ninguna
funcionalidad interna (oculta al exterior) del sistema, ni explican cómo se implementará. Simplemente
muestran los pasos que el actor sigue para realizar una tarea.
Un caso de uso debe:
 describir una tarea del negocio que sirva a una meta de negocio
 tener un nivel apropiado del detalle
 ser bastante sencillo como que un desarrollador lo elabore en un único lanzamiento
Situaciones que pueden darse:
 Un actor se comunica con un caso de uso (si se trata de un actor primario la comunicación la
iniciará el actor, en cambio si es secundario, el sistema será el que inicie la comunicación).
 Un caso de uso extiende otro caso de uso.
 Un caso de uso utiliza otro caso de uso.
Ventajas
La técnica de caso de uso tiene éxito en sistemas interactivos, ya que expresa la intención que tiene el
actor (su usuario) al hacer uso del sistema.
Como técnica de extracción de requerimiento permite que el analista se centre en las necesidades del
usuario, qué espera éste lograr al utilizar el sistema, evitando que la gente especializada en
informática dirija la funcionalidad del nuevo sistema basándose solamente en criterios tecnológicos.
A su vez, durante la extracción (elicitation en inglés), el analista se concentra en las tareas centrales
del usuario describiendo por lo tanto los casos de uso que mayor valor aportan al negocio. Esto facilita
luego la priorización del requerimiento.
Limitaciones
Los casos de uso pueden ser útiles para establecer requisitos de comportamiento, pero no establecen
completamente los requisitos funcionales ni permiten determinar los requisitos no funcionales. Los
casos de uso deben complementarse con información adicional como reglas de negocio, requisitos no
funcionales, diccionario de datos que complementen los requerimientos del sistema. Sin embargo la
ingeniería del funcionamiento especifica que cada caso crítico del uso debe tener un requisito no
funcional centrado en el funcionamiento asociado.
Buenas prácticas y recomendaciones de uso

Los casos de uso, como el resto de los requisitos, deben tener una redacción cuidada para evitar
problemas de interpretación. En general, algunas recomendaciones a tener en cuenta son:
 El caso de uso debe describir qué debe hacer el sistema a desarrollar en su interacción con los
actores y no cómo debe hacerlo. Es decir, debe describir sólo comportamiento observable
externamente, sin entrar en la funcionalidad interna del sistema.
 El nombre del caso de uso debe ilustrar el objetivo que pretende alcanzar el actor al
realizarlo.
 El caso de uso debe describir interacciones con los actores sin hacer referencias explícitas a
elementos concretos de la interfaz de usuario del sistema a desarrollar.
 La invocación de unos casos de uso desde otros casos de uso (lo que se conoce como
inclusión, o extensión si es condicional, en UML), sólo debe usarse como un mecanismo para evitar
repetir una determinada secuencia de pasos que se repite en varios casos de uso. Nunca debe usarse
para expresar posibles menús de la interfaz de usuario.
 Se debe ser cuidadoso al usar estructuras condicionales en la descripción del caso de uso, ya
que los clientes y usuarios no suelen estar familiarizados con este tipo de estructuras, especialmente
si son complejas.
 Se debe intentar que todos los casos de uso de una misma ERS estén descritos al mismo nivel
de detalle.
 En los diagramas de casos de uso, debe evitarse que se crucen las líneas que unen los actores
a los casos de uso.
Ejemplos
A continuación se ofrece un caso de uso ejemplo, elaborado para MADEJA

Guía para La Redacción de Casos de Uso

Cargado por

Copyright:

Formatos disponibles

Guía para La Redacción de Casos de Uso

Cargado por

Información del documento

Descripción original:

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Guía para La Redacción de Casos de Uso

Cargado por

Copyright:

Formatos disponibles

Guía para la redacción de casos de uso

 Carácter del recurso: Recomendado

Buenas prácticas y recomendaciones de uso

También podría gustarte