Presentacin de PowerPoint

CAPITULO 3

AlUMNO: CAJUSOL MIO CHRISTIAN EDGARDO

INGENIERIA DE REQUERIMIENTOSRequisitos funcionales y no funcionalesLos requisitos de software de documentosEspecificacin de RequisitosRequisitos de los procesos de ingenieraRequisitos de obtencin y anlisisRequisitos de validacinRequisitos de gestinTEMAS A TRATARINGENIERIA DE REQUERIMIENTOSLectura 1Ingeniera de RequerimientosEs el proceso de recopilar, analizar y verificar las necesidades del cliente para un sistema.Los requerimientos son la descripcin de los servicios del sistema y las limitaciones que se generan durante el proceso de ingeniera de requerimientos.Qu es un Requerimiento?Un requerimiento es una condicin o capacidad que necesita el usuario para resolver un problema o conseguir un objetivo determinado.

Los requerimientos pueden servir como una doble funcin

Puede ser la base para una oferta de contrato - por lo tanto debe estar abierto a la interpretacin;Puede ser la base del contrato en s - por lo tanto, debe definirse en detalle.Tipos de RequerimientosRequerimientos de usuarioDeclaraciones en lenguaje natural y los esquemas de los servicios que proporciona el sistema y sus limitaciones operacionales. Requerimientos del sistemaUn documento estructurado que establece la descripcin detallada de las funciones del sistema, los servicios y las limitaciones operacionales. Define lo que debe aplicarse, de manera que puede ser parte de un contrato entre el cliente y el contratista.

Requerimiento de usuario y de sistemaEJEMPLOS:

Un requisito de usuario -El MHC PMS (Sistema Gestor de Pacientes para el Cuidado de la salud) debe generar informes mensuales de gestin que muestren el costo de los medicamentos recetados por cada clnica durante ese mes.

Especificacin de requisitos del sistemaEn el ltimo da hbil de cada mes, se generar un resumen de los medicamentos recetados, su costo y las clnicas de prescripcin.

El sistema generar automticamente el informe para su impresin despus de las 17:30 en el ltimo da hbil del mes.

Un informe ser creado para cada clnica y se enumerarn: los nombres de los medicamentos individuales, el nmero total de recetas, el nmero de dosis prescritas y el costo total de los medicamentos prescritos.

Si los medicamentos estn disponibles en unidades de dosis diferentes (por ejemplo, 10 mg. 20mg. etc) se crear informes por separado para cada unidad de dosis.Especificacin de Requerimientos de los diferentes tipos de lectores *Requerimientos de usuarios:-Administradores clientes-Usuarios finales del sistema-Ingenieros clientes-Administradores contratistas-Arquitectos del sistema. *Requerimientos del sistema: -Usuarios finales del sistema -Ingenieros clientes -Arquitectos del sistema -Desarrolladores del software

Requerimientos funcionales y no funcionalesLos requerimientos funcionalesDeclaraciones de los servicios que debe proporcionar el sistema, la forma en que debe reaccionar a las entradas y la forma en que debe comportarse en situaciones particulares.Requerimientos no funcionaleslimitaciones en los servicios o funciones ofrecidas por el sistema como de tiempo, limitaciones en el proceso de desarrollo, normas, etcRequerimientos del dominioRequerimientos que se derivan del dominio de aplicacin del sistema y que reflejan las caractersticas de ese dominioRequerimientos FuncionalesDescribir las funciones o servicios del sistema.Depender del tipo de software, de los posibles usuarios y del tipo de sistema en el que el software se utiliza.Los requerimientos funcionales del sistema deben describir los servicios del sistema de forma detallada.

Requerimientos Funcionales de las Ejemplo (Sistema Gestor de Pacientes para el Cuidado de la salud) (MHC-PMS) Un usuario debe ser capaz de buscar las listas de citas para todas las clnicas.El sistema deber generar cada da, para cada clnica, una lista de los pacientes que se espera que asistan a las citas de ese da.Cada miembro del personal que usa el sistema se identifica por su nmero de empleado de 8 dgitos.Imprecision de los RequerimientosLos problemas surgen cuando los requerimientos no son declarados con precisin.Requerimientos ambiguos pueden interpretarse de diferentes maneras por los desarrolladores y usuarios.Considerar el trmino visores apropiadosIntencin del usuario - visor de propsito especial para cada tipo de documento diferente;Interpretacin del desarrollador - Proporcionar un visor de texto que muestra el contenido del documento.

