DESARROLLO El modelado de requisitos nos sirve y tiene como propósito comprender completamente el problema y todo lo que éste implica y conlleva. Su objetivo principal es delimitar el sistema y capturar la funcionalidad que debe ofrecer desde la perspectiva del usuario.

Además el modelo de requisitos captura las principales características del sistema de software que se desea construir. Por medio de él representamos los requisitos del sistema de forma sencilla, para que de esta manera cualquier usuario pueda revisarlo y además entenderlo, sin necesidad de tener conocimientos previos al modelo e información. Intervienen en el los modelos de caso de uso, que desempeñan un papel importante de gran relevancia.

En el estudio del modelo de requisitos se encuentran los funcionales y no funcionales.

Cabe mencionar que los requisitos determinan lo que hará el sistema, es decir, como funcionará además, las restricciones sobre su operación e implementación. La elicitación, análisis y especificación de requisitos es el proceso del estudio de las necesidades de los usuarios para llegar a una definición de los requisitos del sistema.

Un requisito es una condición o capacidad que necesita el usuario para resolver un problema o conseguir un objetivo determinado. Puede verse como una declaración abstracta de alto nivel de un servicio que el sistema debe proporcionar.

Los requisitos funcionales: son la característica requerida del sistema que expresa una capacidad de acción del mismo, una funcionalidad; generalmente expresada en una declaración en forma verbal. No todo lo que necesitaremos en nuestro sistema es funcionalidad pura; por el contrario a veces se necesitan otras cualidades, si se quieren generalidades, que no son objeto de codificación si bien es cierto que pueden llegar a afectar a esta. Pueden ser frases muy generales sobre lo que el sistema debería hacer. Se suelen expresar como objetivos del sistema. Deben describir los servicios que hay que proporcionar con todo detalle (casos de uso).

Requisitos no funcionales: característica requerida del sistema, del proceso de desarrollo, del servicio prestado o de cualquier otro aspecto del desarrollo, que señala una restricción del mismo. Son todas las exigencias de cualidades que se imponen al proyecto: exigencias de usar un cierto lenguaje de programación o plataforma tecnológica, por ejemplo, Un requisito no funcional

es una característica ya sea del sistema, del proyecto o del servicio de soporte, que nos es requerida junto con la especificación del sistema pero que como ya dije, no se satisface añadiendo código, sino cumpliendo con esta como si de una restricción se tratara.

Los requisitos no funcionales pueden clasificarse en: Requisitos del producto: especifican el comportamiento del producto obtenido.

Requisitos organizacionales: son una consecuencia de las políticas y procedimientos existentes en la organización.

Requisitos externos: presentan factores externos al sistema y a su proceso de desarrollo.

Además, existen los requisitos de usuarios, que nos dice que el sistema debe permitir representar y acceder a archivos externos creados por otras herramientas. Los requisitos del sistema asociado nos dice que el usuario deberá poder definir el tipo de un nuevo archivo externo, el usuario deberá poder definir el icono que representa un tipo de archivo externo.

Encontramos así mismo los requisitos verificables, los requisitos no funcionales suelen ser muy difíciles de expresar con exactitud, ya que los requisitos imprecisos pueden ser difíciles de verificar, como por ejemplo: un deseo general del usuario es la facilidad de uso. Un requisito no funcional verificable, una frase que incluye alguna medida que puede ser objetivamente probada.

Derivado de esto aparecen problemas cuando los requisitos no se precisan con exactitud, por ejemplo, los requisitos expresados de forma ambigua se pueden interpretar de manera diferente por los desarrolladores y por los usuarios.

Por tal motivo se busca como objetivo que la especificación debe ser completa y consistente, completa en el sentido de que todos los servicios solicitados por el usuario estén definidos. Y consistente en que los requisitos no tengan definiciones contradictorias.

El proceso de análisis de requisitos, considera los aspectos relativos al análisis de las funcionalidades y la traducción al modelo conceptual.

Existen tres técnicas que nos permiten generar el modelo de requisitos:

• Misión del sistema: describe cual es el propósito del sistema, sus responsabilidades y el alcance que tendrá. A través de él podemos determinar, en términos generales, que hará y que no hará el sistema. Aunque es una técnica sencilla es de vital importancia para el desarrollo del sistema.

• Árbol de refinamiento de funciones: descompone el sistema en interacciones externas, de acuerdo a algún criterio preestablecido. Cabe mencionar que las interacciones externas son organizadas en funciones que forman una jerarquía a manera de árbol, en cuyo nivel más alto (raíz) se ubica la misión del sistema. Esta Misión del Sistema es refinada hasta obtener otras funciones elementales representadas en la jerarquía a través de los nodos hoja. Este proceso descendente de refinamiento funcional puede generar distintos niveles de nodos.

Aquellos que están entre la raíz y los nodos hoja son denominados nodos intermedios. Un nodo intermedio es un sumario de funciones elementales. En general, una rama completa de nodos con origen en la raíz del árbol, representa toda la funcionalidad relativa a un área o actividad de la organización, según el criterio de descomposición utilizado.

• Modelo de casos de uso: El modelado de requisitos utiliza los elementos del Modelo de Casos de Uso. De esta forma, la especificación de actores y casos de uso así como el establecimiento de las relaciones entre éstos, constituye el objetivo fundamental del Modelo de Casos de Uso. El principal insumo requerido para el desarrollo de este modelo son las funciones elementales identificadas como nodos hoja en el Árbol de Refinamiento Funcional del sistema. Cada una de estas funciones elementales es considerada en el modelo como un caso de uso. Luego de identificar sus actores, la especificación de los casos de uso describe en lenguaje natural la secuencia completa y ordenada de las acciones que el sistema debe ejecutar, incluyendo todas sus posibles variantes, al interactuar con los actores para la satisfacción de los requisitos.

Describe un sistema en término de sus distintas formas de utilización, cada una de esas formas es conocida como un caso de uso. Cada caso de uso o flujo se compone de una secuencia de eventos iniciada por el usuario.

Los actores son entidades distintas a los usuarios, representan un cierto papel que una persona real puede jugar. Modelan cualquier entidad externa que necesite intercambiar información con el sistema. No están restringidos a ser personas físicas, pudiendo representar otros sistemas externos al actual. Lo esencial es que representen entidades externas al sistema. Cada uno de los actores podrá ejecutar una o más tareas del sistema.

El flujo de eventos que se desarrolla entre el actor y el sistema para el logro del objetivo del caso de uso es narrado en la especificación, a manera de conversación, a través de una secuencia numerada de pasos. Esta

clasificación separa las acciones del actor de las ejecutadas por el sistema y las distingue de aquellas relativas al contexto donde se desarrolla el caso de uso.

A medida que se alcanza un mayor conocimiento del dominio, este texto crece en tamaño y detalle adquiriendo formas complejas que limitan su comprensión y posterior uso en las distintas etapas de la construcción del sistema. Con el propósito de minimizar el impacto de estos problemas, la descripción de los casos de uso es estructurada precisándose su nivel de detalle en términos de las necesidades del modelado y del momento de desarrollo del sistema.

El nivel de abstracción de un caso de uso está vinculado al contenido informativo relevante o significativo que se desea expresar en el caso de uso.

El propósito principal de este proceso es identificar las responsabilidades más significativas del sistema en desarrollo. Las responsabilidades conllevan a la definición de operaciones, esto es, a la especificación de los servicios de una clase.

Con el propósito de describir las responsabilidades detectadas en el contexto de un Caso de Uso se utilizan Diagramas de Secuencia con notación UML. En estos diagramas se representan las responsabilidades, identificando el objeto que la invoca (objeto cliente) y el objeto al que ésta pertenece (objeto servidor).

Para mostrar las decisiones sobre asignación de responsabilidades entre los objetos, el Proceso de Análisis de Requisitos prevé la especificación de Diagramas de Secuencia pero a muy alto nivel y como herramienta para representar estas responsabilidades.

