Metodologa Gestin de Requerimientos

El xito de un proyecto de software radica, entre otros factores, en la eleccin correcta de un proceso que conduzca a desarrollar un buen sistema de software. La eleccin de la metodologa adecuada es ms importante que utilizar las mejores y ms potentes herramientas
La metodologa propuesta para la Gestin de Requerimientos contiene los siguientes procesos, los cuales estan definidos en cada uno de los captulos que hacen parte de esta metodologa.

Captulo 1 "IDENTIFICACIN DE NECESIDADES CON EL CLIENTE"

Si los requerimientos se enfocan a describir las necesidades del cliente, entonces es lgico
que para recabarlos haya que obtener la informacin de primera mano. Esto es, mediante entrevistas con el cliente u obteniendo la documentacin que describa la manera que el cliente desea como funcione el sistema de software. Las necesidades y / o requerimientos del cliente evolucionan con el tiempo y cada cambio involucra un costo. Por eso es necesario tener archivada una copia de la documentacin original del cliente, as como cada revisin o cambio que se haga a esta documentacin.

Para que la metodologa sea efectiva en los puntos descritos se definieron las siguientes actividades que se deben desarrollar para la correcta identificacin de necesidades de los clientes:

Obtener y Analizar informacin de las necesidades del cliente

Para hacer una correcta identificacin de los clientes y poder realizar un anlisis de manera asertiva se pueden implementar una serie de tcnicas de acuerdo al cliente con el que se est tratando. Como apoyo a esta etapa la metodologa presenta algunas tcnicas con las que se pueden identificar las necesidades de manera tal que el anlisis sea apropiado para satisfacer las expectativas del cliente. Estas tcnicas se encuentran en el Capitulo 2. Tcnicas para identificar requerimientos.

Definicin del alcance

La definicin del alcance tiene como propsito describir y delimitar claramente las necesidades del cliente, las cuales pretenden ser cumplidas con el proyecto. Es importante para la definicin del alcance la identificacin de los siguientes aspectos:

Los entregables que hacen parte del alcance. Se recomienda describir y listar los entregables finales, principalmente los que deben ser aprobados por el cliente. Nota: no mencionar documentos propios del proyecto como cronograma, estimaciones, entre otros.

Los tipos de datos que estn en el alcance y fuera de l. Los tipo de datos se refieren a la categora del negocio de los entregables tales como datos financieros, datos de ventas, datos de los empleados, etc. Las fuentes de datos (bases de datos) que estn en el alcance y fuera de l. Esto es similar a los tipos de datos, excepto que ahora se est refiriendo a los datos agregados tales como base de datos de clientes, Contabilidad general, sistema de facturacin y cobranza, etc. reas involucradas en el alcance y fuera de l. En algunos casos, las reas involucradas en el proyecto ayudan a delimitar el alcance. Condiciones fuera del alcance. Se recomienda como punto de claridad y contraste al describir entregables que no sern creados, qu organizaciones no sern impactadas, qu facilidades y funciones no sern incluidas, entre otros aspectos.

Fuentes de informacin claves

Cualquier informacin creada anteriormente debe ser usada como base para definir el alcance de manera mas detallada. Si por alguna razn no se cuenta con suficiente informacin para la definicin del alcance, se debe buscar apoyo con el patrocinador para reunir informacin adicional. Si se tienen objetivos del proyecto, se recomienda tenerlos en cuenta para ayudar a afinar el alcance. Por definicin, se deben crear uno o ms entregables para cumplir cada objetivo, y definir los entregables del proyecto es uno de los aspectos principales del alcance del proyecto.

Recomendaciones para definir el alcance

Algunas recomendaciones para la definicin del alcance son: Desarrollar un escrito o documento formal. Detallar claramente qu actividades y procesos son parte del proyecto, es decir, el trabajo que debe ser realizado con el fin de entregar un producto con las caractersticas y especificaciones solicitadas. Definir los criterios que se utilizarn para determinar si el proyecto o fase ha finalizado exitosamente, es decir, los criterios de aceptacin. Al definir el alcance, tener en mente que lo que no est en el alcance est fuera del proyecto. Formalizar la aceptacin del alcance con el cliente.

Beneficios de una buena definicin

El alcance marca la pauta para la toma de decisiones futuras y realizacin de actividades a nivel Operativo y nos ayuda a: Mejorar la precisin en las estimaciones de tiempo, costo y recursos. Facilitar la asignacin clara de recursos y responsabilidades. Definir la lnea base para la medicin del desempeo y control Identificar, tanto el equipo de proyecto como el cliente, el objetivo final del proyecto y sus entregables. Desarrollar y confirmar un entendimiento comn del proyecto entre ambas partes, cliente y equipo de proyecto.

 Asegurar que el proyecto incluye todo el trabajo requerido y solamente el trabajo requerido para terminar exitosamente. "Asegurar que el proyecto incluye todo el trabajo requerido para terminar exitosamente."

Entregable de Identificacin de Necesidades

El presente documento ser trabajado de la mano del cliente, principalmente cuando no se cuenta con documentacin previa que sirva como base para aclarar las necesidades del cliente.

Formato

MR_002_Identificacion de Necesidades (Ver Formato)

Objetivo Presentar una descripcin de lo que se requiere desde la perspectiva del cliente para resolver la necesidad u oportunidad de mejora identificada. El presente documento ser trabajado de la mano del cliente.

Captulo 2 TCNICAS PARA IDENTIFICAR REQUERIMIENTOS

En la actualidad las organizaciones enfocadas al desarrollo de aplicaciones de software utilizan

diferentes herramientas que permiten facilitar la fase de identificacin de requerimientos, puesto que se presta mayor atencin a las necesidades que se identifican en todas las fases del ciclo de vida del sistema; para as obtener un mejor aprovechamiento, entendimiento, y rendimiento al momento que entre en ejecucin el sistema que se est desarrollando.

Las organizaciones actuales utilizan mltiples herramientas para el apoyo de la identificacin de los requerimientos, sin pensar si son las ms convenientes para el proyecto que se est desarrollando, por lo tanto a continuacin se encontraran las tcnicas que apoyen una correcta identificacin de los requerimientos para los proyectos de desarrollo de software.

A continuacin se especifican cada una de las tcnicas utilizadas: Tcnicas generales para la identificacin de requerimientos Tcnicas especficas para la identificacin de requerimientos Tcnicas para Identificar Requisitos Funcionales y No Funcionales Tcnicas de investigacin de los atributos de las necesidades de los clientes

