La notación más inmediata que se puede emplear para expresar los requisitos del sistema es el lenguaje natural que habitualmente empleamos para comunicarnos. Mediante explicaciones más o menos precisas y más o menos exhaustivas es posible describir los requisitos. 

Los principales inconvenientes de este tipo de notación son las imprecisiones, repeticiones e incorrecciones que pueden producirse. Para limitar las imprecisiones y ambigüedades propias del lenguaje natural, es conveniente establecer ciertas reglas que impidan en la medida de lo posible un uso retórico o impreciso.

El lenguaje natural estructurado es una notación más formal que el lenguaje natural. Las restricciones, plantillas y esquemas ayudan a mitigar imprecisiones y ambigüedades. Fundamentalmente se trata de establecer ciertas reglas para la construcción de las frases. 

Por ejemplo, esta redacción resulta algo ambigua: “Al administrar el fármaco la enfermera deberá validar la identidad del paciente y la dosis del medicamento. Una vez realizada la administración se deberán registrar observaciones y la hora de administración”

¿Es la enfermera quién deberá registrar las observaciones y la hora? El uso de lenguaje natural estructurado ayuda a entender correctamente el requisito:

• REQ01. CUANDO la enfermera administre el fármaco, ANTES deberá validar:

  • • la identidad del paciente

    • la dosis del medicamento.

• REQ02. CUANDO la enfermera administre el fármaco, DESPUÉS deberá registrar:

  • • observaciones de la administración

    • hora de la administración

Ambas redacciones indican lo mismo pero la segunda ayuda más a la comprensión eliminando ambigüedades: indica el actor claramente, enumera las acciones y destaca cuando deben realizarse.

En ocasiones el lenguaje natural estructurado puede llegar a sustituirse o complementarse por una tabla:

La Las historias de usuario son propuestas por Kent Beck en el año 1998 en su libro Extreme Programming (XP). Posteriormente Mike Corn, en User Stories Explained, profundiza en el sendero iniciado por Beck.  Las historias de usuario hacen uso de lenguaje natural estructurado.

La función de las Historias de Usuario (HU) es definir una necesidad del usuario mediante el uso de un lenguaje comprensible para cualquier persona que la lea, disponga o no del contexto de la misma. Es la unidad mínima de funcionalidad que aporta por sí misma valor al usuario. Una historia de usuario apenas ocupa un párrafo. En tan reducido espacio una HU no puede contener el diseño, la normativa, ni los detalles para codificar.

Las HUs involucran a los clientes en la definición del producto. Las principales características de las historias de usuario son las tres C’s: 

• Card. La HU “cabe” en una tarjeta o post-it. Son, por lo tanto, descripciones de requisitos no muy detallados. La tarjeta refleja los elementos más importantes de la historia de usuario. Expresa el valor que se quiere conseguir desde el punto de vista del usuario. La “card” suele expresarse formalmente de la siguiente manera: Como [Rol] Quiero [necesidad] Para [motivo]. La primera parte “como ...” responde a “¿quién tiene la necesidad?”. La segunda parte “quiero …” responde a “¿qué necesidad es?”. La tercera parte “para …” responde a “¿por qué es necesaria?”. 

• Conversation. Después de escribir la historia en la tarjeta, es necesario tener una conversación al respecto de su contenido. La HU debe recabar las conversaciones necesarias para aclarar el valor que la funcionalidad requerida tendrá para el negocio. En las conversaciones debe involucrarse tanto al cliente como al equipo de desarrollo.

• Confirmation. La HU debe confirmarse con el cliente/usuario que realmente le aporta valor, para ello se incluyen criterios de aceptación o ejemplos. La confirmación debe contar con unos criterios claros de aceptación y es recomendable que contemple al menos un caso de éxito, un caso de fallo y un caso de error. Es posible utilizar la notación Gherkin, Dado - Cuando - Entonces (Given - When - Then), para formalizarla: Dado [escenario] Cuando [acción] Entonces [resultado]. Redactar los requerimientos incluyendo ejemplos concretos del problema es considerada una buena práctica en entornos complejos, tanto es así que existe un estándar, Specification by example, utilizado en metodologías ágiles. SBE ayuda a “solapar” las fases de requisitos, diseño, codificación y pruebas al introducir estos ejemplos en el código a través de los tests automatizados, este patrón de diseño guiado por pruebas se conoce como ATDD (Acceptance Test Driven Development).

Existen ciertos antipatrones o malas prácticas que conviene identificar a la hora de redactar HU, el más habitual es escribir HUs no centradas en el cliente/usuario. Las HU deben utilizarse para descubrir requisitos funcionales, no son de utilidad para expresar condicionantes técnicos. Por ejemplo, “Como desarrollador quiero un entorno de pruebas para asegurar mi código” no aporta valor alguno al cliente.

Una buena Historia de Usuario debe ser INVEST:

• Independent. No debe depender de otras historias

• Negotiable. No es un contrato, puede cambiar a lo largo del tiempo

• Valuable. Aporta valor por sí misma al usuario

• Estimable. Permite estimar el esfuerzo de realizarla

• Small. Su tamaño debe ser lo más pequeño posible, para acordar avances dentro de las iteraciones (entregas)

• Testeable. Cuenta con criterios de prueba que permitan comprobar que se comporta de la forma esperada