Machine Translated by Google

Capítulo 7

Requisitos
Especificación y
Metodologías ágiles

Introducción a Metodologías Ágiles*

Las metodologías ágiles son una familia de estrategias de desarrollo de software no
tradicionales que han capturado la imaginación de muchos que desconfían de los enfoques
tradicionales cargados de procesos. Las metodologías ágiles se caracterizan por no tener
un proceso rígido, aunque este hecho no significa que las metodologías ágiles, cuando se
emplean correctamente, no sean rigurosas ni adecuadas para aplicaciones industriales, lo
son. Sin embargo, lo que característicamente falta en los enfoques ágiles son las soluciones
de "libro de cocina" que se centran en reuniones obligatorias y enfoques de desarrollo
prescritos de documentación compleja.
Las metodologías ágiles se aplican a la ingeniería de software. Si bien hay elementos
de metodologías ágiles que se pueden aplicar a la ingeniería de sistemas (en particular, las
consideraciones humanas), tales metodologías generalmente se describen como livianas o
esbeltas cuando se aplican a sistemas que no son de software. Esto se debe a que las
metodologías ágiles dependen de una serie de prototipos rápidos y no desechables, un
enfoque que no es práctico en los sistemas basados en hardware. En cualquier caso, el
ingeniero que no es de software aún puede beneficiarse de este capítulo porque las
metodologías ágiles se emplean cada vez más y porque la mentalidad del ingeniero de
software ágil incluye algunas perspectivas saludables.

*
Parte de esta sección ha sido extraída de Laplante (2006) con permiso.

179
Machine Translated by Google

180 ÿ Ingeniería de Requisitos para Software y Sistemas

Estamos descubriendo mejores formas de desarrollar

software haciéndolo y ayudando a otros a hacerlo.

en bruto este trabajo hemos llegado a valorar:

• Individuos e interacciones sobre
procesos y herramientas
• Software de trabajo sobre integral
documentación
• Colaboración del cliente sobre el contrato
negociación
• Responder al cambio sobre seguir un
plan

Es decir, si bien hay valor en los elementos de la

derecha, valoramos más los elementos de la izquierda.