A continuacin se presenta documento de uso opcional como apoyo para identificacin y definicin de requerimiento:

Formato MR_002_Entrevista (Ver formato)

Objetivo
Sugerir las preguntas que permitan detallar el requerimiento.

1. Tcnicas generales para la identificacin de requerimientos

Contenidos
1. 1 Entrevista 2. 2 Lluvia de ideas 3. 3 Cuestionarios
Las tcnicas agrupadas como generales son las que permiten investigar aspectos generales para posteriormente ser especificados con un mayor detalle con el apoyo de tcnicas ms especficas. Estas tcnicas son ms abiertas y requieren ser adecuadamente orientadas para cubrir la informacin que se requiere capturar, es importante que para sacar el mayor provecho de estas tcnicas se debe tener un dialogo lo ms abierto posible entre las organizaciones de desarrollo de software y las empresas cliente.

Entrevista
Estas tcnicas son muy utilizadas para la recoleccin de opiniones, criterios o descripciones sobre diferentes actividades. Se lleva a cabo mediante conversaciones estructuradas donde es fundamental que la relacin con el cliente este basada en la confianza para dar a conocer la informacin de la manera mas detallada.

Antes de iniciar una entrevista es importante tener en cuenta los siguientes Tips a tener en cuenta, no es obligacin realizarlas todas pero si es recomendable estudiar cuales son las que ms se aplica para cada organizacin o cada proyecto.

1.

Estudiar el tipo de personas a las cuales se les realizar la entrevista.

2. Estudiar como ser el entorno donde se llevara a cabo la entrevista para identificar que tan confortables estarn las personas y as obtener la informacin de la manera ms eficiente. 3. Estudiar como es la manera de hablar de las personas individualmente o en un equipo de trabajo. 4. Verificar que las personas tengan la disponibilidad para dar a conocer las necesidades que posterior a esto se puedan convertir en requerimientos. 5. Revisar como es la relacin del cliente con la organizacin que realizar la identificacin de los requerimientos, esto con el fin de facilitar el trabajo y la disposicin de ambas partes. 6. Entender que es importante obtener la mayor informacin para la definicin de los requerimientos, teniendo en cuenta que nada es obvio para las organizaciones de desarrollo de software.

Lluvia de ideas
Esta tcnica es abierta y se utiliza para explorar necesidades iniciales con la ayuda de la identificacin de ideas de todas las personas que hacen parte del equipo de apoyo para la identificacin de los requerimientos. Es utilizada para investigar nuevos servicios o necesidades que no son claramente identificadas. Algunos Tips para tener en cuenta cuando se realice una lluvia de ideas:

1. Escoger un sitio tranquilo que permita que las personas involucradas se sientan cmodas y dispuestas para dar a conocer sus ideas. 2. 3. Tomar la iniciativa para iniciar una reunin enfocada en la confianza. Tomar nota de las ideas que las personas expresan en los equipos de trabajo.

Tener una preparacin sobre el tema que se va a desarrollar en la lluvia de ideas.

Cuestionarios
Esta tcnica puede ir dirigida a un pblico especfico o general, lo que permite obtener una informacin mayor, ya que se tiene la posibilidad de involucrar ms personas para el desarrollo de los cuestionarios y que estos tengan diferentes puntos de vista. Lo importante es tener en cuenta que se debe tener un mayor cuidado en la seleccin de los encuestados y de la forma en que se pregunta para obtener respuestas concretas y confiables.

2. Tcnicas especficas para la identificacin de requerimientos

Contenidos
1. 1 Observacin 2. 2 Escenarios

Las tcnicas agrupadas como especificas son las que permiten complementar las tcnicas generales, para as obtener mayor detalle y eliminar ambigedad en la informacin inicial.

Observacin
Esta tcnica permite obtener informacin directa sobre la forma en que se realizan las actividades. Es una tcnica que sirve para revisar que no existen omisiones o interpretaciones errneas sobre el proceso que se realiza. Hay que tener en cuenta que se debe utilizar si el cliente lo permite y si el proyecto as lo amerita.

Escenarios

Esta tcnica permite conocer el comportamiento del producto ante determinados eventos considerando los datos, acciones y excepciones que se pueden presentar. El anlisis de casos de uso es un ejemplo de aplicacin de esta tcnica.

3. Tcnicas para Identificar Requisitos Funcionales y No Funcionales

Contenidos
1. 1 Identificacin de Requerimientos funcionales 2. 2 Identificacin de Requerimientos no funcionales 3. 3 Aspectos a tener en cuenta en la identificacin de requerimientos funcionales y no funcionales 4. 4 Identificacin de elementos 5. 5 Preguntas generales:

Ya que los requerimientos de sistemas de software se clasifican en funcionales y no funcionales, se deben tener en cuenta las siguientes tcnicas para la identificacin correcta.
Identificacin de Requerimientos funcionales
Los requerimientos funcionales son declaraciones de los servicios que proveer el sistema, de la manera en que ste reaccionar a entradas particulares. En algunos casos, los requerimientos funcionales de los sistemas tambin declaran explcitamente lo que el sistema no debe hacer. Muchos de los problemas de la ingeniera de software provienen de la imprecisin en la especificacin de requerimientos. Para un desarrollador de sistemas es natural dar interpretaciones de un requerimiento ambiguo con el fin de simplificar su implementacin. Sin embargo, a menudo no es lo que el cliente desea. Se tienen que estipular nuevos requerimientos y se deben hacer cambios al sistema, retrasando la entrega de ste e incrementando el costo. En principio, la especificacin de requerimientos funcionales de un sistema debe estar completa y ser consistente. La complecin significa que todos los servicios solicitados por el usuario estn definidos. La consistencia significa que los requerimientos no tienen definiciones contradictorias. En la prctica, para sistemas grandes y complejos, es imposible cumplir los requerimientos de consistencia y complecin. La razn de esto se debe parcialmente a la complejidad inherente del sistema y parcialmente a que los diferentes puntos de vista tienen necesidades inconsistentes. Estas inconsistencias son obvias cuando los requerimientos se especifican por primera vez. Los problemas emergen despus de un anlisis profundo. Una vez que stos se hayan descubierto en las diferentes revisiones o en las fases posteriores del ciclo de vida, se deben corregir en el documento de requerimientos. Identificacin de Requerimientos no funcionales Son aquellos requerimientos que no se refieren directamente a las funciones especficas que entrega el sistema, sino a las propiedades emergentes de ste como la fiabilidad, la respuesta en el tiempo y la capacidad de almacenamiento. De forma alternativa, definen las restricciones del sistema como la capacidad de los dispositivos de entrada/salida y la representacin de datos que se utiliza en la interface del sistema. Los requerimientos no funcionales surgen de la necesidad del usuario, debido a las restricciones en el presupuesto, a las polticas de la organizacin, a la necesidad de

