Este documento presenta información sobre las tareas de la ingeniería de requisitos para el desarrollo de software. Describe las siete fases principales de la ingeniería de requisitos - inicio, obtención, elaboración, negociación, especificación, validación y gestión - y explica las actividades involucradas en cada una. También discute conceptos como casos de uso, modelos de análisis y patrones de requisitos, que son importantes para comprender y documentar los requisitos del cliente.

1. Instituto Tecnológico De Tuxtepec
Materia: Fundamentos de la Ingeniería del
Software.
Catedrático: María De Los Ángeles Morales Martínez
Trabajo: Investigación de las tareas de la ingeniería de requisitos
Alumnos:
Cynthia Del Carmen Barrera Villa
Raziel Iván Peña Calderón
Aradi Pineda Barranca
Axel Huerta Morales
Ivonne Ángeles Ideaquiz
Ismael De Jesús Contreras Rebolledo
Grado & Grupo: I.S.C. 5° ‘A’
Fecha de Entrega:
Miércoles 18/septiembre/2012

2. Introducción:
La ingeniería de requisitos es una herramienta fundamental para los Ingenieros en
Sistema Computacionales, ya que mediante ella podemos analizar mejor el
problema que tenemos y de esta manera es más sencillo hallar una solución
óptima en la cual se trabajara.
La importancia que tiene la Ingeniería de Requisitos es alta dado a que sin ella no
se debe de comenzar a trabajar en el proyecto debido a que uno no sabe con
exactitud que es lo que e cliente en realidad requiere.
Las fases de la ingeniería de requisitos comienza por la fase del inicio en la cual
se define el ámbito y la naturaleza del problema a resolver, posteriormente la
obtención la cual es una tarea que ayuda al cliente a definir sus necesidades,
sigue la elaboración en la cual se refinan y modifican los requisitos básicos, y una
vez que ha definido ya el problema viene a cabo lo que es la negociación donde
se definen cuales son las prioridades cuales aspectos son esenciales y el
momento en el cual se requieren, y por ultimo el problema se especifica de alguna
manera y después es validado y revisado para asegurar la concepción del
problema que tiene el ingeniero de software coincide con la percepción del cliente.

3. El objetivo del proceso de la ingeniería de requisitos es darle a todas las partes
una explicación escrita del problema. Esto se puede lograr por medio de varios
productos de trabajo como lo son escenarios de uso, listas de funciones y
características, modelos de análisis o alguna especificación.
La ingeniería de requisitos debe adaptarse a las necesidades del proceso, el
proyecto, el producto y a las personas que realizan el trabajo. La ingeniería de
requisitos esuna acción de la ingeniería de software la cual se comienza durante la
actividad de la comunicación y dicha continua en la actividad de modelado. En
algunos casos se elige un enfoque abreviado, aunque en otros casos cada una
de las tareas es definida para poder comprender los requisitos los cuales se
llevan de manera muy rigurosa, en el cual el equipo de software debe adaptarse
al enfoque de la ingeniería de requisitos, en el cual dicho equipo debe entender
los requisitos del problema antes de intentar resolverlo.
La ingeniería de requisitos proporciona el mecanismo apropiado para entender lo
que el cliente quiere y así analizar las necesidades, evaluar la factibilidad,
negociar una solución razonable, especificar la solución sin ambigüedades,
validar las especificaciones y administrar los requisitos conforme a estos se
transforme en el sistema operacional. El proceso de la ingeniería de requisitos se
lleva a cabo a través de 7 distintas funciones las cuales son: Inicio, obtención,
elaboración, negociación, especificación validación y gestión. Las cuales están
dirigidas a definir lo que el cliente quiere y todas sirven para establecer una base
solida con respecto al diseño y la construcción de lo obtendrá el cliente.
Comencemos por plantear cada una de las fases de ingeniería de requisitos.
Inicio:
Al inicio del proyecto los ingenieros de software hacen una seriede preguntas
libres de contexto en las cuales, su objetivo es establecer una comprensión básica
del problema, la comunicación preliminar entre el cliente y el desarrollador
permite que los clientes expongan su problema y con ello dar paso a unasolución
deseada. Por lo general la mayoría de los proyectos comienzan cuando se

4. identifica una necesidad de negocios o se descubre un nuevo mercado o servicio
potencial. Cabe aclarar que toda esta información esta sujeta a cambios, sin
embargo estas conversaciones se van adecuando a la ingeniería del software.
En el inicio el desarrollador de software debe identificar a los interesados los
cuales son, aquellas perdonas que van a interactuar de forma directa con el
sistema que se desarrollara o aquellas personas que obtienen beneficios de este.
Posteriormente preguntar a los interesados sus puntos de vista y después entre
todos elegir un conjunto de requisitos para el sistema y de esta manera el sistema
sea consistente. Ya que se tiene esto se procede a identificar las áreas en común
(requisitos en los que todos los interesados están de acuerdo) y las áreas de
conflicto, lo cual es un gran desafío.
Ya que se tiene esto se pasa a la formulación de preguntas en la cuales la
información proporcionada será de gran importancia ya que depende de ellas
conocer la metas generales así como los beneficios.
Las preguntas nos ayudaran a romper el hielo y nos permitirán iniciar la
conversación inicial para la obtención exitosa, pero estas preguntas solo deben
ser utilizadas en el principio, en caso denecesitar mas información en las
siguientes fases de la construcción del software se deben de remplazar por un
formato de obtenciónde requisitos.
Obtención:
La obtención de requisitos es mas detallada, como ya se menciono anteriormente
la sesión de preguntas y repuestas solo debe de ser utilizada para el primer
encuentro, y después debe de remplazarse por un formato de obtención de
requisitos que combine elementos como lo son la resolución, elaboración
negociación y especificación del problema.
Durante la fase del inicio la preguntas y repuestas básicas establecen un ámbito
del problema y la percepción global de la solución, fuera de estas reuniones

5. iniciales los participantes escriben una solicitud de producto de una o 2 paginas
en la cual se fija un lugar, una hora y una fecha para una reunión y se selecciona
un moderador, en la cual los miembros del equipo de software y otras
organizaciones interesadas son invitadas a asistir. La solicitud de producto se
distribuye a todos los asistentes antes de la fecha de reunión para así tengan
tiempo de revisarla y así hacer una lista de los objetos que son parte del ambiente
que rodea al sistema, otros objetos que este producirá y objetos que utiliza para
sus funciones, así como también una lista de servicios que manipulas o
interactúan con los objetos y por ultimo la lista con restricciones y criterios de
rendimiento. Y se le informa a los asistentes que la lista debe de reflejar la
percepción de cada persona sobre el sistema. Cuando se inicia la reunión el
primer tópico que se trata de la necesidad y la justificación para el nuevo producto,
en el cual todos los participantes debende estar de acuerdo en que la necesidad
del producto se justifica, una vez establecido el acuerdo cada participante
presenta sus listas para examinarlas. Después de que las listas se hallan
presentado el grupo crea una lista combinada para todas las áreas en los distintos
tópicos, tal lista se reduce o se incrementa dependiendo de como se apropia el
producto/sistema que se desarrollara.
Teniendo todo esto se puede proseguir con el despliegue de la función de la
calidad(QFD por sus siglas en ingles), la cual es una técnica que traduce las
necesidades del cliente en requisitos técnicos para el software, y este se
concentra en aumentar la satisfacción del cliente desde el proceso de la
ingeniería del software, para lograr esto, el QFD resalta una comprensión de lo
que es valioso para el cliente y después despliega estos valores durante el
proceso de ingeniería en el cual el QFD identifica 3 tipos de requisitos.
Requisitos normales: Reflejan los objetivos y metas establecidos para un producto
o sistema durante las reuniones con e cliente. Si dichos requisitos están
presentes, el cliente estará satisfecho.

