MAS TE R E N I NGE NI E RÍ A DE S O FTWA RE

UNIVERSIDAD POLITÉCNICA DE CATALUNYA

PROYECTO FINAL DE MÁSTER – MRF FRAMEWORK

Guía para la Elicitación

de Requerimientos

Version 1.0 ● 30 SEP 2008

Máster en Ingeniería de Software GUÍA PARA LA ELICITACIÓN DE REQUERIMIENTOS
Proyecto Final de Máster – MRF Framework Versión 1.0 | 30-SEP -2008

Tabla de Contenidos
1. Introducción..................................................................................................... 1

1.1 Qué son los Requerimientos y por qué son tan importantes................1
1.2 Tipología de Requerimientos................................................................1

2. Elicitación de Requerimientos.........................................................................2

2.1 Técnicas de elicitación..........................................................................3

3. Características de un Requerimiento..............................................................3

4. Personal involucrado en la elicitación.............................................................4

4.1 Identificar GPIs......................................................................................5

5. Dificultades para elicitar los Requerimientos...................................................5

5.1 Qué no es un requerimiento..................................................................6

5.2 Soluciones Aplicadas............................................................................6

6. Capturar el vocabulario común: Glosario de Términos...................................6

7. Niveles de Requerimientos.............................................................................7

8. Evaluación y Negociación de los Requerimientos con el Cliente....................7

9. Validación de los Requerimientos...................................................................8

10. Evolución de los Requerimientos....................................................................9

11. Qué artefactos se utilizan en la Gestión de Requerimientos.........................10

REQM-Guia-10ER-1.0 Página i
Máster en Ingeniería de Software GUÍA PARA LA ELICITACIÓN DE REQUERIMIENTOS
Proyecto Final de Máster – MRF Framework Versión 1.0 | 30-SEP -2008

1. Introducción
1.1 Qué son los Requerimientos y por qué son tan importantes

Un requerimiento puede definirse como:

"Condición o capacidad que un usuario necesita para poder resolver un problema o lograr un
objetivo." [IEEE]

"Condición o capacidad que debe exhibir o poseer un sistema para satisfacer un contrato,
estándar, especificación u otra documentación formalmente impuesta". [IEEE]

"Una condición o capacidad que debe ser conformada por el sistema". [RUP]

"Algo que el sistema debe hacer o una cualidad que el sistema debe poseer". [Robertson]

Frederick P. Brooks [Brooks, 1987], dice "La parte más difícil de construir un sistema es
precisamente saber qué construir. Ninguna otra parte del trabajo conceptual es tan difícil como
establecer los requerimientos técnicos detallados, incluyendo todas las interfaces con la gente,
máquinas y otros sistemas. Ninguna otra parte del trabajo afecta tanto el sistema si es hecha
mal. Ninguna es tan difícil de corregir más adelante… Entonces la tarea más importante que el
ingeniero de software hace para el cliente es la extracción iterativa y el refinamiento de los
requerimientos del producto".

1.2 Tipología de Requerimientos

Conocido el dominio del problema o las necesidades de los clientes, se deben establecer las
condiciones o capacidades que deberá cumplir el sistema a desarrollar para cubrir estas
necesidades. La elicitación de los requerimientos es un proceso iterativo que implica la
interacción con el cliente para obtener un consenso sobre los detalles de los requerimientos.

En la práctica, se deberán definir tanto los requerimientos del sistema como los del proyecto
software, así como los requerimientos funcionales y no funcionales relacionados con ellos. Esta
captura de requerimientos a nivel de negocio y de producto garantiza que el proyecto alcance los
objetivos dentro de limitaciones tales como la duración, el ámbito, los recursos o la calidad. Los
tipos fundamentales de requerimientos son:

 Requerimientos del Sistema: Los requerimientos del sistema definen cómo debe
gestionarse el trabajo. Estos requerimientos incluyen el presupuesto, la gestión de la
comunicación, la gestión de los recursos, el aseguramiento de la calidad, la gestión de los
riesgos y la gestión del alcance. De este modo, los requerimientos del sistema se centran en
el quién, cuándo, dónde y cómo se harán las cosas que se han documentado en le Plan del
Proyecto.

 Requerimientos del Software: Los requerimientos del software incluyen las características
y capacidades en alto nivel del producto que el equipo de negocio se ha comprometido a

REQM-Guia-10ER-1.0 Página 1
Máster en Ingeniería de Software GUÍA PARA LA ELICITACIÓN DE REQUERIMIENTOS
Proyecto Final de Máster – MRF Framework Versión 1.0 | 30-SEP -2008

entregar al cliente. Estos requerimientos no tienen que especificar cómo deberán diseñarse
estas capacidades.

- Requerimientos Funcionales  Especifican lo que debe hacer el sistema. Definen

cualquier requerimiento que perfile el modo específico como debe ejecutarse una
funcionalidad del producto o de un componente de dicho producto. Podrían verse
como una especificación, desde el punto de vista de “caja negra”, cómo interactúa la
solución con el mundo exterior.

- Requerimientos No Funcionales  Gestionan ítems tales como la solución

técnica, la gestión del número de personas que necesita utilizar el producto final, la
localización que deberá tener el sistema, el tipo de transacciones a procesar o los
tipos de integración tecnológica. De esta forma, puede verse como una
especificación, desde el punto de vista de “caja negra”, de los atributos de calidad de
la solución.

2. Elicitación de Requerimientos
La elicitación de requerimientos es el proceso de descubrir los requerimientos para un sistema a
través de la comunicación con los clientes, usuarios del sistema y otras personas que tengan
algún tipo de interés y conocimiento sobre el producto a desarrollar [Madigan].

El principal resultado del proceso de elicitación de requerimientos es la serie de requerimientos

que deberán ser utilizados por el equipo de desarrollo de software para crear un producto
correcto y de manera apropiada. Además de este resultado principal, el proceso ofrece una serie
de salidas intangibles.

Cuando existe un buen proceso de elicitación de requerimientos, se ayuda a los usuarios a

entender qué es lo que quieren, qué es lo que necesitan, cuáles son las restricciones y
alternativas, ventajas y desventajas de cada una.

Desde el punto de vista de los ingenieros y desarrolladores, la existencia de un buen proceso de

elicitación de requerimientos ayuda a los mismos a resolver el problema correcto, es decir, lo que
realmente desea y necesita el cliente, a resolver un problema factible, a ganar la confianza del
cliente y su cooperación y a ganar conocimiento sobre el dominio del problema [Tuffley:2005].

Por ello, para una buena elicitación de requerimientos, deberán tenerse en consideración las
siguientes perspectivas:

- Perspectiva de Negocio: Los stakeholders relacionados con el negocio y con marketing

deben identificar las metas y los objetivos en alto nivel de la organización, así como
responder a preguntas tales como por qué se está tratando de solucionar el problema, el
mercado al que va destinado el producto, qué necesidades del negocio se tendrán que
satisfacer, y cuáles serán las métricas para identificar si el proyecto ha sido exitoso.

REQM-Guia-10ER-1.0 Página 2
Máster en Ingeniería de Software GUÍA PARA LA ELICITACIÓN DE REQUERIMIENTOS
Proyecto Final de Máster – MRF Framework Versión 1.0 | 30-SEP -2008

- Perspectiva del Cliente o del Usuario: Los requerimientos más significativos son los del
cliente/usuario. El cliente debe responder a preguntas sobre qué problemas requieren ser
solucionados, y cómo interaccionarán ellos con el producto.

- Perspectiva Técnica: Los ingenieros y desarrolladores proporcionan la perspectiva técnica

necesaria para responder preguntas sobre cómo alcanzar los objetivos del proyecto.

2.1 Técnicas de elicitación

No existe un método perfecto para identificar y elicitar los requerimientos. Las técnicas más
apropiadas para ello son distintas en función del proyecto. No obstante, algunas de las
metodologías más utilizadas para ello son:

 Brainstrorming: Realizar sesiones de brainstorming para confirmar suposiciones en alto nivel

sobre las especificaciones de las necesidades del cliente.

 Entrevistas y Cuestionarios: Se utilizan para recoger información. Sin embargo, es necesario

tener también en cuenta la predisposición del entrevistado, su grado de experiencia o de
habilidad, ya que estos elementos tienden a perjudicar la información obtenida durante el
proceso de entrevistar.

 Historias de Usuario: Consisten en una aproximación simple a la elicitación de

requerimientos que desplaza la importancia desde la formalización de los requerimientos
escritos hacia la conversación. Las historias de usuario deberán ser escritas por el cliente,
enfatizando aquellas funcionalidades que el sistema deberá realizar. Normalmente, estas
historias suelen ser un conjunto reducido de frases largas.

 Workshops: Proporcionan una oportunidad para compartir, refinar y combinar las

perspectivas individuales sobre los requerimientos del negocio.

Existen diferentes elementos a elicitar durante la fase de requerimientos [Nuseibeh]: límites del
sistema, stakeholders, metas, tareas, factibilidad, riesgos, etc. La literatura sugiere que la
elicitación de requerimientos se realiza de distintas maneras, siguiendo una o más de numerosas
metodologías disponibles; sin embargo la práctica de implementación de este proceso presenta 
más variantes debido a la gran dificultad de formalizar indicadores directos o indirectos
(métricas) para la evaluación y monitoreo del proceso.

3. Características de un Requerimiento
El conjunto de requerimientos en estado de madurez, deben presentar una serie de
características tanto individualmente como en grupo. A continuación se presentan las más
importantes:

 Necesario: Un requerimiento es 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.

REQM-Guia-10ER-1.0 Página 3
Máster en Ingeniería de Software GUÍA PARA LA ELICITACIÓN DE REQUERIMIENTOS
Proyecto Final de Máster – MRF Framework Versión 1.0 | 30-SEP -2008

 Conciso: Un requerimiento es conciso si es fácil de leer y entender. Su redacción debe ser

simple y clara para aquellos que vayan a consultarlo en un futuro.

 Completo: Un requerimiento está completo si no necesita ampliar detalles en su redacción,

es decir, si se proporciona la información suficiente para su comprensión.

 Consistente: Un requerimiento es consistente si no es contradictorio con otro requerimiento.

 No ambiguo: Un requerimiento no es ambiguo cuando tiene una sola interpretación. El

lenguaje usado en su definición, no debe causar confusiones al lector.

 Alcanzable: Un requerimiento debe ser un objetivo realista, posible de ser alcanzado con el
dinero, el tiempo y los recursos disponibles.

 Trazable: Se puede determinar el origen de cada requerimiento.

 Verificable: Un requerimiento es verificable cuando puede ser cuantificado de manera que

permita hacer uso de los siguientes métodos de verificación: inspección, análisis,
demostración o pruebas.

 Medible: Un requerimiento debe poder medirse objetivamente mediante el conjunto de

métricas o indicadores definidos. Estas formas de medición permitirán conocer y validar de
forma general y automática el estado del progreso del desarrollo del proyecto.

 Ordenado por importancia y estabilidad: Un requerimiento puede ser ordenado conforme

a la importancia que tenga para el cliente y su estabilidad en sí.

4. Personal involucrado en la elicitación

Los roles más importantes son:

 Usuario final: Son las personas que usarán el sistema desarrollado. Ellos están
relacionados con la usabilidad, la disponibilidad y la fiabilidad del sistema; están
familiarizados con los procesos específicos que debe realizar el software, dentro de los
parámetros de su ambiente laboral. Serán quienes utilicen las interfaces y los manuales de
usuario.

 Usuario Líder: Son los individuos que comprenden el ambiente del sistema o el dominio del
problema en donde será empleado el software desarrollado. Ellos proporcionan al equipo
técnico los detalles y requerimientos de las interfaces del sistema.

 Gerente del proyecto: Es la persona con las habilidades y el conocimiento apropiados para
entender y gestionar correctamente las necesidades del cliente.

 Analistas y programadores: Son los responsables del desarrollo del producto en sí; ellos
interactúan directamente con el cliente.

REQM-Guia-10ER-1.0 Página 4
Máster en Ingeniería de Software GUÍA PARA LA ELICITACIÓN DE REQUERIMIENTOS
Proyecto Final de Máster – MRF Framework Versión 1.0 | 30-SEP -2008

 Personal de pruebas: Se encargan de elaborar y ejecutar el plan de pruebas para asegurar

que las condiciones presentadas por el sistema son las adecuadas. Son quienes van a
validar si los requerimientos satisfacen las necesidades del cliente.

 Otras personas que pueden estar involucradas, dependiendo de la magnitud del proyecto,