interoperabilidad con otros sistemas de software o hardware o a factores externos como los reglamentos de seguridad, las polticas de privacidad, entre otros. Estos diferentes tipos de requerimientos se clasifican de acuerdo con sus implicaciones. Requerimientos del producto. Especifican el comportamiento del producto; como los requerimientos de desempeo en la rapidez de ejecucin del sistema y cunta memoria se requiere; los de fiabilidad que fijan la tasa de fallas para que el sistema sea aceptable; los de portabilidad y los de usabilidad. Requerimientos organizacionales. Se derivan de las polticas y procedimientos existentes en la organizacin del cliente y en la del desarrollador: estndares en los procesos que deben utilizarse; requerimientos de implementacin como los lenguajes de programacin o el mtodo de diseo a utilizar, y los requerimientos de entrega que especifican cundo se entregar el producto y su documentacin. Requerimientos externos. Se derivan de los factores externos al sistema y de su proceso de desarrollo. Incluyen los requerimientos de interoperabilidad que definen la manera en que el sistema interacta con los otros sistemas de la organizacin; los requerimientos legales que deben seguirse para asegurar que el sistema opere dentro de la ley, y los requerimientos ticos. Estos ltimos son impuestos al sistema para asegurar que ser aceptado por el usuario. En la prctica, la especificacin cuantitativa de requerimientos es difcil. A los clientes no les es posible traducir sus metas en requerimientos cuantitativos; para algunas de stas, como las de mantenimiento, no existen mtricas que se puedan utilizar; el costo de verificar de forma objetiva los requerimientos no funcionales cuantitativos es muy alto. En principio, los requerimientos funcionales y no funcionales se diferencian en el documento de requerimientos. En la prctica, esto es difcil. Si un requerimiento no funcional se declara de forma separada a los funcionales, algunas veces es difcil ver la relacin entre ellos. Si se declaran con los requerimientos funcionales, es difcil separar las condiciones funcionales y no funcionales e identificar los requerimientos que se refieren al sistema como un todo. Se debe hallar un balance apropiado que dependa del tipo de sistema a especificar. Sin embargo, los requerimientos que claramente se refieren a las propiedades emergentes del sistema se deben resaltar. Esto se hace colocndolos en una seccin aparte o diferencindolos, de alguna forma, de los otros requerimientos del sistema.

Aspectos a tener en cuenta en la identificacin de requerimientos funcionales y no funcionales

Requerimientos bsicos: se estructura su identificacin al buscar respuestas a preguntas como: Cul es el proceso bsico de la empresa? Qu datos utiliza o produce este proceso? Cules son los lmites impuestos por el tiempo y la carga de trabajo? Qu controles de desempeo utiliza? Siempre se debe comenzar con lo bsico. Cuando se hacen preguntas y se reciben respuestas, se proporcionan antecedentes sobre detalles fundamentales relacionados con el sistema y que sirven para describirlo. Las siguientes preguntas son de utilidad para adquirir la comprensin necesaria: Cul es la finalidad de la actividad dentro de la empresa? Qu pasos se siguen para realizarla?

 Dnde se realizan estos pasos? Quines los realizan? Cunto tiempo tardan en efectuarlos? Con cunta frecuencia lo hacen? Quines emplean la informacin resultante?

Identificacin de elementos

Durante esta, se debe identificar muy claramente los siguientes elementos:

Procesos Flujos de datos entre procesos Datos de cada flujo de datos Bases de datos Datos de las bases de datos

Preguntas generales:
Cuntos empleados laboran para la organizacin en el rea(s) que se pretende desarrollar el sistema; o sea, cuntos tienen relacin directa con el proyecto Cules son las personas claves en el sistema? Por qu son importantes? Existen obstculos o influencias de tipo poltico que afectan la eficiencia del sistema? Existen manuales de procedimientos, polticas o lineamientos de desempeo documentados oficial o no oficialmente?. Si los hay, Se cumplen en forma cabal en el 100% de las ocasiones?, es decir, se respetan dichos procedimientos? Existen mtodos para evadir el sistema?, Por qu se presentan? Qu reas necesitan un control especfico? Qu criterios se emplean para medir y evaluar el desempeo?

4. Tcnicas de investigacin de los atributos de las necesidades de los clientes

Contenidos
1. 2. 3. 4. 1 Grupos focales 2 Entrevista individual 3 Anlisis contextual 4 Clientes piloto

En realidad, quien conoce sus necesidades es el cliente y, consecuentemente, lo que se hace es preguntarle a l sobre cada una de ellas, con el objeto de clasificar y ponderar su importancia.
Este proceso de investigacin debe ser suficientemente inteligente para conseguir respuestas que permitan elevar realmente el nivel de competitividad de la solucin buscada. En definitiva, se recomienda escuchar y entender lo que los estudiosos de la calidad llaman la voz del cliente. Bajo una perspectiva de innovacin proactiva, para la identificacin de necesidades, se requieren mtodos en los cuales el cliente pueda compartir su esfera de conocimientos de aplicacin con mayor riqueza y detalle que en los simples informes de reclamacin. Entre estos mtodos estn:

Grupos focales
Los grupos focales se conforman reuniendo a un grupo seleccionado de clientes, conjuntamente con un moderador que va a conducir un debate de grupo sobre una serie de aspectos y cuestiones concretas en las que se focaliza la discusin. Esta tcnica de investigacin alcanza mayor profundidad que la encuesta y que los informes anteriores. En la reunin se establece, de por s, una relacin de afinidad por la que todas las respuestas giran en torno a la situacin a analizar. El contexto de uso y aplicacin del producto y las caractersticas que se estudian van quedando claros para todos, ms si desde el principio el moderador tiene la habilidad de exponer el propsito de la reunin con nitidez. Se elimina, pues, uno de los problemas de la encuesta. Al mismo tiempo, se consigue ms informacin y de mayor calidad que en los informes. Primero, porque se cuenta con expertos elegidos e identificados, que pueden matizar y contrastar las respuestas entre ellos, aportando puntos de vista especficos de sus mbitos de aplicacin y segundo, porque en todo momento se pueden aclarar dudas y profundizar en el tema hasta lograr su total comprensin. La habilidad para conducir el debate, sugerir y plantear los temas, atemperar las discusiones sobre aspectos banales y centrarla en los relevantes, es una cuestin que va a determinar la cantidad y calidad de la informacin a obtener.

