Columna Referentes: Como escribir buenos requerimientos


Gustavo Pérez Godoy- PMP

Introducción

Para los proyectos informáticos, un requerimiento se define como “una condición o capacidad que debe cumplir un sistema”, el cual puede ser cualquiera de los siguientes:

  • Una cierta capacidad necesaria para un cliente o usuario para resolver un problema o alcanzar un objetivo.
  • Una capacidad que un sistema debe tener para satisfacer un contrato, un estándar, una regulación u otra formalidad impuesta.
  • Una restricción impuesta por un referente interesado.

Un aspecto clave de la disciplina de Ingeniería de Sistemas es convertir “necesidades” en requerimientos de sistemas, que sean claros, precisos y verificables.

En este documento se detalla un conjunto de sugerencias para escribir requerimientos de desarrollo de sistemas y nos concentraremos en la calidad de éstos.

¿Qué es un buen requerimiento?

Un buen requerimiento especifica algo (o una funcionalidad) que es necesario, verificable y alcanzable, así como también claro, no ambiguo y trazable.

NECESIDAD. Si no es necesaria, pero alcanzable y bien escrita, puede todavía ser un buen requerimiento.

Si hay alguna duda respecto de la necesidad, hágase la siguiente pregunta: ¿Qué es lo peor que puede suceder si este requerimiento no se incluye? Si no hay una respuesta fácil, entonces no se necesita.

VERIFICABILIDAD. Para que sea verificable, el requerimiento debe especificar y detallar algo que, mediante el uso de mecanismos de “testing” o de análisis, permita su validación o verificación.

Cuando detalle un requerimiento, defina cómo se va a verificar y el respectivo criterio de aceptación (verificar o validar el alcance).

ALCANZABILIDAD. Las declaraciones subjetivas y poco claras no son alcanzables (Ej. que el reporte sea “fácil de entender”). El requerimiento debe ser fácil de especificar para que sea bien entendido.

Para que sea alcanzable, debe ser técnicamente factible y que se pueda obtener dentro del plazo, presupuesto y del resto de las restricciones del proyecto.

Si tiene dudas respecto de la factibilidad de un requerimiento, entonces tiene que estudiar y/o investigar acerca de su factibilidad. Si todavía hay incertidumbre, entonces lo más probable es que se trate de un objetivo y no de un requerimiento. Aún si fuera técnicamente factible, puede que no sea económicamente factible.

CLARIDAD Y NO AMBIGÜEDAD. Cada requerimiento debe especificar una necesidad simple; sea breve y simple, es importante no ser mal interpretado. Las frases simples son suficientes para un buen requerimiento.

Ejemplo de un requerimiento ambiguo:

El sistema no aceptará contraseñas de más de 10 caracteres

Aquí no está claro qué debería hacer el sistema:

  • El sistema no permitirá que el usuario ingrese más de 10 caracteres
  • El sistema truncará el “string” de entrada a 10 caracteres de largo, o
  • El sistema desplegará un mensaje de error si el usuario ingresa más de 10 caracteres

Un requerimiento correcto debe ser claro:

El sistema no aceptará contraseñas de más de 10 caracteres. Si el usuario ingresa un número mayor de caracteres, debe desplegarse un mensaje de error indicándole que el largo fue excedido y que debe corregir dicho error.

TRAZABILIDAD. La trazabilidad debe comprender todo el ciclo de vida del proyecto. Esto mitigará el impacto de posibles cambios en cualquiera de las fases del ciclo de vida.

Problemas Comunes

La siguiente lista detalla los problemas más comunes, no es exhaustiva:

  • Hacer supuestos incorrectos.
  • Describir detalles de implementación (el ¡CÓMO!) en vez de QUÉ es lo que se necesita.
  • Describir términos o consideraciones operativas en vez de requerimientos.
  • Uso incorrecto de algunos términos.
  • Uso incorrecto de estructuras gramaticales.
  • No detectar requerimientos faltantes.
  • Demasiadas especificaciones para un requerimiento simple.

