UNIDAD 2

INGENIERIA DE
REQUERIMIENTOS
CARRERA: Ingeniera en Sistemas
computacionales
MATERIA: Fundamentos de Ingeniera Software
PROFESORA: Ing. Mara Nancy Castro
INTEGRANTES DEL EQUIPO:
1. Jos Luis Bautista Gmez 11320513
2. Sergio Guadalupe Galeana Escobar 11320550
3. Daniel Bautista Pea 11320514
4. Fabin Alejandro Alegra Valencia 11320496
5. Luis Antonio Vizcarra Vazquez 11320693
HORARIO: 15:00-16:00
AULA: 706
CICLO ESCOLAR: Enero-Junio

10 de Abril del 2014

INTRODUCCION GENERAL



Con el paso del tiempo el software ha sufrido cambios radicales, que han ido
marcando momentos importantes en la historia de la humanidad, es gracias al
software que nuestras tareas cotidianas se facilitan, adems las empresas pueden
producir en mayor cantidad y llevar un mejor control de sus empleados, es por el
que se han desarrollado formas de ayudar al mundo, sin duda esto ha
revolucionado nuestra forma de vivir y pensar, no imaginaramos un mundo sin
computadoras, sin tecnologa; es gracias a ello que la ingeniera de software se
basa en modelos, mtodos y herramientas que sirven como una gua para los
ingenieros del software durante el proceso de desarrollo, con la finalidad de
mejorar la calidad de los proyectos, procesos y productos mediante la evaluacin y
medicin de los mismos.
El propsito de la ingeniera de requisitos es hacer que los mismos alcancen un
estado ptimo antes de alcanzar la fase de diseo en el proyecto. Los
buenos requisitos deben ser medibles, comprobables, sin ambigedades o
contradicciones, etc.
Entonces, la tarea ms importante que el ingeniero de software hace para el
cliente es la extraccin iterativa y el refinamiento de los requerimientos del
producto.


INTRODUCCIN

A travs de los aos se ha podido constatar que los requerimientos o requisitos
son la pieza fundamental en un proyecto de desarrollo de software, ya que marcan
el punto de partida para actividades como la planeacin, bsicamente en lo que se
refiere a las estimaciones de tiempos y costos, as como la definicin de recursos
necesarios y la elaboracin de cronogramas que ser uno de los principales
mecanismos de control con los que se contar durante la etapa de desarrollo.
Adems la especificacin de requerimientos es la base que permite verificar si se
alcanzaron o no los objetivos establecidos en el proyecto ya que estos son un
reflejo detallado de las necesidades de los clientes o usuarios del sistema y es
contra lo que se va a estar verificando si se estn cumpliendo las metas trazadas.
Es muy frecuente escuchar entre los conocedores del desarrollo de software
(programas de computadoras), que un gran nmero de los proyectos de software
fracasan por no realizar una adecuada definicin, especificacin, y administracin
de los requerimientos.
Dentro de esa mala administracin se pueden encontrar factores como la falta de
participacin del usuario, requerimientos incompletos y el mal manejo del cambio a
los requerimientos.











UNIDAD 2 INGENIERIA DE LOS REQUERIMIENTOS
La Ingeniera de Requerimientos (IR) cumple un papel primordial en el proceso de
produccin de software, ya que se enfoca un rea fundamental: la definicin de lo
que se desea producir.
Su principal tarea consiste en la generacin de especificaciones correctas que
describan con claridad, sin ambigedades, en forma consistente y compacta, las
necesidades de los usuarios o clientes; de esta manera, se pretende minimizar los
problemas relacionados por la mala gestin de los requerimientos en el desarrollo
de sistemas.
Qu son requisitos requerimientos?
Se presenta a continuacin la definicin existente en el glosario de la IEEE de lo
que es un Requerimiento:
1. Una condicin o necesidad de un usuario para resolver un problema o
alcanzar un objetivo. (Std 610.12-1900, IEEE: 62)
2. Una condicin o capacidad que debe estar presente en un sistema o
componentes de sistema para satisfacer un contrato, estndar, especificacin u
otro documento formal. (Std 610.12-1900, IEEE: 62)
Tambin, Ian Sommerville presenta una definicin acerca de lo que es un
Requerimiento:
3. Un requerimiento es simplemente una declaracin abstracta de alto nivel
de un servicio que debe proporcionar el sistema o una restriccin de ste.
(Sommerville, 2005: 108)
Caractersticas de un requerimiento
Especificado por escrito: Como todo contrato o acuerdo entre dos partes.
Posible de probar o verificar. Si un requerimiento no se puede comprobar,
entonces cmo se sabe si se cumpli con l o no?
Conciso: Un requerimiento es conciso si es fcil de leer y entender. Su
redaccin debe ser simple y claro para aquellos que vayan a consultarlo en
un futuro.
Completo: Un requerimiento est completo si no necesita ampliar detalles
en su redaccin, es decir, si se proporciona la informacin suficiente para
su comprensin.
Consistente: Un requerimiento es consistente si no es contradictorio con
otro requerimiento.
No ambiguo: Un requerimiento no es ambiguo cuando tiene una sola
interpretacin. El lenguaje usado en su definicin, no debe causar
confusiones al lector.
Definicin de Requerimientos
Ingeniera de Requerimientos ayuda a los ingenieros de software a
entender mejor el problema en cuya solucin trabajarn. Incluye el conjunto
de tareas que conducen a comprender cul ser el impacto del software
sobre el negocio, qu es lo que el cliente quiere y cmo interactuarn los
usuarios finales con el software.
(Pressman, 2006: 155)

BIBLIOGRAFIA 1
Autor: Pressman, Roger S.
Ao de Edicin: 2006,
Libro: Ingeniera del Software: Un enfoque prctico
Sexta edicin, Mxico DF, Editorial McGraw Hill.
Pgina:155-165

Ingeniera de requisitos
La ingeniera de requerimientos es el proceso de desarrollar una
especificacin de software. Las especificaciones pretender comunicar las
necesidades del sistema del cliente a los desarrolladores del sistema.
(Sommerville, 2005: 82)

