Gestión de Requisitos

Resumen

La Gestión de Requisitos, es el proceso encargado de la identificación, asignación, verificación, y modificación de los requisitos a lo largo del ciclo de vida del software. Además es considerada como uno de los procesos más importantes dentro de la Ingeniería de Requisitos. Con una buena Gestión de Requisitos se logra crear software de buen rendimiento que satisface realmente las necesidades del usuario. En este trabajo se abordan los aspectos teóricos necesarios sobre la Gestión de Requisitos, las características más importantes de la misma y las herramientas más utilizadas para su realización. Se hace referencia a las ventajas y desventajas de la Reutilización de Requisitos como una buena alternativa para la reducción del tiempo del trabajo de los proyectos.

Palabras claves: Gestión de Requisitos, Ingeniería de Requisitos.

Introducción

En la actualidad en la Industria de Software existe una tendencia al crecimiento del volumen y complejidad de los productos, y se exige mayor calidad y productividad en menos tiempo. El proceso de desarrollo de software se encarga de traducir las necesidades del usuario en requerimientos de software (Richard , 1997). Estos requerimientos transformados en diseño y el diseño implementado en código, el código es probado, documentado y certificado para su uso operativo.

La Ingeniería de Software, se considera la rama de la ingeniería que aplica los principios de la ciencia de la computación y las matemáticas para lograr soluciones costo-efectivas a los problemas de desarrollo de software, es decir, permite elaborar consistentemente productos correctos, utilizables y costos-efectivos. La misma requiere llevar a cabo varias tareas, una de ellas es el análisis de requisitos. El análisis de requisitos permite extraer los requisitos de un producto de software. La Ingeniería de Software es una tecnología que indica "CÓMO" construir técnicamente un software: económico, fiable y que funcione eficientemente. (Jacobson, 2000)(Booch; 2000 ) .

La ingeniería de requisitos es una disciplina de la Ingeniería de software. Esta disciplina considera diferentes líneas de trabajo, pero una de las más importantes es la gestión de requisitos, la cual se encarga de proveer la dirección y alcance del proyecto. Los requisitos deben ser la base de cualquier desarrollo de software. La obtención de una especificación de requisitos de alta calidad es fundamental para asegurar que el software se corresponde con las necesidades del cliente. En el análisis de requisitos se investiga la parte del mundo real (también llamado universo de discurso o minimundo) que se va a modelar para tener en cuenta todas las necesidades de los usuarios finales y así dejarlas documentadas de la forma más completa posible.

Desarrollo

¿Qué es un requerimiento/requisito?

Normalmente, un tema de la Ingeniería de Software tiene diferentes significados. De las muchas definiciones que existen para requerimiento, a continuación se presenta la definición que aparece en el glosario de la IEEE. (Richard ,1997) .

(1) Una condición o necesidad de un usuario para resolver un problema o alcanzar un objetivo. (2) Una condición o capacidad que debe estar presente en un sistema o componentes de sistema para satisfacer un contrato, estándar, especificación u otro documento formal. (3) Una representación documentada de una condición o capacidad como en (1) o (2). (Richard , 1997)

Características de los requerimientos

Los requerimientos deben especificarse antes de intentar comenzar la construcción del producto, sin ellos no podrá ser posible llevar a cabo las etapas de diseño y construcción correctamente. Los mismos pueden verse como una declaración abstracta de alto nivel de un servicio que el sistema debe proporcionar, como una definición matemática detallada y formal. Los requisitos cumplen una doble función ya que son la base para una oferta de contrato, por lo tanto deben estar abiertos a la interpretación. Además son la base para redactar el contrato en sí mismo.

Los requisitos una vez establecidos y documentados, sufren cambios continuos, en este sentido, no se trata la obtención ni el análisis de los mismos, se trata de su gestión, es decir, el seguimiento respecto a los cambios que se generan durante el ciclo de vida del proyecto y las herramientas de gestión de requisitos que auxilian y/o automatizan estas tareas. El uso de herramientas para auxiliar la gestión de requisitos se ha convertido en un aspecto importante de la Ingeniería de Sistemas y el diseño. Considerando el tamaño y la complejidad del desarrollo, las herramientas vienen siendo algo esencial. Las herramientas que los gestores de requisitos utilizan para automatizar los procesos de Ingeniería de Requisitos han disminuido el trabajo duro en el mantenimiento de requisitos, añadiendo beneficios significativos al reducir errores. (Loucopoulos, 1995).

Las características de un requerimiento son sus propiedades principales. Un conjunto de requerimientos en estado de madurez, deben presentar una serie de características tanto individualmente como en grupo. A continuación se presentan las más importantes.

Necesario: Un requerimiento es necesario si su omisión provoca una deficiencia en el sistema a construir, y además su capacidad, características físicas o factor de calidad no pueden ser reemplazados por otras capacidades del producto o del proceso.

Conciso: Un requerimiento es conciso si es fácil de leer y entender. Su redacción debe ser simple y clara para aquellos que vayan a consultarlo en un futuro.

Completo: Un requerimiento está completo si no necesita ampliar detalles en su redacción, es decir, si se proporciona la información suficiente para su comprensión.

Consistente: Un requerimiento es consistente si no es contradictorio con otro requerimiento.

No ambiguo: Un requerimiento no es ambiguo cuando tiene una sola interpretación. El lenguaje usado en su definición, no debe causar confusiones al lector.

Verificable: Un requerimiento es verificable cuando puede ser cuantificado de manera que permita hacer uso de los siguientes métodos de verificación, inspección, demostración o pruebas.

Tipos de requisitos

Los requerimientos pueden dividirse en varios tipos dentro de ellos, se hará referencia a los siguientes:

• Requisitos de usuario

• Requisitos del sistema

• Requisitos funcionales

• Requisitos no funcionales

Requisitos de usuario

Declaraciones en lenguaje natural y en diversos diagramas de los servicios del sistema y de las restricciones bajo las que debe operar.

1.- El sistema debe permitir representar y acceder a archivos externos creados por otras herramientas.

2. Sentencias muy generales sobre lo que el sistema debería hacer.

Requisitos del sistema

Un documento estructurado que determina las descripciones detalladas de los servicios de sistema. Escrito como contrato entre el cliente y el contratista.

1.- El usuario deberá poder definir el tipo de un nuevo archivo externo.

2.- Cada tipo de archivo tendrá una herramienta asociada, que se le aplicará. 3.- Cada tipo de archivo se representará con un icono específico.

4.- El usuario deberá poder definir el icono que representa un tipo de archivo externo.

5.- Cuando el usuario selecciona un icono que representa un archivo externo, el efecto es aplicar la herramienta asociada con este tipo de archivo al archivo representado por el icono seleccionado.

Requisitos funcionales

Declaración de los servicios que el sistema debe proporcionar, cómo debe reaccionar a una entrada particular y cómo se debe comportar ante situaciones particulares. Describen la funcionalidad del sistema, y dependen del tipo de software, del sistema a desarrollar y de los usuarios del mismo.

Por lo general se describen mejor a través del modelo de Casos de uso y los Casos de uso como tal. Por lo tanto los requerimientos funcionales especifican el comportamiento de entrada y salida del sistema y surgen de la razón fundamental de la existencia del producto.

Requisitos no funcionales

Los requerimientos no funcionales son propiedades o cualidades que el producto debe tener. Restricciones que afectan a los servicios o funciones del sistema, tales como restricciones de tiempo, sobre el proceso de desarrollo, estándares, etc.

Los requerimientos no funcionales tienen que ver con características que de una u otra forma puedan limitar el sistema, como por ejemplo, el rendimiento (en tiempo y espacio), interfaces de usuario, fiabilidad (robustez del sistema, disponibilidad de equipo), mantenimiento, seguridad, portabilidad, etc. Algunas propiedades de los requerimientos no funcionales que hacen al producto atractivo, usable, rápido o confiable, son las siguientes:

Clasificación de los requisitos no funcionales

Requisitos del producto: Especifican el comportamiento del producto obtenido, velocidad de ejecución, memoria requerida, y porcentaje de fallos aceptables.

Requisitos organizacionales: Son una consecuencia de las políticas y procedimientos existentes en la organización, procesos estándar utilizados, de fechas de entrega, y documentación a entregar.

Requisitos externos: Presentan factores externos al sistema y a su proceso de desarrollo, interoperabilidad del sistema con otros, requisitos, legales, y éticos.

Requerimientos de apariencia o interfaz externa Ejemplo: Muy legible, Simple de usar, Profesional o tipo ejecutivo.

Requerimientos de Usabilidad Ejemplo: Facilidad de uso por personas que hablen otros idiomas distintos al del país donde el producto fue creado, Accesibilidad para personas discapacitadas, Consistencia en la interfaz de usuario, Documentación de usuario.

Requerimientos de Rendimiento Ejemplo: Velocidad de procesamiento o cálculo, Eficiencia, Disponibilidad, Tiempo de respuesta.

