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í, podemos rastrear las diferentes fuentes de origen para corroborar información y obtener la que sea necesaria durante el proyecto.

Validación de requerimientos de usuario

Los requerimientos de usuario pueden ser especificados mediante lenguaje natural y documentos. Sin embargo, en la validación debemos optar por actividades más colaborativas:

  • Modelación colaborativa de la solución: el equipo, con los usuarios, colaboran frente a pizarras para definir el aspecto de la aplicación, las interacciones, los flujos de información y de pantallas y el comportamiento adecuado.
  • Mockups y prototipos en papel: el equipo diseña por su cuenta un prototipo, que presenta a los usuarios. Estos lo observan y dan su retroalimentación, la cual es anotada directamente sobre el prototipo con marcas y postits.

Validación de requerimientos no funcionales

En los requerimientos no funcionales, validamos que cada uno se encuentra especificado, con criterios objetivos y medibles.

Los requerimientos no funcionales no pueden ser validados sin la implementación. Sin embargo, esperar hasta que la mayoría del sistema esté construido para poder correr pruebas de sistema tomará mucho tiempo y recursos, y cualquier error será costoso de corregir. Por esa razón, valida los requerimientos no funcionales en etapas tempranas con una prueba de la arquitectura. Para esta prueba, el equipo construye un prototipo funcional, que integra todos los componentes e interfaces de hardware y software con unas pocas funciones y lo despliega en un ambiente similar a producción. Así, observa el comportamiento de la arquitectura en aspectos como carga, seguridad, interoperabilidad, etcétera.

Validar consistencia

Asegura varias de las características de los requerimientos con actividades de revisión e inspección.

Estas consisten en que las personas del equipo revisan minuciosamente las especificaciones con el fin de encontrar inconsistencias y errores. Del mismo modo, una inspección hecha por un panel de expertos, externos al proyecto, permiten validar que la solución es correcta para el negocio y están definidos de la forma adecuada.

Conclusiones

Todo el trabajo de los requerimientos converge en esta actividad. Es donde confirmamos que hemos entendido lo que se debe hacer, o corregimos los errores. La validación nos permite estar seguros que cumpliremos con los objetivos de negocio y los especificamos correctamente; solamente leerlos y firmarlos es insuficiente. 

Cualquier error en los requerimientos debe ser identificado y corregido temprano en el proyecto, cuando es más económico hacerlo. De acuerdo a estadísticas comparativas, corregir un defecto de requerimientos al inicio del proyecto toma 30 minutos en promedio, comparado con un promedio de 17 horas en pruebas del sistema y de aceptación. Hacer estas actividades es una garantía de calidad y satisfacción para el usuario, así que colabora con tu equipo para hacerlo e involúcrense todos.

Deja un comentario

Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.