INGENIERIA DE REQUISITOS

Un sistema de software modela un campo (dominio) de aplicación de tal modo que automatiza una realidad, regularmente asociada a la manipulación de datos, por ejemplo, la gestión de datos de una nómina, 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 aplicación, así como su estado y comportamiento con respecto a los demás conceptos. Por ejemplo, en un banco descubrimos el concepto de cuenta, su estado se define mediante la determinación de sus atributos (número de cuenta, titular, saldo), mientras que el comportamiento queda establecido por las acciones que se pueden efectuar sobre sus atributos (depósito, retiro). Una correcta definición 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 metodología 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 gráfico que ilustra la relación del usuario con el sistema y se acompaña 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 aplicación que se desea automatizar. La importancia de la captura de requisitos ha dado lugar a la definición de un área de estudio denominada Ingeniería de Requisitos y al establecimiento de estándares para su documentación. 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 desempeñan los usuarios y los propios casos de uso, es decir las funcionalidades del sistema. Los casos de uso se representan gráficamente, como se ilustra enseguida y se acompañan de una plantilla textual que describe propiamente el diagrama.

La plantilla descriptiva incluye los siguientes aspectos:

El Modelo de Dominio del Problema (De Información): especifica los aspectos estructurales de la aplicación en términos de objetos y clases mediante un modelo de dominio. El modelo de dominio es, desde el punto de vista técnico, un diagrama de clases de UML que incluye asociaciones y multiplicidad entre clases así como una identificación de sus atributos. Enseguida se ilustra un modelo de dominio.

El Modelo de Interfaces (De Presentación) describe las interfaces a través de un conjunto de ventanas gráficas del sistema, que hace una representación de la interacción de los actores con el sistema. En este aspecto se dibujan las interfaces y se identifican con un nombre clave, que después es utilizado para, desde las plantillas de texto de los casos de uso, indicar la interfaz precisa con que interactúan. Con respecto a UML, el modelo de casos de uso es el primer tipo de diagrama técnico en el desarrollo de un sistema, a pesar de que es el diagrama más básico, 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 visión lógica del sistema que puede ser observada por el usuario final.

PROPUESTA

En cuanto al modelo de comportamiento Weitzenfeld propone diagramas de casos de uso acompañados 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 modificación elimina la plantilla de Weitzenfeld y se queda sólo con un enunciado, esto es inspirado por las historias de usuario de las metodologías ágiles.

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

Finalmente, para el modelo de presentación se sugiere un mapa gráfico de invocación entre ventanas que permita reconocer cual es la secuencia de operación del sistema y una descripción en lenguaje natural de cada ventana. Esta parte le da al usuario de un futuro sistema mucha claridad en cuanto a cómo se verá el sistema.

En lo que respecta a la introducción de los diagramas de casos de uso con una descripción textual, sin considerar plantilla descriptiva. En cuanto al modelo de interfaces, un diagrama que ilustra la interacción entre diferentes interfaces, así como una descripción textual de cada una. Esto ilustra aspectos de navegación 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 formarán parte de la lógica del sistema, sino más bien de los datos que se almacenarán 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 descripción textual en prosa y en lenguaje natural en relación a cada caso de uso.

Modelo de información: La identificación de un conjunto de clases junto con sus atributos

Modelo de presentación: Un mapa de invocación entre ventanas, así como la descripción textual de cada ventana.

El carácter que se le desea dar a la fase de requisitos es que sea posible identificar y documentar de manera rápida los requisitos que plantea un usuario de un futuro sistema. De ese modo, se eleiminan algunas características que se consideran con demasiado detalle técnico del modelo de requisitos de Weitzenfeld y se da mayor énfasis a la descripción en lenguaje natural de alguno de los textos.