UNIDAD 6

EL PROCESO DE ANÁLISIS

6. EL PROCESO DE ANÁLISIS ...................................................................... 1

6.1. OBJETIVO DEL ANÁLISIS ................................................................. 2
6.2. OBJETIVOS SECUNDARIOS DEL ANÁLISIS ........................................ 4
6.3. DINÁMICA DEL ANÁLISIS ................................................................ 5
6.4. CLASIFICACIÓN, O ANOTACIÓN, DE REQUISITOS ............................ 6
6.5. MÉTODOS DÉBILES DE ANÁLISIS ..................................................... 6
6.5.1. CHECKLIST DE ANÁLISIS ....................................................... 6
6.5.2. PROBLEMAS EN LA APLICACIÓN DEL CHECKLIST DE
ANÁLISIS ......................................................................................... 7
6.5.3. MATRIZ DE INTERACCIÓN ..................................................... 8
6.5.4. PROBLEMAS EN LA APLICACIÓN DE LA MATRIZ DE
INTERACCIÓN .................................................................................. 9
6.5.5. IDENTIFICACIÓN DE LOS USUARIOS RELEVANTES ............... 10
6.6. MODELADO CONCEPTUAL ............................................................ 11
6.7. NEGOCIACIÓN Y RESOLUCIÓN DE CONFLICTOS ............................ 12

El análisis es una actividad situada entre dos actividades extremadamente importantes del proceso
de requisitos: la educción, donde los requisitos son identificados, y la documentación, donde los
requisitos se plasman en un documento denominado Especificación de requisitos del software.

Si el proceso de requisitos se desarrollara sin error alguno, sería esperable que todos los requisitos
educidos pasasen a formar parte del documento de especificación de requisitos. Asimismo, dichos
requisitos deberían coincidir con la totalidad de requisitos del software, y éstos deberían ser
correctos, de tal modo que dichos requisitos pudieran ser usados en los posteriores procesos de
validación y diseño.

Obviamente, la ejecución del proceso de desarrollo dista de ser perfecta. Como ya se ha indicado en
la UNIDAD 3, durante la actividad de educción tienen lugar tres categorías principales de
problemas que afectan a la correcta definición de los requisitos: problemas de adquisición,
compresión y volatilidad [Valusek and Fryback 1987][Christel and Kang 1992]. Ello provoca que
no todos los requisitos educidos sean correctos (e, incluso, con mucha frecuencia ni siquiera dichos
requisitos son realmente requisitos), así como que no se eduzcan la totalidad de los requisitos del
software.

El Análisis de Requisitos aparece, por consiguiente, como una actividad fronteriza cuyo objetivo es
asegurar la calidad de los requisitos educidos antes de que éstos pasen a formar parte del
documento de especificación. La sección 6.1. tratará más ampliamente este particular.

Además de asegurar la calidad de los requisitos, el análisis persigue otros objetivos secundarios,
tales como precisar los límites del sistema software, precisar la interacción sistema-entorno,
trasladar los requisitos del usuario a requisitos del software y, finalmente, anotar los requisitos. Ello
se describirá más ampliamente en la sección 6.2.

Asignatura: Análisis de requisitos 1

Para la consecución de los objetivos del análisis, deben realizarse diversas tareas, descritas en las
secciones 6.3 y siguientes: anotar los requisitos, aplicar los métodos débiles de análisis (checklist de
requisitos, matriz de interacción) y, finalmente y si es necesario, aplicar métodos más fuertes de
análisis, como son los modelos conceptuales.

Finalmente, es necesario indicar que, en algunas ocasiones, durante el análisis se detectan requisitos
contradictorios. Dichas contradicciones surgen de las distintas visiones que los usuarios poseen del
sistema. En esta situación, no existe ningún tipo de tarea técnica que permita eliminar las
contradicciones, sino que es necesario acudir a los usuarios y negociar con ellos qué requisitos debe,
o no, implementarse. Ello se comentará en la sección 6.7.

6.1. Objetivo del análisis

El objetivo del análisis es asegurar la calidad de los requisitos. Por suerte, éste es uno de los
aspectos mejor definidos del proceso de requisitos, aunque ello no signifique en modo alguno que
alcanzar una calidad adecuada sea fácil de conseguir.