AMBIGUEDAD

Integridad de requerimientos y consistenciaEn principio, los requerimientos deben estar completos y ser consistentes.CompletitudTodos los servicios solicitados por el usuario deben estar definidos.ConsistenciaNo debera haber conflictos o contradicciones en las descripciones de los requerimientos del sistema.En la prctica, es imposible producir un documento de requerimientos completo y consistente.

Requerimientos no FuncionalesDefinen las caractersticas que de alguna manera u otra pueden determinar la funcionalidad del sistema por ejemplo: interfaces de usuario, mantenimiento y seguridad.

Tipos de requerimientos no funcionales

Implementacin de requerimientos no funcionales. Los requerimientos no funcionales pueden afectar a la arquitectura general de un sistema en lugar de los componentes individuales.

-Por ejemplo, para asegurar que se cumplan los requisitos de rendimiento, puede se que tenga que organizar el sistema para reducir al mnimo las comunicaciones entre componentes.

Clasificacion de requerimientos no FuncionalesRequerimientos del productoEspecifican el comportamiento del producto obtenido: velocidad de Ejecucin, memoria requerida, porcentaje de fallos aceptablesRequerimientos organizacionalesSon una consecuencia de las polticas y procedimientos existentes en la organizacin: procesos estndar utilizados, de fechas de entrega, documentacin a entregar,.Requerimientos externosPresentan factores externos al sistema y a su proceso de desarrollo: interoperabilidad del sistema con otros, requisitos legales, ticos,

Ejemplos de requisitos no funcionales en el (Sistema Gestor de Pacientes para el Cuidado de la salud) (MHC-PM)Requerimientos del producto -El PMS MHC-estarn a disposicin de todas las clnicas durante el horario normal de trabajo (de lunes a viernes, desde 0830 hasta 17,30). El tiempo de inactividad dentro del horario normal de trabajo no podr exceder de cinco segundos en un da.Requerimientos organizacionales -Los usuarios del sistema MHC-PMS deber autenticarse usando su documento de identidad de autoridad sanitaria .Requerimientos externos - El sistema deber aplicar las disposiciones de privacidad del paciente segn lo establecido en HStan-03-2006-priv.

Metas y requerimientosLos requerimientos no funcionales pueden ser muy difciles de precisar y los imprecisos pueden ser difciles de verificar.MetaLa facilidad de uso del sistema.Requerimiento no funcional verificableUna declaracin tangible puede ser objetivamente probada.Las metas son provechosas para los desarrolladores pues transportan las intenciones de los usuarios del sistema.

Requisitos de usabilidadEl sistema debera ser fcil de utilizar por el personal mdico y debe organizarse de tal modo que los errores de usuario son minimizadas. (Meta)El personal mdico debe ser capaz de utilizar todas las funciones del sistema despus de cuatro horas de entrenamiento. Despus de este entrenamiento, el nmero medio de errores cometidos por los usuarios experimentados no exceder de dos por cada hora de uso del sistema. (Comprobable requisito no funcional)Mtricas para los requerimientos

Requerimientos del DominioPueden ser requerimientos funcionales nuevos, restringir los existentes o establecer cmo se deben ejecutar clculos particulares.Si los requerimientos del dominio no se satisfacen, puede ser imposible hacer que el sistema funcione de forma satisfactoria.

Sistema de proteccin deTren .Este es un requisito de dominio de un sistema de proteccin de tren: .La desaceleracin del tren se calcular como:Dtren = Dcontrol + Dgradiente

donde Dgradient es 9.81ms2 * compensado (gradiente / alfa) y los valores de 9.81ms2 / alfa son conocidos por diferentes tipos de trenes.

. Es difcil para un no especialista entender las implicaciones de esto y cmo interacta con otros requisitos.

Problemas de requerimientos de dominiosComprensibilidad: -Los requisitos se expresan en el lenguaje del dominio de aplicacin es decir en el lengueaje del ambiente en que se desarrolla el proyecto;-Esto a menudo no es entendida por los ingenieros de desarrollo de software del sistema

