Elements of a Requirements Management Tool to Improve Software

RACCIS, 2(1), 37-42, 2012.
Revista Antioqueña de las
Ciencias Computacionales y la Ingeniería de Software
ISSN: 2248-7441
www.fundacioniai.org/raccis/index.htm
raccis@fundacioniai.org
Elements of a Requirements Management Tool to Improve Software
Development
Elementos de una Herramienta de Gestión de Requisitos para Mejorar el
Desarrollo de Software
Rogeiro Silva1, Anaima Dasilva2
Universidad de Porto
1 rsilva(AT)up.pt, 2 adasilva(AT)up.pt
INFORMACIÓN DEL ARTÍCULO
Tipo de artículo: Reflexión.
Historia del artículo
Recibido: 16-03-2012
Correcciones: 20-06-2012
Aceptado: 21-06-2012
Categories and Subject Descriptors
D.2.0 [Software Engineering]:
General – Standards.
General Terms
Software Engineering, Requirements
Engineering.
Keywords
Requirements
management
Engineering,
Engineering.
tool,
management,
Software
Requirements
Palabras clave
Gestión de requisitos, herramienta
de gestión, Ingeniería de Software,
Ingeniería de Requisitos.
ABSTRACT
Developing quality software is a challenge that requires professional to use techniques and
methodologies appropriate, at the same time good software engineering practices. In the
industry, the challenge is to hire experienced professionals, especially having to do with
requirements management and tools to do it. To help overcome these problems, this article
presents a way to select a management tool that incorporates best practices, in order to
investigate the elements that ensure that is suitable for specific needs. To achieve this, was
conducted a comparative study among the different tools available that have these
elements. The results show that, until now, there is not a specific tool that contains all,
therefore, has been determined that is essential to develop one that professional can use for
developing quality software.
RESUMEN
Desarrollar software de calidad es un desafío que les exige a los profesionales emplear
técnicas y metodologías apropiadas, al mismo tiempo que buenas prácticas de Ingeniería de
Software. En la industria, el desafío consiste en poder contratar profesionales con
experiencia, especialmente en lo que tiene que ver con la gestión de requisitos y con las
herramientas para hacerlo. Con el fin de ayudar a superar estos problemas, en este artículo
se presenta una forma para seleccionar una herramienta de gestión que incorpore las
mejores prácticas. El objetivo investigar los elementos que garanticen que es adecuada para
unas necesidades específicas. Para lograrlo, se llevó a cabo un estudio comparativo entre las
diferentes herramientas disponibles que tuvieran esos elementos. Los resultados muestran
que, hasta el momento, no existe una herramienta específica que los contenga a todos, por lo
tanto, se determina que es esencial desarrollar una que puedan utilizar los profesionales
para desarrollar software de calidad.
1. INTRODUCCIÓN
En la última década, los productos de la Ingeniería de
Software han tenido un impacto notable en la sociedad y
en la economía global. Cada año, sólo en los Estados
Unidos, se invierte alrededor de USD 275 billones en
cerca de 200.000 proyectos de aplicaciones con un
componente importante de software [1]. Esta industria
genera aproximadamente 1/6 de los ingresos del PIB en
este país. Los productos que tienen un gran componente
software se encuentran por todas partes, como en los
computadores, el correo electrónico, la red mundial, los
teléfonos celulares, las lavadoras y los microondas, entre
otros muchos y se prevé que este impacto seguirá
aumentando en las próximas décadas [2]. Sin embargo, la
mayoría de problemas que enfrenta la industria hoy en
día son los mismos que se experimentaba en 1968,
cuando se acuñó por primera vez el término "Ingeniería
de Software", en la conferencia de la OTAN [3].
© 2012 IAI. All rights reserved.
Muchos proyectos software han fracasado o han sido
cancelados debido a costos excesivos, a retrasos en el
programa y a clientes y partes interesadas insatisfechos.
Los datos del Chaos Report of the Standish Group [4]
muestran que, en promedio, más del 23% de ellos fallan y
más del 49% son desafíos que sobrepasan el presupuesto.
Este fenómeno ha estado latente en la industria del
software por más de cuatro décadas y se ha señalado a la
práctica deficiente de la Ingeniería de Requisitos —IR—
como uno de los motivos principales que contribuyen a
esta situación [5, 6].
Como un proceso de la Ingeniería de Software, la IR juega
un papel vital para asegurar el éxito total de los
proyectos. La gestión de requisitos es una parte de la IR
que se concentra en el manejo de la administración del
cambio, la trazabilidad, el control de versiones y el
seguimiento al estado de los mismos pero, actualmente,
37
esta actividad no se lleva a cabo adecuadamente durante
el desarrollo. Tener práctica en esta gestión durante un
proyecto de desarrollo de software es el primer paso
hacia el aumento de la calidad total del producto. Los
requisitos son atributos que definen características como
capacidad, rendimiento y calidad de un sistema y, para
garantizar la calidad de su especificación, es necesario
hacer un fuerte énfasis para aplicar métodos ingenieriles
en los procesos involucrados, incluyendo la actividad de
la gestión de requisitos mediante el uso de diversas
técnicas y metodologías y de buenas prácticas [7-10].
Dado que los requisitos tienden a cambiar durante el
desarrollo del sistema, estos cambios se deben manejar
adecuadamente.
Por lo general, los procesos de IR implican gran cantidad
de datos y de requisitos inestables, por lo tanto, se han
desarrollado herramientas para ayudar a gestionarlos
[11] y para apoyar la administración de sus bases de
datos y cambios. También recogen las necesidades del
sistema en una base de datos o repositorio y ofrecen una
gama de utilidades para acceder a esa información. En el
mercado existen varias herramientas de gestión de
requisitos que van desde las sencillas, económicas y
fáciles de utilizar hasta las complejas, sofisticadas y
costosas. Sin embargo, la pregunta que surge es, ¿son
adecuadas y apropiadas para las industria del software y
las exigencias actuales? Porque el desafío aquí es
encontrar profesionales con experiencia en Ingeniería de
Software, especialmente en lo que tiene que ver con la
gestión de requisitos y con esas herramientas [12].
Además, éstas no son muy utilizadas en el desarrollo de
proyectos [13]. Si no hay mejoría significativa y progreso
para superar estos problemas, este fenómeno se
convertirá en uno de los mayores retos de la Ingeniería de
Software en la industria.
Una de las principales tareas, a fin de superar esos
problemas, consiste en encontrar una solución factible
para llevar a cabo y poner en práctica la gestión de
requisitos durante el desarrollo de proyectos software.
Por lo tanto, este artículo intenta recomendar una
herramienta que incorpore las mejores prácticas a esta
actividad con la meta de lograr un mejor enfoque para la
práctica. Por lo tanto, este trabajo tiene como objetivo
investigar las características o elementos que debe tener
una herramienta de gestión de requisitos para llegar a ser
apta para la industria. La primera parte del contenido
presenta las revisiones respectivas; a continuación se
definen los elementos de gestión de requisitos de la
herramienta desde las perspectivas general y específica;
posteriormente, se presenta un estudio comparativo y
finalmente se detallan las conclusiones de la
investigación.
2. COMENTARIOS
Tradicionalmente, los equipos de proyecto documentan
los requisitos en un programa estructurado de
especificación escrito en lenguaje natural [14, 15], sin
embargo,
el
documento
resultante
presenta
inconvenientes como [14]:
 Es difícil de actualizar y sincronizar.
 Se dificulta informar los cambios porque la