pueden ser: administradores de proyecto, documentadores, diseñadores de base de datos,
entre otros.

4.1 Identificar GPIs

El GPI o Grupo Primario de Interés está formado por el conjunto de individuos que se encuentran
afectados de forma material por el resultado del sistema o proyecto que se está desarrollando.

Los representantes del GPI deben estar directamente involucrados en la dirección,

modelamiento y alcance del proyecto. El documento de visión del proyecto o el plan del proyecto
deberán incluir un apartado donde se describan quienes son los GPI del proyecto y cuál es su
función en el mismo.

5. Dificultades para elicitar los Requerimientos

Algunos de los factores que pueden dificultar la elicitación de los requerimientos son:

- Los requerimientos no son obvios y proceden de fuentes diversas.

- Son difíciles de expresar en palabras (el lenguaje es ambiguo).

- Los clientes no tiene claro lo que desean.

- 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 abarca áreas funcionales específicas.

- Un requerimiento puede cambiar a lo largo del ciclo de desarrollo, ya que los clientes insisten
en nuevos requisitos después de que el coste y la estimación se hayan fijado.

- Son difíciles de cuantificar, ya que cada conjunto de requerimientos es particular para cada
proyecto.

- Los clientes no se involucran en la elaboración de requerimientos.

REQM-Guia-10ER-1.0 Página 5
Máster en Ingeniería de Software GUÍA PARA LA ELICITACIÓN DE REQUERIMIENTOS
Proyecto Final de Máster – MRF Framework Versión 1.0 | 30-SEP -2008

- No todos los participantes de la elicitación están políticamente igual de motivados.

Analistas:

- Creen entender los problemas mejor que los usuarios.

- Para una correcta redacción de la Especificación de los Requerimientos del Software, deben
evitar el uso de terminología ambigua.

Desarrolladores:

- El personal técnico y los usuarios finales pueden tener diversos vocabularios y pueden llegar
a creer incorrectamente que están de acuerdo, no dándose cuenta del desacuerdo hasta que
se provee el producto final.

- El análisis de requerimientos se puede realizar a menudo por los ingenieros o

programadores, en vez de por el personal con las habilidades de relación con la gente y el
conocimiento apropiados para entender correctamente las necesidades del cliente.

5.1 Qué no es un requerimiento

- Cómo realizar los requerimientos (diseño).

- Cómo saber que los requerimientos han sido satisfechos correctamente (validación y
verificación).

- Cuándo se han satisfecho los requerimientos (trazabilidad).

5.2 Soluciones Aplicadas

Una de las soluciones aplicada a los problemas de comunicación entre los grupos de usuarios
previamente especificados ha emplear a especialistas en análisis del negocio o del sistema.

Asimismo, otras técnicas introducidas para salvar las diferencias entre los clientes y las
organizaciones de desarrollo de software son el uso de un lenguaje de modelado unificado
(UML) para el diseño de los casos de uso o el uso de prototipos que imitan fielmente el producto
final.

También se adquieren herramientas que permiten medir de forma objetiva la calidad de una
especificación de requerimientos. IRqA Quality Analyser o DOORS Quality Analyser son
ejemplos de este tipo de herramientas.

6. Capturar el vocabulario común: Glosario de

Términos
Listar y definir los términos utilizados en el proyecto con el fin de reducir los problemas de
comunicación y requisitos ambiguos, evitando las malas interpretaciones o que un término se

REQM-Guia-10ER-1.0 Página 6
Máster en Ingeniería de Software GUÍA PARA LA ELICITACIÓN DE REQUERIMIENTOS
Proyecto Final de Máster – MRF Framework Versión 1.0 | 30-SEP -2008

utilice de forma distinta por diferentes personas involucradas en las posteriores fases del
proyecto.

Es necesario empezar con la captura del vocabulario común lo antes posible y continuarla a lo
largo de toda la vida del proyecto.

El Framework MRF proporciona una plantilla para realizar el Glosario de Términos (REQM-
Plantilla-10GT-1.0).

7. Niveles de Requerimientos

8. Evaluación y Negociación de los Requerimientos

con el Cliente
Los principales pasos de esta actividad son:

 Descubrir problemas potenciales:

- Definir las condiciones de verificación y validación de cada uno de los requerimientos,

