Definimos Caso de Uso como…

Hoy en día los casos de uso son la principal forma de capturar los requisitos de los proyectos de desarrollo de software; y de ahí por tanto que sean el lugar de inicio más común para los libros que explican métodos de desarrollo. Sin embargo son también quizás, el concepto peor entendido de todos, probablemente por su sencillez y por estar enfocado a su tarea de modelar requisitos pero dejar poco lugar para nada más.

Formalmente, para el glosario:

Caso de Uso Escenario que narra la interacción entre un sistema y una entidad externa a la que se le provee una funcionalidad. Los casos de uso son principalmente cuerpos de texto de definición de requisitos funcionales aunque por medio de extensiones pueden ser utilizados por fuera de este ámbito.

El lenguaje UML incluye en su especificación el soporte para los casos de uso, permitiendo representar por medios visuales diversas características de estos; complementando así lo indicado en las especificaciones en formato texto de cada caso de uso.

Considerando que los sistemas de información modernos son altamente interactivos, tanto por su relación con múltiples operadores humanos como por su necesidad de integrarse e interactuar con otros sistemas, es necesario entonces que los requisitos sean capturados respetando esta naturaleza interactiva. Es decir, si bien antes nos bastaba preguntar qué debe hacer el sistema ahora es necesario agregar para cada uno de sus usuarios.

Por sencillez, llamaremos actor a cada operador externo, tanto si es un sistema aparte del nuestro como si se trata de un operador humano.

Con el enfoque de los casos de uso, el sistema luce diferente para cada uno de sus actores. A unos, la funcionalidad que ofrece serán la que se corresponde con su trabajo, en tanto que a otros, será la que corresponda con la necesidad de estos. Esta organización de la funcionalidad según el punto de vista de cada actor es clave para poder capturar rápida y efectivamente, los requisitos funcionales de un sistema altamente interactivo.

En su conjunto, los casos de uso constituyen el llamado Modelo de Requisitos Funcionales el cual puede ser complementado con documentos que detallen Requisitos No Funcionales en una forma más tradicional. Es responsabilidad del Analista de Requisitos el construir y el mantener estos artefactos.

El Modelado de Casos de Uso es hoy por hoy, la principal técnica de captura de requisitos funcionales, y es una pieza central en los procesos de desarrollo de pruebas, de la interfaz hombre-maquina, de la documentación de usuario y manuales así como de guiar el análisis y diseño de la solución técnica del desarrollo. Es decir, que el proceso de desarrollo se encuentra centrado en casos de uso.

Si bien los casos de uso pueden ser manejados en forma gráfica, con ayuda de los diagramas de caso de uso del lenguaje UML, la información total que estos contienen va mucho más allá. Entre las propiedades de los casos de uso se encuentran los flujos de eventos, las pre condiciones, los puntos de extensión y muchos más elementos, solo posibles de ser representados con ayuda de un documento de texto. En este blog, podrá encontrar un ejemplo completo.

, , , , , , ,

  1. #1 por Gregorio Osorio el 18-07-08 - 6:23 pm

    Sabemos que un caso de uso nos permite describir un requisito funcional del sistema, ahora bien, ¿con que nivel de detalle debe ser descrito el mismo?, ¿Es adecuado ser muy exhaustivo, o por el contrario es útil ser superficial?

  2. #2 por Iván Garcerant el 18-07-08 - 6:55 pm

    Es una excelente pregunta, el tema de los detalles es de hecho tan amplio y necesario en su discusión que en algún momento pretendo exponer mis ideas sobre el punto.

    Lo cierto del caso, es que un caso de uso debe contener requisitos y nada más. El detalle que pongamos será el necesario para expresar lo que queremos especificar del sistema, sin adelantar análisis ni diseño de posibles soluciones.

    Si se es superficial en exceso, significa que las soluciones técnicas propuestas por el diseño van a solucionar un problema ligeramente distinto al que teníamos en mente; si se es demasiado detallado se puede caer en el extremo de prohibir soluciones aún antes de haberlas oído.

    Por lo que el asunto es como en otras cosas, una materia de habilidad y buen gusto.

  1. Tareas: Análisis de Caso de Uso « Tecnología y Synergix
  2. Modelado de Casos de Uso « Tecnología y Synergix
  3. Tipos de requisitos: funcional vs. no funcional « Tecnología y Synergix
  4. Casos de Uso Avanzados: Relación de Extensión « Tecnología y Synergix
  5. Ejemplo de análisis de caso de uso « Tecnología y Synergix
  6. Casos de Uso Avanzados: El Tiempo como Actor « Tecnología y Synergix
  7. Casos de Uso: Flujos de Eventos « Tecnología y Synergix
  8. Todo requisito debe ser preciso y legible « Tecnología y Synergix
  9. Flujos de eventos alternativos « Tecnología y Synergix

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s

A %d blogueros les gusta esto: