1. Materia Fundamentos de Ingeniería de
Software
Catedrático LI. Ma. Ma. De los Ángeles Martínez Morales
Unidad 2 ◘Ingeniería de requisitos◘
Actividad ►Investigación, Ingeniería de requisitos◄
Grupo 5 “A”
Integrantes del Lourdes Morales Susunaga
Equipo Danya Aritzayde Gomez Juan
Emmanuel Ramírez Canseco
Jose Roberto Spiritud Cruz
Ulises Sánchez Santiago.
Víctor Jiménez Villar
Fecha de Miércoles 19 de Septiembre del 2012
entrega
http://fund-ing-soft.blogspot.mx/

2. INTRODUCCION
La compresión de los requisitos de un problema esta entre las tareas más difíciles
que enfrenta un ingeniero de software. La meta del proceso de la ingeniería de
requisitos es crear y mantener un documento de requerimientos del sistema.
La ingeniera de requisitos ayuda los ingenieros de software a entender mejor el
problema en cuya solución trabajaran, Incluye el conjunto de tareas que conducen
a comprender cuál será el impacto del software sobre el negocio, que es lo que el
cliente quiere y como interactuaran los usuarios finales con el software.
La ingeniería de requisitos empieza con la fase de inicio, lo cual es una tarea que
define el ámbito y la naturaleza del problema que debe resolverse. Después
continúa con lo obtención, que es una tarea que ayuda al cliente a definir sus
necesidades; posteriormente sigue con lo elaboración, que es la fase donde se
refinan y modifican los requisitos básicos.
La ingeniería de requisitos, como todas las demás actividades de la ingeniería del
Software, debe adaptarse a las necesidades del proceso, el proyecto, el producto
y las personas que realizan el trabajo. Desde la perspectiva del proceso del
software, la ingeniería de requisitos es una acción de la ingeniería del software
que comienza durante la actividad de comunicación y continúa en la actividad de
modelado.
La ingeniería de requisitos proporciona el mecanismo apropiado para entender lo
que el cliente quiere, analizar las necesidades, evaluar la factibilidad, negociar una
solución razonable, especificar la solución sin ambigüedades, validar la
especificación, y administrar los requisitos conforme éstos se transforman en un
sistema operacional. El proceso de la ingeniería de requisitos se lleva a cabo a
través de siete distintas funciones: inicio, obtención, elaboración, negociación,
especificación, validación y gestión. (Pressman, 2002)

3. Inicio
En el inicio el ingeniero de requisitos puede crear una lista de personas que
contribuirán durante la obtención de requisitos. La lista inicial crecerá conforme se
establezca contacto con los interesados que son todos aquellos que se benefician
en una forma directa o indirecta del sistema que está en desarrollo.
El ingeniero de requisitos deberá categorizar toda la información de los
interesados en una forma que permita a quienes tomen las decisiones elegir un
conjunto de requisitos para el sistema que sean consistentes de manera interna.
Se identificaran las áreas en común y áreas de conflicto o inconsistencia (esto
es, los requisitos solicitados por un interesado que entran en conflicto con las
necesidades de otro) y por ultimo formular un conjunto de preguntas libres de
contexto que se enfocan en el cliente y otros interesados, metas generales y en
los beneficios, preguntas que permitan que el equipo de software comprenda
mejor el problema y el cliente exprese sus percepciones acerca de una solución y
una serie final de preguntas que se enfoquen en la efectividad de la actividad de
comunicación en sí misma.
Obtención
En esta etapa, los ingenieros de software trabajan con los clientes y usuarios
finales del sistema para determinar el dominio de la aplicación, que servicios
proporcionara el sistema, el rendimiento requerido del sistema, las restricciones de
hardware etc. Para lograr lo anterior se utiliza el despliegue de la función de
calidad (QFD, por sus siglas en inglés) es una técnica que traduce las
necesidades del cliente en requisitos técnicos para el software.

4. El QFD identifica tres tipos de requisitos:
Requisitos normales. Reflejan los objetivos y metas establecidos para un pro-
ducto o sistema durante las reuniones con el cliente. Si estos requisitos están
presentes, el cliente estará satisfecho. Algunos ejemplos de requisitos normales
podrían ser los tipos de gráficos en pantalla, las funciones específicas del sistema,
y los niveles de rendimiento solicitados.
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 explícita. Su ausencia causaría una insatisfacción significativa. Algunos
ejemplos son la facilidad de la interacción humano/máquina, corrección y
confiabilidad operacional general y facilidad en la instalación del software.
Requisitos estimulantes. Reflejan las características que van más allá de las
expectativas del cliente y que prueban ser muy satisfactorias cuando están
presentes. Por ejemplo, un software procesador de palabras se solicita con
características estándar. El producto entregado contiene varias capacidades de
configuración de página que son bastante satisfactorias e inesperadas.
Con forme se recopilan los requisitos los desarrolladores y usuarios pueden crear
un conjunto de escenarios que identifican una cadena de uso para el sistema que
se va a construir. Los escenarios, llamados con frecuencia casos de uso
proporcionan una descripción de cómo se usará el sistema.

5. Elaboración
El objetivo de este paso es la elaboración del modelo de análisis, describir los
dominios requeridos de información, funcionamiento y comportamiento para un
sistema basado en computadoras. El modelo de análisis es una representación de
los requisitos en un momento determinado, por lo que se espera que éste cambie.
Los elementos específicos del modelo de análisis los determina el método de
modelado que se utilice. Sin embargo, existe un conjunto de elementos genéricos
común a la mayoría de los modelos de análisis:
Elementos basados en escenarios. El sistema se describe, desde el punto de
vista del usuario, por medio de un enfoque basado en escenarios, con frecuencia
son los primeros que se desarrollan durante la elaboración del modelo. Por tal
motivo, sirven como una entrada para la creación de otros elementos de
modelado.
Elementos basados en clases. Cada escenario de uso implica un conjunto de
"objetos" que se manipula mientras un actor interactúa con el sistema. Estos
objetos se clasifican en clases: una colección de clases con atributos similares y
comportamientos en común.
Además de los diagramas de clase, otros elementos del modelado del análisis
muestran la forma en que las clases colaboran con uno y otro y las relaciones e
interacciones entre las clases.
Elementos de comportamiento. El comportamiento de un sistema basado en
computadora puede tener un profundo efecto sobre el diseño que se elija, así
como en 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.
Además, el diagrama de estado indica las acciones (por ejemplo, la activación del
proceso) que se toman como consecuencia de un evento particular.

6. Elementos orientados al flujo. Cuando la información fluye a través de un
sistema basado en computadora, ésta se transforma. El sistema acepta la entrada
de una variedad de formas, aplica funciones para transformarla y produce una
salida también en formas diferente.
Negociación
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 del 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 (por ejemplo, tiempo, gente, presupuesto) a la, que está sometido
el equipo de software.
Especificación
La especificación es el producto de trabajo final que genera la ingeniería de
requisitos. Sirve como base para las actividades de ingeniería de software
subsecuentes.
Describe la función y el desempeño de un sistema basado en computadora y las
restricciones que regirán su desarrollo.

7. Validación
La validación de requerimientos trata de mostrar que estos realmente definen el
sistema que el cliente desea La validación de requerimientos es importante debido
a que los errores en el documento de requerimientos pueden conducir a
importantes coste al repetir el trabajo cuando son descubiertos durante el
desarrollo o después de que el sistema esté en uso.
Durante este proceso, se deben llevar a cabo verificaciones sobre requerimientos
en el documento de requerimientos, estas verificaciones comprenden:
(Sommerville, 2005)
1. Verificación de validez: Si se requieren funciones adicionales o diferentes.
2. Verificaciones de consistencia: No debe haber restricciones o descripciones
contradictorias de la misma función del sistema.
3. Verificaciones de completitud: Debe incluir todas las funciones y
restricciones propuestas por el usuario.
4. Verificaciones de realismo: Debe verificarse que los requerimientos se
puedan implementar.
5. Verificabilidad. Los requerimientos del sistema deben redactarse de tal
forma que sean verificables.
Gestión
La gestión de requerimientos es el proceso de comprendes y controlar los cambios
en los requerimientos del sistema Es necesario mantenerse al tanto de los
requerimientos particulares y mantener vínculos entre los requerimientos
dependientes de forma que se pueda evaluar el impacto de los cambios.
El proceso de gestión de requerimientos debería empezar en cuanto se tenga una
versión preliminar de documento de requerimientos, pero se debería empezar a
planificar como gestionar los requerimientos que cambian durante el proceso de
obtención de requerimientos.

8. CONCLUSION
Antes de que el diseño y la construcción de un sistema basado en
computadora puedan comenzar. Es necesario entender los requisitos. Esto se
logra realizando una serie de tareas de ingeniería de requisitos. La cual se lleva a
cabo durante las actividades de comunicación con el cliente y modelado que han
sido definidas para el proceso genérico del software.
Al inicio del proyecto el desarrollador y el cliente (así como otros interesados)
establecen los requisitos básicos del problema, definen las restricciones
predominantes del proyecto y especifican las características y funciones más
importantes que deben estar presentes en el sistema para que éste alcance sus
objetivos.
Esta información es expandida y refinada durante la obtención, una actividad para
la recopilación de requisitos que emplea reuniones que encabeza un moderador
facilitadas, el QFD y el desarrollo de escenarios de uso.
La elaboración posterior expande los requisitos hacia un modelo de análisis; es
decir, una colección de elementos del modelo basados en escenarios, en
actividades y en clases, de comportamiento y orientados al flujo. En la creación de
estos elementos se puede utilizar una variedad de notaciones de modelado.
Cuando se identifican los requisitos y se crea el modelo de análisis, el equipo de
software, el cliente y otros interesados en el proyecto negocian la prioridad,
disponibilidad y costo relativo de cada requisito. El objetivo de esta negociación es
desarrollar un plan de proyecto realista. Además. Cada requisito y el modelo de
análisis como un todo se validan contrastándolos con las necesidades del cliente
para asegurar que se construirá el sistema correcto

9. Fuentes de Información
Pressman, R. S. (2002). Ingenieria de Software. Un enfoque practico. McGraw-Hill.
Sommerville, I. (2005). Ingenieria de Software. Pearson Education.