Un Acercamiento a la Ingenierı́a de

Requerimientos
José Manuel Bahamonde Richard Rossel
jbahamon@inf.utfsm.cl rrossel@inf.utfsm.cl
Universidad Técnica Federico Santa Marı́a
03 de Noviembre de 2003

Resumen
La Ingenierı́a de Requerimientos es una disciplina que cumple un
papel primordial en el proceso de desarrollo de software, ya que se es-
pecializa en la definición del comportamiento del sistema, es decir, de
lo que se desea desarrollar o producir. En este documento se presenta
un acercamiento a la teorı́a y la práctica de la Ingenierı́a de Requerim-
ientos, estudiando de manera general algunas técnicas y herramientas
que permiten entender los desafı́os futuros de esta ciencia.

1. Introducción
Por años, la ingenierı́a de software ha presentado distintas metodologı́as
y herramientas para la obtención de software, cada vez de mejor calidad. Sin
embargo, los problemas del desarrollo de sistemas mal definidos no están del
todo ausentes. El caso del año 2000, demostró a la comunidad que no solo
se debe estar preparado para situaciones esperadas, sino que también para
aquellas que no lo son. La integración de tecnologı́as nos hacen cada vez más
dependientes de la calidad de los sistemas que se desarrollan, pero aún ası́,
cómo se explica que muchos de los proyectos de software presenten problemas
que no le permiten llegar a destino de la forma que se habı́a planeado.
La ingenierı́a de requerimientos es una disciplina que cumple un papel
primordial en el proceso de desarrollo de software, ya que se especializa en
la definición del comportamiento del sistema, es decir, de lo que se desea
desarrollar o producir. El objetivo principal de la ingenierı́a de requerimientos
es la definición clara, consistente y compacta de las especificaciones correctas
que definen el comportamiento del sistema con el fin de minimizar al máximo
los problemas que se presentan en el desarrollo de software y que tanto afectan
a la calidad del producto final.
Desde 1990 hasta la fecha, esta disciplina ha sido reconocida como tal.
En 1993, el primer Simposio Internacional de la IEEE sobre Ingenierı́a de
Requerimientos se llevó a cabo [1]. A la fecha, variadas son las técnicas y
herramientas que se han desarrollado, y que han permitido aplicar ésta dis-
ciplina no solo en el ámbito del desarrollo de software, sino incluso en la
definición de requerimientos de componentes para automóviles [5], por ejem-
plo.
Este documento presenta un acercamiento a lo que es la ingenierı́a de
requerimientos, algunas de las metodologı́as desarrolladas a la fecha, ası́ como
los desafı́os que se presentan para los próximos años.

2. RE y sus actividades
La tarea principal del RE consiste en la generación de informes de especi-
ficaciones que describan el comportamiento completo del sistema de forma
clara y consistente, de tal forma disminuir los conflictos dentro y fuera del
desarrollo del proyecto que se generan muy a menudo.
Pero antes de entrar más en detalle revisando las actividades y carac-
terı́sticas de la RE, debemos definir el concepto de requerimiento, para ello
citamos la definición que realizó la IEEE:

(1) Una condición o necesidad de un usuario para resolver

un problema o alcanzar un objetivo. (2) Una condición o capaci-
dad que debe estar presente en un sistema o componentes de sis-
tema para satisfacer un contrato, estándar, especificación u otro
documento formal. (3) Una representación documentada de una
condición o capacidad como en (1) o (2).

2.1. Requerimientos
Existe dos tipos de requerimientos, funcionales y no funcionales. Los re-
querimientos funcionales definen las funciones que el sistema será capaz de

2
realizar. Estos deben definir y describir los procesos y actividades que com-
ponen el sistema completo.
Los requerimientos no funcionales son aquellos que no están relaciona-
dos directamente con los procesos que definen el sistema, si no más bien
tienen que ver con caracterı́sticas adicionales, como seguridad, mantenimien-
to, robustez , portabilidad, etc. Un conjunto de requerimientos en estado de
madurez debe poseer ciertas caracterı́sticas importantes de mencionar como:

Necesario: Un requerimiento es necesario solo si su omisión provoca una

deficiencia en el sistema por lo que su reemplazo es imposible.

Conciso: Un requerimiento es conciso si es fácil de leer y entender. Su redac-

ción debe ser simple y clara sin llegar a la incompletitud.

Completo: Un requerimiento es completo si existe toda la información rela-

cionada a él.

Consistente: Un requerimiento es consistente si no se contradice con otro

requerimiento.

No Ambiguo: Un requerimiento no es ambiguo cuando su especificación

tiene solo una interpretación, evitando de esa manera confusiones a los
lectores.

Verificable: Un requerimiento es verificable cuando puede ser cuantificado

de manera que permita hacer uso de métodos de verificación como
inspección, análisis, demostración o pruebas.

Durante la etapa de identificación de requerimientos a menudo surgen

problemas y dificultades, a continuación una lista de estas complejidades.

Los requerimientos no son obvios y vienen de muchas fuentes.

Son difı́ciles de expresar en palabras

Existen una variada gama de requerimientos y diferentes niveles de

detalles.

Gran número de requerimientos puede volverse inmanejable.

Definir las relaciones entre requerimientos y otras áreas de procesos.

3
 Los requerimientos pueden variar a lo largo del desarrollo del proyecto.

Dificultad en la cuantificación de los requerimientos.

2.2. Definición de RE
Pareciera ser que con un buen conjunto de requerimientos bien definidos,
nos ayudarı́a a entender mejor el problema que se quiere resolver, obteniendo
una visión más completa del panorama. Entonces si se definen bien estos re-
querimientos, ¿Por qué continuamente el desarrollo de proyectos duran más
de lo estimado?, ¿Cuál es el motivo de que los proyectos terminen aumentan-
do los costos de desarrollo?, o ¿Por qué los clientes nunca están conformes
con las entregas desarrolladas?. El motivo está centrado en la definición de
requerimientos. En la sección 2.1 vimos las dificultades en definir requerim-
ientos, y claro está que son esos los errores cometidos para que cada vez
más clientes estén disconformes con la calidad de los softwares obtenidos.
Desde hace ya un par de décadas atrás que vieron la importancia de esta
actividad del desarrollo de software, y definieron una disciplina especializada
en recopilar, analizar y verificar las necesidades del cliente, a esta actividad
la llamaron Ingenierı́a de Requerimientos (RE, Requirements Enginnering).
Una definición algo antigua, pero todavı́a vigente es la de Boehm en 1979.

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

Desde que los ingenieros empezaron a incorporar la RE en sus proyec-

tos, vieron las utilidades y beneficios que esta actividad les entregaba. A
continuación listaremos algunos de estos beneficios:

Permitir las necesidades del proyecto en forma estructurada: Cada

actividad de RE consiste de una serie de pasos organizados y bien
definidos.

Mejora la capacidad de predecir resultados: RE proporciona un pun-

to de partida para los controles subsecuentes y actividades de manten-
imiento, tales como estimación de costos, tiempo y recursos necesarios.

4
Disminuye costos y retrasos en proyectos: RE proporciona un buen es-
tudio del problema al principio del proyecto, disminuyendo de esta man-
era los errores encontrados durante el desarrollo, y ahorro de costos de
reparación de estos errores.

Mejoramiento de la calidad del software: Al cumplir con los requerim-

ientos que define la RE, ,mejoramos aspectos de la calidad como fun-
cionalidad, facilidad de uso, confiabilidad, desempeño, etc.

Mejoramiento de la comunicación entre equipos: RE proporciona una

especificación de requerimientos que representa una forma de consenso
entre clientes y desarrolladores.

Evita rechazos de usuarios finales: Ya que RE incorpora a sus equipos

de trabajos a los usuarios del sistema a desarrollar, obligándolos a con-
siderar sus requerimientos cuidadosamente y revisarlos dentro del mar-
co del problema.

Hemos mencionado que la RE incorpora a sus actividades varios equipos

de trabajos, contando con muchas personas involucradas en el desarrollo de
requerimientos del sistema. El papel desempeñado por cada persona depende
de su conocimiento e intereses que posea, por esto es esencial elegir a las
personas correctas en las actividades de la RE. Los roles más importantes de
la RE se pueden definir como:

Usuario final: Son las personas que usarán el sistema desarrollado.

Usuario lı́der: Son las personas que comprenden totalmente el dominio del
problema en donde será empleado el software desarrollado. Ellos pro-
porcionan al equipo técnico los detalles y requerimientos de las inter-
faces del sistema.

Personal de mantenimiento: Para proyectos que requieran un manten-

imiento eventual. Estas son las personas responsables de la admin-
istración de cambios, implementación y resolución de anomalı́as. Su
trabajo consiste en revisar y mejorar los procesos del producto ya fi-
nalizado.

Analistas y programadores: Son las personas responsables del desarrollo

del producto en sı́, estos interactúan directamente con el cliente.

5
Personal de pruebas: Estas personas se encargan de elaborar y ejecutar
el plan de pruebas para asegurar que las condiciones presentadas por
el sistema sean las adecuadas. Ellos son quienes validarán si los requer-
imientos satisfacen completamente las necesidades del cliente.

Otros equipos de trabajos no mencionados en la lista pero que a veces apare-

cen en las actividades de RE son administradores de proyecto, documenta-
dores, diseñadores de bases de datos, entre otros.

3. Técnicas de RE
A la fecha se han identificado variadas técnicas que han demostrado ser
efectivas al momento de definir los requerimientos del sistema. La utilización
de cada herramienta, dependerá de la naturaleza del sistema que se desea
definir. A continuación, se presentan cuatro de las técnicas más usadas en
esta disciplina.

3.1. Entrevistas y Cuestionarios

En esta técnica, el encargado de definir los requerimientos realiza una
serie de preguntas a personas o grupos, que pueden ser futuros o potenciales
usuarios del sistema que se desea definir. El objetivo es reunir la mayor
cantidad de información posible que permita al analista descubrir opiniones,
sentimientos y experiencias generales, que no necesariamente tengan relación
con el conocimiento de la potencial solución.
Las preguntas pueden ser enfocadas a distintos elementos del sistema
como por ejemplo usuario, proceso, producto, entre otros. Estas preguntas
deben ser de alto nivel y realizadas al comienzo del proceso para ası́ lograr
la recaudación de aspectos globales del problema.
El éxito del uso de esta técnica dependerá de la experiencia y sensibilidad
del entrevistador, ya que además de preparar estratégicamente el curso de la
entrevista, debe ser capaz de interpretar la significancia de las respuestas.

3.2. Brainstorm o Lluvia de Ideas

Esta técnica busca el incentivo de la creatividad de los participantes del
proyecto, creando una atmósfera de trabajo donde todos puedan aportar con

6
ideas de la solución final sin que estas sean enjuiciadas ni criticadas hasta
que ya nadie tenga una nueva idea que aportar.
La lluvia de ideas se suele dividir en tres fases que se caracterizan por
su relativa secuencialidad y los resultados que se obtienen. En la fase de
Descubrimiento de Hechos, que consta con una etapa de ambientación es-
pecialmente importante para aquellos que no tienen experiencia en el tema,
se determina y delimita el problema a tratar, para luego investigar docu-
mentación de experiencias anteriores, en caso de que exista. La segunda fase,
Producción de Ideas, es la más importante, pues es aquı́ donde se busca pro-
ducir una gran cantidad de ideas de todos los participantes, para la solución
del problema. La tercera etapa, corresponde al Descubrimiento de Soluciones,
y es aquella donde se seleccionan las ideas que parecen ser factibles, pon-
derándolas en caso de que sea necesario para generar la lista que más tarde
debe ser analizada en detalle.
Los participantes deben ser guiados por un director que se caracterice
por una gran capacidad creativa. Este debe ser un moderador del encuentro,
además de ser el encargado de definir claramente el problema a tratar. Por
último, se desea que no existan diferencias jerárquicas entre los participantes,
para que todos se sientan a gusto y sus ideas no sean inhibidas.

3.3. Prototipos.
Esta técnica comienza con la definición básica de los requerimientos gen-
erales por parte de los usuarios y clientes con el fin de identificar las car-
acterı́sticas globales del sistema. Luego, se diseña y construye una maqueta
del sistema que permita la representación de aquellos aspectos del software
que serán visibles para el usuario. Esta maqueta es la que se conoce como
prototipo y es el que debe ser evaluado por el cliente y el usuario con el fin
de refinar los requerimientos del sistema.
Se han identificado dos tipos de prototipos, los Prototipos Rápidos, que
son aquellos que facilitan la evaluación de los requerimientos en la etapa
previa al diseño general del sistema; y los Prototipos Evolutivos, a medida que
se avanza en el ciclo de vida del proyecto, los prototipos sufren modificaciones
y mejoras con el fin de llegar hasta el producto final.

7
3.4. Casos de Uso.
Un caso de uso puede ser definido como un conjunto de funcionalidades
que le permiten a alguien o algo interactuar con el sistema, es decir, son
historias o casos de utilización que ejemplifican e incluyen tácitamente los
requerimientos del cliente[4]. Al hablar de algo o alguien, se hace referencia a
que los sistemas no solo son usados por personas sino que también por otros
sistemas de software o hardware.
Esta técnica se divide en siete grandes pasos a seguir para la correcta
definición de los requerimientos. Una primera etapa es la correcta identifi-
cación de los usuarios o actores del caso de uso, que corresponden a entes
externos al sistema y que interactúan con él, es decir, el analista debe pre-
guntarse ¿para quién es este sistema?. Una segunda etapa, es la identificación
de los principales casos de uso para cada actor, sin necesidad de conocer el
detalle de las actividades que componen el caso de uso. Luego, para evitar
la omisión de requerimientos, la tercera etapa consta de la identificación de
nuevos casos de usos a partir de los definidos en la etapa anterior. Una vez
que se tienen todos los casos de uso identificados, estos deben ser documenta-
dos en una cuarta etapa, donde se deben detallar el comienzo, el fin, el flujo
normal de eventos, los flujos alternativos y las excepciones al flujo de even-
tos. En la quinta etapa, se deben definir prioridades de los requerimientos
relacionándolos con los casos de uso con el fin de determinar la funcionalidad
central, y algunos puntos crı́ticos de éstos. Probablemente, el sistema com-
pleto involucra una gran cantidad de casos de uso, por lo que en una sexta
etapa se debe definir los gráficos que se usarán y que casos incluirán, con
el fin de ordenar la información. Por último, la séptima etapa corresponde
a la utilización de herramientas automatizadas cuyos objetivos son la cap-
tura, administración y producción de una especificación de requerimientos.
Es el caso de la herramienta RequisitePro, de Rational Software1 , o DOORS
creada por Quality System and Software2 , las dos herramientas más usadas.

4. Metodologı́as
Desde sus comienzos, variados autores han expuesto sus puntos de vista
en la definición y descomposición de las etapas de la Ingenierı́a de Requerim-
1
http://www.rational.com/products/reqpro/
2
http://www.telelogic.com/products/doorsers/doors

8
ientos. A pesar de esto, la mayorı́a acepta la secuencialidad de tres etapas que
cada uno detalla de manera distinta. Las tres etapas, que son el eje central
del proceso de gestión de requerimientos, son las siguientes.

Elicitación: Es la etapa de mayor interacción con el usuario. Es el momento

en el que se recurre a la observación, lectura de documentos, entrevistas,
entre otras técnicas. Es la instancia en que equipos multidisciplinarios
trabajan conjuntamente con el cliente/usuario para obtener los requer-
imientos reales de la mejor manera.

Análisis: Esta etapa permite al analista representar el dominio de la in-

formación de la aplicación a desarrollar a través de un lenguaje más
técnico, procurando reducir ambigüedades. Esta etapa le entrega al
analista, la representación de la información y las funciones que facili-
tarán la definición del futuro diseño.

Especificación: Es sabido que la forma de especificar tiene mucho que ver

con la calidad de la solución, por lo que esta es quizás la etapa de mayor
cuidado. Las consecuencias de una mala especificación se padecen en
la calidad, oportunidad e integridad del software resultante.

En base e estas tres etapas, variadas metodologı́as han aparecido para la

administración de requerimientos. A continuación, se estudia una metodologı́a
de documentación de requerimientos centrada en el usuario, como referencia
a muchas otras propuestas por distintos autores.

4.1. Metodologı́a DoRCU para RE[3]

DoRCU, Documentación de Requerimientos Centrada en el Usuario, es
una metodologı́a para la RE caracterizada por su flexibilidad y orientación al
usuario. Esta metodologı́a considera los mejores resultados de otros enfoques
estudiados y se apoya en diversos métodos, técnicas y herramientas desarrol-
ladas por otros autores, pero sin comprometerse con los lineamientos de un
paradigma particular.
La metodologı́a DoRCU consta de cuatro etapas para las cuales se definen
distintos objetivos.

Elicitación de Requerimientos: En esta etapa se adquiere el conocimien-

to del trabajo del cliente/usuario, se busca comprender sus necesidades

9
 y se detallan las restricciones medioambientales. Como resultado, se
obtiene el conjunto de requerimientos de todas las partes involucradas.

Análisis de Requerimientos: Aquı́ se estudian los requerimientos extraı́dos

de la etapa anterior, con el fin de detectar áreas no especificadas, req-
uisitos contradictorios y peticiones vagas e irrelevantes. Los resultados
de este análisis podrı́an determinar el regreso a la etapa anterior para
eliminar falencias e inconsistencias. Aquı́ se realizan acercamientos al
lenguaje técnico.

Especificación de Requerimientos: A partir de lo elaborado en la etapa

anterior (funciones, datos, requerimientos no funcionales, objetivos, re-
stricciones de diseño/implementación, costos), e independiente de como
se realice, esta es una etapa de descripción del requerimiento. Evidente-
mente, esta etapa podrı́a determinar el regreso a la anterior en caso de
que exista alguna dificultad en la descripción de algún requerimiento.

Validación y Certificación de los Requerimientos: En esta etapa se pro-

duce la integración y validación final de lo obtenido en las etapas an-
teriores, entregando como resultado final, el Documento de Requer-
imientos. Se crean dos copias de este documento, uno destinado al
cliente/usuario con los efectos de la certificación de los requisitos, y
otra copia técnica orientada a nutrir las restantes etapas de la Inge-
nierı́a de Software.

Para cada una de estas, se definen cuatro etapas, las que no serán estudiadas
en detalle, pero se mencionarán como referencia.

1. Elicitación de Requerimientos.

Formar Equipo Multidisciplinario.

Buscar hechos.
Recolectar y clasificar requerimientos.
Evaluar y racionalizar.
Dar Prioridad.
Integrar y Validar.
Documentar la Etapa.

10
 2. Análisis de Requerimientos.

Reducir ambigüedades en los requerimientos.

Traducir a lenguaje técnico los requerimientos.
Plantear un modelo lógico.
Documentar la Etapa.

3. Especificación de Requerimientos.
Determinar el tipo de requerimiento.
Elegir la herramienta de especificación.
Especificar de acuerdo a la herramienta seleccionada.
Documentar la etapa.
4. Validación y certificación de requerimientos.
Elegir o diseñar el modelo de documento acorde al grado de detalle
requerido.
Elegir herramienta de documentación.
Documentar respetando estándares vigentes.
Verificar que el documento de requerimientos de usuario sea isomórfi-
co con el documento técnico.
Certificar el documento de requerimientos del usuario a través del
conforme del usuario.
A pesar de ser esta una metodologı́a especı́fica, entrega las pautas para en-
tender otras metodologı́as propuestas. Algunas de las ventajas de la metodologı́a
DoRCU son las siguientes.
Contribuye al entendimiento de la Ingenierı́a de Requerimientos al de-
tallar etapas bien definidas.
Ofrece libertad de acción para la selección e integración de las her-
ramientas a emplear.
Contempla aspectos metodológicos para la obtención del Documento
de Requerimientos.
Puede ser aplicada a distintos paradigmas.

11
5. Metas y Desafı́os[1]
Desde 1993 se han realizado conferencias que tienen como objetivo in-
tercambiar ideas, resultados de investigación, visiones e innovaciones en el
campo del ER, como por ejemplo IEEE International Symposium on Require-
ments Engineering y International Conference on Requirements Enginnering,
siendo la IEEE International Requierements Engineering Conference la más
importante de todas. Esta última conferencia se llevó a cabo en Septiembre
del 2002 en Essen, Alemania. Los participantes de esta conferencia identifi-
caron nuevos temas importantes tales como mejoramientos significativos del
establecimiento de técnicas y herramientas. Algunos de estos son:

Gestión Continua de Requerimientos Tradicionalmente, RE fue vista

como una fase temprana en el proceso de desarrollo. Como se propu-
so en la mitad de los ’90, a causa de los menores tiempos de salida
al mercado, cambios técnologicos y los ambientes dinámicos, se pro-
dujo un cambio en la vista tradicional. Por esto, entonces RE deberı́a
entenderse como una actividad continua que gestiona la evolución de
requerimientos a través del ciclo de vida del sistema y entre sus fron-
teras. El artı́culo de Matthias Weber y Joachim Weisobrod describe las
experiencias y desafı́os al adoptar una intensa gestión de requerimientos
en la industria del automóvil de la DaimlerChrysler[5].

Abismo entre requerimientos y software Una continuidad deberı́a exi-

stir desde el dominio del problema al dominio de la solución, como una
estructura del problema, dado que usualmente difiere de lo que se quiere
como solución. Algunas personas discuten soluciones que garantizan es-
ta continuidad basada en chequeos consistentes sistemáticos entre los
dos niveles. Otros enfatizan la definición y uso de estructuras reusables
de problemas, que pueden entonces ser asociados con arquitecturas bien
definidas.

Gestión de Procesos ER Hubo una evidencia clara que los procesos RE

son definidos y distribuidos en organizaciones con muchas sucursales.
Un artı́culo describe la importancia de la gestión de procesos de re-
querimientos en los Sistemas Médicos Philips[2], este nos muestra una
introducción a un sistema coordinado y centralizado de gestión de doc-
umentos de requerimientos y los procesos de soporte que requiere.

12
6. Conclusiones
La definición de requerimientos es uno de los principales pasos que de-
terminan del éxito de un proyecto de desarrollo y la calidad de la solución
final. En este contexto, la ingenierı́a de requerimientos es una disciplina, que
al igual que otras, requiere de tiempo de experiencia y desarrollo para des-
cubrir más y mejores metodologı́as o técnicas que demuestren la efectividad
de su aplicación. Por ahora, las técnicas o metodologı́as que se utilicen para
la definición correcta de los requerimientos, dependerá del proyecto en desar-
rollo, y los resultados para cada una de ellas serán distintos.
Es necesario realizar un estudio más exhaustivo de los avances y desafı́os
de la ingenierı́a de requerimientos para concluir su estado. Los casos prácticos
de la aplicación de esta disciplina tanto en ámbitos de la ingenierı́a de software
como en otros que no tienen relación, podrı́an demostrar la efectividad de la
administración de los requerimientos en la calidad del producto final.

Referencias
[1] Eric Dubois and Klaus Pohl. Re02, a major step toward a mature re-
quirements engineering community. IEEE Software, pages 14–15, En-
ero/Febrero 2003.

[2] Stewart A. Higgins, Maurice de Laata, Paul M.C. Gieles, and Emili-
enne M. Geurts. Managing requirement for medical it products. IEEE
Software, pages 26–33, Enero/Febrero 2003.

[3] Silvia I. Barba Brunner M. Griselda Báez. Metodologı́a dorcu para la

ingenierı́a de requerimientos. Instituto Superior Politécnico José Antonio
Echevarrı́a, 2002.

[4] T. Quatrani. Introduction to the unified modeling language. Rational

Software Coporation, 2001.

[5] Matthias Weber and Joachim Weisbrod. Requirements engineering in

automotive development: Experiences and challenges. IEEE Software,
pages 16 –24, Enero/Febrero 2003.

13