1.
INSTITUTO
TECNOLÓGICO DE
NOMBRE DE LA UNIDAD:
TUXTEPEC
INGENERIA DE REQUISITOS
FUNDAMENTO DE INGENERIA
DE SOFTWARE
ALUMNOS:
MARIA DEL ROSARIO ANTONIO GOMEZ
CLEOTILDE JORGE RAFAEL
KEREN ARADI MARTINEZ HERRERA
CRISTHIAN JOAQUIN CONTI SANCHEZ Tema
ANTONIO VICIENTE MENDOZA Tareas de ingeniería de
software
19/09/2012

2.
Introducción
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 estos se transforman en un
sistema operacional. Existen muchos procesos de desarrollo de software con una
gran serie de estándares para medir.En el proceso de la ingeniería de requisitos
se ejecutan las tareas de inicio, obtención, elaboración, negociación,
especificación, validación y gestión. Dichas funciones deben adaptarse a las
necesidades y particularidades de cada proyecto. En este caso se hablara de las
tareas, actividades o funciones que debe efectuar para llegar a esta meta.

3.
TAREAS DE INGENERÍA DE
SOTWARE
INICIO
Tienepor objetivo identificar el ámbito general del proyecto. Comienza con una
serie de conversaciones informales entre los participantes del mismo (cliente,
usuarios, grupo de desarrollo).
Esta fase suele estar acompañada de los documentos de definición de la visión
global y la visión de dominio del sistema.
Según Carpers Jones dice “por lo general, las semillas de los desastres más
importantes en software se siembra en los primeros tres meses desde el comienzo
del proyecto”
En algunos casos una conversación informal es todo lo que se necesita para
precipitar un esfuerzo importante de ingeniería del software. Pero en general, la
mayoría de los proyectos comienza cuando se identifica una necesidad de
negocios o se descubre un nuevo mercado o servicio potencial. Los participantes
de la comunidad de negocios(es decir, los gerentes, gentes de mercadotecnia,
gentes de producto) definen un caso de negocios para la idea, tratan de identificar
la amplitud y profundidad del mercado, hacen un análisis preliminar de factibilidad,
e identifican una descripción funcional del ámbito del proyecto. Toda esta
información está sujeta a cambios (una situación probable) pero es suficiente para
suscitar conversaciones con la organización de ingeniería del software.
Al inicio del proyecto los ingenieros de software hacen una serie de preguntas
libres de contexto, el objetivo es establecer una comprensión básica del problema,
las personas que quieren una solución, la naturaleza de la solución que se desea,
y la efectividad de la comunicación preliminar entre el cliente y el desarrollador.

4.
OBTENCIÓN
Sugiere a los ingenieros actividades de recopilación de requisitos de manera
organizada.Parece muy simple preguntar al cliente, a los usuarios y otros
interesados cuáles son los objetivos para el sistema o producto, que es lo que se
debe lograr, de que forma el producto satisface las necesidades del negocio y por
último como se utilizara el sistema o producto día a día. Pero no es simple, es muy
difícil ya que se identifican una serie de problemas que ayudan a entender porque
es difícil la obtención de requisitos:
Problema de ámbito: El límite del sistema está mal definido o los
clientes/usuarios especifican detalles técnicos innecesarios que pueden
confundir, en lugar de clarificar, los objetivos generales del sistema.
Problemas de comprensión: Los clientes/usuarios no están seguros por
completo de que es lo se necesita, comprenden poco acerca de las
capacidades ylimitaciones de sus ambiente de computo, no comprende del
todo dominio del problema, tienen dificultades al comunicar necesidades al
ingeniero de sistema, omiten información que consideran “obvia”,
especifican requisitos que chocan con las necesidades de otros
clientes/usuarios, o especifican requisitos ambiguos o inestable.
Problemas de volatilidad:Los problemas cambiara conformé transcurre el
tiempo.
Para ayudar a superar estos problemas, los ingenieros de requisitos deben
realizar en forma organizada la actividad de recopilación de requisitos
ELABORACIÓN
Los ingenieros de software crean un modelo de análisis con la información
obtenida del cliente en las fases de inicio y obtención. El modelo de análisis
define el dominio de la información, las funciones y el compartimiento del

5.
problema.La información conseguida con el cliente durante el inicio y obtención se
expande y se refina durante la elaboración. Esta actividad de la ingeniería de
requisitos se enfoca en el desarrollo de un modelo técnico refinado de las
funciones, características y restricciones del software.
La elaboración del modelado del análisis y su componente de una serie de tareas
de modelado y refinamiento. La elaboración se conduce mediante la creación y
refinamiento de escenarios del usuario que describen la forma en que el usuario
final(y otros actores) interactuaran con el sistema. Cada escenario del usuario se
analiza para obtener clases del análisis: entidades del dominio de negocios
visibles para el usuario final. Se definen los atributos de cada clase de análisis y
se identifican los servicios que requiere cada clase. Se identifican las relaciones y
la colaboración entre las clases y se produce una variedad de diagramas de UML
complementarios.
El resultado final de la elaboración es un modelo de análisis que definen el
dominio de la información, las funciones y el comportamiento del problema.
NEGOCIACIÓN
Durante esta etapa el ingeniero de requisitos debe negociar con el cliente los
alcances y límites del sistema. De forma iterativa los requisitos se priorizan,
modifican, combinan o eliminan buscando acuerdos que beneficien a todas las
partes.
Dados los recursos limitados del negocio, no resulta inusual que los clientes y
usuarios pidan más de lo que se puede lograr. También es relativamente común
que diferentes clientes o usuarios propongan requisitos que entran en conflicto
entre sí al argumentar que su versión es “esencial para nuestra necesidades
especiales”.
El ingeniero de requisitos debe conciliar estos conflictos por medio de un proceso
de negociación. Se pide a los clientes, usuarios y otros interesados que ordenen
sus requisitos y después discutan los conflictos relacionados con la prioridad. Se