Sntesis de Requerimientos
En sntesis, el proceso de ingeniera de requerimientos se utiliza para
definir todas las actividades involucradas en el descubrimiento,
documentacin y mantenimiento de los requerimientos para un producto de
software determinado, donde es muy importante tomar en cuenta que el
aporte de la IR vendr a ayudar a determinar la viabilidad de llevar a cabo
el software (si es factible llevarlo a cabo o no).
Pasando posteriormente por un subproceso de obtencin y anlisis de
requerimientos, su especificacin formal, para finalizar con el subproceso
de validacin donde se verifica que los requerimientos realmente definen el
sistema que quiere el cliente.
Dificultades para definir los requerimientos
Los requerimientos no son obvios y vienen de muchas fuentes.
Son difciles de expresar en palabras (el lenguaje es ambiguo).
La cantidad de requerimientos en un proyecto puede ser difcil de manejar.
Un requerimiento puede cambiar a lo largo del ciclo de desarrollo.
El usuario no puede explicar lo que hace
Tiende a recordar lo excepcional y olvidar lo rutinario
Hablan de lo que no funciona
Los usuarios tienen distinto vocabulario que los desarrolladores.
Actividades de los requerimientos
Extraccin: Aqu, los analistas de requerimientos deben trabajar junto al
cliente para descubrir el problema que el sistema debe resolver, los
diferentes servicios que el sistema debe prestar, las restricciones que se
pueden presentar, etc.
Anlisis: se leen los requerimientos, se conceptan, se investigan, se
intercambian ideas con el resto del equipo, se resaltan los problemas, se
buscan alternativas y soluciones, y luego se van fijando reuniones con el
cliente para discutir los requerimientos.
Especificacin: Es el "pasar en limpio" el anlisis realizado previamente
aplicando tcnicas y/o estndares de documentacin, como la notacin
UML (Lenguaje de Modelado Unificado), que es un estndar para el
modelado orientado a objetos, por lo que los casos de uso y la obtencin de
requerimientos basada en casos de uso se utiliza cada vez ms para la
obtencin de requerimientos.
Validacin: Es la etapa final de la IR. Su objetivo es, ratificar los
requerimientos, es decir, verificar todos los requerimientos que aparecen en
el documento especificado para asegurarse que representan una
descripcin, por lo menos, aceptable del sistema que se debe implementar.
Esto implica verificar que los requerimientos sean consistentes y que estn
completos.
BIBLIOGRAFIA 2
Autor: Sommerville Ian
Ao de Edicin: 2005
Libro: Ingeniera del Software
Sptima edicin, Mxico DF, Editorial Pearson.
Pgina: 82-90


2.1 Tareas de la ingeniera de requisitos
La ingeniera de requisitos proporciona el mecanismo apropiado para entender lo que el cliente
quiere, analizar las necesidades, evaluar la factibilidad, negociar una solucin razonable,
especificar la solucin sim ambigedades, validar la especificacin, y administrar los requisitos
conforme estos se transformar en un sistema operacional. El proceso de la ingeniera de requisitos
se lleva a cabo a travs de siete distintas funciones: inicio, obtencin, elaboracin, negociacin,
especificacin, validacin y gestin.
Inicio
En algunos casos, una conversacin informal es todo lo que se necesita para precipitar un esfuerzo
importante de ingeniera del software. Pero en general, la mayora de los proyectos comienza
cuando se identifica una necesidad de negocios o se descubren un nuevo mercado o servicio
potencial.
Obtencin
Debemos hablar con el cliente y otros interesados de cules son sus 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 ultimo como se utilizara el sistema o producto da a da.
Para ello se debe identificar una serie de problemas que ayudan a entender por qu es difcil la
obtencin de requisitos:
Problemas de mbito: El lmite del sistema est mal definido o los clientes especifican
detalles tcnicos innecesarios que pueden confundir, en lugar de clarificar, los objetivos
generales del sistema.
Problemas de compresin: Los clientes no estn seguros por completo de que es lo que se
necesita, comprenden poco acerca de las capacidades y limitaciones de su ambiente de
computo, no comprenden del todo el dominio del problema, tienen dificultades al
comunicar necesidades al ingeniero de sistemas, omiten informacin que se consideraban
obvia, especifican requisitos que chocan con las necesidades de otros clientes, o
especifican requisitos inestables.
Problemas de volatilidad: Los problemas cambian conforme transcurre el tiempo.
Para ayudar a superar estos problemas, los ingenieros de requisitos deben realizar en forma
organizada la actividad de recopilacin de requisitos.
Elaboracin
La informacin conseguida con el cliente durante el inicio y la obtencin se expande y se refina
durante la elaboracin. Esta actividad de la ingeniera de requisitos se enfoca en el desarrollo de
un modelo tcnico refinado de las funciones, caractersticas y restricciones del software.
Negociacin:
En esta etapa el ingeniero de requisitos debe negociar con el cliente los alcances y lmites del
sistema. De forma iterativa los requisitos se prioriza, modifican, combinan o eliminan buscando
acuerdos que beneficien a todas las partes. Se identifican y analizan los riesgos asociados con cada
requisito.
Especificacin:
Es el producto final de la ingeniera de requisitos, y se convierte en la materia prima para las
actividades posteriores en el proceso de desarrollo del sistema. Una especificacin puede ser un
documento escrito, un conjunto de modelos grficos, un modelo matemtico formal, una
coleccin de escenarios de uso, un prototipo o cualquier combinacin de estos.
Validacin
La calidad de los productos de trabajo procedentes de la ingeniera de requisitos se evala durante
un paso de validacin. La validacin de requisitos se examina la especificacin para asegurar que
todos los requisitos de software se han establecido de manera precisa; que se han detectado las
inconsistencias, omisiones y errores y que estos han sido corregidos, y que los productos de
trabajo cumplen con los estndares establecidos para el proceso, proyecto y producto.
Gestin de requisitos
La gestin 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 el cualquier momento
mientras se desarrolla el proyecto.
La gestin de requisitos comienza con la identificacin. Cada requerimiento se asigna a un solo
identificador. Una vez identificados los requisitos se desarrollan las tablas de rastreabilidad.
Entre las muchas tablas de rastreabilidad posibles estn las siguientes:
De caractersticas: Muestra la manera en que los requisitos se relacionan con las
caractersticas del producto o sistema observables para el cliente.
De fuente: Identifica la fuente de cada requisito.
De dependencia: Indica la forma en que los requisitos estn relacionados entre s.
De subsistema: Establece categoras entre los requisitos de acuerdo con los subsistemas
que gobiernan.
De interfaz: Muestra la forma en que los requisitos se relacin con las interfaces internas y
externas del sistema.
BIBLIOGRAFIA:
Libro: Ingeniera de software un enfoque practico
Edicin: Sexta
Autor: Roger S. Pressman
Editorial: Mc Graw Hill
Paginas: 157-162
2.1 Tareas de la ingeniera de requisitos
Se define como un conjunto de actividades en los cuales, utilizando tcnicas y herramientas, se
analiza un problema y se concluye con la especificacin de una solucin. La ingeniera de requisitos
es el proceso de desarrollar una especificacin de software.
Extraccin: Esta fase representa el comienzo de cada ciclo. Extraccin es el nombre comnmente
dado a las actividades involucradas en el descubrimiento de los requisitos del sistema.
Anlisis: Sobre la base de la extraccin realizada previamente, comienza esta fase en la cual se
enfoca en descubrir problemas con los requisitos del sistema identificados hasta el momento.
Especificacin: En esta fase se documentan los requisitos acordados con el cliente, en un nivel
apropiado de detalle.
Validacin: La validacin es la etapa final de la IR. Su objetivo es, ratificar los requisitos, es decir,
verificar todos los requisitos que aparecen en el documento especificado para asegurarse que
representan una descripcin, por lo menos, aceptable del sistema que se debe implementar. Esto
implica verificar que los requisitos sean consistentes y que estn completos.
LINKOGRAFIA:
http://ithjuanah.blogspot.mx/

2.2 TCNICAS DE LA INGENIERA DE
REQUISITOS
INTRODUCCIN
Las tcnicas de la ingeniera de requisitos nos permiten recoger informacin
sobre el sistema propuesto y los existentes y extraer los requerimientos del
usuario y del sistema de esta informacin.
Las fuentes de informacin durante la fase del descubrimiento de
requerimientos incluyen la documentacin, los stakeholders del sistema y
la especificacin de sistemas similares.
Los stakeholders son todos aquellos individuos que interactan con un
sistema; los cuales abarcan desde los usuarios finales del sistema hasta
los gerentes y stakeholders externos como los reguladores quienes
certifican la aceptabilidad del sistema.
A continuacin se describen tcnicas de descubrimiento de requerimientos
entre las que se incluyen entrevistas, escenarios y etnografa.
ENTREVISTAS
Las entrevistas formales o informales con los stakeholders del sistema son parte
de la mayora de los procesos de la ingeniera de requerimientos. En estas
entrevistas, el equipo de ingeniera de requerimientos hace preguntas a los
stakeholders sobre el sistema que utilizan y el sistema a desarrollar. Los
requerimientos provienen de las respuestas a estas preguntas.

Las entrevistas pueden ser de dos tipos:
1.- Entrevistas cerradas donde los stakeholders responden a un conjunto
predefinido de preguntas.
2.- Entrevistas abiertas donde no hay un programa predefinido. El equipo de la
ingeniera de requerimientos examina una seria de cuestiones con los
stakeholders del sistema y, por lo tanto, desarrolla una mejor comprensin de sus
necesidades.

En la prctica, las entrevistas con los stakeholders normalmente son una mezcla
de stos.
Las entrevistas tambin requieren de un mtodo que podemos establecer en los
siguientes pasos:
Planificacin de la entrevista (antes de realizar la entrevista): Fijar a
quin se debe entrevistar, contando con la aprobacin previa. Se informa al
entrevistado con antelacin del contenido de la entrevista, y se rene toda
la informacin existente sobre el contenido antes de realizar la entrevista.
Finalmente, convenir da, hora y lugar.
Realizacin de la entrevista: Deber llevarse a cabo en un ambiente
apropiado y lo ms exento posible de interrupciones. Conviene ser puntual,
identificarse y explicar el objetivo de la entrevista.
En el desarrollo, se debe ir de lo general a aspectos ms detallados, empezando
por:
Funciones - entradas - salidas (lo que hace).
Salidas - funciones - entradas (los documentos que maneja).
Se debe utilizar un estilo apropiado y evitar la tentacin de argumentar, dar
consejos o envolver emocionalmente al entrevistado (ya que esto ltimo
modificar su actitud de cara a prximas entrevistas).
Finalizacin de la entrevista: Verificaremos las notas con la persona
entrevistada, le expresaremos nuestro agradecimiento y dejaremos el
camino abierto para nuevos contactos.
Consolidacin (despus de la entrevista): Se debe organizar y completar
si fuera preciso las notas recogidas, elaborar un acta que debe ser
entregada a todos los participantes, recabar cuantas consideraciones sean
precisas en relacin a su contenido y conseguir que el usuario lo apruebe.
ESCENARIOS
Normalmente, las personas encuentran ms fcil dar ejemplos de la vida real que
descripciones abstractas. Pueden comprender y criticar un escenario de cmo
interactuar con un sistema software.
Los ingenieros de requerimientos pueden utilizar la informacin obtenida de esta
discusin para formular los requerimientos reales del sistema.
Los escenarios pueden ser especialmente tiles para agregar detalle a un esbozo
de la descripcin de requerimientos. Son descripciones de ejemplos de las
sesiones de interaccin.
Cada escenario abarca una o ms posibles interacciones. Se han desarrollado
varias formas de escenarios, cada una de las cuales proporciona diferentes tipos
de informacin en diferentes niveles de detalle sobre el sistema.
El escenario comienza con un esbozo de la interaccin y, durante la obtencin, se
agregan detalles para crear una descripcin completa de esta interaccin. De
forma general, un escenario puede incluir:
1. Una descripcin de lo que esperan el sistema y los usuarios cuando el
escenario comienza.
2. Una descripcin del flujo normal de eventos en el escenario.
3. Una descripcin de lo que puede ir mal y cmo manejarlo.
4. Informacin de otras actividades que se podran llevar a cabo al mismo
tiempo.
5. Una descripcin del estado del sistema cuando el escenario termina.
Los escenarios se pueden redactar como texto, complementados por diagramas,
fotografas de las pantallas, etctera.
Ejemplo:
Suposicin inicial: el usuario a entrado en el sistema LYBSIS y ha
localizado la revista que contiene el artculo.
Normal: el usuario selecciona el artculo a copiar. El sistema insta al
usuario a proporcionar la informacin de suscriptor de la revista o a indicar
a un mtodo de pago del artculo. El pago se puede efectuar mediante
tarjeta de crdito o citando un nmero de cuenta.
Se le solicita entonces al usuario que rellene un formulario de derechos de
autor que mantiene los detalles de la transaccin y se enva al sistema
LYBSIS.
Se verifica el formulario de derechos de autor, y si se aprueba, se descarga
la versin en PDF del artculo al rea de trabajo de LYBSIS en la computadora
del usuario y se informa al usuario que est disponible. Se le pide al usuario
que seleccione una impresora y se imprime una copia del artculo. Si el artculo
es de sola impresin se elimina del sistema del usuario una vez que ste ha
confirmado que se ha completado la impresin.
Que puede salir mal: el usuario puede rellenar el formulario de derechos
de autor incorrectamente. En este caso, se le debe de volver a mostrar el
formulario para su correccin. Si el formulario reenviado todava es
incorrecto, se rechaza la peticin del artculo por parte del usuario.
El sistema puede rechazar el pago, en cuyo caso se rechaza la peticin del
usuario.
La descarga del articulo puede fallar, haciendo que el sistema lo reintente
hasta que lo consiga o hasta que el usuario termine la sesin.
Es posible que no pueda imprimir el artculo. Si el artculo no es de solo
impresin, se mantiene en el espacio de trabajo del LYBSIS. De lo contrario el
artculo se elimina y se lo cargan a la cuenta del usuario los costes del artculo.
Otras actividades: descarga simultaneas de artculos.
Estado del sistema a la finalizacin: el usuario est dentro del sistema. El
artculo descargado se ha borrado del espacio de trabajo del LYBSIS si es
de solo impresin.

CASOS DE USOS
Los casos de uso son una tcnica que se basa en escenarios para la obtencin de
requerimientos que se introdujeron por primera vez en el mtodo Objeiory
(Jacobsen et ai., 1993).Actualmente se han convertido en una caracterstica
fundamental de la notacin de UML, que se utiliza para describir modelos de
sistemas orientados a objetos.

En su forma ms simple, un caso de uso identifica el tipo de interaccin y
los actores involucrados.
Los actores en el proceso se representan como figuras delineadas, y cada
clase de interaccin se representa como una elipse con su nombre.

Los casos de uso identifican las interacciones particulares con el sistema.
Pueden ser documentadas con texto o vinculadas a modelos UML que
desarrollan el escenario en ms detalle.
Segn Fowler (Fowler y Scott. 1997), un caso de uso encierra un conjunto de
escenarios, y cada uno de stos es un hilo nico a travs del caso de uso.
Los casos de uso son tcnicas eficaces para obtener requerimientos para los
puntos de vista de los interactuadores, donde cada tipo de interaccin se puede
representar como un caso de uso. Tambin se pueden utilizar conjuntamente con
algunos puntos de vista indirectos cuando stos reciben resultados (como un
informe de gestin) del sistema. Sin embargo, debido a que se centran en las
interacciones, no son tan eficaces para obtener restricciones y requerimientos de
negocio y no funcionales de alto nivel de puntos de vista indirectos o para
descubrir requerimientos del dominio.
Ejemplo: Casos de uso para el sistema de biblioteca:

En esta figura se muestra una extensin del ejemplo del LIBSYS y muestra otros
casos de uso en ese entorno.
ETNOGRAFA
La etnografa es una tcnica de observacin que se puede utilizar para
entender los requerimientos sociales y organizacionales. Un analista se sumerge
por s solo en el entorno laboral donde se utilizar el sistema. Observa el trabajo
diario y anota las tareas reales en las que los participantes estn involucrados.
El valor de la etnografa es que ayuda a los analistas a descubrir los
requerimientos implcitos que reflejan los procesos reales ms que los formales en
los que la gente est involucrada.
La etnografa es especialmente efectiva para descubrir dos tipos de
requerimientos:
1. Los requerimientos que se derivan de la forma en la que la gente trabaja
realmente ms que de la forma en la que las definiciones de los procesos
establecen que debera trabajar.
Por ejemplo, los controladores del trfico areo pueden desconectar un
sistema de alerta de conflictos que detecta aviones que cruzan las
trayectorias de vuelo, aun cuando los procedimientos de control normales
especifican que debe utilizarse. Su estrategia de control est diseada para
asegurar que estos aviones se separarn antes de que ocurran problemas
y consideran que la alarma de alerta de conflictos los distrae de su trabajo
2. Los requerimientos que se derivan de la cooperacin y conocimiento de
las actividades de la gente..
Por ejemplo, los controladores del trfico areo pueden utilizar el
conocimiento del trabajo de otros controladores para predecir el nmero de
aviones que entrar en su sector de control. Despus modifican sus
estrategias de control dependiendo del volumen de trabajo pronosticado.
Por lo tanto, un sistema automtico de control del trfico areo debe
permitir a los controladores en un sector tener alguna visibilidad del trabajo
en los sectores adyacentes.
La etnografa se puede combinar con la construccin de prototipos.
La etnografa suministra informacin al desarrollo del prototipo de forma que se
requieren menos ciclos de refinamiento.

Adems, la construccin de prototipos se centra en la etnografa para identificar
problemas y preguntas que se puedan discutir posteriormente con el etngrafo.
Ventajas:
Los estudios etnogrficos pueden revelar los detalles de los procesos crticos que
otras tcnicas de obtencin de requerimientos a menudo olvidan.
Desventajas:
Sin embargo, puesto que se centran en el usuario final, este enfoque no es
apropiado para descubrir los requerimientos organizacionales o del dominio.
Los estudios etnogrficos no siempre pueden identificar nuevas propiedades que
se deban agregar al sistema. Por lo tanto, la etnografa no es un enfoque completo
para la obtencin de requerimientos por s mismo, y debe utilizarse para
complementar otros enfoques, como el anlisis de casos de uso.

REUNIONES
Cuando los diferentes aspectos en relacin a un tema son conocidos por distintas
personas es preciso reunirlas para obtener una informacin lo ms completa
posible sobre dicho tema. El responsable de la reunin suele ser el desarrollador.
Existen una serie de problemas especficos para la aplicacin de esta tcnica,
fundamentalmente los derivados de la dinmica de grupos.

JAD (Joined Application Development, Desarrollo Conjunto de
Aplicaciones)
Surgen con fuerza para resolver dos de los problemas que presentan las
entrevistas:
Los conflictos entre requisitos al entrevistar por separado a distintos usuarios y el
alargamiento en el tiempo debido a las numerosas entrevistas.
Un JAD es una alternativa a las entrevistas, que consiste en un proceso
acelerado de reuniones en el cual todos los usuarios y analistas se renen de
forma intensiva (puede durar desde un da a una semana) para documentar los
requisitos. Normalmente un especialista supervisa las reuniones y acta como
mediador para promover una mejor comunicacin entre analistas y usuarios.
La idea del JAD es:
Aprovechar la dinmica de grupos.
Aprovechar toda clase de ayudas visuales, de comunicacin y comprensin
de soluciones.
Realizar un trabajo sistemtico y organizado.
El mtodo utilizado se divide en:
Preparacin: Seleccionar los participantes, recabar informacin sobre el
sistema a construir y organizar la reunin (lugar, fecha, ayudas
audiovisuales, redaccin de un documento de trabajo...).
Sesin J AD: Consiste en diversas reuniones bien estructuradas y
organizadas donde se parte de un documento de trabajo que hay que
analizar para completar los requisitos del sistema, documento que deber
ser aprobado por los presentes. El jefe del JAD es el responsable de
conseguir que las reuniones sean productivas y de mantener el orden.
Documentacin: Aunque el documento final debera estar terminado al
final de las sesiones JAD, lo cierto es que es preciso completarlo,
organizarlo, etc., para tener el documento es su forma final.
El JAD es difcil de llevar a la prctica al tener que disponer de numerosos
usuarios simultneamente, lo que puede provocar un parn en la produccin.

EXAMEN DE ARCHIVOS
Tcnica bsica para obtener informacin cuantitativa: volmenes, frecuencias,
tendencias, ratios, etc.
Tambin proporciona ayuda para medir el nivel de confianza que se puede
depositar en las estimaciones cuantitativas dadas por el usuario.

MUESTREOS
Es til cuando se pide informacin relativa a un gran volumen de documentos o
actividades que se repiten con mucha frecuencia. En este caso es aceptable
examinar documentos o actividades escogidas al azar.
Por lo menos, debera realizar un muestreo aleatorio simple con un tamao de
muestra de 30 individuos.


CUESTIONARIOS
Son difciles de disear y de interpretar, por lo que su uso debe restringirse
a los casos de localidades remotas o cuando la informacin deba
proporcionarla un nmero elevado de personas.





BIBLIOGRAFA N1
Libro: Fundamentos de Ingeniera del Software
Autor: Ian Sommerville
Editorial: Pearson
Capitulo: 7
Pgina: 132-144

2.2 TCNICAS DE LA INGENIERA DE REQUISITOS

El proceso de Ingeniera de Requerimientos describe de manera detallada y
precisa cada uno de los aspectos del ciclo de vida de un conjunto de
requerimientos. Este proceso presenta dos grandes ramas: Desarrollo de
requerimientos. Administracin de requerimientos.
Que tiene como propsito producir y analizarlos requerimientos de cliente, de
producto y de componente de producto, incluye las siguientes actividades:
Recoleccin, Anlisis, Especificacin y Verificacin. Recoleccin: Es el Proceso a
travs del cual los clientes (compradores y/o usuarios) y el desarrollador
(contratista) de un sistema de software; descubren, revisan, articulan, y entienden
las necesidades de los usuarios del sistema y las restricciones que se dan sobre el
software y el desarrollo del mismo. Algunas de las tcnicas y herramientas ms
importantes para llevar a cabo la recoleccin de requerimientos son:


ENTREVISTAS

Mtodo para descubrir hechos y opiniones que tienen los posibles usuarios y otros
participantes dentro del sistema que se est desarrollando. A su vez se clasifican
en:

Entrevistas cerradas: las preguntas ya estn previstas, tienen un orden y
una forma de ser planteadas que no pueden ser modificadas por el
entrevistador. Es en realidad un cuestionario.

Entrevistas abiertas: en las cuales no se preparan preguntas concretas, y,
por el contrario, se discute con el entrevistado las expectativas que este
tiene del sistema.


SISTEMAS EXISTENTES

Esta tcnica consiste en analizar distintos sistemas ya desarrollados que estn
relacionados con el sistema a ser construido. Por un lado, podemos analizar las
interfaces de usuario, observando el tipo de Informacin que se maneja y cmo es
manejada, por otro lado tambin es til analizar las distintas Salidas que los
sistemas producen (listados, consultas, etc.), porque siempre pueden surgir
nuevas ideas sobre la base de estas.



CASOS DE USO Y/O ESCENARIOS

Los casos de uso describen interacciones entre los usuarios y el sistema,
enfatizando en lo que el usuario necesita del sistema. Los escenarios son
ejemplos de sesiones de interaccin entre el sistema y el usuario, donde un solo
tipo de interaccin entre los dos participantes es simulada y descrita.

OBSERVACIN Y ANLISIS SOCIAL

La observacin permite a los investigadores observar lo que los usuarios hacen
actualmente en un determinado contexto. Esto permite superar problemas con los
participantes del proyecto que realizan descripciones idealizadas o demasiado
simplificadas de los procesos que se llevan a cabo en sus trabajos.


LLUVIA DE IDEAS

Son sesiones donde todos los participantes brindan sus ideas para obtener una
solucin a una problemtica. Una lluvia de ideas est compuesta de dos fases: la
fase de generacin y la fase de evaluacin. Durante la generacin las ideas son
recolectadas y es importante que no sean criticadas. Durante la evaluacin de las
ideas, las propuestas de solucin deben ser evaluadas desde diferentes
perspectivas.

PROTOTIPOS

Es programa de computador que implementa algunos de los requerimientos de un
sistema. Este prototipo puede ser usado para colaborar con la definicin de los
requerimientos, o para facilitar la evaluacin de alternativas de implementacin de
un sistema.

Existen dos grandes tipos de prototipos:
Los prototipos no funcionales o desechables (Throw away), que sirven para
entender la dificultad y aclarar los requerimientos.

Los prototipos funcionales o evolutivos (Evolutionary) que permiten
construir una aproximacin del sistema de manera que se pueda proveer
cierta funcionalidad del sistema final y usualmente se convierten en parte
del mismo.