SUPUESTOS INCORRECTOS. Los malos supuestos (o premisas) suceden cuando los autores del requerimiento no tienen suficiente información o ésta no existe del todo. El primero de los problemas se arregla documentando la información que es crítica al proyecto, incluyendo:

  • Necesidades
  • Objetivos
  • Restricciones
  • Conceptos operacionales
  • Presupuesto
  • Agenda tentativa
  • Detalles de la Organización

Esta información debe dejarse disponible para todos los potenciales autores de requerimientos. Un sistema de gestión de requerimientos debe tener esta facilidad de gestión de contenidos de documentos.

Para el caso donde la información NO EXISTE, el autor del requerimiento debería documentar todas las premisas del requerimiento en cuestión. Cuando se revise el requerimiento, entonces también se revisan las premisas y se puede identificar potenciales problemas. La idea es que esa información esté disponible para todos los que escriben requerimientos.

Jerarquía de Requerimientos

Dependiendo del formato, origen y características comunes, los requerimientos se pueden estructurar en distintos tipos:

  • Necesidad de un referente.
  • Funcionalidad deseada. Este es un servicio requerido por un analista de sistemas.
  • Caso de uso. Es una descripción del comportamiento de un sistema en términos de secuencias de acciones
  • Requerimiento suplementario. Es un requerimiento usualmente no funcional que no se puede capturar en la forma de caso de uso.
  • Pruebas que debe rendir. Son especificaciones de condiciones de ejecución de las cuales se esperan resultados específicos.
  • Secuencia de acciones descritas en casos de uso.

Terminología para describir Requerimientos

Al describir especificaciones, hay palabras que hay que evitar y otras que se deben usar en una forma específica. Se debe ser preciso en el uso de DEBE, DEBERÁ y DEBERÍA.

  • Los requerimientos usan el DEBE
  • Las declaraciones usan el DEBERÁ
  • Los objetivos usan el DEBERÍA

El DEBE tiene que ser verificable y demostrable (usualmente en esquemas regulatorios).

Ejemplos:

  • El Sistema debe proveer…
  • El Sistema debe hacer cumplir con…
  • El Sistema debe tener una interfaz con…

Hay otras palabras que, si se usan, pueden llegar a aumentar los costos.

  • … Debe soportar (cuando se refiere a actividades no bien especificadas)
  • … pero no limitado a…
  • … Etc.
  • … y/o

Ejemplo:

  • El sistema debe dar soporte para que el jefe de contabilidad defina escenarios de auditorías.
  • El sistema debe tener pantallas de ingreso de posibles escenarios de auditoría.

El uso de “pero no limitado a” y el “etc.” aparecen cuando la persona que escribe los requerimientos sospecha que hay cosas que no aparecen en el listado de requerimientos. Una forma de eliminar esta posibilidad es incluir en el SOW un trabajo analítico inicial para determinar si hay más requerimientos que agregar y si hay más ítems que agregar, se modifica el alcance del contrato.

En general, muchas expresiones descritas con palabras pueden malentenderse debido a la ambigüedad propia de las declaraciones en cualquier idioma, por lo tanto, se debe especificar elementos VERIFICABLES.

Algunas palabras y/o frases ambiguas:

  • Minimizar
  • Maximizar
  • Que sea rápido
  • Amistoso al usuario
  • Fácil
  • Suficiente
  • Adecuado
  • Rápido

 

Conclusión

Es evidente que los proyectos de TI son cada vez más complejos y son pocas las organizaciones que invierten en herramientas para gestionar la complejidad de los requerimientos, que son el punto de partida para cualquier proyecto. Sin una cuidadosa gestión de los requerimientos aparecen prontamente complejidades que hacen aumentar sistemáticamente los costos y los plazos.

___________________________________________________________________________

Autor

Gustavo Pérez Godoy es Ingeniero Civil Electricista de la UTFSM, Master of Sciences in Computer Sciences de la New York University, miembro de PMI y está certificado PMP desde 1999. Actualmente es Consultor Senior de PGP Ltda y ha liderado una gran gama de proyectos en los ámbitos de TI y de las comunicaciones.[1]

[1] Referencias: “Determining Project Requirements, Hans Jonasson” y “Writing Good Requirements, Ivy Hooks, Compliance Automation, Inc.