Pautas para la Escritura de Requerimientos

Una de mis tareas, definidas en mi trabajo diario, es controlar requerimientos. Los requerimientos, normalmente son confeccionados por Analistas Funcionales, Consultores y Project Leaders.

Este control, se hace en pro de que los requerimientos estén bien redactados y con toda la información necesaria.

De tanto en tanto, me encuentro con requerimientos que no cumplen con las características que mencioné y es por ello que pretendo dejar una "guía", o como quieran llamarle, para que a la hora de redactar tengan en cuenta ciertos puntos básicos, pero fundamentales, a la hora de elaborar un requerimiento.

Si bien la mejor guía para escribir requerimientos es la experiencia… Existen una serie de pautas que pueden ayudar cuando la experiencia está gestándose…

- Escribir oraciones o párrafos cortos siguiendo apropiadamente las reglas gramaticales y ortográficas y cuidando la puntuación.

- Usar la voz activa (“El actor tal ejecutará la función cual”).

- Utilizar los términos explicados en el glosario consistentemente.

- Utilizar el mismo nombre para cada cosa, consistentemente a lo largo de los documentos (Si se decidió por llamar al nuevo software “sistema” no utilizar sinónimos tales como “aplicativo”, “producto”, “software”, etc.)

- Evitar los condicionales (“debería”, “podría”, etc.).

- Utilizar figuras, gráficos y tablas para presentar la información visualmente. La lectura es más interesante si se evitan los párrafos largos y densos de texto exclusivamente.

- Evitar el lenguaje ambiguo.

- Escribir en positivo evitando el negativo (“El sistema hará” y no “El sistema no hará”)

Aceptable, adecuado: definir qué constituye lo “aceptable” o “adecuado” en términos mensurables y verificables.

Ya que entre las pautas que escribí, coloque el tema de la ambigüedad, les voy a dejar un detalle de lo que normalmente veo redactado y como debería redactarse. Suena autoritario, pero léanlo y después me dicen.

Como van a observar, parece que me estoy yendo a un extremo, pero la realidad es que la especificación de requerimientos, luego es leída por el cliente. Imagínense, que ustedes van a adquirir un servicio, y le digan: "El servicio anda muy rápido". Francamente, no se ustedes, "Muy Rápido" para mi pueden ser 2 segundos, y quizás lo que a ustedes les parece "Muy Rápido", en realidad sean 10 minutos. Sin embargo, si me dicen "El servicio tiene un tiempo máximo de 2 minutos, y un tiempo mínimo de 1 minuto", no se da lugar a la libre interpretación. Y por supuesto, nuestro argumento no solo es mas serio, si no que también puede ser plenamente comprobable.

Les dejo entonces algunos terminos con los que frecuentemente me encuentro, y como podriamos hacer para reemplazarlos.

Como mínimo, al menos, como máximo, como mucho: especificar los valores máximos y mínimos aceptables.

Dependiendo de: definir la naturaleza de la dependencia describiendo si se trata de una precondición, de una condición previa mandatoria, si la dependencia es ocasional, etc.

Eficiente, rápido, flexible: definir cada una de estas características y asignarles rangos mensurables y verificables.

Mejor, superior, mejorado: cuantificar cuán superior o mejor será en el nuevo sistema en qué módulo y para qué clase de usuario. 

Idealmente, normalmente: describir las situaciones ideales o normales y no olvidar describir también las condiciones de anormalidad.

Opcionalmente: clarificar si se trata de una decisión que tomará el sistema o el usuario y explicar las alternativas u opciones posibles.

Razonable, cuando sea necesario, cuando sea apropiado: describir cómo se evalúan estas características en términos mensurables y verificables.