Implcito -Los expertos en el dominio pueden dejar fuera de un requerimiento informacin, sencillamente porque para ellos es obvia, por lo que no piensan en hacer explcitos los requerimientos del dominio.Puntos claveLos requerimientos determinan lo que debe hacer el sistema y definen las restricciones en su funcionamiento y aplicacin.

Los requerimientos funcionales son declaraciones de los servicios que el sistema debe proporcionar o son descripciones de cmo deben llevarse a cabo algunos clculos.

Los requerimientos no funcionales restringen el sistema en desarrollo y el proceso de desarrollo que se debe utilizar.

A menudo se refieren a las propiedades emergentes del sistema y por lo tanto se aplican al sistema como un todo.INGENIERIA DE REQUERIMIENTOSLectura 2Documentos de los requisitos de software El documento de requerimientos de software es la declaracin oficial de lo que se requiere de los desarrolladores del sistema.Debe incluir tanto una definicin de los requisitos del usuario y una especificacin de los requisitos del sistema.No es un documento de diseo. Siempre que sea posible, se debe establecer lo que el sistema debe hacer en lugar de cmo debe hacerlo.Mtodos giles y requisitosMuchos mtodos giles sostienen que la produccin de un documento de requisitos es una prdida de tiempo ya que las necesidades cambian constantemente.El documento es por lo tanto siempre anticuado.Mtodos tales como los usados por XP incrementan los requisitos de ingeniera y los expresan como historias de usuario (que se examinan en el captulo 3).

Usuarios de un documento de requisitos

Variabilidad del documento de requisitoLa informacin contenida en el documento requisitos depende del tipo de sistema y el enfoque de desarrollo utilizado.

Los sistemas desarrollados de forma incremental, mayormente, tienen menos detalles en el documento de requerimientos.

Los documentos de requerimientos estndares han sido diseados( por ejemplo el de IEEE estndar). Estos son principalmente aplicables a grandes proyectos de ingeniera de sistemas.Estructura de un documento de requerimientos

Especificacin de requerimientosEs el proceso de describir las necesidades del usuario y del sistema en un documento de requisitos.

Los requisitos del usuario tienen que ser comprensibles por los usuarios finales y los clientes ,que no tienen una formacin tcnica.

Los requisitos del sistema constituyen requisitos ms detallados y puede incluir informacin ms tcnica.

Los requisitos pueden formar parte de un contrato para el desarrollo del sistema, por tanto, es importante que estos sean tan completos como sea posible.Requerimientos y diseoEn principio, los requerimientos deben indicar qu debe hacer el sistema y el diseo debe describir cmo se hace esto.

En la prctica, los requerimientos y el diseo son inseparablesUna arquitectura de sistema puede ser diseada para estructurar los requerimientos;El sistema puede inter-operar con otros sistemas que generan requerimientos de diseo;El uso de un diseo especfico puede ser un requerimiento del dominio.

Especificacin del lenguaje naturalLos requisitos se escribe como frases en lenguaje natural complementados con diagramas y tablas.Se utiliza para escribir los requisitos, ya que es expresivo, intuitivo y universal. Esto significa que los requisitos puede ser entendido por los usuarios y clientes.Pautas para la escritura de Los requisitosInventar un formato estndar y usarlo para todas los requerimientos.Use lenguaje de manera consistente para con los requerimientos obligatorios, debera usarse para con los requerimientos deseable.Utilice la seleccin de texto para identificar las piezas clave del requerimiento.Evite el uso de jerga informtica.Incluya una explicacin (lgica) de por qu un requerimiento es necesario.Problemas con el lenguaje naturalFalta de claridad-La precisin es difcil sin hacer el documento de difcil lectura.Confusin de requerimientos.-Los requisitos funcionales y no funcionales tienden a ser mezclados.Requisitos de amalgamacin-Varios requisitos diferentes pueden ser expresados juntos.Ejemplo de requisitos para el sistema de software de la bomba de insulinaEl sistema deber medir el azcar en la sangre y administrar insulina si se requiere, cada 10 minutos. (Los Cambios del azcar en la sangre son relativamente lentos ,as ser innecesario hacer mediciones frecuentes; pero las medicin menos frecuente podran conducir a niveles innecesariamente altos de azcar.)El sistema deber ejecutar una rutina de prueba automtica cada minuto para probar las condiciones y medidas correspondientes definidos . (Una rutina de auto-prueba puede descubrir problemas de hardware y software y alertar al usuario el hecho de que un funcionamiento normal puede ser imposible.)Especificaciones estructuradasEs un planteamiento para escribir requisitos donde se limita la libertad del escritor de los requerimientos y adems los requisitos estn escritos de una manera estndar.Esto funciona bien para algunos tipos de requerimientos ,por ejemplo, requisitos para el sistema de control integrado; pero a veces es demasiado rgido para la escritura de los requerimientos del negocio del sistema.Especificaciones basadas en formularioDefinicin de la funcin o entidad.Descripcin de las entradas y de dnde vienen.Descripcin de las salidas y hacia dnde van.Indicacin de otras entidades requeridas.Descripcin de la accin a tomar.Pre y post condiciones (si es apropiado).Descripcin de los efectos colaterales (si los hubiera) de la operacin.

