ÍNDICE DE CO NTENIDO

1. Intro du cci ó n …… ………………………………………………………… ….. 1

2. I mpo rtan ci a de l o s re qu i si to s ……………………………………… …… 1
3. I mpo rtan ci a de l a de f i n i ció n fo rmal de re qu i si to s………… ……. 4
4. D e fi n i ci ón de requ i si tos y an ál i si s de re qui si to s …………… …… 5
5. Cl asi fi caci ó n de l o s re qu i si to s …………………………………… ……. 6
5.1 . Fu n ci o n ale s ………………………………………………………… ….. 6
5.2 . No fu n ci o n ale s …………………………………………………… ……. 6
5.3 . Re g l as de domi n i o ……………………………………………… ……. 6
6. Ca racte rí sti cas de l os re qu i si to s ………………………………… ……. 7
7. P ro ce so de l a i n g en ie r í a de re qu i sito s ………………………… ……. 8
7.1 . Estu di o de vi abi l i dad …………………………………………… ….. 8
7.2 . O bte n ci ón y an ál i si s de re qu i sito s ………………………… …… 9
7.3 . Espe ci fi caci ón de re qui si to s ………………………………… ……. 9
7.4 . Val i daci ó n de re qui si to s ……………………………………… ……. 10
7.5 . G e sti ón de re qui si to s ………………………………………...… … .. 11
8. Co ncl u sio ne s ……………………………………………...…………… ……. 11
9. Bi bl i o g raf í a…… ………………………………………………………… ……. 12

ÍNDICE DE TABLA S Y F IGURAS

Tabl a 1. Re su l tados de pro ye ctos de so ftware ………………..… ……. 2

Fi gu ra 1. G rá fi co de re su l tados de pro ye cto s de so ftware ………… 2
Tabl a 2 . Facto re s de é xi to de u n proyecto ……………..………… ……. 3
Tabl a 3 . Facto re s qu e de sví an u n pro ye cto ……………………… …….. 3
Tabl a 4. Facto re s qu e can cel an u n pro yecto ……………………… …… 4
Tabl a 5. Co mo se ve n usu ari o s y de sarro l l ado re s e ntre s í … ……… 4
Fi gu ra 2. P ro ce so de i nge nie rí a de requ i si tos …………………… ……. 8
Fi gu ra 3 . P ro bl e mas e n e l de sa rro l l o de si ste mas..... .. .. . ... .. .. .. .. . 10
Fi gu ra 4. Evo l u ci ón de l o s re qu i si to s ……………………………… …….. 11
 1

ANÁLISIS DE REQUISITOS DE INFORMACIÓN

1. INTRODUCCIÓN

El diseño y construcción del software es difícil, creativo y divertido. En

realidad, elaborar software es tan atractivo que muchos desarrolladores de
software quieren ir directo a él antes de haber tenido el entendimiento claro de
lo que se necesita.
El análisis de requisitos es una de las tareas más importantes en el ciclo
de vida del desarrollo de software, puesto que en ella se determinan los
“planos” de la nueva aplicación, se puede definir como el proceso de estudio
de las necesidades de los usuarios para llegar a una definición de los requisitos
del sistema.
En cualquier proyecto de software los requisitos son las necesidades del
producto que se debe desarrollar. Por ello, en la fase de análisis de requisitos
se deben identificar claramente las necesidades y documentarlas. Como
resultado de esta fase se debe producir un documento de especificación de
requisitos en el que se describa lo que el futuro sistema debe hacer. Por tanto,
no se trata simplemente de una actividad de análisis sino también de síntesis.
En la determinación de los requisitos no sólo deben actuar los analistas,
es muy importante la participación de los propios usuarios, porque son estos
los que mejor conocen el sistema que se va a automatizar. Analista y cliente se
deben poner de acuerdo en las necesidades del nuevo sistema, ya que el cliente
no suele entender el proceso de diseño y desarrollo de software como para
redactar una especificación de requisitos de software (ERS) y los analistas no
suelen entender completamente el problema del cliente, debido a que no
dominan su área de trabajo.
Cada uno de los modelos del proceso de desarrollo del software propuesto,
incluye actividades que apuntan a la captura de requisitos, basándose en
estos, el ingeniero de software procederá al modelado del futuro sistema
utilizando diferentes tipos de metodologías entre las que destacan la
metodología estructurada y la metodología orientada a objetos (por ejemplo
DFD y UML respectivamente).

