modelo de interfaces

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 sistema, por lo que debera proyectar lo que el cliente desea segun la percepcion
del desarrollador. Por ello, es esencialque los clientes lo comprendan.
El modelo de requisites es el primero en desarrollarse, y es la base para formar todos los demas modelos en el desarrollo de software. En general, cualquier cambio en la funcionalidad del sistema es mas facil de hacer, y con menores 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 metodologia es parte del Proceso unificado rational (RUP) [Rational Unified Process].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 modelode casos de uso sirve para expresar el modelo de
requisites, el cual se desarrolla en cooperacion con otros modelos como e
s
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 implementacion.
Diseno: Lafuncionalidad de los casos de uso, ya estructurada por el analisis, la realiza el modelo de diseno, adaptandose al ambiente de implementacion 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 componentes y de integracion.
Documentacion: El modelo de casosde 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 notacion que se describiran mas adelante.

Figura 6.1

Dependencia de los distintos modelos del proceso de software
del modelo de casos de uso.

Elproposito del modelo de requisitos es comprender en su totalidad el problema y sus implicaciones. Los demas modelos, analisis, diseno, implementacion
y pruebas dependen directa o indirectamente del modelo de requisitos. Asimismo, este modelo sirve de base para el desarrollo de las instrucciones operacionales y los manuales, ya que todo lo que el sistema deba hacer se describe aqui
desde laperspectiva del usuario. El modelo de requisitos no es un proceso mecanico, el analista debe interactuar constantemente con el cliente para completar la informacion faltante, y asi resolver ambigiiedades e inconsistencias. Tambien debe separar los requisitos verdaderos de las decisiones relacionadas con
el diseno e implementacion. Se deben indicar cuales aspectos son obligatorios
y cuales opcionalespara evitar que se limite la flexibilidad de la implementacion. Durante el diseno, se debe extender el modelo de requisitos con las especificaciones 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 deprogramacion particulars.
En la metodologia de Objectory, el modelo de requisitos consta de tres modelos 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...