Figura 7.1 Manifiesto para el desarrollo ágil de software. (Tomado de Beck, K.,
Extreme Programming Explained: Embrace Change, Longman Higher Education, Londres, 2000

Para comprender completamente la naturaleza de las metodologías ágiles, debemos examinar un

documento llamado Manifiesto Ágil y los principios que lo sustentan.
El Manifiesto Ágil fue presentado por varios de los principales defensores de las metodologías ágiles para
explicar su filosofía (consulte la Figura 7.1).
Los signatarios del Manifiesto Ágil incluyen muchas luminarias de la práctica moderna de la ingeniería
de software, como Kent Beck, Mike Beedle, Alistair Cockburn, Ward Cunningham, Martin Fowler, Jim
Highsmith, Ron Jeffries, Brian Marick, Robert Martin, Steve Mellor y Ken Schwaber. Detrás del Manifiesto
Ágil hay un conjunto de principios. Mire los principios a continuación, notando el énfasis en aquellos aspectos
que se enfocan en la ingeniería de requisitos, que ponemos en cursiva.

Principios detrás del manifiesto ágil

fi A intervalos regulares, el equipo reflexiona sobre cómo ser más eficaz y luego
sintoniza y ajusta su comportamiento en consecuencia.
ÿ Nuestra mayor prioridad es satisfacer al cliente a través de una atención temprana y continua.
entrega de software valioso.
fi Dar la bienvenida a los requisitos cambiantes, incluso al final del desarrollo. Procesos ágiles har
cambio de ness para la ventaja competitiva del cliente.
fi Entregar software que funcione con frecuencia, desde un par de semanas hasta un par de meses, con
preferencia a la escala de tiempo más corta.
fi Los empresarios y los desarrolladores deben trabajar juntos a diario durante todo el proyecto.
fi Construir proyectos en torno a personas motivadas. Dales el ambiente y
apoyo que necesitan y confiar en ellos para hacer el trabajo.
fi El método más eficiente y eficaz para transmitir información hacia y dentro de un
El equipo de desarrollo es una conversación cara a cara.
Machine Translated by Google

Especificación de requisitos y metodologías ágiles ÿ 181

fi El software funcional es la medida principal del progreso.

ÿ Los procesos ágiles promueven el desarrollo sostenible. Los patrocinadores, desarrolladores y
usuarios deberían poder mantener un ritmo constante indefinidamente.
ÿ La atención continua a la excelencia técnica y el buen diseño mejora
agilidad.
fi La simplicidad, el arte de maximizar la cantidad de trabajo no realizado, es esencial
cial “Haz lo más simple que pueda funcionar”.
fi Las mejores arquitecturas, requisitos y diseños surgen de la autoorganización
equipos (Beck 2000).

Observe cómo los principios reconocen y adoptan la noción de que los requisitos cambian a lo
largo del proceso. Además, los principios ágiles enfatizan la comunicación personal frecuente (esta
característica también es beneficiosa en la ingeniería de sistemas que no son de software). Las
características destacadas de la ingeniería de requisitos en los modelos de procesos ágiles difieren de
la cascada "tradicional" y de los modelos más modernos, como el desarrollo iterativo, evolutivo o en
espiral. Estos otros modelos favorecen una gran cantidad de trabajo inicial en el proceso de ingeniería
de requisitos y la producción, a menudo, de documentos de especificaciones de requisitos voluminosos.

Beneficios del desarrollo de software ágil

Los métodos ágiles de desarrollo de software son un subconjunto de métodos iterativos* que se
enfocan en aceptar el cambio y enfatizan la colaboración y la entrega temprana del producto,
manteniendo la calidad. El código de trabajo se considera el verdadero artefacto del proceso de
desarrollo. Los modelos, planes y documentación son importantes y tienen su valor, pero existen solo
para respaldar el desarrollo de software funcional, en contraste con los otros enfoques ya discutidos.
Sin embargo, esto no significa que un enfoque de desarrollo ágil sea un juego de todos. Hay prácticas
y principios muy claros que los metodólogos ágiles deben adoptar.

Los métodos ágiles son adaptativos en lugar de predictivos. Este enfoque difiere significativamente
de los modelos de proceso que enfatizan la planificación del software en gran detalle durante un largo
período de tiempo, y para los cuales los cambios significativos en la especificación de los requisitos
del software pueden ser problemáticos. Los métodos ágiles son una respuesta al problema común de
los requisitos en constante cambio que pueden atascar los enfoques de diseño iniciales más
"ceremoniales", que se centran en gran medida en la documentación al principio.

Los métodos ágiles también están orientados a las personas en lugar de a los procesos. Esto
significa que explícitamente intentan hacer que el desarrollo sea "divertido". Presumiblemente,

*
La mayoría de la gente define las metodologías ágiles como incrementales. Pero el desarrollo incremental
implica que se planifican las características y el cronograma de cada versión entregada. En algunos casos,
las metodologías ágiles tienden a generar versiones con conjuntos de funciones y fechas de entrega que
casi siempre no son las previstas.
Machine Translated by Google

182 ÿ Ingeniería de Requisitos para Software y Sistemas

esto se debe a que escribir especificaciones de requisitos de software y descripciones de diseño de software
es oneroso y, por lo tanto, debe minimizarse.
Inayat et al. realizaron una revisión sistemática de estudios de proyectos de software ágiles publicados
entre 2002 y 2012. Identificaron cinco desafíos de ingeniería de requisitos tradicionales que fueron
erradicados o minimizados por las prácticas de ingeniería de requisitos que se encuentran en las
metodologías ágiles. Estos desafíos fueron:

fi Cerrar la brecha de comunicación con todas las partes interesadas

ÿ Aumentar la participación del cliente
ÿ Reducir el tamaño y la complejidad de la documentación
ÿ Reducción del desplazamiento del alcance

fi Lograr la validación de requisitos (Inayat et al. 2015)

Señalaron que se necesitaba más investigación y evidencia empírica para fortalecer y generalizar estas
conclusiones, pero los resultados de su estudio aún apuntan fuertemente al poder de los métodos ágiles.

Las metodologías ágiles incluyen Crystal, Extreme Programming, Scrum, el método de desarrollo de
sistemas dinámicos (DSDM), el desarrollo basado en funciones y la programación adaptativa, entre otras.
Veremos más de cerca dos de las metodologías ágiles más utilizadas: XP y Scrum.

Programación extrema
Extreme Programming (XP)* es una de las metodologías ágiles más utilizadas.
XP está tradicionalmente dirigido a equipos de desarrollo más pequeños y requiere relativamente pocos
artefactos detallados. XP adopta un enfoque iterativo para sus ciclos de desarrollo. Podemos visualizar la
diferencia en el proceso entre un modelo de cascada tradicional, modelos iterativos y XP (Figura 7.2).
Mientras que un método evolutivo o iterativo aún puede tener distintas fases de análisis, diseño,
implementación y prueba de requisitos similares al método en cascada, XP trata estas actividades como
interrelacionadas y continuas.

XP promueve un conjunto de 12 prácticas básicas que ayudan a los desarrolladores a responder y

adoptar cambios inevitables. Las prácticas se pueden agrupar según cuatro prácticas
áreas:

ÿ Planificación
ÿ Codificación
ÿ Diseño
ÿ Pruebas

*
La programación extrema a veces también se escribe "Programación extrema" para resaltar el "XP".
Machine Translated by Google

Especificación de requisitos y metodologías ágiles ÿ 183

Cascada Iterativo PE

Análisis

Diseño
Tiempo

Implementación

Prueba

Figura 7.2 Comparación de los ciclos de desarrollo en cascada, iterativo y XP.

(Tomado de Beck, K., Extreme Programming Explained: Embrace Change,
Longman Higher Education, Londres, 2000.)

Algunas de las características de planificación distintivas de XP incluyen la celebración de reuniones diarias*,

la realización de pequeños lanzamientos frecuentes y el traslado de personas. Las prácticas de codificación incluyen
tener al cliente disponible constantemente, codificar primero los casos de prueba de unidad y emplear la
programación en pares (una estrategia de codificación única en la que dos desarrolladores trabajan juntos en el
mismo código). La eliminación de la propiedad territorial de cualquier unidad de código es otra característica de XP.

Las prácticas de diseño incluyen buscar primero las soluciones más simples, evitar demasiada planificación
para el crecimiento futuro (generalidad especulativa) y refactorizar el código (mejorar su estructura) continuamente.

Las prácticas de prueba incluyen la creación de nuevos casos de prueba cada vez que se encuentra un error y
tener pruebas unitarias para todo el código, posiblemente utilizando marcos como XUnit.

Melé
Scrum, que lleva el nombre de un punto particularmente polémico en un partido de rugby, permite la autoorganización
de los equipos fomentando la comunicación verbal entre todos los miembros del equipo y entre todas las partes
interesadas. Un principio fundamental de Scrum es que las metodologías tradicionales de desarrollo de software
basadas en planes, como el desarrollo iterativo y en cascada, se centran demasiado en el proceso y no lo suficiente
en el software. Además, mientras que el desarrollo dirigido por planes se enfoca en artefactos que no son de
software (p. ej., documentación) y procesos (p. ej., revisiones formales), Scrum enfatiza la importancia de producir
software que funcione pronto y con frecuencia. Scrum alienta

* Las reuniones de pie duran 10 minutos o menos, donde los participantes literalmente se ponen de pie y
dan un informe oral de las actividades del día anterior y los planes para ese día.
Machine Translated by Google

184 ÿ Ingeniería de Requisitos para Software y Sistemas

autoorganización fomentando una comunicación de alta calidad entre todas las partes interesadas.
En este caso, está implícito que el problema no puede entenderse o definirse completamente (puede
ser un problema perverso). Y el enfoque en Scrum está en maximizar la capacidad del equipo para
responder de manera ágil a los desafíos emergentes.
Scrum presenta una acumulación viva de trabajo priorizado por hacer. La finalización de un
conjunto en gran parte fijo de elementos pendientes se produce en una serie de iteraciones o sprints
breves (aproximadamente 30 días). Cada día, se lleva a cabo una reunión breve (por ejemplo, de 15
minutos) o Scrum en la que se explica el progreso, se describe el trabajo próximo y se plantean los
impedimentos. Se produce una breve sesión de planificación al comienzo de cada sprint para definir
los elementos del registro atrasado que se completarán. Al final del sprint se realiza una breve revisión
post-mortem o retrospectiva de los latidos del corazón (Figura 7.3).
Un Scrum Master elimina obstáculos o impedimentos en cada sprint. El Scrum Master no es el
líder del equipo (ya que se autoorganizan), sino que actúa como un amortiguador de productividad
entre el equipo y cualquier influencia desestabilizadora. En algunas organizaciones, el rol del Scrum
Master puede causar confusión. Por ejemplo, si dos miembros de un equipo Scrum no están trabajando
bien juntos, un gerente sénior podría esperar que el Scrum Master solucione el problema. Arreglar la
disfunción del equipo no es el papel del Scrum Master. Los problemas de personal deben ser resueltos
por los gerentes de línea a los que reportan las partes involucradas. Este escenario ilustra la necesidad
de educación en toda la institución sobre metodologías ágiles cuando se van a emplear dichos
enfoques.

24
horas

Scrum : 10–15
minutos

30 diarios
pique reunión
dias
reserva

Artículos Nuevo
pendientes ampliados por la funcionalidad es
equipo demostrado
al final del
Producto
sprint.
reserva

Figura 7.3 El proceso de desarrollo Scrum de Boehm y Turner (2003).

(Adaptado de Schwaber, K. y Beedle, M., Agile Software Development
with SCRUM, Prentice Hall, Upper Saddle River, NJ, 2001).
Machine Translated by Google

Especificación de requisitos y metodologías ágiles ÿ 185

Ingeniería de Requerimientos para Metodologías Ágiles

Una diferencia importante entre las metodologías tradicionales (aquí nos referimos a cascada,
evolutiva, iterativa, espiral, etc.) y ágil está en la recopilación de requisitos.
De hecho, algunos defensores de las metodologías ágiles utilizan las supuestas ventajas de las
prácticas de ingeniería de requisitos ágiles como punto de venta de los métodos ágiles.
Los enfoques de ingeniería de requisitos para metodologías ágiles tienden a ser mucho más
informales.
Otra diferencia está en el momento de las actividades de ingeniería de requisitos.
En los sistemas tradicionales y la ingeniería de software, los requisitos se recopilan, analizan,
refinan, etc. en la etapa inicial del proceso. En los métodos ágiles, la ingeniería de requisitos es una
actividad continua; es decir, los requisitos se refinan y descubren con cada construcción del
sistema. Incluso en metodologías en espiral, donde se utilizan prototipos para el refinamiento de
requisitos, la ingeniería de requisitos ocurre mucho menos tarde en el proceso de desarrollo.

Los clientes están constantemente involucrados en el descubrimiento y refinamiento de

requisitos en métodos ágiles. Todos los desarrolladores de sistemas están involucrados en la
actividad de ingeniería de requisitos y cada uno puede, y debe, tener una interacción regular con
los clientes. En los enfoques tradicionales, el cliente tiene menos participación una vez que se ha
escrito y aprobado la especificación de requisitos y, por lo general, la participación no suele ser con
los desarrolladores de sistemas.
Presumiblemente, el enfoque ágil de la ingeniería de requisitos es mucho más invulnerable a
los cambios a lo largo del proceso (recuerde, "aceptar el cambio") que en la ingeniería de software
tradicional.

Prácticas Generales en Metodologías Ágiles

Cao y Ramesh (2008) estudiaron 16 organizaciones de desarrollo de software que usaban XP o
Scrum (o ambos) y descubrieron siete prácticas de ingeniería de requisitos que eran ágiles por
naturaleza.

1. Comunicaciones cara a cara (sobre especificaciones escritas)

2. Ingeniería de requisitos iterativos
3. Priorización extrema (priorización continua en lugar de una vez al principio,
y la priorización se basa principalmente en el valor comercial)
4. Planificación constante
5. Prototipos
6. Desarrollo basado en pruebas
7. Revisiones y pruebas

Algunas de estas prácticas se pueden encontrar en el desarrollo no ágil (por ejemplo, desarrollo
basado en pruebas y creación de prototipos), pero estas siete prácticas fueron consistentes en
todas las organizaciones estudiadas.
Machine Translated by Google

186 ÿ Ingeniería de Requisitos para Software y Sistemas

Nivel de habilidad del personal

Bajo

Dinamismo
Criticidad
Alto
Alto

Bajo Alto

Bajo
Pequeña

Caos

Largo
Pedido
Tamaño del equipo Cultura

Figura 7.4: Equilibrando agilidad y disciplina. (Adaptado de Boehm, B.

y Turner, R., Balancing Agility and Discipline: A Guide to the Perplexed,
Addison Wesley, Boston, 2003).

A diferencia de la especificación de requisitos de software fundamentales, el artefacto fundamental

en los métodos ágiles es una pila de requisitos en constante evolución y perfeccionamiento. Estos
requisitos son generalmente en forma de historias de usuario. En cualquier caso, estos requisitos son
generados por el cliente y priorizados: cuanto mayor sea el nivel de detalle en el requisito, mayor será
la prioridad. A medida que se descubren nuevos requisitos, se agregan a la pila y la pila se reorganiza
para preservar la priorización (Figura 7.4).

No hay proscripciones para agregar, cambiar o eliminar requisitos de la lista en ningún momento
(lo que le da al cliente una gran libertad). Por supuesto, una vez que se construye el sistema, o
probablemente mientras se está construyendo, la pila de historias de usuario se puede convertir a una
especificación de requisitos de software convencional para el mantenimiento del sistema y otros
propósitos convencionales.

Ejemplo de aplicación de desarrollo de software ágil

Considere el sistema de punto de venta de la tienda de mascotas. Supongamos que quisiéramos
utilizar una metodología ágil de desarrollo de software, concretamente Scrum, para desarrollar este sistema.
Veamos cómo podría ser el proceso de ingeniería de requisitos.
Supongamos que tuviéramos un equipo de desarrollo de cinco personas, incluido el Scrum Master.
Para simplificar, supongamos que las únicas partes interesadas son el dueño de la tienda de mascotas
(que en realidad es el cliente, ya que paga por el sistema), los clientes de la tienda, los cajeros y los
contadores. Seleccionaremos representantes de clase para la tienda.
Machine Translated by Google

Especificación de requisitos y metodologías ágiles ÿ 187

clientes, cajeros y contadores. Colectivamente, llamémoslos el “panel de partes interesadas”. Ahora

considere las siguientes actividades.

1. El Scrum Master organiza una serie de reuniones entre el equipo de desarrollo y el cliente (el
propietario de la tienda) para obtener una comprensión básica de los requisitos, restricciones y
reglas básicas del sistema. Con base en estas discusiones, el Scrum Master organiza un conjunto
de actividades de elicitación adicionales, que posiblemente incluyan entrevistas estructuradas,
clasificación de tarjetas y grupos focales con otras partes interesadas. Se utiliza un estudio QFD
como actividad de validación (ya que es probable que haya muchos otros sistemas POS que se
puedan comparar). El objetivo de estas actividades es producir un conjunto de historias de
usuarios priorizadas (digamos alrededor de 100), incluidas las estimaciones de esfuerzo para
cada una. Pero el cliente nos ha dicho que quiere un sistema de "vanguardia", por lo que sabemos
que a medida que el sistema pasa por el desarrollo, el cliente y otras partes interesadas van a
querer una funcionalidad nueva o diferente.

2. El equipo de desarrollo analiza las historias de usuario y selecciona un subconjunto de estas;

digamos 10, para el primer sprint. Estas 10 serían las historias más "de cara al usuario", dejando
la mayor parte del procesamiento de back-end para más adelante.
3. El equipo de desarrollo vuelve a consultar con las partes interesadas para obtener más claridad
sobre estas 10 historias de usuarios antes de comenzar el desarrollo.
4. Cada día comienza con un scrum. Los desarrolladores utilizan el diseño basado en pruebas para
derivar orgánicamente el diseño del sistema, así como los casos de prueba de unidad. El Scrum
Master facilita las comunicaciones entre el equipo de desarrollo y las distintas partes interesadas
para que las preguntas de las partes interesadas puedan responderse rápidamente.
Después de aproximadamente 30 días, se completa el primer sprint.
5. Se presenta al panel de partes interesadas el sistema creado durante el sprint para recibir
comentarios. Estos comentarios incluirán cambios en el incremento del sistema actual, nuevas
funciones que se agregarán y, posiblemente, funciones que se omitirán.
6. Con base en estos comentarios, el equipo de desarrollo crea nuevas historias de usuarios y las
agrega al trabajo pendiente, modifica otras historias de usuarios según sea necesario y reorganiza
el trabajo pendiente.
7. El equipo de desarrollo selecciona un nuevo conjunto de historias de usuario (digamos 10) del
trabajo pendiente para el siguiente sprint de 30 días, y los pasos del proceso (C a F) se repiten
hasta que se agota el trabajo pendiente.

Se pueden realizar pruebas de aceptación adicionales, según los términos del contrato con el cliente.
Esta prueba se basaría en un conjunto de criterios desarrollados durante la negociación del contrato.
Estas pruebas de aceptación basadas en una especificación de requisitos son habituales para el
desarrollo convencional, pero atípicas para el desarrollo ágil.

Originalmente había 100 historias de usuarios, pero incluso si programamos 10 historias de usuarios
por sprint (mes), es probable que el tiempo total de desarrollo supere los 10 meses.
Esto se debe a que se están agregando nuevas historias de usuario y se están cambiando las antiguas.
Machine Translated by Google

188 ÿ Ingeniería de Requisitos para Software y Sistemas

Por supuesto, Scrum Master realiza un seguimiento de la velocidad del proyecto durante cada sprint para refinar sus
estimaciones de finalización del proyecto.

¿Cuándo se recomienda Agile?*

El uso de metodologías ágiles de software se está volviendo muy popular en la industria, al menos como lo demuestran
los datos de las encuestas. Por ejemplo, en un Forrester/Dr. En la encuesta de desarrolladores de Dobbs, el 35% de
los encuestados informaron que utilizan algún tipo de metodología ágil (West et al. 2010). Más recientemente, Kassab
et al. (2014) encontraron que el 46% de los ingenieros de software encuestados usaban una metodología ágil. También
se descubrió que los métodos ágiles eran más del doble de populares que el desarrollo en cascada dentro de los
Estados Unidos y siete veces más populares fuera de los Estados Unidos. También encontraron que el desarrollo de
software ágil se usaba con más frecuencia que la cascada en todas las regiones de los Estados Unidos, excepto en el
noreste, donde se usan casi por igual. Finalmente, la investigación encontró que los métodos ágiles se usaban con
más frecuencia que el desarrollo estilo cascada en todas las industrias excepto en finanzas, banca y seguros. Lo que
es más importante, el estudio encontró que los encuestados expresaron una mayor satisfacción con las prácticas de
ingeniería de requisitos al usar el desarrollo ágil en comparación con el desarrollo de estilo en cascada (Kassab et al.
2014).

Pero surge la pregunta, ¿cuándo se deben utilizar metodologías ágiles de desarrollo?

Boehm y Turner sugieren que la forma de responder a la pregunta es mirar el proyecto a lo largo de un continuo de
cinco dimensiones; tamaño (en términos de cantidad de personal involucrado), criticidad del sistema, nivel de habilidad
del personal, dinamismo (cantidad anticipada de cambios en el sistema durante algún intervalo de tiempo) y cultura
organizacional (si la organización prospera en el caos o en el orden) (Boehm y Turner 2003) . En la Figura 7.4, a
medida que las características del proyecto tienden a alejarse del centro del diagrama, la probabilidad de éxito con
metodologías ágiles disminuye.

Por lo tanto, los proyectos evaluados en el círculo más interno son candidatos probables para enfoques ágiles,
los del segundo círculo (pero no en el círculo interno) son marginales y los que están fuera del segundo círculo no son
buenos candidatos para enfoques ágiles.

Mejores prácticas de requisitos ágiles

Scott Ambler (2007) sugiere las siguientes mejores prácticas para la ingeniería de requisitos utilizando métodos
ágiles. Muchas de las prácticas se derivan directamente de los principios del Manifiesto Ágil:

fi Tener una participación activa de las partes interesadas

fi Usar modelos inclusivos (partes interesadas)

ÿ Adopte un enfoque que priorice la amplitud

fi Modele los detalles de la “tormenta” (requisitos altamente volátiles) justo a tiempo

* Esta sección es una adaptación de Laplante (2006) con permiso.

Machine Translated by Google

Especificación de requisitos y metodologías ágiles ÿ 189

fi Implementar requisitos, no documentarlos

ÿ Cree requisitos independientes de la plataforma hasta cierto punto
ÿ Recuerda que cuanto más pequeño mejor

ÿ Trazabilidad de preguntas
fi Explicar las técnicas
fi Adoptar la terminología de las partes interesadas

ÿ Hazlo divertido
ÿ Obtener apoyo administrativo
ÿ Convierta a las partes interesadas en desarrolladores

ÿ Tratar los requisitos como una pila priorizada

fi Tener una interacción personal frecuente
ÿ Realizar entregas frecuentes de software
ÿ Expresar requisitos como características

Ambler también sugiere el uso de artefactos como CRC, pruebas de aceptación, definiciones de
reglas comerciales, casos de cambio, diagramas de flujo de datos, interfaces de usuario, casos de uso,
prototipos, características y escenarios, diagramas de casos de uso e historias de usuarios para modelar
los requisitos (Ambler 2007). ). Estos elementos se pueden agregar al documento de especificación de
requisitos de software junto con las historias de usuario.
Para la elicitación de requisitos, sugiere utilizar entrevistas (tanto en persona como electrónicas),
grupos focales, JAD, análisis de código heredado, observación etnográfica, análisis de dominio y tener al
cliente en el sitio en todo momento (Ambler 2007). En el resto de este capítulo, nuestra discusión se
centra en el uso de historias de usuarios para modelar los requisitos.

