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.
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 funcionales 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. 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.
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 específica 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 estos y los que pertenecen
al Proceso de Análisis de Requisitos.
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.
Bibliografia:
