Este error
es reiterativo y cuando digo eso me refiero a que siempre hago énfasis en que
no es así, pero algunos analistas funcionales insisten en hacer exactamente lo
contrario.
Un caso de
uso especifica lo que debe hacer un sistema de software. No es correcto incluir
detalles de la interfaz gráfica resultante, como botones, cuadros de texto,
listas de opciones, entre otros, lo mismo que otros mecanismos relativos a los
elementos de software con los que se implementará el caso de uso, como
referencias a componentes de software, a librerías de acceso a datos, o a
tablas u otros objetos de bases de datos. Todo esto hace parte del “como” se
implantará el caso de uso en el sistema una vez que esté terminado, son
detalles poco entendibles para el usuario final, interesado principal en la
especificación del caso de uso y de los requisitos en general.
Recordemos
además que un caso de uso detalla la interacción entre el actor y el software,
desde el punto de vista del usuario; es decir, al usuario solo le interesa
conocer sobre los insumos que tiene que proporcionarle al sistema a través de
ese caso de uso y también de los resultados que el sistema le sirve de vuelta,
no cómo ese resultado es calculado, encontrado, o procesado al interior del
sistema.
Ahora bien,
suele ocurrir que algunos usuarios, a fuerza de lidiar durante tantos años con
los sistemas, conocen de nombres de tablas y hasta de procedimientos
almacenados y son capaces de establecer explícitamente de qué tabla quieren que
se tome un dato o cual procedimiento requieren ejecutar en cierto momento.
Estos detalles se documentan, pero se formalizan durante la etapa de Análisis y
Diseño del caso de uso, cuando este se suplementa.
Los
requisitos del software, y con ellos los casos de uso cuando se utilicen como
mecanismo de especificación, son independientes de diseño y de implementación.
Impacto en la calidad: Medio.
No hay comentarios.:
Publicar un comentario