Entrevista individual
Una tcnica de investigacin ms eficaz que la anterior es la entrevista individual entre un experto del cliente y un entrevistador cualificado del equipo de anlisis. Esta tiene alguna ventaja adicional sobre el grupo focal, como el que se pueden matizar, en un ambiente de mayor privacidad, los aspectos con mayores atributos de impacto. Si el moderador, en el caso de los grupos focales, era importante, el entrevistador juega aqu un papel crtico. No slo tiene que dominar las tcnicas de la entrevista, como el saber preguntar, el crear un clima de cooperacin, sino que, adems debe reunir la experiencia y dominio suficiente sobre el tema a discutir para generar en el cliente una motivacin positiva, en el sentido de que se est tratando de descubrir los conocimientos de uso del producto que pueden realmente incidir en innovaciones que mejoren el rendimiento de su actividad y su satisfaccin.

Anlisis contextual
En la medida en que el conocimiento del cliente cobra importancia para el diseo del nuevo requerimiento, la comprensin de los detalles y particularidades de uso comienza a ser vital para la innovacin proactiva. Con esta tcnica, lo que se hace es, no slo pedir al cliente que cuente su experiencia de uso y responda a las sagaces y hbiles preguntas de los mtodos anteriores, sino que se le solicita, adems, ver cmo utiliza el producto para comprender el por qu de su necesidad y discutir sobre el terreno cada uno de los detalles y particularidades de uso. En esta tcnica de anlisis, la colaboracin del cliente pasa de contar y relatar su experiencia y opinin, desde luego en sus expresiones y en sus propios trminos, a dejar ver al fabricante cmo realmente se construye esa opinin y se acumula esa experiencia.

Clientes piloto
Un mtodo de investigacin ms sofisticado es utilizar clientes piloto. Clientes de alto prestigio y conocimiento que pueden ofrecer un formidable campo de pruebas para el nuevo producto. Claro est que no es fcil encontrar este tipo de clientes piloto, pero tambin es claro que los beneficios de esta tcnica son elevados. Si el cliente es un colaborador ms a la hora de descubrir atributos de impacto y de mejorar los de rendimiento, se est contando realmente con una ayuda especializada, con una opinin experta, que aconseja y valida diseos, que contrasta y mide rendimientos y que, de alguna manera, se involucra en el desarrollo. Arthur D. Little llama a este tipo de clientes lead adopters y seala algunas condiciones que deben cumplir con ese papel de cliente piloto. En primer lugar, se espera que sean empresas exigentes en aquellos aspectos del producto que se quiere verificar. Se est solicitando que sean ms exigentes que la media de los dems clientes, para estar seguros de que el proceso trata con rigor y profundidad, incluso con severidad, las caractersticas a estudiar. En segundo lugar, se les pide liderazgo en el producto, es decir, se trata de clientes de reconocido prestigio por su conocimiento y experiencia en su campo de actividad. Se induce, pues, que su potencial para aplicar el nuevo producto y sugerir cambios, corregir defectos o completar caractersticas, es elevado. Con la aplicacin de esta tcnica se busca dar el primer paso hacia la tendencia actual de integracin de la empresa en amplias redes de cooperacin. En la red, clientes y proveedores colaboran, no slo en la generacin de valor, sino tambin en su gestin, contribuyendo a crear estructuras operativas eficaces, consistentes y dinmicas con las que afrontar la creciente diversidad y dificultad de los mercados.

Captulo 3 DEFINICIN REQUERIMIENTOS

Contenidos
1. 1 Definicin de Requisitos 2. 2 Clasificacin de requerimientos 1. 2.1 Requerimientos Funcionales: 2. 2.2 Requerimientos no funcionales 3. 3 Verificacin de Requisitos 4. 4 Revisin de Requisitos Vs Especificacin 1. 4.1 Preparar plan de revisin: 2. 4.2 Documentos de requisitos a revisar: 3. 4.3 Preparar reunin:

4. 5. 6. 7. 8.

4.4 Realizar reunin: 4.5 Identificar de defectos de la especificacin: 4.6 Realizacin de correcciones a los documentos: 4.7 Informar modificaciones a los interesados: 4.8 Cierre de los requerimientos:

Para tener una buena definicin de requerimientos es necesario realizar una buena identificacin de los mismos, posterior a esto es importante definirlos de manera detallada, donde se involucre la informacin aportada por los usuarios
Para realizar una correcta definicin de los requerimientos del proyecto y que stos satisfagan las necesidades verdaderas del cliente, se deben tener en cuenta las siguientes actividades:

Definicin de Requisitos
Para realizar con xito la definicin de los requerimientos es importante conseguir que los requerimientos sean claramente definidos para minimizar la ambigedad de los requerimientos, para esto es importante tener en cuenta lo siguiente: Definir los requerimientos teniendo en cuenta la informacin identificada con la perspectiva del usuario

Reutilizar requerimientos, revisando proyectos ya finalizados para ver si contienen material potencialmente reutilizable. La ventaja de esta reusabilidad es que, una vez que un requisito ha sido especificado satisfactoriamente para un producto y que el producto ha tenido xito, el requerimiento no tendr que volverse a inventar, podr ser utilizado las veces que se desee teniendo en cuenta los derechos de autor.

Se debe documentar los requerimientos de una forma clara y correcta. En la mayora de los proyectos se observa que la documentacin de los requerimientos puede parecer una tarea tediosa, pero es la nica manera de asegurar que la esencia de los requisitos ha sido capturada correctamente, y que esto pueda ser probado.

Clasificacin de requerimientos

