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á”)
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.
