Este documento presenta un enfoque de ingeniería de requisitos para modelar sistemas de información conceptualmente. El enfoque se basa en herramientas para especificar requisitos y en un método gráfico orientado a objetos para modelado conceptual que permite generar código automáticamente. El proceso define cómo construir un modelo de requisitos funcionales y cómo representar esos requisitos en el modelo conceptual.

1. INSTITUTO TECNOLÓGICO
DE TUXTEPEC
ING. EN SISTEMAS COMPUTACIONALES
“FUNDAMENTOS DE INGENIERÍA DEL
SOFTWARE”
UNIDAD II: INGENIERÍA DE REQUISITOS
ACTIVIDAD
“INVESTIGACIÓN SOBRE LAS APLICACIONES DEL
MODELADO Y SUS ESPECIFICACIONES”
PROFE:
MARIA DE LOS ANGELES MARTINEZ MORALES
ALUMNOS:
ANTONIO GOMEZ MARIA DEL ROSARIO
JORGE RAFAEL CLEOTILDE
MARTINEZ HERRERA KEREN ARADI
CONTI SANCHEZ CRISTHIAN JOAQUIN
VICENTE MENDOZA ANTONIO
19/SEPTIEMBRE/2012

2. CONTENIDO
En este trabajo se presenta un enfoque de Ingeniería de Requisitos para el
modelado conceptual de sistemas de información. Su principal objetivo es
proporcionar un conjunto de técnicas y guías para capturar los requisitos del
software, analizarlos y expresarlos en un esquema conceptual de OO-Method
garantizando la trazabilidad entre éstos. El enfoque se basa en un marco
referencial de herramientas de especificación de requisitos (TRADE) y un
método gráfico orientado a objetos para el modelado conceptual con
capacidades de generación automática de código (OO-Method). Se define la
estructura y técnicas para la construcción de un Modelo de Requisitos
funcionales del sistema y a partir de este modelo, un Proceso de Análisis de
Requisitos (PAR) define constructores que permiten representar dichos
requisitos en elementos del Modelo Conceptual de OO-Method. Utilizando este
proceso cada elemento del Modelo de Requisitos tiene una representación
perfectamente identificable en el Modelo Conceptual OO-Method y cada
elemento del Modelo Conceptual tiene su origen en el Modelo de Requisitos.

3. INTRODUCCIÓN
En este tema nos damos cuenta que a menudo los diseñadores de sistemas
cometen el error de comenzar a diseñar e implementar soluciones que no han
sido completamente especificadas y que corresponden a problemas a los que
les falta delimitación, lo cual conduce a la construcción de sistemas que no
satisfacen las necesidades de los clientes y que incurren en el aumento de los
costos y en el incumplimiento de los plazos establecidos.
Más aún, generalmente estos métodos carecen de directrices adecuadas para
el desarrollo de modelos conceptuales derivados de las especificaciones y
posteriormente de código que sea funcionalmente equivalente a dichos
modelos conceptuales.
Como un esfuerzo para la superación de estas limitaciones, en este trabajo se
presenta un enfoque sistemático de Ingeniería de Requisitos que define un
proceso que posibilita la descomposición sistemática y repetitiva de los
requisitos de software hasta obtener una detallada especificación que
constituirá el modelo conceptual del sistema deseado. Este enfoque pretende
mejorar la calidad del proceso de producción de software:
 Proporcionando predecibilidad mediante la construcción de un modelo
conceptual como una precisa, estructurada y bien definida
representación de los requisitos de los usuarios.
 Aumentando la productividad al establecer vínculos precisos entre el
modelo conceptual y los requisitos de los usuarios. Esto facilitará la
incorporación en el modelo conceptual de cambios en los requisitos. En
consecuencia, tales modificaciones quedarán reflejadas también en el
sistema de software desarrollado.

4. 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

5. 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.

6.  Á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

7. 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

8. 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:

9.  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.

10. 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.

11. 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.

12. 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