El siguiente texto, es parte de un debate iniciado en el grupo de discusión TESTING & QA, y bajo el título de:
“…tenemos un problema, dos programadores no entienden de una misma manera un mismo análisis funcional…”
Algo que ocurre muchas veces es que todos en el equipo del proyecto esperan que en la documentación de requisitos, en general, y de casos de uso, en particular, esté incluido no solo la especificación de requisitos (funcionales y no funcionales), la definición del problema y sus detalles, sino también la solución de ese problema en términos de software.
Es decir, esperamos que la especificación de un caso de uso, por ejemplo, contenga los elementos básicos de un caso de uso, como el Actor, la secuencia básica y las alternativas (si existen), las pre y pos-condiciones y los requisitos especiales, entre otras. Pero también esperamos que tenga la así llamada “realización del caso de uso”.
Esta no es más que el análisis y diseño del caso de uso, o sea, la manera como se va a implementar ese caso de uso en términos de diseño. Normalmente para esto usamos diagramas de UML, los que sean necesarios, empezando por diagramas de interacción (ya sean de Secuencia o de Comunicación), y también diagramas de Estado o de Actividad, entre otros.
El asunto es que la especificación del caso de uso debe ser lo suficientemente clara (no ambigua) y completa para que cualquier “interpretación” que se haga de la misma arroje los mismos resultados. Y esto debe ser así no solo para el equipo de diseño y de programación, sino para el equipo de pruebas. Es decir, la documentación debe ser tal que el diseñador y el verificador se hagan el mismo modelo o esquema mental del diseño y de las pruebas (casos de prueba) respectivamente.
Algunas técnicas para mejorar la especificación de requisitos (y de casos de uso) incluyen la revisión par, que debe comprender revisión de forma y de contenido. Esta revisión debe validar que cada requisito (y cada caso de uso) cumpla con algunas características bien conocidas:
? Claro
? Atómico
? No ambiguo
? Verificable
? Necesario
? PriorizadoEntre tanto, la especificación de requisitos (incluyendo todos los casos de uso) debe ser:
? Correcta
? Independiente de diseño
? Completa
? Consistente
? Rastreable
? Modificable / ExtensiblePara finalizar, los Analistas Funcionales deben presentar esta especificación al equipo de diseño, construcción y pruebas. Este es un paso muy importante que muchas veces se omite o se cumple con simplemente enviar un mensaje electrónico que incluye los documentos relacionados. El objetivo de la presentación no debe ser únicamente exhibir la especificación, sino lograr que todos los involucrados en el equipo salgan con las mismas ideas, con el mismo mapa mental del que hablaba antes.
Lo encuentran en: El miembro que escribió este comentario, invita a que accedan a otro artículo escrito por él y referido con ‘Realización de Casos de Uso’
http://gazafatonarioit.blogspot.com/2007/10/lecturas-fundamentales-10-lectura_3046.html
Lo recomiendo porque me resultó muy interesante.
El siguiente texto es el enunciado principal de una ‘Discusión’ publicada en el Grupo de Discusión denominado: Análisis Funcional.
El siguiente texto es el enunciado principal de una ‘Discusión’ publicada en el 
En relación con el Debate iniciado en LinkedIn: