Sistemas II, Ingenieria de requisitos y requerimientos

1. República Bolivariana de Venezuela
Ministerio del Poder Popular para la Educación Universitaria
Instituto Universitario Politécnico Santiago Mariño
Asignatura: Sistemas II
Escuela: Sistemas (47)
INGENIERÍA DE REQUISITOS E INGENIERÍA DE REQUERIMIENTOS
Facilitador: Bachiller:
Ing. Diógenes Rodríguez Brito Anthoni Y. Cedeño N.
CI.: 25.877.214
Porlamar, Julio Del 2017

2. Introducción
La Ingeniería de Requisitos es aquella que 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 objetivo 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. Sus funciones principales son:
Inicio, obtención, elaboración, negociación, especificación, validación y gestión.
Los requerimientos son los que especifican qué es lo que el sistema debe hacer y
sus propiedades esenciales y deseables. Su 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. Este 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. Entre las características
de un Requerimiento encontramos: Completo, Correcto, Realizable, Necesario,
Priorizable.
La ingeniería de Requerimientos viene a ser 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.
Las técnicas principales aplicadas en la Ingeniería de Requisitos son: 1) Captura de
Requisitos (Entrevistas, JAD (Joint Application Development/Desarrollo conjunto de
aplicaciones), Brainstorming (Tormenta de ideas), Concept Mapping, Sketches y
Storyboards, Casos de Uso, Cuestionarios y Checklists, Comparación de terminología);
2) Definición de requisitos (Lenguaje natural, Glosario y ontologías, Plantillas o
patrones, Escenarios, Casos de uso, Lenguajes Formales); 3) Validación de Requisitos
(Reviews o Walk-throughs, Auditorías, Matrices de trazabilidad, Prototipos).

3. Entre las fases de la Ingeniería de requerimientos podemos mencionar: Obtención
requisitos, Análisis de requisitos, Documentar requisitos, Verificar los requisitos, Validar
los requisitos.
Los requerimientos de software de la Ingeniería de requerimientos comprenden:
Requerimientos del sistema y el documento de requerimientos del software.
Existen actividades de la Ingeniería de Requerimientos las cuales son: Extracción,
Análisis, Especificación, Validación.
También podemos encontrar dificultades para definir los Requerimientos y técnicas
y herramientas utilizadas en la Ingeniería de Requerimientos.

4. Ingeniería de Requisitos
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.
-Al analizar los resultados y según la opinión de Ennovi221 (2011): “La ingeniería de
requisitos proporciona el mecanismo apropiado para entender lo que el cliente quiere,
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.
(Párrafo 1)
El trabajo del ingeniero de requisitos es identificar áreas en común (es decir, los
requisitos en los que todos los interesados están de acuerdo) y áreas de conflictos o
inconsistencias (esto es, los requisitos solicitados por los interesados que entran en
conflictos con las necesidades de otro). Esta es, por supuesto, la última categoría que
presenta un desafío. (Párrafo 3)
La ingeniería de requisitos se lleva a cabo a través de siete funciones: Inicio,
obtención, elaboración, negociación, especificación, validación y gestión. Es importante
destacar que algunas de las funciones de la ingeniería de requisitos ocurren en paralelo y
que todas deben adaptarse a las necesidades del proyecto. Todas están dirigidas a definir
lo que el cliente quiere, y todas sirven para establecer una base sólida respecto del diseño
y la construcción de lo que obtendrá el cliente. (Párrafo 4)”

5. Definición de Requerimientos
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.
-Al analizar los resultados y según la opinión de Editorial (2014): “Los requerimientos
especifican qué es lo que el sistema debe hacer (sus funciones) y sus propiedades
esenciales y deseables. La captura de los requerimientos tiene como objetivo principal 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. (Párrafo 1)
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 [Norris & Rigby, 1994].
(Párrafo 2)”
Características de los Requerimientos
Las características son las propiedades principales de un requerimiento. Un
conjunto de requerimientos en estado de madurez, deben presentar una serie de
características tanto individualmente como en grupo.

6. Características de la Descripción de un Requerimiento:
 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.
