El documento describe el proceso de ingeniería de requisitos para identificar las necesidades del cliente y transformarlas en especificaciones precisas y no ambiguas del sistema. La ingeniería de requisitos se lleva a cabo a través de siete funciones clave: inicio, obtención, elaboración, negociación, especificación, validación y gestión. También se describen varias técnicas para la obtención y análisis de requisitos como entrevistas, casos de uso y prototipos.

2. Proporciona el mecanismo apropiado para comprender lo que el cliente
solicita, analizar las necesidades, evaluar la posibilidad, negociar una solución
razonable, especificar la solución sin equívocos, certificar la definición y gestionar
los requisitos.El trabajo del ingeniero de requisitos es identificar áreas en común y
áreas de conflictos o inconsistencias. Esta es, por supuesto, la última categoría que
presenta un desafío.Esta ingeniería se lleva a cabo a través de siete funciones:
Inicio, obtención, elaboración, negociación, especificación, validación y gestión.
Algunas de las funciones de la ingeniería de requisitos ocurren en paralelo y todas
deben adaptarse a las necesidades del proyecto. Están dirigidas a definir lo que el
cliente quiere y sirven para establecer una base sólida respecto del diseño y la
construcción de lo que obtendrá el cliente.

3. Especifican qué es lo que el sistema debe hacer y sus propiedades esenciales y
deseables. El objetivo principal de la captura de los requerimientos es la
comprensión de lo que los clientes y los usuarios esperan que haga el sistema. Un
requerimiento expresa el propósito del sistema sin considerar como se va a
implantar. En otras palabras, los requerimientos identifican el qué del sistema,
mientras que el diseño establece el cómo del sistema.La captura y el análisis de los
requerimientos 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 requerimientos reduce los
costos y el riesgo general asociado con el desarrollo.

4. -Completo: Cada requerimiento debe describir de manera completa la
funcionalidad que debe cumplir.
-Correcto: Cada requerimiento debe describir de manera precisa la
funcionalidad que se debe construir. Un requerimiento correcto no debe entrar en
conflicto con otro requerimiento.
-Realizable: Debe ser posible implementar cada requerimiento de acuerdo a las
capacidades y limitaciones del sistema y el medio que lo rodea. Para garantizar
que no se determinen requerimientos no realizables, se recomienda contar con
personal al interior del equipo de analistas de requerimientos que pueda
establecer las limitaciones técnicas y de costos.
-Necesario: Cada requerimiento debe documentar algo que los clientes
realmente necesiten, algo que sea para conformidad de un sistema externo con el
que se tenga interacción, o para satisfacer un estándar.
-Priorizable: Es importante asignar una prioridad para cada requerimiento que
indique que tan esencial es el mismo para la realización del producto.

5. 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 a especificaciones precisas, no
ambiguas, consistentes y completas del comportamiento del sistema, incluyendo
funciones, interfaces, rendimiento y Limitaciones.

7. -Entrevistas: Es una técnica muy aceptada dentro de la ingeniería de requisitos
y su uso está ampliamente extendido. Estas le permiten al analista tomar
conocimiento del problema y comprender los objetivos de la solución buscada. La
estructura de la entrevista abarca los siguientes pasos: Identificación de los
entrevistados, preparación de la entrevista, realización de la entrevista y
documentación de los resultados.
-JAD (Joint Application Development/Desarrollo conjunto de aplicaciones): Es
una alternativa a las entrevistas. Es una práctica de grupo que se desarrolla
durante varios días y en la que participan analistas, usuarios, administradores del
sistema y clientes. Está basada en cuatro principios fundamentales que son:
Dinámica de grupo, el uso de ayudas visuales para mejorar la comunicación,
mantener un proceso organizado y racional y una filosofía de documentación
WYSIWYG (What You See Is What You Get, lo que ve es lo que obtiene).Esta
técnica presenta una serie de ventajas frente a las entrevistas tradicionales, ahorra
tiempo al evitar que las opiniones de los clientes se tengan que contrastar por
separado, pero requiere un grupo de participantes bien integrados y organizados.
-Brainstorming (Tormenta de ideas): Técnica de reuniones en grupo y su
objetivo es que los participantes muestren sus ideas de forma libre. Consiste en la
acumulación de ideas y/o información sin evaluar las mismas. El grupo de
personas que participa en estas reuniones no debe ser muy numeroso, una de ellas
debe asumir el rol de moderador de la sesión, pero sin carácter de controlador.

