Ingeniera de Requisitos en los M

etodos de Desarrollo

Agiles
Rafael Ayerbe Bernal
Trabajo para la asignatura Ingeniera de Requisitos del curso de doctorado 2006/2007
Departamento de Lenguajes y Sistemas Inform
aticos
Universidad de Sevilla. Espa
na

4 de junio de 2007

Resumen

rrollo, planeando el desarrollo en ciclos cortos de una

duracion de semanas. Esto permite al usuario probar
El desarrollo
agil de software es un termino general pa- el software durante el desarrollo sin tener que espera una aproximaci
on que es implementada por distintos rar al final. El entorno colaborativo que propugnan
metodos de desarrollo software, tales como XP, Scrum y los m
etodos agiles facilita la depuracion rapida de reDSDM. La parte com
un que comparten los metodos a
giles quisitos.
es que dan soporte a los valores incluidos en el ManifiesEn comparacion con los procesos tradicionales,
[1]. El desarrollo de software
to Agil
agil evoluciona como seg
un [4], el desarrollo agil se centra menos en la dorespuesta a las deficiencias del desarrollo en cascada ba- cumentaci
on y esta mas orientado al codigo. Esto, sin
sado en la documentaci
on. En estos metodos siempre se embargo, no es sino una consecuencia de diferencias
habla de captura de requisitos y de documentarlos, lo que m
as profundas entre ambas aproximaciones:
genera una documentaci
on considerable que es difcil de
leer. Para los nuevos metodos
agiles es importante recordar que el principal prop
osito del desarrollo de un proyecto es entregar un sistema software que genere valor al
negocio. Los modelos y los documentos son esencialmente
productos colaterales del desarrollo que no generan valor
directamente. Si vamos a optimizar el flujo de valor en
el desarrollo software, entonces necesitamos pensar seriamente en eliminar procesos innecesarios.

1.

Los metodos agiles son adaptativos mas que predictivos. Con los metodos tradicionales, la mayor
parte del desarrollo software se planifica en detalle para un largo periodo de tiempo. Esto funciona bien si no hay muchos cambios, y si el equipo
de desarrollo comprende bien el dominio de la
aplicacion y la tecnologa. Los metodos agiles se
desarrollaron para adaptarse y prosperar en entornos de cambio frecuente.

Introducci
on

Los metodos agiles estan orientados a las personas, mas que a los procesos. Confan en la experiencia, competencia y colaboracion de la gente,
mas que en los rigurosos procesos centrados en
los documentos, para producir software de calidad.

El n
ucleo del desarrollo de software
agil es construir caractersticas del sistema increment
almente en
un entorno colaborativo. Los metodos
agiles se construyen alrededor de un principio clave: se continua
aprendiendo acerca del sistema y su entorno durante
el proyecto. Los metodos
agiles evolucionan iterativa
Cuando nos movemos a un ciclo de vida iteratiy conjuntamente los requisitos y el sistema en desa- vo, perdemos las fases tradicionales de los metodos
1

en cascada: an
alisis, dise
no, codificaci
on y pruebas.
Estas actividades ahora se ejecutan en paralelo. Esto tiene un impacto en como se organiza un proyecto
software. Mas que crear equipos de especialistas dedicados a las fases en cascada, tiene m
as sentido formar
un equipo multi-funcional juntando gente del negocio
y gente tecnica, cuya tarea va a ser dar forma e implementar el sistema software juntos.
Cuando el equipo de trabajo trabaja en el analisis y
el desarrollo del sistema en paralelo, se crea una oportunidad de trabajar en los requisitos de una forma
diferente. Especficamente, esto nos permite el poder
considerar otros canales de comunicaci
on para abrir
un dialogo. Los equipos
agiles usan lo conversacion
como metodo preferido para comunicar los requisitos

lles suficientes para ser capaces de estimar el esfuerzo