Básicamente, un conjunto de requisitos posee una calidad adecuada cuando cumplen con una serie
de criterios, o poseen una serie de atributos, de calidad, tales como: ambigüedad, completitud,
corrección, comprensibilidad, verificabilidad, realizabilidad, redundancia, etc. El motivo de referir
la calidad global de los requisitos a una serie de criterios o atributos es clara: De este modo, es
posible descomponer la calidad global en pequeñas piezas, más manejables, y, en caso de que exista
alguna carencia (por ejemplo, los requisitos son ambiguos, o están incompletos) actuar sobre dicho
aspecto específico (la ambigüedad, la completitud), sin preocuparse de los demás atributos de
calidad.

Nótese, en cualquier caso, que los atributos de calidad no son aspectos dicotómicos. Por ejemplo,
para el requisito cualquiera ‘A’, y un atributo de calidad cualquiera, tal como ‘ambigüedad’, dicho
requisito A no tiene por qué ser únicamente ‘ambiguo’ o ‘no ambiguo’. Muy al contrario, A puede
ser más o menos ambiguo. Lógicamente, cuanto menos ambiguo sea A, mayor calidad posee este
requisito, pero es impensable conseguir una ambigüedad del 0% (o una calidad del 100%). Lo
mismo ocurre con los restantes atributos de calidad.

La lista de atributos de calidad es larga y puede variar entre autores. Una revisión bastante
exhaustiva de los atributos de calidad, descritos en el IEEE-Std-830-1998 puede encontrarse en la
UNIDAD 10.

Durante el análisis, el concepto de calidad es exactamente el mismo que el indicado anteriormente,

aunque por razones prácticas el número de atributos a considerar es menor1. Concretamente, los
atributos considerados son típicamente los siguientes (una definición más formal y completa de los
atributos que siguen está disponible en la UNIDAD 10):

1
Ello se debe a que existen ciertos atributos de calidad que no pueden considerarse durante un momento del
proceso de requisitos tan temprano como es el análisis. Por ejemplo, siempre es posible verificar la
ambigüedad en la descripción de un requisito, independientemente del momento en que se realice. No
obstante, no es posible realizar lo mismo, por ejemplo, con la completitud. Ello se debe a que para determinar
la completitud de un conjunto de requisitos: 1) se debería disponer de un documento de especificación
completo, hecho que no es posible durante el análisis y 2) se debería tener acceso a los clientes/usuarios, lo
cual tampoco es siempre cierto.

Asignatura: Análisis de requisitos 2

 • Independencia del diseño. Este atributo hace referencia al hecho de que los requisitos no
deben incluir consideraciones de diseño. Por consideración de diseño, debe entenderse
cualquier aspecto que indique como debe implementarse el sistema software, por ejemplo:
intercambio de mensajes entre objetos, mecanismos de sincronización entre procesos, etc.
Los atributos que no son independientes del diseño son de baja calidad, debido a que
limitan el rango de opciones de implementación.
• Redundancia. Un conjunto de requisitos es redundante cuando dos o más requisitos se
refieren al mismo aspecto del software. Por ejemplo, los requisitos ‘El sistema debe generar
facturas’ y ‘Las facturas se generarán mensualmente’ son redundantes, porque se refieren al
mismo aspecto del sistema (la generación de facturas). La redundancia no es deseable,
debido a que puede causar defectos en la especificación en caso de que sea necesario
modificar los requisitos.
• Concisión. Un requisito, o un conjunto de requisitos, es conciso si están expresados de la
forma más simple posible. Por ejemplo, el requisito ‘El sistema generará albaranes y
facturas’ no es conciso, porque mezcla dos requisitos simples (la generación de albaranes y
la generación de facturas). Asimismo, el requisito ‘El sistema generará facturas el primer
día laborable de cada mes, debido a que los clientes deben recibir las facturas antes del día
5’ no es conciso, ya que añade un detalle innecesario para la implementación del futuro
sistema software. Es deseable que los requisitos sean lo más concisos posible, siempre y
cuando dicha concisión no perjudique la consecución de otros atributos de calidad, como
por ejemplo la ambigüedad.
• Realizabilidad. Un requisito es realizable cuando puede implementarse con la tecnología
disponible. Por citar un ejemplo, si se dispone de una conexión MODEM entre dos puntos,
no se puede exigir que el ancho de banda sea de 128KBPS. Debe intentarse que todos los
requisitos sean realizables para evitar tener que invertir en tecnología no existente.
• Internamente consistente. Un conjunto de requisitos es internamente consistente si no
existen contradicciones entre ellos. Por ejemplo, los requisitos ‘El sistema generará las
facturas quincenalmente’ y ‘El sistema generará las facturas mensualmente’ son
inconsistentes. Un conjunto de requisitos debe ser internamente consistente, ya que en otro
caso no sería posible implementar el sistema software.
• Externamente consistente. Un conjunto de requisitos es externamente consistente si no
existen contradicciones entre ellos y otros documentos, tales como políticas u objetivos
empresa. Es deseable que los requisitos sean externamente consistentes, para evitar
negociaciones posteriores.
• Ambigüedad. Un requisito es ambiguo cuando puede entenderse de formas diversas. Por
ejemplo, el requisito ‘El sistema tendrá la máxima disponibilidad’ es ambiguo, porque el
concepto de ‘máxima disponibilidad’ no está claro. Un requisito mucho menos ambiguo
sería ‘El sistema tendrá una disponibilidad de 23h/día’. La ambigüedad de los requisitos es
muy perniciosa, porque produce que la implementación del sistema software no sea la
deseada por los clientes/usuarios.
• Verificabilidad. Un requisito es verificable cuando un test puede determinar su existencia
en el producto software final. Por ejemplo, el requisito ‘El sistema debe funcionar bien’ es,
además de ambiguo, no verificable, porque no es posible diseñar una prueba o test que
indique que el sistema funciona bien. Si sería verificable, por el contrario, el requisito ‘El
sistema debe soportar 50 transacciones por minuto’. Los requisitos no verificables son
tremendamente perniciosos, porque pueden conducir a discusiones acerca de si el sistema
software implementado cumple o no con los requisitos del software establecidos en el
documento de especificación.

