1. Capítulo 1 "IDENTIFICACIÓN DE NECESIDADES CON EL CLIENTE"
Si los requerimientos se enfocan a describir las necesidades del cliente, entonces es lógico que para recabarlos haya que obtener la información de primera mano. Esto es, mediante
entrevistas con el cliente u obteniendo la documentación 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 documentación original del cliente, así como cada revisión o
cambio que se haga a esta documentación.
Para que la metodología sea efectiva en los puntos descritos se definieron las siguientes actividades que se deben desarrollar para la correcta
identificación de necesidades de los clientes:
Obtener y Analizar información de las necesidades del cliente
Para hacer una correcta identificación de los clientes y poder realizar un análisis de manera asertiva se pueden implementar una serie de técnicas de acuerdo al cliente con el que se
esté tratando. Como apoyo a esta etapa la metodología presenta algunas técnicas con las que se pueden identificar las necesidades de manera tal que el análisis sea apropiado para

2. satisfacer las expectativas del cliente. Estas técnicas se encuentran en el Capitulo 2. Técnicas para identificar requerimientos.
Definición del alcance
La definición del alcance tiene como propósito describir y delimitar claramente las necesidades del cliente, las cuales pretenden ser cumplidas con el proyecto.
Es importante para la definición del alcance la identificación de los siguientes aspectos:
o Los entregables que hacen parte del alcance. Se recomienda describir y listar los entregables finales, principalmente los que deben ser aprobados por el cliente.

3. Nota: no mencionar documentos propios del proyecto como cronograma, estimaciones, entre otros.
o Los tipos de datos que están en el alcance y fuera de él. Los “tipo de datos” se refieren a la categoría del negocio de los entregables tales como datos financieros, datos
de ventas, datos de los empleados, etc.
o
o Las fuentes de datos (bases de datos) que están 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 facturación y cobranza, etc.
o
o Áreas involucradas en el alcance y fuera de él. En algunos casos, las áreas involucradas en el proyecto ayudan a delimitar el alcance.
o
o Condiciones fuera del alcance. Se recomienda como punto de claridad y contraste al describir entregables que no serán creados, qué organizaciones no serán impactadas,
qué facilidades y funciones no serán incluidas, entre otros aspectos.
Fuentes de información claves
Cualquier información creada anteriormente debe ser usada como base para definir el alcance de manera más detallada. Si por alguna razón no se cuenta con suficiente información
para la definición del alcance, se debe buscar apoyo con el patrocinador para reunir información adicional.
Si se tienen objetivos del proyecto, se recomienda tenerlos en cuenta para ayudar a afinar el alcance. Por definición, se deben crear uno o más entregables para cumplir cada objetivo, y
definir los entregables del proyecto es uno de los aspectos principales del alcance del proyecto.

4. Recomendaciones para definir el alcance
Algunas recomendaciones para la definición 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 características y
especificaciones solicitadas.
• Definir los criterios que se utilizarán para determinar si el proyecto o fase ha finalizado exitosamente, es decir, los criterios de aceptación.

5. • Al definir el alcance, tener en mente que lo que no esté en el alcance está fuera del proyecto.
• Formalizar la aceptación del alcance con el cliente.
Beneficios de una buena definición
El alcance marca la pauta para la toma de decisiones futuras y realización de actividades a nivel Operativo y nos ayuda a:
• Mejorar la precisión en las estimaciones de tiempo, costo y recursos.
• Facilitar la asignación clara de recursos y responsabilidades.
• Definir la línea base para la medición del desempeño y control
• Identificar, tanto el equipo de proyecto como el cliente, el objetivo final del proyecto y sus entregables.
• Desarrollar y confirmar un entendimiento común 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 Identificación de Necesidades

6. El presente documento será trabajado de la mano del cliente, principalmente cuando no se cuenta con documentación previa que sirva como base para aclarar las necesidades del
cliente.
Formato Objetivo
MR_002_Identificacion de Necesidades (Ver
Formato)
Presentar una descripción 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.

7. Capítulo 2 TÉCNICAS PARA IDENTIFICAR REQUERIMIENTOS
En la actualidad las organizaciones enfocadas al desarrollo de aplicaciones de software utilizan diferentes herramientas que permiten facilitar la fase de identificación de
requerimientos, puesto que se presta mayor atención 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 ejecución el sistema que se esté desarrollando.
Las organizaciones actuales utilizan múltiples herramientas para el apoyo de la identificación de los requerimientos, sin pensar si son las más convenientes para el proyecto que se esté
desarrollando, por lo tanto a continuación se encontraran las técnicas que apoyen una correcta identificación de los requerimientos para los proyectos de desarrollo de software.
A continuación se especifican cada una de las técnicas utilizadas:
o Técnicas generales para la identificación de requerimientos
o Técnicas específicas para la identificación de requerimientos
o Técnicas para Identificar Requisitos Funcionales y No Funcionales
o Técnicas de investigación de los atributos de las necesidades de los clientes
o
A continuación se presenta documento de uso opcional como apoyo para identificación y definición de requerimiento:

8. Formato Objetivo
MR_002_Entrevista (Ver formato) Sugerir las preguntas que permitan detallar el
requerimiento.
1. Técnicas generales para la identificación de requerimientos
Contenidos
. 1 Entrevista
. 2 Lluvia de ideas
. 3 Cuestionarios
Las técnicas agrupadas como generales son las que permiten investigar aspectos generales para posteriormente ser especificados con un mayor detalle con el apoyo de técnicas más
específicas. Estas técnicas son más abiertas y requieren ser adecuadamente orientadas para cubrir la información que se requiere capturar, es importante que para sacar el mayor
provecho de estas técnicas se debe tener un dialogo lo más abierto posible entre las organizaciones de desarrollo de software y las empresas cliente.

9. Entrevista
Estas técnicas son muy utilizadas para la recolección de opiniones, criterios o descripciones sobre diferentes actividades. Se lleva a cabo mediante conversaciones estructuradas
donde es fundamental que la relación con el cliente este basada en la confianza para dar a conocer la información de la manera mas detallada.
Antes de iniciar una entrevista es importante tener en cuenta los siguientes Tips a tener en cuenta, no es obligación realizarlas todas pero si es recomendable estudiar cuales son las
que más se aplica para cada organización o cada proyecto.

10. 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 estarán las personas y así obtener la información de la manera más
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 relación del cliente con la organización que realizará la identificación de los requerimientos, esto con el fin de facilitar el trabajo y la disposición de ambas
partes.
6. Entender que es importante obtener la mayor información para la definición de los requerimientos, teniendo en cuenta que nada es obvio para las organizaciones de desarrollo
de software.
Lluvia de ideas
Esta técnica es abierta y se utiliza para explorar necesidades iniciales con la ayuda de la identificación de ideas de todas las personas que hacen parte del equipo de apoyo para la
identificación 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 cómodas y dispuestas para dar a conocer sus ideas.
2. Tomar la iniciativa para iniciar una reunión enfocada en la confianza.
3. Tomar nota de las ideas que las personas expresan en los equipos de trabajo.

11. Tener una preparación sobre el tema que se va a desarrollar en la lluvia de ideas.
2. Técnicas específicas para la identificación de requerimientos
Contenidos
1 Observación
2 Escenarios
Las técnicas agrupadas como especificas son las que permiten complementar las técnicas generales, para así obtener mayor detalle y eliminar ambigüedad en la información inicial.

12. Observación
Esta técnica permite obtener información directa sobre la forma en que se realizan las actividades. Es una técnica que sirve para revisar que no existen omisiones o interpretaciones
erróneas 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 técnica permite conocer el comportamiento del producto ante determinados eventos considerando los datos, acciones y excepciones que se pueden
presentar. El análisis de casos de uso es un ejemplo de aplicación de esta técnica.

13. 3. Técnicas para Identificar Requisitos Funcionales y No Funcionales
Contenidos
. 1 Identificación de Requerimientos funcionales
. 2 Identificación de Requerimientos no funcionales
. 3 Aspectos a tener en cuenta en la identificación de requerimientos funcionales y no funcionales
. 4 Identificación de elementos
. 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 técnicas para la
identificación correcta.
Identificación 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 también declaran explícitamente lo que el sistema no debe hacer.
Muchos de los problemas de la ingeniería de software provienen de la imprecisión en la especificación de requerimientos. Para un desarrollador de sistemas es natural dar
interpretaciones de un requerimiento ambiguo con el fin de simplificar su implementación. 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 especificación de requerimientos funcionales de un sistema debe estar completa y ser consistente. La compleción significa que todos los servicios solicitados por el
usuario están definidos. La consistencia significa que los requerimientos no tienen definiciones contradictorias.
En la práctica, para sistemas grandes y complejos, es imposible cumplir los requerimientos de consistencia y compleción. La razón 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