Requerimientos Funcionales: Estos requerimientos se utilizan para determinar que har el Software, definiendo las relaciones de su operacin y su implementacin, sin olvidar que deben ser explcitos tambin en lo que el sistema no debe hacer y que validaciones se deben realizar, teniendo en cuenta cual ser el comportamiento del sistema. Los Requerimientos funcionales se pueden dividir en dos puntos de vista: El primero tiene relacin con el usuario, donde se identifica la relacin del usuario con el sistema desde el punto de vista del mismo; El segundo tiene relacin con el sistema dando respuesta al usuario, es decir desde el punto de vista de lo que realiza el sistema. Para un desarrollador de sistemas es natural dar interpretaciones de un requerimiento ambiguo con el fin de simplificar su implementacin. Sin embargo, a menudo no es lo que el cliente desea. Se tienen que estipular nuevos requerimientos y se deben hacer cambios al sistema, retrasando la entrega de ste e incrementando el costo. En principio, la especificacin de requerimientos funcionales de un sistema debe estar completa y ser consistente con lo solicitado por el usuario Requerimientos no funcionales Estos requerimientos se basan en las restricciones de los servicios o funciones ofrecidos por el sistema. Incluyen restricciones de tiempo, sobre el proceso de desarrollo, estndares, usabilidad, portabilidad, entre otros. Los Requerimientos funcionales son los requerimientos que no se refieren directamente a las funciones especficas que entrega el sistema, sino a las propiedades emergentes de ste como la fiabilidad, la respuesta en el tiempo y la capacidad de almacenamiento. Los requerimientos no funcionales surgen de la necesidad del usuario, debido a las restricciones en el presupuesto, a las herramientas utilizadas, a las polticas de la organizacin, a la necesidad de interoperabilidad con otros sistemas de software o hardware o a factores externos como los reglamentos de seguridad, las polticas de privacidad, etctera. Los dos tipos de requerimientos especificados son de gran importancia para el desarrollo de una aplicacin en software, por lo tanto siempre deben ser escritos con claridad, contener la mayor especificacin de las necesidades expuestas por el cliente, esto con el fin de tener un soporte base desde el cual se trabajaran y no presentar ambigedades en la definicin y el resultado del producto. La figura a continuacin muestra los inconvenientes que se pueden presentar cunado no se hace una identificacin correcta de los requerimientos.

Verificacin de Requisitos
Para la verificacin de requisitos se deben aadir criterios de aceptacin por cada requisito, una tarea de la calidad es asegurarse de que cada requisito cumple con los criterios asignados, este criterio es una medida del requisito que lo hace entendible y con capacidad de ser probado.

Para la verificacin de requisitos se debe validar lo siguiente:

Revisin de Requisitos Vs Especificacin

Una vez ya identificado los requerimientos, documentados y verificados se procede a realizar la revisin de los mismos con base a la informacin recolectada con los usuarios del sistema, en esta revisin participa los analistas del equipo de trabajo y los usuarios necesarios para esta revisin de debe chequear que:

A continuacin se presenta el proceso para la verificacin de los requerimientos.

Preparar plan de revisin:

En la preparacin del plan de reunin de debe planear quienes deben asistir que se va a hablar y cunto tiempo se va a gastar.

Documentos de requisitos a revisar:

Identificar cules son los documentos de especificacin de requisitos que se va a revisar

Preparar reunin:
Se debe confirmar el lugar en el cual realizar la reunin y se deben prepara necesarios para la reunin (lpices, hojas, elementos visuales etc). los materiales

Realizar reunin:
Se revisa el entendimiento de la especificacin por parte de los interesados y se valida que lo especificado si cumple con la necesidad del cliente y con lo solicitado.

Identificar de defectos de la especificacin:

Si revisa si se encuentran defectos con respecto a lo solicitado o si hace falta alguna especificacin requerida.

Realizacin de correcciones a los documentos:

Si en la etapa anterior se encuentran defectos en la especificacin el analista del sistema debe realizan las debidas correcciones al documento.

Informar modificaciones a los interesados:

Una vez los defectos en la especificacin han sido subsanados, se debe enviar un breve resumen informando las tareas realizadas para la correccin de los documentos especificados junto con los documentos corregidos a los participantes en la reunin para dar su aprobacin

Cierre de los requerimientos:

Por ltimo se da por cerrado y entendido la el requerimiento se firma la aprobacin por parte de los interesados y se procede a enviarse un correo con la aprobacin del requerimiento.

Captulo 4 TCNICAS PARA DEFINIR REQUISITOS

Contenidos 1. 2. 3. 4. 5. 1 Definicin de diagramas 2 Definicin de Casos de uso 3 Especificacin de Casos de uso 4 Prototipos 5 Definicin de criterios de aceptacin

Para obtener los requisitos del cliente se pueden emplear varias tcnicas. Histricamente, esto ha incluido tcnicas tales como las entrevistas, o talleres con grupos para crear listas de requisitos. Tcnicas ms modernas incluyen los prototipos, y utilizan casos de uso. Cuando sea necesario, el analista emplear una combinacin de estos mtodos para establecer los requisitos exactos de las personas implicadas, para producir un sistema que resuelva las necesidades del negocio.

De acuerdo a las necesidades de los clientes especficos a los cuales se va a aplicar la metodologa propuesta, se han definido las siguientes:

Definicin de diagramas
Cuando se inicia con el desarrollo de un sistema por lo general nos encontramos con la dificultad de no saber como dar inicio a la especificacin y descripcin de la funcionalidad en general que buscamos apoyar con dicha herramienta, para ello hay muchas herramientas en el mercado que buscan apoyar dicha tarea. De manera general se recomienda el uso de los diagramas UML, pero cundo utilizar diagramas UML? y cundo no hacerlo?. Veamos de manera didctica cundo utilizar y no utilizar los diagramas UML Cuando no Utilizar Diagramas No dibujar diagramas porque el proceso te lo dice Porque te sientes culpable de no hacerlo o porque piensas que es buen diseo hacerlo. Los buenos diseadores escriben cdigo y dibujan diagramas solamente cuando es necesario. Dibujar diagramas para que otra persona codifique

Cuando Utilizar los Diagramas

Utilizar los diagramas cuando varias personas necesiten entender la estructura de una parte particular del diseo, porque todos ellos lo estarn trabajando simultneamente. Detngase cuando todos ellos estn de acuerdo que lo han entendido Cuando dos o mas personas estn en desacuerdo con un elemento particular que debera ser diseado, y quieres un consenso del equipo. Detente cuando la decisin haya sido tomada Cuando quieras jugar con una idea de diseo, y los diagramas pueden ayudarte a entenderlo. Detente cuando hayas conseguido finalizar el punto que queras codificar Cuando necesites exponer una estructura de alguna parte del cdigo a alguien ms o a ti mismo.

Los diagramas que se utilizan son los siguientes: De estados: Estos diagramas nos muestra los diferentes estados de un objeto durante su vida. De secuencia: secuencia Estos nos muestran el intercambio de mensajes (es decir la forma en que se invocan) en un momento dado.Los diagramas de secuencia ponen especial nfasis
en el orden y el momento en que se envan los mensajes a los objetos.