Asignatura: Análisis de requisitos 3

6.2. Objetivos secundarios del análisis

Tal y como se ha indicado anteriormente, la actividad de análisis tiene como objetivo asegurar la
calidad de los requisitos, ello mediante la detección y resolución de las carencias que se detecten en
los requisitos respecto a los atributos de calidad indicados en la sección 6.2. Adicionalmente,
durante esta actividad:

• Se precisan los límites del sistema software y su interacción con el entorno. Ello
significa que, a medida que se conocen y comprenden mejor los requisitos del software,
queda progresivamente claro qué funcionalidades se deben implementar y cuáles no (esto
es, los límites del sistema). De igual forma, al definir adecuadamente los límites del
sistema, también se aclara cómo el sistema software debe interaccionar con su entorno
(datos recibidos y generados, protocolos de comunicación, interfaces, etc.).
• Se trasladan los requisitos de usuario a requisitos del software. Éste es un aspecto del
análisis no universalmente aceptado. Por requisitos del usuario, deben entenderse los
requisitos del modo en que los usuarios los formulan. Todos los ejemplos aportados hasta
el momento pertenecen a esta categoría. Los requisitos del software, en contraste con los
requisitos del usuario, están más completa y correctamente definidos.
Por ejemplo, el requisito ‘El sistema deberá generar facturas’ es claramente un requisito del
usuario. Éste mismo requisito, más correctamente formulado (esto es, como requisito del
software), sería como sigue:

- El sistema deberá generar facturas.

- Las facturas se generarán mensualmente.
- El formato de la factura será el indicado en el apéndice X.
- Los pedidos facturados serán marcados como ‘Facturado’, para evitar su re-
facturación posterior.
- Por cada factura generada, se creará un registro de cobro en estado
‘Pendiente’.

La transformación de los requisitos del usuario en requisitos del software ocurre

naturalmente durante el análisis. Esto es: a medida que los requisitos van siendo revisados
y estudiados, los analistas los transforman a formulaciones más precisas, con la finalidad
de que reflejen mejor el comportamiento deseado del sistema.

• Se anotan los requisitos. Este es un tema más técnico. Anotar, o clasificar, los requisitos
significa asignar a éstos ciertos valores, de tal modo que se facilite la gestión posterior de
dichos requisitos. Existen múltiples tipos de anotaciones de requisitos, aunque las única
obligadas son:
o Identificación: A cada requisito debe asignarse un identificador único. Este
identificador facilitará sobre todo la trazabilidad. A este respecto, véase la
UNIDAD 12.
o Versión. A cada requisito debe asignarse un identificador único de versión. Ello
también facilitará la trazabilidad, así como el control de versiones (gestión de
configuración).
Anotar por identificación y versión es tan sencillo como asignar un valor numérico (1, 2,
...) a cada requisito. Obviamente, otras muchas opciones de anotación son igualmente
posibles.