14. por primera vez. Los problemas emergen después de un análisis 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.
Identificación de Requerimientos no funcionales
Son aquellos requerimientos que no se refieren directamente a las funciones específicas 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
representación 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 políticas de la organización, a la necesidad de
interoperabilidad con otros sistemas de software o hardware o a factores externos como los reglamentos de seguridad, las políticas 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 desempeño en la rapidez de ejecución del sistema y cuánta 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 políticas y procedimientos existentes en la organización del cliente y en la del desarrollador: estándares en los procesos que
deben utilizarse; requerimientos de implementación como los lenguajes de programación o el método de diseño a utilizar, y los requerimientos de entrega que especifican cuándo se
entregará el producto y su documentación.
• 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 interactúa con los otros sistemas de la organización; 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 práctica, la especificación cuantitativa de requerimientos es difícil. A los clientes no les es posible traducir sus metas en requerimientos cuantitativos; para algunas de éstas, como
las de mantenimiento, no existen métricas 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 práctica, esto es difícil. Si un requerimiento no funcional se declara
de forma separada a los funcionales, algunas veces es difícil ver la relación entre ellos. Si se declaran con los requerimientos funcionales, es difícil 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 colocándolos en una sección aparte o

15. diferenciándolos, de alguna forma, de los otros requerimientos del sistema.
Aspectos a tener en cuenta en la identificación de requerimientos funcionales y no funcionales
Requerimientos básicos: se estructura su identificación al buscar respuestas a preguntas como:
• ¿Cuál es el proceso básico de la empresa?
• ¿Qué datos utiliza o produce este proceso?
• ¿Cuáles son los límites impuestos por el tiempo y la carga de trabajo?
• ¿Qué controles de desempeño utiliza?
Siempre se debe comenzar con lo básico. 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 comprensión necesaria:
• ¿Cuál es la finalidad de la actividad dentro de la empresa?
• ¿Qué pasos se siguen para realizarla?
• ¿Dónde se realizan estos pasos?
• ¿Quiénes los realizan?
• ¿Cuánto tiempo tardan en efectuarlos?
• ¿Con cuánta frecuencia lo hacen?
• ¿Quiénes emplean la información resultante?
Identificación de elementos
Durante esta, se debe identificar muy claramente los siguientes elementos:
• Procesos
• Flujos de datos entre procesos
• Datos de cada flujo de datos

16. • Bases de datos
• Datos de las bases de datos
Preguntas generales:
• ¿Cuántos empleados laboran para la organización en el área(s) que se pretende desarrollar el sistema; o sea, cuántos tienen relación directa con el proyecto
• ¿Cuáles son las personas claves en el sistema? ¿Por qué son importantes?
• ¿Existen obstáculos o influencias de tipo político que afectan la eficiencia del sistema?
• ¿Existen manuales de procedimientos, políticas o lineamientos de desempeño 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 métodos para evadir el sistema?, ¿Por qué se presentan?
• ¿Qué áreas necesitan un control específico?
• ¿Qué criterios se emplean para medir y evaluar el desempeño?
4. Técnicas de investigación de los atributos de las necesidades de
los clientes
Contenidos
1 Grupos focales
2 Entrevista individual
3 Análisis 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

17. de clasificar y ponderar su importancia.
Este proceso de investigación debe ser suficientemente inteligente para conseguir respuestas que permitan elevar realmente el nivel de competitividad de la solución buscada.
En definitiva, se recomienda escuchar y entender lo que los estudiosos de la calidad llaman la voz del cliente.
Bajo una perspectiva de innovación proactiva, para la identificación de necesidades, se requieren métodos en los cuales el cliente pueda compartir su esfera de conocimientos de
aplicación con mayor riqueza y detalle que en los simples informes de reclamación. Entre estos métodos están:
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

