República bolivariana de Venezuela.

Instituto Universitario Politécnico

“Santiago Mariño”

Extensión Porlamar

Ingeniería de Requisitos e Ingeniería de

Requerimientos.

Ing. Diógenes Rodríguez Realizado por:

Br. Naylu Rincón

C.I V–20.534.435.

Porlamar Noviembre del 2014

Introducción

En la actualidad, son muchos los procesos de desarrollo de software que

existen. Con el pasar de los años, la Ingeniería de Software ha introducido y

popularizado una serie de estándares para medir y certificar la calidad, tanto

del sistema a desarrollar, como del proceso de desarrollo en sí. Se han

publicado muchos libros y artículos relacionados con este tema, con el

modelado de procesos del negocio y la reingeniería.

La razón principal para escoger este tema se fundamentó en la gran cantidad de proyectos de software que no llegan a cumplir sus objetivos. En nuestro país somos partícipes de este problema a diario, en donde se ha vuelto común la compra de sistemas extranjeros, para luego "personalizarlos" supuestamente a la medida de las empresas a medida que pasa el tiempo se logra entender que el empleo del software es una buena opción para agilizar y sistematizar las tareas en el desarrollo de procesos. El desarrollo de software no es la excepción; en este caso dichas herramientas se han denominado CASE (Ingeniería De Software Asistida Por Computador). Estas incluyen un conjunto de programas que facilitan la optimización de un producto ofreciendo apoyo permanente a los analistas, ingenieros de software y desarrolladores. CASE es la aplicación de métodos y técnicas que dan utilidades a los programas, por medio de otros, procedimientos y su respectiva documentación. Tal "personalización", la mayoría de las veces, termina retrasando el proyecto en meses, o incluso en años. La problemática del año 2000 trajo como consecuencia una serie de cambios apresurados en los sistemas existentes; cambios que, desde mi punto de vista, no fueron bien planificados. El reemplazo de plataformas y tecnologías obsoletas, la compra de sistemas completamente nuevos, las modificaciones de todos o de casi todos los programas que forman un sistema, entre otras razones, llevan a desarrollar proyectos en calendarios sumamente ajustados y en algunos casos irreales; esto ocasiona que se omitan muchos pasos importantes en el mundo de la ingeniería.

Ingeniería de Requisitos

La ingeniería de requisitos es el conjunto de actividades y tareas del proceso de desarrollo de sistemas software que tiene como objetivos:

Definir, con la mejor calidad posible, las características de un sistema software que satisfaga las necesidades de negocio de clientes y usuarios y que se integre con éxito en el entorno en el que se explote. La definición de dicho sistema se realiza mediante lo que se conoce como una especificación de requisitos.

Gestionar las líneas base y las peticiones de cambios que se vayan produciendo en la especificación de requisitos, manteniendo la trazabilidad entre los requisitos y otros productos del desarrollo.

MADEJA recoge la ingeniería de requisitos como pieza clave para proporcionar un sistema de información con calidad. Esta calidad debe entenderse como la satisfacción del usuario ante el sistema de información proporcionado, que cubre las expectativas, deseos y necesidades que los usuarios manifestaron y que se supieron recoger e implementar.

El resultado de esta tarea o actividad no es estático, ya que a lo largo del proyecto pueden aparecer nuevos requisitos, ampliaciones, incluso eliminaciones o modificaciones de los existentes. Cuanto más tarde descubramos requisitos nuevos o haya desviaciones entre los requisitos y el producto, mucho mayor impacto tendrá en tiempo y coste.

Desde este punto de vista, se tiene que considerar la trazabilidad de los requisitos como aspecto fundamental en la gestión de un proyecto. Es decir, actualizar los requisitos del proyecto conforme se vayan produciendo tales cambios, pero sin olvidar la actualización, el impacto y la coherencia de la documentación asociada al mismo: análisis del sistema, diseño, pruebas de validación, etc. A continuación se muestra un gráfico que refleja las dependencias que se establecen entre la definición de requisitos y su gestión de proyectos, el desarrollo del mismo y la documentación de soporte que se genera.

La Ingeniería de Requisitos es una de las partes cruciales en el éxito de todo proyecto software. La aparición de errores o carencias durante la recogida de requisitos implica un descenso en la productividad del proceso de desarrollo y, por lo tanto, un incremento del coste del mismo. Incluir una adecuada ingeniería de requisitos en el ciclo de vida del software minimizará la posibilidad de que esto ocurra. La Ingeniería de Requisitos se convierte en pieza clave para poder medir la calidad de un sistema informático al poder

