El ADN de los buenos requerimientos

ADN
Imagen DNA  por  Thomas Wensing  (CC BY-SA)

En el artículo El porqué del análisis de requerimientos comentamos cuán importante es esta etapa del SDLC, constituyendo ésta el pilar sobre la que sustentar el resto de etapas.

Los requerimientos podemos expresarlos de diversas formas -como por ejemplo mediante modelos visuales de representación-, sin embargo la forma más sencilla de hacerlo es usar el lenguaje natural.

El uso del lenguaje natural puede presentar problemas de entendimiento si no es utilzado correctamente, cosa que derivará en una no muy apropiada redacción de los requerimeintos y, por ende, problemas de compresnsión, vueltas atrás para clarificarlos o, lo que es peor, una errónea implementación de los mismos.

Veamos cómo es el ADN de los buenos requerimientos.

El lenguaje natural y los líos en los que te puede meter

El lenguaje natural es un lenguaje informal y sin restricciones, tal como se usa en el habla y la escritura cotidiana. El lenguaje natural es el medio más común de expresión de requerimientos en muchas industrias; es flexible, fácil de usar y no requiere capacitación adicional… y ahí empiezan los problemas.

Fíjate en estas frases; la introducción de una simple coma cambia su significado:

El maestro dice, Sarmiento es un ignorante El maestro, dice Sarmiento, es un ignorante

Esta otra frase puede mal interpretarse y perderse una amistad cuando tu intención no era insultar:

La perra de Ana esta muy enferma

Con esta frase podemos estar esperando a alguien en el banco (entidad bancaria frente a mobiliario urbano) equivocado:

Te espero en el banco de la plaza

Así pues, en el uso del lenguaje natural a la hora de especificar requerimientos, debemos de ser cuidadosos si no queremos liarla parda.

Redactando bien un requerimiento

No somos autómatas, y pretender tener todos los requerimientos de un sistema perfectamente redactados no es una tarea baladí; lleva tiempo y se va perfeccionando con la experiencia.

Para mi, una primera premisa de lo que debe de ser un requerimiento correctamente redactado es que defina sin ambajes ni ambigüedades QUÉ se necesita y no estipule ni restrinja CÓMO materializarlo.

Además, es preciso utilizar el lenguaje natural de forma controlada usando sujeto, verbo y predicado.

Algunos consejos a la hora de redactar requerimientos:

  1. Deben ser frases cortas, evitando párrafos que contengan varios requerimientos.
  2. Usa la voz activa (expresa la acción del sujeto en la oración); identifica el sujeto que realiza la acción.
  3. Establece la acción mediante el uso de un verbo.
  4. Establece el objeto sobre el que se realiza la acción.
  5. Usa la terminología del área de negocio que estés analizando (crea un glosario si es necesario).
  6. Define, si cabe, la condición que debe cumplirse para efectuar la acción.
  7. Indica las reglas que determinan el resultado de la acción.
  8. Indica el comportamiento en caso de excepción.
  9. Mantén el mismo nivel de detalle en todos los requerimientos.

No olvidemos, aunque no seamos de la rama de letras y nos pueda sonar a chino, evitar figuras literarias como:

  1. Elipsis: omitir voluntariamente elementos de la oración que se sobreentienden por el contexto.
  2. Hipérbaton: alterar el orden lógico de las palabras de una oración.
  3. Paráfrasis: ampliar la explicación de un determinado concepto mediante un resumen de lo dicho y con palabras propias.

Algunas estructuras creadas ex profeso y que te pueden ayudar para dirigir la redacción de requerimientos son las que comentamos en el artículo sobre estructuras de especificación de requerimientos.

Características del buen requerimiento

Documentar requerimientos es algo esencial en el proceso de la gestión de requerimientos. Para ello hemos visto que existen algunas recomendaciones para su redacción, pero todo requerimiento debe exhibir ciertas características para que sea considerado como ‘bueno’. Todo requerimiento debe de ser:

  1. Completo: contiene toda la información necesaria para definir la función del sistema y no quedan puntos o áreas a ser definidas
  2. Correcto: debe describir con precisión la funcionalidad.
  3. Claro: debe ser fácilmente entendible.
  4. Consistente: no entra en conflicto con otros requerimientos
  5. Independiente de la implementación: definir qué funciones debe presentar el sistema, no cómo podemos implementarlas
  6. Independiente: el requerimiento, dentro del conjunto de ellos, no puede solaparse con otros
  7. Factible: debe poder materializarse y no ser algo inviable o inalcanzable dentro de las restricciones del proyecto
  8. No ambiguo: sin múltiples interpretaciones.
  9. Necesario: debe alinearse con los objetivos que se persiguen, de forma que lleve a una deficiencia en el sistema si no se dispone de él.
  10. Verificable: podemos evaluar si el sistema lo cumple o no
  11. Atómico: no puede romperse o escindirse en requerimientos más pequeños
  12. Trazable: se le debe poder seguir la pista en otros requerimientos de mayor nivel o en elementos que forman parte del análisis, diseño y pruebas del sistema.