6.
identifican y analizan los riesgos asociados con cada requisito. Se hacen
“estimaciones” preliminares del esfuerzo requerido para su desarrollo y después
se utilizan para evaluar el impacto de cada requisito en el costo del proyecto y
sobre el tiempo de entrega. Mediante un enfoque iterativo, los requisitos se
eliminan, combinan o modifican de forma que cada parte alcance cierto grado de
satisfacción.
ESPECIFICACIÓN
Es el producto final de la ingeniería de requisitos, y se convierte en la materia
prima para las actividades posteriores en el proceso de desarrollo del sistema. La
formalidad y especificación varían dependiendo de la complejidad del proyecto.
En el contexto de los sistemas basados en computadora (y en software), el
término especificación tiene significados diferentes para personas distintas. Una
especificación puede ser un documento escrito, un conjunto de modelos gráficos,
un modelo matemático formal, una colección de escenarios de uso, un prototipo o
cualquier combinación de estos.
Algunos sugieren que para una especificación se debe desarrollar y utilizar una
“plantilla estándar”argumenta que esto conduce a que los requisitos sean
presentados de una manera másconsciente y por ende más entendible. Sin
embargo, algunas veces es necesario ser flexible mientras se desarrolla una
especificación.
Respecto de sistema grande el mejor enfoque podría ser un documento escrito
que combinara descripciones en el lenguaje natural y modelos gráficos. Por otro
lado, en cuanto a productos o sistemas más pequeños, podría ser que no se
necesite más que escenarios de uso, cuando dichos sistemas residan en
ambientes técnicos que se comprendan bien.
La especificación es el producto de trabajo final que genera a ingeniería de
requisitos. Sirve como base para las actividades de ingeniería de software
subsecuentes.

7.
Describe la función yel desempeño de un sistema basado en computadora y las
restricciones que regirán su desarrollo.
VALIDACIÓN
Un equipo de validación toma el producto de la fase de especialización, lo revisa
para detectar errores, conflictos u omisiones y los corrige con el fin de garantizar la
consistencia de los requisitos.
La calidad de los productos de trabajo procedentes de la ingeniería de requisitos se
evalúa durante un paso de validación. La validación de requisitos examina la
especificación para asegurar que todos los requisitos de software se han
establecidos de manera precisa; que se han detectado las inconsistencias
omisiones y errores y queestos han sido corregidos, y que los producto de trabajo
cumplen con los estándares establecidos para el proceso, proyecto y producto.
El mecanismo primario para la validación de requisitos es la revisión técnica formal.
El equipo de revisión que valida los requisitos incluye ingenieros de software,
clientes, usuarios y otros interesados que examinan la especificación y buscan
errores en el contenido o la interpretación, áreas que tal vez requieran una
clasificación, información faltante, inconsistencia (que es problema importante)
cuando se desarrollan productos o sistemas grandes), conflictos entre los
requisitos, o requisitos irreales (inalcanzables).
GESTIÓN DE REQUISITOS
Ayuda al equipo de proyecto a rastrear los requisitos según las características de
los mismos, el código fuente relacionado, dependencia entre requisitos,
subsistemas e interfaces internas y externas; de forma que pueda identificarse con
rapidez para entender cómo afectará una modificación diferentes aspectos del
sistema a construir.
La gestión de requisitos es un conjunto de actividades que ayudan al equipo de
proyecto a identificar, controlar y rastrear los requisitos y los cambios a estos en

8.
cualquier momento mientras se desarrolla el proyecto.Muchas de estas
actividades son idénticas a las actividades de la gestión de la configuración del
software(GGS).
La gestión de requisitos comienza con la identificación. Cada requerimiento se
asigna a un solo identificador. Una vez identificados los requisitos se desarrollan
las tablas de rastreabilidad que son las siguientes:
Tabla de rastreabilidad de las características. Muestra la manera en que los
requisitos se relacionan con las características del sistema/producto observables
para el cliente.
Tabla de rastreabilidad de la fuente. Identifica la fuente de cada requisito.
Tabla de rastreabilidad de dependencia.Indica la forma en que los requisitos
están relacionados entre sí.
Tablas de rastreabilidad del subsistema. Establece categorías entre los
requisitos de acuerdo con el (los) subsistema(s) que gobierna(n).
Tablas de rastreabilidad de la interfaz. Muestra la forma en que los requisitos se
relacionan con las interfaces internas y externas del sistema.
En muchos casos, esas tablas de rastreabilidad se mantienen como parte de la
base de datos de los requisitos de forma que pueda buscársele con rapidez para
entender como el cambio en un requisito afectara diferentes aspectos del sistema
que se construirá.
Los requerimientos en un proyecto no solo comprenden las tareas de captura y
manejo de los cambios a lo largo de todo el proyecto, también comprenden de
estas otras tareas:
1. I d e n t i f i c a r l o s s t a k e h o l d e r s ( s e refiere a «quienes pueden afectar
o son afectados por las actividades de una empresa»): Se describe una lista
de toda la persona interesada en el desarrollo del sistema.
2. Entender las necesidades de los usuarios y clientes necesarias para planear el sistema
y sus expectativas.

