Asociación Profesional del Cuerpo Superior

de Sistemas y Tecnologías de la Información

de la Administración del Estado

Temas Específicos para la preparación de la Oposición al Cuerpo

Superior de Sistemas y Tecnologías de la Información de la
Administración del Estado.

TEMAS ESPECÍFICOS III: Ingeniería de los Sistemas de

Información

Tema 78. El Análisis de Requisitos de los Sistemas de

Información y de Comunicaciones

AUTOR: Carlos J. de Bustos Martín

Fecha 2009
 Volumen 3. INGENIERÍA DE LOS SISTEMAS

078. El Análisis de Requisitos de los Sistemas de Información y de

Comunicaciones

Autor: Carlos J. de Bustos Martín

Sumario

078.01 Introducción
078.02 El Análisis de los Sistemas de Información
078.02.01 Actividades del Análisis
078.02.02 Otras Nomenclaturas en el Análisis
078.03 El Análisis de Requisitos de los Sistemas de Información y de Comunicaciones
078.03.01 El Desarrollador, El Cliente y el Usuario
078.03.02 ¿Qué es el Análisis de Requisitos?
078.03.03 Porqué es importante el Análisis de Requisitos
078.03.04 Concepto de Requisito o Requerimiento
078.03.05 Proceso de Obtención de Requisitos
078.03.06 Fuentes de Información para el Análisis de Requisitos
078.03.07 Validación de Requerimientos
078.04 Gestión de Requisitos
078.04.01 ¿Porqué hace falta tener un procedimiento?
078.04.02 Procedimientos de Gestión de Requisitos
078.04.03 El Comité de Control de Cambios
078.05 El Análisis de Requisitos en Métrica versión 3
078.06 Herramientas para el Análisis de Requisitos
078.06.01 Aportaciones de las Herramientas de Análisis de Requisitos
078.06.02 Funcionalidades de las Herramientas
078.06.03 Ejemplos de Herramientas de Análisis de Requisitos

Bibliografía
- Arlow, J y I. Neustadt. UML and the Unified Process. Ed. Addison Wesley 2002.
- Gonzalo Cuevas, Agustín. Gestión del Proceso de Software. Ed. Centro de Estudios Ramón
Areces. 1ª Ed. ISBN 84-8004-546-9
- Metodología Métrica versión 3. Ministerio de Administraciones Públicas. 1998.
[Link]
- Pressman, Roger. S. Ingeniería del Software. Un Enfoque Práctico. Ed. McGraw Hill. 4ª Ed.
1997. ISBN 84-481-1186-9
- Pressman, Roger. Ingeniería del Software. Un Enfoque Práctico . Ed. McGraw Hill. 6ª Ed.
ISBN 970-105473-3
- Sommerville, Ian. Ingeniería del Software. Ed. Pearson-Addison-Wesley. 7ª Ed. 2005.
ISBN 84-7829-074-5
- Thayer, RH y Dorfman, M. Software Requirements Engineering. 2ª Ed, IEEE Computer Society
Press, 1997.
- Whitten et. al. Análisis de Sistemas y Métodos de Diseño. Ed. Irwin. 3ª Ed.1996.
ISBN 84-8086-252-1
078.- El Análisis de Requisitos de los Sistemas de Información y de Comunicaciones 1
 Volumen 3. INGENIERÍA DE LOS SISTEMAS

78.01. Introducción
Desde la creación de los primeros computadores, hacia principios de los años 40 del siglo XX, hasta la actualidad ha
habido grandes cambios en todo lo relacionado con los programas que se ejecutan en los ordenadores. Hemos pasado
de unos pequeños programas, desarrollados en código máquina, o como mucho en ensamblador, a grandes sistemas,
formados por millones de líneas de código, los cuales permiten funcionalidades impensables hace no mucho tiempo.
Hemos pasado de sistemas en que el usuario, desarrollador y operador era la misma persona, a sistemas en que estos
perfiles están completamente diferenciados, con unos niveles de formación muy diferentes, muchas veces no
relacionados con aspectos técnicos.
Este gran crecimiento en el tamaño de los sistemas y esta separación en los perfiles de los participantes lleva por
supuesto emparejado un creciente riesgo de cometer errores durante todo el ciclo de vida del sistema, desde la
concepción hasta las pruebas. A lo largo de este tema se estudiarán los problemas que se encuentran al principio del
ciclo de vida, durante la concepción del sistema, cuando se debe capturar las necesidades del usuario. Si esta relación
desarrollador-usuario no se realiza correctamente es muy probable que lo que se obtenga difiera en considerable
medida de lo que el usuario espera, llevando a la frustración y descontento de éste.
En este tema y posteriores se pone de manifiesto que el software es un producto cada vez más complejo que requiere
un proceso de ingeniería en su desarrollo para garantizar el éxito en el mismo. A lo largo de estos temas se verán
diferentes enfoques para atacar y resolver el problema de una manera ordenada, que nos permita construir un sistema
de una forma metódica y sistemática, siguiendo una serie de pasos preestablecidos y aplicando un conjunto de técnica
de reconocida efectividad, para lograr, en último fin, satisfacer completamente las necesidades del usuario.

78.02. El Análisis de los Sistemas de Información

El Análisis de los Sistemas de Información, si descartamos las fases previas de planificación estratégica y estudios de
viabilidad de los sistemas, es la primera fase del desarrollo de un sistema. Según Métrica v3, el Análisis del Sistema de
Información tiene por objetivo la obtención de una especificación detallada del sistema que satisfaga las necesidades
de información de los usuarios y sirva de base para el posterior diseño del mismo. A esta especificación se la suele
conocer como ERS o Especificación de Requisitos Software.
Existe un vacío entre el problema real (descripción del sistema) y la definición de un sistema que resuelva el problema
real (modelo de diseño del sistema). Con el análisis se pretende pasar del dominio del problema a un modelo del
sistema que sea implementable en una máquina. El Análisis hace de puente entre el problema y el diseño, identificando
las necesidades y restricciones del problema y generando unas especificaciones (modelo de análisis) que sirvan de base
para crear un diseño.

Descripción Modelo de
Descripción Modelo de
del Sistema Diseño
del Sistema Diseño

Modelo de
Modelo de
Análisis
Análisis

Según Pressman, el modelo de análisis debe cumplir tres objetivos:

 Describir lo que el cliente quiere.
 Establecer una base para la creación de un diseño de software.
 Definir un conjunto de requisitos que una vez el sistema construido se puedan validar.
El primer objetivo es vital, si el modelo de análisis no describe lo que el cliente quiere, como en las siguientes fases nos
basaremos en el modelo de análisis, el sistema resultante tras todo el proceso de desarrollo no satisfará las
necesidades del cliente.
El segundo punto, el establecimiento de una base para la creación de un diseño software hace referencia a crear una
especificación que defina, sin ninguna ambigüedad o clase de duda, el funcionamiento del sistema.
078.- El Análisis de Requisitos de los Sistemas de Información y de Comunicaciones 2
 Volumen 3. INGENIERÍA DE LOS SISTEMAS

En cuanto al tercer objetivo, es muy común utilizar los requisitos del sistema como parte del contrato entre el
desarrollador y el cliente. Si el conjunto de requisitos definido es muy vago o no son requisitos reales que puedan ser
posteriormente validados, la relación contractual entre ambas partes puede verse resentida, ya que no habrá manera
de demostrar, de forma fehaciente, que el sistema construido cumple o deja de cumplir con los requisitos.
La Ingeniería del Software ha desarrollado métodos orientados a la captura de las necesidades que tienen los usuarios,
métodos que permiten facilitar el trabajo, pues rara vez los usuarios son capaces de explicarlos claramente. Mediante el
estudio de forma iterativa del problema y aplicando diversas métodos y herramientas, se permite lograr una idea clara
de qué espera el usuario obtener al final del ciclo de desarrollo. A lo largo de este tema se estudiarán técnicas que nos
permitan obtener las necesidades reales del cliente y en posteriores temas se estudiarán técnicas para representar
estas necesidades.

78.02.1. Actividades del Análisis

Dependiendo de los autores, y dado el tremendo avance que se ha producido en esta área en los últimos 30 años,
existen diferente nomenclaturas de actividades para hacer referencia a un mismo concepto, el análisis. En todas estas
nomenclaturas subyace la secuencia básica de actividades siguiente:

Educción de Análisis de Representación Validación de

Requisitos Requisitos de Requisitos Requisitos

La primera actividad es la Educción de Requisitos. En ella los analistas obtienen las necesidades del cliente a partir de
todas las fuentes de información que tienen disponibles (documentación, entrevistas, estudio de los procesos de la
organización, etc.). Términos equivalentes usados por los ingenieros de software para esta actividad son Extracción de
Requisitos, Identificación de Requisitos, Determinación de Requisitos, etc.
En la actividad de Análisis de Requisitos se procede a trabajar sobre los requisitos educidos en el paso anterior. Se
estudian los requisitos en busca de conflictos e incoherencias, implicaciones, información no obtenida y aspectos no
resueltos. Después se clasifican, evalúa su viabilidad y se integran los nuevos requisitos con los ya existentes. El
objetivo final es lograr una lista de requisitos que defina las necesidades del cliente.
El tercer paso corresponde con la Representación de los Requisitos, actividad en la que se representan los requisitos de
una o más formas, utilizando para ello diferentes técnicas como por ejemplo el lenguaje formal, el lenguaje natural,
representaciones gráficas, etc. Para la representación existen múltiples técnicas, las más usadas son, entre otras, los
Diagramas de Flujo de Datos, Modelo Entidad Relación, Casos de Uso o Diagramas de Clases. Una vez que están los
requisitos representados, es necesario que se reúnan los diversos participantes en el desarrollo para revisarlos y
aprobarlos. El producto final con el que culmina esta fase es la Especificación de Requisitos Software, en donde está
descrito con exactitud todo lo que el sistema debe hacer.
En el último paso, en la Validación de Requisitos se procede a definir una serie de criterios y técnicas que permitirán,
cuando el sistema esté construido, comprobar que éste cumple los requisitos.
Las dos primeras actividades están en estrecha relación con el usuario o cliente, ya que se obtiene de ellos la
información. Por el contrario, la tercera fase está más relacionada con el equipo de desarrollo, ya que los analistas, a
partir de la información obtenida del cliente, se encargan de construir una serie de modelos, que posteriormente serán
validados por el cliente, pero cuyo objetivo primordial es el de indicarle a los diseñadores qué se debe hacer.
Aunque estas cuatro actividades se han dibujado de forma secuencial en el diagrama, la realidad es que no existe una
estricta secuencialidad entre ellas debido a que se llevan a cabo entrelazadamente y de forma repetitiva, hasta que las
especificaciones del sistema están completamente confeccionadas.
A lo largo de este tema se estudiarán las actividades de “Educción de Requisitos” y “Análisis de Requisitos” dejándose
para temas posteriores el estudio de la “Representación de los Requisitos” y “Validación de los Requisitos”.

78.02.2. Otras Nomenclaturas en el Análisis

Aunque como hemos dicho anteriormente, las ideas subyacentes son las mismas, no todos los autores utilizan la
nomenclatura anterior para referirse a los distintos pasos que se dan durante el análisis. Hay autores que separan el
concepto de análisis de requisitos de la especificación, simplificando el número de pasos, mientras otros consideran el
análisis del sistema como la representación, quedando fuera de dichos límites la obtención de los requisitos del sistema.
Existen autores que separan la fase de análisis en dos actividades:
 Análisis del Problema, Definición de Requisitos, Análisis de Requisitos, Definición del Problema o Modelización

078.- El Análisis de Requisitos de los Sistemas de Información y de Comunicaciones 3

 Volumen 3. INGENIERÍA DE LOS SISTEMAS

Esencial: Donde se adquiere el conocimiento sobre el problema, se identifican restricciones, y se organiza la

información hasta que se tiene una visión clara del problema. Esta actividad corresponde con las actividades de
“Educción de Requisitos” y “Análisis del Problema”.
 Descripción del Producto, Definición del Comportamiento Externo, Especificación Funcional o Modelo de
Usuario: Se prepara el documento de descripción del producto. Esta actividad corresponde con la actividad de
“Representación de Requisitos” vista anteriormente.
En la versión 2.1 de Métrica, la Metodología de la Administración Española, se hace esta división. Existe una fase de
Análisis de Sistemas que se subdivide en dos módulos:
 Módulo ARS (Análisis de Requisitos del Sistema): Describir el alcance, los objetivos y los requisitos del sistema.
 Módulo EFS (Especificación Funcional del Sistema): En este segundo módulo, el objetivo es el de elaborar un
documento con las especificaciones funcionales del sistema a construir.
Sin embargo, en la versión 3 de Métrica todas las actividades se unen bajo una única fase, la fase de Análisis del
Sistema de Información (ASI). Las tareas de análisis de requisitos y especificación funcional se fusionan en una sola,
quedando primero un análisis de requisitos y después una serie de actividades de modelización, que dependerán estas
últimas del enfoque estructurado u orientado a objetos que se le quiera dar al proyecto.
Otros autores como Thayer, al análisis lo denominan Ingeniería de Requisitos y expanden estos cuatro pasos detallando
más las actividades que se realizan:
 Inicio. Se establece una comprensión básica del problema por parte de los analistas.
 Obtención. Se obtienen los requisitos del software mediante la interacción entre los analistas y el cliente.
 Elaboración. Se refina la información obtenida en el paso anterior y se enfoca a la construcción de un
modelo de análisis que represente al sistema a construir.
 Negociación. Hay requisitos que no son implementables o son difíciles de hacerse, por esta razón los
analistas negocian estos requisitos para llegar a un entendimiento y lograr un sistema factible de desarrollarse
en un plazo y coste.
 Especificación. Se confecciona un conjunto de documentos (descripciones en lenguaje natural, diagramas,
etc.) que definan lo que el sistema debe hacer.
 Validación. Se examina la especificación para asegurar que todos los requisitos software se han establecido
de una manera precisa, que no hay inconsistencias, omisiones ni errores, además de cumplirse los estándares
de calidad establecidos para el proyecto.
 Gestión de Requisitos. Esta actividad permite tratar con el inevitable problema de los cambios de
especificaciones, identificando, controlando y determinando el impacto del cambio de requisitos en el resto.
Como se puede ver, las dos primeras fases se corresponden con la Educción de Requisitos, las dos subsiguientes con el
Análisis de Requisitos y las dos siguientes con la Representación de Requisitos.
En cuanto a la Gestión de Requisitos es una actividad que se realizar a lo largo de todo el proyecto, desde que se dan
por establecidos los requisitos hasta que se finaliza el sistema, y tiene por objeto gestionar los cambios en los mismos.
Sin una adecuada gestión de los requisitos no se puede garantizar el éxito del proyecto, ya que puede darse la
paradoja de que el sistema construido de soporte a las necesidades del usuario cuando los requisitos se definieron,
pero que estos cambien y ya el sistema no dé soporte a las nuevas necesidades.
Las razones por las que cada autor usa una terminología en apariencia diferente no son caprichosas, sino que son
debidas a la rápida y constante evolución que existe en el área de los requisitos de los sistemas software, uno de los
más desconocidos del desarrollo.

78.03. El Análisis de Requisitos de los Sistemas de Información y de Comunicaciones

Como dice Fred Brooks, “La parte más difícil de construir un sistema es decidir qué construir. Ninguna parte del trabajo
estropea tanto el sistema resultante si se hace mal. Ninguna parte es más difícil de rectificar después.”
Con esta afirmación queda claro que un error mientras se decide qué se va a construir puede ser fatal para todo el
proyecto. Una mala orientación del proyecto al principio del mismo puede hacer que éste siga un camino equivocado y
se construya un sistema, que en el mejor de los casos no cubra todas las necesidades y expectativas del usuario, y que
en el peor de los casos llegue a paralizar el desarrollo del proyecto y se cancele éste.
Puede parecer demasiado exagerado el que no se sepa determinar correctamente el sistema a construir, ya que al fin y
al cabo, todos son parecidos y los que desarrollan los sistemas tienen mucha experiencia. El problema principal no está
en la experiencia de los desarrolladores, la experiencia de los usuarios o la similitud de un sistema con los demás, sino
más bien el problema principal está en el entendimiento entre ambas partes.
078.- El Análisis de Requisitos de los Sistemas de Información y de Comunicaciones 4
 Volumen 3. INGENIERÍA DE LOS SISTEMAS

El siguiente ejemplo es real y le ocurrió a una empresa multinacional de refrescos. Esta empresa hizo un estudio para
lanzar un nuevo envase de 3 litros para sus refrescos en el mercado español. Se basó en los resultados obtenidos en el
mercado estadounidense y vio que la idea tenía un gran potencial. Se desarrolló y se puso en venta el producto pero
éste resultó ser un fracaso. Estudios posteriores revelaron que había un detalle “sin importancia” que habían pasado los
analistas del producto por alto: “los frigoríficos europeos son más pequeños que los americanos y las botellas de tres
litros no caben de pie en la puerta del mismo”. Sirva este ejemplo como clarificador de que un pequeño detalle puede
hacer que todo el sistema fracase.
Otro ejemplo también real, esta vez del sector informático, es el de un proyecto que se construyó en 1990 para el
Sistema de Ambulancias de Londres. El proyecto contó una inversión total de 1.2 millones de libras y el objetivo era
eliminar las estaciones de radio y teléfonos. Los resultados de la puesta en marcha del sistema no pudieron ser peores.
Se estimó que hubo 20 fallecimientos por retraso en las llegadas de las ambulancias, retrasos que no se habrían
producido si se hubieses seguido con el sistema antiguo. Además el tiempo de espera fue alto, se produjeron llamadas
duplicadas, se perdían llamadas y había problemas de uso con el sistema.
Del análisis del problema se pudo extraer que una de las causas principales del fracaso fue la interfaz de usuario que se
desarrolló era moderna y llamativa, pero al mismo tiempo ineficaz. Si se hubiese hecho un adecuado análisis de
requisitos se hubiese detectado, quizás mediante la construcción de un prototipo de la interfaz de usuario, las
deficiencias de ésta y se hubiesen podido resolver antes de la puesta en marcha del sistema. Este fue un fracaso que
no sólo costó mala imagen y dinero, sino también vidas humanas.
Pressman, haciendo referencia al entendimiento entre ambas partes escribió:
Es tu peor pesadilla. Un cliente entra en la oficina, se sienta, te mira directo a los ojos, y dice: "Yo sé que usted piensa
que entiende lo que digo, pero lo que usted no entiende es que lo que digo no es realmente lo que quiero decir". Esto
sucede de manera invariable cuando el proyecto está avanzado, después de que se han realizado los compromisos
relativos al tiempo de entrega, las reputaciones están en juego y el dinero está en serio peligro .
Esto, por desgracia, resume lo que ocurre en muchos proyectos cuando no se hace un adecuado análisis de las
necesidades del cliente. Es muy común que el cliente “no sepa” lo que quiere. Tiene una idea aproximada pero en la
mayoría de los casos no tiene los conocimientos o no sabe exactamente como concretarla. Por eso, el trabajo del
analista está en ayudarle a perfilar esa idea, desterrar las ideas inviables y redirigirle a soluciones mejores, para que el
sistema que se construya pueda aportar todo su potencial a la organización. El análisis de requisitos es por tanto una
ayuda a los analistas para conocer mejor el problema.

78.03.1. El Desarrollador, El Cliente y el Usuario

Antes de continuar con la exposición hay que puntualizar las diferencias existentes entre los tres principales
participantes de un proyecto informático: El Desarrollador, El Cliente y El Usuario.
El Desarrollador es cualquiera de los participantes que construyen y ponen en marcha el sistema. Bajo el término de
desarrollador se hace referencia desde un analista a un programador o un técnico de pruebas, por poner algunos
ejemplos.
El Cliente es el participante que paga la construcción del sistema. Normalmente, el cliente no participa directamente
en el desarrollo del sistema, sino que define a un conjunto de usuarios avanzados para que lo hagan. Se puede ver al
cliente como la organización que paga el sistema o a la alta dirección que la dirige.
El Usuario pertenece a la organización cliente y tiene un conocimiento avanzado sobre una o varias áreas que abarca
el proyecto. Normalmente los usuarios no suelen ser los que utilizan directamente el sistema, sino que suelen ser
responsables de un cierto área y para ellos trabaja una serie de personas, que sí que usan el sistema. Este nivel
superior al de un usuario normal permite al usuario avanzado tener una visión más general que la que tiene un usuario
normal. Los usuarios no suelen disponer del 100% del tiempo para el proyecto sino que el desarrollo lo compaginan
con su trabajo diario normal.
Es muy común que los desarrolladores no pertenezcan a la empresa cliente. Los desarrolladores son contratados para
desarrollar el sistema y cuando terminan dejan el proyecto. En algunos casos el cliente toma las riendas del proyecto
de mantenimiento, y en otras el cliente decide adjudicar el mantenimiento a una empresa externa, ya sea la misma
empresa que desarrolló el sistema u otra tercera empresa.

78.03.2. ¿Qué es el Análisis de Requisitos?

Antes de comenzar a estudiar en detalle el Análisis de Requisitos es conveniente tener una visión general de qué y
dónde se sitúa el análisis de requisitos dentro del proceso de desarrollo de software. A grandes rasgos, el análisis de
requisitos es una actividad de la ingeniería del software que permite identificar y plasmar en un documento las
necesidades del cliente. Como se ha visto anteriormente, el análisis de requisitos es una de las partes que componen la
fase de análisis, en la que se obtiene del cliente las necesidades que éste tiene sobre un determinado problema. Estas
necesidades son plasmadas en un documento de requisitos que se usará posteriormente, en la actividad de

078.- El Análisis de Requisitos de los Sistemas de Información y de Comunicaciones 5

 Volumen 3. INGENIERÍA DE LOS SISTEMAS

especificación del sistema, para generar una especificación funcional de lo que el sistema debe hacer, es decir, una
especificación de qué hay que construir sin entrar en el detalle de cómo hacerlo.
Existen numerosas definiciones de Análisis de Requisitos, como por ejemplo la que propone el CMMI (Capacity Maturity
Model Integration) es "El objeto de la Gestión de Requisitos es establecer un entendimiento común entre el cliente y el
proyecto de software respecto a los requisitos del cliente a abordar en el proyecto de software."
Thayer la define como “La ingeniería de requisitos proporciona el mecanismo apropiado para entender lo que el cliente
quiere, analizar las necesidades, evaluar la factibilidad, negociar una solución razonable, especificar la solución sin
ambigüedades, validar la especificación, y administrar los requisitos conforme se transforman en un sistema
operacional”.
De todas las definiciones existentes, el concepto que subyace bajo todas ellas es el mismo, es decir, que con el análisis
de requisitos el analista comprenda el problema del cliente para así poder construir un sistema que responda
satisfactoriamente a las necesidades del cliente.

78.03.3. Porqué es importante el Análisis de Requisitos

Ya se ha visto que el coste de corregir un error de requisitos en un sistema que está funcionando es muy elevado, pero
¿cuánto representa?. Se han hecho estudios que cuantifican entre unos márgenes el coste de realizar dichas
modificaciones.
En el siguiente gráfico se representa el coste relativo de corregir un error. Si el coste relativo de corregir un error en la
fase de análisis es 1, el coste de corregirlo en el resto de fases se multiplica por un factor de 3 a 6 en el Diseño, un
factor de 10 en la Construcción, un factor de 14 a 40 en las Pruebas de Desarrollo, un factor de 30 a 70 en las pruebas
del sistema y entre 40 y 1000 cuando el sistema está en explotación.

Análisis (1 vez)
Diseño (3-6 veces)
Construccion (10 veces)
Prb Desarrollo (15-40 veces) Coste Relativo
Prb Sistema (30-70 veces)
Explotación (40-1000 veces)

1 10 100 1000

Además de estos costes, que son monetarios y referentes al coste dentro del proyecto, hay que tener en cuenta otros
costes adicionales, como por ejemplo:
 Pérdidas por dejar de ingresar dinero debido a los fallos del sistema.
 Pérdidas debidas al retraso de la entrada en funcionamiento del sistema.
 Pérdidas de imagen corporativa, al no funcionar correctamente el sistema. Estas pérdida son difícilmente
cuantificables y se suelen medir en el número de clientes perdidos.
 Pérdidas humanas, como las del ejemplo de las Ambulancias de Londres.
 Pérdidas por parte de la empresa desarrolladora debidas a que el trabajo presupuestado era inferior al real
realizado. Esto se debe al retrabajo que se ha requerido para modificar el sistema y adecuarlo a las nuevas
necesidades.

78.03.4. Concepto de Requisito o Requerimiento

En el análisis de requisitos, el elemento básico que se maneja durante las actividades es el requisito o también llamado
requerimiento. Los requisitos se generan a partir de la interacción entre los usuarios y los desarrolladores,
representando dichos requisitos las características del sistema a construir, es decir, las necesidades de los usuarios.
[Link]. ¿Qué es un requisito?
Hay múltiples definiciones de un requisito, algunas de ellas son:
 Según IEEE un requisito es:

078.- El Análisis de Requisitos de los Sistemas de Información y de Comunicaciones 6

 Volumen 3. INGENIERÍA DE LOS SISTEMAS

o Una condición o capacidad necesitada por un usuario para resolver un problema o alcanzar un
objetivo.
o Una condición o capacidad que debe cumplir o poseer un sistema o un componente del mismo para
satisfacer un contrato, un estándar, una especificación, u otro documento impuesto de una manera
formal.
o Una representación documentada de una condición o capacidad tal como las expresadas en los dos
puntos anteriores.
 Desde el punto de vista del usuario, los requisitos son las condiciones o capacidades necesarias para que un
usuario pueda resolver un problema o alcanzar un objetivo
 Desde el punto de vista del equipo de desarrollo, los requisitos son las capacidades o condiciones que debe
reunir un sistema para satisfacer un contrato, estándar o cualquier otro documento impuesto formalmente.
En resumen, los requisitos son las características que debe cumplir el sistema para que cubra las necesidades de los
usuarios.
Para que un proyecto de desarrollo se un éxito hace falta que se den las tres condiciones siguientes:
 Se entiendan y documenten adecuadamente las necesidades del sistema. Esta condición se logra mediante un
buen análisis de requisitos.
 Se haga un desarrollo de manera adecuada. Es decir, que a partir de un buen análisis de requisitos se haga un
buen desarrollo.
 Se controlen suficientemente los cambios. Aún cuando se haga un análisis de requisitos excelente, lo más
probable es que se produzcan cambios en los mismos. Es vital que se gestione el proceso de cambios en los
requisitos para que el sistema que finalmente se construya siga dando respuesta a las necesidades del
usuario.
[Link]. Requisitos a Nivel de Sistema vs Requisitos a Nivel de Software
La principal diferencia entre los Requisitos a Nivel de Sistema y a Nivel de Software es que en el primer caso los
requisitos no sólo hacen referencia al sistema software a construir, sino que también hacen referencia a otros
elementos diferentes al sistema software.
La diferencia se entiende bien en un sistema como por ejemplo un avión. En la actualidad un avión no sólo está
compuesto por componentes mecánicos sino que está compuesto por una mezcla de software y múltiples piezas
mecánicas que se mueven por la acción manual o mediante actuadores mecánicos. Muchas de estas piezas permitirán
interactuar con el sistema software o serán movidas por el sistema software para actuar sobre el entorno. La
especificación del sistema comprendería tanto la parte software del avión (software de aviónica, presentación de la
información en pantallas, actualización de los instrumentos de navegación según la información recibida, detección de
la posición de los elementos de control del avión como la palanca de potencia o mandos de control, etc.) como la parte
que no es software, sino otro tipo de elementos físicos (asientos, tren de aterrizaje, parte física de los mandos de
control, flaps, parte física de la palanca de potencia, fuselaje, alas, especificación de los motores, etc.)
En el caso de la especificación de un sistema TIC, que incluya tanto parte software como parte de comunicaciones,
será necesario especificar el sistema completo, que incluirá la especificación de la parte software y también la
especificación de la parte de comunicaciones. En la primera se especificará lo que debe hacer el software mientras que
en la última se incluirán los equipos de redes, cableados, etc. que hacen posible las comunicaciones.
[Link]. Identificación única de cada requisito
Es vital para el proyecto que cada requisito se pueda identificar de forma única de entre el conjunto de requisitos. De
esta forma, un requisito podrá hacer referencia a otros requisitos y también se podrán hacer matrices de trazabilidad
que permitan relacionar en ellas cada una de las funcionalidades del sistema y a qué requisitos se deben dichas
funcionalidades.
El código único puede estar basado en cualquier esquema de numeración que permita generar números únicos.
Algunos ejemplos pueden ser:
 Número secuencial. Ej. 1, 2, 3, 4...
 Esquema Jerárquico. Ej. RF1.1.4, RF2.8.7, [Link]
 Esquema Jerárquico y Subsistema. Se puede definir un código para cada subsistema y después, dentro del
subsistema usar un esquema jerárquico. Para proyectos grandes permite una primera partición de los requisitos
en subsistemas de una forma sencilla e intuitiva. Ej. FAC.1.7.21.

078.- El Análisis de Requisitos de los Sistemas de Información y de Comunicaciones 7

 Volumen 3. INGENIERÍA DE LOS SISTEMAS

[Link]. Información a registrar de cada requisito

Será necesario que cada requisito esté descrito por al menos los siguientes datos:
 Código Único. Permitirá identificar al requisito.
 Nombre Descriptivo del Requisito. Será una frase que describa brevemente el requisito. Deberá permitir
leer la frase y entender qué es lo que se describe en el requisito sin necesidad de leer la descripción completa.
 Descripción. Será la descripción detallada del requisito, explicando con el detalle que sea necesario las
características del mismo. Se podrán incluir, si es necesario, diagramas, referencias a documentos del cliente,
etc.
Adicionalmente es recomendable que se registren también los siguientes datos:
 Fecha de Creación
 Número de Versión
 Códigos de Requisito,
 Estado en el que se encuentra el requisito. Se indicará si el requisito está aceptado, rechazado, duplicado con
otro, etc.
 Autor y/o organización que generó el requisito
 Prioridad o importancia del requisito en relación con el producto (especificado como alta, media o baja)
 Subsistema y / o funcionalidad a la que está asignado el requisito
 Liberación o entrega del producto en que quedaría implantado el requisito
 Especificación del origen del requisito, la razón que lo respalda, si la hubiera, y dónde puede encontrarse esa
información.
 Persona u organización que garantiza formalmente la implantación del requisito y método de verificación a
utilizar.
 Criterio de pruebas de aceptación del requisito.
 Opcional u Obligatorio. Hay requisitos son deseos del usuario de que el software automatice en un solo paso
ciertas tareas que se pueden hacer con el sistema pero requieren varios pasos. Estas automatizaciones no son
esenciales aunque son deseables para el usuario. Otras veces es un deseo del usuario que le parece que podría
venir bien para el sistema, pero si no se hace, no pasa nada.
 Beneficio, penalización, coste y riesgo que se espera tener por la implantación o no del requisito.
 Estabilidad del requisito. Especifica si el requisito tiene pocas probabilidades de cambiarse (requisito estable) o
si por el contrario tiene muchas (volátil).
Si la gestión de requisitos se hace de forma manual, algunos de los datos anteriores son difíciles de mantener
actualizados, como las fechas de actualización y los usuarios de actualización. Por el contrario, si se usa una
herramienta de análisis de requisitos, ésta permitirá registrar todos los datos anteriores, además de permitir configurar
otros datos que se consideren necesarios para un proyecto en particular.
[Link]. Categorización de los requisitos (funcionales, no funcionales, etc.)
Según Sommerville, los requisitos pueden clasificarse en requisitos a nivel de sistema y requisitos a nivel de software.
Los requisitos a nivel de sistema hacen referencia no sólo al software, sino a todas las partes implicadas en el sistema
que se está construyendo, como sistemas de comunicaciones, hardware, etc.
 A nivel de sistema:
o Requerimientos Funcionales Abstractos. Son las funciones básicas que debe hacer el sistema a
un nivel abstracto. Posteriormente, en cada uno de los subsistemas se concretan más.
o Propiedades del Sistema: Propiedades no funcionales del sistema como por ejemplo
disponibilidad, rendimiento, seguridad. Estas propiedades puede que no afecten a todos los
subsistemas.
o Características que no debe mostrar el sistema. En algunas ocasiones es importante especificar
lo que el sistema no debe hacer. En un sistema de control de tráfico aéreo, se puede especificar que
el sistema no debe especificar demasiada información al controlador.
 A nivel del software:

078.- El Análisis de Requisitos de los Sistemas de Información y de Comunicaciones 8

 Volumen 3. INGENIERÍA DE LOS SISTEMAS

o Requerimientos Funcionales: Son los requisitos que especifican el funcionamiento del software a
construir.
o Requerimientos No Funcionales: Son los requisitos que especifican aspectos adicionales que no
corresponden con el funcionamiento del sistema. Estos requisitos no funcionales se pueden
categorizar en:
 Seguridad
 Rendimiento
 Entorno
 Implantación
 Disponibilidad del Sistema
 Portabilidad
 Fiabilidad
 Eficiencia
 Ingeniería Humana
 Modificabilidad
 Etc.
También según Sommerville, los requisitos se pueden categorizar como requisitos de usuario, los cuales dan una visión
del sistema desde el punto de vista del usuario, o de sistema, los cuales dan una visión más detallada de la
funcionalidad a proporcionar.
 Requisitos de Usuario: Declaraciones abstractas de los requerimientos del usuario final y el cliente. Se
especifican normalmente como lenguaje natural o diagramas. Son los servicios que el sistema proporciona y
las restricciones que debe cumplir.
 Requisitos del Sistema: Descripción más detallada de la funcionalidad a proporcionar. Establece con detalle
funciones, servicios y restricciones operativas del sistema.
[Link]. Ejemplos de requisitos
A continuación se muestran algunos ejemplos de requisitos:
 1: El sistema deberá dar la respuesta a la consulta en un tiempo inferior a 1 segundo.
 RF1: El sistema deberá validar los datos de la entrada de la compra.
o RF1.1: El nombre y apellidos se validará contra la base de datos corporativa de clientes.
o RF1.2: La dirección se validará contra el sistema de callejero corporativo.
o RF1.3: El importe de la compra no podrá ser inferior a 6€.
 FAC.1.7.21: El sistema ejecutará el ciclo de facturación diariamente con todos los clientes incluidos en dicho
ciclo de facturación.
En el primer ejemplo se usa un esquema de numeración secuencial, mientras que en el segundo se usa un esquema
jerárquico.
En el ejemplo se describe un requisito RF1, que es detallado posteriormente en otros requisitos de menor nivel, como
RF1.1, RF1.2 y RF1.3.
En el último ejemplo se hace una división por subsistemas, al subsistema de Facturación se le identifica por el código
FAC y dentro de éste se hace una subdivisión jerárquica como en el ejemplo anterior.
[Link]. Características de los requisitos
Para que los requisitos sean de utilidad éstos deben cumplir una serie de características. Así, los requisitos deben ser:
 Completos. Los requisitos deben describir toda la información necesaria para construir el sistema.
 Consistentes. No debe haber inconsistencias o errores entre distintos requisitos.
 No Ambiguos. Cada requisito debe dejar completamente claro, y sin ningún tipo de duda, la característica que
describe del sistema.
 Verificables. Los requisitos del sistema deben poder ser verificados posteriormente, cuando el sistema esté
construido, para poder probar que el sistema cumple con las necesidades del usuario.
 Comprensibles. Deben ser fáciles de entender, tanto por los usuarios como por los desarrolladores.
 Fáciles de Modificar. Deben poderse modificar fácilmente. Un cambio en un requisito no debe impactar en
muchos cambios en el resto. El referenciar unos requisitos desde otros en vez de copiar el texto es una buena
práctica.
078.- El Análisis de Requisitos de los Sistemas de Información y de Comunicaciones 9
 Volumen 3. INGENIERÍA DE LOS SISTEMAS

78.03.5. Proceso de Obtención de Requisitos

El proceso de obtención de los requisitos no es un proceso lineal al que se le aplican unas determinadas técnicas y se
obtiene la lista de requisitos, sino que éste es un proceso complicado, es un proceso social, que afecta a la
comunicación entre las personas, y que por tanto requiere hacerse de forma iterativa. Pressman define este proceso
como un proceso iterativo, en el que el analista debe modelar lo que conoce y utilizar el trabajo ya realizado para
obtener el resto.
El proceso de obtención de los requisitos se puede definir como un proceso iterativo que comprende las siguientes
fases:
1. Identificar las fuentes relevantes de información
2. Preguntar las cuestiones apropiadas para obtener y comprender sus necesidades
3. Analizar la información obtenida buscando:
 Inconsistencias
 Implicaciones
 Información no obtenida o aspectos no resueltos
4. Confirmar la comprensión de los requisitos con los usuarios
5. Sintetizar la información en uno o varios requisitos
El primer paso es la obtención de las fuentes de información que son relevantes para cada proyecto. Se puede hacer
una lista de fuentes de información estándar, pero en cada proyecto existirán fuentes específicas que no deben ser
obviadas. En el apartado 78.03.6 Fuentes de Información para el Análisis de Requisitos se describen estas fuentes de
información.
El segundo paso consiste en estudiar la información obtenida y a partir de ahí preparar un conjunto de cuestiones que
preguntadas de a forma adecuada nos permitirán comprender las necesidades del usuario. Este es uno de los puntos
más complicados, pues trata con la comunicación entre usuarios y desarrolladores, la cual no está exenta de
problemas. Hacer las preguntas adecuadas y obtener las respuestas precisas es una labor complicada, que viene
ayudada por una serie de técnicas que se estudiarán más adelante.
El tercer paso es el de analizar la información obtenida en el paso anterior, buscando inconsistencias, implicaciones,
información que no se haya obtenido o aspectos que no están todavía resueltos. Las implicaciones pueden llevar a
detectar inconsistencias subyacentes que deberán ser posteriormente resueltas. Tanto las inconsistencias como la
información no obtenida o los aspectos no resueltos deben ser parte de una nueva batería de cuestiones que se
deberán hacer para obtener toda la información.
En el cuarto paso, una vez que los analistas consideran que toda la información obtenida es consistente y completa,
éstos deben confirmar con los usuarios que ésta es correcta, es decir, que el usuario considera que ésta representa a la
realidad, y que no ha existido un malentendimiento entre usuarios y desarrolladores a la hora de capturar los
requisitos.
El último paso consiste en sintetizar la información obtenida en uno o más requisitos que describan el aspecto del
sistema que se ha estudiado.
[Link]. Dificultades en la Obtención de Requisitos
Como se ha visto anteriormente, el proceso de obtención de requisitos es un proceso social, una comunicación entre
personas, por lo que no está exento de problemas. Es importante conocer cuales son estos problemas para así poder
tratar de forma efectiva con ellos.
 El lenguaje de comunicación es en sí ambiguo y se presta a la mala interpretación.
 Los usuarios tienen una vaga idea de lo que quieren. No saben expresar con claridad lo que quieren.
 Los usuarios y los desarrolladores tienen una visión diferente del sistema.
 Los usuarios no tienen una formación informática y no entienden todo lo que se les dice. Hay que tener
cuidado con la terminología.
Los problemas de obtención de requisitos se pueden agrupar en tres categorías:
 Problemas de Alcance: Se debe especificar con precisión el alcance que va a tener el sistema,
determinándose los límites y los objetivos del mismo. El alcance se puede definir en función de:
o La Organización: Ofrecen una comprensión de la organización en la que se desarrolla el proyecto y
del contexto en el que se desarrolla éste. Quien introduce las entradas al sistema, quien recibe los

078.- El Análisis de Requisitos de los Sistemas de Información y de Comunicaciones 10

 Volumen 3. INGENIERÍA DE LOS SISTEMAS

resultados, cambios en el modo de trabajo de la organización por introducir el nuevo sistema.

o Del Entorno: Descripción del entorno en el que va a operar el sistema que se va a crear.
Restricciones de hardware, software, si el sistema está dentro de otro más grande, etc.
o Del Proyecto: Factores del contexto del proyecto que se va a desarrollar, como: conocimientos de los
participantes, experiencia, jerarquía de personas, tiempo, coste, etc.
 Problemas de Comprensión: La obtención de requisitos es un proceso de comunicación entre personas que
está expuesto a malentendidos y diferentes interpretaciones. Los problemas de comprensión se pueden dividir
en:
o Diferente formación de los participantes en el proyecto: informáticos, usuarios, control de calidad,
etc.
o Lenguaje demasiado formal o informal para ser entendido correctamente por todos. Un mismo
término puede tener un significado general distinto al que tiene en un contexto en particular.
o La información que se va obteniendo es necesario organizarla y transformarla, lo que la hace
vulnerable a interpretaciones erróneas durante el procesado.
o Visión diferente del proyecto por parte de cada uno de los participantes. La visión del desarrollador
no es la misma que la del usuario o la de la alta dirección. Uno ve el proyecto como el trabajo a
desarrollar mientras que el usuario lo ve como una herramienta que le ayudará en su trabajo y la alta
dirección lo ve como una herramienta para lograr los objetivos.
 Problemas de Volatilidad: Las necesidades del usuario van cambiando a lo largo del proyecto, ya sea por
razones externas al usuario o porque ha madurado las ideas y ha visto mejores formas de hacer algo. Las
principales causas de volatilidad de son:
o Las necesidades del usuario cambian.
o Los requisitos son el resultado de integrar información de múltiples fuentes, algunas con intereses
contrapuestos.
o La complejidad de la organización puede hacer que a lo largo del proyecto se cambien objetivos,
políticas, legislación, etc.
[Link]. Conductas a la hora de obtener requisitos
A la hora de obtener requisitos es importante mantener una serie de conductas que ayudaran a superar con éxito las
dificultades de la obtención de requisitos.
Dado que no sólo los desarrolladores son los únicos participantes del proyecto, es necesario que todos los participantes
entiendan y sigan las recomendaciones para lograr un buen proceso de obtención de requisitos.
[Link].1. Conductas de un Buen Proceso de Obtención de Requisitos
A continuación se resumen las conductas que se deben tener para lograr un buen proceso de obtención de requisitos.
 Usuarios y Clientes
 Comprender las decisiones tomadas al desarrollar los requisitos . Para ello, los desarrolladores deben
explicar dichas decisiones, las razones por las que las toman, y que no se hacen de forma arbitraria o porque
es más sencillo.
 Compartir con el ingeniero de software una visión de los problemas a resolver y las clases de
soluciones posibles. Ambas partes deben tener la misma visión del sistema, de cuales son los problemas que
están presentes y las soluciones para hacerlo. El usuario es el que más conoce sobre su área de negocio, el
desarrollador el que sabe sobre construir sistemas. Ambos deben juntar su conocimiento para superar los
problemas que se presenten.
 Sentirse propietario de los productos que se están produciendo. Si los usuarios se sienten propietarios
de lo que se está haciendo, éstos participarán de forma mucho más activa en el desarrollo, y cuando esté
construido usarán el sistema con mucho más entusiasmo.
 Los clientes podrán usar el sistema de una forma efectiva . Si los usuarios han participado en el
desarrollo y han aportado su conocimiento, el sistema resultante permitirá trabajar de una forma mucho más
efectiva. Una misma actividad se puede realizar de diferentes formas, se debe adaptar el sistema a cómo se
hace dicha actividad en una empresa en particular.
 Ingenieros de Software y Desarrolladores
 Están resolviendo el problema correcto para los usuarios . Es muy importante estar siempre convencido
078.- El Análisis de Requisitos de los Sistemas de Información y de Comunicaciones 11
 Volumen 3. INGENIERÍA DE LOS SISTEMAS

de que se resuelve el problema correcto, ya que de lo contrario, el trabajo que se está realizando no tiene
ningún sentido.
 Tienen clara la especificación de alto nivel del sistema a construir . Hace falta tener una visión clara del
sistema desde arriba, para poder determinar el camino a seguir en todo momento en función de esa visión
general.
 Creen que están resolviendo un sistema viable desde todas las perspectivas . Si no se cree en lo que
se está haciendo es mejor parar, disipar las dudas mediante la construcción de prototipos, contrastar con
expertos, con otras fuentes, etc. antes de continuar y que tras tener el sistema construido éste no sea
operativo.
 Conocen el dominio del sistema, lo que les permitirá tomar posteriores decisiones. El desarrollador
debe “empaparse” del conocimiento del entorno del proyecto y del proyecto en si mismo. Si se sabe para qué
sirve el sistema, cómo funciona y qué se quiere lograr, es mucho más fácil que se tomen decisiones acertadas.
[Link].2. Conductas de un Mal Proceso de Obtención de Requisitos
A continuación se resumen las conductas que se deben evitar para lograr un buen proceso de obtención de requisitos.
 Usuarios y Clientes
 Los desarrolladores no les escuchan. No hay nada más frustrante para una persona que lo que propone no
sea escuchado. Se debe escuchar al usuario y determinar si lo que dice es factible o no, argumentándosele
motivadamente las razones por las que no se acepta la idea. El rechazar las aportaciones por norma o porque
sí llevan a una desmotivación de los usuarios y a una baja participación de éstos en el desarrollo.
 Los desarrolladores imponen sus puntos de vista. Muchas veces el desarrollador, debido a la experiencia
de otros proyectos anteriores, trata de imponer su punto de vista. Como antes se ha visto, hay diferentes
formas de realizar la misma actividad y lo que en una organización se hace de una forma, en otra es diferente.
El desarrollador debe tratar de construir un sistema que se adapte a la organización y no al revés.
 Tienen poca participación. Si no se escucha a los usuarios y se trata de imponer el punto de vista de los
desarrolladores, lo más probable es que los usuarios tiendan a no participar en el desarrollo pues ven que sus
inquietudes no son atendidas y que tienen poco que hacer.
 Ingenieros de Software y Desarrolladores
 Están resolviendo el problema equivocado. Si se sabe que se está construyendo el sistema equivocado, lo
mejor es parar y determinar las razones de dicha creencia. Es mejor parar al principio que cuando todo el
sistema está ya construido y los cambios son muchísimo más costosos.
 Nueva información importante aparece en reuniones posteriores . Si se presenta esta situación significa
que el análisis de requisitos no se ha realizado correctamente. Se han omitido fuentes o conceptos que no se
han estudiado con la suficiente profundidad.
 Toman decisiones incorrectas debidas a la falta de conocimientos . El desarrollador debe conocer el
proyecto y el entorno donde se desarrolla éste, para de esta forma poder tomar decisiones correctas. Una
decisión incorrecta, sobre todo en las primeras fases, puede tener unas repercusiones muy elevadas.
[Link]. Técnicas
Para poder lograr un buen análisis de requisitos se han creado una serie de técnicas que le facilitan al analista la labor
de obtención y procesamiento de los requisitos. Todas estas técnicas han sido creadas para superar las dificultades
inherentes al comportamiento humano.
Las técnicas de obtención de requisitos se pueden clasificar, en un primer nivel, en técnicas de alto nivel y técnicas de
bajo nivel. Las técnicas de alto nivel permiten la obtención de requisitos generales, mientras que las técnicas de bajo
nivel permiten obtener requisitos específicos de una parte del sistema o de un usuario en particular. La correcta
combinación de dichas técnicas permitirá al analista hacerse una idea clara del sistema que se debe construir y de las
necesidades del usuario.
A continuación se muestran algunas técnicas de alto nivel y otras de bajo nivel. Algunas de dichas técnicas serán, por
su interés, detalladas más adelante.
 Técnicas de Alto Nivel
o Sesiones JAD Y JRP
o Entorno de Bucles Adaptativo
o Prototipos
o Factores Críticos de Éxito
 Técnicas de Bajo Nivel
078.- El Análisis de Requisitos de los Sistemas de Información y de Comunicaciones 12
 Volumen 3. INGENIERÍA DE LOS SISTEMAS

