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