Asignatura: Análisis de requisitos 4

 Además de las indicadas, las siguientes anotaciones pueden ser adecuadas en distintos tipos
de proyectos:
o Importancia. Por importancia, debe entenderse la importancia que los usuarios
asignan a cada requisito. Existen varias escalas de valores para esta anotación,
aunque la más típica es la (alta, baja). La anotación por importancia es importante
cuando se debe limitar el conjunto de requisitos a implementar, ya que permite
seleccionar un subconjunto estable de los mismos2.
o Prioridad. La prioridad es similar a la importancia. Por prioridad, debe entenderse
cuánto de necesario cree el cliente que es cada requisito. Valores usuales para esta
anotación son: (alta, baja).
o Estabilidad. Por estabilidad, debe entenderse la probabilidad de que el requisito
cambie con el tiempo. Valores usuales para esta anotación son: (alta, baja).

6.3. Dinámica del análisis

A diferencia de la educción de requisitos, la actividad de análisis posee una cierta estructura interna
mostrada en la Figura 1. Nótese que, en la Figura 1, la Lista preliminar de requisitos es el producto
resultante de la educción.

Modelado
conceptual

Lista
preliminar Métodos
de Anotación
débiles
requisitos

Figura 1. Proceso de análisis

Las tareas de las que se compone el análisis son las siguientes:

• Anotación de los requisitos.

• Aplicación de los métodos débiles de análisis. Los métodos débiles de análisis son un
conjunto de técnicas simples que permiten comprobar rápidamente la calidad de los
requisitos obtenidos durante la educción. Las técnicas más utilizadas son el checklist de
análisis y la matriz de interacción.
• Finalmente y en tercer lugar, si la complejidad del sistema software lo aconseja, es posible
utilizar el modelado conceptual para comprobar la calidad general de los requisitos del
software.

2
Lo mismo sucede con el resto de las anotaciones.

Asignatura: Análisis de requisitos 5

A estos tres aspectos se dedican las secciones siguientes.

6.4. Clasificación, o anotación, de requisitos

Como ya se ha indicado en la sección 6.2, anotar los requisitos significa asignar a éstos ciertos
valores de importancia, prioridad, etc., de tal modo que se facilite la gestión de requisitos posterior.
A efectos prácticos, la anotación se realiza en tres fases:

• Anotar los requisitos por identificación y versión. El analista debe realizar esta
anotación en todos los proyectos de desarrollo, debido a su importancia para la trazabilidad
y el control de versiones. Ambos aspectos se describirán en la UNIDAD 12.
• Decidir qué tipos de anotación suplementaria son necesarios. En muchos casos, las
características del proyecto no exigen anotaciones suplementarias. Por ejemplo, si todos los
requisitos está bien determinados y todos ellos van a implementarse, es ocioso anotar por
importancia o estabilidad. No obstante, en otros casos, realizar anotaciones suplementarias
puede ser vital para el éxito del proyecto. De nuevo, en la UNIDAD 12, se realizarán
algunas referencias a este respecto.
• Realizar las anotaciones suplementarias. Estas anotaciones deben ser realizadas por el
analista con el concierto de los clientes y usuarios. De hecho, en la mayoría de las
ocasiones, los valores de las anotaciones suplementarias se obtienen durante la misma
actividad de educción.

6.5. Métodos débiles de análisis

Existen, principalmente, dos métodos débiles de análisis: el checklist de análisis y la matriz de

interacción. La denominación de métodos débiles surge del hecho de que, al contrario que los
modelos conceptuales, aquellos son válidos en todo tipo de sistema software y configuración de
proyecto. Esto es, los métodos débiles pueden usarse siempre, mientras que los modelos
conceptuales, dependiendo del tipo de sistema, pueden ser más o menos útiles.

6.5.1. Checklist de análisis

Un checklist de análisis es, simplemente, un conjunto de preguntas que el analista debe considerar
para cada requisito individual. Estas preguntas están relacionadas con alguno de los siguientes
atributos de calidad:

• Independencia del diseño

• Concisión
• Realizabilidad
• Externamente consistente
• Ambigüedad
• Verificabilidad

Asignatura: Análisis de requisitos 6

El propósito del checklist es asegurar que el analista ha descrito adecuadamente cada requisito de la
lista preliminar de requisitos. En caso de que el analista detectase alguna carencia, éste debería
corregir el requisito defectuoso de forma inmediata.