2. IMPORTANCIA DE LOS REQUISITOS

Sabemos que muchos proyectos de software fracasan porque no se realiza

un estudio previo de los requisitos del usuario, no se hace una definición
completa del alcance del proyecto. No se realiza el modelado del negocio antes
de desarrollar el software, esto significa que el analista no se involucra en el
problema; aunque tiene claro que el sistema debe desarrollarse para dar
soporte a los procesos de la organización.
Requisitos incompletos y el cambio frecuente de los requisitos establecidos
son otros de los factores que llevan al sistema al fracaso, entonces es
importante que no exista carencia de requisitos bien definidos porque así
evitamos la siguiente lista de problemas.
 2

 No se realizan estimaciones realistas.

 No se emplean coherentemente herramientas de planeación.
 No se puede realizar versiones periódicas del progreso en base a
especificaciones.
 La arquitectura, el diseño y el desarrollo de software carecerán de una base
firme.
 Las pruebas se basaran en supuestos, no en lo que el usuario requiere.
 No es posible controlar e crecimiento de los requisitos.
The Standish Group1 hizo un estudio sobre las compañías y proyectos de
software para averiguar cómo les estaba yendo, los resultados fueron
decepcionantes.
A continuación se muestra una tabla de los resultados de proyectos de
software en EE.UU:

AÑOS EXITOSO DESVIADO CANCELADO

1994 16% 53% 31%
1996 27% 33% 40%
1998 26% 46% 28%
2000 28% 49% 23%
2004 29% 53% 18%
Tabla 1. Resultados de proyectos de software.

EXITOSO: El proyecto es completado en el tiempo y presupuesto con todas las

características y funcionalidades especificadas.
DESVIADO: El proyecto es completado y operacional, pero sobre el presupuesto
fuera de plazo y con pocas características y funcionalidades inicialmente
especificadas.
CANCELADO: El proyecto es cancelado antes de completarse o nunca se
implementó.

Figura 1. Gráfico de resultados de proyectos de software.

1
The Standish Group es una organización de asesoramiento de investigación principal que se enfoca en el
rendimiento de proyectos de software.
 3

The Standish Group encuestó a los gerentes ejecutivos sobre cuáles

podrían ser las causas para que un proyecto fallara o sea exitoso, uno de los
principales resultados que sale a relucir está relacionada con los requisitos, a
continuación veremos en las siguientes tablas el factor que tienen estos:
Factores que contribuyen al éxito

Project Sucess Factors % of Responses

1. User involvement 15.9%
2. Executive Mangement Support 13.9%
3. Clear Statement of Requirements 13.0%
4. Proper Planning 9.6%
5. Realistic Expectations 8.2%
6. Smaller Proyect Milestones 7.7%
7. Competent Staff 7.2%
8. Ownership 5.3%
9. Clear Vision & Objectives 2.9%
10. Hard-Working, Focused Staff 2.4%
Others 13.9%
Tabla 2. Factores de éxito de un proyecto.

Factores que ponen en problemas un proyecto

Project Challenged Factors % of Responses

1. Lack of User Input 12.8%
2. Incomplete Requirements & Specifications 12.3%
3. Changing Requirements & Specifications 11.8%
4. Lack of Executive Support 7.5%
5. Technology Incompetence 7.0%
6. Lack of Resources 6.4%
7. Unrealistic Expectations 5.9%
8. Unclear Objectives 5.3%
9. Unrealistic Time Frames 4.3%
10. New Technology 3.7%
Others 23.0%
Tabla 3. Factores que desvían un proyecto.

Factores que causan una cancelación

Project Impaired Factors % of Responses

1. Incomplete Requirements 13.1%
2. Lack of User Involvement 12.4%
3. Lack of Resources 10.6%
4. Unrealistic Expectations 9.9%
5. Lack of Executive Support 9.3%
6. Changing Requirements & Specifications 8.7%
 4

7. Lack of Planning 8.1%

8. Didn’t Need It Any Longer 7.5%
9. Lack of IT Management 6.2%
10. Technology Illiteracy 4.3%
Other 9.9%
Tabla 4. Factores que cancelan un proyecto.

3. IMPORTANCIA DE LA DEFINICIÓN FORMAL DE REQUISITOS

El análisis y especificación de requisitos puede parecer una tarea

