Tema UNIDAD 4 Redacción Definir el nivel de detalle de los casos de uso. Antes de iniciar con la redacción 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 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. Redactar el flujo principal primero Es importante administrar el esfuerzo en el comienzo del análisis de un sistema. Se recomienda trabajar a un nivel de precisión bajo donde sea posible. Una lista de metas de los actores puede ser el primer paso de esta estrategia. Como siguiente paso tendríamos la redacción del flujo principal ("camino feliz") de los casos de uso. 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.
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. Otra de 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, sería muy costoso actualizar los casos de uso afectados por el cambio. Casos de uso CRUD. Comúnmente es necesario redactar casos de uso de funcionalidades CRUD Create, Retrieve, Update, Delete - (Crear, Obtener, Actualizar, Eliminar). Hay quienes recomiendan no generar casos de uso para modelar funcionalidades CRUD debido a que un caso de uso CRUD estaría ligado más al diseño de la aplicación que a su funcionalidad. Sin embargo, en la práctica frecuentemente es necesario redactar este tipo de casos de uso pues el nivel de detalle lo requiere. Se recomienda redactar un caso (Ejemplo: “Administrar Catalogo de Contrato”) del cual se llame 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 más específicos generados van a ser usados más de una vez. (Reúso) Si cada caso de uso es suficientemente complejo como para requerir una descripción narrativa extensa. (Complejidad) Si nos permite estimar mejor el esfuerzo requerido para implementar el caso de uso. (Cubicación)