Requerimientos de Soporte Ejemplo: Adaptabilidad, Mantenimiento. Requerimientos de Portabilidad Ejemplo: El producto podrá ser usado bajo el sistema operativo Linux .

Requerimientos de Seguridad Confidencialidad: La información manejada por el sistema está protegida de acceso no autorizado y divulgación.

Integridad: la información manejada por el sistema será objeto de cuidadosa protección contra la corrupción y estados inconsistentes.

Disponibilidad: Significa que los usuarios autorizados se les garantizará el acceso a la información y que los dispositivos o mecanismos utilizados para lograr la seguridad no ocultarán o retrasarán a los usuarios para obtener los datos deseados en un momento dado.

Requerimientos de confiabilidad :Frecuencia y severidad de los fallos, Protección contra fallos, Recuperación, Predicción de fallos, Tiempo medio entre fallos.

Requerimientos de Software: Ejemplo: Sistema Operativo Windows 95 o Superior; Maquina Virtual de Java versión 1.3 o Superior; etc.

Requerimientos de Hardware: Ejemplo: se requiere disponer de un MODEM estándar o una tarjeta digitalizadora de video, etc.

A pesar de las diferentes características que nos brindan los requerimientos, existen dificultades para recolectar los requisitos, las cuales no nos permiten elegir los requerimientos con la calidad necesaria; ya que estos pueden relacionarse unos con otros y a su vez con otras partes del proceso. Pero aun así, se plantea que sin el levantamiento de requisitos no se podrían desarrollar procesos que son de vital importancia para el desarrollo del software. Los requisitos constituyen el enlace entre las necesidades reales de los clientes, usuarios y otros participantes vinculados al sistema.

¿Qué se entiende por Ingeniería de Requisitos (IR)?

La Ingeniería de Requisitos es definida como:

La disciplina de la Ingeniería de Software que trata con actividades y intenta comprender las necesidades exactas de los usuarios del sistema software, para traducir tales necesidades en instrucciones precisas y no ambiguas las cuales podrían ser posteriormente utilizadas en el desarrollo del sistema. ( Loucopoulos,1995).

Ingeniería de Requerimientos es el proceso en el cual se transforman los requerimientos declarados por los clientes , ya sean hablados o escritos, a especificaciones precisas, no ambiguas, consistentes y completas del comportamiento del sistema, incluyendo funciones, interfaces, rendimiento y limitaciones. Es el proceso mediante el cual se intercambian diferentes puntos de vista para recopilar y modelar lo que el sistema va a realizar. (Richard, 1997).

Ingeniería de Requisitos (IR). Sus Características

La Ingeniería de Requisitos en una disciplina de la Ingeniería de Software, en ésta, se identifica el propósito del sistema, dirección y alcance. Abarca un conjunto de actividades y transformaciones que pretenden comprender las necesidades de un sistema software y convertir la declaración de estas necesidades en una descripción completa, precisa y documentada siguiendo un determinado estándar.

La Ingeniería de Requerimientos cumple un papel primordial en el proceso de producción de software, ya que enfoca un área fundamental: la definición de lo que se desea producir. Su principal tarea consiste en la generación de especificaciones correctas que describan con claridad, sin ambigüedades, en forma consistente y compacta, el comportamiento del sistema; de esta manera, se pretende minimizar los problemas relacionados al desarrollo de sistemas. El proceso de Ingeniería de Requisitos tiene como objetivos, descubrir, modelar, validar y mantener un documento de requisitos, utilizando una combinación de métodos, herramientas y actores.

Actividades de la Ingeniería de Requerimientos

Las actividades de la Ingeniería de Requisitos más comunes son:

Estudio de Viabilidad

Elicitación de Requisitos

Análisis de Requisitos

Especificación de Requisitos(ERS)

Validación de Requisitos

Gestión de Requisitos

Estudio de viabilidad: El estudio de viabilidad permite decidir si el sistema propuesto es conveniente. Es un estudio rápido y orientado a conocer. Además tiene en cuenta si el sistema contribuye a los objetivos de la organización, si el sistema se puede realizar con la tecnología actual y con el tiempo y el coste previsto, y si el sistema puede integrarse con otros existentes.

Elicitación de requisitos: Elicitación (o extracción o determinación) de requisitos, es el proceso mediante el cual los usuarios descubren, revelan, articulan y comprenden los requisitos que desean. En esta etapa, se trata de descubrir los requisitos y personal técnico trabaja con los clientes y usuarios para descubrir el dominio de la aplicación, los servicios que se deben proporcionar y las restricciones. Puede implicar a usuarios finales, encargados, ingenieros implicados en el mantenimiento, expertos del dominio, etc. Son los llamados participantes (stakeholders).

Análisis de requisitos: El proceso de razonamiento sobre los requisitos obtenidos en la etapa anterior, detectando y resolviendo posibles inconsistencias o conflictos, coordinando los requisitos relacionados entre sí, etc.

Especificación de Requisitos (ERS):La especificación de requisitos de software es la actividad en la cual se genera el documento, con el mismo nombre, que contiene una descripción completa de las necesidades y funcionalidades del sistema que será desarrollado; describe el alcance del sistema y la forma en como hará sus funciones, definiendo los requerimientos funcionales y los no funcionales. En la SRS se definen todos los requerimientos de hardware y software, diagramas, modelos de sistemas y cualquier otra información que sirva de soporte y guía para fases posteriores.

Validación de requisitos: El proceso de confirmación, por parte de los usuarios, de que los requisitos especificados son válidos, consistentes, y completos.

Gestión de Requisitos: Es el proceso de manejar los requisitos que cambian durante el desarrollo del sistema.

El proceso de Ingeniería de Requisitos se adapta a los diferentes modelos de procesos de Ingeniería de Software como pueden ser, de cascada, espiral, prototipazo, transformacional, etc.

Validación de Requisitos La validación es la actividad de la IR que permite demostrar que los requerimientos definidos en el sistema son los que realmente quiere el cliente; además revisa que no se haya omitido ninguno, que no sean ambiguos, inconsistentes o redundantes.

En este punto es necesario recordar que la ERS debe estar libre de errores, por lo tanto, la validación garantiza que todos los requerimientos presentes en el documento de especificación sigan los estándares de calidad. No debe confundirse la actividad de evaluación de requerimientos con la validación de requerimientos. La evaluación verifica las propiedades de cada requerimiento, mientras que la validación revisa el cumplimiento de las características de la especificación de requisitos. Durante la actividad de validación pueden hacerse preguntas en base a cada una de las características que se desean revisar. La validación de requerimientos es importante pues de ella depende que no existan elevados costos de mantenimiento para el software desarrollado.

Personal involucrado en la Ingeniería de Requerimientos

Realmente, son muchas las personas involucradas en el desarrollo de los requerimientos de un sistema. Es importante saber que cada una de esas personas tienen diversos intereses y juegan roles específicos dentro de la planificación del proyecto; el conocimiento de cada papel desempeñado, asegura que se involucren a las personas correctas en las diferentes fases del ciclo de vida, y en las diferentes actividades de la IR.

No conocer estos intereses puede ocasionar una comunicación poco efectiva entre clientes y desarrolladores, que a la vez traería impactos negativos tanto en tiempo como en presupuesto. Los roles más importantes pueden clasificarse como sigue:

Usuario final: Son las personas que usarán el sistema desarrollado. Ellos están relacionados con la usabilidad, la disponibilidad y la fiabilidad del sistema; están familiarizados con los procesos específicos que debe realizar el software, dentro de los parámetros de su ambiente laboral. Serán quienes utilicen las interfaces y los manuales de usuario.

Usuario Líder: Son los individuos que comprenden el ambiente del sistema o el dominio del problema en donde será empleado el software desarrollado. Ellos proporcionan al equipo técnico los detalles y requerimientos de las interfaces del sistema.

Personal de Mantenimiento: Para proyectos que requieran un mantenimiento eventual, estas personas son las responsables de la administración de cambios, de la implementación y resolución de anomalías. Su trabajo consiste en revisar y mejorar los procesos del producto ya finalizado.

Analistas y programadores: Son los responsables del desarrollo del producto en sí; ellos interactúan directamente con el cliente.

Personal de pruebas: Se encargan de elaborar y ejecutar el plan de pruebas para asegurar que las condiciones presentadas por el sistema son las adecuadas. Son quienes van a validar si los requerimientos satisfacen las necesidades del cliente.

Otras personas que pueden estar involucradas, dependiendo de la magnitud del proyecto, pueden ser: administradores de proyecto, documentadores, diseñadores de base de datos, entre otros.

Análisis comparativo de las técnicas de Ingeniería de Requerimientos

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.

Permiten combinarse con otras técnicas.

Desventajas

La información obtenida al principio puede ser redundante o incompleta.