comunicación entre los miembros del equipo es un
proceso manual.
 No es fácil almacenar la información complementaria,
especialmente atributos acerca de los requisitos.
 Es difícil definir los vínculos entre los requisitos
funcionales y otros elementos del sistema.
 El seguimiento al estado de los requisitos es muy
difícil e involucra procesos manuales.
 Cuando los miembros del equipo están separados
geográficamente no les es fácil modificar los
requisitos.
 No se deja espacio adecuado para almacenar los que
fueron rechazados y los que se eliminaron de la línea
base.
Se puede concluir entonces que existen limitaciones en el
documento, por lo que una herramienta de gestión de
requisitos, que almacene información en una base de
datos multi-usuario, proporcionaría una solución robusta
a estos problemas. Esta solución podría beneficiar tanto a
los grandes proyectos como a los pequeños. Para manejar
los requisitos en uno pequeño, el repositorio central
podrían ser aplicaciones de hoja de cálculo o bases de
datos sencillas. Las bases de datos relacionales se utilizan
para almacenar y administrar gran número de registros,
que tienen la misma estructura y unas conexiones
mínimas entre ellos y muchas herramientas de gestión de
requisitos se basan en ellas. De acuerdo con Sommerville
y Sawyer [9], es posible mantener muchos vínculos con
una base de datos relacional, pero esto no es suficiente
porque requieren operaciones en tablas individuales
diferentes. Además, que las bases de datos orientadas a
objetos son estructuralmente más adecuadas para la
gestión, porque permiten mantener diferentes tipos de
información en diferentes objetos y la forma como
gestionan los vínculos entre ellos es bastante sencilla.
Por otra parte, los proyectos grandes podrían emplear las
herramientas de gestión comerciales disponibles, debido
a que ofrecen muchas características para que los
usuarios importen los requisitos desde el documento
origen, definan los valores de los atributos, filtren y
muestren el contenido de bases de datos, exporten
requisitos en varios formatos, definan los enlaces de
trazabilidad y conecten los requisitos con los elementos
almacenados en otras herramientas de desarrollo [14]. La
razón principal por la que todos los proyectos software
deben utilizar una herramienta de gestión se debe a que
proporciona asistencia automatizada que ayuda a
gestionarlos, a medida que avanza el desarrollo. También
porque ayuda a realizar las siguientes tareas [14]:
 Gestión de versiones y cambios. La gestión de requisitos
implica organizar y almacenar la información
pertinente, de modo que las herramientas ayudan a
manejar la historia de los cambios para que, si es
necesario, se puedan modificar los iniciales así como
mantener versiones actualizadas de los mismos.
38
 Almacenar los atributos de los requisitos. En un
repositorio central se debe almacenar variada
información de los requisitos lo mismo que sus
atributos. Cada miembro del equipo debe ser capaz de
verla y estar autorizado para actualizar sus valores.
Por lo general, las herramientas de gestión generan
algunos atributos definidos por el sistema, como la
fecha de creación y el número de versión y también les
permiten a los usuarios definir atributos adicionales,
como autor, persona responsable, origen, razón de ser,
número de versión, estado, prioridad, costo, nivel de
dificultad, estabilidad y riesgo.
 Facilitan el análisis de impacto. La mayoría de estas
herramientas permite el seguimiento a los requisitos
mediante la definición de enlaces entre los diferentes
tipos, entre requisitos en diferentes subsistemas y
entre requisitos individuales y componentes
relacionados con el sistema. Estos enlaces ayudan a
analizar el impacto de un cambio en un requisito
específico, identificando otros elementos del sistema
que se puedan afectar. También proporciona la
capacidad de seguimiento para que cada requisito
funcional regrese a su origen.
 Seguimiento al estado de los requisitos. Las
