4.

Casos de uso y requisitos funcionales

Los casos de uso son requisitos funcionales y no funcionales que indican
que har el sistema. Generalmente su idea clave es reducir la importancia
o el uso de listas de caractersticas detalladas al estilo antiguo y escribir
casos de uso solo para los requisitos funcionales.
Los casos de uso son documentos de textos, no diagramas. El modelado
de casos de uso es una accin de escribir texto, no de dibujar. Sin
embargo, UML define un diagrama de casos de uso para ilustrar los
nombres, actores y relaciones del mismo.
Tipos de formalidad
Los casos de uso se describen con formatos diferentes, dependiendo de la
necesidad. A dems del tipo de visibilidad, los casos de uso se escriben
con varios grados de formalidad:
Breve: resumen conciso de un prrafo, normalmente del escenario
principal con xito. Ejemplo: procesar venta.
Informal: formato de prrafo en un estilo informal. Mltiples prrafos que
comprenden varios escenarios. Ejemplo: gestionar devoluciones.
Completo: el ms elaborado. Se escribe con detalle todos los pasos y
variaciones, y hay secciones de apoyo como precondiciones y garantas de
xitos. (Universidad de El Salvador, 2007, pp. 8-9)
Ejemplo:

Casos de uso: Nombre=Procesar Venta






Actor principal: el actor principal que recurre a los servicios del sistema
para cumplir un objetivo.

Personal involucrado e intereses: importante personal involucrado y lista
de intereses.

Precondiciones: establece lo que siempre debe cumplirse antes de
comenzar un escenario de caso de uso.

Garantas de xito (postcondiciones): establecen que debe cumplirse
cuando el caso de uso se completa con xito. La garanta debera satisfacer
las necesidades de todo el personal involucrado.

Escenario principal de xito (o flujo bsico): camino feliz, describe el
camino de xito tpico que satisface los intereses del personal involucrado.

Extensiones (o flujo alternativo): las extensiones son muy importantes.
Indican todos los escenarios o bifurcaciones tanto de xito como de
fracaso.

Requisitos especiales: un requisito no funcional, atributo de calidad o
restriccin. Estas incluyen cualidades tales como rendimiento, fiabilidad, y
facilidad de uso.



Redaccin

Definir el nivel de detalle de los casos de uso

Antes de iniciar con la redaccin de los casos de uso, se debe acordar el nivel de
detalle necesario para el proyecto.

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 informacin adicional como reglas de negocio, requisitos no funcionales,
diccionario de datos que completen los requerimientos del sistema. Sin embargo la
ingeniera del funcionamiento especifica que cada caso crtico del uso debe tener
un requisito no funcional centrado en el funcionamiento asociado.



Redactar el flujo principal primero

Es importante administrar el esfuerzo en el comienzo del anlisis de un sistema.
Se recomienda trabajar a un nivel de precisin bajo. Como primer paso de esta
estrategia, realizar una lista de metas de los actores seguido de la redaccin del
flujo principal ("camino feliz") de los casos de uso.

La tcnica de caso de uso tiene xito en sistemas interactivos, ya que expresa la
intencin que tiene el actor (su usuario) al hacer uso del sistema. Como tcnica de
extraccin de requerimiento permite que el analista se centre en las necesidades
del usuario para que logre utilizar el sistema, evitando que la gente especializada
en informtica dirija la funcionalidad del nuevo sistema basndose solamente en
criterios tecnolgicos.

A su vez, durante la extraccin (elicitation en ingls), el analista se concentra en
las tareas centrales del usuario describiendo por lo tanto los casos de uso de
mayor valor que aportan al negocio. Esto facilita luego la priorizacin del
requerimiento.


Separar la interfaz de usuario (GUI) de las funcionalidades

Al separar la interfaz de usuario de las funcionalidades descritas en los casos de
uso se previene la inconveniencia de producir documentos saturados y extensos.

Las ventajas de redactar casos de uso independientes de la interfaz es la
mantenibilidad. Si un caso de uso contiene muchos detalles de la interfaz de
usuario y esta llegase a cambiar, sera muy costoso actualizar los casos de uso
afectados por el cambio.

Casos de uso CRUD

Comnmente es necesario redactar casos de uso de funcionalidades Create,
Retrieve, Update, Delete, CRUD, que en espaol traduce crear, obtener,
actualizar y eliminar.

Hay quienes recomiendan no generar casos de uso para modelar funcionalidades
CRUD, debido a que estara ligado ms al diseo de la aplicacin que a su
funcionalidad. Sin embargo, en la prctica frecuentemente es necesario redactar
este tipo de casos de uso pues el nivel de detalle lo requiere.



Se recomienda redactar un caso (ejemplo: administrar catlogo de contrato) del
cual se llama a los casos de uso de la funcionalidad CRUD, ya sea con flujos
alternos o con llamadas a otros casos de uso si la funcionalidad es muy compleja.

Es conveniente descomponer un CRUD?

Depende:

Si los casos de uso ms especficos generados van a ser usados ms de una
vez. (Reso).

Si cada caso de uso es suficientemente complejo para requerir una descripcin
narrativa extensa. (Complejidad).

Si nos permite estimar mejor el esfuerzo requerido para implementar el caso de
uso. (Cubicacin).



























Referencias


Servicio Nacional de Aprendizaje, SENA. (2010). Diseo de casos de uso.
Colombia: Autor.
Universidad de El Salvador. (2007). Definicin de Requisitos. Consultado el 28
de enero de 2014, en
http://ybathich.site90.com/documentos/Material/Metodologia/Requerimientos/Un
idad_2.pdf



Control del documento


Nombre Cargo Dependencia Fecha
Autor

Patricia Isabel
Lozada
Arregocs

Contratista
Centro Agroturstico
Regional Santander.

Diciembre
de 2013

Adaptacin
Ana Mara Mora
Jaramillo
Guionista -
Lnea de
produccin
Centro
Agroindustrial
Regional Quindo
Enero de
2014