Si el volumen de información manejado es alto, requiere mucha organización de parte del analista, así como la habilidad para tratar y comprender el comportamiento de todos los involucrados.

Realización de las Entrevistas

Los pasos:

Preparación

Ejecución

Recapitulación

¿Cómo lograr una entrevista exitosa?

Acordar una cita por anticipado con las personas que se entrevistarán.

Avisar a los entrevistados sobre la naturaleza de la entrevista.

Planear una entrevista común por no más de una hora.

Prepararla conociendo de antemano a los individuos que se van a entrevistar.

Familiarizarse con el tema y preparar un conjunto apropiado de preguntas.

Durante la entrevista

Presentarse, subrayando el tema y la naturaleza del proyecto.

Comenzar con preguntas generales que establezcan el marco de trabajo.

Continuar con los temas y aspectos que surjan de quienes responden.

Asegurarse de encontrar por qué quienes responden creen que es tan importante el tema como para comentarlo.

Cuando todos los temas vistos se hayan discutido, realícense otras preguntas específicas que se crea deban discutirse.

Al finalizar, resumir la información recabada durante la misma.

Si se considera apropiado, indicar que se preparará un resumen escrito de la entrevista.

Considerar la posibilidad de continuar con la entrevista en otro momento.

Técnica: Cuestionarios.

Características

Permiten obtener información de un gran número de personas en corto tiempo, sin que estas deban estar presentes.

Son recomendables cuando:

Se requiere una pequeña cantidad de información de un gran número de personas en un corto periodo de tiempo.

La información se desea consolidar en tablas estadísticas.

Usuarios geográficamente dispersos.

¿Cómo desarrollar un Cuestionario?

Determinar qué datos se necesitan y qué personas están calificadas para proporcionarlos.

Seleccionar el tipo de cuestionario (abierto, cerrado).

Incluir preguntas redundantes, cuando sea necesario, para verificar consistencia.

Examine el cuestionario para detectar errores en preguntas que:

Puedan ser mal interpretadas.

No se puedan responder.

Se interpretarán en forma diferente dependiendo de cada entrevistado.

No proporcionan opciones adecuadas de respuesta.

No estén ordenadas adecuadamente.

Desventajas

Información suministrada por escrito.

Los encuestados pueden objetar preguntas, interpretarlas a su forma o no tomarlas en serio.

Difíciles de diseñar.

Antes de aplicar un Cuestionario:

Probarlo en un grupo pequeño para detectar otros problemas.

Analizar las respuestas de prueba para asegurar que el análisis se pueda llevar a cabo con los datos recopilados.

Técnica: Lluvia de Ideas

Ventajas

Los diferentes puntos de vista y las confusiones en cuento a terminología, son aclaradas por expertos.

Ayuda a desarrollar ideas unificadas basadas en la experiencia de un experto.

Desventaja

Es necesaria una buena compenetración del grupo participante.

Técnica: Prototipos

El uso de prototipos para recoger requisitos o comprobar si se han entendido perfectamente es una práctica cada vez más extendida, especialmente en sistemas que suponen un elevado grado de interactividad. En este caso los prototipos a evaluar no serán más que maquetas no operativas o especificaciones formales que un grupo de expertos deberán evaluar.

Ventajas

Ayudan a validar y desarrollar nuevos requerimientos.

Permite comprender aquellos requerimientos que no estén muy claros y que son de alta volatilidad.

Desventajas

El cliente puede llegar a pensar que el prototipo es una versión del software que será desarrollado.

A menudo, el desarrollador hace compromisos de implementación con el objetivo de acelerar la puesta en funcionamiento del prototipo.

Técnica: Análisis Jerárquico

Ventajas

Permite determinar el grado de importancia de cada requerimiento

Ayuda a identificar conflictos en los requerimientos.

Muestra el orden en que deben ser implementados los requerimientos

Desventaja

Debe construirse un estándar claro de evaluación, que incluya la participación del cliente.

Técnica: Casos de Uso

Ventajas

Representan los requerimientos desde el punto de vista del usuario.

Identifica requerimientos estancados, dentro de un conjunto de requerimientos.

Desventaja

En sistemas grandes, toma mucho tiempo definir todos los casos de uso.

El análisis de calidad depende de la calidad con que se haya hecho la descripción inicial.

Técnica: Estudio

Estudio de documentación: En esta técnica se estudia documentación o estándares que puedan informar sobre las actividades de las tareas a realizar, puesto que en muchas ocasiones algunos procedimientos ya están sujetos a algún tipo de regulación que es preciso tener en cuenta.