6. Requisitos esperados: están implícitos en el producto o sistema y pueden parecer
tan obvios, aunque son fundamentales, que el cliente no los establece de manera
explicita. Su ausencia causaría una insatisfacción significativa.
Requisitos estimulantes: reflejan las características que van masallá de las
expectativas del cliente y que prueban ser muy satisfactorias cuando están
presentes.
En la actualidad el QFD barca la totalidad del proceso de la ingeniería. Sin
embargo muchos conceptos del QFD son aplicables a la actividad de obtención
de requisitos.
A los ingenieros les resulta difícil entender como aplicaran las funciones y
características los usuarios finales por lo cual los desarrolladores y usuarios
finales crean un conjunto de escenarios que identifican una cadena para el uso
del sistema a construir. Los escenarios llamados con frecuencia casos de uso
proporcionan una descripción de como se usara el sistema.
Los productos de trabajo producidos como consecuencia de la obtención de
requisitosvaria de acuerdo con el tamaño del sistema o producto que se valla a
construir. Y cada una de los trabajos los revisa toda la gente que ha participado en
la obtención de requisitos.
Elaboración:
Dentro de esta fase se encuentra el desarrollo de casos que es en esencia una
historia estilizada de la manera en que un usuario final interactúa con el sistema
en un conjunto especifico de circunstancias. Para poder llevarloa cabo primero
que nada se debe definir el conjunto de actores que estarán involucrados en la
historia. Cabe destacar que un actor y un usuario final no son necesariamente lo
mismo. Después de la revisión cuidadosa de los requisitos el software de control
requiere de 4 diferentes modos para su interacción de los cuales son, modo de
programación, modo de prueba, modo monitoreo y modo de resolución de
problemas.

7. Y dentro de esta misma fase se encuentra el modelo de análisis en el cual su
objetivo es describir los dominios requeridos de información, funcionamiento y
comportamiento para un sistema basado en computadoras. Conforme el modelo
de análisis evoluciona ciertos elementos se volverán relativamente estables por
lo cual proporcionaran una base solida para las tareas de diseño.
Los elementos del modelo de análisis
Existe una gran diversidad de maneras de buscar los requisitos para un sistema
basado en una computadora. Los elementos específicos del modelo de analisis
los determina el método de modelado, sin embargo existe un conjunto de
elementos genéricos común a la mayoría de los modelos de análisis que son los
siguientes:
Elementos basados en escenarios: en este el sistema se describe, desde el punto
de vista del usuario, por medio de un enfoque basado en escenarios, los
elementos del modelo de análisis basados en escenario con frecuencia son los
primeros que se desarrollan en la elaboración del modelo. Y en este se muestran
las actividades o funciones que han sido definidas como parte de la tarea de
obtención de requisitos. Los modelos en esta categoría pueden definirse de
manera iterativa.
Elementos basados en clases: en cada escenario se utiliza un conjunto de objetos
los cuales se clasifican en clases, una colección de atributos similares y
comportamientos en común.
Elementos de comportamiento: el comportamiento de un sistema basado en
unacomputadora puede tener un profundo efecto sobre el diseño que se elija, así
como el enfoque de implementación que se aplique. Por lo tanto el modelo de
análisis debe proporcionar elementos de modelado que muestren el
comportamiento. El diagrama de estado es un método para representar el
comportamiento de un sistema al mostrar sus estados y los eventos que
ocasionan que dicho sistema cambie de estado. Un estado es cualquier forma de
comportamiento observable.

