6

CAPITULO

Modelo de requisites
El modelo de requisites tiene como objetivo delimitar el sistema y capturar la
funcionalidad que ofrecera desde la perspectiva del usuario. Este modelo puede
trabajar como un contrato entre el desarrollador y el cliente, o usuario del sis-
tema, por lo que debera proyectar lo que el cliente desea segun la percepcion
del desarrollador. Por ello, es esencial que los clientes lo comprendan.

El modelo de requisites es el primero en desarrollarse, y es la base para for-

mar todos los demas modelos en el desarrollo de software. En general, cual-
quier cambio en la funcionalidad del sistema es mas facil de hacer, y con me-
nores consecuencias a este nivel que posteriormente. El modelo de requisites
que se desarrollara se basa en la metodologia Objectory (Jacobson et al. 1992),
que tiene su fundamento en el modelo de casos de uso. Actualmente esta me-
todologia es parte del Proceso unificado rational (RUP) [Rational Unified Pro-
cess].1 El modelo de casos de uso y el propio modelo de requisites son la base
para los demas modelos. A continuacion se repasaran los conceptos detallados
en el capitulo 3, que nos serviran en esta seccion:

Requisites: El modelo de casos de uso sirve para expresar el modelo de

requisites, el cual se desarrolla en cooperacion con otros modelos como es
vera mas adelante.
Analisis: La funcionalidad especificada por el modelo de casos de uso se
estructura en el modelo de analisis, que es estable con respecto a cambios,
lo que lo hace un modelo logico independiente del ambiente de implemen-
tacion.
Diseno: La funcionalidad de los casos de uso, ya estructurada por el ana-
lisis, la realiza el modelo de diseno, adaptandose al ambiente de implemen-
tacion real y refinandose aun mas.
Implementacion: Los casos de uso se instrumentan mediante el codigo
fuente en el modelo de implementacion.
Pruebas: Los casos de uso se comprueban a traves de las pruebas de com-
ponentes y de integracion.
Documentacion: El modelo de casos de uso se debe registrar a lo largo
de las diversas actividades, dando lugar a distintos documentos como los
manuales de usuario, de administracion, etcetera.

El diagrama de la figura 6.1 ilustra los distintos modelos, los detalles y la nota-
cion que se describiran mas adelante.
 Figura 6.1 Dependencia de los distintos modelos del proceso de software
del modelo de casos de uso.

El proposito del modelo de requisitos es comprender en su totalidad el proble-

ma y sus implicaciones. Los demas modelos, analisis, diseno, implementacion
y pruebas dependen directa o indirectamente del modelo de requisitos. Asimis-
mo, este modelo sirve de base para el desarrollo de las instrucciones operacio-
nales y los manuales, ya que todo lo que el sistema deba hacer se describe aqui
desde la perspectiva del usuario. El modelo de requisitos no es un proceso me-
canico, el analista debe interactuar constantemente con el cliente para comple-
tar la informacion faltante, y asi resolver ambigiiedades e inconsistencias. Tam-
bien debe separar los requisitos verdaderos de las decisiones relacionadas con
el diseno e implementacion. Se deben indicar cuales aspectos son obligatorios
y cuales opcionales para evitar que se limite la flexibilidad de la implementa-
cion. Durante el diseno, se debe extender el modelo de requisitos con las es-
pecificaciones de rendimiento y los protocolos de interaccion para los sistemas
externos, al igual que las provisiones sobre modularidad y futuras extensiones.
Incluso, en ciertas ocasiones se pueden incluir aspectos de diseno, como el uso
de lenguajes de programacion particulars.

En la metodologia de Objectory, el modelo de requisitos consta de tres mode-

los principales, visualmente representado por un diagrama de tres dimensiones
como se muestra en la figura 6.2.

Figura 6.2 Los tres ejes de modelado del modelo de requisitos.

El modelo de comportamiento, basado directamente del modelo de casos

de uso, especifica la funcionalidad que ofrece el sistema desde el punto de
vista del usuario. Este modelo utiliza dos conceptos claves: actores para re-

196 CAP. 6 — MODELO DE REQUISITOS

 presenter los distintos papeles que los usuarios desempenan con el sistema
y casos de uso para significar que pueden hacer los actores con respecto al
sistema.
El modelo de presentation o modelo de interfaces (o horde) especifica como
interactua el sistema con actores externos al ejecutar los casos de uso. En
particular, en los sistemas de informacion que tienen mucho contacto con
el usuario, especifica como se veran visualmente las interfaces graficas, y
que funcionalidad ofrecera cada una.
El modelo de information o modelo del dominio del problema especifica
los aspectos estructurales de la aplicacion en terminos de objetos. Este mo-
delo permite identificar rapidamente cuales objetos podran ser guardados
en una base de datos, si ese fuera el caso. Ademas, es utilizado para guar-
dar informacion temporal en la aplicacion, y eventualmente servira como
parametro de llamadas entre funciones en el sistema.

Es importante resaltar que esta separacion en tres ejes de modelado indepen-

dientes sirve para una mayor estabilidad en el desarrollo del sistema, lo que
permite minimizar los efectos de cada uno sob re los otros dos.

Para ilustrar el modelo de requisites y el desarrollo de los modelos posteriores,

se utilizara el ejemplo del "Sistema de reservaciones de vuelo" como se men-
ciono antes. Para ello, mostraremos inicialmente una description del problema.
A partir de esta descripcion inicial se describiran los tres modelos basicos del
modelo de requisites.

6.1 Descripcion del problema

La descripcion del problema es un resumen preliminar de necesidades que
sirve como punto de partida para comprender los requisites del sistema. Aqui
se trata de simular una descripcion preparada por un cliente, la cual debe evo-
lucionar por medio del modelo de requisites, con objeto de lograr la especifi-
cacion final del sistema a desarrollarse. La descripcion del problema debe ser
una especificacion de necesidades y no una propuesta de solucion. La descrip-
cion inicial puede ser incompleta e informal, pues al realizarse sin un analisis
completo, no hay ninguna razon para esperar que sea correcta.

Como ejemplo se desarrollara un Sistema de reservaciones de vuelos, el cual per-

mitira al usuario hacer consultas y reservaciones de vuelos; ademas de comprar
los boletos aereos de forma remota, sin la necesidad de recurrir a un agente de
viajes. En la actualidad, existen multiples sistemas de reservaciones de vuelos
que utilizan las agencias de viajes para dar servicio a los clientes, entre es-
tos los cuatro mas importantes son: Sabre2, Galileo5, Worldspan4 y Amadeus5.
Estos sistemas son conocidos como sistemas de distribucion global. Tambien
existen sistemas de reservaciones de vuelo por Internet, como Tmvelocity6 y
Expedia1, entre otras, los cuales se basan en su mayoria, de manera directa o
indirecta, en los sistemas de distribucion global anteriores.

La descripcion del problema para nuestro sistema de reservaciones de vuelos

es la siguiente:

DESCRIPCION DEL PROBLEMA 197