2 Ingenieria de requisitos

2.1. Tareas de la Ingenieria de Requisitos

Se define como un conjunto de actividades en los cuales, utilizando tecnicas y herramientas, se analiza un problema y se concluye con la especificación de una solución. La ingeniería de requisitos es el proceso de desarrollar una especificación de software.

ÿ Inicio:

Tiene por objetivo identificar el ámbito del proyecto general. Comienza con una serie de conversaciones informales entre los participantes del mismo. Esta fase suele ser acompañada de los documentos de definición de la visión global y la visión del dominio del sistema. Se inicia muchas veces por: se descubre un nuevo mercado y se descubre un nuevo servicio.

ÿ Obtención:

Se sugiere a los ingenieros recopilar requisitos de manera organizada, preguntando a los usuarios y otros interesados cuales son os objetivos para el sistema o producto, que es lo que se debe lograr, de que forma el producto satisface las necesidades del negocio y como se utilizara el producto día d día. Se identifican una serie de problemas que ayudan a entender porque es difícil la obtención de requisitos:

1 Problema de ámbito

1 Problema de comprensión

1 Problemas de volatilidad

ÿ Elaboración:

Se crea un modelo de análisis con la información obtenida del cliente en las fases de inicio y obtención. La información conseguida con el cliente durante el inicio y obtención se expande y se refina durante la elaboración. Esta actividad se enfoca en el desarrollo de un modelo técnico refinado de las funciones, características y restricciones del software. La elaboración se conduce mediante la creación y refinamiento de escenarios del usuario que describan la forma en que el usuario final y otros actores interactúan con el sistema.

ÿ Negociación:

En esta etapa el ingeniero de requisitos debe negociar con el cliente los alcances y límites 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.

ÿ Especificación:

Es el producto final de la ingeniería de requisitos, y se convierte en la materia prima para las actividades posteriores en el proceso de desarrollo del sistema. Una especificación puede ser un documento escrito, un conjunto de modelos gráficos, un modelo matemático formal, una colección de escenarios de uso, un prototipo o cualquier combinación de estos.

ÿ Validación:

Un equipo de validación toma el producto de la fase de especialización, lo revisa para detectar errores, conflictos u omisiones y los corrige con el fin de garantizar la consistencia de requisitos. La validación de requisitos examina la especificación para asegurar que todos los requisitos de software se han establecidos de manera precisa; que se han detectado las inconsistencias omisiones y errores y que estos han sido corregidos y que el producto de trabajo cumple con los estándares establecidos para el proceso, proyecto y producto.

ÿ Gestión de requisitos:

Ayuda a rastrear los requisitos según las características de los mismos, el código fuente relacionado, dependencia entre requisitos, subsistemas e interfaces internas y externas de forma que pueda identificarse con rapidez para entender como afectara una modificación diferentes aspectos del sistema a construir. Es un conjunto de actividades que ayudan al equipo de proyecto a identificar, controlar y rastrear los requisitos y los cambios a estos en cualquier momento mientras se desarrolla el proyecto.

2.2. Técnicas de la Ingeniería de Requisitos

En la Ingeniería de Requisitos se describen técnicas que permiten la captura requisitos de software, la recopilación de la información y en qué casos es adecuada usar cada cual. A continuación se hace un análisis de estas técnicas. (Sommerville, 1997).

Técnica: Entrevistas.

Características.

Forma de conversación, no de interrogación.

Ocupan un lugar preponderante de acuerdo al tiempo que ocupan y el objetivo que tienen.

Mayor fuente de información del analista

Basadas en un cuestionario rígido o una guía que las orienta hacia puntos bien definidos.

Ventajas

Se presenta necesidades de forma directa y se verifica si las preguntas fueron interpretadas correctamente.

Oportunidad para conocer el grado de aceptación o no entre los usuarios hacia el sistema que se desea diseñar. Mediante ellas se obtiene una gran cantidad de información correcta a través del usuario.

Pueden ser usadas para obtener un pantallazo del dominio del problema.

Son flexibles

Cuestionarios: Las entrevistas y cuestionarios se emplean para reunir información proveniente de personas o grupos, información que se obtiene conversando con el encuestado. Las preguntas suelen distinguirse en dos categorías: abiertas y cerradas. Las preguntas abiertas permiten que los encuestados respondan con su propia terminología, mientras que las preguntas cerradas predeterminan todas las posibles respuestas y el interrogado elige entre las opciones presentadas.

Grabaciones De Video Y De Audio: Básicamente existen dos formas de utilizar las grabaciones: como registro y apoyo de las entrevistas, y para analizar algún proceso en particular. En cuanto a su función de apoyo, es importante porque permite centrar la atención en la entrevista en sí, en vez de distraerse tomando notas de todo lo que se dice. Cuando se trata de analizar algún 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 intención en su aplicación es la de generar la máxima cantidad posible de requisitos para el sistema. No hay que detenerse en pensar si la idea es o no del todo utilizable.

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 según la percepción 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 formación de todos los demás modelos en el desarrollo de software. En general, el cualquier cambio en la funcionalidad del sistema es más fácil de hacer, y con menores consecuencias, a este nivel que posteriormente. El modelo de requisitos que desarrollaremos se basa en la metodología Objectory (Jacobson et al. 1992), basada principalmente en el modelo de casos de uso.

Actualmente esta metodología 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 demás modelos.

·         Requisitos: El modelo de casos de uso sirve para expresar el modelo de requisitos, el cual se desarrolla en cooperación con otros modelos como se verá más adelante.

·         Análisis: La funcionalidad especificada por el modelo de casos de uso se estructura en el modelo de análisis, que es estable con respecto a cambios, siendo un modelo lógico independiente del ambiente de implementación.

·         Diseño: La funcionalidad de los casos de uso ya estructurada por el análisis es realizada por el modelo de diseño, adaptándose al ambiente de implementación real y refinándose aún más.

·         Implementación: Los casos de uso son implementados mediante el código fuente en el modelo de implementación.

·         Pruebas: Los casos de uso son probados a través de las pruebas de componentes y pruebas de integración.

·         Documentación: 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 administración, etc.

El propósito 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 también se desarrollan directamente de él. El modelo de requisitos sirve también 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 mecánico, el analista debe interactuar constantemente con el cliente para completar la información faltante, y así clarificar ambigüedades e inconsistencias. El analista debe separar entre los requisitos verdaderos y las decisiones relacionadas con el diseño e implementación. Se debe indicar cuales aspectos son obligatorios y cuales son opcionales para evitar restringir la flexibilidad de la implementación. Durante el diseño se debe extender el modelo de requisitos con especificaciones de rendimiento y protocolos de interacción con sistemas externos, al igual que provisiones sobre modularidad y futuras extensiones. En ciertas ocasiones ya se puede incluir aspectos de diseño, como el uso de lenguajes de programación particulares.

En la metodología 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 presentación o modelo de interfaces, especifica cómo interactúa el sistema con actores externos al ejecutar los casos de uso, en particular, en los sistemas de información ricos en interacción con el usuario, especifica cómo se verán visualmente las interfaces gráficas y que funcionalidad ofrecerá cada una de ellas.

·         El modelo de información o modelo del dominio del problema especifica los aspectos estructurales del sistema.

Este modelo conceptualiza el sistema según los objetos que representan las entidades básicas de la aplicación.

Aunque en muchas metodologías 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 más ayuda como apoyo al modelo de casos de uso y no como una entidad totalmente independiente.

Es importante resaltar que esta separación 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 descripción del problema. A partir de esta descripción inicial se describirán los tres modelos básicos del modelo de requisitos.

2.4. Herramientas CASE para la Ingenieria de requisitos.

El desarrollo de software ha ocupado un lugar importante en la Ingeniería, pero al igual que otras disciplinas, aún presenta fallas. Debido a esto se han planteado técnicas y métodos para minimizar los problemas identificados en la crisis del software. Es así como surge la Ingeniería de Software, presentando distintos modelos de procesos que se ajustan a las necesidades y proyectos requeridos. La mayoría de ellos involucran en sus fases iníciales tareas como planeación, levantamiento de información, determinación de las características que debe cumplir el software, agrupadas en lo que hoy se conoce como Ingeniería de Requisitos (IR).

 IRQA 43

Herramienta CASE de Ingeniería de Requisitos, diseñada para soportar las actividades realizadas en el proceso de especificación de sistemas. Ésta facilita y formaliza la comunicación entre el cliente, el proveedor

y los distintos miembros del equipo de desarrollo. Facilita la captura, organización y análisis de las condiciones, así como la especificación de la solución mediante el apoyo metodológico adaptable

a cada cliente.

RETO

Esta herramienta propone un modelo de requisitos para capturar los aspectos funcionales del sistema; básicamente, mediante tres técnicas complementarias entre sí: la definición de la Misión del Sistema, la construcción del Árbol de Refinamiento de Funciones y el desarrollo del Modelo de Casos de Uso. Además, se introduce un Proceso de Análisis que permite traducir el Modelo de Requisitos en el Mo- delo Conceptual, manteniendo la trazabilidad entre ambos y propiciando una representación de la información

en el segundo prototipo.

CONTROLA

Herramienta de apoyo al proceso de ingeniería de software en pequeñas empresas. Se creó gracias a la expansión que tuvo el mercado y a la generación de grandes y pequeñas empresas, las cuales requieren un instrumento para el desarrollo de sus proyectos. Ofrece recursos importantes tales como: Administración de requisitos, administración de casos de uso, administración de casos de prueba y error, planeamiento de liberaciones, administración de implementaciones, control de dependencia entre Implementaciones, matriz de rastreabilidad y rastreabilidad de los requisitos.

OSRMT (Open Source Requirements Management Tool)4

Herramienta libre para la gestión de requisitos, cuyas principales características son: trabaja en arquitectura cliente/servidor, desarrollada bajo Java; la versión 1.3 trae un módulo para manejar la trazabilidad y lo introduce para el control de cambios; así mismo, genera la documentación de los requisitos tratados.

JEREMIA5

Se trata exclusivamente de una aplicación cliente exclusivamente, lo cual no permite la posibilidad de trabajar en equipo. Ésta, ayuda durante el desarrollo desarrollo del sistema, especialmente en el seguimiento de cambios de los requisitos a lo largo del ciclo de vida. Con JEREMIA es posible captar las necesidades, analizarlas y clasificarlas. Implementa un módulo orientado a la generación de la documentación posible de exportar en formato DocBook XML, la cual junto con los requisitos, se almacena en una base de datos en MySQL.

RAMBUTAN6

Esta herramienta está basada en XML, realmente consta de un conjunto de aplicaciones para el usuario final, ayudando a los analistas de sistemas en la recopilación y categorización de hechos en un documento de especificación de requisitos. Lo curioso es que tiene un cliente para palm (PDA), el cual se utiliza para recopilar los hechos en el lugar donde está ubicado el cliente mientras que la aplicación de escritorio recibe la información, edita y perfecciona. Ambas aplicaciones permiten al usuario introducir, modificar y visualizar los datos que componen un documento de especificación de requisitos