Especificacin estructurada del requerimiento de una bomba de insulina

Especificacin TabularUtilizado para complementar el lenguaje natural.Particularmente til cuando usted tiene que definir una serie de posibles cursos de accin alternativos.Por ejemplo, los sistemas de bomba de insulina basa sus clculos en la tasa de cambio de nivel azcar en la sangre y la especificacin de tabla explica cmo calcular el requerimiento de insulina para diferentes escenarios.Procesos de la ingeniera de requerimientosLos procesos utilizados para la ingeniera de requerimientos varan ampliamente dependiendo en el dominio de la aplicacin, las personas implicadas y la organizacin que desarrolla los requerimientos.

Sin embargo, hay una serie de actividades genricas comunes a todos los procesosObtencin de requerimientos;Anlisis de requerimientos;Validacin de requerimientos;Gestin de requerimientos.

En la prctica, la ingeniera de requerimiento es un a actividad iterativa en el cual estos procesos se intercalan.Una vista en espiral del proceso de ingeniera de requerimientos

Obtencin y anlisis de requerimientosA veces llamado obtencin o descubrimiento de requerimientos.Implica personal tcnico que trabaja con los clientes para conocer el dominio de aplicacin.Puede implicar a los usuarios finales, administradores, ingenieros involucrados en el mantenimiento, expertos de dominio, los sindicatos, etc. Estos se llaman stakeholders (afectados por el sistema).

Problemas de anlisis de requerimientosLos stakeholders no saben lo que realmente quieren.Los afectados por el sistema expresan los requerimientos en sus propios trminos.Las diferentes partes interesadas (stakeholders) pueden tener requerimientos conflictivos.Factores organizacionales y polticos pueden influir en los requerimientos del sistema.Las requerimientos cambian durante el proceso de anlisis. Pueden surgir nuevos stakeholders y el entorno empresarial cambia.Obtencin y anlisis de requerimientosLos ingenieros de software trabajan con una serie de stakeholders del sistema para obtener informacin sobre el dominio de aplicacin, los servicios que el sistema debe proporcionar el rendimiento requerido del sistema, las limitaciones de hardware, otros sistemas, etc.

Las etapas son: -descubrimiento de requisitos -clasificacin y organizacin de requisitos -priorizacin y negociacin de requisitos -especificacin de requisitosProceso de obtencin y anlisis de requerimiento

Actividades del procesoDescubrimiento de requerimientosInteractuar con las partes interesadas para conocer sus necesidades. Los requerimientos del dominio son tambin descubiertos en esta etapa.

Clasificacin y organizacin de requerimientosAgrupa los requerimientos relacionados y los organiza de un modo coherente.

Ordenacin por prioridades y negociacinPriorizar requerimientos y resolver los conflictos entre los mismos.

Documentacin de requerimientosLos requerimientos son documentados e ingresados en la siguiente iteracin.Puntos clavesEl documento de requerimientos de software es una declaracin acordada de los requisitos del sistema. Debe estar organizado de forma que tanto los clientes del sistema como desarrolladores de software pueden utilizarlo.El proceso de ingeniera de requerimientos es un proceso iterativo que incluye la validacin, especificacin y obtencin de requerimientosEl anlisis y obtencin de requisitos es un proceso iterativo que se puede representar como una espiral de actividades : descubrimiento de requisitos, clasificacin y organizacin de requisitos, negociacin de los requisitos y documentacin de los requisitos.INGENIERIA DE REQUERIMIENTOSLectura 3Descubrimiento de requerimientosProceso de recopilacin de informacin sobre los sistemas propuestos y los existentes y extraer los requerimientos de usuario y del sistema a partir de esta informacin. Se debe tener en cuenta:La interaccin de los stakeholders del sistema de los administradores con los reguladores externos.Los sistemas normalmente tienen una serie de stakeholders.STAKEHOLDERS Y REGULADORES EXTERNOS