Estudio de la literatura: Otra valiosa fuente de información, especialmente adecuada si el equipo de desarrollo no tiene mucha experiencia en el dominio de aplicación del producto, es buscar en la literatura ejemplos de productos similares. En base a las ventajas y desventajas mostradas anteriormente, se hace una comparación entre algunas de las técnicas.

Entrevistas vs. Casos de Uso: Un alto porcentaje de la información recolectada durante una entrevista, puede ser usada para construir casos de uso. Mediante esto, el equipo de desarrollo puede entender mejor el ambiente de trabajo de los involucrados. Cuando el analista sienta que tiene dificultades para entender una tarea, pueden recurrir al uso de un cuestionario y mostrar los detalles recabados en un caso de uso. De hecho, durante las entrevistas cualquier usuario puede utilizar diagramas de casos de uso para explicar su entorno de trabajo.

Entrevistas vs. Lluvia de Ideas: Muchas de las ideas planteadas en el grupo, provienen de información recopilada en entrevistas o cuestionarios previos. Realmente la lluvia de ideas trata de encontrar las dificultades que existen para la comprensión de términos y conceptos por parte de los participantes; de esta forma se llega a un consenso.

Casos de Uso vs. Lluvia de Ideas: La lista de ideas proveniente del brainstorm puede ser representada gráficamente mediante casos de uso. Las Técnicas de la Ingeniería de Requisitos son de gran importancia, nos permiten conocer las diferentes alternativas que existen para identificar requerimientos.

Importancia de la Ingeniería de Requerimientos

Los principales beneficios que se obtienen de la Ingeniería de Requerimientos son

Permite gestionar las necesidades del proyecto en forma estructurada: Cada actividad de la IR consiste de una serie de pasos organizados y bien definidos.

Mejora la capacidad de predecir cronogramas de proyectos, así como sus resultados: La IR proporciona un punto de partida para controles subsecuentes y actividades de mantenimiento, tales como estimación de costos, tiempo y recursos necesarios.

Disminuye los costos y retrasos del proyecto: Muchos estudios han demostrado que reparar errores por un mal desarrollo no descubierto a tiempo, es sumamente caro.

Mejora la comunicación entre equipos: La especificación de requerimientos representa una forma de consenso entre clientes y desarrolladores. Si este consenso no ocurre, el proyecto no será exitoso.

Mejora la calidad del software: La calidad en el software tiene que ver con cumplir un conjunto de requerimientos (funcionalidad, facilidad de uso, confiabilidad, desempeño, etc.).

Evita rechazos de usuarios finales: La ingeniería de requerimientos obliga al cliente a considerar sus requerimientos cuidadosamente y revisarlos dentro del marco del problema, por lo que se le involucra durante todo el desarrollo del proyecto.

Gestión de Requisitos. Principales características

La Gestión de Requisitos es un componente vital en el desarrollo de un proyecto software ya que es una de las actividades de la Ingeniería de Requisitos más importantes. Los requisitos se inician cuando empieza un proyecto en las etapas de análisis y especificación de requisitos, posteriormente, dichos requisitos en el ciclo de vida de un proyecto pueden ser modificados por lo que se establece el concepto de Gestión de Requisitos, que es el tratamiento y control de las actualizaciones y cambios a los mismos. Debido a que un proyecto informático es susceptible de cambios, habría que proceder a su actualización o a la incorporación de nuevas funcionalidades o eliminar otras, esto obliga a mantener controlado y documentado el producto. Los cambios de requisitos deben ser gestionados para asegurar que la calidad de los mismos se mantenga, los problemas suscitados por los cambios de requisitos podrían incurrir en altos costos, siendo el requisito factor crítico de riesgo.

Más formalmente el Manejo de Requisitos es una forma sistemática de descubrir, organizar y documentar los requisitos del sistema. Además es el proceso que establece y mantiene un consenso entre el cliente y el grupo del proyecto en el cambio de los requisitos del sistema.

El término Gestión de Requisitos incluye:

Técnicas para Descubrimiento/Recogida de Requisitos

Recoger las peticiones del usuario y determinar las verdaderas necesidades de éste.

Técnicas de Análisis

Especificación y verificación

Manejo de Requisitos

Tareas principales de la Gestión de Requisitos.

Durante el proceso de la gestión de requisitos, hay que planear algunas actividades, dentro de las que se pueden mencionar las siguientes: la identificación de los requisitos, en proceso de gestión de los cambios, las políticas de trazabilidad, la cantidad de información sobre las relaciones entre los requisitos que se mantiene, entre otras.