-Al analizar los resultados y según la opinión de R. González Brenda M. (2012): “Las
características de un requerimiento son sus propiedades principales. Un conjunto de
requerimientos en estado de madurez, deben presentar una serie de características tanto
individualmente como engrupo.
Características de la Descripción de un Requerimiento:
Las características que tiene una buena descripción individual de un requerimiento,
que lo diferencian de uno mal descrito, son:
• Completo: Cada requerimiento debe describir de manera completa la funcionalidad
que debe cumplir. Debe contener toda la información necesaria para que el desarrollador
diseñe e implemente tal funcionalidad.
• Correcto: Cada requerimiento debe describir de manera precisa la funcionalidad que
se debe construir. Un requerimiento correcto no debe entrar en conflicto con otro

7. requerimiento. Sólo los usuarios más representativos del sistema pueden determinar de
manera precisa si un requerimiento es correcto o no.
• 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. Para determinar si un requerimiento es
necesario se debe determinar quién lo propuso, es decir, conocer su origen.
• Priorizable: Es importante asignar una prioridad para cada requerimiento que indique
que tan esencial es el mismo para la realización del producto. Se pueden perder elementos
de juicio para el desarrollo del sistema si se asigna el mismo grado de prioridad a todos los
requerimientos.”
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 a especificaciones precisas, no ambiguas, consistentes y
completas del comportamiento del sistema, incluyendo funciones, interfaces,
rendimiento y Limitaciones.
-Al analizar los resultados y según la opinión de Naylu Rincón (2014): “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,

8. consistentes y completas del comportamiento del sistema, incluyendo funciones,
interfaces, rendimiento y Limitaciones.”(Pág. 5)
Técnicas principales aplicadas en la Ingeniería de Requisitos
Captura de Requisitos
 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.
 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.

9.  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.
Definición de requisitos
 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

10. 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.
 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.
Validación de Requisitos
 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.
-Al analizar los resultados y según la opinión de Isidro Gonzalez (2017): “Captura de
Requisitos
• Entrevistas: resultan una técnica muy aceptada dentro de la ingeniería de requisitos y
su uso está ampliamente extendido. Las entrevistas le permiten al analista tomar
conocimiento del problema y comprender los objetivos de la solución buscada. A través de
esta técnica el equipo de trabajo se acerca al problema de una forma natural. Existen

11. muchos tipos de entrevistas y son muchos los autores que han trabajado en definir su
estructura y dar guías para su correcta realización (Durán, Bernáldez, Ruíz & Toro, 1999 y
Pan, Zhu & Jonhson, 2001). Básicamente, la estructura de la entrevista abarca tres pasos:
identificación de los entrevistados, preparación de la entrevista, realización de la entrevista
y documentación de los resultados (protocolo de la entrevista).
A pesar de que las entrevistas son esenciales en el proceso de la captura de requisitos
y con su aplicación el equipo de desarrollo puede obtener una amplia visión del trabajo y
las necesidades del usuario, es necesario destacar que no es una técnica sencilla de
aplicar (Pan, Zhu & Johnson, 2001). Requiere que el entrevistador sea experimentado y
tenga capacidad para elegir bien a los entrevistados y obtener de ellos toda la información
posible en un período de tiempo siempre limitado.
• JAD (Joint Application Development/Desarrollo conjunto de aplicaciones): esta
técnica resulta 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 (IBM, 1997). Está basada en cuatro principios fundamentales: 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), es decir, durante la aplicación de la técnica se
trabajará sobre lo que se generará. Tras una fase de preparación del JAD al caso concreto,
el equipo de trabajo se reúne en varias sesiones.
Esta técnica presenta una serie de ventajas frente a las entrevistas tradicionales, ya
que 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): es también una técnica de reuniones en grupo
cuyo objetivo es que los participantes muestren sus ideas de forma libre (Raghavan,
Zelesnik & Ford, 1994). Consiste en la mera 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 (máximo 10 personas), una de ellas debe asumir el rol de moderador de la
sesión, pero sin carácter de controlador.
Como técnica de captura de requisitos es sencilla de usar y de aplicar, contrariamente
al JAD, puesto que no requiere tanto trabajo en grupo como éste. Además suele ofrecer

12. una visión general de las necesidades del sistema, pero normalmente no sirve para
obtener detalles concretos del mismo, por lo que suele aplicarse en los primeros
encuentros.
• Concept Mapping: Los mapas conceptuales (Pan, Zhu & Johnson, 2001) 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, pues 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: Está técnica es frecuentemente usada por los diseñadores
gráficos de aplicaciones en el entorno web. La misma consiste en representar sobre papel
en forma muy esquemática las diferentes interfaces al usuario (sketches). Estos sketches
pueden ser agrupados y unidos por enlaces dando idea de la estructura de navegación
(storyboard).
• Casos de Uso: Aunque inicialmente se desarrollaron como técnica para la definición
de requisitos (Jacobson, 1995), algunos autores proponen casos de uso como técnica para
la captura de requisitos (Pan, Zhu & Johnson, 2001 y Liu & Yu, 200). Los casos de uso
permiten mostrar el contorno (actores) y el alcance 8 (requisitos funcionales expresados
como casos de uso) 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 (personas, otros sistemas, etc.) que
interactúan con el sistema como si de una caja negra se tratase. Un actor puede participar
en varios casos de uso y un caso de uso puede interactuar con varios actores.
La ventaja esencial de los casos de uso es que resultan muy fáciles de entender para
el usuario o cliente, sin embargo carecen de la precisión necesaria (Vilain, Schwabe &
Sieckenius, 2002 y Insfrán, Pastor & Wieringa, 2002) si no se acompañan con una
información textual o detallada con otra técnica como pueden ser los diagramas de
actividades (UML, 2001).
• Cuestionarios y Checklists: Esta técnica requiere que el analista conozca el ámbito
del problema en el que está trabajando. Consiste en redactar un documento con preguntas
cuyas respuestas sean cortas y concretas, o incluso cerradas por unas cuantas opciones

13. en el propio cuestionario (Checklist). Este cuestionario será cumplimentado por el grupo de
personas entrevistadas o simplemente para recoger información en forma independiente
de una entrevista.
• Comparación de terminología: Uno de los problemas que surge durante la licitación
de requisitos es que usuarios y expertos no llegan a entenderse debido a problemas de
terminología. Esta técnica 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.
Para ello es necesario identificar el uso de términos diferentes para los mismos conceptos
(correspondencia), misma terminología para diferentes conceptos (conflictos) o cuando no
hay concordancia exacta ni en el vocabulario ni en los conceptos (contraste) (Pan, Zhu &
Johnson, 2001).
Existen más técnicas para la captura de requisitos (análisis de otros sistemas, estudio
de la documentación, etc.), incluso también es común encontrar alternativas que combinen
varias de estas técnicas (Pan, Zhu & Johnson, 2001). Sin embargo, las presentadas
ofrecen un conjunto representativo de las más utilizadas y resultan suficientes para el
objetivo de este trabajo.
Definición de requisitos
También para la actividad de definición de requisitos en el proceso de ingeniería de
requisitos hay un gran número de técnicas propuestas. Describimos brevemente las más
relevantes para este trabajo.
• Lenguaje natural: Resulta una técnica muy ambigua para la definición de los
requisitos. Consiste en definir los requisitos en lenguaje natural sin usar reglas para ello. A
pesar de que son muchos los trabajos que critican su uso, es cierto que a nivel práctico se
sigue utilizando.
• 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 (Koch, 2001). Por esta razón 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.

14. En esta línea se encuentra también el uso de ontologías, en las que no sólo aparecen
los términos, sino también las relaciones entre ellos.
• Plantillas o patrones: Esta técnica, recomendada por varios autores (Durán,
Bernáldez, Ruíz & Toro, 1999 y Escalona, Torres & Mejias, 2002), 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 cumplimentando 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: La técnica de los escenarios consiste en describir las características del
sistema a desarrollar mediante una secuencia de pasos (Liu & Yu, 2001). La
representación del escenario puede variar dependiendo del autor. Esta representación
puede ser casi textual o ir encaminada hacia una representación gráfica en forma de
diagramas de flujo (Weidenhaupt, Pohl, Jarke & Haumer, 1999). El análisis de los
escenarios, hechos de una forma u otra, pueden ofrecer información importante sobre las
necesidades funcionales de sistema (Lowe & Hall, 1999).
• 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 (Kruchten, 1998). Sin embargo, son varios los autores que defienden que
pueden resultar ambiguos a la hora de definir los requisitos (Díez, 2001 y Vilain, Schwabe
& Sieckenius, 2002 y Insfrán, Pastor & Wieringa, 2002), por lo que hay propuestas que los
acompañan de descripciones basadas en plantillas o de diccionarios de datos que eliminen
su ambigüedad.
• Lenguajes Formales: es la utilización de lenguajes formales 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 años (Peña, 1998). Sin embargo, resultan muy complejas en su utilización y para ser
entendidas por el cliente. El mayor inconveniente es que no favorecen la comunicación
entre cliente y analista. Por el contrario, es la representación menos ambigua de los
requisitos y la que más se presta a técnicas de verificación automatizadas.
Validación de Requisitos

15. Los requisitos una vez definidos necesitan ser validados. La validación de requisitos
tiene como misión demostrar que la definición de los requisitos define realmente el sistema
que el usuario necesita o el cliente desea (Lowe & Hall, 1999). Es necesario asegurar que
el análisis realizado y los resultados obtenidos de la etapa de definición de 10 requisitos
son correctos. Pocas son las propuestas existentes que ofrecen técnicas para la
realización de la validación y muchas de ellas consisten en revisar los modelos obtenidos
en la definición de requisitos con el usuario para detectar errores o inconsistencias.
Aun así, existen algunas técnicas que pueden aplicarse para ello:
• Reviews o Walk-throughs: Está técnica consiste en la lectura y corrección de la
completa documentación o modelado de la definición de requisitos. Con ello solamente se
puede validar la correcta interpretación de la información transmitida. Más difícil es verificar
consistencia de la documentación o información faltante.
• Auditorías: La revisión de la documentación con esta técnica consiste en un chequeo
de los resultados contra una checklist predefinida o definida a comienzos del proceso, es
decir sólo una muestra es revisada.
• Matrices de trazabilidad: Esta técnica consiste en marcar los objetivos del sistema y
chequearlos contra los requisitos del mismo (Durán, Bernáldez, Ruíz & Toro, 1999). Es
necesario ir viendo qué objetivos cubre cada requisito, de esta forma se podrán detectar
inconsistencias u objetivos no cubiertos.
• Prototipos: Algunas propuestas se basan en obtener de la definición de requisitos
prototipos que, sin tener la totalidad de la funcionalidad del sistema, permitan al usuario
hacerse una idea de la estructura de la interfaz del sistema con el usuario (Olsina, 1999).
Esta técnica tiene el problema de que el usuario debe entender que lo que está viendo es
un prototipo y no el sistema final.” (Pág. 5).
Fases de la Ingeniería de requerimientos
 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.

16.  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. (wikipedia, 2017)
Requerimientos de software de la Ingeniería de Requerimientos
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. (Marvin Romero, 2010, Pág. 5).
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. (Marvin Romero, 2010, Pág.
24).
Actividades de la Ingeniería de Requerimientos
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

17. 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.
-“1. Extracción: 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. Ejemplo, Observar las necesidades del nuevo
sistema o mejora de uno existente. Para extraer las funciones que no han de cambiar y las
nuevas que surgirán en el nuevo sistema, identificar las necesidades del Sistema para el
control y seguimiento de asistencia del personal de INVICA con la colaboración del cliente
para entender de forma clara y precisa lo que se quiere del sistema, que hay que resolver,
restricciones del sistema y servicio que prestará el sistema.
2. 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. Estudiar sobre la base de extracción los requerimientos del
cliente los problemas existentes, como solucionarlos, entre otros puntos de interés.
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.
3. Especificación: En esta fase 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), que es un estándar para el modelado orientado a

18. 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.
4. Validación: La validación es 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.” (Hendrina García, Alfredo Marcano, María Puentes,
2010).
Dificultades para definir los Requerimientos
 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. (phigux, 2012)
Técnicas y herramientas utilizadas en la Ingeniería de Requerimientos
 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

19. 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.
 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. -Modelo de Comportamiento: Utilizado en la parte de

20. 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. “(Francis coronel,
2013)”

21. Conclusión
Después de finalizar el presente trabajo de investigación puedo concluir que la
Ingeniería de Requisitos es nos proporciona el forma apropiada para entender lo que el
cliente solicita, analizar las necesidades, evaluar la posibilidad, negociar una solución
razonable, especificar la solución sin errores, certificar la definición y gestionar los
requisitos. Nuestro objetivo como ingeniero de requisitos es conseguir áreas en común
y áreas de conflictos o inconsistencias. Las funciones principales de la ingeniería de
requisitos son: Inicio, obtención, elaboración, negociación, especificación, validación y
gestión.
Tenemos que los requerimientos son los que nos indican que es lo que el sistema
debe hacer y sus propiedades esenciales y deseables. El objetivo principal de la
captura de los requerimientos es el entendimiento de lo que los clientes y los usuarios
esperan que haga el sistema. Los requerimientos nos da el qué del sistema, mientras
que el diseño da el cómo del sistema. Debemos tener en cuenta las características de
un Requerimiento que son: Completo, Correcto, Realizable, Necesario, Priorizable.
La ingeniería de Requerimientos es disciplina que nos ayuda a desarrollar una
especificación completa, consistente y no ambigua, la cual nos servirá como base para
acuerdos comunes entre todas las partes involucradas y en donde se describen las
funciones que realizará el sistema.
Debemos tomar en cuenta las técnicas que se aplican en la Ingeniería de
Requisitos que son: 1) Captura de Requisitos (Entrevistas, JAD (Joint Application
Development/Desarrollo conjunto de aplicaciones), Brainstorming (Tormenta de ideas),
Concept Mapping, Sketches y Storyboards, Casos de Uso, Cuestionarios y Checklists,
Comparación de terminología); 2) Definición de requisitos (Lenguaje natural, Glosario y
ontologías, Plantillas o patrones, Escenarios, Casos de uso, Lenguajes Formales); 3)
Validación de Requisitos (Reviews o Walk-throughs, Auditorías, Matrices de
trazabilidad, Prototipos). También contamos con unas faces en la Ingeniería de
requerimientos que son: Obtención requisitos, Análisis de requisitos, Documentar
requisitos, Verificar los requisitos, Validar los requisitos.

22. Cuando se habla de los requerimientos de software de la Ingeniería de
requerimientos debemos saber que estamos hablando de: Requerimientos del sistema
y el documento de requerimientos del software. Debemos saber que existen
actividades de la Ingeniería de Requerimientos las cuales son: La Extracción, Análisis,
Especificación y Validación. También podemos encontrar dificultades para definir los
Requerimientos y técnicas y herramientas utilizadas en la Ingeniería de
Requerimientos.

23. Referencias Bibliográficas
 Ennovi221 (2011). La ingenieria de Requisitos. Lugar de publicación:
WordPress. Recuperado de https://ennovi221.wordpress.com/2011/06/10/ensayo-la-
ingenieria-de-requisitos/
 Editorial (2014). Definición de Requerimientos y de Análisis de Requerimientos.
Lugar de publicación: conocimientosweb. Recuperado de
http://www.conocimientosweb.net/dcmt/ficha25180.html
 R. González Brenda M. (2012). Ensayo “Características de un Buen
Requerimiento”. Lugar de publicación: scribd. Recuperado de
https://es.scribd.com/doc/96826075/Caracteristicas-de-un-Buen-Requerimiento
 Naylu Rincón (2014). Ingeniería de Requerimientos. Lugar de publicación:
slideshare. Recuperado de https://es.slideshare.net/NayluLorena1990/ingeniera-
sistemas-2-naylurincon
 Isidro Gonzalez (2017). Ingenieria de requisitos y requerimientos. Lugar de
publicación: slideshare. Recuperado de
https://es.slideshare.net/igonzalezprs/ingenieria-de-requisitos-y-requerimientos-
71311763
 (2017).Ingeniería de requisitos. Lugar de publicación: wikipedia. Recuperado de
https://es.wikipedia.org/wiki/Ingenier%C3%ADa_de_requisitos#Fases_de_implementaci
.C3.B3n
 Marvin Romero (2010). Ingenieria de requerimientos. Lugar de publicación:
wikipedia. Recuperado de https://es.slideshare.net/marfonline/ingenieria-de-
requerimientos
 Hendrina García, Alfredo Marcano, María Puentes (2010): Actividades de la
Ingeniería de Requerimientos. Lugar de publicación: blogger. Recuperado de
http://fundamentosdeingenieriahg.blogspot.com/p/actividades-de-la-ingenieria-de.html
 phigux (2012): Memorias dentro del Desarrollo de Software. Lugar de
publicación: blogger. Recuperado de http://phigux.blogspot.com/2012/03/dificultades-
para-definir-los.html
 Francis coronel (2013): Ingenieria De Requisitos. Lugar de publicación: blogger.
Recuperado de http://tecnologicofch.blogspot.com/2013/03/22-tecnicas-de-la-
ingenieria-de.html