herramientas de gestión de requisitos tienen una base
de datos central para almacenar todos los requisitos.
El uso de herramientas de gestión es esencial, teniendo en
cuenta el tamaño y la complejidad de los esfuerzos de
desarrollo [16]. Sin embargo, un estudio [12] en la
industria del software reveló que no existe un enfoque
adecuado de gestión de requisitos e identificó la
necesidad de que los ingenieros de software utilicen las
mejores prácticas en esa gestión. Por lo tanto, es
necesario difundir y promover las herramientas de
gestión de requisitos en la industria de software.
Existen plataformas comerciales para la gestión de
requisitos, como DOORS [17] y Rational Requisite Pro
[18], que utilizan diferentes conceptos y que tienen
diferentes capacidades y grados de madurez con respecto
a su aplicabilidad en proyectos de Ingeniería de Software
[16]. De acuerdo con Zainol y Mansoor [13], sólo el 12.2%
de los 74 encuestados utilizan herramientas de gestión de
requisitos, de los cuales el 10.8%, utiliza Rational y el
1.4% otro tipo de herramientas. Casi todos los
encuestados respondieron nunca haber utilizado
herramientas de gestión para apoyar sus proyectos de
desarrollo de software. También informan estos autores
que a la industria le hace falta utilizar herramientas
sofisticadas. Como resultado, existe la necesidad de
desarrollar una que sea apropiada, con el fin de garantizar
que sea apta. Para ello, es importante identificar primero
qué elementos necesita y realizar un estudio comparativo
entre las disponibles en el mercado global.
3. ELEMENTOS DE UNA HERRAMIENTA DE GESTIÓN
DE REQUISITOS
Encontrar los elementos que debe poseer una
herramienta de gestión de requisitos se inicia con un
estudio a la literatura. Los requisitos para estas
herramientas se presentan en un par de artículos de
investigación: los dieciséis requisitos para desarrollar
productos colaborativos se introducen en [19] y en [16]
se presenta una serie de requisitos para las herramientas
de gestión en la industria automotriz y de aviación.
Además, la lista detallada de las características de estas
herramientas se introducen en [9] y en [20] se define una
lista de requisitos para las que se utilizan en la IS:
 Mantener la descripción única de identificación de
todos los requisitos.
 Clasificar los requisitos lógicos en grupos definidos
por el usuario.
 Especificar los requisitos con un modelo de
descripción basado en texto y gráficos.
 Definir las asociaciones de trazabilidad entre los
requisitos.
 Verificar las asignaciones de los requisitos de los
usuarios a las especificaciones técnicas del diseño.
 Mantener un registro de auditoría de cambios y de
versiones de archivos de referencia.
 Involucrar un mecanismo para autenticar y aprobar
las solicitudes de cambio.
 Apoyar segura y concurrentemente el trabajo
cooperativo entre los miembros de un equipo de
desarrollo multidisciplinar.
 Soportar los sistemas estándar de técnicas de
modelado y de notaciones.
 Mantener un diccionario de datos completo en un
repositorio compartido de todos los componentes y
requisitos del proyecto.
 Generar reportes predefinidos y ad hoc.
 Generar documentos que cumplan con las plantillas
estándar de la industria.
 Conectarse perfectamente con otras herramientas y
sistemas.
Así, los elementos para herramientas de gestión se
recogen de estudios a la literatura y el mercado. En estos
últimos se utilizó un conjunto de cuestionarios para
recopilar cuáles son los elementos que los ingenieros de
software desean tener. Al combinar la información de
ambos estudios, fue posible definir los principios de la
herramienta. Este criterio preliminar se dividió en
elementos generales y en criterios específicos. Los
generales son características que la herramienta de
software debe tener, mientras que los específicos son
requisitos concretos para ella.
3.1 Elementos generales
Los elementos generales son importantes porque
describen las características que la herramienta debe
lograr para poder adaptarse a las necesidades de la
industria del software.
 Usabilidad,
simplicidad y personalización. La
herramienta debe ser fácil de usar, no requerir mucho
entrenamiento y administración, no debe crear tareas
adicionales y su instalación no debe requerir una
amplia personalización. La usabilidad es una
necesidad obvia para una herramienta de trabajo con
39
soporte colaborativo. Para que las empresas utilicen
las herramientas, éstas no deben crear tareas
adicionales ni complicar el trabajo de desarrollo.
Además, la sencillez, por ejemplo, en entrenamiento y
administración, y la capacidad de operar sin una
personalización extensa son factores importantes,
especialmente para las pequeñas empresas.
 Control de acceso. Debe tener un estricto control de