Actividades y su descripción:

Recolección: Recolección y documentación de requisitos es una actividad de comunicación iterativa entre clientes, gerentes y practicantes, para descubrir, definir, refinar y registrar una representación precisa de los requisitos del producto. Varios métodos son utilizados para la recolección de requisitos. Algunos análisis iniciales como es la agrupación, categorización, priorización son desarrollados durante esta actividad.

Documentación: Después que los requisitos han sido recolectados, hay que analizarlos a detalle y documentarlos en una especificación de requisitos. El resultado de la especificación de requisitos y de cualquier especificación de requisitos de componentes hardware/software derivado sirve como registro de convenio con el cliente y compromiso con el proveedor. Estas especificaciones son rastreadas utilizando una matriz de trazabilidad de requerimientos y son sujetos a verificación y gestión de cambio a través del ciclo de vida del producto.

Verificación: Una vez que la especificación de requisitos ha sido desarrollada, los requisitos son verificados. La verificación de requisitos es un proceso para asegurar que la especificación de requisito del producto es una representación exacta de las necesidades del cliente. Este proceso también asegura que los requisitos sean trazados y verificados a través de varias fases del ciclo de vida; particularmente en el diseño, implementación y pruebas. Además, todos estos requerimientos deben ser trazados al diseño, implementación y pruebas para asegurarse que los requerimientos han sido satisfechos.

Gestión de Cambios: Gestión de cambios es un proceso formal para identificar, evaluar, trazar y reportar cambios propuestos y aprobados a la especificación del producto. Como el proyecto va evolucionando, los requerimientos pueden cambiar o expandirse para ajustar algunas modificaciones en el alcance o diseño del proyecto. Un proceso de gestión de cambios proporciona un rastreo completo y preciso de todos los cambios que son pertinentes al proyecto. El proceso del ciclo de vida de la Gestión de Requisitos, debe ser flexible y adaptable para reunir las necesidades del proyecto. Las características del alcance e implementación del proceso del ciclo de vida de la Gestión de Requisitos en un proyecto, variará dependiendo de algunos factores claves.

Tamaño y complejidad del proyecto

Experiencia del personal del proyecto

Experiencia de los clientes del proyecto

Dominio de la aplicación

El propósito y uso de esta aplicación

Las Herramientas de Gestión de Requisitos

El uso de herramientas de la gestión de requisitos es alentado para mejorar tanto la productividad como la calidad en el desarrollo de un proyecto software. Existen varias herramientas tanto hechas en casa como en el mercado que auxilian a las tareas de gestión.

Rational RequisitePro, es una herramienta centrada en documentos, que almacena los requisitos asociándolos a documentos (aunque también permite guardarlos directamente en la base de datos), mientras que las otras herramientas están orientadas a requisitos.

Se auxilia especialmente en el control de cambio de requisitos, con trazabilidad para especificaciones de software y pruebas. La herramienta permite el uso de Oracle sobre Unix o Windows y también soporta SQL Server sobre Windows. Beneficios de RequisitePro

Permite el trabajo en equipo por medio de un repositorio compartido de información.

Permite la clasificación de requerimientos, en base a las necesidades de cada empresa.

Define atributos para todos los tipos de requerimientos especificados.

Ayuda a manipular el alcance del proyecto mediante la asignación de prioridad de desarrollo a cada uno de los requerimientos planteados.

Permite características avanzadas de rastreo, por medio de matrices, que permiten visualizar las dependencias entre requerimientos dentro de un proyecto o en diferentes proyectos.

Administración de cambios mediante el rastreo y la visualización histórica de los cambios efectuados al requerimiento, cuándo y quién los realizó.

Interactúa con los demás productos Rational para el ciclo de vida, así como con herramientas de Microsoft Office.

Ayuda a determinar en forma automatizada cuántos requerimientos tiene el proyecto.

Ayuda a determinar responsables y actores en cada uno de los requerimientos.

RequisitePro, permite organizar los requerimientos, establecer y mantener relaciones padre/hijo entre ellos.

El uso de una herramienta de gestión de requisitos proporciona al proyecto:

Ahorro en costes de especificación y de desarrollo minimizando el impacto de errores.

Mejora la calidad mediante un adecuado análisis y gestión de los requisitos.

Reduce las no-conformidades del sistema.

Permite controlar la especificación.

Permite administrar más fácilmente la especificación.