relativamente sencilla, pero las apariencias engañan. Puesto que el contenido
de comunicación es muy alto, abundan los cambios por mala interpretación o
falta de información. El dilema con el que se enfrenta un ingeniero de software
puede ser comprendido repitiendo la sentencia del cliente anónimo: “Sé que
crees que comprendes lo que piensas que he dicho, pero no estoy seguro de
que entendiste lo que yo quise decir”. En la siguiente tabla se ilustra el conflicto
que encontró (Scharer, 1990) cuando los desarrolladores y los usuarios se
limitan a ver el problema desde su particular punto de vista sin tomar en
cuenta la situación del otro.

Como ven los desarrolladores a los
usuarios.
Los usuarios no saben lo que quieren.
Los usuarios no pueden articular lo
que quieren.
Los usuarios lo quieren todo bien y
ahora.
Los usuarios tienen muchas
necesidades motivadas políticamente.
Los usuarios son incapaces de
priorizar sus necesidades.
Los usuarios rehúsan tomar
responsabilidades por el sistema.
Los usuarios son incapaces de
proporcionar un enunciado utilizable
de las necesidades.
Los usuarios no están comprometidos
con los proyectos de desarrollo de
sistemas.
Los usuarios no tienen voluntad de
colaborar.
Los usuarios no pueden mantener el
cronograma.
Tabla 5. Como se ven usuarios y desarrolladores entre sí.
Como ven los usuarios a los
desarrolladores
Los desarrolladores no comprenden las
necesidades operacionales.
Los desarrolladores ponen demasiado
énfasis en la técnica.
Los desarrolladores pretenden decirnos
como hacer nuestro trabajo.
Los desarrolladores no pueden traducir
nuestras necesidades claramente
establecidas a un sistema exitoso.
Los desarrolladores dicen “no” todo el
tiempo.
Los desarrolladores siempre están por
encima del presupuesto.
Los desarrolladores siempre están
atrasados.
Los desarrolladores piden a los
usuarios tiempo y esfuerzo, aún en
detrimento de sus obligaciones
primarias importantes.
Los desarrolladores establecen
estándares no realistas para la
definición de los requisitos.
Los desarrolladores son incapaces de
responder rápidamente a los legítimos
cambios de las necesidades.
 5

En realidad existen muchos contribuyentes al conjunto de requisitos, cada

uno tiene una visión particular del sistema de cómo debe funcionar, a menudo
estas visiones son conflictivas. Una de las muchas habilidades de una analista
de requisitos es la capacidad para comprender cada punto de vista y capturar
requisitos de una manera que refleje los intereses de cada participante.

4. DEFINICIÓN DE REQUISITOS Y ANÁLISIS DE REQUISITOS

Requisitos: Los requisitos especifican que es lo que el sistema debe hacer

(sus funciones) y sus propiedades esenciales y deseables. La captura de
requisitos tiene como objetivo principal la comprensión de que los clientes y
los usuarios esperan que haga el sistema. Un requisito expresa el propósito
del sistema sin considerar como se va a implementar. En otras palabras, los
requisitos identifican el qué del sistema, mientras que el diseño establece el
cómo del sistema.

La captura y el análisis de los requisitos del sistema es una de las fases

más importantes para que el proyecto tenga éxito. Como regla de modo
empírico, el costo de reparar un error se incrementa en un factor de diez de
una fase de desarrollo a la siguiente, por lo tanto la preparación de una
especificación adecuada de requisitos reduce los costos y el riesgo general
asociado con el desarrollo.
Análisis de requisitos: Es el conjunto de técnicas y procedimientos que
nos permiten conocer los elementos necesarios para definir un proyecto de
software, es una tarea que permite especificar las características operacionales
del software.
La especificación de requisitos suministra al desarrollador y al cliente, los
medios para valorar el cumplimiento de resultados, procedimientos y datos,
una vez que se haya construido.
La tarea de análisis de requisitos es un proceso de descubrimiento y refina
miento, el cliente y el desarrollador tienen un papel activo en la ingeniería
de requisitos de software. El cliente intenta plantear un sistema que en
muchas ocasiones es confuso para él, sin embargo, es necesario que describa
los datos, que especifique las funciones y el comportamiento del sistema que
desea. El objetivo es que el desarrollador actúe como un negociador, un
interrogador, un consultor, o sea, como persona que consulta y propone para
resolver las necesidades del cliente.
“La carencia de buenos requisitos ha sido la causa del fracaso de proyectos
con presupuestos de millones de dólares, ha impedido el desarrollo productivo,
y ha sido el mayor contribuyente de los costes elevados del mantenimiento de
software”2