de implementacion de la historia. Basandose en estas
estimaciones y en el tiempo disponible, los clientes
priorizan las historias que tienen que ser resueltas
en la siguiente iteracion. XP pone enfasis en escribir
las pruebas antes de codificar. Se definen los test de
aceptacion por el cliente y se usan para validar que la
historia de usuario esta desarrollada completamente.
XP se basa en versiones peque
nas y frecuentes. Puede ser comparado con la revision de requisitos y con
la evolucion de un prototipo. la diferencia entre XP
y el prototipo es que XP requiere que sea probado,
que el codigo este bien dise
nado y limpio, mientras
que en los prototipos puede ser desarrollado mas informalmente. Los clientes pueden revisar y probar la
funcionalidad y el dise
no del programa entregado y
discutir las cuestiones que quieren que sean cambia2. La Ingeniera de Requisitos das o anadidas a la siguiente version.
Modelado Agil (AM). La idea basica de AM
en los m
etodos
agiles
es dar a los desarrolladores una gua de como construir modelos que ayuden a resolver los problemas de
En esta secci
on estudiaremos como tratan los re- dise
no. Como XP, AM apunta que los cambios son
quisitos los metodos
agiles m
as comunes.
normales en el desarrollo software. AM no se refiere
Extreme Programming (XP) est
a basado en explcitamente a ninguna tecnica de IR, pero alguna
los principios de simplicidad, comunicaci
on, retroali- de las practicas soportan varias tecnicas de IR (comentacion y valor. Trabaja con el equipo completo, mo las pruebas y las tormentas de ideas). AM resalta
usando practicas simples, con la suficiente retroali- la diferencia entre los modelos informales cuyo u
nimentacion para permitirle saber siempre donde estan. co proposito es ayudar a la comunicacion cara a cara
XP no habla explcitamente de tecnicas de requisi- y los modelos que van a ser mantenidos como docutos en detalle, sino sobre el proceso general de desa- mentacion del sistema. Estos u
ltimos son los que con
rrollo software y lo que se hace durante este proceso. frecuencia se encuentran en las aproximaciones de la
Varias de las pr
acticas de XP (o de las tecnicas usa- IR tradicional.
das en estas pr
acticas) pueden ser comparadas con las
Scrum es un metodo para gestionar el proceso de
tecnicas de la Ingeniera de Requisitos (IR). Especfi- desarrollo del sistema aplicando las ideas de flexibicamente, durante el Planning Game, se usan tecnicas lidad, adaptabilidad y productividad provenientes de
de elicitacion como las entrevistas, las tormentas de la teora de control de procesos industriales. Scrum se
ideas y la priorizaci
on. XP usa las historias de usua- enfoca en como el equipo de trabajo debera trabajar
rios (story cards) para la elicitaci
on.
junto para producir trabajos de calidad en entornos
Antes de que las historias de usuario puedan ser es- cambiantes.
critas, los clientes tienen que pensar acerca de lo que
Las principales tecnicas de Scrum son el backlog
ellos esperan que haga el sistema. Este proceso puede del producto, los sprints y las reuniones diarias. En
ser visto como una tormenta de ideas. Pensar acerca relacion con la IR el backlog juega un papel imporde una funcionalidad especfica lleva a m
as ideas y a tante en Scrum. Todos los requisitos recolectados comas historias de usuario. Cada historia se discute en mo necesarios o u
tiles para el producto se listan en
forma de preguntas abiertas antes de la implementa- el backlog del producto. Contiene una lista priorizacion. Inicialmente, los desarrolladores piden los deta- da de todas las caractersticas, funciones, mejoras y
2

arreglo de errores que deben ser implementados en el

