Gestionando expectativas:

Cómo trasladar un buen Catálogo de Requisitos

Uno de los problemas a los que nos enfrentamos cuando vamos a comenzar un nuevo proyecto o fase del mismo, es trasladar nuestras necesidades, verbalizarlas, comunicarlas y que la persona que tenemos enfrente, Consultor o Analista, interno o externo, sea capaz de conectar con nosotros y captar nuestra necesidad.

Principalmente nos encontramos ante un problema de comunicación; es decir, que lo que uno crea expresar a la persona de enfrente lo entienda igual, que nosotros somos capaces de trasladarlo, que nuestras expectativas están alineadas con la persona encargada de facilitarnos lo que hemos solicitado. Aquí reside parte del éxito.

La tarea parece simple; pero no, no lo es.

En la gestión de los Requisitos intervienen dos partes esenciales, el que solicita la necesidad y el profesional que se encuentra ante el trabajo de realizar la captura e interpretación del requisito y ambos desempeñan una función esencial.

Vayamos por partes:

La Guía Practica de Gestión de Requisitos publicada por el “Instituto Nacional de Tecnologías de la Comunicación en 2008”, nos indica que “Un requisito es algo que el producto debe hacer o una característica que debe tener. Un requisito existe por el tipo de demanda que tiene el producto o porque el cliente quiere que el requisito sea parte del producto entregado. La tarea de todo analista de requisitos es hablar con la gente, entenderla, escuchar lo que dicen y también lo que no dicen, para entender lo que necesitan.”

Lo importante de esta definición está en la tarea de comprensión que debe de realizar el especialista, Consultor, Analista, etc. en saber captar e interpretar las necesidades de su interlocutor y verbalizarlas de una forma comprensible y en un lenguaje adecuado en función del destino final que vaya a tener ese Catálogo.

Los mayores problemas que me he encontrado a lo largo de estos años están en las expectativas, en gestionar lo que el cliente trata de expresarte y en verbalizarlo de una forma neutra. Es como cuando vas a comprarte un paquete de vacaciones, se supone que te lo vas a pasar fenomenal, se vende ilusión, felicidad, nadie cuestiona que te lo vas a pasar mal; pero que ocurre si cuando llegas al destino el sitio es horroroso y no es lo que estabas esperando……

Veamos cuales son los pasos que debemos de realizar para mejorar la alineación de expectativas.

1. ¿Qué es lo primero que debemos hacer?

Lo primero que debemos hacer sin duda es conocer el objetivo de la organización para lograr una buena identificación de las necesidades a abordar. Ver cuál es el punto de partida, para tener claro hacia que meta se quiere llegar.

2. ¿Cómo vamos a identificar las necesidades que el cliente tiene?

Aquí hay varias técnicas que se pueden utilizar:

• Diseño de flujogramas de proceso
• Cuestionarios de recogida de información con preguntas dirigidas a los usuarios.
• Entrevistas con los usuarios
• Sesiones grupales de Brainstormig, Resolución de problemas, etc.

¿Qué tipos de Requisitos nos encontraremos?

• Los más fáciles de identificar con los usuarios serán los funcionales, pero no son los únicos, tendremos también
• Técnicos o de producto: velocidad, memoria, capacidad de almacenamiento, etc.
• Diseño: Restricciones que pueda tener
• Atributos del sistema: fiabilidad, mantenibilidad, portabilidad, seguridad
  

3. ¿Qué características deberán cumplir nuestros requisitos?

Sobre este tema corren ríos de tinta, dejarme que en mi caso me acoja a la clasificación que sigue la “Especificación de Requisitos Software (ERS) según el estándar IEEE 830”. A modo de resumen.

• Corrección: La ERS es correcta si y sólo si todo requisito que figura aquí (y que será implementado en el sistema) refleja alguna necesidad real.
• No ambiguos: Cada requisito tiene una sola interpretación.
• Completos: Todos los requisitos relevantes han sido incluidos en la ERS.
• Consistentes: Los requisitos no pueden ser contradictorios.
• Clasificados: Normalmente, no todos los requisitos son igual de importantes.
• Verificables: La ERS es verificable si y sólo si todos sus requisitos son verificables.
• Modificables: La ERS es modificable si y sólo si se encuentra estructurada de forma que los cambios a los requisitos pueden realizarse de forma fácil, completa y consistente.
• Trazables: La ERS es trazable si se conoce el origen de cada requisito y se facilita la referencia de cada requisito a los componentes del diseño y de la implementación. La trazabilidad hacia atrás indica el origen (documento, persona, etc.) de cada requisito.

Desde Ibermatica Microsoft Mid-Market podemos ayudarte a realizar una identificación de necesidades acorde al objetivo de tu Compañía y el Catálogo de Requisitos necesario para ello, cuenta con nosotros cuando pienses desarrollar este laborioso objetivo.

Carmen Muñoz

Consultora Senior Microsoft Dynamics