Un escenario es una secuencia específica de las acciones que describe un caso de uso. Así, un caso de uso puede ser considerado como la compilación de múltiples escenarios algunos de los cuales, los primarios, describen su trayectoria normal mientras que otros, los secundarios, se refieren a sus trayectorias alternas.

Los diagramas de secuencia permiten describir patrones de interacción entre objetos o clases. A través de estos diagramas se muestra la secuencia ordenada en el tiempo de los mensajes que envían y reciben genéricamente los objetos durante la ejecución de un escenario. Un estímulo es una comunicación entre dos objetos que se transmiten información con la finalidad de que se ejecute una actividad. Un mensaje especifica los roles que deben cumplir tanto el objeto emisor (el cliente) como el objeto receptor del estímulo (el servidor) así como la acción que

será ejecutada. De esta forma, a través de los mensajes se expresan las responsabilidades que cumplirán los objetos en el sistema.

En el Proceso de Análisis de Requisitos, es posible utilizar dos tipos de diagramas de secuencia, que va a depender del momento y estrategia de desarrollo seguida así como también del nivel de detalle deseado.

1) OO-Method: hace énfasis en la interacción, en términos de los actores y el sistema, mostrando el flujo de eventos que ocurren en el dominio del problema. Este tipo de diagrama de secuencia muestra las responsabilidades pero no los objetos clientes ni los objetos servidores (dada una especificación de Casos de Uso con sus pasos se obtiene automáticamente donde cada paso se convierte en un auto-mensaje).

2) La evolución del primero: representa de manera precisa y detallada las interacciones entre los actores y el sistema pero, esta vez, indicando el intercambio de mensajes entre las clases de objetos participantes. Se muestran las responsabilidades y también las clases de objetos clientes y servidores.

El Proceso de Análisis de Requisitos consiste, básicamente, en la construcción de los diagramas de secuencia OO-Method a partir del Modelo de Requisitos del sistema.

Los diagramas de secuencia, además de expresar en detalle los resultados del Proceso de Análisis de Requisitos, constituyen un recurso de mucha importancia para la construcción del Modelo de Objetos. Con esta finalidad, se ha incorporado en estos diagramas cierta información que resulta de interés para identificar elementos de este modelo. Esta información se expresa estereotipando los mensajes del diagrama de secuencia con el propósito de distinguirlos según la clasificación.

El modelo de trazabilidad es utilizado para relacionar los distintos elementos del Enfoque de Ingeniería de Requisitos con los elementos del Modelo Conceptual, se caracteriza por ser estructural y estar basado en referencias cruzadas. Esto significa, que la relación establecida entre estos elementos es estructural. En segundo lugar, se establecen explícitamente referencias entre los elementos a diferentes niveles de abstracción.

Por otra parte, la trazabilidad en el enfoque de Ingeniería de Requisitos puede ser estudiada desde dos perspectivas:

• Internamente.- la trazabilidad es establecida entre los elementos de las distintas técnicas del Modelo de Requisitos y entre éstos y los que pertenecen al Proceso de Análisis de Requisitos.

• Externamente, la trazabilidad queda determinada por los vínculos establecidos entre los elementos de dicho proceso y los constructores del Modelo Conceptual.

Encontramos dentro de éste proceso la validación y gestión de requisitos, que consiste en demostrar que los requisitos definen el sistema que los clientes desean. Y por lo tanto los costes de los errores en los requisitos son muy altos por lo que la validación funge como un factor muy importante en dicho proceso.

La gestión de los requisitos es el proceso de manejar los requisitos que cambian durante el desarrollo del sistema. Los requisitos pueden ser inevitablemente inconsistentes e incompletos.

Dentro de las aplicaciones del modelado de requisitos encontramos: los procesos de negocio de la organización se identifican partiendo de sus propios objetivos, y se describen mediante flujos de actividades que se representan mediante diagramas de actividades UML. De este modo, los casos de uso del sistema se obtienen a partir de las actividades de los procesos del negocio, se organizan jerárquicamente y se facilita su desarrollo iterativo e incremental.

