Requisitos vs Casos de uso vs Historias de Usuario
¿Qué diferencias hay entre estos 3 conceptos?
Los tres intentan representar las características que tiene que tener un sistema, la diferencia está en el enfoque dado.
Los Requisitos del sistema están escritos desde la perspectiva del sistema y no en la interacción del usuario, representan las características en estado puro.
Los Casos de Uso están escritos como una serie de interacciones entre el usuario y el sistema. Hacen hincapié en el contexto orientado al usuario. Las características que utiliza cada usuario identificado en el sistema. Son la forma de capturar los requisitos del sistema desde el punto de vista del usuario.
Las Historias de Usuario sirven para describir lo que el usuario desea ser capaz de hacer. Además, las historias de los usuarios se centran en el valor que viene de usar el sistema en lugar de una especificación detallada de lo que el sistema debe hacer. Están concebidos como un medio para fomentar la colaboración.
Los requisitos y los casos de uso se pueden utilizar en desarrollos ágiles de software, pero ambos se apoyan fuertemente en las especificaciones documentadas del sistema, en lugar de colaboración tradicional de los métodos ágiles. Si no existe un enfoque integrado en la colaboración, es posible que se ahonde en una especificación detallada en el caso de uso que se convierte en la fuente de registro en lugar de un mecanismo de conversaciones.
En resumen las diferencias son: los requisitos tradicionales se centran en las operaciones del sistema, con una tendencia a la especificación detallada del sistema, los casos de uso se centran en las interacciones entre el usuario y el sistema con una tendencia similar de las especificaciones detalladas, y las historias de los usuarios se centran en el valor del cliente con una fuerte intención de fomentar la comunicación.
¿Son las historias de usuario mejor que otros tipos de especificación de requerimientos? Depende de la situación, pero en un ambiente de colaboración, la experiencia indica que claramente sí. Las historias de usuarios no hará que el proyecto sea ágil, o la falta de ellas hará que sea difícil adquirir agilidad.
Si estamos en un contexto no-ágil, ¿ayudan las historias de usuario? Depende del equipo. Si un equipo está inmerso en un proceso de desarrollo en cascada o con procesos iterativos pesados y se utiliza el enfoque de “planificación pesada y requerimientos up-front”, es muy probable que influya en las historias de los usuarios, convirtiéndolas en requisitos tradicionales. Las historias de usuarios son claramente un poco vagas en cuanto a descripción y se prestan a refinamientos sucesivos, la planificación y el diseño por adelantado no es su punto fuerte. La especificación detallada a menudo es la práctica en entornos de procesos controlados y pesados, antes de que comience la codificación de manera que los requisitos se puedan utilizar para planificar el presupuesto y el proyecto entero.
Las historias de usuarios (cuando se utiliza según lo previsto por algunos expertos, p.ej: Cockburn) son demasiado vagas en formato para prestarse a una documentación completa. Pero si, por el contrario, el equipo está abierto a la colaboración con los usuarios, el cliente, los analistas de negocios y los patrocinadores del proyecto y se puede o se desea tolerar el cambio, las historias de los usuarios pueden ser el método de requisitos más apropiado que además ayuda a la colaboración.
Comentarios
Publicar un comentario