Para la aplicación de este método débil, existen algunos (pocos) checklists predefinidos. La Tabla 1
muestra un checklist propuesto en [Kotonya and Sommerville, 1998] y que puede ser útil en una
gran diversidad de proyectos.

Finalmente, es necesario indicar que, a medida que el analista gana en experiencia, éste acostumbra
a redactar de una forma bastante adecuada la lista preliminar de requisitos, por lo que no es posible
detectar carencias en los requisitos con checklists como el mostrado en la Tabla 1. En este caso, es
necesario utilizar modelado conceptual o, alternativamente, utilizar la estrategia indicada en la
sección 6.5.2.

Atributo de calidad a
Pregunta
considerar
• ¿La lista de requisitos anticipa el diseño o incluye información de
Independencia del diseño
implementación?
• ¿Cada requisito es simple o, por el contrario, podría dividirse en varios
requisitos?
Concisión
• ¿Existe algún requisito que no parezca añadir ninguna información útil acerca
del sistema a desarrollar?
• ¿Es realizable el requisito en la plataforma de implementación?
• ¿Existe algún requisito irrealizable con la tecnología actual?
Realizabilidad
NOTA: Para responder a esta pregunta, es necesario conocer los aspectos técnicos
de la plataforma donde se implementará el sistema.
• ¿Existe algún requisito que contradiga requisitos organizativos explícitamente
Consistencia externa
formulados?
Ambigüedad • ¿Es posible interpretar de varias formas un requisito?
• ¿Es posible idear algún caso de prueba que permita establecer que el requisito
Verificabilidad
NO SE CUMPLE?

Tabla 1. Checklist de análisis

6.5.2. Problemas en la aplicación del checklist de análisis

El problema más común que surge durante la utilización de los checklist de análisis es la
imposibilidad de localizar defectos en los requisitos. Esto sucede cuando el analista aplica el
checklist, pero no detecta ningún requisito defectuoso.

Lo anterior puede estar motivado por dos factores: (1) el analista posee mucha experiencia y ha
confeccionado adecuadamente la lista preliminar de requisitos y, lo que es más probable, (2) el
analista no es capaz de descubrir defectos en la lista preliminar de requisitos por que ha sido él
mismo el que la ha confeccionado.

Existe una máxima bastante antigua de la validación del software, y dice más o menos que una
persona no puede probar un programa que él mismo ha construido. Con los requisitos sucede

Asignatura: Análisis de requisitos 7

exactamente lo mismo: no es eficaz, en muchas ocasiones, intentar localizar defectos en los
requisitos escritos por uno mismo.

En estas circunstancias, lo mejor es que el checklist de análisis sea aplicado por una persona distinta
que el analista que confeccionó la lista preliminar de requisitos (un compañero de trabajo, por
ejemplo). Ésta otra persona tendría dos responsabilidades:

• Localizar defectos en los requisitos

• Comunicar estos defectos al analista, junto con sugerencias acerca de cómo solucionar
dichos defectos

Esto es, la persona que aplica el cheklist tiene la responsabilidad de identificar errores y
comunicárselos al analista, pero no la de corregirlos por sí mismo. Muy al contrario, esta es
responsabilidad del analista, dado que es el que mejor conoce el sistema software a desarrollar. Los
errores y las sugerencias de solución acostumbran a plasmarse en un documento como el mostrado
en la Tabla 2, denominado Lista de errores y acciones recomendadas.

Nº de Defectos detectados Acciones recomendadas

requisito
1 Error de estilo, que lleva a Modificar el texto del requisito de tal forma que diga algo
ambigüedad como “El sistema deberá permitir el registro de los fondos
bibliográficos”
2 Idem Idem
11 Ambigüedad Precisar la duración de las reservas
12 Concisión No se han identificado diferencias entre profesores y
alumnos a todo lo largo de la lista de requisitos. Este
requisito se debería eliminar, ya que proporciona ningún
tipo de información relevante.
15 Realizabilidad El sistema no puede realizar automáticamente los
préstamos. Quizás se refiere el requisito a que debe
proporcionar el máximo de automatización? Precisar, en
este caso, o eliminar por irreal.
17 Concisión Separar lo referido a libros prestados de lo referido a libros
reservados.

Tabla 2. Lista de errores y acciones recomendadas

6.5.3. Matriz de interacción