8. -Concept Mapping: Son grafos en los que los vértices representan conceptos y
las aristas representan posibles relaciones entre dichos conceptos. Estos grafos de
relaciones se desarrollan con el usuario y sirven para aclarar los conceptos
relacionados con el sistema a desarrollar. Son muy usados dentro de la ingeniería
de requisitos porque son fáciles de entender por el usuario, más aún si el equipo
de desarrollo hace el esfuerzo de elaborarlo en el lenguaje de éste.
-Sketches y Storyboards: Es frecuentemente usada por los diseñadores gráficos
de aplicaciones en el entorno web. Esta consiste en representar sobre papel en
forma muy esquemática las diferentes interfaces al usuario.
-Casos de Uso: Permiten mostrar el contorno y el alcance 8 de un sistema. Un
caso de uso describe la secuencia de interacciones que se producen entre el
sistema y los actores del mismo para realizar una determinada función. Los
actores son elementos externos que interactúan con el sistema como si de una caja
negra se tratase.
-Cuestionarios y Checklists: Consiste en redactar un documento con preguntas
cuyas respuestas sean cortas y concretas, o incluso cerradas por unas cuantas
opciones en el propio cuestionario.
-Comparación de terminología: Es utilizada en forma complementaria a otras
técnicas para obtener consenso respecto de la terminología a ser usada en el
proyecto de desarrollo. Es necesario identificar el uso de términos diferentes para
los mismos conceptos, misma terminología para diferentes conceptos o cuando
no hay concordancia exacta ni en el vocabulario ni en los conceptos.

9. -Lenguaje natural: Consiste en definir los requisitos en lenguaje natural sin
usar reglas para ello.
-Glosario y ontologías: La diversidad de personas que forman parte de un
proyecto software hace que sea necesario establecer un marco de terminología
común. Esta necesidad se vuelve más patente en los sistemas de información web
puesto que el equipo de desarrollo en ellas suele ser más interdisciplinario. Son
muchas las propuestas que abogan por desarrollar un glosario de términos en el
que se recogen y definen los conceptos más relevantes y críticos para el sistema.
-Plantillas o patrones: Tiene por objetivo el describir los requisitos mediante el
lenguaje natural pero de una forma estructurada. Una plantilla es una tabla con
una serie de campos y una estructura predefinida que el equipo de desarrollo va
complementando usando para ello el lenguaje del usuario. Las plantillas eliminan
parte de la ambigüedad del lenguaje natural al estructurar la información; cuanto
más estructurada sea ésta, menos ambigüedad ofrece.
-Escenarios: Consiste en describir las características del sistema a desarrollar
mediante una secuencia de pasos. Esta representación puede ser casi textual o ir
encaminada hacia una representación gráfica en forma de diagramas de flujo. El
análisis de los escenarios, hechos de una forma u otra, pueden ofrecer
información importante sobre las necesidades funcionales de sistema.

10. -Casos de uso: Como técnica de definición de requisitos es como más
ampliamente han sido aceptados los casos de uso. Actualmente se ha propuesto
como técnica básica del proceso RUP.
-Lenguajes Formales: Es para describir los requisitos de un sistema. Las
especificaciones algebraicas como ejemplo de técnicas de descripción formal, han
sido aplicadas en el mundo de la ingeniería de requisitos desde hace mucho.
-Reviews o Walk-throughs: Consiste en la lectura y corrección de la completa
documentación o modelado de la definición de requisitos.
-Auditorías: Consiste en un chequeo de los resultados contra una checklist
predefinida o definida a comienzos del proceso.
-Matrices de trazabilidad: Consiste en marcar los objetivos del sistema y
chequearlos contra los requisitos del mismo.
-Prototipos: Permitan al usuario hacerse una idea de la estructura de la interfaz
del sistema con el usuario. Tiene el problema de que el usuario debe entender que
lo que está viendo es un prototipo y no el sistema final.

11. -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
requisitos.
-Validar los requisitos: comprobar que los requisitos implementados sean
funcionales para lo que inicialmente se construyó el producto.

12. Requerimientos del sistema
Establecen con detalle las funciones, servicios y restricciones operativas del
sistema. El documento de requerimientos del sistema debe ser funcional. Debe
definir exactamente qué es lo que se va a implementar.
El documento de requerimientos del software
Es la declaración oficial de qué deben implementar los desarrolladores del
sistema. Debe incluir tanto los requerimientos del usuario para el sistema como
una especificación detallada de los requerimientos del sistema.