ANLISIS

Es el proceso de analizar las necesidades de los clientes y los usuarios para
llegar a una definicin de los requerimientos de software.

Dentro de las prcticas principales se encuentra:

JAD (Joint Application Development)

Esta prctica se basa en la creacin de espacios que permitan celebrar sesiones o
reuniones en donde los participantes y directos interesados dentro del desarrollo
del proyecto buscan obtener o generar conocimiento alrededor del desarrollo que
se va a llevar a cabo. En estas sesiones se trabaja bajo un enfoque comn que
permite el fcil entendimiento de los temas expuestos por parte de los invitados a
la sesin

BIBLIOGRAFA N2

http://tecnologicofch.blogspot.mx/2013/03/22-tecnicas-de-la-ingenieria-de.html
Autor: francis coronel,
Publicado: lunes, 11 de marzo de 2013
http://ithjuanah.blogspot.mx/
Autor: Juana Hernndez Hernndez










2.3. Modelado de Requisitos

Objetivos del Modelado de Requisitos:

Entender los conceptos de requerimientos del usuario y del sistema, as
como por qu tales requerimientos se deben escribir en diferentes formas.
Comprender las diferencias entre requerimientos de software funcional y no
funcional.
Reconocer cmo se organizan los requerimientos dentro de un documento
de requerimientos de software.
Conocer las principales actividades de la ingeniera de requerimientos:
adquisicin, anlisis y validacin, as como las relaciones entre dichas
actividades.
Analizar por qu es necesaria la administracin de requerimientos y cmo
sta apoya otras actividades de la ingeniera de requerimientos.

Casos de Uso
Los casos de uso son una tcnica de descubrimiento de requerimientos que se
introdujo por primera vez en el mtodo Objectory (Jacobson et al., 1993). Ahora se
ha convertido en una caracterstica fundamental del modelado de lenguaje
unificado. En su forma ms sencilla, un caso de uso identifica a los actores
implicados en una interaccin, y nombra el tipo de interaccin. Entonces, esto se
complementa con informacin adicional que describe la interaccin con el sistema.
La informacin adicional puede ser una descripcin textual, o bien, uno o ms
modelos grficos como una secuencia UML (Lenguaje de Modelado Unificado) o
un grfico de estado.

Los casos de uso se documentan con el empleo de un diagrama de caso de uso
de alto nivel. El conjunto de casos de uso representa todas las interacciones
posibles que se describirn en los requerimientos del sistema. Los actores en el
proceso, que pueden ser individuos u otros sistemas, se representan como figuras
sencillas. Cada clase de interaccin se constituye como una elipse con etiqueta.
Lneas vinculan a los actores con la interaccin. De manera opcional, se agregan
puntas de flecha a las lneas para mostrar cmo se inicia la interaccin. Esto se
ilustra en la figura 4.15, que presenta algunos de los casos de uso para el sistema
de informacin del paciente.
Los casos de uso identifican las interacciones individuales entre el sistema y sus
usuarios u otros sistemas. Cada caso de uso debe documentarse con una
descripcin vincularse con otros modelos en el UML que desarrollar el escenario
con ms detalle.

Captura de Requerimientos (La Entrevista)

Los requerimientos se derivan de las respuestas a dichas preguntas. Las
entrevistas son de dos tipos:
1. Entrevistas cerradas, donde los participantes responden a un conjunto de
preguntas preestablecidas.
2. Entrevistas abiertas, en las cuales no hay agenda predefinida. El equipo
de ingeniera de requerimientos explora un rango de conflictos con los
participantes del sistema y, como resultado, desarrolla una mejor
comprensin de sus necesidades.
Por dos razones resulta difcil asimilar el conocimiento de dominio a travs de
entrevistas:
1. Todos los especialistas en la aplicacin usan terminologa y jerga que
son especficos de un dominio. Es imposible que ellos discutan los
requerimientos de dominio sin usar este tipo de lenguaje. Por lo general,
usan la terminologa en una forma precisa y sutil, que para los ingenieros
de requerimientos es fcil de malinterpretar.
2. Cierto conocimiento del dominio es tan familiar a los participantes que
encuentran difcil de explicarlo, o bien, creen que es tan fundamental que
no vale la pena mencionarlo. Por ejemplo, para un bibliotecario no es
necesario decir que todas las adquisiciones deben catalogarse antes de
agregarlas al acervo. Sin embargo, esto quiz no sea obvio para el
entrevistador y, por lo tanto, es posible que no lo tome en cuenta en los
requerimientos.
En general, la mayora de las personas se muestran renuentes a discutir los
conflictos polticos y organizacionales que afecten los requerimientos. Los
entrevistadores efectivos poseen dos caractersticas:
1. Tienen mentalidad abierta, evitan ideas preconcebidas sobre los
requerimientos y escuchan a los participantes. Si el participante aparece
con requerimientos tienen disposicin para cambiar su mentalidad acerca
del sistema.
2. Al entrevistado con una pregunta de trampoln para continuar la pltica,
dar una propuesta de requerimientos o trabajar juntos en un sistema de
prototipo. Cuando se pregunta al individuo dime qu quieres es
improbable que alguien consiga informacin til. Encuentran mucho ms
sencillo hablar en un contexto definido que en trminos generales.

Las actividades del proceso
Descubrimiento de requerimientos: participantes del sistema para descubrir
sus requerimientos. Tambin los requerimientos de dominio de los
participantes y la documentacin se descubren durante esta actividad.
Clasificacin y organizacin de requerimientos: compilacin no estructurada
de requerimientos, agrupa requerimientos relacionados y los organiza en
grupos coherentes. La forma ms comn de agrupar requerimientos es
Usar un modelo de la arquitectura del sistema: para identificar subsistemas
y asociar los requerimientos con cada subsistema. En la prctica, la
ingeniera de requerimientos y el diseo arquitectnico no son actividades
separadas completamente.
Priorizacin y negociacin de requerimientos: en diversos participantes, los
requerimientos entrarn en conflicto. Esta actividad se preocupa por
priorizar los requerimientos, as como por encontrar y resolver conflictos de
requerimientos mediante la negociacin. Por lo general, los participantes
tienen que reunirse para resolver las diferencias y estar de acuerdo con el
compromiso de los requerimientos.
Especificacin de requerimientos: Los requerimientos se documentan e
ingresan en la siguiente ronda de la espiral.