2
Dr. Raymond Yeh in the forward to System and Software Requirements Engineering, IEEE Comouter
Society Press Tutorial, Editors, M. Dorfman, and R. H. Thayer, 1990.
 6

5. CLASIFICACIÓN DE LOS REQUISITOS

Tradicionalmente los requisitos del software se descomponen en requisitos

funcionales y no funcionales, y últimamente apareció otra categoría que son
las reglas del dominio.
5.1. Funcionales.
Son las funciones o características que describen que debe hacer el
sistema, describe la interacción con su ambiente y detalla cómo debe
comportarse el sistema ante un determinado estímulo.

Son declaraciones de los servicios que debe proporcionar el sistema,

de la manera en que éste debe reaccionar a entradas particulares y de
cómo se debe comportar en situaciones particulares. En algunos de los
casos, también pueden declarar explícitamente lo que el sistema no debe
hacer.

Cuando se expresan como requisitos de usuario, se define de forma

general. Cuando se expresan como requisitos del sistema, describen con
detalle la función de éste, sus entradas y salidas, excepciones, etc.
[Como ejemplo, pongámonos en el caso de un cajero automático de
banco que ofrece a los clientes, la posibilidad las 24 horas del día en casi
cualquier lugar cercano al que se encuentre el cliente; obtener
información sobre saldo y movimiento de sus cuentas, de forma que
ofrece un valor a las personas que tienen una manera sencilla de
mantener un control sobre sus finanzas personales, una persona observa
eso de valor, resuelve sus necesidades, y tanto es así que está dispuesto
a pagar por ello].
5.2. No funcionales.
Son los atributos de calidad del sistema (del tipo prestaciones), 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.
Muchos requisitos no funcionales se refieren al sistema como un todo
más que a rasgos particulares del mismo.
A menudo son más críticos que los funcionales, mientras que un
incumplimiento de un requisito funcional degrada el sistema, el de un
requisito no funcional lo inutiliza.
5.3. Reglas de dominio.
Son requisitos que representan prestaciones generales del dominio
de aplicación de la empresa en que se sitúa o del sistema legal. Son por
ejemplo, la ley de protección de datos de carácter personal.
Si hay algo que distingue a las reglas de dominio es que no aplican a
un solo sistema en concreto, sino a todos los sistemas de la organización.

Hay muchas clasificaciones más pormenorizadas de los que se describió,

de grandes clientes de software como la Agencia Espacial Europea que
proporcionan clasificaciones asociado al Modelo de Proceso Unificado (UML),
 7

existen estándares como el ISO/IEC 2500 que si bien están pensados para
valorar la calidad de los productos de software a través de una serie de
atributos puede ser usado al revés para clasificar los requisitos en función de
ese estándar de forma que garantice que al final se cumpla los criterios de
calidad.

6. CARACTERÍSTICAS DE LOS REQUISITOS

Los requisitos permiten que los desarrolladores expliquen cómo han

entendido lo que el cliente pretende del sistema. También, indican a los
diseñadores que funcionalidad y que características va a tener el sistema
resultante. Y además, indican al equipo de pruebas qué demostraciones llevar
a cabo para convencer al cliente de que el sistema que se le entrega es lo que
solicitó.
Los requisitos deben ser de alta calidad para la buena comprensión de
clientes y desarrolladores. Con este fin de comprobarse que los requisitos
posean características que se desprenden según el estándar IEEE830 que los
explica [Pfleeger, 2002] y es como sigue:
Deben ser correctos
Tanto el cliente como el desarrollador deben revisarlos para asegurar que
no tienen errores.

Deben ser consistentes

Dos requisitos son inconsistentes cuando es imposible satisfacerlos
simultáneamente. Es decir que no deben ser conflictivos ni ambiguos.

Deben estar completos

El conjunto de requisitos está completo si todos los estados posibles,
cambios de estado, entradas, productos y restricciones están descritos en
alguno de los requisitos.

Deben ser realistas

¿El sistema puede hacer realmente lo que el cliente está pidiendo que haga?
Todos los requisitos deben ser revisados para asegurar que son posibles.

¿Cada requisito describe algo que es necesario para el cliente?

Los requisitos deben ser revisados para conservar sólo aquellos que inciden
directamente en la resolución del problema del cliente.

Deben ser verificables

