Gestionar el Alcance es uno de los procesos clave para el éxito rotundo de todo proyecto. Bien sabido es que en éste grupo de procesos se debe definir exactamente lo que requieren los clientes y otros interesados. Luego, debemos asegurarnos que todo ese trabajo y solamente ese trabajo se deba realizar. Si se realiza trabajo de más o de menos, nos encontramos ante un alcance “bañado en oro” o corrupto. De allí que el Plan de Gestión de los Requisitos reviste una gran relevancia, porque si el equipo que producirá los entregables del proyecto no entiende perfecta y claramente cuál es el trabajo que va a realizar ¿qué calidad tendrán los entregables y el proyecto? ¿Cómo el cliente o los interesados satisfarán sus expectativas?

Un Requerimiento es la condición que debe tener un producto, servicio, componente o sistema para satisfacer un estándar, contrato, especificación u cualquier otro documento formal de la organización. Los requisitos varían con el tiempo. Se definen en la etapa inicial del proyecto.

Estadísticas del PMI (Project Management Institute), a inicios del año 2021, reflejan que:

• El 47% de los proyectos informáticos fracasan debido a la deficiente o inmadura gestión de los requisitos de software.
• Menos del 50% de los proyectos, poseen recursos adecuados para realizar una buena gestión de los requerimientos.
• Tan solo el 20% de los proyectos reporta un alto nivel de madurez de análisis del negocio.

PARA DEFINIR UN BUEN ALCANCE, TENGA EN CUENTA LO SIGUIENTE:

1. Conozca claramente los objetivos de la organización o dependencia ejecutora del proyecto.
2. Escriba los requerimientos, requisitos o especificaciones en un documento formal y firmado por la persona que brinda los mismos y por quien los recopila.
3. Detalle correctamente qué procesos y actividades forman parte del proyecto.
4. Defina correctamente los criterios de aceptación de los entregables, los cuales servirán para el cierre de fase o del proyecto.
5. Tenga presente siempre y en todo momento, que todo aquello que no esté dentro del alcance NO FORMA PARTE DEL PROYECTO. Esto evitará bañar en oro o corromper el alcance.

CARACTERÍSTICAS DE LOS REQUISITOS O REQUERIMIENTOS

ESPECÍFICOS: No se pueden ni deben mezclar 2 requisitos diferentes

ÚNICO: El requisito se interpreta exclusivamente de una manera y solamente una.

PRECISOS: Deben ser claros, completos y bien descritos o definidos.

REALISTA. Debe ser factible atendiendo las restricciones de tiempo, dinero y recursos disponibles.

VERIFICABLES: Capaces de ser verificados durante pruebas.

CONSISTENTES Y PRIORIZADOS. En base a los objetivos del negocio, deben tener prioridad y ser consistentes.

ÚTIL O NECESARIO: Un requerimiento no es útil si no es demandado por los interesados, o si su retirada no ejercerá efecto alguno.

CATEGORÍAS DE REQUISITOS COMUNES

A. REQUISITOS DEL NEGOCIO

La guía BABOK (BUSINESS ANALYSIS BODY OF KNOWLEDGE), es uno de los estándares internacionales más reconocidos en la práctica de análisis de negocio y gestión de requisitos. Esta guía define cuatro (4) tipos de requisitos:  Requisitos de negocio, Requisitos de los interesados, Requisitos de la solución y Requisitos de Transición.

Los Requisitos del Negocio comprenden las metas, objetivos y resultados que describen por qué se está ejecutando el proyecto. Esto aplica a toda la organización, área de negocio, dependencia o alguna iniciativa específica. Por lo general, los Requisitos del Negocio se encuentran en el Acta de Constitución del Proyecto, o bien, en los documentos iniciales del proyecto.

EJEMPLOS:

1. Optimizar la gestión de pedidos de los clientes a fin de incrementar en un 50% la cantidad de pedidos que se pueden procesar en un mes.
2. Automatizar el registro en línea ante el INSS, el listado de personal de nuevo ingreso en cada organización del país, de acuerdo a nuevo requerimiento de ley.

B. REQUISITOS DE LOS INTERESADOS

Los interesados son todas aquellas personas que pueden ser afectadas positiva o negativamente por el proyecto. Los Requisitos de los Interesados son influyentes en sus áreas de negocio. Se conocen también como requerimientos de los usuarios. Son el vínculo entre los Requisitos del Negocio y los Requisitos de la Solución.

EJEMPLOS:

1. Necesitamos una forma para recibir los pedidos de los clientes en línea, mediante una plataforma digital.
2. Requerimos que los pedidos que recibamos de los clientes en línea, se asignen de forma automática a la persona que los procesará por tipo de cliente y región del país.