De caso de uso:
Los diagramas de casos de uso describen las relaciones y las dependencias entre un grupo de casos de uso y los actores participantes en el proceso. Los diagramas de casos de uso

describen qu es lo que debe hacer el sistema, pero no cmo.

Definicin de Casos de uso

Para la correcta definicin de los casos de uso a emplear en la especificacin de los requisitos, se deben tener en cuenta algunos aspectos como: La identificacin de actores: Esto nos permite categorizar los diferentes grupos de actores, es decir identificar caractersticas comunes de los actores que intervienen en el sistema, en esta identificacin de actores debemos tener en cuenta que dichos actores pueden llegar a ser un usuario, un humano u otro sistema o dispositivo de hardware, tambin debemos hacernos las siguientes preguntas: Quin o qu inicia eventos con el sistema? Quin proveer, usar o quitar informacin? Quin usar esta funcionalidad? Quin est interesado en cierto requerimiento? En que parte de la organizacin ser usado el sistema?

Quin dar soporte y mantendr el sistema? Cuales son los recursos externos del sistema? Qu otros sistemas necesitarn interactuar con este sistema?

Al definir los actores que intervienen en un caso de uso se debe considerar que una persona puede ejecutar distintos roles en el sistema. Hay actores principales, que son los que usan el sistema directamente; para quienes desarrollamos el sistema. Y hay actores secundarios, que son aquellos de los que el sistema necesita ayuda para poder cumplir con el objetivo del caso de uso Intereses de los actores:

La identificacin de estos intereses nos permiten priorizar desarrollo de los casos de uso, planificar mejor las interacciones y reconocer cuales son los usuarios con los que debemos levantar los casos de uso.
La identificacin de eventos y escenarios que este podra llegar a tener: La identificacin de eventos y escenarios es necesarios para poder determinar cual es la interaccin entre el sistema y los actores, que puede ser descrito mediante una secuencia de mensajes, es una descripcin narrativa de lo que la gente hace al intentar utilizar la aplicacin.

Especificacin de Casos de uso

Los casos de uso deben ser relatos secuenciales que especifiquen una funcionalidad determinada del sistema que se desea desarrollar, as que debe describir como inicia y termina el caso de uso, que datos se intercambian entre el actor y el caso de uso, el flujo de eventos, no solo la funcionalidad, para reforzar esto debe comenzar cada accin con la frase El actor..., describir solo los eventos que pertenecen a ese caso de uso, y no lo que pasa en otros casos de uso o fuera del sistema.

De la misma manera se debe tener especial cuidado de no utilizar los siguientes detalles:

No describir detalles de la interfaz del usuario, a menos que sea necesario para entender el comportamiento del sistema. Evitar terminologa vaga tal como por ejemplo etc informacin. Evite dejar en el texto del caso de uso ambigedades o preguntas que se debieron resolver en el levantamiento de informacin.

Los casos de uso deben contar con los siguientes elementos

El conjunto de todos los casos de uso, debe cubrir los requerimientos del sistema en su totalidad. Se pueden definir casos de uso en diferentes niveles. o A nivel de sistema de Negocio o A nivel de sistema de Software Las descripciones de los casos de uso son cruciales para la comprensin del sistema.

Debe contar con Pre y Post Condiciones, una Pre-Condicin es una restriccin sobre cuando un caso de uso puede empezar. que necesita para poder ser ejecutado, la Post-Condicin para un caso de uso debe ser verdadera, independientemente de cual flujo sea ejecutado. Si algo puede fallar, debera cubrirse en la post condicin diciendo: La accin se ha completado o si algo ha fallado, la accin no se ha realizado, en lugar de decir La accin se ha completado.

Prototipos
Los prototipos son modelos a escala o facsmil de lo real, pero no tan funcional para que equivalga a un producto final, ya que no lleva a cabo la totalidad de las funciones necesarias del sistema final. Es importante definir un objetivo para los prototipos, ya que puede ser til en diferentes fases del proyecto, por ello su objetivo debe ser claro. Es decir durante diferentes etapas del ciclo de vida se pueden utilizar para diferentes necesidades, por ejemplo durante la fase de anlisis se usa para obtener los requerimientos del usuario, en la fase de diseo se usa para ayudar a evaluar muchos aspectos de la implementacin seleccionada y as de acuerdo a la necesidad de cada etapa.

Caractersticas de un prototipo

El prototipo es una aplicacin que puede no funcionar(conjunto de dibujos por ejemplo, una presentacin de escenarios) o que puede funcionar (conjunto de pantallas que proporcionan un modelo dinmico).
Los prototipos se crean con rapidez Los prototipos evolucionan a travs de un proceso iterativo. Los prototipos tiene un costo bajo desarrollo.

Definicin de criterios de aceptacin

Estos criterios nos permiten asegurar que los requisitos satisfacen la funcionalidad requerida y al mismo tiempo que el producto es de calidad, nos ayuda a obtener un nivel de aceptacin realista tanto para el cliente como la empresa que los desarrolla. para la definicin de criterios de aceptacin se presenta el siguiente modelo:

Se debe encontrar el documento de requisito terminado, revisado y aprobado por las diferentes partes, implicadas. El requisito no debe tener escenarios ambiguos El requisito debe hacer que dice el documento de especificacin ni mas, ni menos y cumplir con todos los escenarios.
El requisito debe ser medible, es fcil identificar si cumple o no cumple. No existe contraindicaciones con otros requisitos El requisito debe haber sido probado y aceptado por este proceso. Se debe entregar el requisito dentro de las fechas establecidas. El requisito aparte de cumplir con los anteriores pasos, puede haber otros criterios que el cliente solicite.

Captulo 5 PRUEBAS DE REQUERIMIENTOS

El objetivo de las pruebas de verificacin es buscar discrepancias entre los requerimientos y la

ejecucin del software. Partiendo de lo anterior se proponen las siguientes actividades para que las pruebas realizadas a los productos desarrollados mediante esta metodologa sean correcta, se tendrn en cuenta las siguientes fases:

Planeacin
En esta fase se define el alcance y limitaciones de la prueba, la estrategia utilizada para la ejecucin de la prueba, los requerimientos para poder realizar las pruebas (documentacin, recurso humano y recurso tecnolgico), los tiempos de estimados de duracin de la misma y los criterios para terminacin. Entregable: MR_005.1_Planeacin Prueba de requerimiento