Se deben poder preparar pruebas que demuestren que se han cumplido los
requisitos.

Deben ser rastreables

¿Se puede rastrear cada función del sistema hasta el conjunto de requisitos
que la establece? ¿Resulta fácil encontrar el conjunto de requisitos que
coinciden a un aspecto específico del sistema?
 8

7. PROCESO DE LA INGENIERÍA DE REQUISITOS

El análisis de requisitos es todo un proceso al cual [Sommerville, 2005]

llama “Ingeniería de Requisitos” cuya meta es crear y mantener un documento
de requisitos del sistema. Este proceso general consta de cuatro subprocesos:
 El estudio de la viabilidad que evalúa si el sistema es útil para el negocio.
 Obtención y análisis de requisitos.
 Especificación de requisitos: es la transformación de los requisitos en
formularios estándar.

 Validación: verificar que los requisitos realmente definen el sistema que

quiere el cliente.
En la siguiente figura se muestra el proceso de ingeniería de requisitos.

Figura 2. Proceso de ingeniería de requisitos (Sommerville, 2005)

7.1. Estudio de viabilidad

[Sommerville, 2005] define el estudio de viabilidad como un estudio

corto para ver si es posible construir el sistema con la tecnología
existente, las restricciones de costo, tiempo, etc. Orientado a resolver las
siguientes preguntas:
- ¿El sistema contribuye a los objetivos generales de la organización o
empresa?
- ¿El sistema se puede implantar utilizando tecnología actual dentro
de las restricciones del tiempo y presupuesto?
- ¿El sistema puede integrarse a otros sistemas existentes en la
empresa?
El estudio de viabilidad no debe requerir más de dos o tres semanas.
El resultado de este estudio es un informe que recomiende si vale la pena
seguir con la ingeniería de requisitos y el proceso de desarrollo del
sistema. En el informe se pueden proponer cambios en el alcance, el
presupuesto o sugerir requisitos adicionales de alto nivel.
 9

7.2. Obtención y análisis de requisitos

La siguiente etapa del proceso de ingeniería de requisitos es la
obtención y análisis de requisitos. En esta actividad, los ingenieros de
software trabajan con los clientes y los usuarios finales del sistema para
determinar el dominio de la aplicación, qué servicios debe proporcionar
el sistema, el rendimiento requerido del sistema, las restricciones
hardware, etcétera.
Los requisitos se pueden extraer de muchas maneras, [Sommerville,
2005] sugiere ser creativos en la forma de averiguar qué es lo que los
clientes quieren y propone:
- Revisar la situación actual.
- Trabajar en el ámbito del usuario para comprender el contexto, los
problemas y las relaciones.
- Entrevistar a los usuarios actuales y potenciales.
- Realizar un video para mostrar cómo podría funcionar el nuevo
sistema.
- Investigar en documentos existentes.
- Conducir tormentas de ideas con los usuarios actuales y
potenciales.
- Observar las estructuras y los patrones.

7.3. Especificación de requisitos

La especificación es un documento que define, de forma completa,
precisa y verificable, los requisitos, el diseño y el comportamiento u otras
características de un sistema o componente de un sistema.
Para realizar bien el desarrollo de software es esencial tener una
especificación completa de los requisitos, la forma de especificar tiene
mucho que ver con la calidad de la solución.
Los ingenieros de software se han esforzado en trabajar en
especificaciones incompletas, inconsistentes o mal establecidas, han
experimentado la frustración y confusión que invariablemente se
produce.
Como se ilustra en la siguiente figura, las consecuencias se padecen
en la calidad, oportunidad y completitud del software resultante.
 10

Figura 3. Problemas en el desarrollo de sistemas.

7.4. Validación de requisitos

La validación de requisitos sirve para demostrar que éstos realmente
definen el sistema que el cliente desea, asegura que los requisitos estén
completos, sean exactos y consistentes. Debe garantizar que lo descrito
es lo que el cliente pretende ver en el producto final, esta validación es
importante porque la detección de errores durante el proceso de análisis
de requisitos reduce mucho los costos.
Existen varias técnicas de validación de requisitos, estas son:
revisiones de requisitos, construcción de prototipos y generación de casos
de prueba.
La revisión de requisitos es un proceso manual en la que intervienen
tanto el cliente como el personal involucrado en el desarrollo del sistema,
ésta puede ser formal o informal, y tiene el fin de verificar que el
documento de requisitos no presente anomalías ni omisiones.
La construcción del prototipo consiste en mostrar un modelo
ejecutable del sistema a los usuarios finales y a los clientes, así estos
pueden experimentar con el modelo para ver si cumple con las
necesidades reales.
Los requisitos deben probarse, es por esto que se debe hacerse una
generación de casos de prueba. Si una prueba es difícil o imposible de
diseñar, normalmente significa que los requisitos serán difíciles de
implantar y deberían ser considerados nuevamente.
 11