sistema. Este backlog puede compararse con un documento de requisitos imcompleto y cambiante, que
contiene informaci
on necesaria para el desarrollo. En
cada sprint, de unos 30 das aproximadamente, las
tareas mas prioritarias son llevadas desde el backlog
a la lista de tareas que tienen que ser desarrolladas
en dicho sprint (sprint backlog). Durante el sprint, no
se permiten cambios en el backlog, sin embargo hay
flexibilidad absoluta para que cliente modifique el backlog para el siguiente sprint. Al finalizar el sprint se
produce una reuni
on para demostrar la nueva funcionalidad al cliente y solicitar retroalimentacion.
Los conocimientos adquiridos en esta reunion y
el backlog actual sirven para planificar el siguiente
sprint. En la reuni
on de revisi
on del sprint puede ser
comparado con una revisi
on de los requisitos y una
presentacion de un prototipo evolucionado al cliente.
Las metodologas Crystal. Las metodologas
Crystal son una familia de diferentes metodologas
desde las cuales se puede seleccionar la adecuada para un proyecto concreto. Los diferentes miembros de
la familia pueden ser adaptadas para ajustarse a circunstancias variadas. Actualmente no est
an desarrollados todos los miembros de la familia Crystal. Algunas polticas est
andar de todas las metodologas
crystal pueden ser comparadas con las tecnicas de
IR:

y son la base para construir la lista de caractersticas.

Una caracterstica en FDD es funcion con valor para
el cliente. Los elementos de la lista de caractersticas
estan priorizados por el equipo. La lista de caractersticas es revisada por los expertos en el dominio.
FDD propone una reunion semanal de 30 minutos
en la que el estado de las caractersticas se discute y
se escribe un informe sobre la reunion. Este informe
puede ser comparado con un seguimiento de los
requisitos.
El M
etodo de desarrollo de sistemas din
amicos (DSDM) proporciona un marco para el desarrollo rapido de aplicaciones. Las primeras dos fases de
DSDM son el estudio de viabilidad y el estudio del negocio. Durante estas dos fases, los requisitos base son
elicitados. El resto de requisitos se elicitan durante el
proceso de desarrollo. DSDM no propone tecnicas en
concreto. De esta forma, cualquiera de las tecnicas de
IR puede ser usada durante el proceso de desarrollo.
En DSDM, las pruebas estan integradas a traves de
todo el ciclo de vida.
El Desarrollo adaptativo del software (ASD)
proporciona un marco para el desarrollo iterativo de
sistemas grandes y complejos. El metodo fomenta el
desarrollo iterativo e incremental con el uso de prototipos. ASD resalta que las aproximaciones secuenciales en cascada solo funcionan en entornos bien conocidos. Pero como los cambios ocurren frecuentemente
en el desarrollo software, es importante usar un metodo tolerante a cambios. El primer ciclo de un proyecto
ASD suele ser corto, asegurando que el cliente esta involucrado y confirmando la viabilidad del proyecto.
Cada ciclo termina con una revision en grupo enfocada al cliente. Durante las reuniones de revision, se
estudia la aplicacion funcionando. El resultado de las
reuniones son peticiones de cambio documentadas.

Entregas incrementales usando time-boxing

(prototipado, revisiones)
Pruebas de regresi
on automatizadas (pruebas)
Revisiones de usuarios por versi
on (revisiones)
Reuniones de trabajo para el ajuste del producto
y de la metodologa al principio y en mitad de
cada iteraci
on (revisiones)

Desarrollo orientado a caractersticas

3. T
ecnicas de IR en los m
eto(FDD). FDD es un proceso de desarrollo software
dos
agiles
de iteraciones cortas, enfocado a las fases de dise
no y
construccion en vez de cubrir el desarrollo completo.
En la primera fase, se desarrolla el modelo del
En la seccion anterior vimos los principales metodominio completo por expertos en el dominio y por dos agiles y como tratan la IR. Ahora vamos a analidesarrolladores. El modelo consiste en diagramas de zar las principales caractersticas de las tecnicas usaclases, en las que los metodos expresan funcionalidad das en estos metodos.
3

Implicaci
on de los usuarios. Un punto clave en
los metodos agiles es tener a los clientes accesibles y
on-line. Con frecuencia se basan en un representante ideal del cliente, el cual puede responder a todas
las preguntas de los desarrolladores correctamente.
Pero incluso si los requisitos son elicitados en sesiones de grupo (DSDM, Scrum) no se garantiza que
los usuarios con todo el conocimiento necesario esten
presentes. Las tecnicas de IR tradicionales tienen una
idea de los clientes menos idealizada. Estas intentan
capturar todo el conocimiento que sea posible de todas las partes implicadas y resolver los conflictos, suponiendo que los clientes que participan no tienen el
conocimiento global del problema.
Otra diferencia importante es que el los metodos
tradicionales el cliente se implica principalmente en
las primeras fases del desarrollo, mientras que en los
metodos agiles, la implicaci
on ocurre a lo largo de
todo el proceso de desarrollo.
Entrevistas. Ya que la involucraci
on del cliente es
el principal objetivo del desarrollo
agil, las entrevistas
son la principal tecnica de IR. Estas proporcionan un
acceso directo y sin filtros al conocimiento. Todos los
metodos agiles coinciden en que hablar con el cliente
es el mejor modo de conseguir la informacion necesaria y evitar los malos entendidos.
La Priorizaci
on se encuentra en todos los metodos agiles. Una pr
actica com
un es implementar primero las caractersticas m
as prioritarias para entregar lo mas valioso para el negocio. Durante el desarrollo, el conocimiento del proyecto se incrementa y
se a
naden nuevos requisitos. Para mantener las prioridades actualizadas, se reprioriza la lista de caractersticas durante todo el proceso de desarrollo.
Las reuniones de an
alisis (JAD) se usan en varios metodos
agiles. El resultado de las sesiones se documenta y est
a accesible para resolver cuestiones que
surjan en el futuro. La documentaci
on de los requisitos suele ser menos rgida en el contexto de los metodos agiles. Para tener una constante retroalimentacion, las reuniones se suelen mantener durante todo
el proceso de desarrollo, lo que facilita la implicacion
de los clientes y la confianza mutua, en clara lnea
con los principios
agiles.
Modelado. El modelado se usa en los metodos
agiles de una forma distinta a en la IR tradicional.

En los metodos agiles, los modelos tienen el proposito

de comunicar la comprension de peque
nas partes del
sistema a desarrollar. La mayora de estos modelos
son de usar y tirar, y no llegan a formar parte de
la documentacion del proyecto, como sucede en la
ingeniera de software tradicional.
Documentaci
on. En el desarrollo agil de software, el crear una documentacion consistente y completa esta considerado como inviable o, al menos, como no eficiente. Algunos metodos agiles incluyen una
especie de documentacion o recomiendan el uso de
documentos de requisitos (DSDM, Scrum, Crystal),
pero la decision de su extension se deja al equipo de
desarrollo. Ademas la estructura y el contenido de los
documentos no esta detallado.
Validaci
on. Las aproximaciones agiles usan
reuniones de revision y aceptacion para la validacion
de los requisitos. Estas reuniones sirven para comprobar que el proyecto esta dentro de los objetivos y los
plazos, incrementan la confianza de los clientes en el
equipo y resaltan los problemas que puedan aparecer. En las reuniones de revision los clientes pueden
intervenir de distintas formas: probando el sistema,
discutiendo el dise
no, haciendo las pruebas de aceptacion, .... . Dependiendo del metodo y del proyecto
el sistema es puesto en produccion despues de cada
reunion. Este rapido despliegue cambia la economa
del proyecto, proporcionando un retorno de la inversion mas inmediato. Los metodos agiles se pueden
comparar con la evolucion de prototipos: ambos estan
basados en la entrega frecuente de trozos del sistema
para mejorar la comunicacion. La diferencia radica en
el fuerte enfasis en las pruebas en los metodos agiles.
Una aproximacion a la validacion de requisitos se describe en el artculo de Botaschanjan [2]. Esta basada
en la simulacion y en las pruebas automatizadas.
Gesti
on. Desde el punto de vista de la IR, debera
ser posible seguir la pista a los cambios realizados
en los requisitos, dise
nos, o documentacion para ver
por que se ha producido el cambio. Esto crea mas
trabajo y documentacion para garantizar la trazabilidad. Ademas, no ha sido probado que el control
de cambios proporcione beneficios economicos al proyecto. La falta de documentacion puede ser crtica si
los requisitos forman parte de un contrato legal entre
dos organizaciones, usando el contrato como forma
4

de confianza. Sin embargo los metodos

