2. Como lo entendio el lider del proyecto: El lider de proyecto en el proceso de elicitacion no es capaz de analizar ni comprender bien los requerimientos dichos ya que probablemente no puso en practica algunos metodos de elicitacion para recopilar la informacion, y esto es un principal problema ya que a partir de aqui el lider de proyecto se crea la matriz de trazabilidad para que las demas entidades del desarrollo del proyecto puedan comprender cada uno de los requerimientos, ademas de que se va a dificultar mucho mas ya que al no tener los requerimientos claros, tampoco va a tener un refinamiento claro de los requisitos. En la imagen el lider de proyecto tuvo una idea "vaga", simplificada, incorrecta e incompleta de los requerimientos dichos por el cliente

3. Como lo diseño el analista: Como consecuencia de la falta de Especificidad en los requerimientos, en el momento de empezar el analisis de requerimientos, los requerimientos funcionales no van a cumplir las verdaderas necesidades del cliente, por lo que tambien al empezar el modelado de escenarios o modelado de los requerimientos en distintos diagramas como de secuencia, caso de uso, UML, van a estar mal estructurados debido a la falta de especificacion en los requisitos. Ademas, que los requerimientos esten mal especificados afecta mucho en la trazabilidad de los requisitos y la gestion de cambios de estos mismos. En la imagen el analista interpreto casi lo mismo que hizo el gerente de proyecto pero añadiendo un cambio o "funcionalidad" cortando el tronco del arbol

4. Como lo escribio el programador: Debido a que muy posiblemente la informacion de la matriz de trazabilidad no sea especifica, el programador puede desarrollar en el sistema implementaciones que estan mal estructuradas o hechas, afectando asi las interacciones y el comportamiento del sistema, afectando asi el modelo de comportamiento y la secuencia de eventos. Haciendo que el sistema no fluya y no cumpla los requisitos funcionales del cliente. Se representa en la imagen como que los requerimientos no estan muy bien especificados y no cumple muy bien con las necesidades finales del cliente

5. Como lo describio el consultor de negocios:

El consultor en la imagen puede denotar que hace un la validacion y gestion de estos requerimientos, y la gestion de cambios, pero como se puede ver parece que le ha parecido que el software esta muy bien hecho. Se representa en la imagen con supuestas mejoras al sistema con el sillon y esos brillos amarillos

6. Como se documento el proyecto

Al no haber ningun tipo de documentacion del sistema, esto impide a la trazabilidad de los requisitos, impidiendo como evolucionan a medida del ciclo de vida del software, por lo que tambien afectan en entender de forma mas concreta el funcionamiento del sistema, como el flujo de actividades y sesiones, por lo que este a la vez impide el flujo de datos y procesos En general, impide la escalabilidad del software. Se representa en la imagen con que no hay ningun rastro de nada

7. Lo que instalo operaciones:

   Esto se refiere a la etapa de validacion de requerimientos, y ejemplifica que algunos de los requerimientos se cumplieron, pero aun asi no se cumplieron todos los requisitos funcionales, por lo que se podria decir que el software esta incompleto o no cumplio con las necesidades del cliente o stakeholder. En la imagen se instalo un requisito esencial que es la cuerda, pero faltan otras funcionalidades importantes

8. Como se le cobro al cliente:

   Debido a los diferentes errores, falta de comunicacion y demoras en el desarrollo y entrega del software, hizo que este software sea de baja calidad y ademas sufra de sobrecostos, debido a la falta de especificidad de los requerimientos y a los constantes gestion de cambios de los requisitos. Representando asi una montaña rusa, donde s epuede denominar que al inicio se tenia un acuerdo bajo, pero debido a las diferentes cuestiones ya mencionadas este incremento

9. Como es soporte:

   Debido a la falta de escalabilidad del software a causa de la falta de documentacion, gestion de cambios y la falta de trazabilidad de los requisitos, y las no muy bien estructurados modelos de escenarios y requerimientos, hace que cualquier cambio o modificacion que se le haga al sistema pueda afectarlo por a otras funcionalidades de requisitos. Ademas de que puede carecer de requisitos no funcionales, que son aquellos que son los encargados de que el arbol sea estable y seguro, como su soporte

10. Lo que necesitaba el usuario final:

    Lo que realmente necesitaba era un mecanismo sencillo como un columpio, sostenido de 2 cuerdas y una llanta como requisitos funcionales, por lo que se puede decir que el comportamiento del sistema habia cambiado bastante y lo que se entrego en "lo que se instalo en operaciones" no cumple con la necesidad del cliente