Diseo de casos de prueba

En esta fase se define el checklist con las caractersticas a evaluar del requerimiento. A continuacin se presenta algunas de las caractersticas para evaluar dichos requerimientos

Entregable: MR_005.2_Diseo de Casos de Prueba

Ejecucin de casos de prueba
En esta fase se evaluara cada uno de los requerimientos (casos de uso) de acuerdo al checklist definidos como casos de prueba (conciso, contraposicin, ambigedad y completitud, entre otras) se reportaran las consideraciones, errores, sugerencias, y se realizaran reuniones para hacer aclaraciones y definir si las consideraciones planteadas van a ser solucionadas o si el requerimiento es correcto como esta Entregable: MR_005.3_Ejecucion de Casos de Prueba

Cierre
En esta fase una vez se haya completados la ejecucin con resultados satisfactorios y ajustes correspondientes, se realizara el cierre de la prueba donde se dar el visto bueno sobre los requisitos evaluados Entregable: MR_005.4_Informe final prueba

A continuacin se presentan los entregables o documentos de soporte de la etapa de pruebas del requerimientos de la metodologa:

Formato
MR_005.1_Planeacin Prueba de requerimiento (Ver Formato) MR_005.2_Diseo de Casos de Prueba (Ver Formato) MR_005.3_Ejecucion de Casos de Prueba (Ver Formato)

Objetivo
Presentar la estrategia, alcance, estimacin de tiempos, de la prueba de requerimiento. Identificar los posibles casos de prueba del requerimiento Presentar resultado de ejecucin de los casos

MR_005.4_Informe final prueba (Ver Formato)

Presentar informe de cierre con los aspectos ms relevantes de la ejecucin

Captulo 6 GESTIN DE CAMBIOS

La gestin de cambio en los proyectos debe ser una coordinacin planificada de las actividades que conlleve el logro de los objetivos o propsitos comunes a travs de una comunicacin clara y eficiente.

A continuacin se presenta el proceso de gestin de cambios con las actividades que se deben llevar a cabo:

Identificacin Control de cambios

Para una correcta identificacin de lo controles de cambios de los requerimientos de las organizaciones de desarrollo de software, se identifican las siguientes actividades:

Anlisis de la Solicitud:

La solicitud es recibida por parte del cliente interno o externo, esta debe ser recibida por parte del lder de implementacin para ser analizada. Uno de los puntos importantes para analizar son el Alcance y el Tiempo, esto con el fin de identificar si la solicitud es viable realizarla sobre el mismo requerimiento o si por el contrario es mejor manejarla como un requerimiento nuevo.

Con respecto al anlisis con relacin al alcance es recomendable buscar colaboracin con las reas involucradas en la solicitud, para identificar de mejor manera el impacto y los elementos que se ven afectados con la solicitud.

Valorar el cambio

Otro punto importante es valorar la factibilidad de la solicitud realizada ya sea por un cliente interno o uno externo. Para ello se deber ir recorriendo todo el rbol de requisitos viendo como les afecta el cambio, y aqu es donde entra la trazabilidad de los requisitos.

Analizar Modificacin

El lder de implementacin debe realizar el anlisis de la solicitud para saber que tanto impacta la modificacin e identificar puntualmente las modificaciones solicitadas que afectan el requerimiento completo y as identificar si el cambio afecta mas de un requerimiento.

Documentar Cambio

Para tener un mejor control sobre los cambios solicitados es recomendable realizar una documentacin clara para evitar ambigedades en las modificaciones que se van a realizar a los requerimientos. Este punto apoya tambin a tener un control de las modificaciones que se realizan sobre un documento de requerimiento esto con el fin de mantener informado al grupo de trabajo y al cliente que actualizaciones se han realizado sobre los documentos, cual es la razn del cambio y quien lo aprob.

Aprobacin Control de Cambios

Aprobar Cambios

Una vez se ha analizado el impacto del cambio, se debe tomar una decisin. Si se acepta el cambio, tras negociarlo con el cliente, se continuar con la actividad de implementar el cambio. En caso contrario, se deber negociar con el cliente el siguiente paso a realizar.

Planear Cambio

Despus de tener una aprobacin formal del cambio aceptado se planea el tiempo necesario y los recursos necesarios para llevar a cabo el cambio aprobado.

Realizar Cambio

Una vez se planea el cambio aprobado se debe realizar las modificaciones necesarias a todos los productos que resulten afectados por dicho cambio.

Revisar Cambio

Una vez se realice el cambio es recomendable hacer una verificacin por parte del lder para identificar que el requerimiento incluye todos los cambios solicitados y que fueron aprobados.

Actualizar Lnea Base

Es recomendable utilizar el nuevo requerimiento como lnea base, esto con el fin de trabajar siempre sobre la ultima versin del requerimiento.

Informar

Una vez se realice la modificacin de la solicitud se debe informar a los interesados que el cambio ya esta realizado para que sea verificado por el cliente.

Entregable Control de Cambios

Como se especifico en los puntos anteriores es importante utilizar el documento que apoye a la identificacin de la solicitud realizada por los clientes internos o externos. Esta documentacin no debe ser ambigua y debe ser validada por las dos partes, el cliente y las empresas de desarrollo de software.

El formato necesario para la documentacin del control de cambios se encuentra en el capitulo ocho Formatos de la Metodologa

Formato MR_006_Control de cambios

Objetivo Describir la situacin de cambio solicitada por el cliente.

Captulo 7 GESTIN DE REQUERIMIENTO

Contenidos 1. 1 Matrices de Trazabilidad 1. 1.1 Matriz de relacin de documentos 2. 1.2 Matriz de valoracin y aprobacin de los requisitos 2 Matriz de Control de cambios

2.

Para que la gestin de los requerimientos sea realmente aplicable al cliente en pro de la satisfaccin de las necesidades y control del proyecto en general, se debe cumplir con las siguientes acciones:

Matrices de Trazabilidad
Matriz de relacin de documentos
La siguiente Matriz nos muestra cuales son las relaciones de documentacin de cada requisito su clasificacin si es de negocio, usuario o sistema y si es funciona o no funcional, su respectivo caso de uso, sus casos de prueba asociados, la dependencia con otros requerimientos y las peticiones de cambio en caso que las tenga.

Matriz de valoracin y aprobacin de los requisitos

