Gestión de requerimientos en un proyecto de software de gestión empresarial

Buscar

Engloba todas las actividades y verificaciones necesarias para descubrir, analizar, documentar y mantener el conjunto de requerimientos de un proyecto en la implementación de un software de gestión empresarial.

La gestión de requerimientos define lo que nuestro sistema deberá hacer en relación a procesos, consultas, informes, pantallas, avisos, control de usuarios y otros elementos que nuestro negocio necesite, lo que conllevara que, si no se identifican de manera correcta, el software no proporcionara a los usuarios las funcionalidades e información esperada, además si estos no se especifican de manera concreta y entendible nos será imposible estimar la dimensión real del proyecto, generando problemas y falta de confianza entre todas las partes del mismo.

Ingeniería de requerimientos

Conjunto de técnicas que son usadas para asegurarse que los requerimientos del sistema sean completos, entendibles, relevantes y consistentes.

Proporciona a las partes integrantes del proyecto la herramienta que asegura que todas estén de acuerdo en el alcance funcional y técnico.

Transforma una necesidad operacional en una de descripción del sistema, los parámetros de desempeño y configuración, mediante un ciclo o ciclos de análisis, diseño y pruebas.

El documento generado debe ser claro tanto para el cliente como para el proveedor, si existieran necesidades técnicas estas deberán contener explicaciones para que el cliente pueda entenderlas ya que este documento será aceptado y firmado por ambas partes.

Requerimientos de un proyecto de software

El cliente es experto en sus procesos de negocio, conoce cuales son sus necesidades de información, el proveedor es experto en características y especificaciones de los sistemas de software.

Mientras el origen de los requerimientos del sistema radica en las necesidades del usuario, el origen de la gestión de requerimientos del proyecto se origina en los requerimientos y especificaciones del sistema.

Origen de los problemas

Es común que los requerimientos del proyecto no se expresen de manera clara, ni se documenten de la manera apropiada, que se den suposiciones, que se produzcan mal entendidos.

Aunque existen diversas técnicas, no son utilizadas por su complejidad, llegan a ser incomprensibles para los usuarios y muchas veces no reflejan la realidad.

Es común también que dichos requerimientos cambien durante el proyecto y estos no se reflejen en la documentación ni sean comunicados a los integrantes del proyecto. Estos cambios normalmente impactan de manera importante en la planificación y estructura del proyecto.

En algunos proyectos la cantidad y detalle de requerimientos los hace difícil de controlar.

Es indispensable la participación del usuario para identificarlos y validarlos y es una participación que ha veces no se tiene. A veces los usuarios que participan no son los idóneos para estos análisis.

¿Porque definir los requerimientos?

Una de las razones por la que un sistema falla es una mala gestión de requerimientos.

Documentar las necesidades, correctamente y que sean medibles, es uno de los problemas mas comunes en la gestión de un proyecto.

La principal relación entre la implementación de un software y el retraso de este radica en algunos aspectos que están fuera del alcance original, el cual nunca fue documentado.

Los usuarios por lo general saben lo que quieren, pero en muchas ocasiones no saben cómo solicitarlo.

No importa lo bien diseñado que este un programa, sino se ha analizado correctamente defraudara al usuario y frustrara al proveedor.

El cliente muchas veces y a fin de evitarse tiempo, considera que los ajustes se producirán sobre la marcha.

El proveedor para no elevar el coste del proyecto y no perder la venta tampoco exige el análisis.

La identificación no es fácil, debe satisfacer las necesidades reales, las cuales muchas veces no son claras, provienen de diferentes fuentes y son de diferentes tipos, lo que requiere de habilidades y herramientas por parte de los analistas.

Cuando mas grande sea el proyecto, mas se debe invertir tiempo en definir el alcance, cuando mas detallado, menor sera el riesgo de fracaso.

Es un hecho además que la modificación de los requerimientos conlleva unos costes relacionados, muchas veces difíciles de asumir.

Clasificación de los requerimientos

♦ Requerimientos funcionales.

Especifican lo que el sistema debe hacer sin restricciones físicas, especifican el comportamiento del sistema.

♦ Requerimientos no funcionales.

Describen únicamente características del sistema y atributos del ambiente del mismo, interfaz, diseño, implementación, legalidad, coste, tiempo, calidad, seguridad, etc..

Nivel de cumplimiento de estos

♦ Obligatorios.

Debe ser sin dudas implementado.

♦ Recomendables.

Deseables a ser implementados.

♦ Opcionales.

No es crítica su implementación.

♦ No incluidos.

No estan incluidos en el alcance.

Responsabilidades de los usuarios

♦ Enseñar a los analistas sobre el negocio y su vocabulario.

♦ Invertir tiempo en proporcionar requerimientos y solucionar dudas.

♦ Ser específico y preciso en expresar las necesidades y requerimientos del negocio.

small_c_popup.png

Documento

¿Como me adapto al control horario obligatorio?

small_c_popup.png

Contacta con nosotros

¿Necesitas una demo?