o Brainstorming
o Entrevistas
o PIECES
o Casos de Uso
o Análisis de Mercado
[Link].1. Sesiones JAD Y JRP
Las técnicas JAD y JRP son técnicas que promueven la cooperación entre los usuarios y los desarrolladores para lograr
que ambas partes compartan una visión común. JAD y JRP son los acrónimos de:
JAD = Joint Application Design = Diseño Conjunto de Aplicaciones
JRP = Joint Requirements Planning = Planificación Conjunta de Requisitos
Tanto JAD como JRP siguen una estructura similar pero con participantes y contenidos a obtener diferentes. Mientras
que JRP se usa para la planificación de requisitos, JAD se usa para el diseño conjunto de aplicaciones.
Ambas técnicas están formadas por el conjunto de pasos siguientes:
[Link]ón del Proyecto. Se definen las características básicas del proyecto, es decir, propósito, alcance y
objetivos del proyecto.
[Link]ón. El equipo se familiariza con el sistema, se investiga y documenta el flujo de trabajo, se
reúnen especificaciones preliminares para los datos elementales, pantallas e informes.
[Link]ón. Se confecciona un documento de trabajo que sirva como base al documento JRP definitivo
(documento de especificación de requisitos).
[Link]ón JAD o JRP. Partiendo del documento de trabajo del paso anterior, y a lo largo de entre 3 a 5 días
de trabajo se definen las especificaciones finales del problema.
[Link] Final. Se confecciona el documento final a partir de todos los formularios, diagramas, etc.
generados durante la sesión.
La base de las técnicas JAD o JRP está en la confección del documento de partida confeccionado en el paso 3. Este
documento será confeccionado por el equipo de desarrollo a partir de la información obtenida en el paso 1 de forma
que cuando el equipo completo se reúna en el paso 4, desarrolladores y usuarios, se podrán conseguir un documento
final en un plazo de 3 a 5 días.
La sesión JAD o JRP requiere que al menos haya personas para desempeñar los siguientes roles:
 Durante toda la sesión existirá un jefe o moderador JAD que se encargará de dirigir la sesión y de organizar la
intervención de los diferente participantes.
 Una persona se encargará de hacer un acta con todos los puntos importantes que vayan surgiendo en las
reuniones.
Las sesiones JAD y JRP deberían durar media jornada. Hay que tener en cuenta que los usuarios normalmente tienen
cometidos que cumplir en la organización. Han sido asignados de forma temporal al proyecto pero no se les descarga
de su día a día. Por esta razón, si una sesión JAD o JRP dura medio día, permite a los usuarios que durante medio día
hagan su trabajo diario o revisar la información generada el día anterior, y en el resto del día puedan participar en el
desarrollo del sistema.
Para evitar que la sesión se desvíe y termine en largas discusiones, sobre temas de poca trascendencia, que no llevan a
ninguna parte, es estrictamente necesario que se planifique ésta antes de empezar. Para cada tema se debe definir el
tiempo que se quiere dedicar a dicho tema, y este tiempo no se puede exceder.
Para la ejecución del paso 4, la sesión propiamente dicha, es de gran utilidad el uso de ayudas audiovisuales como
proyectores, pantallas gigantes, uso de herramientas informáticas para hacer diagramas, etc. La combinación de un
proyector con una pantalla gigante y una herramienta de diagramado es especialmente útil, pues permite a todo el
equipo seguir el razonamiento e ir viendo cómo se van confeccionando los diferentes diagramas.
Una vez que se ha confeccionado el documento final, consensuado por todos, es necesario que este sea revisado por
cada uno de los usuarios. Tras la sesión se enviará dicho documento a todos los participantes para que realicen las
alegaciones que consideren necesarias al mismo.
Por último, para la sesiones JAD y JRP es de especial utilidad seguir el siguiente decálogo para que la reunión se a un
éxito:
1. Compromiso con el Usuario
2. Todos los participantes deben asistir a todas las sesiones

078.- El Análisis de Requisitos de los Sistemas de Información y de Comunicaciones 13

 Volumen 3. INGENIERÍA DE LOS SISTEMAS

3. En la sesión deben estar los participantes correctos para que puedan tomar decisiones
4. Todos los participantes son iguales
5. La preparación es tan importante como la sesión
6. La documentación preparada antes de la sesión se considera una propuesta
7. Celebrar la sesión en un lugar retirado para que sea más productivo
8. Ser puntual en las sesiones
9. Hacer una buena agenda y atenerse a ella
10. Tratar de evitar la jerga técnica
[Link].2. Prototipos
Los prototipos son sistemas software que sólo implementan una parte del sistema. Normalmente, los prototipos se
emplean para obtener requisitos del usuario cuando éstos no están completamente claros. Es mucho más fácil que el
usuario entienda y apruebe un sistema, que aunque es reducido pero también es operativo y puede interaccionar con
él, a revisar una larga lista de texto con los requisitos que describen dicho sistema. Al fin y al cabo, como se suele
decir, el prototipo permite salvar la situación siguiente:
“No se lo que quiero, pero lo sabré cuando lo vea”
Y en efecto, será mucho más fácil para un usuario saber si lo que quiere es lo que tiene delante y que puede
interaccionar con él, que si es un taco de hojas con todos los requisitos escritos uno a uno.
El desarrollo de prototipos no siempre está recomendado, sino que debe usarse principalmente cuando se quiere
probar un aspecto del sistema que no está claro, y el riesgo de cometer un error tiene un impacto considerable en el
resultado del sistema. Hay que tener muy en cuenta que un prototipo cuesta una cantidad considerable de esfuerzo, y
que sólo se justifica ese esfuerzo cuando el esfuerzo ahorrado es superior, para lo cual es muy recomendable el
disponer de herramientas de desarrollo de prototipos, que permitan reducir los tiempos de desarrollo.
No se entrará en detalle en esta técnica pues existe en este temario un tema específico que trata sobre la técnica del
prototipado.
[Link].3. Brainstorming
Esta técnica se usa principalmente para la generación de ideas en los casos en los que la generación de éstas no es
obvia. Se trata de una técnica sencilla en la que se reúnen en grupo de 4 a 10 personas para generar ideas, sin
restricciones, en un ambiente libre de críticas.
Uno de los principales puntos fuertes de la técnica es que ideas que en un principio pueden ser descabelladas tienen
cabida. Primero se proporcionan las ideas y en una segunda vuelta se refinan.
El Brainstorming permite aportar a la obtención de requisitos los siguientes aspectos:
 Genera múltiples puntos de vista de un problema. Cada uno da su visión del problema, que no tiene
porqué ser la misma. Una vez vistos todos los puntos de vista se puede atacar el problema de una forma más
efectiva.
 Formular un problema de distintas formas. Cada participante puede ver el problema desde una óptica
distinta, por lo que a la hora de formularlo lo hará de una forma distinta. Estas diferencias pueden aportar gran
valor a la hora del estudio del problema, identificando los puntos clave del problema de cada participante.
La técnica de Brainstorming, para que sea efectiva, debe ser previamente preparada. Las fases por las que pasa la
ejecución de la técnica son:
 Fase de Preparación.
o Se identifican los participantes de la sesión (clientes, usuarios, analistas, etc.), se designa un líder
que lleva la sesión, se planifica la sesión y se busca una sala adecuada.
 Fase de Generación.
o Se comienza exponiendo las ideas de forma libre, por turnos o espontáneamente. Las ideas se van
apuntando en una pizarra que todos puedan ver.
 Fase de Consolidación.
o Se revisan las idas obtenidas en el paso anterior, se clarifican si no están claras, se rescriben si es
necesario, se descartan las que no son utilizables, se discuten las restantes y se priorizan.

078.- El Análisis de Requisitos de los Sistemas de Información y de Comunicaciones 14

 Volumen 3. INGENIERÍA DE LOS SISTEMAS

[Link].4. Entrevistas
Las entrevistas son una de las técnicas más importantes a la hora de obtener requisitos. Estas técnicas, funcionando
independientemente, o como parte de otra técnica, permiten la obtención de información detallada.
Aunque las entrevistas pueden parecer una técnica fácil y trivial a primera vista, es necesario disponer de un conjunto
de habilidades y planificarlas previamente para sacar el máximo partido de ellas.
Para poder realizar entrevistas, el entrevistador debe contar con la siguientes habilidades:
 Habilidades sociales para comunicarse con el interlocutor, empatía, elocuencia, etc.
 Capacidad para escuchar al entrevistado
 Conocimiento de las diversas tácticas de entrevista

[Link].4.1. Fases de una Entrevista

Las entrevistas tienen 4 fases durante su ejecución:
1. Identificación de Candidatos: Se identifican las personas a las cuales se va a entrevistar. Normalmente, el
primero en ser entrevistado es el que ha autorizado o patrocina el proyecto.
2. Preparación. Se prepara la entrevista. Para ello se confeccionan las preguntas a realizar, se agrupan por
temas y se les asigna un determinado tiempo a cada tema.
3. Ejecución de la Entrevista. La ejecución de la entrevista está formada por tres partes diferenciadas:
o Inicio: Se abre la sesión, se le explican al entrevistado los motivos y las nomenclaturas de diagramas
que se van a usar en la entrevista.
o Desarrollo de la Entrevista: Se realizan las preguntas que se llevan planificadas dentro del tiempo
asignado a cada una. Puede que a partir de una pregunta surjan nuevas para clarificar puntos que no
quedan claros o puntos nuevos que han aparecido durante la misma.
o Finalización de la Entrevista: La finalización es muy importante, pues en ella se resume, en 5 minutos
todo lo visto en la sesión, para que ambas partes estén de acuerdo. De todas formas hay que indicar
al entrevistado que la sesión se va escribir en papel y que se le enviará una copia al entrevistado, con
lo que se ha hablado, para que lo revise.
4. Actividades Posteriores a la Entrevista: Se procederá a hacer un acta de la entrevista, la cual se enviará
al entrevistado para que la revise y la confirme. La información que aparezca durante una entrevista debería
ser corroborada con otras fuentes diferentes para asegurarse de que es fidedigna y no representa
simplemente el punto de vista de un usuario, o incluso que se trata de una visión incorrecta que tiene el
usuario.

[Link].4.2. Tipos de Preguntas en una Entrevista

Las preguntas que se realizan durante una entrevista pueden ser de los diferentes tipos:
 Generales: Se emplean para establecer el contexto del sistema. Serán las primeras en usarse o cuando se
quiera entrar en un nuevo área diferente del que se estaba discutiendo. Son ejemplos:
“¿Qué se espera del sistema?”
“¿Cuáles son sus cometidos?”
 Abiertas: Este tipo de preguntas da pie a que el entrevistado hable y se explique, pudiéndose de dicha
explicación obtener nueva información o clarificar la ya existente. Estas preguntas permiten obtener mucha
información, aunque hay que saber controlar al interlocutor para que no se desvíe del tema principal. Ejemplo:
“¿Dígame qué tiene que hacer cuando se presenta dicha situación?”
 Cerradas: Este tipo de preguntas proporciona detalles sobre un determinado aspecto. En estas preguntas,
dependiendo de cómo se hagan, pueden causar que se lleve al entrevistado a corroborar nuestro punto de
vista. Ejemplo:
“¿qué fórmula se usa para calcular el índice de retraso?”
Si en vez de esta pregunta, se hace una pregunta como “y el índice de retraso lo calcula como ... ¿no?” puede
que llevemos al entrevistado a corroborar nuestro punto de vista, que puede que no sea el correcto o sea una
visión parcial de la situación.
 Preguntas que Elevan el Nivel. Son preguntas que se realizan para cambiar el nivel de abstracción de la
078.- El Análisis de Requisitos de los Sistemas de Información y de Comunicaciones 15
 Volumen 3. INGENIERÍA DE LOS SISTEMAS

misma. Así por ejemplo, si estamos analizando un tema con mucho detalle y queremos reducir el nivel de
detalle podemos usar una pregunta como:
“¿Cuál es el objetivo de eso?”
De esta forma pasaremos a ver el proceso como una caja negra y el entrevistado pasará a detallar los
objetivos del mismo.
 Preguntas de Contexto. Este tipo de preguntas permite cambiar el contexto del que se está hablando. Son