13. 1. Extracción: La extracción debe ser efectiva, ya que la aceptación del sistema
dependerá de tan bien éste satisfaga las necesidades del cliente.
2. Análisis: Es fase siguiente de la extracción, en la cual se enfoca en descubrir
problemas con los requerimientos del sistema identificados hasta el momento.
Estudiar sobre la base de extracción los requerimientos del cliente los problemas
existentes, como solucionarlos, entre otros puntos de interés.
3. Especificación: Se documentan los requerimientos acordados con el cliente,
en un nivel apropiado de detalle. Aquí se definen con el cliente la documentación
del requerimiento detallando muy bien cada proceso, necesidad, mejora, en fin
conocer en detalle el requerimiento. 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).
4. Validación: Es la etapa final de la IR. Tiene como objetivo, ratificar los
requerimientos, en otras palabras, 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.

14. -Los requerimientos no son obvios y vienen de muchas fuentes.
-Son difíciles de expresar en palabras (el lenguaje es ambiguo).
-Existen muchos tipos de requerimientos y diferentes niveles de detalle.
-La cantidad de requerimientos en un proyecto puede ser difícil de manejar.
-Nunca son iguales. Algunos son más difíciles, más riesgosos, más importantes
o más estables que otros.
-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.
-Un requerimiento puede cambiar a lo largo del ciclo de desarrollo.
-Son difíciles de cuantificar, ya que cada conjunto de requerimientos es
particular para cada proyecto.

15. -Entrevistas cerradas: las preguntas ya están previstas, tienen un orden y una
forma de ser planteadas que no pueden ser modificadas por el entrevistador. Es en
realidad un cuestionario.
Entrevistas abiertas: no se preparan preguntas concretas, y, por el contrario, se
discute con el entrevistado las expectativas que este tiene del sistema.
Casos de Uso y/o Escenarios: Los casos de uso describen interacciones entre los
usuarios y el sistema, enfatizando en lo que el usuario necesita del sistema. Los
escenarios son ejemplos de sesiones de interacción entre el sistema y el usuario,
donde un solo tipo de interacción entre los dos participantes es simulada y
descrita.
Observación y análisis social: La observación permite a los investigadores
observar lo que los usuarios hacen actualmente en un determinado contexto. Esto
permite superar problemas con los participantes del proyecto que realizan
descripciones idealizadas o demasiado simplificadas de los procesos que se llevan
a cabo en sus trabajos.
Lluvia de Ideas: Son sesiones donde todos los participantes brindan sus ideas
para obtener una solución a una problemática. Una lluvia de ideas está compuesta
de dos fases: la fase de generación y la fase de evaluación.

16. -Prototipos: Puede ser usado para colaborar con la definición de los
requerimientos, o para facilitar la evaluación de alternativas de implementación
de un sistema. Existen dos grandes tipos de prototipos. Los prototipos no
funcionales o desechables (Throw away), que sirven para entender la dificultad y
aclarar los requerimientos; y los prototipos funcionales o evolutivos
(Evolutionary) que permiten construir una aproximación del sistema de manera
que se pueda proveer cierta funcionalidad del sistema final y usualmente se
convierten en parte del mismo. Análisis: Es el proceso de analizar las necesidades
de los clientes y los usuarios para llegar a una definición de los requerimientos de
software.
-Dentro de las prácticas principales se encuentra: JAD (Joint Application
Development): Esta práctica se basa en la creación de espacios que permitan
celebrar sesiones o reuniones en donde los participantes y directos interesados
dentro del desarrollo del proyecto buscan obtener o generar conocimiento
alrededor del desarrollo que se va a llevar a cabo.
-Modelos: Esquema teórico, generalmente en forma matemática, de un sistema
o de una realidad compleja, como la evolución económica de un país, que se
elabora para facilitar su comprensión y el estudio de su comportamiento. Existen
dos tipos de modelos.
-Modelo conceptual: Es el utilizado en la especificación del sistema, representa
los conceptos más significativos en el dominio del problema. Nos describe la parte
estática del problema.

17. -Modelo de Comportamiento: Utilizado en la parte de diseño del sistema,
define la parte dinámica. Los diagramas de secuencia y de estados son parte de
este modelo.
-Especificación: Es el desarrollo de un documento que de manera clara y
precisa contenga y especifique cada uno de los requerimientos del sistema de
software.
-Verificación: Es el proceso de asegurar que la especificación de requerimientos
de software sea acorde con los requerimientos del sistema.
-Administración de requerimientos: Es un proceso que tiene por objetivo
comprender y controlar los requerimientos. Como todo proceso de
administración, inicia con la planeación a la par de la identificación inicial de
requerimientos.