Una matriz de interacción es, simplemente, una matriz de doble entrada donde se cruzan todos los
requisitos entre sí, tal y como muestra la Tabla 3. Por cruzar, debe entenderse que para cualesquiera
dos requisitos r1 y r2, se debe comprobar si:

• r1 se solapa con r2, esto es, r1 trata aspectos del sistema también tratados en r2. Ello, de ser
cierto, daría lugar a problemas de redundancia. Esto es lo que se ha indicado con una S en la
Tabla 3.

Asignatura: Análisis de requisitos 8

 • r1 está en conflicto con r2, esto es, r1 y r2 son contradictorios. Ello, lógicamente, da lugar a
problemas de consistencia interna. Esto es lo que se ha indicado con una C en la Tabla 3.

r1 r2 ... rn
r1 C
r2 S
...
rn

Tabla 3. Matriz de interacción

En el caso de que dos requisitos r1 y r2 estén solapados, la solución es simple: Dado que se puede
producir un problema de redundancia, el analista debe condensar los requisitos r1 y r2 en un nuevo
requisito r1+2, que refleje los contenidos de los requisitos r1 y r2. Condensar los requisitos de este
modo es interesante, ya que produce un efecto positivo aparte de la disminución de redundancia: los
requisitos tienden a dejar de expresarse como requisitos de usuario y se describen como requisitos
del sistema.

Reutilizando el ejemplo usado en la sección 6.1, los requisitos ‘El sistema deberá generar facturas’
y ‘Las facturas deberán generarse mensualmente’ están solapados (tratan el mismo aspecto del
sistema) y, por lo tanto, producen redundancia. Al mismo tiempo, ambos están expresados
claramente como requisitos de usuario.

Para eliminar la redundancia producida por los requisitos anteriores, es necesario condensar éstos.
El resultado podría ser el siguiente:

- El sistema deberá generar facturas.

- Las facturas se generarán mensualmente.

Obviamente, lo anterior está expresado claramente como un requisito del software.

En el caso de que dos requisitos r1 y r2 estén en conflicto, la solución es más compleja. Salvo que el
conflicto resida en algún problema de expresión, o algún defecto de orden menor en la lista
preliminar de requisitos, lo más probable es que su origen esté en conflictos en la concepción del
sistema software por parte de los usuarios. Este tipo de defecto no puede ser resuelto por el analista
en solitario: éste deberá acudir a los usuarios que han generado el conflicto y negociar con ellos
hasta que el conflicto se resuelta, tal y como se indica en la sección 6.7.

6.5.4. Problemas en la aplicación de la matriz de interacción

Existen tres problemas principales en la aplicación del método de la matriz de interacción.

• El ya mencionado en la sección 6.5.2, acerca de la imposibilidad del analista de verificar

sus propias creaciones. La solución, en este caso, sería la misma que la indicada
anteriormente (permitir que la matriz de interacción fuese aplicada por otra persona y que

Asignatura: Análisis de requisitos 9

 ésta detectase los defectos en los requisitos y los plasmase en un alista de errores y acciones
recomendadas).
• Cómo detectar conflictos y solapamientos. Esto es, dados dos requisitos r1 y r2, ¿cómo
puede saber el analista, o la persona que esté aplicando la matriz de interacción, si ambos
requisitos son conflictivos o están solapados?
Esta pregunta es, no obstante, de fácil respuesta. Para poder aplicar la matriz de interacción,
el analista, o la persona que lo substituye, debería poseer un buen conocimiento de la
aplicación a construir. Sólo de este modo es posible no cometer errores, por omisión o
comisión, a este respecto.
Finalmente, si poseyendo un buen conocimiento de la aplicación, el analista, o la persona
que lo substituye, no puede juzgar si dos requisitos r1 y r2 son conflictivos o están
solapados3, lo preferible es considerar que existe un problema potencial entre los requisitos
r1 y r2 y estudiar éstos más detenidamente.
• Cómo manejar grandes conjuntos de requisitos. La única solución a este problema es
descomponer el sistema software en varios subsistemas, con la finalidad de reducir la
complejidad del análisis de cada uno de ellos.

6.5.5. Identificación de los usuarios relevantes

Tal y como se ha indicado anteriormente, durante el análisis se detectan diversas carencias en los
requisitos, tales como errores, omisiones, inconsistencias, etc. En muchos casos, para eliminar
dichas carencias, es necesario acudir a los clientes/usuarios que enunciaron los requisitos. El
problema surge en recordar a qué clientes/usuarios concretos es necesario acudir.