Espiral de Procesos de Ingeniera de Requerimientos


Puntos Clave para el Modelado de Requerimientos

Los requerimientos para un sistema de software establecen lo que debe
hacer el sistema y definen las restricciones sobre su operacin e
implementacin.
Los requerimientos funcionales son enunciados de los servicios que debe
proporcionar el sistema, o descripciones de cmo deben realizarse algunos
clculos.
Los requerimientos no funcionales restringen con frecuencia el sistema que
se va a desarrollar y el proceso de desarrollo a usar. stos pueden ser
requerimientos del producto, requerimientos organizacionales o
requerimientos externos. A menudo se relacionan con las propiedades
emergentes del sistema y, por lo tanto, se aplican al sistema en su
conjunto.
El documento de requerimientos de software es un enunciado acordado
sobre los requerimientos del sistema. Debe organizarse de forma que
puedan usarlo tanto los clientes del sistema como los desarrolladores del
software.
El proceso de ingeniera de requerimientos incluye un estudio de
factibilidad, adquisicin y anlisis de requerimientos, especificacin de
requerimientos, validacin de requerimientos y administracin de
requerimientos.
La adquisicin y el anlisis de requerimientos es un proceso iterativo que se
representa como una espiral de actividades: descubrimiento de
requerimientos, clasificacin y organizacin de requerimientos, negociacin
de requerimientos y documentacin de requerimientos.
La validacin de requerimientos es el proceso de comprobar la validez, la
consistencia, la totalidad, el realismo y la verificabilidad de los
requerimientos.
Los cambios empresariales, organizacionales y tcnicos conducen
inevitablemente a cambios en los requerimientos para un sistema de
software. La administracin de requerimientos es el proceso de gestionar y
controlar dichos cambios.
BIBLIOGRAFIA 1

1. INGENIERIA DE SOFTWARE ,Ian Somerville, 9 Edicin, Capitulo 4
Ingeniera de Requerimientos pg.82
2.3. Modelado de Requisitos

Objetivos del Modelado de Requisitos

El modelo de requisitos tiene como objetivo delimitar el sistema y capturar la
funcionalidad que debe ofrecer desde la perspectiva del usuario. Este modelo
puede funcionar como un contrato entre el desarrollador y el cliente o usuario del
sistema, y por lo tanto proyecta lo que el cliente desea segn la percepcin del
desarrollador. Por lo tanto, es esencial que los clientes puedan comprender este
modelo.
El modelo de requisitos es el primer modelo a desarrollarse, sirviendo de base
para la formacin de todos los dems modelos en el desarrollo de software. En
general, el cualquier cambio en la funcionalidad del sistema es ms fcil de hacer,
y con menores consecuencias, a este nivel que posteriormente. El modelo de
requisitos que desarrollaremos se basa en la metodologa Objectory (Jacobson et
al. 1992), basada principalmente en el modelo de casos de uso.
Actualmente esta metodologa es parte del Proceso Unificado de Rational (RUP).
El modelo de casos de uso y el propio modelo de requisitos son la base para los
dems modelos.

Herramientas ms Usadas

Entrevistas y cuestionarios: Las entrevistas y cuestionarios se emplean
para reunir informacin proveniente de personas o grupos, informacin que
se obtiene conversando con el encuestado. Las preguntas suelen
distinguirse en dos categoras: abiertas y cerradas. Las preguntas abiertas
permiten que los encuestados respondan con su propia terminologa,
mientras que las preguntas cerradas predeterminan todas las posibles
respuestas y el interrogado elige entre las opciones presentadas.
Grabaciones de video y de audio: Bsicamente existen dos formas de
utilizar las grabaciones: como registro y apoyo de las entrevistas, y para
analizar algn proceso en particular. En cuanto a su funcin de apoyo, es
importante porque permite centrar la atencin en la entrevista en s, en vez
de distraerse tomando notas de todo lo que se dice. Cuando se trata de
analizar algn proceso en particular, su ayuda es inestimable (sobre todo
las filmaciones de video) porque permite ver y analizar en detalle ese
proceso la cantidad de veces que sea necesario.
Brainstorming (tormenta de ideas): Este es un modelo que se usa para
generar ideas. La intencin en su aplicacin es la de generar la mxima
cantidad posible de requisitos para el sistema. No hay que detenerse en
pensar si la idea es o no del todo utilizable.
Fases del Modelado de Requisitos



Fases del Modelado de Requisitos

Fase de concepcin (anlisis)
Esta fase tiene como propsito definir y acordar el alcance del proyecto con los
patrocinadores, identificar los riesgos potenciales
asociados al proyecto, proponer una visin muy general de la arquitectura de
software y producir el plan de las fases y el de iteraciones.
Fase de elaboracin (diseo)
En la fase de elaboracin se seleccionan los casos de uso que permiten definir la
arquitectura base del sistema y se desarrollaran en esta fase, se realiza la
especificacin de los casos de uso seleccionados y el primer anlisis del dominio
del problema, se disea la solucin preliminar.
Fase de construccin (implementacin)
El propsito de esta fase es completar la funcionalidad del sistema, para ello se
deben clarificar los requerimientos pendientes, administrar los cambios de acuerdo
a las evaluaciones realizados por los usuarios y se realizan las mejoras para el
proyecto.
Fase de transicin (pruebas)
El propsito de esta fase es asegurar que el software est disponible para los
usuarios finales, ajustar los errores y defectos encontrados en las pruebas de
aceptacin, capacitar a los usuarios y proveer el soporte tcnico necesario. Se
debe verificar que el producto cumpla con las especificaciones entregadas por las
personas involucradas en el proyecto.

Documentacin
El modelo de casos de uso debe ser documentado a lo largo de las diversas
actividades, dando lugar a distintos documentos como los manuales de usuario,
manuales de administracin, etc.

1. 2.http://www.utvm.edu.mx/OrganoInformativo/orgJ ul07/RUP.htm
2. 3. http://w ww.infor.uva.es/~mlaguna/is1/apuntes/2-requisitos.pdf