9.
3. I d e n t i f i c a r l o s r e q u e r i m i e n t o s : Inicialmente los requerimientos
provienen de los objetivos que plantea el negocio. En esta actividad los
requerimientos se indican por medio de sentencias. En un escenario de
negocio se usa para entender los requerimientos del negocio.
4. Aclarecer y refinar los requerimientos:Esta actividad se ejecuta
cuando se tiene plena seguridad plena certeza de que los requerimientos
indican las necesidades reales del cliente y que estos pueden ser usados
por el resto de equipos en el proyecto.
5. A n a l i z a r l o s r e q u e r i m i e n t o s : Se realiza cuando los requerimientos
se encuentran bien definidos y cumplen con el criteriode un buen
requerimiento.
6. Definir los requerimientos de forma estándar para los
stakeholders:Debido a que cada stakeholders tiene una perspectiva
diferente del sistema y susrequerimientos, es importante esforzar un poco
de tiempo en la descripción de losrequerimientos usando un vocabulario
adecuado.
7. E s p e c i f i c a r los r e q u e r i m i e n t o s : Cada requerimiento debe
expresarse en forma detallada de tal manera que pueda ser incluido en
otros documentos de especificación o en otros proyectos.
8. P r i o r i z a r l o s r e q u e r i m i e n t o s : Todos los requerimientos tienen
niveles diferentes de importancia para los clientes yusuarios. Unos tienen
prioridad críticas, otros no tanta y otros de bajo nivel de prioridad.La
priorización de los requerimientos es una actividad que nos va a permitir
desarrollar nuevas versiones de nuestro proyecto de forma continua sin
verse retrasadas por tiempo ensus salidas.
9. D e r i v a r l o s r e q u e r i m i e n t o s : Esta actividad nos permite detallar
requerimientos no visibles para nuestros clientes ousuarios que no se han
logrado identificar, pero que son importantes para el
funcionamientoadecuado del requerimiento en detalle.
10. Particionarlos requerimientos:donde se clasifican los requerimientos en
diferentes criterios: Hardware, software yentrenamiento.

10.
11. Asignar los requerimientos:Esta actividad asigna los requerimientos a
diferentes subsistemas y componentes internos.
12. Hacer seguimiento a los requerimientos:Se desarrolla la capacidad de
permitir que un requerimiento satisfecho pueda ser referenciado dentro del
sistema.
13. Manejar los requerimientos:Se desarrolla un sistema de control de los
requerimientos, necesario para adicionar, modificar y borrar requerimientos,
al igual que la implantación de un repositorio para estos.
14. Probar y verificar los requerimientos:En esta actividad se validan los
requerimientos, diseños, código,etc... Para asegurarse quelos
requerimientos están bien.
15. Validar los requerimientos:Finalmente se confirman los requerimientos
reales que han sido implementados.

11.
Conclusión
Es de mucha importancia tomarse el tiempo necesario para conocer a los clientes
y usuarios, así como su ambiente de trabajo. Esto ayuda a establecer una buena
relación de trabajo y comunicación entre el equipo de desarrollo y los clientes. Es
realmente necesario que los clientes y usuarios participen en la definición de sus
requerimientos, y con estos tareas, funciones o actividades que acabamos de ver,
son necesario porque ponen una serie de estándares para medir y certificar la
calidad tanto del sistema que está a desarrollar, como también del proceso de
desarrollo que con lleva ya que esto son los que deciden el destino del proyectoy
se decidedel gusto o inconformidady además del financiamientoque dará de fruto
el proyecto.

12.
Referencias
http://yaqui.mxl.uabc.mx/~molguin/as/IngReq.htm
http://es.scribd.com/doc/270431/Ingenieria-requerimientos
http://www.monografias.com/trabajos6/resof/resof.shtml
http://redalyc.uaemex.mx/pdf/666/66661111.pdf
http://ldc.usb.ve/~abianc/materias/ci4712/apuntes3.pdf
http://es.scribd.com/doc/19083744/INGENIERIA-DE-REQUERIMIENTOS
http://www.monografias.com/trabajos5/inso/inso2.shtml
http://www.arcos.inf.uc3m.es/~ii_si/IngReqCIII.pdf
http://www.rodolfoquispe.org/blog/que-es-la-ingenieria-de-requisitos.php