iniciar la definición de la batería de pruebas que el sistema debe pasar, garantizando que éstas satisfacen los requisitos establecidos y por lo tanto el sistema es válido y funcionalmente es correcto.

http://www.juntadeandalucia.es/servicios/madeja/contenido/subsistemas/ingenieria/ingenieria-requisitos

Definición de Requerimientos

Es el conjunto estructurado de actividades, mediante las cuales obtenemos,

validamos y mantenemos el documento de especificación de requerimientos.

Las actividades del proceso incluyen la extracción de requerimientos, el

análisis, la negociación y la validación. No existe un proceso único que sea

válido de aplicar en todas las organizaciones. Cada organización debe

desarrollar su propio proceso de acuerdo al tipo de producto que se esté

desarrollando, a la cultura organizacional, y al nivel de experiencia y habilidad

de las personas involucradas en la ingeniería de requerimientos.

http://dgsa.uaeh.edu.mx:8080/bibliotecadigital/bitstream/231104/415/1/Ingeni

eria%20de%20requerimientos.pdf

Características de los Requerimientos.

Las características de los requerimientos son sus propiedades principales. Un conjunto de requerimientos en estado de madurez, deben presentar una serie de atributos tanto individualmente como en grupo Características más importantes: Necesario: Si su omisión provoca una deficiencia en el sistema a construir, y además su capacidad, características físicas o factor de calidad no pueden ser reemplazados por otras capacidades del producto o del proceso.

Conciso: Si es fácil de leer y entender. Su redacción debe ser simple y clara para aquellos que vayan a consultarlos en un futuro. Completo: Si no necesita ampliar detalles en su redacción, es decir, si se proporciona la información suficiente para su comprensión. Consistente: Si no es contradictorio con otro requerimiento. No ambiguo: Cuando tiene una sola interpretación. El lenguaje usado en su definición, no debe causar confusiones al lector.

Ingeniería de Requerimientos

El proceso de recopilar, analizar y verificar las necesidades del cliente para un sistema llamado Ingeniería de Requerimientos La meta de la Ingeniería de Requerimientos es entregar una especificación de requisitos de software correcta y completa

Ingeniería de Requerimientos es la disciplina para desarrollar una Especificación completa, consistente y no ambigua, la cual servirá como base para acuerdos comunes entre todas las partes involucradas y en donde se describen las funciones que realizará el sistema Ingeniería de Requerimientos es el proceso por el cual se transforman los requerimientos declarados por los clientes, ya sean hablados escritos, a especificaciones precisas, no ambiguas, consistentes y completas del comportamiento del sistema, incluyendo funciones, interfaces, rendimiento y Limitaciones Es el proceso mediante el cual se intercambian diferentes puntos de vista para recopilar y modelar lo que el sistema va a realizar. Este proceso utiliza una combinación de métodos, herramientas y actores, cuyo producto es un modelo del cual se genera un documento de requerimientos.

Técnicas Principales Aplicadas en la Ingeniería de Requisitos

La ingeniería de requisitos puede ser un proceso largo y arduo para el que se requiere de habilidades psicológicas. Los nuevos sistemas cambian el entorno y las relaciones entre la gente, así que es importante identificar a todos los actores involucrados, considerar sus necesidades y asegurar que entienden las implicaciones de los nuevos sistemas. Los analistas pueden emplear varias técnicas para obtener los requisitos del cliente. 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.

Entrevistas

Las entrevistas son un método común. Por lo general no se entrevista a toda la gente que se relacionará con el sistema, sino a una selección de personas que represente a todos los sectores críticos de la organización, con el énfasis puesto en los sectores más afectados o que harán un uso más frecuente del nuevo sistema.

Talleres

Los requisitos tienen a menudo implicaciones cruzadas desconocidas para las personas implicadas individuales y que a menudo no se descubren en las entrevistas o quedan incompletamente definidas durante la misma. Estas implicaciones cruzadas pueden descubrirse realizando en un ambiente controlado, talleres facilitados por un analista del negocio, en donde las personas implicadas participan en discusiones para descubrir requisitos, analizan sus detalles y las implicaciones cruzadas. A menudo es útil la selección de un secretario dedicado a la documentación de la discusión, liberando al analista del negocio para centrarse en el proceso de la definición de los requisitos y para dirigir la discusión.