acceso mediante el que cada participante tenga acceso
adecuado a los datos. Puede estar basado en roles o en
control por proyectos o tareas. El control de acceso es
importante en entornos de desarrollo colaborativo
porque, por ejemplo, las personas externas no deben
poder ver toda la información propiedad de los
sistemas de datos de la empresa. Por otra parte, no es
necesario, por ejemplo, que los desarrolladores vean
el presupuesto del proyecto, ni que las personas de
aseguramiento de la calidad puedan leer los requisitos
porque su edición no es posible para ellos. La
herramienta debe apoyar la restricción de acceso a los
grupos de usuarios a cierta información y, en general,
proteger los datos y controlar el acceso mediante
contraseñas.
 Confección y adaptabilidad. Debe ser adaptable y
 Clasificación y visualización de requisitos. Clasificar los
requisitos en grupos lógicos definidos por los
usuarios. Es la capacidad de clasificarlos ofreciendo
diferentes puntos de vista de los mismos datos a
diferentes usuarios. Un punto de vista ofrece la
posibilidad de ver y cambiar libremente una colección
definida de partes de los datos de varios proyectos, en
una representación de libre configuración.
 Línea base de requisitos. La herramienta debe ser
capaz de mantener y gestionar los requisitos
funcionales y no funcionales que el equipo de
desarrollo se ha comprometido a implementar en una
versión específica.
 Control de cambios. La herramienta debe: (1) ofrecer
una posibilidad de tramitar las solicitudes formales de
cambios, (2) rastrear y mantener en la base de datos
todos los cambios en los requisitos y (3) actualizar el
documento de requisitos. Esta es la característica más
importante porque se necesita que el equipo de
trabajo pueda conocer la historia de los cambios y
tener acceso al registro de quién, qué, cuándo, dónde,
por qué y cómo se hizo. El control de cambios permite
realizar un seguimiento al estado de todos los
propuestos y ayuda a asegurar que no se han perdido
o pasado por alto.
extensible a las necesidades de la organización o
proyecto. La confección y la adaptabilidad son
prácticas cuando la empresa tiene muchos proyectos
de diferentes tamaños y utiliza muchas herramientas
diferentes con la de gestión de requisitos.
 Control de versiones. Debe identificar: (1) las versiones
 Licencia libre y disponibilidad de versión completa.
 Rastreo de estado. Es decir, tiene que: (1) definir los
Debe ser de licencia libre que le permita al usuario
utilizarla sin limitaciones en la versión completa. La
licencia libre y la disponibilidad de versión completa
es una característica importante que podría promover
que el usuario la utilice, porque es gratuita y está
disponible para uso total.
 Centrada en la base de datos. La herramienta debe
estar centrada en la base de datos y también apoyar la
gestión de documentos. Centrada en la base de datos
significa que la herramienta se concentra en mantener
toda la información en una base de datos, sin embargo,
también debe ser capaz de manejar y generar los
documentos. Es importante que la herramienta
garantice que la información contenida en la base de
datos esté reflejada en los documentos.
3.2 Elementos específicos
 Identificación de requisitos. El identificador de
requisitos, que es un número individual, es obligatorio.
Esto significa la capacidad de identificar todos los
requisitos individuales para distinguirlos fácilmente
de los demás. Puede hacerse con números de
identificación y con la ayuda de atributos. Además, la
herramienta debe soportar la priorización requisitos,
porque algunos son más importantes que otros y se
deben implementar primero.
del documento de requisitos y (2) las versiones de los
requisitos individuales.
posibles estados de los requisitos, (2) registrar el
estado de cada uno y (3) informar sobre el estado de la
distribución de todos ellos. Esta capacidad consiste en
rastrear el estado de los requisitos establecidos en la
línea base. Rastrear requisitos consiste en manejar los
vínculos lógicos entre los requisitos individuales y
otros productos del proyecto.
 Generar especificaciones de casos de uso. Debe ser
