La gestión de requerimientos establece lo que necesita la empresa y el sistema debe hacer para satisfacerlo, sino lo identificamos de forma correcta, no se cumplirán las expectativas finales del usuario, ni se podrá determinar de una manera clara el alcance y la dimensión del proyecto.

El objetivo principal será dar tanto al cliente como al proveedor un mecanismo de control y seguridad de que ambas partes están de acuerdo en el alcance funcional y técnico.

Su complejidad será en relación a la necesidad de que sean completos, relevantes y consistentes para ambas partes.

Requerimientos de sistema y software.

El cliente es experto en los procesos de negocio, por lo cual sabe cuáles son sus necesidades de información, siendo el origen de sus requerimientos las necesidades del usuario, en tanto el proveedor es experto en las  características de los sistemas y especificaciones del software.

El origen del problema.

Normalmente no se exponen de manera clara ni se documentan de manera apropiada, son incompresibles para los usuarios y no existe una método estándar entre los técnicos, alejándose muchas veces de la realidad.

Los requerimientos cambian, no se actualiza la documentación asociada, y no son comunicados a todos los involucrados en el proyecto.

Existen diferentes niveles de detalle y son difíciles de controlar.

Debería existir una alto compromiso de los usuarios en la validación de los requerimientos, para garantizar que sean los correctos y cubran sus necesidades, participación que en la mayoría de los casos no se da.

Porque se deben definir los requerimientos.

Si el sistema falla, suele ser debido a una mala definición de los mismos.

El definir unas buenas especificaciones de sistema y software que sea correcta, completa y medible es de difícil consecución.

No importa lo bien diseñado o desarrollado que este un programa o implantación sino se ha analizado correctamente, con seguridad defraudara al usuario y frustrara al proveedor.

Los usuarios saben lo que quieren pero muchas veces no saben cómo solicitarlo y mucho menos documentarlo. Es necesario ayudarle y formarle de cómo debe documentar los requerimientos.

Por un lado los clientes a fin de ahorrarse tiempo o considerando que a medida que avance el proyecto ya se harán los ajustes necesarios y de otro lado el proveedor que debería exigir ese análisis pero con el miedo de perder la venta por el aumento de costes no lo exige. En todo caso se debe buscar un punto medio donde por lo menos se asegure el alcance.

No es fácil la identificación de requerimientos, hay que satisfacer necesidades que a veces no son reales de los usuarios, provienen de diferentes fuentes, y son de diversos tipos, e aquí donde las habilidades y herramientas de un buen analista hacen que el sistema cumpla con las funcionalidades correctas.

La principal relación que existe entre el retraso de un proyecto y los requerimientos, es que algunos aspectos están fuera del alcance inicial, lo que suele dar malos entendidos entre el cliente y el proveedor.

Cuando más grande sea el proyecto más tiempo hay que invertir en el control del alcance, considerando además que los requerimientos se suelen relacionar unos con otros.

Clasificación de requerimientos.

Según Funcionalidad.

  • Requerimientos funcionales. Definen lo que el sistema debe hacer, acciones que debe realizar, que comportamiento deberá tener.
  • Requerimientos no funcionales. Describen atributos del sistema o su entorno, interfaces, diseño, legales, físicos, coste, tiempo, calidad, seguridad etc…

Según nivel de cumplimiento.

  • Obligatorios.
  • Recomendables.
  • Opcionales.

Responsabilidad de los usuarios.

Instruir a los analistas sobre el negocio, definir vocabulario, invertir tiempo en proporcionar requerimientos, aclarar dudas, tomar las decisiones a tiempo, fijar prioridades, respetar las características del sistema y los costes.