Existen dos técnicas de este tipo que son las más utilizadas: Brainstorming (Lluvia de ideas) y JAD (Joint Application Development, Diseño de Aplicación Conjunta). La diferencia que existe entre ambas técnicas es que durante la tormenta de ideas se tiene como objetivo generar una gran cantidad de ideas, es desestructurada y la información que se obtiene puede ser visual, textual ó coloquial; mientras que en el JAD el taller es ordenado, la información que se obtiene es visual y su objetivo es generar requisitos y la interfaz del sistema.

Durante una sesión de Lluvia de ideas, todos los participantes pueden aportar distintas ideas en un ambiente libre de prejuicios. Ningún participante debe juzgar negativamente la propuesta de otros, sino que se anotan todas las ideas en una pizarra y serán evaluadas al final de la sesión. El principio básico es no descartar de manera apresurada ningún planteo, de modo que existe la posibilidad de que surjan otras ideas derivadas de la idea original y se generan varios puntos de vista del problema.

En el Joint application development se trabaja directamente sobre los documentos a generar, las temáticas que se tratan durante las reuniones siguen un esquema y se busca que la misma sea ordenada y racional. Se define una agenda con los puntos principales a tratar durante la jornada. Este tipo de taller tiene el inconveniente de que es muy difícil poder reunir a todos los participantes, es costoso y generalmente es necesaria más de una reunión para establecer los requisitos del sistema.

Forma de contrato

En lugar de una entrevista, se pueden llenar formularios o contratos indicando los requisitos. En sistemas muy complejos éstos pueden tener centenares de páginas.

Objetivos medibles

Los requisitos formulados por los usuarios se toman como objetivos generales, a largo plazo, y en cambio se los debe analizar una y otra vez desde el punto de vista del sistema hasta determinar los objetivos críticos del funcionamiento interno que luego darán forma a los comportamientos apreciables por el usuario. Luego, se establecen formas de medir el progreso en la construcción, para evaluar en cualquier momento qué tan avanzado se encuentra el proyecto.

Prototipos y Casos de uso

Un prototipo es una pequeña muestra, de funcionalidad limitada, de cómo sería el producto final una vez terminado. Ayudan a conocer la opinión de los usuarios y rectificar algunos aspectos antes de llegar al producto terminado.

Un caso de uso es una técnica para documentar posibles requisitos, graficando la relación del sistema con los usuarios u otros sistemas. Dado que el propio sistema aparece como una caja negra, y sólo se representa su interacción con entidades externas, permite omitir dichos aspectos y determinar los que realmente corresponden a las entidades externas. El objetivo de esta práctica es mejorar la comunicación entre los usuarios y los desarrolladores, mediante la prueba temprana de prototipos para minimizar cambios hacia el final del proyecto y reducir los costes finales. Esta técnica se enfrenta a los siguientes peligros potenciales.

A los directivos, una vez que ven un prototipo, les cuesta comprender que queda mucho trabajo por hacer para completar el diseño final.

Los diseñadores tienden a reutilizar el código de los prototipos por temor a “perder el tiempo” al comenzar otra vez.

Los prototipos ayudan principalmente a las decisiones del diseño y de la interfaz de usuario. Sin embargo, no proporcionan explícitamente cuáles son los requisitos.

Los diseñadores y los usuarios finales pueden centrarse demasiado en el diseño de la interfaz de usuario y demasiado poco en producir un sistema que sirva el proceso del negocio.

Los prototipos pueden ser: diagramas, aplicaciones operativas con funcionalidades sintetizadas. Los diagramas, en los casos donde se espera que el software final tenga diseño gráfico, se realizan en una variedad de documentos de diseño gráficos y a menudo elimina todo el color del diseño del software (es decir utilizar una gama de grises). Esto ayuda a prevenir la confusión sobre la apariencia final de la aplicación.

http://es.wikipedia.org/wiki/Ingenier%C3%ADa_de_requisitos

Fases de la Ingeniería de Requerimientos.

Desde un punto de vista conceptual, las actividades son de cinco clases.

Obtener requisitos: a través de entrevistas o comunicación con clientes o futuros usuarios, para saber cuáles son sus expectativas.

Analizar requisitos: detectar y corregir las carencias o falencias comunicativas, transformando los requisitos obtenidos de entrevistas y requisitos, en condiciones apropiadas para ser tratados en el diseño.

Documentar requisitos: igual que todas las etapas, los requisitos deben estar debidamente documentados.