útiles para pasar de un tema a otro que no tiene relación. Es muy importante que el entrevistado se de cuenta
de que se ha hecho el cambio de contexto, para que se adapte al nuevo. Se debe evitar cambiar mucho de
contexto, y cuando se haga dejar bien claro cual es el nuevo contexto, para no confundir y desorientar al
entrevistado.

[Link].4.3. Recomendaciones en las Entrevistas

A continuación se muestran algunas recomendaciones a tener en cuenta a la hora de realizar una entrevista.
 La primera pregunta a una respuesta no es necesariamente completa o correcta. Se debe indagar más
mediante:
o El resumen de lo que se ha dicho.
o Reconstruyendo respuestas (reformulando la frase en palabras del entrevistador).
o Mostrando implicaciones.
 Hay que Saber Escuchar
o Contacto visual con e entrevistado.
o Se deben tomar notas, pero sin dejar de escuchar.
 Permitir realizar preguntas al entrevistado, pero sin perder el control de la entrevista.
 Ser amable y no estresar al entrevistado.
 Uso de técnicas de Comunicación No Verbal.
 Puede que se tengan que hacer más entrevistas. Con una sola entrevista no suele valer.

[Link].4.4. Errores Más Comunes

Dado que las entrevistas son una comunicación persona a persona, mediante el uso del lenguaje natural, esta
comunicación no está exenta de imprecisiones, ambigüedades, interpretaciones, etc. Es importante conocer los errores
que se pueden producir durante una entrevista para así detectarlos y resolverlos.
Es importante comprobar frecuentemente que el entrevistador entiende lo que el entrevistado dice. Se podrán usar
tácticas como frases de resumen o rehacer las respuestas para que el entrevistado nos confirme que hemos entendido
el punto de vista.
Los errores más comunes que se pueden presentar son:
 Errores de Observación: Distintas personas tienen una percepción distinta ante un mismo fenómeno.
 Errores de Recuerdo: Las personas recuerdan cosas erróneas aunque piensan que son verdaderas.
 Errores de Interpretación: La misma palabra tiene diferentes significados en un cierto contexto.
 Errores de Enfoque: Cada participante habla de un nivel diferente de abstracción.
 Ambigüedades del Lenguaje Natural
 Opiniones que se dan al entrevistado como hechos verdaderos
[Link].5. PIECES
PIECES es una técnica que define seis categorías de aspectos que el analista debe estudiar con los usuarios. El nombre
PIECES procede de un acrónimo formado por dichas 6 categorías, que son:
 Rendimiento (Performance)
 Información y Datos (Information)
 Economía (Economy)

078.- El Análisis de Requisitos de los Sistemas de Información y de Comunicaciones 16

 Volumen 3. INGENIERÍA DE LOS SISTEMAS

 Control (Control)
 Eficiencia (Efficiency)
 Servicios (Services)
PIECES define un conjunto de preguntas estándar para cada una de las categorías, las cuales están orientadas para la
obtención de requisitos.
Algunos de aspectos que PIECES evalúa para cada una de las seis categorías son:
 Rendimiento (Performance)
o Throughput (Número de sucesos por unidad de tiempo)
o Tiempo de Respuesta
 Información y Datos (Information)
o Datos útiles para la toma de decisión
o Acceso a la clase correcta de información, en el momento adecuado y cantidad justa
 Economía (Economy)
o Nivel de Servicio a ofrecer
o Exceso de Capacidad para soportar picos
 Control (Control)
o Seguridad
o Auditoría
 Eficiencia (Efficiency)
o Aprovechamiento de los recursos disponibles
 Servicios (Services)
o A los usuarios
o A los clientes
o A otros sistemas

78.03.6. Fuentes de Información para el Análisis de Requisitos

En general, las fuentes de información para realizar el análisis de requisitos son todas aquellas que existan en el
proyecto. Si bien es cierto que existe un conjunto más o menos estable de fuentes que son útiles consultar en un
proyecto genérico, también es cierto que para cada proyecto en particular es necesario que se determinen todas las
fuentes de información y se les preste el debido interés. Una fuente olvidada, o a la que no se le ha prestado todo el
interés que se debía, potencialmente puede hacer que el análisis de requisitos sea incompleto o incluso inconsistente o
que no representen debidamente a la realidad.
Las fuentes de información que siempre deberían considerarse a la hora de obtener información de requisitos son:
 Los documentos generados en fases previas al análisis de requisitos, como un estudio de viabilidad o un plan
de sistemas de información. En cualquiera de los dos casos, el sistema que se construya deberá estar alineado
con los conceptos que se expongan en estos documentos.
 Declaración de Necesidades del Cliente. Contiene en términos del cliente todo lo que éste necesita. No tiene
porqué ser un documento coherente, correcto, completo, etc. porque depende en gran medida de los
conocimientos del que lo escribe. Será labor del analista el determinar a partir de esta información qué quiere
el cliente y generar la Especificación de Requisitos. La declaración del cliente suele tener las siguientes
deficiencias:
o Incluir aspectos que no son importantes para el sistema.
o Describen aspectos ambiguos, que se pueden entender de diferentes formas.
o Incurren en el defecto de asumir ciertas características, que no explicitan en el documento pero dan
por supuestas que las tiene que tener el sistema.
o Incorporar directrices de cómo debe hacerse el diseño o la implantación.

078.- El Análisis de Requisitos de los Sistemas de Información y de Comunicaciones 17

 Volumen 3. INGENIERÍA DE LOS SISTEMAS

 Reuniones con el cliente, proveedores, etc.

 Documentación del sistema de información actual (tanto manual como automático)
 Código fuente del sistema,
 Reuniones con los usuarios para ver cómo trabajan, etc.
 Observación de los sistemas existentes
 Análisis de Tareas, Reingeniería de procesos de negocio
 Expertos en la materia
 Otros sistemas con los que hay conexión
 Legislación vigente y estándares a cumplir

78.03.7. Validación de Requerimientos

Según Sommerville, el principal objetivo de la validación de requerimientos es el de mostrar que éstos definen el
sistema que el cliente desea. La validación es una actividad muy importante ya que si existen errores en la
especificación y se construye el sistema con dichos errores, tras la construcción, el coste de corregirlos será mucho
mayor que si se detectan durante la validación de requisitos.
Las verificaciones que se llevan a cabo durante la validación son:
 Verificaciones de Validez. Se debe comprobar que los requerimientos de los usuarios describen lo que
realmente el usuario necesita. Muchas veces el usuario piensa que necesita una determinada funcionalidad
pero realmente, tras un concienzudo análisis, se identifica que necesita funcionalidades adicionales o incluso
diferentes. También se deben tener en cuenta que en un mismo sistema suele haber diferentes usuarios, con
diferentes puntos de vista, algunas veces contrapuestos, y que éstos deben llegar a un compromiso a la hora
de definir los requisitos del sistema.
 Verificaciones de Consistencia. Los requerimientos no deben contradecirse.
 Verificaciones de Completitud. Los requerimientos deben definir todas las funciones y restricciones
propuestas por el usuario del sistema.
 Verificaciones de Realismo. Se debe comprobar que los requerimientos se pueden implementar con la
tecnología existente en la actualidad.
 Verificabilidad. Los requisitos siempre deben ser redactados de forma que se puedan posteriormente
verificar, es decir, que se puedan construir un conjunto de pruebas de forma que se pueda determinar si se
cumple o no un cierto requisito. Este aspecto toma un valor clave cuando el contrato entre el cliente y el
desarrollador se basa en los requerimientos del sistema.
Existen varias técnicas para realizar la validación de los requerimientos. Algunas de ellas se realizan de forma individual
mientras que otras se hacen en grupo:
 Revisión de los Requisitos: Los requisitos son analizados sistemáticamente por un equipo de revisores.
o El grupo de revisores estará formado por personal del cliente y de los desarrolladores.
o Se buscarán omisiones y errores en los requerimientos.
o Se hace una revisión formal de los requerimientos, explicándose al cliente los requerimientos y las
implicaciones de cada uno.
o Los revisores deben:
 Comprobar la consistencia de cada requerimiento.
 Comprobar la completitud del conjunto de requerimientos.
 Comprobar la verificabilidad. ¿se puede probar el requerimiento de forma realista?.
 Comprobar la comprensibilidad. ¿Comprende el usuario correctamente el requerimiento?.
 Rastreabilidad. ¿está claramente establecido el origen del requerimiento?. Ante un cambio
puede que haga falta ir a la fuente del requerimiento para determinar si se debe cambiar o
incluso anular.
 Comprobar la Adaptabilidad. ¿Es adaptable el requerimiento?, es decir, ¿se puede éste
cambiar sin que afecte a otros requerimientos del sistema?

078.- El Análisis de Requisitos de los Sistemas de Información y de Comunicaciones 18

 Volumen 3. INGENIERÍA DE LOS SISTEMAS

o Durante la revisión formal se deben registrar formalmente, en un informe de revisión, los conflictos,
contradicciones, errores y omisiones que se identifiquen.
 Construcción de Prototipos: Se construye un prototipo del sistema en base a los requerimientos obtenidos.
Se le entrega al cliente para que pueda experimentar con él y determinar si es lo que necesita.
 Generación de Casos de Prueba: Los requerimientos deben poder probarse (ser verificables). Si se
intentan construir casos de prueba para probar los requisitos y los requisitos no son correctos, probablemente
se identifiquen problemas a la hora de construir los casos.
Es muy difícil hacer una validación de los requisitos del sistema. Para informáticos expertos en el desarrollo es difícil
hacer el modelo mental de todo el sistema en funcionamiento, pero hay que tener muy en cuenta que para los usuarios
sea probablemente mucho más difícil. Por estas razones se debe asumir que determinados errores se detectarán en
fases posteriores del desarrollo, aunque por lo menos, con estas comprobaciones se conseguirá detectar y corregir el
grueso de errores que puedan surgir.

78.04. Gestión de Requisitos

Es tan importante el realizar un buen análisis de requisitos como posteriormente realizar una buena gestión de los
cambios que puedan surgir en éstos. No sirve de nada haber confeccionado un análisis de requisitos perfecto si durante
el desarrollo del sistema estos van cambiando y no se van realizando las modificaciones adecuadas en el análisis de
requisitos y documentos que se hayan derivado de éstos.
Para garantizar que los requisitos son actualizados de forma coherente y consistente, y que se sigue un control en
realizar dicha actividad, es necesario que se defina en el proyecto un Procedimiento de Gestión de Requisitos, para que
todos los participantes conozcan cómo se deben gestionar.
La Gestión de Requisitos se encarga de el tratamiento y control de las actualizaciones y cambios en los requisitos. La
Gestión de Requisitos se realiza durante toda la vida del proyecto, no como el análisis de requisitos, que se hace al
principio. Durante el desarrollo, especialmente en el mantenimiento, aparecerán nuevas necesidades que generarán
nuevos requisitos, los cuales deberán integrarse con los requisitos existentes. Para poder realizar esta actividad es muy
importante la trazabilidad, es decir, la capacidad para poder relacionar dos o más requisitos, y así poder analizar el
impacto de un cambio.
La Gestión de Requisitos es una actividad esencial en un proyecto y que requiere recursos para su realización.

78.04.1. ¿Porqué hace falta tener un procedimiento?

A la hora de la gestión de requisitos mediante un procedimiento pueden surgir las siguientes preguntas:
 ¿Es estrictamente necesario tener un procedimiento para la gestión de los requisitos?. Quizás sea demasiado
esfuerzo para algo que no merece la pena.
 ¿Son los requisitos algo tan importante como para que se defina formalmente una forma de gestionarlos?
Como veremos en los siguientes puntos, los requisitos son un punto clave del desarrollo del sistema. Una mala
especificación o una especificación errónea puede llevar a construir un sistema que no sea usable, o como poco, que
requiera posteriormente modificaciones para adaptarlo a las necesidades reales. Por lo tanto, los requisitos son lo
suficientemente importantes como para requerir la definición de un procedimiento de gestión de los mismos.
 Los requisitos son normalmente el contrato entre el desarrollador y el cliente. En los requisitos se suele