C. REQUISITOS DE SOLUCIONES

Estos requisitos describen funcionalidades y capacidades de la solución para satisfacer los Requisitos de los Interesados. Se describen en mayor o menor grado de detalle según sea necesario para su desarrollo e implementación. Estos Requisitos pueden ser Funcionales y No Funcionales.

C.1 REQUISITOS FUNCIONALES

Estos requisitos describen las capacidades que debe tener la solución. Se expresan haciendo referencia al comportamiento y la información que maneja.

EJEMPLOS:

1. La solución emitirá los Estados de Cuentas por correo electrónico por cada cliente que tenga préstamo.
2. La solución permitirá emitir facturas electrónicas por los servicios de energía eléctrica.

C.2 REQUISITOS NO FUNCIONALES

Estos requisitos describen las condiciones bajo las cuales debe funcionar la solución para que sea efectiva, y qué requisitos de calidad debe cumplir. A estos requisitos también se les conoce como requisitos de calidad de servicio. Los mismos no se relacionan de forma directa con la funcionalidad que debe tener la solución. Además, se dividen en categorías de requisitos de usabilidad (pensado por y para el usuario), eficiencia, de entorno, operacionales, seguridad, éticos, regulatorios y legislativos.

EJEMPLOS

1. Todas las comunicaciones deben encriptarse con el algoritmo MD5.
2. La consistencia del concreto de los edificios de más de 5 pisos, deberán ser capaces de soportar sismos mayores a 10 en la escala de Richter.

D. REQUISITOS DE TRANSICIÓN

Este tipo de requisitos describen las condiciones y capacidades que debe cumplir la solución para facilitar la transición entre la situación actual y la nueva, y que ya no serán necesarias hasta que se haya concluido el cambio. Estos requisitos son temporales, abarcan temas como entrenamiento, continuidad del negocio, conversiones de datos, por ejemplo.

EJEMPLOS

1. Los datos históricos de las transacciones de al menos 10 años, deben ser trasladados a fin de emitir informes útiles para las auditorías de los ejercicios contables.
2. Los obreros deberán ser entrenados en el manejo de las nuevas máquinas de trefilado.

E. REQUISITOS DEL PROYECTO

Estos requisitos se refieren directamente a la forma en que en deberán llevarse a cabo los procesos de Iniciación, Planificación, Ejecución, Control y el Cierre del Proyecto.

EJEMPLOS

1. Durante el Proceso de Control del proyecto, deberá proporcionarse la Relación de Informes del Proyecto; Informes de Rendimiento; Relación de entregables terminados; Rendimiento por indicadores de gestión.
2. En el proceso de Cierre de la Fase II de Diseño, como parte de las Lecciones Aprendidas, se deberá recopilar: Plano de Arquitectura de la Red Actual; Plan Maestro de Automatización; Documento de Lista de señales Eléctricas aprobadas.

F. REQUISITOS DE CALIDAD

Estos requisitos tienen que ver estrictamente con las medidas de calidad que deberá cumplir el producto, resultado o servicio; y qué constituye un entregable con éxito para prever problemas futuros.

EJEMPLOS

1. Atendiendo a la experiencia del usuario, si la calidad del producto, resultado o servicio no satisface ni concuerda con las expectativas del usuario, el producto no funcionará.

G. REQUISITOS TÉCNICOS

Estos son los Requisitos con los que deberá construirse el producto, y qué especificaciones tendrá.

EJEMPLOS

1. Los cables para el tendido eléctrico, deberán ser colocados de forma subterránea, en zanjas de 70 centímetros de profundidad a fin de evitar daños a los mismos.

EJERCICIO SENCILLO.

Indique en la casilla correspondiente, la categoría de Requisito que corresponda. Utilice las abreviaturas siguientes:

RTR Requisito de Transición; RNF Requisitos No Funcionales; RF Requisitos Funcionales; RI Requisitos de Interesados; RN Requisitos de Negocio.

SOLUCIÓN

CONCLUSIÓN

Sin buenos requerimientos no puede haber proyecto exitoso. De igual manera, un requisito mal identificado impactará el éxito del proyecto. Este artículo le ayudará a tener mayor dominio del tipo de requisito que deba identificar y documentar, según la fase en que se encuentra el proyecto. Usted será más valioso en su organización si revisa las prácticas internas para establecer qué tipo de requisito debe documentar, cómo y cuándo. También será capaz de implementar estándares si en su organización no se usa ninguno.

¿Ha encontrado útil e interesante éste artículo? Nuestra función es apoyarle en hacer las cosas mejor cada día. No deje de consultarnos.