Unidad 2:

Ingeniera de requisitos

Rodrigo Bautista Dmazo

2.1-Tareas de la ingeniera de requisitos

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.

2.2-Tecnicas de la ingeniera de requisitos

La ingeniera de requisitos puede ser un proceso largo y arduo para el que se requiere de habilidades psicolgicas. Los nuevos sistemas cambian el entorno y las relaciones entre la gente, as que es importante identificar a todos los actores involucrados, considerar sus necesidades y asegurar que entienden las implicaciones de los nuevos sistemas. Los analistas pueden emplear varias tcnicas para obtener los requisitos del cliente. Histricamente, esto ha incluido tcnicas tales como las entrevistas, o talleres con grupos para crear listas de requisitos. Tcnicas ms modernas incluyen los prototipos, y utilizan casos de uso. Cuando sea necesario, el analista emplear una combinacin de estos mtodos para establecer los requisitos exactos de las personas implicadas, para producir un sistema que resuelva las necesidades del negocio. Entrevistas Las entrevistas son un mtodo comn. Por lo general no se entrevista a toda la gente que se relacionar con el sistema, sino a una seleccin de personas que represente a todos los sectores crticos de la organizacin, con el nfasis puesto en los sectores ms afectados o que harn un uso ms frecuente del nuevo sistema. Talleres Los requisitos tienen a menudo implicaciones cruzadas desconocidas para las personas implicadas individuales y que a menudo no se descubren en las entrevistas o quedan incompletamente definidas durante la misma. Estas implicaciones cruzadas pueden descubrirse realizando en un ambiente controlado, talleres facilitados por un analista del negocio, en donde las personas implicadas participan en discusiones para descubrir requisitos, analizan sus detalles y las implicaciones cruzadas. A menudo es til la seleccin de un secretario dedicado a la documentacin de la discusin, liberando al analista del negocio para centrarse en el proceso de la definicin de los requisitos y para dirigir la discusin.

Forma de contrato En lugar de una entrevista, se pueden llenar formularios o contratos indicando los requisitos. En sistemas muy complejos stos pueden tener centenares de pginas. Objetivos medibles Los requisitos formulados por los usuarios se toman como objetivos generales, a largo plazo, y en cambio se los debe analizar una y otra vez desde el punto de vista del sistema hasta determinar los objetivos crticos del funcionamiento interno que luego darn forma a los comportamientos apreciables por el usuario. Luego, se establecen formas de medir el progreso en la construccin, para evaluar en cualquier momento qu tan avanzado se encuentra el proyecto. Prototipos Un prototipo es una pequea muestra, de funcionalidad limitada, de cmo sera el producto final una vez terminado. Ayudan a conocer la opinin de los usuarios y rectificar algunos aspectos antes de llegar al producto terminado. Casos de uso Un caso de uso es una tcnica para documentar posibles requisitos, graficando la relacin del sistema con los usuarios u otros sistemas. Dado que el propio sistema aparece como una caja negra, y slo se representa su interaccin con entidades externas, permite omitir dichos aspectos y determinar los que realmente corresponden a las entidades externas. El objetivo de esta prctica es mejorar la comunicacin entre los usuarios y los desarrolladores, mediante la prueba temprana de prototipos para minimizar cambios hacia el final del proyecto y reducir los costes finales. Esta tcnica se enfrenta a los siguientes peligros potenciales.

A los directivos, una vez que ven un prototipo, les cuesta comprender que queda mucho trabajo por hacer para completar el diseo final. Los diseadores tienden a reutilizar el cdigo de los prototipos por temor a perder el tiempo al comenzar otra vez. Los prototipos ayudan principalmente a las decisiones del diseo y de la interfaz de usuario. Sin embargo, no proporcionan explcitamente cules son los requisitos. Los diseadores y los usuarios finales pueden centrarse demasiado en el diseo de la interfaz de usuario y demasiado poco en producir un sistema que sirva el proceso del negocio.

