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