18. cuestiones concretas en las que se focaliza la discusión. Esta técnica de investigación alcanza mayor profundidad que la encuesta y que los informes anteriores.
En la reunión se establece, de por sí, una relación de afinidad por la que todas las respuestas giran en torno a la situación a analizar. El contexto de uso y aplicación del producto y las
características que se estudian van quedando claros para todos, más si desde el principio el moderador tiene la habilidad de exponer el propósito de la reunión con nitidez.
Se elimina, pues, uno de los problemas de la encuesta. Al mismo tiempo, se consigue más información 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 específicos de sus ámbitos de aplicación y segundo, porque en todo
momento se pueden aclarar dudas y profundizar en el tema hasta lograr su total comprensión.
La habilidad para conducir el debate, sugerir y plantear los temas, atemperar las discusiones sobre aspectos banales y centrarla en los relevantes, es una cuestión que va a determinar
la cantidad y calidad de la información a obtener.
Entrevista individual
Una técnica de investigación más eficaz que la anterior es la entrevista individual entre un experto del cliente y un entrevistador cualificado del equipo de análisis. 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 crítico. No sólo tiene que dominar las técnicas de la entrevista, como el saber
preguntar, el crear un clima de cooperación, sino que, además debe reunir la experiencia y dominio suficiente sobre el tema a discutir para generar en el cliente una motivación 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
satisfacción.
Análisis contextual
En la medida en que el conocimiento del cliente cobra importancia para el diseño del nuevo requerimiento, la comprensión de los detalles y particularidades de uso comienza a ser vital
para la innovación proactiva.
Con esta técnica, lo que se hace es, no sólo pedir al cliente que cuente su experiencia de uso y responda a las sagaces y hábiles preguntas de los métodos anteriores, sino que se le
solicita, además, ver cómo 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 técnica
de análisis, la colaboración del cliente pasa de contar y relatar su experiencia y opinión, desde luego en sus expresiones y en sus propios términos, a dejar ver al fabricante cómo
realmente se construye esa opinión y se acumula esa experiencia.

19. Clientes piloto
Un método de investigación más 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 fácil encontrar este tipo de clientes piloto, pero también es claro que los beneficios de esta técnica son elevados. Si el cliente es un colaborador más a la
hora de descubrir atributos de impacto y de mejorar los de rendimiento, se está contando realmente con una ayuda especializada, con una opinión experta, que aconseja y valida
diseños, 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 señala 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 más exigentes que la media de los demás clientes, para estar seguros de
que el proceso trata con rigor y profundidad, incluso con severidad, las características 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 características, es elevado.
Con la aplicación de esta técnica se busca dar el primer paso hacia la tendencia actual de integración de la empresa en amplias redes de cooperación. En la red, clientes y proveedores
colaboran, no sólo en la generación de valor, sino también en su gestión, contribuyendo a crear estructuras operativas eficaces, consistentes y dinámicas con las que afrontar la
creciente diversidad y dificultad de los mercados.
Capítulo 3 DEFINICIÓN REQUERIMIENTOS
Contenidos
1 Definición de Requisitos
2 Clasificación de requerimientos
1. 2.1 Requerimientos Funcionales:
2. 2.2 Requerimientos no funcionales

20. 3 Verificación de Requisitos
4 Revisión de Requisitos Vs Especificación
1. 4.1 Preparar plan de revisión:
2. 4.2 Documentos de requisitos a revisar:
3. 4.3 Preparar reunión:
4. 4.4 Realizar reunión:
5. 4.5 Identificar de defectos de la especificación:
6. 4.6 Realización de correcciones a los documentos:
7. 4.7 Informar modificaciones a los interesados:
8. 4.8 Cierre de los requerimientos:
Para tener una buena definición de requerimientos es necesario realizar una buena identificación de los mismos, posterior a esto es importante definirlos
de manera detallada, donde se involucre la información aportada por los usuarios
Para realizar una correcta definición de los requerimientos del proyecto y que éstos satisfagan las necesidades verdaderas del cliente, se deben tener en cuenta las siguientes
actividades:

21. Definición de Requisitos
Para realizar con éxito la definición de los requerimientos es importante conseguir que los requerimientos sean claramente definidos para minimizar la ambigüedad de los
requerimientos, para esto es importante tener en cuenta lo siguiente:
o Definir los requerimientos teniendo en cuenta la información identificada con la perspectiva del usuario
o 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.
o Se debe documentar los requerimientos de una forma clara y correcta. En la mayoría de los proyectos se observa que la documentación 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.
Clasificación de requerimientos
Requerimientos Funcionales:
Estos requerimientos se utilizan para determinar que hará el Software, definiendo las relaciones de su operación y su implementación, sin olvidar que deben ser explícitos también 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 relación con el usuario, donde se identifica la relación del usuario con el sistema desde el
punto de vista del mismo; El segundo tiene relación 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 implementación. 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
especificación de requerimientos funcionales de un sistema debe estar completa y ser consistente con lo solicitado por el usuario.

22. 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, estándares,
usabilidad, portabilidad, entre otros.
Los Requerimientos funcionales son los requerimientos que no se refieren directamente a las funciones específicas 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 políticas de la organización, a la
necesidad de interoperabilidad con otros sistemas de software o hardware o a factores externos como los reglamentos de seguridad, las políticas de privacidad, etcétera.
Los dos tipos de requerimientos especificados son de gran importancia para el desarrollo de una aplicación en software, por lo tanto siempre deben ser escritos con claridad, contener la
mayor especificación de las necesidades expuestas por el cliente, esto con el fin de tener un soporte base desde el cual se trabajaran y no presentar ambigüedades en la definición y el
resultado del producto. La figura a continuación muestra los inconvenientes que se pueden presentar cunado no se hace una identificación correcta de los requerimientos.

23. Verificación de Requisitos
Para la verificación de requisitos se deben añadir criterios de aceptación 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.

24. Para la verificación de requisitos se debe validar lo siguiente:

25. Revisión de Requisitos Vs Especificación

26. Una vez ya identificado los requerimientos, documentados y verificados se procede a realizar la revisión de los mismos con base a la información recolectada con los usuarios del
sistema, en esta revisión participa los analistas del equipo de trabajo y los usuarios necesarios para esta revisión de debe chequear que:
A continuación se presenta el proceso para la verificación de los requerimientos.

27. Preparar plan de revisión:
En la preparación del plan de reunión de debe planear quienes deben asistir que se va a hablar y cuánto tiempo se va a gastar.
Documentos de requisitos a revisar:

28. Identificar cuáles son los documentos de especificación de requisitos que se va a revisar
Preparar reunión:
Se debe confirmar el lugar en el cual realizará la reunión y se deben prepara los materiales necesarios para la reunión (lápices, hojas, elementos visuales… etc. :).
Realizar reunión:
Se revisa el entendimiento de la especificación 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 especificación:
Si revisa si se encuentran defectos con respecto a lo solicitado o si hace falta alguna especificación requerida.
Realización de correcciones a los documentos:
Si en la etapa anterior se encuentran defectos en la especificación el analista del sistema debe realizan las debidas correcciones al documento.
Informar modificaciones a los interesados:
Una vez los defectos en la especificación han sido subsanados, se debe enviar un breve resumen informando las tareas realizadas para la corrección de los documentos especificados
junto con los documentos corregidos a los participantes en la reunión para dar su aprobación
Cierre de los requerimientos:

29. Por último se da por cerrado y entendido la el requerimiento se firma la aprobación por parte de los interesados y se procede a enviarse un correo con la aprobación del requerimiento.
Capítulo 4 TÉCNICAS PARA DEFINIR REQUISITOS
Contenidos
1 Definición de diagramas
2 Definición de Casos de uso
3 Especificación de Casos de uso
4 Prototipos
5 Definición de criterios de aceptación
Para obtener los requisitos del cliente se pueden emplear varias técnicas. Históricamente, esto ha incluido técnicas tales como las entrevistas, o talleres con grupos para crear listas de
requisitos. Técnicas más modernas incluyen los prototipos, y utilizan casos de uso. Cuando sea necesario, el analista empleará una combinación de estos métodos para establecer los
requisitos exactos de las personas implicadas, para producir un sistema que resuelva las necesidades del negocio.

30. De acuerdo a las necesidades de los clientes específicos a los cuales se va a aplicar la metodología propuesta, se han definido las siguientes:
Definición 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 especificación y descripción 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 cuándo utilizar diagramas UML? y cuándo no hacerlo?.
Veamos de manera didáctica cuándo utilizar y no utilizar los diagramas UML
Cuando no Utilizar Diagramas

31. o No dibujar diagramas porque el proceso te lo dice
o Porque te sientes culpable de no hacerlo o porque piensas que es buen diseño hacerlo. Los buenos diseñadores escriben código y dibujan diagramas solamente cuando es
necesario.
o Dibujar diagramas para que otra persona codifique
Cuando Utilizar los Diagramas
o Utilizar los diagramas cuando varias personas necesiten entender la estructura de una parte particular del diseño, porque todos ellos lo estarán trabajando simultáneamente.
Deténgase cuando todos ellos estén de acuerdo que lo han entendido
o Cuando dos o mas personas estén en desacuerdo con un elemento particular que debería ser diseñado, y quieres un consenso del equipo. Detente cuando la decisión haya
sido tomada
o Cuando quieras jugar con una idea de diseño, y los diagramas pueden ayudarte a entenderlo. Detente cuando hayas conseguido finalizar el punto que querías codificar
o Cuando necesites exponer una estructura de alguna parte del código a alguien más 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:
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 envían los mensajes a los objetos.
De caso de uso:

32. 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 cómo.
Definición de Casos de uso
Para la correcta definición de los casos de uso a emplear en la especificación de los requisitos, se deben tener en cuenta algunos aspectos como:
La identificación de actores:
Esto nos permite categorizar los diferentes grupos de actores, es decir identificar características comunes de los actores que intervienen en el sistema, en esta identificación de actores
debemos tener en cuenta que dichos actores pueden llegar a ser un usuario, un humano u otro sistema o dispositivo de hardware, también debemos hacernos las siguientes preguntas:
o Quién o qué inicia eventos con el sistema?
o Quién proveerá, usará o quitará información?
o Quién usará esta funcionalidad?
o Quién está interesado en cierto requerimiento?
o En que parte de la organización será usado el sistema?
o Quién dará soporte y mantendrá el sistema?
o Cuales son los recursos externos del sistema?
o Qué otros sistemas necesitarán 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 identificación 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.

33. La identificación de eventos y escenarios que este podría llegar a tener:
La identificación de eventos y escenarios es necesarios para poder determinar cual es la interacción entre el sistema y los actores, que puede ser descrito mediante una secuencia de
mensajes, es una descripción narrativa de lo que la gente hace al intentar utilizar la aplicación.
Especificación 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 acción 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:
o No describir detalles de la interfaz del usuario, a menos que sea necesario para entender el comportamiento del sistema.
o Evitar terminología vaga tal como “por ejemplo” “etc” “información”.
o Evite dejar en el texto del caso de uso ambigüedades o preguntas que se debieron resolver en el levantamiento de información.
Los casos de uso deben contar con los siguientes elementos
o El conjunto de todos los casos de uso, debe cubrir los requerimientos del sistema en su totalidad.
o Se pueden definir casos de uso en diferentes niveles.
o A nivel de sistema de Negocio
o A nivel de sistema de Software
o Las descripciones de los casos de uso son cruciales para la comprensión del sistema.
o Debe contar con Pre y Post Condiciones, una Pre-Condición es una restricción sobre cuando un caso de uso puede empezar. que necesita para poder ser ejecutado,
la Post-Condición para un caso de uso debe ser verdadera, independientemente de cual flujo sea ejecutado. Si algo puede fallar, debería cubrirse en la post condición

34. diciendo: “La acción se ha completado o si algo ha fallado, la acción no se ha realizado”, en lugar de decir “La acción se ha completado”.
Prototipos
Los prototipos son modelos a escala o facsímil 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 análisis se usa para obtener los requerimientos del usuario, en la fase de diseño se usa para
ayudar a evaluar muchos aspectos de la implementación seleccionada y así de acuerdo a la necesidad de cada etapa.
Características de un prototipo
o El prototipo es una aplicación que puede no funcionar(conjunto de dibujos por ejemplo, una presentación de escenarios) o que puede funcionar
(conjunto de pantallas que proporcionan un modelo dinámico).
o Los prototipos se crean con rapidez
o Los prototipos evolucionan a través de un proceso iterativo.
o Los prototipos tiene un costo bajo desarrollo.
Definición de criterios de aceptación
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
aceptación realista tanto para el cliente como la empresa que los desarrolla.
para la definición de criterios de aceptación se presenta el siguiente modelo:
o Se debe encontrar el documento de requisito terminado, revisado y aprobado por las diferentes partes, implicadas.
o El requisito no debe tener escenarios ambiguos
o El requisito debe hacer que dice el documento de especificación ni mas, ni menos y cumplir con todos los escenarios.
o El requisito debe ser medible, es fácil identificar si cumple o no cumple.

35. o No existe contraindicaciones con otros requisitos
o El requisito debe haber sido probado y aceptado por este proceso.
o Se debe entregar el requisito dentro de las fechas establecidas.
o El requisito aparte de cumplir con los anteriores pasos, puede haber otros criterios que el cliente solicite.
Capítulo 5 PRUEBAS DE REQUERIMIENTOS
El objetivo de las pruebas de verificación es buscar discrepancias entre los requerimientos y la ejecución del software.
Partiendo de lo anterior se proponen las siguientes actividades para que las pruebas realizadas a los productos desarrollados mediante esta metodología sean correcta, se tendrán en
cuenta las siguientes fases:

36. Planeación
En esta fase se define el alcance y limitaciones de la prueba, la estrategia utilizada para la ejecución de la prueba, los requerimientos para poder realizar las pruebas (documentación, recurso humano y
recurso tecnológico), los tiempos de estimados de duración de la misma y los criterios para terminación.
Entregable: MR_005.1_Planeación Prueba de requerimiento
Diseño de casos de prueba