Verificar los requisitos: consiste en comprobar la implementación de los requerimientos.

Validar los requisitos: comprobar que los requisitos implementados sean funcionales para lo que inicialmente se construyó el producto.

http://es.wikipedia.org/wiki/Ingenier%C3%ADa_de_requisitos

Requerimientos de software de la Ingeniería de Requerimientos. Una especificación de requisitos del software es una descripción completa

del comportamiento del sistema a desarrollar. Incluye un conjunto de casos de

uso que describen todas las interacciones que se prevén que los usuarios

tendrán con el software. También contiene requisitos no funcionales (o

suplementarios). Los requisitos no funcionales son los requisitos que imponen

restricciones al diseño o funcionamiento del sistema (tal como requisitos de

funcionamiento, estándares de calidad, o requisitos del diseño).

Las estrategias recomendadas para la especificación de los requisitos del

software están descritas por IEEE 830-1998. Este estándar describe las

estructuras posibles, contenido deseable, y calidades de una especificación

de requisitos del software.

Los requisitos se dividen en tres:

Funcionales: son los que el usuario necesita que efectúe el software. Ej.: el sistema debe emitir un comprobante al asentar la entrega de mercadería.

No funcionales: son los "recursos" para que trabaje el sistema de información (redes, tecnología). Ej: el soporte de almacenamiento a usar debe ser MySQL.

Empresariales u Organizacionales: son el marco contextual en el cual se implantará el sistema para conseguir un objetivo macro. Ej: abaratar costos de expedición.

http://unidad2requerimientos.blogspot.com/2013/03/ingenieria-de-requerimientos.html

Actividades de la Ingeniería de Requerimientos.

Extracción

Esta fase representa el comienzo de cada ciclo. Extracción es el nombre comúnmente dado a las actividades involucradas en el descubrimiento de los requerimientos del sistema. Aquí, los analistas de requerimientos deben trabajar junto al cliente para descubrir el problema que el sistema debe resolver, los diferentes servicios que el sistema debe prestar, las restricciones que se pueden presentar, etc. Es importante, que la extracción sea efectiva, ya que la aceptación del sistema dependerá de cuan bien éste satisfaga las necesidades del cliente.

Análisis

Sobre la base de la extracción realizada previamente, comienza esta fase en la cual se enfoca en descubrir problemas con los requerimientos del sistema identificados hasta el momento. Usualmente se hace un análisis luego de haber producido un bosquejo inicial del documento de requerimientos; en esta etapa se leen los requerimientos, se conceptúan, se investigan, se intercambian ideas con el resto del equipo, se resaltan los problemas, se buscan alternativas y soluciones, y luego se van fijando reuniones con el cliente para discutir los requerimientos.

Especificación

En esta fase se documentan los requerimientos acordados con el cliente, en un nivel apropiado de detalle. En la práctica, esta etapa se va realizando conjuntamente con el análisis, se puede decir que la especificación es el "pasar en limpio" el análisis realizado previamente aplicando técnicas y/o estándares de documentación, como la notación UML (Lenguaje de Modelado Unificado), que es un estándar para el modelado orientado a objetos, por lo que los casos de uso y la obtención de requerimientos basada en casos de uso se utiliza cada vez más para la obtención de requerimientos.

Validación

La etapa final de la IR. Su objetivo es, ratificar los requerimientos, es decir, verificar todos los requerimientos que aparecen en el documento especificado para asegurarse que representan una descripción, por lo menos, aceptable del sistema que se debe implementar. Esto implica verificar que los requerimientos sean consistentes y que estén completos. Se puede apreciar que el proceso de ingeniería de requerimientos es un conjunto estructurado de actividades, mediante las cuales se obtiene, se valida y se logra dar un mantenimiento adecuado al documento de especificación de requerimientos, que es el documento final, de carácter formal, que se obtiene de este proceso. Es necesario recalcar que no existe un proceso único que sea válido de aplicar en todas las organizaciones. Cada organización debe desarrollar su propio proceso de acuerdo al tipo de producto que se esté desarrollando, a la cultura organizacional, y al nivel de experiencia y habilidad de las personas involucradas en la ingeniería de requerimientos. Hay muchas maneras de organizar el proceso de ingeniería de requerimientos y en otras ocasiones se tiene la oportunidad de recurrir a consultores, ya que ellos tienen una perspectiva más objetiva que las personas involucradas en el proceso.

http://unidad2requerimientos.blogspot.com/2013/03/ingenieria-de-requerimientos.html