En resumen, la validación pretende asegurar que los requisitos

satisfarán las necesidades del cliente.
7.5. Gestión de requisitos. (Manejo de los cambios de requisitos durante la
construcción).
En la práctica en casi todos los sistemas los requisitos cambian, se
hacen modificaciones a los sistemas de hardware, software y el entorno
organizacional. El proceso de organizar y llevar a cabo los cambios en los
requisitos se llama gestión de requisitos.
Una vez que un sistema se ha instalado, inevitablemente surgen
nuevos requisitos. Es difícil para los usuarios y clientes del sistema
anticipar qué efectos tendrá el sistema nuevo en la organización. Cuando
los usuarios finales tienen experiencia con un sistema, descubren nuevas
necesidades y prioridades.
En la siguiente figura se muestra como se tiene una mejor
comprensión de las necesidades de los usuarios conforme se va
desarrollando la definición de requisitos, esta nueva comprensión
retroalimenta al usuario, quien puede proponer entonces un cambio en
los requisitos.

Figura 4. Evolución de los requisitos.

8. CONCLUSIONES

Un requisito “es una característica del sistema o una descripción de algo

que el sistema es capaz de hacer con el objeto de satisfacer el propósito del
sistema”.

Para conseguir el éxito en cualquier desarrollo de un sistema es esencial

la comprensión total de los requisitos del usuario. No importa lo bien diseñado
o codificado que pueda estar, si no se ha analizado correctamente puede
defraudar al usuario y frustrar al desarrollador.
El análisis y la especificación de los requisitos pueden parecer una tarea
relativamente sencilla, pero, en realidad, el contenido del análisis es muy
denso y abundan las malas interpretaciones o la falta de información. Es muy
difícil evitar la ambigüedad.
 12

La tarea del análisis de requisitos es un proceso de descubrimiento,

refinamiento, modelado y especificación y, por tanto, el desarrollador y el
cliente tienen un papel activo en la obtención de estas necesidades.

El hecho de enfocar el análisis de requisitos hacia el usuario tiene una

doble ventaja: por un lado evita las tendencias del informático hacia un diseño
técnico que permita optimizaciones innecesarias o complicaciones añadidas;
por otro lado, la participación del usuario en el proceso y la utilización de su
lenguaje cotidiano en la reacción de los casos de uso facilita la identificación
de las necesidades del sistema.

9. BIBLIOGRAFÍA

 Gómez Fuentes, María del C. (2011). Notas del curso: Análisis de

Requerimientos. México DF, México: Publidisa Mexicana S.A.
 Maita, Y. (2012). Los requerimientos y su importancia en el desarrollo de
software [Blog post]. Recuperado de: http://kuainasi.ciens.ucv.ve/red_educa
tiva/blogs/20
 Monferrer Agut, R. (2000-2001). Especificación de Requisitos de Software
según el estándar de IEEE 830. Castellón de la Plana, España:
Departament d’Informàtica – Universitat Jaume I.
 Pleeger, Shari L. (2002). Ingeniería de software. Teoría y práctica. Buenos
Aires, Argentina: Pearson Education.
 Sanchez, S. (2011). Unidad 1.3 Análisis de Requerimientos [Slisdeshare].
Recuperado de https://es.slideshare.net/SergioRios/unidad-13-analisis-de-
requerimientos
 Sommerville, Ian. (2005). Ingeniería del Software. Madrid, España: Pearson
Addison Wesley.
 Standish Group. (s.f.). About The Standish Group [online]. Recuperado de:
https://www.standishgroup.com/about
 The Standish Group Report. (2014). Chaos Report [PDF en línea].
Recuperado de https://www.projectsmart.co.uk/white-papers/chaos-report.pdf
 Universidad Politécnica de Madrid [UPM]. (2014, December 12). Métodos
ágiles e ingeniería de requisitos con historias de usuario [Archivo de
video]. Recuperado de:
https://www.youtube.com/watch?v=PEaqUlwyDS4&t=150s