agiles prefieren que la confianza se cree integrando al cliente en
el proceso de desarrollo.
Los metodos
agiles proporcionan una buena base
para la gestion de los requisitos. Todos ellos estan escritos en tarjetas o mantenidos en un backlog o lista
de caractersticas. La diferencia es el nivel de detalle
con que se describen. Normalmente los metodos agiles
omiten los detalles, y esperan a que sean completados en iteraciones posteriores. Se puede denominar
elicitacion de requisitos perezosa (lazy).
Observaci
on, an
alisis social y tormenta de
ideas. Estas tecnicas no se mencionan explcitamente en los metodos de desarrollo
agil pero pueden ser
usadas en cualquiera de ellos.
Requisitos no funcionales. En los metodos agiles, los requisitos no funcionales son difciles de definir y no incluyen un tratamiento explicito de este
tipo de requisitos. Los clientes no piensan en ellos
en las reuniones con el equipo. Normalmente estos
requisitos aparecen durante el desarrollo del sistema.

4.

cumentos de requisitos. Las historias de usuarios son

escritas por los clientes para expresar cosas que el
sistema necesita hacer para ellos. Son similares a los
escenarios de uso, excepto en que no estan limitados
a describir una interface de usuario. Tienen la forma
de tres frases aproximadamente escritas por el cliente
en su propio lenguaje sin terminos tecnicos.
Uno de los grandes errores con las historias de
usuario es la diferencia con las tradicionales especificacion de requisitos. La mayor diferencia es el nivel de
detalle. Las historias de usuario deberan proporcionar u
nicamente el suficiente detalle para realizar una
estimacion con bajo riesgo de cuanto va a costar implementarla. Cuando llegue la hora de implementarla,
los desarrolladores iran a los clientes para recibir una
descripcion detallada del requisito cara a cara.
Los desarrolladores estiman cuanto les llevara desarrollar la historia. Cada una de ellas podra llevarles
1, 2 o 3 semanas en un tiempo ideal de desarrollo.
Es decir, si no hay distracciones, otras tareas asignadas y saben exactamente lo que hay que hacer. Para
mas de 3 semanas, significa que es necesario dividir
la historia, y para menos de 1 semana significa que se
ha detallado demasiado y que es necesario combinar
varias historias.
Otra diferencia entre las historias y los documentos de requisitos es el enfoque en las necesidades del
usuario. Se debe intentar evitar detalles tecnologicos
especficos, dise
nos de base de datos y algoritmos. Se
debe intentar mantener las historias enfocadas a las
necesidades del usuario y sus beneficios, en vez de a
especificar el dise
no de las interfaces.

User stories

Una de las tecnicas m

as usadas por los metodos
agiles para el tratamiento de los requisitos, y que no
se incluyen en la IR tradicional, son las historias de
usuario. Vamos a introducir brevemente de que se
trata.
Los documentos de especificaci
on de requisitos
estan normalmente expresados en un lenguaje impersonal y fro, d
andonos el que sin ninguna explicacion del negocio. Esto es muy distinto al modo
en que contamos historias. En una historia empezamos describiendo el contexto y dando antecedentes a
los actores. Una historia lleva a los actores a traves
de de una cadena de eventos que comunican un resultado deseado. A traves de las historias, el oyente
comprende las necesidades de los usuarios, y puede
tener un profundo efecto en la motivaci
on del equipo
de desarrollo.
Las historias de usuario (User Stories) sirven para
el mismo prop
osito que los casos de uso. Se usan para
estimar tiempos en la planificaci
on de los proyectos
software. Tambien se usan en vez de los grandes do-

5.

Conclusiones

Las fases del proceso de IR (elicitacion, analisis y

validacion) estan presentes en los metodos agiles. Pero no estan tan claramente separadas como en los
metodos tradicionales. Se repiten en cada iteracion,
lo que hace mas difcil distinguir las fases. La aproximacion perezosa a la IR, que realizan los metodos
agiles, puede tener ventajas en el coste del proyecto,
ya que pospone el esfuerzo de coleccionar los detalles
de los requisitos hasta el u
ltimo momento: justo antes
de ser implementados. Las tecnicas usadas estan, a
5