Los prototipos pueden ser: diagramas, aplicaciones operativas con funcionalidades sintetizadas. Los diagramas, en los casos donde se espera que el software final tenga diseo grfico, se realizan en una variedad de documentos de diseo grficos y a menudo elimina todo el color del diseo del software (es decir utilizar una gama de grises). Esto ayuda a prevenir la confusin sobre la apariencia final de la aplicacin.

2.3-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. Requisitos: El modelo de casos de uso sirve para expresar el modelo de requisitos, el cual se desarrolla en cooperacin con otros modelos como se ver ms adelante. Anlisis: La funcionalidad especificada por el modelo de casos de uso se estructura en el modelo de anlisis, que es estable con respecto a cambios, siendo un modelo lgico independiente del ambiente de implementacin. Diseo: La funcionalidad de los casos de uso ya estructurada por el anlisis es realizada por el modelo de diseo, adaptndose al ambiente de implementacin real y refinndose an ms. Implementacin: Los casos de uso son implementados mediante el cdigo fuente en el modelo de implementacin. Pruebas: Los casos de uso son probados a travs de las pruebas de componentes y pruebas de integracin. 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. El propsito del modelo de requisitos es comprender completamente el problema y sus implicaciones. Todos los modelos no solamente se verifican contra el modelo de requisitos, sino que tambin se desarrollan directamente de l. El modelo de requisitos sirve tambin como base para el desarrollo de las instrucciones operacionales y los manuales ya que todo lo que el sistema deba hacer se describe aqu desde la perspectiva del usuario. El modelo de requisitos no es un proceso mecnico, el analista debe interactuar constantemente con el cliente para completar la informacin faltante, y as clarificar ambigedades e inconsistencias. El analista debe separar entre los requisitos verdaderos y las decisiones relacionadas con el diseo e implementacin. Se debe indicar cuales aspectos son obligatorios y cuales son opcionales para evitar restringir la flexibilidad de la implementacin. Durante el diseo se debe extender el modelo de requisitos con especificaciones de rendimiento y protocolos de interaccin con sistemas externos, al igual que provisiones sobre modularidad y futuras extensiones. En ciertas ocasiones ya se puede incluir aspectos de diseo, como el uso de lenguajes de programacin particulares. En la metodologa de Objectory, el modelo de requisitos consiste de tres modelos principales.

El modelo de comportamiento, basado directamente en el modelo de casos de uso, especifica la funcionalidad que ofrece el sistema desde el punto de vista del usuario. Este modelo utiliza dos conceptos claves: actores para representar los distintos papeles que los usuarios pueden jugar con el sistema, y casos de uso para representar qu pueden hacer los actores con respecto al sistema El modelo de presentacin o modelo de interfaces, especifica cmo interacta el sistema con actores externos al ejecutar los casos de uso, en particular, en los sistemas de informacin ricos en interaccin con el usuario, especifica cmo se vern visualmente las interfaces grficas y que funcionalidad ofrecer cada una de ellas. El modelo de informacin o modelo del dominio del problema especifica los aspectos estructurales del sistema.

Este modelo conceptualiza el sistema segn los objetos que representan las entidades bsicas de la aplicacin. Aunque en muchas metodologas se permite especificar la funcionalidad completa del sistema utilizando el modelo del dominio del problema, incluyendo operaciones formales sobre los objetos correspondientes a un modelo de requisitos expresado sin casos de uso, el modelo del dominio del problema ser de mucha ms ayuda como apoyo al modelo de casos de uso y no como una entidad totalmente independiente. Es importante resaltar que esta separacin en tres ejes de modelado independientes es la base para una mayor estabilidad en el desarrollo del sistema, permitiendo minimizar los efectos de cada uno sobre los otros dos. Para ilustrar el modelo de requisitos y el desarrollo de los modelos posteriores, utilizaremos el ejemplo del Sistema de Reservaciones de Vuelo como se mencion anteriormente. Para tal meta, mostraremos inicialmente una descripcin del problema. A partir de esta descripcin inicial se describirn los tres modelos bsicos del modelo de requisitos.

2.4 Herramientas CASE para la ingeniera de requisitos

1. 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. 2. 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. 3. 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). 4. 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. 5. 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. 6. 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