Buscar en Gazafatonario IT

miércoles, septiembre 26, 2012

Casos de Abuso, Parte 9: Todos los requisitos funcionales se documentan en casos de uso


El que un proceso sea dirigido por casos de uso no quiere decir que toda la funcionalidad del software debe estar documentada en casos de uso. Hay requisitos que son transversales al producto, es decir, aplican en varias partes del sistema; también hay requisitos funcionales que se expresan mejor en prosa, siempre en términos del usuario, pero en narrativa; hay otras funcionalidades cuya complejidad amerita el uso de diagramas de actividad o de otro tipo de elementos gráficos o visuales para entenderse. En este último caso, siempre recomiendo el uso formal de UML como mecanismo de comunicación para no dar pie a malos entendidos o a concentración de ambigüedades.
Ya lo he expresado antes, los casos de uso apenas son uno de los mecanismos para identificar, organizar, documentar y administrar requisitos o, en el orden de ideas que estoy formulando, un receptáculo de requisitos, un depósito, un bote, una funda, un artilugio. De hecho, los casos de uso constituyen la práctica industrial más ampliamente usada en materia de requisitos de sistemas de información.
Lo digo de esta manera porque he notado que es muy fácil para las personas extraviar la noción y la práctica correcta de la Ingeniería de Requisitos y volverse “caso-de-uso-dependientes” y en ocasiones crean una especie de religión donde el acto de fe por los casos de uso toma tintes de devoción.
Como cualquier adicción, esta también va a ser difícil de desarraigar de nuestros modelos mentales. Sin embargo, vamos a intentarlo. Pero antes de eso, quiero reiterarles que soy entusiasta de los casos de uso, quienes han seguido mi Gazafatonario IT conocen las Lecturas Fundamentales, un esfuerzo medio modesto medio imponente por transmitir mi experiencia en el tema y que fueron la base de mi próximo libro, actualmente en etapa de edición.
En los últimos meses también he estado publicando sobre casos de uso 2.0, una estrategia que reúne las mejores prácticas tradicionales y ágiles para la documentación de requisitos de software, expuesta recientemente por el Dr. Ivar Jacobson y su equipo. Sobre este tema volveremos más adelante, cuando hayamos entendido, o hayamos vuelto a entender, el verdadero sentido del uso y el abuso de los casos de uso.
Este ha sido el principal objetivo de esta serie así llamada “Casos de Abuso”. En el capítulo 4 de la misma expongo las distintas formas y colores que pueden tomar los requisitos del software:
Impacto en la calidad: Bajo.
PD. Para saber más de ingeniería de requisitos, análisis de requisitos y el papel del Analista de Requisitos y de otros aspectos relacionados, pueden leer mi Lectura Fundamental 9:RUP: Fase de Concepción, Parte 2”, en mi Gazafatonario IT:

No hay comentarios.:

Publicar un comentario