En mi anterior post (Para quien se debe escribir los casos de uso) indicaba dependiendo del perfil o rol de las personas que leyeran el caso de uso tenían diferentes expectativas del mismo.
Según un comentario que me realizaron, los casos de uso no son el documento Dios, pero la verdad hay que tener en cuenta los diferentes Intereses de cada uno de los interesados
Si nos olvidamos por un momento del usuario, tenemos los siguientes roles:
- Diseñador: el cual es el que buscar la mejor solución técnica para el proyecto
- Desarrollador: busca que el código sea lo mas elegante posible para el diseño planteado
- Tester: el cual quiere que se construya lo correcto de forma correcta.
Estos tienen expectativas diferentes, por eso cada uno lee de forma diferente los documentos que los analistas de requerimientos generen. Acá es necesario pensar en una pirámide de dependencias
Donde los analistas tienen que pensar, al momento de generar los documentos de especificación de requerimientos, en todos los diseñadores, desarrolladores y testers que le siguen en la construcción del software. Los diseñadores en los desarrolladores y los testers, por último los desarrolladores piensan en los que testers puedan realizar sus pruebas de manera exitosa.
Para la especificación de requerimientos (requerimientos <> casos de uso), un trabajo de los analistas de requerimientos, debería aplicar los principios de buenos desarrollos:
- Alta coherencia: Me refiero a que dependiendo del tipo de requerimiento que se requiera detallar usar el tipo de artefacto adecuado.
- Bajo Acoplamiento: Que entre los documentos generados para especificar un requisito exista la mínima dependencia entre estos, es decir que si modifico un documento no sea necesario modificar todos.
Si tenemos en cuenta estos dos principios al momento de especificar podríamos de eliminar los documentos de especificación DIOS, y la información esperada por cada rol estará donde debe estar y estará.
Cuídense