8. Elementos orientados al flujo: cuando la información fluye a través de un sistema
basado en computadora, esta se transforma. El sistema acepta la entrada en
variedad de formas, aplica funciones para transformarla y produce una salida
también en formas diferentes.
Patrones de análisis son aquellascosas que suceden de manera recurrente en
todos los proyectos dentro de un dominio de aplicación que puede reutilizarse al
modelar muchas aplicaciones. Los patrones de análisis se integran al modelo
respectivo mediante una referencia al nombre del patrón, estos también se
encuentran almacenados en un depósito para que los ingenieros de requisitos
puedan utilizar los servicios de búsqueda y así encontrarlos y reutilizarlos.
Negociación:
En un contexto ideal de la ingeniería de requisitos, las tareas de inicio, obtención
y elaboración determinan requisitos con el suficiente detalle como para
emprender los pasos subsecuentes de la ingeniería del software.
Desafortunadamente esto sucede muy rara vez, pues el cliente y el desarrollador
entran en un proceso de negociación, en el cual se le debe pedir al cliente un
balance de la funcionalidad el rendimiento y otras características del sistema o
producto frente al costo y el tiempo de colocación en el mercado. El objetivo de
esta negociación, es desarrollar un plan de proyecto que satisfaga las
necesidades del cliente al mismo tiempo que refleja las restricciones del mundo
real, alas cuales esta sometido el equipo de software.
Las mejores negociaciones son aquella que buscan un resultado del tipo ganar-
ganar. Esto es, el cliente gana al obtener el sistema o producto que satisface la
mayoría de sus necesidades, y el equipo de software gana al trabajar con
presupuestos y limites de tiempos realistas y alcanzables.

9. Validación:
Al crear cada elemento del modelo de análisis, este se examina para conocer su
consistencia, omisiones y ambigüedades. A los requisitos que representa el
modelo el cliente les da la jerarquía y se agrupan en paquetes de requisitos que se
implementan como incrementos de software y se le entregan. Una revisión del
modelo de análisis se enfoca en las siguientes preguntas:
¿cada requisito es consistente con el objetivo general del
sistema/producto?
¿todos los requisitos han sido especificados con el grado apropiado de
abstracción?
¿el requisito es necesario en realidad o representa una característica
agregada irrelevante para el objetivo del sistema?
¿cada requisito esta limitado y no es ambiguo?
¿cada requisito tiene una atribución?
¿algunos requisitos entran en conflicto con otros?
Cada requisito es alcanzable en el ambiente técnico que recibirá al sistema
o producto?
¿cada requisito se puede probar una vez que este haya sido
implementado?
¿el modelo de requisitos refleja de manera apropiada la información, la
función y el comportamiento del sistema que será construido?
¿el modelo de requisitos se ha sometido a partición para que se exponga
en forma progresiva información mas detallada acerca del sistema?
¿se han usado patrones de requisitos par simplificar el modelo de
requisitos?,¿todos los patrones se han validado de manera apropiada?,
¿todos los patrones son consistentes en los requisitos del cliente?
Estas y otras preguntas deben realizarse y contestarse para asegurar que el
modelo de requisitos es el reflejo exacto de las necesidades del clientey que
proporciona una base solida para el diseño.

10. Conclusión.
Como ya se vio anteriormente para la creación o desarrollo de algún sistema
antes que nada es necesario entender los requisitos del cliente. Esto se logra
realizando la serie de tareas de la ingeniería de requisitos mencionadas
anteriormente, las cuales se llevan a cabo durante las actividades de
comunicación con el cliente y modelado que han sido definidas para el proceso
genérico del software. Los miembros del equipo de software realizan 7 funciones
distintas dentro de la ingeniería de requisitos: las cuales son: inicio, obtención,
elaboración negociación, especificación validación y gestión. Como ya se vio las
tareas de la ingeniería de requisitos son de tal importancia debido a que gracias a
ella obtenemos información gran importancia para desarrollar el software, debido
a que sin la ayuda de estas tareas los ingenieros de software no sabrían a
manera concreta que es lo que desea el cliente y como lo quiere estructurado, la
ingeniería de requisitos no es nada fácil debido a que se debe de realiza un sinfín
de movimientos antes de comenzar a desarrollar el software, lo cual también
necesitad e prueban ante los usuarios finales y ver cuales son las fallas que tiene
o características con mayor importancia.

11. Referencias.
(Pressman, 2008).