Muchas veces ocurre que no comprendimos bien los requerimientos de un sistema y ponemos el producto incorrecto en las manos del cliente. Esto, si ya ha pasado mucho tiempo y se ha consumido mucho del presupuesto, puede causar daños irreparables para el cliente, hasta la quiebra de la compañía.

Entender mal los requerimientos es algo completamente normal y a todos nos va a pasar. Lo importante es que nos demos cuenta lo más pronto posible, cuando es fácil y barato corregir.

La validación de requerimientos es el medio que nos permite asegurar el entendimiento de lo que se va a hacer. Depende de lo que quieres validar es la técnica que puedes usar.

Soy Edgar Fernández, hablemos de la validación de requerimientos.

¿Qué es la validación de los requerimientos?

Validar los requerimientos es un paso crucial. Va más allá de leer los documentos, aprobar y recolectar firmas. Aunque esto es necesario a veces, no es lo más importante. 

Validar correctamente los requerimientos es lo que permitirá que el equipo se enfoque en producir y entregar valor frecuentemente. Es el paso en el que encontramos lo valioso y nos deshacemos de lo innecesario.

Hay varias formas de validar un requerimiento. Antes de conocerlas, primero veamos cuáles son las características de un requerimiento excelente.

Características de un requerimiento excelente 

Correcto: el requerimiento provee una función o capacidad que es acorde con una necesidad de los stakeholders. La función está descrita con claridad.

Factible: es posible implementar el requerimiento dentro de las capacidades y limitaciones del sistema y el proyecto. Por ejemplo, tenemos y conocemos el framework de desarrollo para hacerlo y contamos con el tiempo y el presupuesto necesarios.

Necesario: el requerimiento ofrece a los stakeholders el valor de negocio esperado, diferencia el producto de software de otros en el mercado, o es necesario para adecuarse a una regulación externa. En nuestra metodología DINO, estos son los requerimientos Obligatorios.

No ambiguo: primeramente, la definición del requerimiento debe ser comprensible; quien lo lee debe ser capaz de comprender lo que fue definido. Después, el requerimiento debe ser interpretado de la misma manera por dos o más personas.

Verificable: el requerimiento es verificable si podemos definir formas de probarlo. 

Consistente: los requerimientos deben ser atómicos y no entrar en conflicto con otros o contradecirse. Un ejemplo de contradicción es que el sistema de permisos autorice a usuarios a hacer cosas que no están en su tabla de acceso.

Completo: la especificación tiene el detalle suficiente para permitirle al equipo entender lo que se debe desarrollar. 

Ahora que conocemos las características de los requerimientos excelentes, veamos cómo se validan los requerimientos en sus diferentes niveles. 

Validación de requerimientos de negocio

Para validar los requerimientos de negocio, debemos asegurar que estamos alineados con los objetivos del negocio y que la solución propuesta nos conduce a ello.

Podemos validar estos requerimientos en dos momentos:

Al inicio del proyecto, con una prueba de concepto. Esta puede realizarse con un prototipo no funcional, que simula la aplicación final y la mostramos a los usuarios. Los prototipos no funcionales son hechos con tecnología y componentes que no serán parte del producto final, como un prototipo en papel, una presentación interactiva de diapositivas o un andamio rápido como los que hace Ruby on Rails.

Al comenzar el desarrollo, con un MVP. Esperamos que el equipo construya una primera versión del producto completo, con la que se validará la idea de negocio.

En la validación de requerimientos de negocio, aseguramos dos cosas más:

Los criterios de éxito están definidos en términos del negocio y sus objetivos, lo cual nos permitirá medir los parámetros que usaremos para nuestros prototipos.

Los perfiles de los stakeholders están completos. Así,