veces, descritas muy vagamente y la implementacion

real se deja en manos de los desarrolladores. Este es
el resultado de el enfasis en las personas con un alto
nivel tecnico que hacen los metodos
agiles: los buenos
desarrolladores har
an las cosas bien.
La falta de documentaci
on de los metodos agiles
puede causar problemas. La documentacion se usa
para compartir conocimiento entre las personas del
proyecto. Un tecnico nuevo no necesita preguntar para resolver sus dudas. Adem
as la documentacion reduce la perdida de conocimiento cuando un miembro
del equipo desaparece del proyecto. Sin embargo, los
metodos agiles suelen producir una documentacion
mas orientada al cliente, ya que se realiza normalmente bajo demanda de el. Esta documentacion es mas
compacta y m
as f
acil de mantener. Los metodos agiles dedican menos esfuerzo a documentar, por lo que
suelen ser mas productivos. Mientras, en los metodos
tradicionales se suele producir la documentacion para
responder a todas las preguntas que puedan surgir en
un futuro. Esto es una tarea muy difcil de cumplir
y genera demasiada cantidad de documentos, lo que
hace que sea complicado mantenerla actualizada.
Los metodos
agiles tambien tienen problemas de
trazabilidad de requisitos como se estudia en el
artculo de Lee [3]. Mantenerla de la misma forma
que la IR tradicional, desde las tecnicas de elicitacion
al producto final, requiere un seguimiento manual a
traves de las distintas etapas. Por lo que normalmente no se realiza ya que el esfuerzo requerido es mayor
que el beneficio percibido. La naturaleza de los artefactos de desarrollo de los metodos
agiles, dificulta
para los modelos centrados en los documentos cumplir con las necesidades de trazabilidad. Este artculo
[3] propone una herramienta para el seguimiento de
los requisitos en los metodos
agiles denominada Echo.
Esta actitud perezosa ante los requisitos que tienen los metodos
agiles hace que la estimacion y el
desarrollo de la arquitectura software sea mas difcil,
como concluye el estudio de Tomayko [5]. Sin el conocimiento de la forma final del producto, ni las demandas del mercado, es imposible realizar una estimacion
correcta. Es poco reconfortante reconocer que la mayora de las estimaciones realizadas por los metodos
tradicionales son err
oneas debido a la omision de requisitos o a los cambios en ellos.

Como resumen final, podemos ver que los metodos

agiles proporcionan muchas ventajas en el desarrollo
de proyectos software, sobre todo en la comunicacion
con el cliente y en la eficiencia del desarrollo. Sin embargo todava tienen muchos problemas por resolver,
alguno de ellos en el tratamiento que hacen de los requisitos. Estos metodos sacrifican la documentacion
de requisitos, en beneficio de la flexibilidad y la rapidez del desarrollo, lo que como hemos visto puede
provocar problemas en la gestion del proyecto.

Referencias
[1] Varios autores. Manifesto for agile software development. http://www.agilemanifesto.org/, 2001.
[2] J. Botaschanjan, M. Pister, and B. Rumpe.
TESTING AGILE REQUIREMENTS MODELS.
First Hanzhou-Lubeck Conference on Software
Engineering (HL-SE03), pages 7379, 2003.
[3] C. Lee, L. Guadagno, and X. Jia. An Agile Approach to Capturing Requirements and Traceability. Proceedings of 2nd International Workshop
on Traceability in Emerging Forms of Software
Engineering, Montreal, Canada, 7, 2003.
[4] F. Paetsch, A. Eberlein, and F. Maurer. Requirements engineering and agile software development. Enabling Technologies: Infrastructure for
Collaborative Enterprises, 2003. WET ICE 2003.
Proceedings. Twelfth IEEE International Workshops on, pages 308313, 2003.
[5] J.E. Tomayko. Engineering of Unstable Requirements Using Agile Methods. Proceedings of
the International Workshop on Time Constrained
Requirements Engineering at IEEE Joint International Requirements Conference, Essen, Germany, IEEE, 2002.