DESARROLLO

El modelado de requisitos nos sirve y tiene como propsito 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.
Adems el modelo de requisitos captura las principales caractersticas 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 adems entenderlo, sin necesidad de tener
conocimientos previos al modelo e informacin. Intervienen en el los modelos
de caso de uso, que desempean 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 adems, las restricciones sobre su operacin e
implementacin. La elicitacin, anlisis y especificacin de requisitos es el
proceso del estudio de las necesidades de los usuarios para llegar a una
definicin de los requisitos del sistema.
Un requisito es una condicin o capacidad que necesita el usuario para
resolver un problema o conseguir un objetivo determinado. Puede verse como
una declaracin abstracta de alto nivel de un servicio que el sistema debe
proporcionar.
Los requisitos funcionales: son la caracterstica requerida del sistema que
expresa una capacidad de accin del mismo, una funcionalidad; generalmente
expresada en una declaracin 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
codificacin si bien es cierto que pueden llegar a afectar a esta. Pueden ser
frases muy generales sobre lo que el sistema debera 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: caracterstica requerida del sistema, del proceso
de desarrollo, del servicio prestado o de cualquier otro aspecto del desarrollo,
que seala una restriccin del mismo. Son todas las exigencias de cualidades
que se imponen al proyecto: exigencias de usar un cierto lenguaje de
programacin o plataforma tecnolgica, por ejemplo, Un requisito no funcional

es una caracterstica ya sea del sistema, del proyecto o del servicio de soporte,
que nos es requerida junto con la especificacin del sistema pero que como ya
dije, no se satisface aadiendo cdigo, sino cumpliendo con esta como si de
una restriccin 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 polticas y
procedimientos existentes en la organizacin.
Requisitos externos: presentan factores externos al sistema y a su proceso
de desarrollo.
Adems, 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 difciles de expresar con exactitud, ya que los requisitos
imprecisos pueden ser difciles 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 especificacin debe ser completa
y consistente, completa en el sentido de que todos los servicios solicitados por
el usuario estn definidos. Y consistente en que los requisitos no tengan
definiciones contradictorias.
El proceso de anlisis de requisitos, considera los aspectos relativos al anlisis
de las funcionalidades y la traduccin al modelo conceptual.
Existen tres tcnicas que nos permiten generar el modelo de requisitos:

Misin del sistema: describe cual es el propsito del sistema, sus

responsabilidades y el alcance que tendr. A travs de l podemos
determinar, en trminos generales, que har y que no har el sistema.
Aunque es una tcnica sencilla es de vital importancia para el desarrollo
del sistema.

rbol de refinamiento de funciones: descompone el sistema en

interacciones externas, de acuerdo a algn criterio preestablecido. Cabe
mencionar que las interacciones externas son organizadas en funciones
que forman una jerarqua a manera de rbol, en cuyo nivel ms alto
(raz) se ubica la misin del sistema. Esta Misin del Sistema es refinada
hasta obtener otras funciones elementales representadas en la
jerarqua a travs de los nodos hoja. Este proceso descendente de
refinamiento funcional puede generar distintos niveles de nodos.
Aquellos que estn entre la raz 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
raz del rbol, representa toda la funcionalidad relativa a un rea o
actividad de la organizacin, segn el criterio de descomposicin
utilizado.

Modelo de casos de uso: El modelado de requisitos utiliza los elementos

del Modelo de Casos de Uso. De esta forma, la especificacin 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 especificacin 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 satisfaccin de los requisitos.

Describe un sistema en trmino de sus distintas formas de utilizacin, 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 informacin con el sistema. No estn restringidos
a ser personas fsicas, 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 ms 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 especificacin, a manera de
conversacin, a travs de una secuencia numerada de pasos. Esta

clasificacin 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 tamao y detalle adquiriendo formas complejas que limitan su
comprensin y posterior uso en las distintas etapas de la construccin del
sistema. Con el propsito de minimizar el impacto de estos problemas, la
descripcin de los casos de uso es estructurada precisndose su nivel de
detalle en trminos de las necesidades del modelado y del momento de
desarrollo del sistema.
El nivel de abstraccin de un caso de uso est vinculado al contenido
informativo relevante o significativo que se desea expresar en el caso de
uso.
El propsito principal de este proceso es identificar las responsabilidades
ms significativas del sistema en desarrollo. Las responsabilidades
conllevan a la definicin de operaciones, esto es, a la especificacin de los
servicios de una clase.
Con el propsito de describir las responsabilidades detectadas en el
contexto de un Caso de Uso se utilizan Diagramas de Secuencia con
notacin 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 asignacin de responsabilidades entre
los objetos, el Proceso de Anlisis de Requisitos prev la especificacin de
Diagramas de Secuencia pero a muy alto nivel y como herramienta para
representar estas responsabilidades.
Un escenario es una secuencia especfica de las acciones que describe un
caso de uso. As, un caso de uso puede ser considerado como la
compilacin de mltiples 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 interaccin
entre objetos o clases. A travs de estos diagramas se muestra la
secuencia ordenada en el tiempo de los mensajes que envan y reciben
genricamente los objetos durante la ejecucin de un escenario. Un
estmulo es una comunicacin entre dos objetos que se transmiten
informacin 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 estmulo (el servidor) as como la accin que