Ingeniería de requisitos en XP
La ingeniería de requisitos en XP sigue el modelo que se muestra en la Figura 7.5, donde la pila de
requisitos en el modelo de Ambler se refiere a historias de usuarios. Y en XP, las historias de usuario se
administran e implementan como código a través del “juego de planificación”.
El juego de planificación en XP toma dos formas: lanzamiento y planificación de iteraciones.
La planificación del lanzamiento se lleva a cabo después de que se haya escrito un conjunto inicial de historias de usuario.

Este conjunto de historias se utiliza para desarrollar el plan general del proyecto y el plan de iteraciones.
El conjunto también se usa para decidir el cronograma aproximado para cada historia de usuario y
proyecto general.
La planificación de iteraciones es un período de tiempo en el que se implementan un conjunto de
historias de usuarios y correcciones de pruebas fallidas de iteraciones anteriores. Cada iteración tiene una
duración de 1 a 3 semanas. El seguimiento de la tasa de implementación de historias de usuarios de
iteraciones anteriores (lo que se denomina velocidad del proyecto) ayuda a refinar el programa de desarrollo.
Debido a que los requisitos evolucionan constantemente durante estos procesos, el creador de XP,
Kent Beck, dice que "en XP, los requisitos son un diálogo, no un documento" (Beck et al. 2001), aunque
es típico convertir la pila de historias de usuario en un software. especificación de requisitos.
Machine Translated by Google