Ayuda a cumplir con estándares de calidad.

Permite centralizar toda la información del problema.

Proporciona una trazabilidad completa de la especificación, etc.

Otras Herramientas de la Gestión de Requisitos en el Mercado

Las herramientas seleccionadas proporcionan casi todas las necesidades básicas exigibles. Además, estas herramientas están ampliamente difundidas y son muy reconocidas. Todas las herramientas asumen que la estructura de los requisitos es jerárquica, de forma que un requisito puede estar formado o tener asociados otros requisitos de nivel inferior, y la mayoría permite extraer párrafos de ficheros generados por procesadores de texto comerciales y convertirlos en requisitos. Otras de las características comunes a la mayor parte de las herramientas es la posibilidad de realizar consultas sobre los requisitos en función de determinados valores de sus atributos. Estas herramientas son: IRqA 3.0, CaliberRM y DOORS IRqA 3.0 es una herramienta de ingeniería de requisitos especialmente diseñada para soportar el proceso completo de ingeniería de requisitos. En IRqA el ciclo de especificación completo incluye la captura de requisitos, análisis, especificación de sistema, validación y la organización de requisitos es soportada por modelos estándares. ( Lan A, 1994).

CaliberRM es para sistemas grandes y complejos y proporciona una base de datos de requisitos con trazabilidad. Se ve a los requisitos como parte del proceso al igual de gestión de la calidad del software, las pruebas (testing) y el trazado de defectos (defect tracking). Caliber está basado en internet y maneja referencia de documentos, responsabilidad de usuario, trazabilidad, prioridad y estado entre otras características.

DOORS a diferencia del resto de las herramientas, considera los requisitos como objetos y los documentos como módulos. Tiene una orientación basada en objetos, frente a RequisitePro y Caliber-RM, que manejan solamente requisitos y sus atributos. Es una herramienta para organizaciones grandes que necesitan controlar complejos conjuntos de usuarios y requisitos de sistemas con una completa trazabilidad. Proporciona buena visualización de tales documentos como jerárquicas, y su lenguaje de extensión permite una gran variedad de soporte de herramientas a ser construidas.

Conclusiones

Con este documento dejamos claro la importancia que tiene el conocimiento de la Ingeniería de Requerimiento y con ella la Gestión de Requisitos .Sin dejar de mencionar que el resultado satisfactorio depende de una intensa comunicación entre clientes y analistas de requerimientos. La Ingeniería se encarga de establecer y mantener un acuerdo en qué el sistema debe hacer, demás proporciona al equipo de desarrollo un entendimiento de los requisitos, hasta definir los límites del sistema.

Referencias Bibliografías

(Anaya, 2002) Anaya, V., Letelier, P., SmarTTrace: Una Herramienta para Trazabilidad de Requisitos en Proyectos basados en UML, Proceedings of the V Workshop on Requirements Engineering, pp. 210-224, Valencia, España, Noviembre 2002.

(Booch, 2000) Booch, Grady Rombaugh ,james y Jacobson, Ivar (2002.El lenguaje Unificado de modelado España: Adyson Wesley) 432 p.

(Booch, 2002) Grady Booch. Growing the UML. Software and System Modeling, (2002).

(Charette, 1989) Charette, R. N.: Software Engineering Risk Analysis and Management, McGraw–Hill/Intertext, 1989.

(Finkelstein, 2000) Anthony Finkelstein & Wolfgang Emmerich (University College London, Dept. Computer Science.)Paper "The Future of Requirement Management Tools"

(Lan A., 1994) Requirements Engineering Tool Vendors and Freeware Suppliers, 1994.

(Loucopoulos, 1995) Karakostas, V. (1995); System Requirements Engineering McGraw-Hill, 1995. , Loucopoulos.

(Pressman, 2002) Pressman, Roger S.: Ingeniería de Software. Un enfoque práctico. Quinta edición. McGraw-Hill. Madrid. 2002.

(Ramesh, 2001) B. Ramesh and M. Jarke. Toward Reference Models for Requirements Traceability.IEEE Transactions on Software Engineering, Vol. 27, No. 1, pp.58-93, January 2001.

(Richard , 1997) IEEE Software Requirement Engineering, Second Edition. Thayer y Merlin Dorfman, IEEE Computing Society, New York, NY. 1997.

(Sommerville, 1997) Requerimentes Engineering: A Good Practice Guide. Johm Wiley and Sons, 1997.

Autor:

Msc. Dayra Iris Hechavarría Rodríguez

La Habana, 2012