37. En esta fase se define el checklist con las características a evaluar del requerimiento. A continuación se presenta algunas de las características para evaluar dichos requerimientos
Entregable: MR_005.2_Diseño de Casos de Prueba
Ejecución 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, contraposición, ambigüedad 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

38. como esta
Entregable: MR_005.3_Ejecucion de Casos de Prueba
Cierre
En esta fase una vez se haya completados la ejecución 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 continuación se presentan los entregables o documentos de soporte de la etapa de pruebas del requerimientos de la metodología:
Formato Objetivo
MR_005.1_Planeación Prueba de requerimiento
(Ver Formato)
Presentar la estrategia, alcance, estimación de
tiempos, de la prueba de requerimiento.
MR_005.2_Diseño de Casos de Prueba (Ver
Formato)
Identificar los posibles casos de prueba del
requerimiento
MR_005.3_Ejecucion de Casos de Prueba (Ver
Formato)
Presentar resultado de ejecución de los casos
MR_005.4_Informe final prueba (Ver Formato) Presentar informe de cierre con los aspectos más
relevantes de la ejecución
Capítulo 6 GESTIÓN DE CAMBIOS

39. La gestión de cambio en los proyectos debe ser una coordinación planificada de las actividades que conlleve el logro de los objetivos o propósitos comunes a través de una
comunicación clara y eficiente.
A continuación se presenta el proceso de gestión de cambios con las actividades que se deben llevar a cabo:

40. Identificación Control de cambios
Para una correcta identificación de lo controles de cambios de los requerimientos de las organizaciones de desarrollo de software, se identifican las siguientes actividades:

41. Identificación Control de cambios
Para una correcta identificación de lo controles de cambios de los requerimientos de las organizaciones de desarrollo de software, se identifican las
siguientes actividades:
 Análisis de la Solicitud:
La solicitud es recibida por parte del cliente interno o externo, esta debe ser recibida por parte del líder de implementación 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 análisis con relación al alcance es recomendable buscar colaboración 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 Modificación
El líder de implementación debe realizar el análisis de la solicitud para saber que tanto impacta la modificación 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 documentación clara para evitar ambigüedades en las
modificaciones que se van a realizar a los requerimientos. Este punto apoya también a tener un control de las modificaciones que se realizan sobre un

42. 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 razón del cambio y quien lo aprobó.
Aprobación Control de Cambios
 Aprobar Cambios
Una vez se ha analizado el impacto del cambio, se debe tomar una decisión. 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
Después de tener una aprobación 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 verificación por parte del líder para identificar que el requerimiento incluye todos los cambios
solicitados y que fueron aprobados.
 Actualizar Línea Base
Es recomendable utilizar el nuevo requerimiento como línea base, esto con el fin de trabajar siempre sobre la ultima versión del requerimiento.

43.  Informar
Una vez se realice la modificación 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 identificación de la solicitud realizada por los clientes
internos o externos. Esta documentación 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 documentación del control de cambios se encuentra en el capitulo ocho “Formatos de la Metodología”
Formato Objetivo
MR_006_Control de cambios Describir la situación de cambio solicitada por
el cliente.
Capítulo 7 GESTIÓN DE REQUERIMIENTO
Contenidos
. 1 Matrices de Trazabilidad
1. 1.1 Matriz de relación de documentos
2. 1.2 Matriz de valoración y aprobación de los requisitos

44. . 2 Matriz de Control de cambios
Para que la gestión de los requerimientos sea realmente aplicable al cliente en pro de la satisfacción de las necesidades y control del proyecto en general, se debe cumplir con las
siguientes acciones:
Matrices de Trazabilidad
Matriz de relación de documentos
La siguiente Matriz nos muestra cuales son las relaciones de documentación de cada requisito su clasificación 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.

45. Matriz de valoración y aprobación 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 metodología, 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 documentación de la metodología 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.

46. No Cumple= N, El color rojo es para dar una señal de alerta informando que el requisito no está cumpliendo correctamente con el criterio de aceptación y que se debe revisar porque
razón 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.

48. 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 número de control de cambio que se tiene
asignado, la referencia a la documentación 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 ejecución hasta llegar al 100%, el o los requisitos afectados y una descripción breve del control de cambios.
Esta matriz nos permitirá llevar un control detallado de los controles de cambios solicitados y su estado actual