especificar lo que el sistema va a hacer. Si tras construir el sistema, éste hace lo que dicen los requisitos, el
desarrollador cobra y se resuelve el contrato. Si por el contrario no se cumplen los requisitos, el desarrollador
debe dotar de recursos adicionales al proyecto para modificar las discrepancias.
 Los cambios en los requisitos son inevitables. Existen cambios en todos los aspectos del sistema durante el
desarrollo de este. Hay que pensar que un sistema grande requiere mucho tiempo de desarrollo, uno o dos
años no son unos plazos excesivamente grandes, pero en los cuales si que se pueden producir múltiples
cambios en las necesidades. Se pueden producir cambios durante el desarrollo por:
o Cambios en el negocio
o Cambios en la reglamentación / legislación
o Nuevas necesidades surgidas de un mejor conocimiento del sistema y de lo que se puede hacer con
él.
o Es imposible congelar los requisitos y continuar con el desarrollo. En ciertos modelos de ciclo de vida,
como en el modelo en cascada se hace, pero en la actualidad no es práctico.
o Etc.

078.- El Análisis de Requisitos de los Sistemas de Información y de Comunicaciones 19

 Volumen 3. INGENIERÍA DE LOS SISTEMAS

Por lo tanto es necesario controlar los cambios. Para hacerlo hace falta primero analizar el cambio, lo que comporta, la
necesidad, el impacto sobre el resto del sistema, etc. y determinar si es realmente interesante hacer el cambio
(aceptarlo o rechazarlo). Este análisis lo llevará a cabo un equipo creado específicamente para que realice la gestión de
dicho cambio de requisitos. Los cambios pueden implicar grandes modificaciones en los requisitos, por lo que si no se
controlan, aunque sean necesarios, pueden dar lugar a constantes modificaciones del sistema, sin lograr llegar a su
finalización. Los cambios que se hagan deben ser lo suficientemente justificados como para destinar esfuerzo adicional
a la realización de los mismos, posponiéndose el resto para futuras versiones del sistema, cuando éste ya esté estable
y el equipo de mantenimiento pueda acometerlos.
Por supuesto, para la gestión de los cambios de los requisitos se hace indispensable un procedimiento por el cual los
solicitantes de cada cambio puedan saber qué pasos hay que seguir para notificar el cambio, y que los que controlan
los cambios deban saber qué pasos dar si se aprueba o se pospone el cambio.
Una organización que gestione el cambio de los requisitos debería al menos garantizar que:
 Los cambios, a partir de su formalización, deberían comunicarse a todas las áreas y personas afectadas.
 Los cambios propuestos son evaluados y analizados sus impactos.
 Las personas que deban tomar decisiones sobre los cambios deben estar identificadas, nombradas, se deben
consideran las adecuadas y representan a toda las áreas afectadas.
 Todos los cambios aprobados, con impacto en el proyecto, deben estar reflejados en los documentos de
requisitos del mismo, y en los documentos del proyecto en que sea necesario.
 El proyecto incorpora cambios aprobados en los requisitos de una forma ordenada, disciplinada en función de
su prioridad e impacto.
 Los responsables del proyecto controlarán los cambios de requisitos durante toda la vida del proyecto.
 Las consecuencias de los cambios no se vuelven más graves conforme se va progresando en el desarrollo (es
decir, que el coste y las consecuencias no crecen exponencialmente en vez de proporcionalmente).

78.04.2. Procedimientos de Gestión de Requisitos

En cada organización se deberían definir un conjunto de procedimientos que permitan especificar de una forma clara
las diferentes actividades a realizar en lo referente a la gestión de los requisitos. A continuación se describen los
principales procedimientos que se deberían definir y las actividades a realizar. Dependiendo de la magnitud del
proyecto, de la magnitud de la organización, etc. estos procedimientos serán más o menos complejos.
 Control de Cambios
 Control de Versiones
 Trazabilidad de Requisitos
 Etc.
La ejecución de los procedimientos generan documentos que contendrán la descripción del cambio, motivo, etc. Esta
documentación se deberá guardar, incluso cuando se rechace el cambio, para poder volver a ella más adelante, quizás
cuando sea un momento más idóneo para incorporar el cambio, o simplemente para revisar porqué se rechazó un
determinado cambio.
[Link]. Control de Cambios
El control de cambios es un procedimiento que está formado por los siguientes pasos:
 Propuesta de Cambios. El afectado por un requisito que no le satisface debe rellenar un formulario de
propuesta de cambio indicando cual es el cambio que hay que realizar. Este cambio se remitirá al equipo de
gestión de requisitos para que lo estudie.
 Análisis de Impactos. La propuesta de cambio se evalúa para determinar el impacto del cambio en el resto
de los requisitos. Hay propuestas cuyo impacto es mínimo, y otras cuyo impacto hace que se deba modificar
una parte sustancial del sistema.
Además del impacto se deberá estudiar la oportunidad o necesidad del cambio. Ocurre muchas veces que a un
usuario no le parece bien un determinado aspecto del sistema pero a otros si les satisface. En estos casos se
debe llegar a un consenso entre todas las partes.
Otras veces el cambio es interesante pero se considera que no es oportuno hacerlo en dicho momento, quizás
porque se quiera lanzar el sistema cuanto antes o porque el cambio es considerable y sería mejor atacarlo en
una fase posterior de desarrollo.

078.- El Análisis de Requisitos de los Sistemas de Información y de Comunicaciones 20

 Volumen 3. INGENIERÍA DE LOS SISTEMAS

 Toma de Decisiones. Dependiendo del impacto, de la necesidad u oportunidad del cambio y de otras
cuestiones específicas que puedan surgir alrededor del cambio, se debe determinar si el cambio debe ser
realizado o no. Si se decide realizarlo se deben hacer las modificaciones pertinentes en el sistema para integrar
el cambio con el resto, empezando por los requisitos y finalizando por las partes más avanzadas del sistema.
Si por el contrario se decide no hacerlo se puede optar por dos soluciones:
o Rechazar el cambio, porque se considera que no tiene sentido.
o Posponer su realización para un futuro, se considera el cambio necesario pero el momento no es
oportuno. Se pospone para cuando se pueda acometer.
 Comunicación. Tanto si se acepta como si no, se debe notificar los efectos de la propuesta de cambio a todos
los afectados.
 Incorporación. Se hacen las modificaciones pertinentes que se identificaron en el análisis de impacto en los
diferentes elementos afectados por el cambio.
 Medición de la Estabilidad de los Requisitos. Se evalúan los parámetros que definen la estabilidad de los
requisitos tras las modificaciones que se hayan realizado.
[Link]. Control de Versiones
El control de versiones se encarga de mantener en todo momento una versión de los requisitos que sea correcta,
coherente y completa. Cuando los requisitos se aprueban, éstos han pasado todas las validaciones y forman un
conjunto completo, coherente y correcto. Una vez que se van haciendo cambios en los mismos, si la realización de
estos cambios no se controlan, y no se sabe si una determinada versión está completa o está siendo cambiada, es muy
probable que los desarrolladores se confundan y se basen en requisitos obsoletos.
Por esta razón es necesario definir lo que se denomina una línea base. Esta línea base constituye el marco de
referencia estable para el desarrollo del producto, conteniendo un conjunto de requisitos completo, coherente y
correcto.
IEEE define el concepto de línea base como una especificación o producto que ha sido revisado formalmente y sobre la
que se ha llegado a un acuerdo, y que de ahí en adelante sirve como base para un desarrollo posterior y que puede
cambiarse solamente a través de procedimientos formales de control de cambios.
Los desarrolladores se basarán en la línea base, que tiene las últimas versiones aprobadas de los requisitos. El hecho
de que la línea base sea una versión congelada de los requisitos no implica que estos no puedan cambiarse. Si un
requisito se quiere cambiar, se realizarán las modificaciones pertinentes y cuando ya estén finalizadas y aprobadas se
procederá a cambiarlo en la línea base. Acto seguido se notificará la existencia de una nueva línea base para que los
desarrolladores lo tengan en cuenta.
Las tareas más importantes en el control de versiones son las de controlar los documentos que se están usado para el
desarrollo. Para ello:
 Se empleará una herramienta automática de control de versiones para controlar todas y cada una de las
versiones de los documentos que se generen durante el desarrollo y mantenimiento del sistema. Se pueden
usar para ello herramientas como CVS, Subversion, PVCS, MS Source Safe, SCCS, etc. Algunas herramientas
son de software libre, como CVS o Subversion, mientras que otras como PVCS o MS Source Safe son de pago.
Cualquiera de estas herramientas permite llevar un control de la línea base, poder ver el histórico de
modificaciones de cada elemento controlado por el sistema y de obtener la última versión de un elemento.
Cuando varias personas quieren trabajar sobre un mismo elemento, éstas obtienen el de la línea base, realizan
sus modificaciones y según van terminando van integrando sus cambios en la versión de la línea base. Esta
versión de la línea base podrá ser la que ellos obtuvieron originalmente al empezar el cambio, o una diferente
que puede haber cambiado porque alguna otra persona ya haya incorporado antes sus cambios.
 Se debería poder acceder siempre a la última versión y a versiones anteriores de cada documento. De esta
forma, si se detecta un fallo en una versión de un documento es posible volver atrás y recuperar los datos
originales.
 Todos los cambios que se hagan deben documentarse y comunicarse a los afectados, para que todo el mundo
trabaje con la última versión. Es especialmente importante el indicar en cada nueva versión qué cambios sufre
respecto a la anterior, para evitar que tenga que revisarse el documento entero.
 Cada documento debería tener:
o Historia de revisiones que identifique los cambios realizados
o Fecha del cambio, responsable y motivos.

078.- El Análisis de Requisitos de los Sistemas de Información y de Comunicaciones 21

 Volumen 3. INGENIERÍA DE LOS SISTEMAS

[Link]. Trazabilidad de Requisitos

El concepto de trazabilidad hace referencia a la posibilidad de determinar cómo se ha llegado a un cierto elemento del
software a partir de otros. Para poder llevar a cabo esta trazabilidad es especialmente importante el poder relacionar
unos requisitos con otros y también relacionar requisitos con elementos del sistema a los que da lugar.
Se pueden dar dos tipos de trazabilidad:
 Hacia delante. Partiendo de un requisito se llega a todos los elementos que materializan dicho requisito.
 Hacia Atrás. Partiendo de un elemento del sistema se llega al requisito que lo generó.
Un requisito se debe poder relacionar con otros requisitos similares para así evitar repeticiones en los mismos, lo cual
facilita la actualización de los mismos. Además, cuando se hace un cambio en uno, es más fácil localizar aquellos
requisitos en los que hay relación, para ver el impacto del cambio.
Por otro lado, es útil poder relacionar un requisito con los elementos del sistema a los que éste da lugar. De esta
forma, si hay que cambiar un elemento del sistema, o simplemente, poder saber qué requisitos dieron lugar a un
determinado componente del sistema. Esta relación no sólo debe ser entre requisitos, sino también entre cualquier
elemento que se haya derivado posteriormente, ya sea del análisis, del diseño, de la construcción, de pruebas, etc.
Esta relación también permite poder hacer validaciones para comprobar que todos los requisitos del sistema dan lugar
a al menos una parte del sistema, y que todas las partes del sistema están basadas al menos en un requisito. Si esto
no se cumple, es porque o el requisito sobra, ya que no da lugar a ninguna parte del sistema, o en el otro caso, la
parte del sistema sobra porque no está soportada por ningún requisito.

78.04.3. El Comité de Control de Cambios

La gestión de los requisitos debe recaer en un equipo específico que se encargue, a tiempo parcial o completo, de
realizar las actividades asociadas a dicha gestión. El Comité de Control de Cambios, Comité de Control de Configuración
o también conocido como CCB o Change Control Board es el responsable de realizar dicha gestión. El constituir un CCB
es una buena práctica para el desarrollo del software y está recogido en todas las normas y estándares internacionales.
El CCB está compuesto por una o varias personas dependiendo del tamaño del proyecto o de la organización. Por la
misma razón, estas personas pueden estar a tiempo parcial o completo asignadas a dicha tarea. Debería estar
compuesto por representantes de todas las áreas implicadas en el sistema, que de una forma genérica podrían ser:
 Sistemas o grupo que defina el producto
 Marketing o representantes del cliente
 Gestión del Proyecto
 Desarrollo
 Pruebas
 Instalación y Soporte Técnico
 Aseguramiento de la Calidad
 Explotación
 Gestión de Configuración
