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/Unidad_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