49. Capítulo 8 FORMATOS DE LA METODOLOGÍA
Los formatos utilizados en las plantillas se presentan como una herramienta de apoyo y soporte a las actividades sugeridas en la presente metodología.
Por lo tanto cada uno de los formatos a utilizar presenta las especificaciones correspondientes para su diligenciamiento.
A continuación se encuentran cada uno de los formatos recomendados para utilizar en los capítulos que hacen parte de esta metodología:
Capitulo Formato Objetivo
Cap 1 FMR_001_Identificacion de
Necesidades
Presentar una descripción 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.
Cap 2 FMR_002_Entrevista Sugerir preguntas que permitan
detallar el requerimiento.
Cap 3 FMR_003_Matrices_Trazabilidad Presentar matrices de trazabilidad
(Relación de documentación, Revisión
de Pares, Registro de Controles de
Cambio)

50. Cap 4 FMR_004.1_00X_Especificacion
Funcional
Especificar detalladamente la
funcionalidad (requerimientos
funcionales y no funcionales) de los
componentes del sistema y sus
interacciones
FMR_004.2_00X_Caso de Uso
FMR_004.3_00X_Especificacion de
Diagramas
Cap 5 FMR_005.1_Planeación Prueba de
requerimiento
Presentar la estrategia, alcance,
estimación de tiempos, de la prueba
de requerimiento.
FMR_005.2_Diseño de Casos de
Prueba
Identificar los posibles casos de
prueba del requerimiento
FMR_005.3_Ejecucion de Casos de
Prueba
Presentar resultado de ejecución de
los casos
FMR_005.4_Informe final prueba Presentar informe de cierre con los
aspectos más relevantes de la
ejecución
Cap 6 FMR_006_Control de cambios Describir la situación de cambio
solicitada por el cliente.
Capítulo 9 MEJORES PRACTICAS
Contenidos
. 1 Mejores practicas en el desarrollo de requisitos
. 2 Mejores prácticas en la gestión de requisitos

51. Actualmente existen y se desarrollan continuamente innumerables metodologías para la gestión de requerimientos para los proyectos de software, por tal motivo es de suma
importancia reconocer la importancia de las metodologías que han impactado la gestión 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 prácticas utilizadas en las diferentes metodologías y así poder asegurar que la metodología propuesta sea
efectiva para el mercado.
En el desarrollo de software, una mejor práctica es un método bien definido que contribuye a una implementación exitosa del proyecto software. Las organizaciones implementan
mejores prácticas 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 continuación se describen una serie de mejores prácticas orientadas al desarrollo de requisitos:
o Documentar el alcance y visión 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.
o Mantener un glosario del proyecto: facilitará una comunicación efectiva asegurando un entendimiento unánime
o Uso de técnicas de obtención de requisitos de usuario: para facilitar esta tarea.
o Involucrar a toda la gente implicada: asegura una validación temprana del entendimiento de los requisitos.
o Desarrollo incremental de requisitos: puede minimizar la cantidad de re-trabajo del proyecto
o Captura de requisitos usando casos de uso: será más fácil gestionar los requisitos y hacer un seguimiento de los mismos
o Validar requisitos: para mejorar el éxito de los proyectos es crítico que se validen los requisitos de forma adecuada
o Verificar requisitos: para asegurar que los requisitos proporcionan una base adecuada para llevar a cabo el diseño, la construcción y las pruebas.

52. Mejores prácticas en la gestión de requisitos
A continuación se muestran una serie de mejores prácticas relacionadas con la gestión de requisitos:
o Priorizar requisitos: para determinar aquellos que se deberían cumplir en la primera versión o producto y aquellos que pueden llevarse a cabo en sucesivas versiones
o Establecer líneas base de los requisitos: para asegurar que cualquier modificación en los requisitos que cambie la línea base se trata como cambios de alcance
o Comunicación abierta: para asegurar que la información relacionada con los requisitos se comunica de forma consistente. Una comunicación abierta también implica
comunicar a la gente correcta y al conjunto mínimo de personas
o Gestión de cambios de los requisitos: es esencial gestionar estos cambios de forma efectiva y eficiente
o Uso de herramientas para la gestión de requisitos: para facilitar la gestión de requisitos
o Mantener trazabilidad de requisitos: para llevar un seguimiento de la vida de un requisito
o Establecer un plan de mejora de procesos para la ingeniería de requisitos: para cumplir con las necesidades actuales y futuras de forma más eficiente y con mayor calidad.
o Formar a los analistas de requisitos: para asegurar que los analistas de requisitos tienen el conocimiento, entre otros aspectos, de cómo escribir buenos requisitos, etc.