observando que cubran las necesidades del comportamiento de la aplicación.

REQM-Guia-10ER-1.0 Página 7
Máster en Ingeniería de Software GUÍA PARA LA ELICITACIÓN DE REQUERIMIENTOS
Proyecto Final de Máster – MRF Framework Versión 1.0 | 30-SEP -2008

- Especificar los atributos que deberá tener dicho comportamiento.

- Especificar sus discrepancias, suposiciones y restricciones.

 Clasificar los requerimientos. En base a la prioridad, cada requerimiento puede clasificarse

en:

- Obligatorio  Si afecta a una operación crítica del negocio.

- Deseable  Si existe algún proceso que se quiera incluir para mejorar los procesos
actuales.

- No necesario  Si se trata de un requerimiento informativo que puede esperar a fases

posteriores.

 Evaluar factibilidades y riesgos:

- Factibilidades técnicas  ¿pueden implementarse los requerimientos con la tecnología

actual?

- Factibilidades operacionales ¿puede ser utilizado el sistema sin alterar el organigrama

actual?

- Factibilidades económicas  ¿ha sido aprobado el presupuesto por los clientes?

9. Validación de los Requerimientos

La validación es la actividad que permite demostrar que los requerimientos definidos en el
sistema son los que realmente quiere el cliente. Además, revisa que no se haya omitido ninguno,
que no sean ambiguos, inconsistentes o redundantes.

La validación garantiza que todos los requerimientos presentes en los documentos de

Especificación sigan los estándares de calidad.

Durante la actividad de validación pueden hacerse preguntas en base a cada una de las
características que se desean revisar. A continuación se presentan varios ejemplos:

 COMPLETA: ¿Están incluidas todas las funciones requeridas por el cliente?

 CONSISTENTE: ¿Existen conflictos en los requerimientos?

 NO AMBIGUA: ¿Tiene alguno de los requerimientos más de una interpretación?

 ENTENDIBLE: ¿Está cada requerimiento claramente representado?

 FACTIBLE: ¿Pueden los requerimientos ser implementados con la tecnología y el

presupuesto disponible?

REQM-Guia-10ER-1.0 Página 8
Máster en Ingeniería de Software GUÍA PARA LA ELICITACIÓN DE REQUERIMIENTOS
Proyecto Final de Máster – MRF Framework Versión 1.0 | 30-SEP -2008

 CLARA: ¿Está la Especificación de los Requerimientos del Software escrita en un lenguaje

apropiado?

 MODIFICABLE: ¿Existe facilidad para hacer cambios en los requerimientos?

 RASTREABLE: ¿Está claramente definido el origen de cada requisito?

 VERIFICABLE: ¿Pueden los requerimientos ser sometidos a medidas cuantitativas?

La validación de requisitos es importante pues de ella depende que no existan elevados costos
de modificaciones y/o mantenimiento para el software desarrollado.

10. Evolución de los Requerimientos

Los requerimientos son una manera de comprender mejor el desarrollo de las necesidades de
los usuarios y cómo los objetivos de la organización pueden cambiar, por lo tanto, es esencial
planear posibles cambios a los requerimientos cuando el sistema sea desarrollado y utilizado.
Así, la actividad de evolución es un proceso externo que ocurre a lo largo del ciclo de vida del
proyecto.

Los requerimientos cambian por diferentes razones. Las más frecuentes son:

- Porque al analizar el problema, no se hacen las preguntas correctas a las personas

correctas.

- Porque cambió el problema que se estaba resolviendo.

- Porque los usuarios cambiaron su forma de pensar o sus percepciones.

- Porque cambió el ambiente de negocios.

- Porque cambió el mercado en el cual se desenvuelve el negocio.

Los cambios en los requisitos involucran modificar el tiempo en el que se va a implementar una
característica en particular, modificación que a la vez puede tener impacto en otros
requerimientos. Por esto, la administración de cambios involucra actividades como establecer
políticas, guardar históricos de cada requerimiento, identificar dependencias entre ellos y
mantener un control de versiones.

Es muy importante remarcar que antes de realizar cambios en los requerimientos, se deberán
analizar todas sus implicaciones sobre el resto.

11. Qué artefactos se utilizan en la Gestión de

Requerimientos

REQM-Guia-10ER-1.0 Página 9