¿Las historias de usuario son requisitos o requerimientos ágiles?

La historia de usuario, un requisito ágil

En el último curso de Historias de Usuario, Ingeniería de requisitos ágil, se abrió este debate interesantísimo en el foro que generó conocimiento, escribimos ciencia como me gusta decir, y que quiero exponer en este post.

Según la RAE, requisito es una circunstancia o condición necesaria para algo, mientras que requerimiento está más orientado a requerir o necesitar (a la falta de algo).

La diferenciación que hace generalmente la ingeniería de software es que un requisito es una condición exigida o necesaria, mientras que un requerimiento, que proviene de requerir, es la acción de solicitar algo.

Requerimiento es una necesidad planteada por un usuario (que puede o no ser solventada por medio de software), mientras que el requisito forma parte de aquellas condiciones que debe cumplir el producto para satisfacer los requerimientos (o necesidades). El requisito representa funcionalidades, características y restricciones que afectan al producto, determinan lo que este debe de cumplir y siempre hacen referencia a características observables.

Veamos un ejemplo de ambos:

• "El software tendrá que ser fácil de usar", esto sería un requerimiento, ya que no es algo observable y no supone una restricción
• "El listado de clientes se mostrará por defecto en orden alfabético", esto sería un requisito ya que establece una restricción observable

Por tanto la historia de usuario "Como administrativo quiero que el listado de clientes se muestre por defecto en orden alfabético para poder encontrar fácilmente a un cliente" está más relacionada con un requisito que con un requerimiento.

Si vamos un poco más allá podríamos ver a los dos términos como hablar de lo mismo con distintas perspectivas y profundidad. Los requerimientos se pueden ver como las necesidades funcionales que demanda el usuario a un nivel más o menos medio, y a los requisitos como la manera de detallarlos en los aspectos necesarios para poder implementar esas necesidades.

Si miramos una pila de producto nos encontramos en la parte superior, la más cercana, con historias de usuario detalladas con sus criterios de aceptación, que son claramente requisitos con sus características observables. Pero, si miramos la parte inferior, la más lejana, nos encontramos con epics y temas, elementos que podrían ser requerimientos que representen necesidades funcionales que están a nivel de demanda. Si esto lo aceptamos así, nos llevaría a la conclusión coherente de que uno o varios requisitos podrían llegar a satisfacer o cumplir un requerimiento.

Quiero dar mis agradecimientos a los participantes del debate William, Alejandro y Luís qué hicieron que este post fuera posible.