capaz de generar documentos de especificación de
casos de uso y de utilizar definiciones de documentos
predefinidos para generar documentos con los datos
de la base de datos. Esto no es práctico para imprimir
todo el contenido de la base de datos en un
documento, sólo para los requisitos apropiados. La
herramienta permitirá generar especificaciones de
casos de uso que sigan el estándar industrial.
 Generar listas de requisitos. Debe generar una lista de
requisitos como documentos de apoyo, es decir, una
capacidad para generar los requisitos que se acordó
implementar en la línea base actual. Este documento
describe los datos de los requisitos con su respectivo
número de versión.
 Relacionar los requisitos con los elementos del sistema.
Debe mantener una relación constante entre los
requisitos funcionales, los componentes de diseño y
los módulos de código que se ocupan de cada
40
requisito, así como de los casos de prueba que
verifican su correcta implementación. Los elementos
del sistema se asignan a cada requisito después de que
se ha completado el trabajo y de esta manera registrar
los requisitos con sus elementos del sistema
particulares completados.
 Procedimiento de autenticación. La herramienta
deberá permitir el acceso de personas diferentes con
diferentes roles y restringir las funciones de los
diferentes usuarios.
 Definición del proyecto. La herramienta deberá
permitir que se defina cada proyecto con el objetivo de
mantener los requisitos separados de cada uno. Es la
capacidad de mantener el proceso y la identificación
de cada proyecto. Esto es importante para asegurar
que todos los requisitos se mantienen sobre la base de
la identificación del proyecto.
 Administrar usuarios. La herramienta debe ser capaz