Dificultades para definir los Requerimientos.

Los requerimientos no son obvios y vienen de muchas fuentes.

Son difíciles de expresar en palabras de lenguaje ambiguo.

Existen muchos tipos de requerimientos y diferentes niveles de detalle.

La cantidad de requerimientos en un proyecto puede ser difíciles de

manejar.

Nunca son iguales. algunos son más difíciles, más riesgosos, mas

importat6ntes o más estables que otros.

Un requerimiento puede cambiar a lo largo del ciclo de desarrollo.

Los requerimientos están relacionados unos con otros, y a su vez se

relacionan con otras partes del proceso.

Cada requerimiento tiene propiedades únicas y abarcan áreas

funcionales específicas.

Son difíciles de cuantificar, ya que cada conjunto de requerimientos es

particular para cada proyecto.

Técnicas y herramientas utilizadas en la Ingeniería de Requerimientos. Técnicas utilizadas en las actividades de IR

Existen varias técnicas para la IR, sin embargo, en este documento se van

a estudiar sólo algunas de ellas. Cada técnica puede aplicarse en una o más

actividades de la IR; en la práctica, la técnica más apropiada para cada

actividad dependerá del proyecto que esté desarrollándose.

Este análisis de Técnica vs. Actividad será discutido en el capítulo IV. Por

el momento sólo mencionaremos en qué consiste cada técnica.

Entrevistas y Cuestionarios

Las entrevistas y cuestionarios se emplean para reunir información

proveniente de personas o de grupos. Durante la entrevista, el analista

conversa con el encuestado; el cuestionario consiste en una serie de

preguntas relacionadas con varios aspectos de un sistema.

Por lo común, los encuestados son usuarios de los sistemas existentes o

usuarios en potencia del sistema propuesto. En algunos casos, son gerentes

o empleados que proporcionan datos para el sistema propuesto o que serán

afectados por él.

Las preguntas que deben realizarse en esta técnica, deben ser preguntas

de alto nivel y abstractas que pueden realizarse al inicio del proyecto para

obtener información sobre aspectos globales del problema del usuario y

soluciones potenciales.

Con frecuencia, se utilizan preguntas abiertas para descubrir sentimientos,

opiniones y experiencias generales, o para explorar un proceso o problema.

Este tipo de preguntas son siempre apropiadas, además que ayudan a

entender la perspectiva del afectado y no están influenciadas por el

conocimiento de la solución.

Las preguntas pueden ser enfocadas a un elemento del sistema, tales

como usuarios, procesos, etc. El siguiente ejemplo algunos tipos de preguntas

abiertas.

Del Usuario

¿Quién es el cliente?

¿Quién es el usuario?

¿Son sus necesidades diferentes?

¿Cuáles son sus habilidades, capacidades, ambiente?

Del Proceso

¿Cuál es la razón por la que se quiere resolver este problema?

¿Cuál es el valor de una solución exitosa?

¿Cómo usted resuelve el problema actualmente?

¿Qué retrasos ocurren o pueden ocurrir?

Del Producto

¿Qué problemas podría causar este producto en el negocio?

¿En qué ambiente se usará el producto?

¿Cuáles son sus expectativas para los conceptos fácil de usar, confiable,

rendimiento?

¿Qué obstáculos afectan la eficiencia del sistema?

El éxito de esta técnica combinada, depende de la habilidad del

entrevistador y de su preparación para la misma. Los analistas necesitan ser

sensibles las dificultades que algunos entrevistados crean durante la entrevista

y saber cómo tratar con problemas potenciales. Asimismo, necesitan

considerar no sólo la información que adquieren a través del cuestionario y la

entrevista, sino también, su significancia Lluvia de Ideas (Brainstorm) Este

método comenzó en el ámbito de las empresas, aplicándose a temas tan

variados como la productividad, la necesidad de encontrar nuevas ideas y

soluciones para los productos del mercado, encontrar nuevos métodos que

desarrollen el pensamiento creativo a todos los niveles, etc. Pero pronto se

extendió a otros ámbitos, incluyendo el mundo de desarrollo de sistemas;

básicamente se busca que los involucrados en un proyecto desarrollen su

creatividad, promoviendo la introducción de los principios creativos.

A esta técnica se le conoce también como torbellino de ideas, tormenta de

ideas, desencadenamiento de ideas, movilización verbal, bombardeo de ideas,

sacudidas de cerebros, promoción de ideas, tormenta cerebral, avalancha de