Algunos malos ejemplos

Tratemos de ilustrar algunos de los típicos errores en los que caemos y, por tanto, se incumple alguna de las características antes detalladas:

La herramienta permitirá publicar automáticamente los contenidos en la fecha prevista

¿A qué herramienta, sistema o subsistema hacermos referencia? ¿Bajo qué reglas o circunstancias se debe automatizar? ¿Qué contenidos? ¿Cada cuánto se realziará la publicación (cada día, cada hora, cada vez que mi suegra llame a casa, …)? No disponemos del detalle suficiente. Este requerimiento no es completo.

El galerista editará las imágenes de las obras de arte mediante un plugin de Java para que no sea necesario instalar software en el PC cliente

Estamos entrando en custiones de diseño e implementación, pues estamos definiendo cómo hacer las cosas, confuendiendo el Qué con el Cómo. Este requerimiento no es independiente de la implementación. Tampoco establece qué capacidades de edición se pueden efectuar, con lo que no es completo.

El galerista construirá nuevas páginas de fichas de productos con una herramienta ágil y sencilla

¿Qué es ‘sencilla’? ¿Qué es ‘ágil’? Seguramente tú y yo no vamos a tener el msmo concepto en mente de esas palabras; ambas son interpretables. Este requerimiento no es claro porque no concreta pero, sobre todo, es ambiguo.

Se deben capturar los datos del artista además del curriculum

Aquí hay 2 requerimientos unidos por un adverbio (que equivale a haber puesto una conjunción). Este requerimiento no es atómico ni tampoco trazable para la fase de pruebas.

Reescribiendo requerimientos

Una vez escritos los requerimientos debemos releerlos y reescribirlos, si es necesario, para que cumplan con los criterios y características planteadas en el desarrollo de este artículo.

Ejemplo 1:

La herramienta permitirá publicar automáticamente los contenidos en la fecha prevista

podría ser reescrito como:

  • El gestor de contenidos revisará las obras de arte pendientes de publicarse cada 60 minutos

  • El gestor de contenidos publicará nuevas obras de arte en la webde la galería cuando dicha obra esté marcada como ‘publicable’

Ejemplo 2:

El galerista editará las imágenes de las obras de arte mediante un plugin de Java para que no sea necesario instalar software en el PC cliente

podría ser reescrito como:

  • El galerista podrá recortar las imágenes de las obras de arte del gestor de contenidos cuando esté en modo edición

  • El galerista podrá rotar 90 grados hacia la izquierda las imágenes de las obras de arte del gestor de contenidos cuando esté en modo edición

  • El galerista podrá rotar 90 grados hacia la derecha las imágenes de las obras de arte del gestor de contenidos cuando esté en modo edición

Ejemplo 3:

El galerista construirá nuevas páginas de fichas de productos con una herramienta ágil y sencilla

podría ser reescrito como:

El galerista creará nuevas páginas de fichas de obras de arte en el gestor de contenidos

  • El gestor de contenidos presentará un lienzo en blanco cuando se creen nuevas páginas de fichas de obras

  • El galerista dispondrá de una paleta de bloques de objetos para la maquetación de nuevas páginas de obras de arte

  • El galerista podrá seleccionar el objeto de tipo ‘imagen’ de la paleta de bloques de objetos

  • El galerista podrá seleccionar el objeto de tipo ‘título’ de la paleta de bloques de objetos

  • El galerista podrá seleccionar el objeto de tipo ‘párrafo’ de la paleta de bloques de objetos

  • El galerista dispondrá sobre el lienzo cada bloque cuando maquete nuevas páginas de obras de arte

Ejemplo 4:

Se deben capturar los datos del artista además del curriculum

podría ser reescrito como:

  • El galerista creará nuevas fichas de artistas en el CRM

  • El galerista cumplimentará los datos de nombre, apellido, lugar de nacimiento y fecha de nacimiento de la nueva ficha de artista

  • El galerista introducirá la información del CV del artista de la nueva ficha de artista

  • El CRM no guardará la nueva ficha de artista si no se han registrado los datos de apellido, lugar de nacimiento y fecha de nacimiento