El CCB es el órgano encargado de la toma decisiones, de aprobar o rechazar cambios en los requisitos, incorporar
nuevos requisitos y vigilar la implantación de los requisitos. El CCB también decide sobre los informes de incidencias
que se generan y cuando deben corregirse dichas incidencias.

78.05. El Análisis de Requisitos en Métrica versión 3

Métrica v3 dedica una actividad al análisis de requisitos, dedicando cuatro actividades adicionales para la modelización
del sistema. Dos de estas actividades se realizan cuando se usa una aproximación estructurada, las actividades de
confección del modelo de datos y modelo de procesos, mientras que las otras dos se usan con una aproximación
orientada a objetos, confeccionándose en este caso los casos de uso y el diagrama de clases. En esta explicación nos
centraremos en la parte correspondiente a la obtención y análisis de requisitos.
En la actividad “ASI 1. Definición del Sistema” se procede a definir el sistema, los límites de éste y los interfaces con
otros sistemas. Como parte de esta actividad se confecciona el catálogo de requisitos del sistema, para lo cual se
partirá del catálogo de requisitos que se identificó en la fase EVS de Estudio de la Viabilidad del Sistema. Este catálogo
de requisitos será el germen a partir del cual se generará en la actividad siguiente el catálogo de requisitos del
software.

078.- El Análisis de Requisitos de los Sistemas de Información y de Comunicaciones 22

 Volumen 3. INGENIERÍA DE LOS SISTEMAS

El Análisis de Requisitos propiamente dicho se lleva a cabo en la actividad “ASI 2. Establecimiento de Requisitos”. A lo
largo de esta actividad se lleva a cabo la definición, análisis y validación de los requisitos a partir de la información
facilitada por los usuarios. El objetivo principal de esta actividad es el de confeccionar un catálogo detallado de
requisitos.
Como técnica para ayudar a la obtención de requisitos se propone el uso de la técnica de Especificación de los Casos
de Uso, que es obligatoria para la aproximación orientada a objetos, pero que es opcional para el enfoque
estructurado.
La actividad “ASI 2. Establecimiento de Requisitos” se subdivide en cuatro tareas, que no requieren ser ejecutadas
estrictamente en un orden secuencial, sino que más bien se ejecutan de forma iterativa exigiendo continuas
realimentaciones y solapamientos.
Las cuatro tareas que se definen dentro de la actividad ASI 2 son las siguientes:
 ASI 2.1: Obtención de Requisitos. En esta tarea se realiza la obtención de los requisitos mediante
reuniones con los usuarios. Se definen las prioridades a los requisitos que se van obteniendo y se identifican los
diferentes casos de uso.
 ASI 2.2: Especificación de Casos de Uso. Se especifica cada caso de uso que se haya identificado. Es
opcional para el enfoque estructurado.
 ASI 2.3: Análisis de Requisitos. Se estudia la información capturada en las tareas anteriores en busca de
inconsistencias, duplicidades, ambigüedades, falta de información, etc. Además se analizan las prioridades
definidas por el usuario y se relacionan unos requisitos con otros. Mediante sesiones de trabajo, se contrastan
las conclusiones con los usuarios.
 ASI 2.4: Validación de Requisitos. Se comprueba junto con los usuarios que el catálogo de requisitos
generado y los casos de uso son válidos, consistentes y completos.
En la guía de técnicas y prácticas de Métrica v3 se incorporan un conjunto de técnicas para poder obtener unos buenos
resultados a la hora de realizar un análisis de requisitos. Técnicas como las entrevistas, factores críticos de éxito, casos
de uso, ya vistas anteriormente en este tema, son algunas de las técnicas descritas por Métrica v3 y usadas en esta
actividad de Análisis de Requisitos.
Como resumen se muestran en la siguiente tabla las tareas, productos, técnicas, prácticas y participantes de la
actividad.

Tarea Productos Técnicas y Prácticas Participantes

ASI 2.1 Obtención de  Catálogo de Requisitos  Sesiones de Trabajo  Usuarios Expertos
Requisitos  Modelo de Casos de Uso  Catalogación  Analistas
 Casos de Uso
ASI 2.2 Especificación de  Catálogo de Requisitos  Sesiones de Trabajo  Usuarios Expertos
Casos de Uso  Modelo de Casos de Uso  Catalogación  Analistas
 Especificación de Casos  Casos de Uso
de Uso
ASI 2.3 Análisis de  Catálogo de Requisitos  Sesiones de Trabajo  Usuarios Expertos
Requisitos  Modelo de Casos de Uso  Catalogación  Analistas
 Especificación de Casos  Casos de Uso
de Uso
ASI 2.4 Validación de  Catálogo de Requisitos  Sesiones de Trabajo  Usuarios Expertos
Requisitos  Modelo de Casos de Uso  Catalogación  Analistas
 Especificación de Casos  Casos de Uso
de Uso

78.06. Herramientas para el Análisis de Requisitos

El Análisis de Requisitos es una tarea que se ve enormemente facilitada si se emplean herramientas que permiten
automatizar las tareas más costosas, como por ejemplo, las comprobaciones. Si bien es cierto que las herramientas en
esta área tienen un coste elevado, las ventajas que éstas ofrecen son también muchas.
Por supuesto, el tamaño del proyecto es un factor crítico a la hora de determinar si se va a emplear una herramienta
de análisis de requisitos o se va a realizar la gestión a “mano”, con una hoja de cálculo, base de datos, documento de
procesador de texto, etc. Además, en un proyecto pequeño, con un analista y una duración corta, para desarrollar un
sistema pequeño, con una herramienta de análisis de requisitos probablemente genere más sobrecarga que los
beneficios que aporte.
 Se puede plantear el uso de una herramienta para el Análisis de Requisitos para proyectos grandes, ya que en
078.- El Análisis de Requisitos de los Sistemas de Información y de Comunicaciones 23
 Volumen 3. INGENIERÍA DE LOS SISTEMAS

dichos proyectos facilita la gestión y la colaboración entre los diferentes participantes.

 Antes de decantarse por una herramienta es importante el analizar las herramientas del mercado para ver
cómo funcionan y si su filosofía de funcionamiento se adapta a la organización. Estas herramientas suelen ser
caras, por lo que probablemente, la adquisición sólo se justifique para proyectos muy grandes.

78.06.1. Aportaciones de las Herramientas de Análisis de Requisitos

No hay duda de que el uso de herramientas que automaticen el proceso de Análisis de Requisitos es una gran ayuda,
tanto para mejorar la calidad de los resultados como la productividad. En los próximos apartados se va a ver la
funcionalidad que éstas aportan al proyecto y algunos ejemplos de herramientas comerciales que están en uso en la
actualidad.

78.06.2. Funcionalidades de las Herramientas

Las principales funcionalidades que permiten las herramientas de Análisis de Requisitos son los siguientes:
 Gestión de la Información de los requisitos. Permiten gestionar toda la información asociada a los
requisitos. No sólo el nombre y descripción sino otros aspectos como quién ha modificado qué en qué
momento, anexar documentos, etc.
 Gestión de versiones y cambios. Permiten llevar una gestión de versiones y un control de cambios.
Soportan el procedimiento de gestión de requisitos, para que diferentes participantes en el proyecto puedan
todos trabajar a la vez sin interferirse.
 Facilitar el análisis de impactos. Con la automatización de la trazabilidad permiten determinar qué
requisitos pueden verse afectados al modificar un cierto requisito.
 Seguimiento del Estado de Requisitos. Permiten hacer un seguimiento del estado en que se encuentra
cada requisito, permitiendo confeccionar listados en función del estado de los requisitos, para determinar los
que están todavía sin completarse y poder trabajar sobre ellos.
 Control de Permisos de Acceso. Permiten definir una estrategia de control de accesos para que diferentes
usuarios puedan trabajar en el mismo proyecto sin que se interfieran.
 Informar a los Afectados. Permiten determinar quién está trabajando sobre qué elemento de forma que si
se requiere hacer modificaciones sobre un elemento que alguien está usando se le pueda notificar que ha
habido cambios, para que se pueda actuar en consecuencia.
 Facilidad de Traza. Permiten automatizar las operaciones de trazabilidad, generación de matrices de
trazabilidad, etc.

78.06.3. Ejemplos de Herramientas de Análisis de Requisitos

Existen numerosas herramientas en el mercado. En este apartado vamos a estudiar las principales características de
tres de ellas:
 RequisitePro de IBM - Rational
 Borland Caliber de Borland
 ARTS (Analyst Real Team System) de Goda Software
En la dirección de Internet [Link] puede consultarse una amplia lista de herramientas.
[Link]. RequisitePro de IBM – Rational
RequisitePro es la herramienta que IBM-Rational ofrece para el análisis y gestión de requisitos. Esta herramienta tiene
como características principales las siguientes:
 Ofrece integración con Microsoft Word. Los requisitos son almacenados en una base de datos pero para
definirlos se usa el soporte de Microsoft Word, que es mucho más potente. Para ello, RequisitePro enlaza los
documentos Word a una base de datos.
 Es adaptable a las necesidades del Cliente.
 Soporta trazabilidad y análisis de coberturas.
 Permite realizar análisis detallados de impacto frente a cambios.
 Permite la comunicación de los diferentes afectados frente a cambios en los requisitos.
 Permite la creación y comparación de distintas líneas base.

078.- El Análisis de Requisitos de los Sistemas de Información y de Comunicaciones 24

 Volumen 3. INGENIERÍA DE LOS SISTEMAS

 Proporciona acceso web para equipos que se encuentren de forma distribuida.

 Ofrece herramientas para generar informes que son configurables a las necesidades de la organización.
 Ofrece herramientas configurables de importación.
 Se integra con múltiples herramientas de IBM Rational para el desarrollo de software.
 Permite plantillas predefinidas de proyectos, para ser directamente usadas.
[Link]. Borland Caliber DefineIT y Borland Caliber Requirements Management de Borland
Borland ofrece dos herramientas para la gestión de requisitos:
 Borland Caliber DefineIT: Permite definir los requisitos desde el comienzo del análisis de requisitos. La
herramienta permite que tanto los analistas como los usuarios puedan colaborar para capturar los requisitos del
sistema, de una forma sencilla, mediante la definición de escenarios. Esta herramienta soporta los cuatro
procesos de la definición de requisitos:
o Educción
o Análisis
o Especificación
o Validación
 Borland Caliber RM (Requirements Management): Esta herramienta está orientada a la gestión de los
requerimientos durante todo el proceso de desarrollo del software. Las principales funcionalidades de esta
herramienta permiten:
o Repositorio Centralizado de requisitos
o Herramienta adaptable para ajustarse a las necesidades del proceso de gestión de requisitos que esté
implantado en la organización.
o Permite la trazabilidad de los requisitos a lo largo de todo el ciclo de vida de la aplicación.
o Análisis de Impacto en Tiempo Real. Permite múltiples métodos de visualización de la trazabilidad
para poder ver inmediatamente el impacto de un cambio.
[Link]. ARTS (Analyst Real Team System) de Goda Software
ARTS ofrece un conjunto de herramientas de modelado para el desarrollo de sistemas que permite realizar tareas como
el modelado de casos de uso, casos de prueba, definición de reglas de negocio, detección de errores, definición de
tareas a realizar, etc.
ARTS permite la generación de la documentación del proyecto de forma automática a partir de la información
introducida en el sistema, permitiendo definir el formato de salida de la misma.
La interfaz de acceso a la herramienta es vía web con lo que facilita el acceso de todos los participantes en el proyecto
a la misma.
Por último, ARTS ofrece herramientas de gestión de la configuración como el bloqueo de elementos, creación de líneas
base, etc y es configurable para modelos de proceso que sean tanto ágiles como no ágiles.

078.- El Análisis de Requisitos de los Sistemas de Información y de Comunicaciones 25