de crear nombres y contraseñas de usuario con
diferentes roles. Esto es importante para que cada
usuario pueda acceder y utilizar la herramienta de
manera eficiente y para asegurar la fiabilidad y el
rendimiento de la misma.
4. ESTUDIO COMPARATIVO
En los últimos años se ha incrementado la venta de
herramientas de gestión de requisitos [21] y en el
mercado se ofrece gran variedad. Se encuentran desde las
más complicadas y sofisticadas hasta las más sencillas y
desde las más costosas hasta las económicas y gratuitas.
Muchas ofrecen soporte a las actividades de gestión de
requisitos [20], aunque no todas están centradas
exclusivamente en estas actividades. Las disponibles en el
mercado las desarrollan proveedores generalmente con el
objetivo de gestionar todos los requisitos, sin embargo,
cada empresa tiene su propia cultura y política hacia la
gestión. Por lo tanto, con base en los elementos
previamente definidos se realizó un estudio comparativo
con el objetivo de encontrar la herramienta más adecuada
para llevar a cabo la gestión de requisitos.
Para este estudio se seleccionó un conjunto de
herramientas disponibles en el mercado y en función de
cómo los proveedores prometen soportar proyectos de
Ingeniería de Software de diversos tamaños. El número
de herramientas encontrado es bastante amplio, pero
para este estudio no se incluyeron todas. Las
características que debían cumplir fueron: ser bien
conocida y ampliamente utilizada en la industria. Las
herramientas seleccionadas fueron:
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
Borland CaliberRM
Insoft Prosareq
IBM Rational RequisitePro
ViewSet PACE
Igatech Systems RDT
SpeeDEV RM
RBC RMTrack
Telelogic DOORS
Serena RTM
Teledyne Brown XTie-RT
Todas estas herramientas se analizaron de acuerdo con
los elementos definidos para criterios generales y
específicos. La Tabla 1 ilustra la síntesis de los resultados.
El criterio de usabilidad, simplicidad y personalización se
deja en blanco porque la evaluación de la usabilidad exige
una prueba de uso con todas ellas, algo que no está entre
los objetivos trazados.
Tabla 1
Resultados del Estudio Preliminar - Elementos Generales
Herramientas
1
2
3
4
5
6
7
Usabilidad, simplicidad y personalización
-------Control de acceso
SI
SI
SI
SI
SI
SI
SI
Confección y adaptabilidad
SI
SI
?
?
NO
?
SI
Licencia libre y disponibilidad de versión completa
NO NO
NO
NO
NO
NO
NO
Centrada en la base de datos
SI
?
SI
NO
SI
NO
SI
SI: Soportado; NO: No soportado; PS: Parcialmente soportado; ?: No conocido
Elementos generales
Como se observa en los datos de la Tabla 1, el control de
acceso es una característica bien soportada por cada
herramienta. Por otro lado, varias de ellas poseen la
característica de confección y adaptabilidad y algunas la
de centrada en la base de datos. Sin embargo, ninguna
proporciona licencias libres con disponibilidad completa.
De la Tabla 2 se puede concluir que casi todas las
herramientas soportan plenamente la identificación, la
clasificación y la visualización, el control de línea base, la
trazabilidad, el control de versiones, el seguimiento y el
cambio de requisitos; mientras que algunas soportan
parcialmente la generación de casos de uso y la lista de
requisitos, la relación con los elementos del sistema, el
8
-SI
?
NO
?
9
-SI
SI
NO
SI
10
-SI
SI
NO
SI
procedimiento de autenticación, la definición del proyecto
y la creación de usuarios. Como conclusión, no se
encuentra una herramienta que posea todos los
elementos generales y que sea totalmente compatible con
los específicos. Por lo tanto, ninguna es adecuada para
ayudarles a los profesionales de software en el desarrollo
de productos de calidad.
En este artículo, usabilidad, simplicidad y personalización
se consideran elementos difíciles de evaluar sin aplicar
pruebas que, debido a la falta de tiempo y recursos, no se
aplicaron en esta investigación. Hay que hacer notar que
estos resultados no son exhaustivos, son sólo indicativos,
porque los datos de evaluación se recopilaron desde las
41
páginas web de cada empresa proveedora y de otros
reportes de evaluación disponibles. Sin embargo, los
resultados ofrecen un nivel aceptable de revisión a las
herramientas que soportan actualmente la gestión de
requisitos.
TABLA 2
Resultados del Estudio Preliminar - Elementos Específicos
Elementos específicos
Identificación de requisitos
Clasificación y visualización de requisitos
Línea base de requisitos
Control de cambios
Control de versiones
Rastreo de estado
Generar especificación de casos de uso
Generar listas de requisitos
Relacionar los requisitos con los elementos del sistema
Procedimiento de autenticación
Definición del proyecto
Crear usuarios
1
SI
SI
SI
SI
SI
SI
SI
SI
SI
SI
SI
SI
5. CONCLUSIONES
Como proceso clave de la Ingeniería de Software, la
Ingeniería de Requisitos juega un papel crucial en todo el
ciclo de vida del producto. Varias investigaciones han
demostrado que los fracasos de los proyectos software
suelen estar relacionados con una pobre especificación de
requisitos y que, cuando son bien definidos, se
incrementa la probabilidad de que el proyecto tenga éxito.
Sin embargo, no es posible desarrollar requisitos de
calidad sino se aplican buenas prácticas de gestión.
Debido a que la Ingeniería de Requisitos es el punto de
partida de la Ingeniería de Software y a que las últimas
fases del desarrollo dependen en gran medida de la
calidad de los requisitos, es necesario prestar mucha
atención a la automatización del proceso de gestión. Es
importante tener una herramienta que soporte y facilite
una gestión eficaz de los requisitos a través de todo el
ciclo de vida del producto.
En este artículo se definió un conjunto de elementos para
analizar las herramientas de gestión de requisitos. Estos
elementos, generales y específicos, se consideran como
criterios en el estudio comparativo con el fin de realizar
una inspección a las herramientas disponibles. Los
resultados concluyen que ninguna de las herramientas de
gestión evaluadas posee todos los elementos, por lo tanto,
es conveniente realizar un proyecto que tenga como
objetivo desarrollar una nueva para satisfacer las
necesidades aquí expresadas.
2
SI
SI
SI
SI
SI
SI
PS
PS
NO
SI
SI
SI
[6]
[7]
[8]
[9]
[10]
[11]
[12]
[13]
[14]
[15]
[16]
6. REFERENCIAS
[1]
[2]
[3]
[4]
[5]
Standish Group. 1999. Chaos: A Recipe for Success. The
Standish Group International, Inc.
Serna, M. E. 2009. La ingeniería de sistemas y su evolución
hacia la arquitectura de sistemas. Lámpsakos, 2, 96-105.
Naur, P. & Randell, B. 1969. Software Engineering. Science
Committee NATO.
Standish Group. 2001. Extreme Chaos. The Standish Group
International, Inc.
Stephen, B. 1996. FAA Shifts Focus to Sealed-Back DSR.
IEEE Software, March, 110.
[17]
[18]
[19]
[20]
[21]
3
SI
SI
SI
SI
SI
SI
PS
PS
?
SI
SI
SI
4
SI
SI
PS
SI
SI
SI
PS
PS
SI
PS
NO
NO
Herramientas
5
6
7
SI
SI
SI
SI
SI
SI
SI
SI
SI
SI
SI
SI
SI
SI
SI
SI
NO
SI
SI
SI
NO
SI
SI
NO
SI
NO
SI
SI
NO
SI
NO
SI
SI
SI
NO
SI
8
SI
SI
SI
SI
SI
SI
?
?
?
?
?
?
9
SI
SI
SI
SI
SI
SI
PS
PS
SI
SI
SI
SI
10
SI
SI
SI
SI
SI
SI
?
?
SI
SI
?
SI
Brooks, F. 1987. No Silver Bullet – Essence and Accident in
Software Engineering. IEEE Computer, 20(4), 10-19.
Emam, K. E. & Birk, A. 2000. Validating the ISO/IEC 15504
Measure of Software Requirements Analysis Process
Capability. IEEE Transactions on Software Engineering,
26(6), 541-566.
Young, R. R. 2004. The Requirements Engineering
Handbook. Artech House.
Sommerville, I. & Sawyer, P. 1997. Requirements
Engineering: A Good Practice Guide. Wiley.
Damian, D. et al. 2003. An Industrial Case Study of
Immediate Benefits of Requirements Engineering Process
Improvement at the Australian Center for Unisys Software.
Journal of Empirical Software Engineering, 9(1-2), 45-75.
Kotonya, G & Sommerville, I. 1998. Requirements
Engineering: Processes and Techniques. Wiley.
Zainol, A. & Mansoor, S. 2008. Investigation into
Requirements Management Practices in the Malaysian
Software Industry. Proceedings of 2008 International
Conference on Computer Science and Software
Engineering, 2, 292-295. Wuhan, China.
Zainol, A. & Mansoor, S. 2009. A Survey of Software
Engineering Practice in the Software Industry. Proceedings
of IASTED International Conference on Software
Engineering. Innsbruck, Austria.
Wiegers, K. E. 2003. Software requirements. Microsoft
Press.
Firesmith, D. G. 2007. Common Requirements Problems,
Their Negative Consequences, and the Industry Best
Practices to Help Solve Them. Journal of Object
Technology, 6(1), 17-33.
Hoffmann, M. et al. 2004. Requirements for Requirements
Management Tools. Proceedings of 12th IEEE International
Requirements Engineering Conference RE´04, 301-308.
Paris, France.
IBM. Telelogic DOORS. Online. [Jan. 2012].
IBM. Rational RequisitePro. Online. [Jan. 2012].
Rönnbäck, A. Ö. 2002. Interorganizational IT Support for
Collaborative Product Development. Dissertation from the
International Graduate School of Management and
Industrial Engineering. IMIE, 59, Doctoral Dissertation.
Lang, M. & Dunggan, J. 2001. A Tool to Support
Collaborative Software Requirements Management.
Requirements Engineering, 6(3), 161-172.
Standish Group International. 1998. Special COMPASS
report on requirements management tool.
42