Si el tamaño del sistema software es pequeño, o el número de clientes/usuarios es reducido, recordar

a qué clientes/usuarios concretos es necesario acudir no es un problema: la memoria del analista es
suficiente. No obstante, en casos más complicados, la memoria por sí sola no es suficiente o, al
menos, aconsejable.

En estos casos, es conveniente utilizar lo que se conoce como trazabilidad hacia atrás. La
trazabilidad hacia atrás consiste en relacionar cada requisito con su origen4. Dicha relación puede
materializarse fácilmente como un tipo de anotación, al igual que la anotación por identificación o
versión, ya indicadas en la sección 6.4. La única diferencia consiste en que la anotación, en lugar de
contener el número o versión del requisito, contiene el número de documento o el nombre del
cliente/usuario que enunció dicho requisito.

Nótese, finalmente, que cuando los requisitos poseen trazabilidad hacia atrás, la especificación
poseerá la propiedad de ser trazable. Éste es, de nuevo, uno de los requisitos de calidad que se
describirán ampliamente en la UNIDAD 10.

3
Dicho de otra forma: si una persona con conocimiento y experiencia no puede dictaminar unívocamente
algo, lo más prudente es suponer que ello pueda ser una fuente de conflicto más adelante.
4
El origen de un requisito puede ser un documento (la transcripción de una entrevista, por ejemplo), o un
cliente o usuario concreto.

Asignatura: Análisis de requisitos 10

6.6. Modelado conceptual

Por ‘Modelado Conceptual’ debe entenderse el proceso de creación de modelos conceptuales.

Asimismo, un modelo conceptual es una representación, típicamente semi-formal y de naturaleza
gráfica, de algún aspecto de interés del sistema software a desarrollar.

La definición anterior es de poca utilidad sin un ejemplo. Supóngase por un instante que el sistema
software a construir tuviera como objetivo ensamblar automáticamente automóviles. Utilizando un
diagrama de cajas, el cual es una representación bien conocida por todo el mundo, sería posible
representar dicho sistema5 tal y como se indica en la Figura 2.

Ensamblar Automóvil
Piezas
automóvil ensamblado

Figura 2. Proceso de ensamblaje de un automóvil

Pues bien: el diagrama mostrado en la Figura 2 cumple con todas las características de modelo
conceptual: es gráfico, es semi-formal (al menos, podemos suponer que se verifican las reglas
básicas de conservación de materiales) y representa un aspecto importante del sistema a construir
(esto es, los materiales de entrada y el producto de salida esperado).

Los modelos conceptuales usados típicamente durante el análisis son similares al diagrama de cajas
mostrado en la Figura 2, aunque un poquitín más perfeccionados6. Históricamente, los modelos
conceptuales son bastante antiguos: éstos modelos aparecieron originalmente en el campo de las
bases de datos en los años 70, donde se utilizaron para representar datos y relaciones entre datos
independientemente del modelo lógico (relacional CODASYL, etc.) utilizados por los sistemas
gestores de bases de datos. De esta época es el más famoso de los modelos conceptuales: el modelo
entidad-relación, utilizado todavía hoy en día. Con los años, la idea de modelo conceptual se amplió
progresivamente y, en lugar de representar datos y relaciones, se ha tendido a que éstos representen
cualquiera aspectos del dominio de discurso.

Por dominio de discurso, debe entenderse el entorno que rodea al software, donde éste ejerce su
influencia (toma datos, suministra datos) y donde existen unas reglas que el software debe respetar
para funcionar correctamente y proporcionar un trabajo útil (reglas tales como que las facturas
deben imprimirse mensualmente o que éstas tendrán un formado determinado).

5
En realidad, los modelos conceptuales representan el dominio de discurso, y no el sistema software. Esto es,
con un poco de atención es fácil observar que la Figura 2 no describe el software a construir, sino el problema
a resolver en el mundo real. No obstante, esta diferencia es muy sutil y difícil de explicar. Es mejor pasar por
encima de este aspecto y estudiarlo a medida que se estudien los distintos tipos de modelos conceptuales en
las unidades 7, 8 y 9.
6
Cuando los modelos conceptuales se formalizan completamente, se convierten en lenguajes formales, en el
sentido matemático del término, con todo lo que ello conlleva (precisión, verificabilidad, etc.). No obstante,
los lenguajes formales son más usados durante la actividad de documentación que durante la actividad de
análisis. Véase, a este respecto, la UNIDAD 10.

