2.2 TCNICAS DE LA INGENIERA DE REQUISITOSINTRODUCCIN 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.ENTREVISTASLas 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.ESCENARIOSNormalmente, 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 USOSLos 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 trabajo2. 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.

REUNIONESCuando 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 JAD: 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 ARCHIVOSTcnica 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.

MUESTREOSEs 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 usuariospara 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.htmlAutor: francis coronel, Publicado: lunes, 11 de marzo de 2013http://ithjuanah.blogspot.mx/Autor: Juana Hernndez Hernndez