La siguiente matriz de trazabilidad es la que nos permite valorar si el requisito cumple con todas las etapas llevadas a cabo en la metodologa, en caso que todos los criterios se cumplan se dar por cerrado y aprobado el requisito. Modo de desarrollo, la persona encargada de revisar la lista de chequeo deber tener en cuenta todo el proceso y documentacin de la metodologa para as dar un dictamen correcto, el manejo es el siguiente. Cumple=C, esto nos indica que el requisito cumple con el criterio correctamente, se encuentra en color verde. No Cumple= N, El color rojo es para dar una seal de alerta informando que el requisito no est cumpliendo correctamente con el criterio de aceptacin y que se debe revisar porque razn esto pasando esto y tomar las medidas de control necesarias.

No aplica= En caso que el criterio no aplique en ese caso para el requisito se mostrar en amarillo informando que no hay problema.

Matriz de Control de cambios

La matriz de control de cambios nos permite registrar los controles de cambios que se van presentando, en esta matriz podremos registrar el nmero de control de cambio que se tiene asignado, la referencia a la documentacin de dicho control, quien aprob el control, quien lo llevo a cabo o quien lo est realizando, por quien fue revisado en caso que ya se encuentre revisado, su porcentaje de ejecucin hasta llegar al 100%, el o los requisitos afectados y una descripcin breve del control de cambios. Esta matriz nos permitir llevar un control detallado de los controles de cambios solicitados y su estado actual

Captulo 8 FORMATOS DE LA METODOLOGA

Los formatos utilizados en las plantillas se presentan como una herramienta de apoyo y soporte a las actividades sugeridas en la presente metodologa. Por lo tanto cada uno de los formatos a utilizar presenta las especificaciones correspondientes para su diligenciamiento. A continuacin se encuentran cada uno de los formatos recomendados para utilizar en los captulos que hacen parte de esta metodologa:

Capitulo

Formato

Objetivo
Presentar una descripcin de lo que se requiere desde la perspectiva del cliente para resolver la necesidad u oportunidad de mejora identificada. El presente documento ser trabajado de la mano del cliente. Sugerir preguntas que permitan detallar el requerimiento. Presentar matrices de trazabilidad (Relacin de documentacin, Revisin de Pares, Registro de Controles de Cambio) Especificar detalladamente la funcionalidad (requerimientos funcionales y no funcionales) de los componentes del sistema y sus interacciones Presentar la estrategia, alcance, estimacin de tiempos, de la prueba de requerimiento. Identificar los posibles casos de prueba del requerimiento Presentar resultado de ejecucin de los casos

Cap 1

FMR_001_Identificacion de Necesidades

Cap 2 Cap 3

FMR_002_Entrevista

FMR_003_Matrices_Trazabilidad FMR_004.1_00X_Especificacion Funcional FMR_004.2_00X_Caso de Uso FMR_004.3_00X_Especificacion de Diagramas FMR_005.1_Planeacin Prueba de requerimiento

Cap 4

Cap 5

FMR_005.2_Diseo de Casos de Prueba FMR_005.3_Ejecucion de Casos de Prueba

FMR_005.4_Informe final prueba Cap 6 FMR_006_Control de cambios

Presentar informe de cierre con los aspectos ms relevantes de la ejecucin Describir la situacin de cambio solicitada por el cliente.

https://sites.google.com/site/metodologiareq/capitulo-ix

Captulo 9 MEJORES PRACTICAS

Contenidos 1. 1 Mejores practicas en el desarrollo de requisitos 2. 2 Mejores prcticas en la gestin de requisitos

Actualmente existen y se desarrollan continuamente innumerables metodologas para la gestin de requerimientos para los proyectos de software, por tal motivo es de suma importancia reconocer la importancia de las metodologas que han impactado la gestin de manera positiva y de as tomar las acciones o actividades que generan xito. Por lo anterior es importante hacer un compilado de todas las mejores prcticas utilizadas en las diferentes metodologas y as poder asegurar que la metodologa propuesta sea efectiva para el mercado. En el desarrollo de software, una mejor prctica es un mtodo bien definido que contribuye a una implementacin exitosa del proyecto software. Las organizaciones implementan mejores prcticas reconocidas en su medio, para que les ayuden a enfrentar los inconvenientes presentados al encarar un proyecto de software, teniendo como herramientas las lecciones aprendidas en anteriores proyectos.

Mejores practicas en el desarrollo de requisitos

A continuacin se describen una serie de mejores prcticas orientadas al desarrollo de requisitos:

Documentar el alcance y visin del proyecto: permitir tener un mejor entendimiento de los requisitos y asegurar que todas las personas involucradas en el proyecto trabajen hacia la misma meta. Mantener un glosario del proyecto: facilitar una comunicacin efectiva asegurando un entendimiento unnime Uso de tcnicas de obtencin de requisitos de usuario: para facilitar esta tarea. Involucrar a toda la gente implicada: asegura una validacin temprana del entendimiento de los requisitos. Desarrollo incremental de requisitos: puede minimizar la cantidad de re-trabajo del proyecto Captura de requisitos usando casos de uso: ser ms fcil gestionar los requisitos y hacer un seguimiento de los mismos

Validar requisitos: para mejorar el xito de los proyectos es crtico que se validen los requisitos de forma adecuada Verificar requisitos: para asegurar que los requisitos proporcionan una base adecuada para llevar a cabo el diseo, la construccin y las pruebas.

Mejores prcticas en la gestin de requisitos

A continuacin se muestran una serie de mejores prcticas relacionadas con la gestin de requisitos:

Priorizar requisitos: para determinar aquellos que se deberan cumplir en la primera versin o producto y aquellos que pueden llevarse a cabo en sucesivas versiones Establecer lneas base de los requisitos: para asegurar que cualquier modificacin en los requisitos que cambie la lnea base se trata como cambios de alcance Comunicacin abierta: para asegurar que la informacin relacionada con los requisitos se comunica de forma consistente. Una comunicacin abierta tambin implica comunicar a la gente correcta y al conjunto mnimo de personas Gestin de cambios de los requisitos: es esencial gestionar estos cambios de forma efectiva y eficiente Uso de herramientas para la gestin de requisitos: para facilitar la gestin de requisitos Mantener trazabilidad de requisitos: para llevar un seguimiento de la vida de un requisito Establecer un plan de mejora de procesos para la ingeniera de requisitos: para cumplir con las necesidades actuales y futuras de forma ms eficiente y con mayor calidad. Formar a los analistas de requisitos: para asegurar que los analistas de requisitos tienen el conocimiento, entre otros aspectos, de cmo escribir buenos requisitos, etc.