ideas, tempestad en el cerebro y tempestad de ideas, entre otras.

Principios de la lluvia de ideas

Aplazar el juicio y no realizar críticas, hasta que no agoten las ideas, ya que

actuaría como un inhibidor. Se ha de crear una atmósfera de trabajo en la que

nadie se sienta amenazado.

Cuantas más ideas se sugieren, mejores resultados se conseguirán: "la

cantidad produce la calidad". Las mejores ideas aparecen tarde en el periodo

de producción de ideas, será más fácil que encontremos las soluciones y

tendremos más variedad sobre la que elegir.

La producción de ideas en grupos puede ser más efectiva que la individual.

Tampoco debemos olvidar que durante las sesiones, las ideas de una persona,

serán asociadas de manera distinta por cada miembro, y hará que aparezcan

otras por contacto.

El equipo en una lluvia de ideas debe estar formado por:

El Director: es la figura principal y el encargado de dirigir la sesión. Debe ser

un experto en pensamiento creador. Su función es formular claramente el

problema y que todos se familiaricen con él. Cuando lo haga, debe estimular

ideas y hacer que se rompa el hielo en el grupo. Es el encargado de que se

cumplan las normas, no permitiendo las críticas. Debe permanecer callado e

intervenir cuando se corte la afluencia de ideas, por lo que le será útil llevar ya

un listado de ideas. Debe hacer que todos participen y den ideas. Además, es

la persona que da concede la palabra y da por finalizada la sesión.

Posteriormente, clasificará las ideas de la lista que le proporciona el secretario.

El secretario: registra por escrito las ideas según van surgiendo. Las

enumera, las reproduce fielmente, las redacta y se asegura que todos están

de acuerdo con lo escrito. Por último realizará una lista de ideas.

Los participantes: pueden ser habituales o invitados; cualquier involucrado

en el proyecto entra en esta categoría. Su función es producir ideas. Conviene

que entre ellos no haya diferencias jerárquicas.

http://dgsa.uaeh.edu.mx:8080/bibliotecadigital/bitstream/231104/415/1/Ingenieria%20de%20requerimientos.pdf

Conclusión

Es importante tomarse el tiempo necesario para conocer los problemas y soluciones que se presentaron en esta investigación, ya que hay una serie de actividades y técnicas, que no pertenecen a una sola metodología si no a varias del proceso en sí, si no que una alternativas al material publicado por diferentes actores. El desarrollo de la herramienta surgió gracias al conocimiento del estado del arte en el área de la ingeniería de requisitos, que además permitió identificar los requisitos y requerimientos propios para su implementación. Con el desarrollo se puede soportar la realización de las actividades involucradas en la fase de entendimiento del problema de acuerdo con el proceso unificado; además permite al usuario realizar la actividad de e licitación de requisito organizada y documentadamente. La descripción que se realizó anteriormente permite vislumbrar los antecedentes tenidos en cuenta para generar una nueva herramienta de carácter académico y de uso libre y además de describir de manera completa su uso.

Bibliografía

Leite, J., Hadad, G., Doorn, J., Kaplan, G., “A Scenario Construction Process”,

Requirements Engineering Journal, Vol. 5, Nro. 1, 2000, pp 36-61

McConnell, Steve (1996). Rapid Development: Taming Wild Software

Schedules, 1st ed., Redmond, WA: Microsoft Press.ISBN 1-55615-900-5.

Wiegers, Karl E. (2003). Software Requirements 2: Practical techniques for

gathering and managing requirements throughout the product development

cycle, 2nd ed., Redmond: Microsoft Press. ISBN 0-7356-1879-8.

Landgraf, Katja (2011) Requirement Management in Product Development,

Symposion Publishing ISBN 978-3-939707-84-4

REFERENCIAS DE INTERNET

http://www.juntadeandalucia.es/servicios/madeja/contenido/subsistemas/ingenieria/ingenieria-requisitos

http://dgsa.uaeh.edu.mx:8080/bibliotecadigital/bitstream/231104/415/1/Ingenieria%20de%20requerimientos.pdf

http://es.wikipedia.org/wiki/Ingenier%C3%ADa_de_requisitos

http://unidad2requerimientos.blogspot.com/2013/03/ingenieria-de-requerimientos.html

http://dgsa.uaeh.edu.mx:8080/bibliotecadigital/bitstream/231104/415/1/Ingeni

eria%20de%20requerimientos.pdf