2.4. Herramientas CASE para la Ingeniera de
requisitos
A medida que pasa el tiempo se logra entender que el empleo del software es una
buena opcin para agilizar y sistematizar las tareas en el desarrollo de procesos.
El desarrollo de software no es la excepcin; en este caso dichas herramientas se
han denominado CASE (Ingeniera De Software Asistida Por Computador). Estas
incluyen un conjunto de programas que facilitan la optimizacin de un producto
ofreciendo apoyo permanente a los analistas, ingenieros de software y
desarrolladores. CASE es la aplicacin de mtodos y tcnicas que dan utilidades a
los programas, por medio de otros, procedimientos y su respectiva
documentacin.
En este post se hace referencia a 3 herramientas que ayudan a la gestin de
requisitos; es decir al proceso de identificacin, asignacin y seguimiento de los
mismos, incluyendo interfaz, verificacin, modificacin y control de cada
requisito, durante el ciclo de vida del proyecto. Los cambios/actualizaciones de
requisitos deben ser gestionados para asegurar que se mantenga la calidad del
producto.

IRQA
Herramienta CASE de Ingeniera de Requisitos, diseada para soportar las
actividades realizadas en el proceso de especificacin de sistemas. sta facilita y
formaliza la comunicacin entre el cliente, el proveedor y los distintos miembros
del equipo de desarrollo. Facilita la captura, organizacin y anlisis de las
condiciones, as como la especificacin de la solucin mediante el apoyo
metodolgico adaptable a cada cliente.

CONTROLA
Herramienta de apoyo al proceso de ingeniera de software en pequeas
empresas. Se cre gracias a la expansin que tuvo el mercado y a la
generacin de grandes y pequeas empresas, las cuales requieren un instrumento
para el desarrollo de sus proyectos. Ofrece recursos importantes tales como:
Administracin de requisitos, administracin de casos de uso, administracin de
casos de prueba y error, planeamiento de liberaciones, administracin
de implementaciones, control de dependencia entre Implementaciones, matriz
de rastreabilidad y rastreabilidad de los requisitos.

RETO
Esta herramienta propone un modelo de requisitos para capturar los aspectos
funcionales del sistema, bsicamente, mediante tres tcnicas complementarias
entre si: la definicin de la misin del sistema, la construccin del rbol de
refinamiento de funciones y el desarrollo de modelo de uso.
OSRMT
Herramienta libre para la gestin de requisitos, cuyas principales caractersticas
son: trabaja en arquitectura cliente/servidor, desarrollada bajo Java; la versin 1.3
trae un mdulo para manejar la trazabilidad y lo introduce para el control de
cambios; as mismo, genera la documentacin de los requisitos tratados.
JEREMIA
Se trata de una aplicacin cliente exclusivamente, lo cual no permite la posibilidad
de trabajar en equipo. Esta herramienta ayuda durante el desarrollo del sistema,
especialmente con el seguimiento de cambio de los requisitos a lo largo del ciclo
de vida.
RAMBUTAN
Esta herramienta esta basada en XML, realmente consta de un conjunto de
aplicaciones para el usuario final ayudando a los analistas del sistema en la
recopilacin y la categorizacin de hechos en un documento de especificacin de
requisito.
En comparacin con otras herramientas la gestin de requisitos rambutn y las
ofrecen la<s siguientes ventajas competitivas: aplicacin del cliente (PDA- class)
portabilidad entre plataformas, independiente a cualquier metodologa de
especificacin de requisitos herramientas de distribucin libre.


Fuente:
http://unidad2requerimientos.blogspot.mx/





2.4 Herramientas CASE para la ingeniera de
requisitos

Borland Caliber Analyst
Se trata de un producto que est compuesto por dos aplicaciones desarrolladas
por la compaa Borland.
Por un lado est el Caliber DefineIT (la ltima de las herramientas en cuanto a
fecha de lanzamiento) que permite definir los requisitos del sistema as como
capturar los diferentes escenarios de negocio a travs de diferentes herramientas
visuales; es necesario sealar que este software es compatible con gran nmero
de herramientas existentes en el mercado.
CASE Spec
Esta herramienta est desarrollada por la empresa Goda Software, siendo esta
una aplicacin comercial de uso exclusivo para el sistema operativo Windows.
Las principales caractersticas que avalan a esta herramienta son las siguientes:
Especificacin: posibilidad de realizar las especificaciones tanto con las tcnicas
tradicionales como con los diagramas de casos de uso. Adems, nos permite
crear diagramas UML y de flujo de datos.
Seguimiento de los requisitos: a travs del uso combinado de un procesador de
textos y una hoja de clculo, el usuario ser capaz de realizar el seguimiento de
los requisitos as como hacer un informe acerca de los mismos.
Capacidad de rastreo: mediante la existencia de una matriz se representan de
manera sencilla las diferentes relaciones existentes entre los requisitos definidos y
otra serie de elementos incidentes en el proyecto.
IRQA 4
Herramienta desarrollada por Visure y que tiene la meta de servir como aplicacin
para proporcionar un soporte integral en la ingeniera de requisitos de un proyecto
de informtica.
A parte de incluir las tareas ms bsicas de la ingeniera de requisitos (captura,
anlisis, modelado, organizacin y seguimiento).

Tiger Pro
Estamos ante una herramienta shareware desarrollada para facilitar al usuario la
tarea de redactar los requerimientos de un proyecto. Este aplicativo es capaz de
solucionar algunos de los defectos que aparecen a la hora de definir los requisitos
de un programa. Tambin ayuda al usuario a aclarar algunos de los
requerimientos desde el punto de vista de las pruebas a realizar, sealando
aquellos requerimientos cuya verificacin pueda resultar complicada.
GatherSpace
A la hora de realizar la definicin de los requisitos para un proyecto de informtica,
el trabajo conjunto de todo el equipo de desarrollo es una parte fundamental para
conseguir un buen resultado. Esta herramienta de definicin y gestin de
requisitos utiliza Internet como su lanzadera, ya que no es necesario instalar
ningn programa para utilizarla: bastar con crear una cuenta en el sitio web de la
misma y comenzar a definir el proyecto que se quiere desarrollar.
IBM Rational Requisite Pro
Esta herramienta, desarrollada por una de las compaas ms importantes dentro
del campo de la informtica, se considera una de las herramientas ms completas
y potentes dentro del anlisis y la gestin de los requisitos.



Bibliografa:
http://ldc.usb.ve/~abianc/materias/ci4712/apuntes3.pdf
http://www.rodolfoquispe.org/blog/que-es-la-ingenieria-de-requisitos.php