Problemas del análisis de Requisitos

 Steve McConnell, en su libro Rapid Development , detalla una serie de formas en que los usuarios pueden inhibir la recopilación de requisitos:Los usuarios no entienden lo que quieren o los usuarios no tienen una idea clara de sus requisitos.

Los usuarios no se comprometerán con un conjunto de requisitos escritos

Los usuarios insisten en nuevos requisitos después de que el costo y el calendario se hayan solucionado

La comunicación con los usuarios es lenta

Los usuarios a menudo no participan en las revisiones o son incapaces de hacerlo

Los usuarios son técnicamente poco sofisticados

Los usuarios no entienden el proceso de desarrollo

Los usuarios no saben acerca de la tecnología actual

Esto puede conducir a una situación en la que los requisitos del usuario sigan cambiando incluso cuando se haya iniciado el desarrollo del sistema o del producto.

Problemas de ingeniero / desarrollador

Los posibles problemas causados ​​por ingenieros y desarrolladores durante el análisis de requisitos son:

Una inclinación natural hacia el código de escritura puede llevar a la implementación comenzando antes de que se complete el análisis de requisitos, lo que podría resultar en una refactorización poco elegante para cumplir con los requisitos reales una vez que se conocen.

El personal técnico y los usuarios finales pueden tener diferentes vocabularios. En consecuencia, pueden creer equivocadamente que están en perfecto acuerdo hasta que se suministre el producto terminado.

Los ingenieros y desarrolladores pueden intentar que los requisitos se ajusten a un sistema o modelo existente, en lugar de desarrollar un sistema específico para las necesidades del cliente.

Intento de soluciones

Un intento de solución a los problemas de comunicación ha sido emplear especialistas en análisis de negocios o sistemas.

Las técnicas introducidas en la década de 1990, como prototipos , lenguaje de modelado unificado (UML), casos de uso y desarrollo ágil de software también pretenden ser soluciones a problemas encontrados con métodos anteriores.

Además, una nueva clase de simulación de aplicaciones o herramientas de definición de aplicaciones han ingresado al mercado. Estas herramientas están diseñadas para salvar la brecha de comunicación entre los usuarios comerciales y la organización de TI, y también para permitir que las aplicaciones se 'prueben comercializando' antes de que se produzca ningún código. Lo mejor de estas herramientas ofrece:

Pizarras electrónicas para bosquejar flujos de aplicaciones y probar alternativas

capacidad de capturar la lógica de negocios y las necesidades de datos

capacidad de generar prototipos de alta fidelidad que imitan de cerca la aplicación final

interactividad

capacidad para agregar requisitos contextuales y otros comentarios

capacidad para usuarios remotos y distribuidos para ejecutar e interactuar con la simulació