190 ÿ Ingeniería de Requisitos para Software y Sistemas

Usuario
Más Alto cuentos
Comience a implementar
requisitos desde aquí

Detalle Prioridad

Los requisitos pueden ser

implementación
Dirección
de agregado, eliminado y
reorganizado en cualquier momento

Menos Bajo

Figura 7.5 Proceso ágil de gestión de cambios en los requisitos. (Adaptado

de Ambler, S., Gestión de cambios de requisitos ágiles, 2007, http://
www.agilemod eling.com/essays/changeManagement.htm, último (consultado en enero de

Ingeniería de requisitos en Scrum

En Scrum, la pila de requisitos que se muestra en el modelo de la Figura 7.5 es, como en XP, la
evolución de la acumulación de historias de usuarios. Y como en XP, estos requisitos se congelan
en cada iteración para la estabilidad del desarrollo. En Scrum, cada iteración toma alrededor de un mes.
Para gestionar los cambios en la pila, se otorga a una persona la autoridad final para la priorización
de requisitos (generalmente el patrocinador del producto).
En Scrum, la acumulación de requisitos se organiza en tres tipos: producto, lanzamiento y
sprint. El backlog del producto contiene los backlogs de la versión, y cada versión contiene el
backlog del sprint. La figura 7.6 es un diagrama de Venn que muestra la relación de contención de
los elementos pendientes.
El backlog del producto actúa como un repositorio de los requisitos destinados a su lanzamiento
en algún momento. Los requisitos en la cartera de productos incluyen requisitos de nivel bajo, medio
y alto.
El backlog de la versión es un conjunto priorizado de elementos extraídos del backlog del
producto. Los requisitos en la acumulación de versiones pueden evolucionar para que contengan
más detalles y estimaciones de bajo nivel.
Finalmente, la lista de tareas pendientes del sprint es un conjunto de requisitos de lanzamiento
que el equipo completará (totalmente codificados, probados y documentados) al final del sprint.
Estos requisitos han evolucionado a un nivel muy alto de detalle y, por lo tanto, su prioridad es alta.
Scrum ha sido adoptado en varias corporaciones importantes, con un éxito notable.
Algunos de los estudiantes del autor también usan Scrum en los cursos. En estos casos, resulta
muy eficaz cuando hay poco tiempo para largos procesos de descubrimiento de requisitos.
Machine Translated by Google

Especificación de requisitos y metodologías ágiles ÿ 191

Producto

Liberación pique

Liberación pique

pique

Figura 7.6 Relación de backlog entre producto, lanzamientos y sprints.

Escribir historias de usuario

Las historias de usuario son la unidad de requisitos más básica en la mayoría de las metodologías ágiles.
Cada historia de usuario representa una característica deseada por el cliente. Las historias de usuario (un
término acuñado por Kent Beck) las escribe el cliente en fichas, aunque el proceso puede automatizarse a
través de wikis u otras herramientas. Los requisitos formales, los casos de uso y otros artefactos se derivan
de las historias de los usuarios por parte del equipo de ingeniería de software según sea necesario.

Una historia de usuario consta de los siguientes componentes:

ÿ Título: este es un identificador corto para la historia. Un verbo en tiempo presente en voz activa es
deseable en el título.

fi Prueba de aceptación: este es un identificador único que será el nombre de un método para probar la
historia.
fi Prioridad—esto se basa en el esquema de priorización adoptado. La prioridad se puede asignar en
función de la priorización "tradicional" de la importancia o del nivel de detalle (la mayor prioridad se
asigna al mayor detalle).
ÿ Puntos de historia: este es el tiempo estimado para implementar la historia de usuario. Este aspecto
hace que las historias de usuario sean útiles para la estimación de esfuerzos y costos.
fi Descripción: esta es de una a tres oraciones que describen la historia.

En la Tabla 7.1 se muestra un diseño de muestra para estos elementos en una ficha.
Las historias iniciales de los usuarios generalmente se recopilan en pequeñas reuniones fuera del sitio.
Las historias se pueden generar a través de enfoques orientados a objetivos (p. ej., “discutamos cómo un
cliente hace una compra”) oa través de enfoques interactivos (flujo de conciencia).
El desarrollo de historias de usuario es un proceso "iterativo e interactivo". El equipo de desarrollo también
administra el tamaño de las historias para lograr uniformidad (p. ej., demasiado grande, dividir, demasiado
pequeño, combinar).
Machine Translated by Google

192 ÿ Ingeniería de Requisitos para Software y Sistemas

Una historia de usuario de ejemplo para un cliente que devuelve artículos en el sistema POS de la tienda de mascotas
tem se muestra en la Tabla 7.2.

Las historias de usuario deben ser comprensibles para los clientes y cada historia debe agregar valor.

Los desarrolladores no escriben historias de usuarios, lo hacen los usuarios. Pero las historias deben ser lo

suficientemente pequeñas como para que se puedan completar varias por iteración. Las historias deben ser independientes

(tanto como sea posible); es decir, una historia no debe hacer referencia de ida y vuelta a otras historias.

Finalmente, las historias deben ser comprobables, como cualquier requisito, si no se puede probar, no es un requisito. El

equipo de desarrollo considera la capacidad de prueba de cada historia.

La Tabla 7.3 muestra otra historia de usuario de ejemplo que describe la detección de una amenaza a la seguridad en

el sistema de manejo de equipaje del aeropuerto.

Finalmente, vale la pena señalar que existe una diferencia significativa entre los casos de uso y las historias de usuario.

Las historias de usuarios provienen de la perspectiva del cliente y son simples, y evitan los detalles de implementación. Los

casos de uso son más complejos y pueden incluir detalles de implementación (por ejemplo, objetos fabricados). Los clientes

no suelen escribir casos de uso (y si lo hacen, ojo, porque ahora el cliente se dedica a la “ingeniería de software”). Finalmente,

es difícil decir cuál es la equivalencia para el número de casos de uso por historia de usuario. Una historia de usuario podría

equivaler a uno o más de 20 casos de uso.

Tabla 7.1 Diseño de la historia de usuario

Título

Examen de ingreso Puntos de historia prioritarios

Descripción

Tabla 7.2 Historia de usuario: Sistema POS de tienda de mascotas

Título: Artículos devueltos por el cliente

Prueba de aceptación: custRetItem Prioridad 1 Puntos de historia: 2

Cuando un cliente devuelve un artículo, su compra debe ser autenticada. Si la compra fue auténtica, entonces
se debe acreditar la cuenta del cliente o devolver el monto de la compra. El inventario debe actualizarse en
consecuencia.

Tabla 7.3 Historia de usuario: Manejo de equipaje

Título: Detectar amenazas de seguridad

Prueba de aceptación: detSecThrt Prioridad 1 Puntos de historia: 3

Cuando se determina que una bolsa escaneada contiene una instancia de un artículo prohibido, la bolsa se
desviará al transportador del punto de control de seguridad. Al responsable de seguridad se le enviará un correo
electrónico indicando que se ha detectado una amenaza potencial.
Machine Translated by Google

Especificación de requisitos y metodologías ágiles ÿ 193

Por ejemplo, para la historia de usuario de devolución del cliente en la Tabla 7.2, puede imaginar que se
necesitarán muchos más casos de uso para lidiar con las diversas situaciones que pueden surgir en la
devolución de un cliente. En las metodologías ágiles, las historias de usuario son mucho más preferidas que los casos de uso.
El Apéndice D incluye una discusión adicional de las historias de usuarios tanto en entornos ágiles como
no ágiles.

Ingeniería de requisitos ágiles

Necesitamos hacer una distinción entre ingeniería de requisitos para metodologías ágiles e ingeniería de
requisitos ágiles. La ingeniería de requisitos ágil significa, en general, cualquier enfoque de ingeniería de
requisitos ad hoc que pretenda ser más flexible que la ingeniería de requisitos tradicional. Esta definición no
debe confundirse con las prácticas específicas para la ingeniería de requisitos en metodologías ágiles como
acabamos de discutir (Sillitti y Succi 2006).

En los últimos años se han introducido varios enfoques de ingeniería de requisitos ágiles, muchos de los
cuales no son mucho más que una ingeniería de requisitos descuidada. Pero parte del trabajo reciente en esta
área también ha sido bueno. Sin embargo, para cualquier metodología de ingeniería de requisitos ágiles
"legítima" que pueda encontrar, la mayoría de las prácticas se pueden rastrear hasta el Manifiesto Ágil. Por
ejemplo, Vlaanderen et al. (2011) mostró cómo ciertas prácticas de ingeniería de requisitos de Scrum también
podrían ser para la gestión de productos de software (después de la entrega). En particular, identificaron los
ciclos de sprint, la administración de la acumulación, las reuniones diarias y la colaboración temprana y
frecuente como prácticas necesarias.

Historia Desarrollo basado en pruebas

Para ilustrar una metodología ágil, describimos un ejemplo notable. En esta metodología llamada SDD (Story
Test-Driven Development), se incorporan muchas de las características habituales de cara al cliente de las
metodologías ágiles junto con ráfagas breves de desarrollo iterativo al estilo XP o Scrum. Sin embargo, una
diferencia en SDD es que, en lugar de las historias de usuarios convencionales, los clientes escriben o revisan
"pruebas de historias".
Las pruebas de historia son descripciones no técnicas del comportamiento junto con pruebas que verifican que
el comportamiento es correcto. Las pruebas de historias ayudan a “descubrir muchas piezas faltantes o
inconsistencias en una historia” (Mugridge 2008).
Una buena característica de la prueba de la historia es que utiliza el marco Fit para permitir a los usuarios
crear casos de prueba en las historias de forma tabular (consulte el Capítulo 8). Por lo tanto, los usuarios
especifican intuitivamente el comportamiento y las pruebas para ese comportamiento en los requisitos.
Por ejemplo, para un sistema de nómina típico para una empresa (como la tienda de mascotas), en la
figura 7.7 se proporciona una prueba de historia que describe cómo calcular el pago de horas extra y ordinarias
para un empleado en función de varias horas registradas.
La tabla de la Figura 7.7 muestra, por ejemplo, que si un empleado trabaja 5 jornadas laborales
consecutivas de 9 horas, entonces se considera que tiene 45 horas en jornadas ordinarias y ordinarias.
Machine Translated by Google

194 ÿ Ingeniería de Requisitos para Software y Sistemas

Dentro de

Procesamiento de salarios

Calcular

Horas máx. Horas extraordinarias ordinarias

común

9,9,9,9,9 9 45 0
9,7 9 dieciséis 0
9,0 9 9 0
0 9 0 0

11,7 9 dieciséis 2
9,9,9,9,9 8 40 5
10,11,12,13,14 9 45 15

Figura 7.7 Uso de una prueba de historia para mostrar cómo una empresa calcula el pago
de horas ordinarias y horas extra. (Tomado de Mugridge, R., Software, 25: 68–75, 2008.)

cero horas en el pago de horas extras adeudadas. Si un trabajador trabaja 10, 11, 12,
13 y 14 horas al día en una semana, tiene derecho a 45 horas regulares y 15 horas
extra. Pero el marco de ajuste es una especificación interactiva: si ingresa diferentes
valores en la tabla que son incorrectos, se mostrarán como no válidos (consulte el Capítulo 8).
Se considera que el desarrollo SDD es complementario al desarrollo basado en
pruebas (TDD) en el sentido de que el primero se aplica al desarrollo general del sistema
(Mugridge 2008).

Desafíos para la ingeniería de

requisitos en metodologías ágiles
Por supuesto, hay desafíos en cualquier tecnología nueva, y los hay en el uso de
metodologías ágiles, particularmente con respecto a la ingeniería de requisitos.
Williams (2004) analiza algunas de estas deficiencias.
Por ejemplo, las metodologías ágiles no siempre tratan bien los requisitos no
funcionales. ¿Por qué esto es así? Una razón es que no siempre son evidentes cuando
se trata solo de la funcionalidad de requisitos (a través de historias de usuarios).
Machine Translated by Google

Especificación de requisitos y metodologías ágiles ÿ 195

Williams sugiere enfrentar este desafío aumentando las historias de usuario con técnicas apropiadas
de descubrimiento de requisitos no funcionales, como el análisis competitivo.

Otra deficiencia es que con metodologías ágiles, la interacción con el cliente es sólida, pero
principalmente a través de la creación de prototipos. Como hemos visto, hay otras formas de obtener
requisitos matizados y comprender las necesidades de las partes interesadas, por ejemplo, sería
deseable utilizar varias técnicas de entrevista.
Además, con metodologías ágiles, la validación es fuerte a través de pruebas y prototipos, pero
la verificación no es tan fuerte. Williams (2004) sugiere que el uso de métodos formales podría
fortalecer la ingeniería de requisitos ágiles (2004).
Rubin y Rubin (2011) identificaron construcciones de documentación que a menudo se pasan
por alto en el desarrollo ágil de software y sugirieron formas de aliviar este problema. En particular,
señalaron que el conocimiento del dominio y la arquitectura y el diseño del sistema emergente no
se capturan adecuadamente en las prácticas tradicionales de requisitos ágiles. Sus hallazgos
implican que los documentos de requisitos ágiles deben anotarse con el conocimiento de dominio
apropiado, y los documentos de diseño y arquitectura ágil correspondientes deben anotarse con la
arquitectura y el diseño del sistema final, respectivamente.

La gestión de requisitos está integrada en el proceso (por ejemplo, XP y Scrum), pero se centra
principalmente en el nivel de código. Williams sugiere que la gestión de requisitos podría fortalecerse
agregando más prácticas de gestión de configuración estándar.

Finalmente, Inayat et al. (2015) resumió un conjunto de desafíos de ingeniería de requisitos

ágiles. Los desafíos identificados por Inayat et al. fueron:

ÿ Descuidar los requisitos no funcionales

ÿ Falta de trazabilidad de requisitos
ÿ Priorización incorrecta de requisitos
ÿ Documentación de requisitos mínimos
ÿ Cuestiones contractuales

ÿ Disponibilidad del cliente

ÿ Acuerdo del cliente

Estos desafíos se hicieron eco de algunos de los identificados por otros.

Aunque todavía existen desafíos importantes en el uso de metodologías ágiles para la ingeniería
de software, también existen ventajas significativas. Por lo tanto, las metodologías ágiles de software
deben considerarse al menos para la mayoría de los proyectos. E incluso cuando las metodologías
ágiles no se consideran adecuadas para ciertos proyectos de software, o cuando el proyecto no es
software, se podrían utilizar muchas de las prácticas discutidas para las metodologías ágiles. Por
ejemplo, prácticas como el cliente siempre en el sitio, el enfoque en el producto sobre la
documentación y el desarrollo temprano de casos de prueba, aún deben incorporarse en casi todos
los proyectos.
Machine Translated by Google

196 ÿ Ingeniería de Requisitos para Software y Sistemas

VIÑETA 7.1 Sitio web de la Ley del Cuidado de Salud a Bajo Precio

En 2010, los Estados Unidos aprobaron la Ley del Cuidado de Salud

a Bajo Precio que exige que todos los ciudadanos obtengan algún
tipo de seguro médico. La ley fue controvertida, y se sumó a la
controversia el lanzamiento desastroso del sitio web asociado del
gobierno federal. El proyecto fue complejo e involucró a 55 contratistas.
En lugar de centrarse en un proceso de desarrollo sólido, hubo prisa
por implementar el sitio web y, como era de esperar, sufrió muchos
problemas. Hubo muchos problemas estructurales y de seguridad,
pero los problemas de usabilidad, como bloqueos frecuentes, tiempos
de respuesta deficientes, contenido faltante o engañoso y dificultades
de navegación recibieron la mayor atención pública (Venkatesh et al.
2014). Alrededor de 9,47 millones de usuarios intentaron registrarse
durante la primera semana de implementación, pero solo 271ÿ000 lo
lograron (Cleland-Huang 2014). Los estudios sobre el lanzamiento
fallido del sitio web mencionaron una variedad de causas
fundamentales, incluida la subestimación del cronograma del proyecto,
el alcance mal definido, la especificación deficiente de los requisitos
y el análisis y la gestión de riesgos ineficientes (Anthopoulos et al. 2016).
Si bien muchos expertos sugirieron correctamente que un mejor
proceso de requisitos tradicionales habría mitigado estos problemas,
la presión para implementar el sitio rápidamente fue tremenda. Sin
embargo, es probable que un proceso ágil y dinámico de
descubrimiento y desarrollo de requisitos podría haber llevado a
mejores resultados del proyecto y percepción pública, al tiempo que
permitió una implementación más temprana. No se informa que tal
proceso haya sido sugerido o considerado.

Ejercicios

7.1 ¿Cómo encaja la documentación de SRS en un marco ágil?

7.2 ¿Es posible utilizar metodologías ágiles cuando el cliente no está en el sitio?
¿Si es así, cómo?

7.3 ¿Por qué las metodologías ágiles generalmente no son adecuadas para proyectos basados en
hardware a diferencia de los proyectos de software?
7.4 ¿Por qué puede ser difícil que las metodologías ágiles cubran requisitos no funcionales?

7.5 ¿Hay algún problema al encapsular los requisitos en las historias de los usuarios?
7.6 Para el sistema POS de la tienda de mascotas, genere una historia de usuario para las compras de los clientes.
7.7 Para el sistema POS de la tienda de mascotas, genere casos de uso para varios clientes
compras
Machine Translated by Google

Especificación de requisitos y metodologías ágiles ÿ 197

7.8 Para el sistema de manejo de equipaje del aeropuerto, genere una historia de usuario para tratar
con equipaje que va a ser desviado a otro vuelo.
7.9 Para el sistema de manejo de equipaje del aeropuerto, genere casos de uso para tratar una pieza
de equipaje perdida.
7.10 Para el sistema de manejo de equipaje del aeropuerto, generar casos de uso para manejar el
equipaje que se desviará a otro vuelo.
7.11 Para los siguientes sistemas, discuta las ventajas y desventajas de usar un enfoque ágil (para los
componentes de software):
7.11.1 Sistema POS de tienda de mascotas

7.11.2 Sistema de manipulación de equipaje de líneas aéreas

7.11.3 Sistema de casa inteligente (Apéndice A)

*7.12 Hay una serie de herramientas de software, tanto comerciales como de código abierto, que se pueden
utilizar para gestionar las actividades de requisitos de un proyecto ágil.
Investigue estas herramientas y prepare una matriz de comparación de productos.

Referencias
Ambler, S. (2007). Gestión ágil del cambio de requisitos. http://www.modeladoagile.
com/essays/changeManagement.htm (consultado en enero de 2017).
Anthopoulos, L., Reddickb, CG y Giannakidou, I. (2016). ¿Por qué fracasan los proyectos de gobierno
electrónico? Un análisis de la Sanidad. Gov. Government Information Quarterly 33(1): 161–173.

Beck, K. (2000). Programación extrema explicada: aceptar el cambio. Longman superior

Educación. Londres.
Beck, K., Beedle, M., van Bennekum, A., Cockburn, A., Cunningham, W., Fowler, M., Grenning, J., et
al. (2001). “Manifiesto Ágil” y “Principios detrás del Manifiesto Ágil”. http://agilemanifesto.org/
(consultado en enero de 2017).
Boehm, B. y Turner, R. (2003). Equilibrar la agilidad y la disciplina: una guía para los perplejos.
Addison-Wesley. Bostón.
Cleland-Huang, J. (2014). ¡No despidas al arquitecto! ¿Dónde estaban los requisitos? Software IEEE,
31(2): 27–29.
Cao, L. y Ramesh, B. (2008). Prácticas ágiles de ingeniería de requisitos: un estudio empírico
estudio. Software, 25(1): 60–67.
Inayat, I., Moraes, L., Daneva, M. y Salim, SS (mayo de 2015). Una reflexión sobre la ingeniería de
requisitos ágiles: Soluciones aportadas y retos planteados. En Actas del taller científico de
XP2015, p. 6, ACM, Chicago, IL.
Kassab, M., Neill, C. y Laplante, P. (2014). Estado de la práctica en ingeniería de requisitos: datos
contemporáneos. Innovaciones en Ingeniería de Sistemas y Software, 10(4): 235–241.
Laplante, PA (2006). Lo que todo ingeniero necesita saber sobre ingeniería de software.
CRC/Taylor & Francis, Boca Ratón, Florida.
Mugridge, R. (2008). Gestión de requisitos de proyectos ágiles con desarrollo basado en pruebas de
historia. Software, 25(1): 68–75.
Rubin, E. y Rubin, H. (2011). Apoyar el desarrollo ágil de software a través de activos
documentación. Ingeniería de requisitos, 16(2): 117–132.
Machine Translated by Google

198 ÿ Ingeniería de Requisitos para Software y Sistemas

Schwaber, K. y Beedle, M. (2001). Desarrollo Ágil de Software con SCRUM. Prentice Hall.
Upper Saddle River, Nueva Jersey.

Sillitti, A. y Succi, G. (2006). Ingeniería de requisitos para métodos ágiles, en A. Aurum y C. Wohlin
(Eds.), Requisitos de ingeniería y gestión de software, págs. 309–326.
Saltador. Nueva York, NY.
Venkatesh, V., Hoehle, H. y Aljafari, R. (2014). Una evaluación de usabilidad del sitio web de Obamacare.
Información Gubernamental Trimestral, 31(4): 669–680.
Vlaanderen, K., Jansen, S., Brinkkemper, S. y Jaspers, E. (2011). La refinería de requisitos ágil: aplicación
de los principios SCRUM a la gestión de productos de software. Tecnología de la información y el
software, 53(1): 58–70.
West, D., Grant, T., Gerush, M. y D'Silva, D. (2010). Desarrollo ágil: la adopción generalizada ha
cambiado la agilidad. Investigaciones Forrester. Cambridge, MA.
Williams, L. (2004). Elicitación ágil de requisitos. http://agile.csc.ncsu.edu/SEMaterials/
AgileRE.pdf (consultado en enero de 2017).