INGENIERIA DE REQUISITOS Un sistema de software modela un campo (dominio) de aplicacin de tal modo que automatiza una realidad, regularmente

asociada a la manipulacin de datos, por ejemplo, la gestin de datos de una nmina, de un banco, de una escuela, etc. La fase de requisitos tiene como finalidad fundamental propiciar el descubrimiento de los conceptos asociados al dominio de aplicacin, as como su estado y comportamiento con respecto a los dems conceptos. Por ejemplo, en un banco descubrimos el concepto de cuenta, su estado se define mediante la determinacin de sus atributos (nmero de cuenta, titular, saldo), mientras que el comportamiento queda establecido por las acciones que se pueden efectuar sobre sus atributos (depsito, retiro). Una correcta definicin de requisitos permite asegurar que el ingeniero de software entiende qu es lo que un cliente desea recibir como resultado del desarrollo de un sistema y que, por tanto, el xito del proyecto es factible. MODELO DE REQUISITOS La metodologa presentada por Weitzenfeld [4] en la que, para la fase de requisitos sugiere especificar los siguientes modelos: a) Modelo de casos de uso, b) Modelo de interfaces y c) Modelo de dominio. El primero es un diagrama grfico que ilustra la relacin del usuario con el sistema y se acompaa de una plantilla descriptiva textual. El segundo busca definir las interfaces que contendr el sistema y el tercero pretende

identificar las clases (conceptos) propios del campo de aplicacin que se desea automatizar. La importancia de la captura de requisitos ha dado lugar a la definicin de un rea de estudio denominada Ingeniera de Requisitos y al establecimiento de estndares para su documentacin. En el Modelo de Casos de Uso (De Comportamiento) se especifica la funcionalidad que ofrecer el sistema desde el punto de vista de usuario. Aqu intervienen dos conceptos clave, los actores, que representan los distintos papeles que desempean los usuarios y los propios casos de uso, es decir las funcionalidades del sistema. Los casos de uso se representan grficamente, como se ilustra enseguida y se acompaan de una plantilla textual que describe propiamente el diagrama.

La plantilla descriptiva incluye los siguientes aspectos:

El Modelo de Dominio del Problema (De Informacin): especifica los aspectos estructurales de la aplicacin en trminos de objetos y clases mediante un modelo de dominio. El modelo de dominio es, desde el punto de vista tcnico, un diagrama de clases de UML que incluye asociaciones y multiplicidad entre clases as como una identificacin de sus atributos. Enseguida se ilustra un modelo de dominio.

El Modelo de Interfaces (De Presentacin) describe las interfaces a travs de un conjunto de ventanas grficas del sistema, que hace una representacin de la interaccin de los actores con el sistema. En este aspecto se dibujan las interfaces y se identifican con un nombre clave, que despus es utilizado para, desde las plantillas de texto de los casos de uso, indicar la interfaz precisa con que interactan.

Con respecto a UML, el modelo de casos de uso es el primer tipo de diagrama tcnico en el desarrollo de un sistema, a pesar de que es el diagrama ms bsico, no retroalimenta suficientemente al usuario con respecto a lo que espera del sistema. Por ello el modelo de interfaces cobra importancia ya que ofrece una visin lgica del sistema que puede ser observada por el usuario final.

PROPUESTA
En cuanto al modelo de comportamiento Weitzenfeld propone diagramas de casos de uso acompaados de una plantilla textual descriptiva. En lo que al curso respecta, se solicita un diagrama de casos de uso junto con un enunciado en lenguaje natural que describa la funcionalidad del sistema que representa el dibujo. Esta modificacin elimina la plantilla de Weitzenfeld y se queda slo con un enunciado, esto es inspirado por las historias de usuario de las metodologas giles.

La propuesta sugiere identificar las clases del sistema con sus atributos, para en etapas posteriores del ciclo de vida de ingeniera de software atender sus roles, relaciones y multiplicidades.

Finalmente, para el modelo de presentacin se sugiere un mapa grfico de invocacin entre ventanas que permita reconocer cual es la secuencia de operacin del sistema y una descripcin en lenguaje natural de cada ventana. Esta parte le da al usuario de un futuro sistema mucha claridad en cuanto a cmo se ver el sistema. En lo que respecta a la introduccin de los diagramas de casos de uso con una descripcin textual, sin considerar plantilla descriptiva. En cuanto al modelo de interfaces, un diagrama que ilustra la interaccin entre diferentes interfaces, as como una descripcin textual de cada una. Esto ilustra aspectos de navegacin en el sistema. En cuanto al modelo de dominio identificar las clases del sistema junto con sus atributos, pero sin analizar relaciones entre ellas, ya que algunas no formarn parte de la lgica del sistema, sino ms bien de los datos que se almacenarn en disco, y eso, son aspectos que no corresponden a la fase de requisitos.

CONCLUSIONES.
Modelo de comportamiento: Diagramas de casos de uso con una descripcin textual en prosa y en lenguaje natural en relacin a cada caso de uso. Modelo de informacin: La identificacin de un conjunto de clases junto con sus atributos Modelo de presentacin: Un mapa de invocacin entre ventanas, as como la descripcin textual de cada ventana.

El carcter que se le desea dar a la fase de requisitos es que sea posible identificar y documentar de manera rpida los requisitos que plantea un usuario de un futuro sistema. De ese modo, se eleiminan algunas caractersticas que se consideran con demasiado detalle tcnico del modelo de requisitos de Weitzenfeld y se da mayor nfasis a la descripcin en lenguaje natural de alguno de los textos.