Requisitos vs Casos de uso vs Historias de Usuario

Posted on 28 febrero, 2016

¿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.

The Differences: Lean Startup vs Agile Methodology

Can Lean Startup and Agile Methodology work together?

In today’s dynamic business world, we transform our project planning focus from an expanding control change process to an adaptive process that embraces change: a process that responds to business requests whenever they are made, a process that is flexible enough to change even the process itself.

That process entails practicing Lean Startup with the Agile Methodology, in addition to the traditional project management focus on controlling activities. Leanstartup principles measure ongoing results but then challenge those requirements as needed, as part of a build-measure-learn loop. A true picture of success or failure starts to emerge–and a true picture of failure may induce even the most intractable project sponsors to make significant changes before things go off the rails.

The Agile methodology is an approach to project management, typically used in software development. It helps teams respond to the unpredictability of building software through incremental, iterative sprints. Below is a diagram showing the various components of the agile method.

Requirement Analysis– This is equivalent to researching and brainstorming what the product requires. Examples can include general features, architecture discussions, workflow discussions and general product discovery.

Design Document & Prototype-This is the SOW (Scope of work), which will have all the requirements defined for the product.

Iterations, Demo & Feedback– During the development, iterations are needed to test the code as well as get feedback from the customer on progress. Feedback from the customer can include: mockups, front-end designs, and usability.

Identify defects & Resolve Bugs– Bugs and defects are always a constant in the software development process. It is important that there are good Quality Assurance standards to eliminate general issues.

Production & Technical Support– The software application is finally deployed and live. Once this occurs, a support plan needs to be in place for maintenance and general support on potential future issues.

Differences Between Lean and Agile

In the traditional uses of Lean and Agile, the main difference is the following:

Lean is used to help build and define a marketable product. Agile is the means to achieve this in software development. Below is a chart depicting the high level differences from a terminology perspective BUT they equate to the same meaning in a different context.

Both methodologies require a Project Manager to work closely with the development team and customer; driving the pace of the project. As a result, the Project Manager plays an integral role in the success of the overall project.