Stakeholders en los MHC-PMSLa informacin de los pacientes es registrada en el sistema.Los mdicos se encargan de evaluar y tratar a los pacientes.Los recepcionistas mdicos administran las citas de los pacientes.El personal es responsable de la instalacin y mantenimiento del sistema.

En este ejemplo se nota que tanto los stakeholders (clientes como usuarios) se ven afectados por las decisiones que se toman en el MHC-PMS.EntrevistaLas entrevistas formales e informales con los interesadas, son parte de la mayora de procesos de Ingeniera de Requerimiento.Tipos de entrevistas:-Entrevistas cerradas ,basadas en una lista de preguntas pre-determinadas.-Entrevistas Abiertas, en las que se exploran diversos temas con las partes interesadas.Entrevistadores eficaces-Los entrevistadores deben ser de mentalidad abierta, dispuestos a escuchar a los Stakeholders.

En resumen las Entrevistas son importantes para entender mejor la interaccin entre los Stakeholders y el sistema.EscenariosLos escenarios son ejemplos de la vida real de cmo un sistema puede ser utilizado.Deben incluir:Una descripcin de la situacin inicial;Una descripcin del flujo normal de los acontecimientos;Una descripcin de lo que puede salir mal y cmo manejarlo;Informacin acerca de otras actividades;Una descripcin del estado del sistema cuando finalice el escenario.En otras palabras son las SIMULACIONES de los posibles escenarios que se pueden presentar en el flujo de los AcontecimientosEscenario para recopilar la historia clnica en el MHC-PMS

Escenario para recopilar la historia clnica en el MHC-PMS

Casos de usoSon un escenario basado en la tcnica de UML (Lenguaje Unificado de Modelado) que permite identificar a los actores interactuantes y que describen la interaccin propiamente dicha.

Un conjunto de casos de uso deben describir todas las posibles interacciones con el sistema.

EJEMPLO DE CASOS DE USO

EtnografaLos analistas pasan un considerable tiempo observando y analizando cmo la gente trabaja realmente.Se pueden observar factores sociales y organizacionales de importancia.Estudios etnogrficos han mostrado que el trabajo es generalmente ms rico y ms complejo de lo que sugieren los modelos de sistemas simples.

Alcance de la etnografaLos requerimientos son derivados de la forma en que las personas trabajan ,en lugar de la forma, en que las definiciones de proceso ,sugieren que se debe trabajar.Los requerimientos se derivan de la cooperacin y el conocimiento de las actividades de otras personas.

La etnografa es eficaz para la comprensin de los procesos existentes, pero no puede identificar las nuevas caractersticas que se deben ser agregadas a un sistema.EJEMPLOLos requerimientos se derivan de la cooperacin y el conocimiento de las actividades de otras personas.Los controladores del trafico areo pueden utilizar el conocimiento del trabajo de otros controladores para predecir el numero de aviones que entrara a su sector de control. Despus modifican sus estrategias de control dependiendo del volumen de trabajo pronosticado. Por lo tanto, un sistema automtico de control de trafico areo debe permitir a los controladores en un sector tener alguna visibilidad del trabajo en los sectores adyacentes.Validacin de requerimientosEs el proceso de comprobar la validez de los requerimientos que definen el sistema, para lo que el cliente realmente quiere.

Los costos de error en los requerimientos son muy altos, por lo que la validacin es muy importanteReparar un error en los requerimientos despus de la entrega puede costar hasta 100 veces ms que la reparacin de un error en la implementacin.

Verificacin de los requerimientosVerificaciones de validez. El sistema proporciona los servicios que mejor responden a las necesidades del cliente?Verificaciones de consistencia. Hay conflictos entre los requerimientos?Verificaciones de completitud. Son todas las funciones requeridas por el cliente?Verificaciones de realismo. Pueden implementarse los requerimientos dada la disponibilidad de presupuesto y tecnologa?Verificabilidad. Pueden ser verificados los requisitos?