Las clases del modelo conceptual se obtienen a partir de los objetos de información que fluyen entre las actividades. A la vez que se realiza el modelado del negocio y de los requisitos, las reglas del negocio de la organización se recogen en un glosario, en forma de especificación de las actividades y de los casos de uso asociados, así como de los objetos de información y de las clases que los implementan. Esto permite mantener las correspondientes relaciones de trazabilidad entre los diferentes artefactos del modelado.

Además, el hecho de que los requisitos surjan de la descripción de los procesos del negocio, y que éstos sean el resultado del análisis de los objetivos de la organización, posibilita que los requisitos del sistema sean validados y verificados contra los objetivos del negocio.

Además también encontramos su utilización en aplicaciones web. Los sitios Web, por lo general, son complejos y enormemente dinámicos. Requieren fases de desarrollo cortas con la finalidad de tener listo el producto y ejecutarlo rápidamente. Con frecuencia, los desarrolladores van directo hacia la fase de codificación sin comprender que están tratando de construir o como quieren construirlo. La codificación respecto del servidor con frecuencia se hace ad hoc, las tablas de bases de datos se agregan conforme se necesitan y la arquitectura evoluciona en una forma a veces no intencional.

El análisis de requisitos para las WebApps abarca tres grandes tareas: Formulación, recopilación de requisitos, y modelado de análisis. Durante la formulación se identifica la motivación (metas) y los objetivos básicos para la WebApp, y también se define las categorías de usuario. Los requisitos de contenido y funcionales se enlistan y se desarrollan los escenarios de interacción (casos de uso) descritos desde el punto de vista del usuario final.

La jerarquía de usuario. Las categorías de usuario finales que interactuarán con la WebApp se identifican como parte de las tareas de formulación y de recopilación de requisitos.

En la mayoría de los casos las categorías de usuario son relativamente limitadas y no necesitan de representación UML.

Desarrollo de casos de uso Los casos de uso se desarrollan par cada categoría de usuario descrita en la jerarquía de usuario. En el contexto de ingeniería Web, el caso de uso en sí mismo es relativamente informal: un párrafo narrativo que describe una interacción específica entre un usuario y la WebApp.

CONCLUSIÓN Recordemos que el objetivo de la ingeniería del software es el desarrollo de sistemas apegados a las necesidades del cliente, pero también ajustados a otros criterios, como el modelo de negocio, los recursos disponibles y el tiempo de entrega. Es obvio espero, que la ingeniería del software no solo ha de cumplir con la funcionalidad (escribir código ajustado a los requisitos funcionales) sino también con las cualidad suplementarias (requisitos no funcionales) o de lo contrario no cumplirá con su misión: desarrollar el software que se necesita en el momento y condiciones que se tienen disponibles; o dicho de otra manera, desarrollar software de calidad.

También nos damos cuenta que el modelado de requisitos nos sirve como propósito para comprender completamente el problema y todo lo que éste implica. El objetivo principal del sistema es capturar la funcionalidad que debe ofrecer desde la perspectiva del usuario.

Aprendimos que el modelo de requisitos de divide en funcionales y no funcionales lo que nos lleva a darnos cuenta cómo es que funcionara el modelo y las diferentes restricciones que se tiene.

REFERENCIAS

http://www.itescam.edu.mx/principal/sylabus/fpdb/recursos/r88205.PDF

http://www.itescam.edu.mx/principal/sylabus/fpdb/recursos/r88021.PDF

http://www.slideshare.net/msch/modelo-requistos

http://docencia.udea.edu.co/ingenieria/ArquitecturaSoftware/documentos/Del% 20Modelo%20Del%20Negocio%20Al%20Modelo%20De%20Requisitos.pdf

http://es.scribd.com/doc/32677971/36/Modelado-de-analisis-para-aplicaciones- web

http://www.infor.uva.es/~mlaguna/is1/apuntes/2-requisitos.pdf