ser ejecutada. De esta forma, a travs de los mensajes se expresan las

responsabilidades que cumplirn los objetos en el sistema.
En el Proceso de Anlisis de Requisitos, es posible utilizar dos tipos de
diagramas de secuencia,
que va a depender del momento y estrategia
de desarrollo seguida as como tambin del nivel de detalle deseado.
1) OO-Method: hace nfasis en la interaccin, en trminos 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 especificacin de Casos de Uso con sus pasos se obtiene
automticamente donde cada paso se convierte en un auto-mensaje).
2) La evolucin 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 tambin las clases de objetos clientes
y servidores.
El Proceso de Anlisis de Requisitos consiste, bsicamente, en la construccin
de los diagramas de secuencia OO-Method a partir del Modelo de Requisitos
del sistema.
Los diagramas de secuencia, adems de expresar en detalle los resultados del
Proceso de Anlisis de Requisitos, constituyen un recurso de mucha
importancia para la construccin del Modelo de Objetos. Con esta finalidad, se
ha incorporado en estos diagramas cierta informacin que resulta de inters
para identificar elementos de este modelo. Esta informacin se expresa
estereotipando los mensajes del diagrama de secuencia con el propsito de
distinguirlos segn la clasificacin.

El modelo de trazabilidad es utilizado para relacionar los distintos elementos

del Enfoque de Ingeniera de Requisitos con los elementos del Modelo
Conceptual, se caracteriza por ser estructural y estar basado en referencias
cruzadas. Esto significa, que la relacin establecida entre estos elementos es
estructural. En segundo lugar, se establecen explcitamente referencias entre
los elementos a diferentes niveles de abstraccin.
Por otra parte, la trazabilidad en el enfoque de Ingeniera de Requisitos puede
ser estudiada desde dos perspectivas:

Internamente.- la trazabilidad es establecida entre los elementos de las

distintas tcnicas del Modelo de Requisitos y entre stos y los que
pertenecen al Proceso de Anlisis de Requisitos.
Externamente, la trazabilidad queda determinada por los vnculos
establecidos entre los elementos de dicho proceso y los constructores
del Modelo Conceptual.

Encontramos dentro de ste proceso la validacin y gestin 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 validacin funge como un factor muy importante en dicho proceso.
La gestin 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 organizacin 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 jerrquicamente y se facilita su desarrollo iterativo e incremental.
Las clases del modelo conceptual se obtienen a partir de los objetos de
informacin 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
organizacin se recogen en un glosario, en forma de especificacin de las
actividades y de los casos de uso asociados, as como de los objetos de
informacin y de las clases que los implementan. Esto permite mantener las
correspondientes relaciones de trazabilidad entre los diferentes artefactos del
modelado.
Adems, el hecho de que los requisitos surjan de la descripcin de los
procesos del negocio, y que stos sean el resultado del anlisis de los objetivos
de la organizacin, posibilita que los requisitos del sistema sean validados y
verificados contra los objetivos del negocio.
Adems tambin encontramos su utilizacin en aplicaciones web. Los sitios
Web, por lo general, son complejos y enormemente dinmicos. Requieren
fases de desarrollo cortas con la finalidad de tener listo el producto y ejecutarlo
rpidamente. Con frecuencia, los desarrolladores van directo hacia la fase de
codificacin sin comprender que estn tratando de construir o como quieren
construirlo. La codificacin 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 anlisis de requisitos para las WebApps abarca tres grandes tareas:

Formulacin, recopilacin de requisitos, y modelado de anlisis. Durante la
formulacin se identifica la motivacin (metas) y los objetivos bsicos para la
WebApp, y tambin se define las categoras de usuario. Los requisitos de
contenido y funcionales se enlistan y se desarrollan los escenarios de
interaccin (casos de uso) descritos desde el punto de vista del usuario final.

La jerarqua de usuario.
Las categoras de usuario finales que interactuarn con la WebApp se
identifican como parte de las tareas de formulacin y de recopilacin de
requisitos.

En la mayora de los casos las categoras de usuario son relativamente

limitadas y no necesitan de representacin UML.

Desarrollo de casos de uso

Los casos de uso se desarrollan par cada categora de usuario descrita en la
jerarqua de usuario. En el contexto de ingeniera Web, el caso de uso en s
mismo es relativamente informal: un prrafo narrativo que describe una
interaccin especfica entre un usuario y la WebApp.

CONCLUSIN

Recordemos que el objetivo de la ingeniera del software es el desarrollo de

sistemas apegados a las necesidades del cliente, pero tambin ajustados a
otros criterios, como el modelo de negocio, los recursos disponibles y el tiempo
de entrega. Es obvio espero, que la ingeniera del software no solo ha de
cumplir con la funcionalidad (escribir cdigo ajustado a los requisitos
funcionales) sino tambin con las cualidad suplementarias (requisitos no
funcionales) o de lo contrario no cumplir con su misin: desarrollar el software
que se necesita en el momento y condiciones que se tienen disponibles; o
dicho de otra manera, desarrollar software de calidad.

Tambin nos damos cuenta que el modelado de requisitos nos sirve como
propsito 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 cmo 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-aplicacionesweb

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