Tcnicas de validacin de requerimientosRevisiones de requerimientosAnlisis sistemtico manual de los requerimientos.Desarrollo de PrototiposUsando un modelo ejecutable del sistema para verificar los requerimientos. Generacin de casos de pruebaDesarrollar pruebas para los requerimientos del usuario y comprobar que stos deben poder probarse.

DIFERENCIA ENTRE PROTOTIPOS Y CASOS DE PRUEBALos PROTOTIPOS, son un mtodo de validacin ampliamente utilizado en muchas disciplinas , el prototipado consiste en la creacin de una maqueta o versin del producto final. Los CASOS DE PRUEBA, son artefactos bien definidos en el contexto de la prueba del software. Durante la Validacin de requerimientos, los casos de prueba se utilizan del mismo modo que durante la prueba de software.

Evaluacin de requerimientosUna evaluacin de requerimientos es un proceso manual que involucra a personas tanto de la organizacin del cliente como del contratista.Tanto el cliente como el personal contratista deben participar en las evaluaciones.Las evaluaciones pueden ser formales (con documentos completos) o informales. Una buena comunicacin entre desarrolladores, clientes y usuarios pueden resolver los problemas en una etapa inicial o temprana.

Verificacin de evaluacionesVerificabilidad. Puede probarse el requerimiento de modo realista?Comprensibilidad. Es el requisito comprensible?Rastreabilidad. Est claramente definido el origen del requerimiento?Adaptabilidad. Puede modificarse el requerimiento sin causar un gran impacto en otros requerimientos?

Gestion de requerimientosEs el proceso de gestionar la evolucin de los requerimientos durante el proceso de ingeniera de requerimientos y el desarrollo del sistema.

Nuevos requerimientos emergen durante y despus del proceso de desarrollo del sistema.

Es necesario hacer un seguimiento de los requerimientos individuales y mantener vnculos entre las necesidades secundarias para evaluar el impacto de los cambios en los requisitos. Cambios en los requerimientosEl entorno tcnico y empresarial del sistema siempre cambia despus de la instalacin.

-Un nuevo hardware puede ser introducido, puede que sea necesario para interconectar el sistema con otros sistemas; pero este hardware debe acatar los mismos reglamentos del sistema.

Las personas que pagan por el sistema y los usuarios de este sistema son rara vez las mismas personas.

-Los clientes del sistema pueden especificar los requerimientos desde una perspectiva empresarial que entra en conflicto con los requerimientos de los usuarios finales.

Planificacin de la gestin de requerimientosEstablece el nivel de detalle de la gestin de requisitos que se requiere.Decisiones de la gestin de requerimientos:-Identificacin de requerimientos: Cada requisito debe ser identificado de forma nica, ya que puede ser confundido con otros requisitos.-Un proceso de gestin del cambio: Este es el conjunto de actividades que evalan el impacto y el costo de los cambios.-Las polticas de rastreo:La cantidad de informacin acerca de las relaciones de los requerimientos que se mantienen;-Herramientas de apoyo:Las herramientas que se pueden utilizar van desde sistemas especializados de gestin de requisitos a hojas de clculo y sistemas de bases de datos simples.;

Gestin del cambio de requerimientosLa decisin si un cambio de requisitos debe ser aceptado*Anlisis del problema y especificacin de cambio : Durante esta etapa, el problema o la propuesta de cambio ,se analiza para comprobar que es vlido.

*Anlisis de cambio y clculo de costos: El efecto del cambio propuesto se evalu a travs de la informacin de trazabilidad y el conocimiento general de los requisitos del sistema. Una vez que este anlisis se ha completado, se toma una decisin si proceder o no con el cambio de los requisitos.

*Implementacin del cambio: Modificar el documento de requerimientos y otros documentos a fin de reflejar el cambio.Gestin del cambio de requerimientos

Puntos clavesUsted puede usar una serie de tcnicas para la obtencin de requerimientos que incluyen: entrevistas, escenarios, casos de uso y la etnografa.La validacin de requerimientos es el proceso de comprobar la validez, la coherencia, la integridad, el realismo y la verificabilidad de los requerimientos.Cambios en las empresas, organizativas o tcnicas inevitablemente llevan a cambios en los requerimientos del sistema . La gestin de requerimientos incluye la planificacin y gestin del cambio.