Asignatura: Análisis de requisitos 11

Actualmente, se distinguen tres grandes grupos de modelos conceptuales: los orientados a procesos,
datos/objetos y estados. Estos tres tipos de modelos conceptuales permiten describir de forma
bastante completa cualquier dominio de discurso7. Dichos tipos de modelos, por su extensión y
complejidad, se describirán en unidades separadas: las UNIDADES 7, 8 y 9.

Queda decir, finalmente, cómo permiten los modelos conceptuales aumentar la calidad de los
requisitos, lo cual es el objetivo del análisis. Pues bien: los modelos conceptuales, al representar el
dominio de discurso, permiten dos realizar dos tareas fundamentales:

• Que el analista comprenda mejor el dominio de discurso, de tal modo que

• sea posible detectar más fácilmente omisiones e inconsistencias

Como ello es posible será descrito en las UNIDADES 7, 8 y 9.

6.7. Negociación y resolución de conflictos

En la sección 6.5.3, cuando se describió el método de la matriz de interacción, se indicó que uno de
los defectos que se puede localizar en la lista preliminar de requisitos son los requisitos
contradictorios. También se indicó que, en la mayoría de los casos, los requisitos contradictorios
surgen de las distintas visiones que los usuarios tienen del futuro sistema, por lo que, para eliminar
los conflictos entre requisitos, el analista debe negociar con los usuarios un conjunto coherente de
requisitos.

Puede resultar difícil de creer que los usuarios expresen requisitos contradictorios para un mismo
sistema. No obstante, ello es mucho más común de lo que parece: basta con que existan pequeñas
diferencias acerca del objetivo del sistema como para que aparezcan inmediatamente conflictos. Por
ejemplo, supóngase un sistema de gestión de personal. Es posible que el departamento de personal
desee que el sistema establezca automáticamente qué empleados trabajan en un determinado turno
(para evitar tener que realizar la asignación manualmente). Sin embargo, puede ocurrir que el jefe
del departamento de fabricación (imaginemos que es una empresa de fabricación) desee que las
asignaciones sean manuales para que en planta haya un número similar de personas con y sin
experiencia laboral (ello para evitar errores en la producción).

En el momento en que el usuario detecta requisitos conflictivos, debe iniciar el proceso de

negociación con los usuarios8 que lo han motivado. Para ello, el analista debe dejar claro el origen
del conflicto y debe intentar que los usuarios se pongan de acuerdo acerca de una solución de
compromiso que elimine dicho conflicto y que satisfaga a ambos. Dicha solución (esto es, un
conjunto de requisitos coherentes) sustituirán a los requisitos conflictivos en la lista preliminar de
requisitos.

7
El modelado conceptual es un campo extremadamente complejo de la informática. Existen escuelas que
jamás denominarían a un modelo de procesos como ‘modelo conceptual’. Incluso, un anciano tan venerable
como es el modelo entidad-relación puede muchas veces ser referido como ‘modelo semántico’, en lugar de
‘modelo conceptual’. Resumiendo: la denominación concreta utilizada depende mucho de los autores que se
consulten.
8
¿Cómo es posible saber qué usuario generó cada requisito? Siempre es conveniente anotar cada requisito con
el usuario que lo enunció. Éste es un tipo de trazabilidad al origen, tal y como se describe en la UNIDAD 12.

Asignatura: Análisis de requisitos 12

Durante la negociación, el analista debe actuar de hombre bueno y no tomar partido por ninguna de
las posibles soluciones que propongan los usuarios. Obviamente, el papel del analista no es
simplemente pasivo y, en este sentido, puede sugerir caminos de acción o explicar a los usuarios el
impacto de cada solución parcial que ellos propongan.

Si, finalmente, no existe posibilidad de acuerdo, el analista debe acudir al cliente9 y comunicarle el
conflicto. El cliente utilizará sus propios recursos para poner de acuerdo a los usuarios o,
alternativamente, establecerá el mismo qué requisitos se implementarán y cuáles no. Esto es lo que
se denomina resolución por decreto y, aunque es sumamente efectiva (el conflicto, simplemente,
desaparece), causa malestar en los usuarios y debe ser evitada siempre que sea posible.

9
O acudir al jefe de proyecto y que éste se ponga en contacto con el cliente. Los detalles del acceso al cliente
ya dependen de las particularidades del proyecto de desarrollo.

Asignatura: Análisis de requisitos 13