# data[].attributes.headline
Definicion de ingenieria de requerimientos

# data[].attributes.subject
Definicion de ingenieria de requerimientos

# data[].attributes.body
La ingenieria de requerimeintos es una parte fundamental de un proyecto, ya que esta permite identificar, analizar, documentar y gestionar los distintos requerimientos que tiene un cliente sobre las necesidades de un sistema o software

# data[].attributes.body
1. Como lo explico el usuario: En el proceso inicial de elicitacion, el usuario explica como requisito funcional que primero quiere desarrollar como un tipo de escalera, pero aun asi este sufre de ciertas ambiguedades o falta de especificidad ya que los requisitos que este dicto no tiene mucha funcionalidad ni estan dichos de forma estructurada.

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

# data[].attributes.body
1. Stakeholder: Son aquellas personas que estan interesadas en el proyecto o software

2. Refinamiento de requisitos: Se refiere a que requisitos que abarca cosas muy grandes, dividirlos en partes o tareas mas pequeñas, haciendolos mas especificos

3. Trazabilidad de requerimiento: Se refiere a como va evolucionando un requisito a medida del ciclo de vida del software

4. Elicitacion: Es el proceso inicial de recopilar la informacion de los usuarios finales o stakeholders utililizando diferentes metodos como entrevistas, encuestas, etc...

5. Prototipado: Se trata de lanzar o estructurar en formato de prueba, ciertas funcionalidades del software, para obtener retroalimentacion y sugerencias de los stakeholders

6. Modelado de requerimientos: Habla de estructurar de forma clara y concisa del funcionamiento del software o de un requerimiento

7. Entornos del sistema: Se refiere a todo lo que el sistema puede abarcar en si, todo aquello que se puede gestionar en este mismo sin depender de factores externos

8. Modelado de escenarios: Se refiere a como responde el sistema a diferentes interacciones que tiene el usuario con el sistema, osea que es lo que debe hacer el sistema en cada situacion

9. Gestion de cambios: Se refiere a manejar los diferentes estados que tiene un requerimiento, indicando tambien los diferentes cambios que va sufriendo a medida del desarrollo

10. Validacion de requisitos: Se encarga de que los requisitos sean correctos, completos, y realmente cumplan las necesidades del usuario

11. Negociacion de requisitos: Trata de resolver los diferentes conflictos de intereses entre las diferentes individuos, se trata de llegar a un acuerdo que beneficie a las 2 partes y encuentre un equilibrio, dependiendo de la factibilidad, impacto y prioridad de este requisito