En la mayoría de las organizaciones en las que he trabajado, se realiza una Toma de Requisitos bastante detallada y posteriormente un Análisis Funcional basado en los requisitos recogidos.
¿Qué es lo que se hace?, se capturan y describen los requisitos y después se traslada a un modelo de casos de uso, dónde se vuelve a describir la funcionalidad deseada; posiblemente si se hace bien, con un enfoque más orientado al usuario y con una estructura más clara.
Ahora bien, ¿qué conseguimos con esto?, más horas de análisis, más horas de validaciones, tener repetido lo que tiene que hacer el sistema en dos artefactos diferentes, inconsistencias, etc...
La captura de los requisitos se debe realizar a través de los casos de uso. Si se decide no utilizar casos de uso, se puede realizar a través de un documento de análisis que contenga las funcionalidades y su estructuración.
Si para realizar el análisis de una aplicación, primero se capturan las necesidades, luego se hace un documento de toma de requisitos que además se tiene que validar y finalmente se hace un modelo de casos de uso (con su validación correspondiente), daremos la razón a todos aquellos que piensan que el proceso de Análisis es demasiado pesado.
CONCLUSIÓN FINAL: Los requisitos funcionales se deben capturar a través de los casos de uso. No se debe perder el tiempo en hacer un documento de requisitos funcionales.
Más adelante hablaremos sobre las Historias de Usuario, aunque para ello tendremos que poner el contexto del tipo de proyecto que manejamos.
Estoy de acuerdo en cuanto a que se realizan actividades repetitivas pero solo cuando se tiene mucha experiencia se pueden educir requisitos a partir de casos de uso de lo contrario es mejor hacer la tarea para que el análisis se realice correctamente
ResponderEliminar