Gestion de Requisitos

Gestión de
requisitos
PID_00191267
Jordi Pradel Miquel

Jose Raya Martos
CC-BY-SA • PID_00191267 Gestión de requisitos
Los textos e imágenes publicados en esta obra están sujetos –excepto que se indique lo contrario– a una licencia de
Reconocimiento-Compartir igual (BY-SA) v.3.0 España de Creative Commons. Se puede modificar la obra, reproducirla, distribuirla
o comunicarla públicamente siempre que se cite el autor y la fuente (FUOC. Fundació per a la Universitat Oberta de Catalunya), y
siempre que la obra derivada quede sujeta a la misma licencia que el material original. La licencia completa se puede consultar en:
http://creativecommons.org/licenses/by-sa/3.0/es/legalcode.ca
Índice
Introducción............................................................................................... 5
Objetivos....................................................................................................... 6
1. Factores que hay que considerar para la gestión de

requisitos.............................................................................................. 7
1.1. Factores básicos para la gestión de requisitos ............................. 7
1.2. Impacto financiero de los requisitos .......................................... 9
2. Estimación de requisitos.................................................................. 11
2.1. Magnitudes para la estimación de requisitos .............................. 11
2.2. Precisión de las estimaciones ...................................................... 13
2.3. Técnicas de estimación ............................................................... 14
2.3.1. Comparación y triangulación ........................................ 14
2.3.2. Estimación colaborativa: planning poker......................... 15
2.4. Estimación de requisitos no funcionales .................................... 16
3. Priorización y selección de requisitos.......................................... 17

3.1. Gestión de productos de software .............................................. 18
3.1.1. La visión del producto .................................................. 18
3.1.2. Producto mínimo entregable ......................................... 20
3.1.3. User-story mapping........................................................... 21
3.2. Técnicas de priorización ............................................................. 22
3.2.1. La técnica de los 100 dólares ........................................ 22
3.2.2. Prioridades limitadas ..................................................... 23
3.2.3. El modelo Kano ............................................................. 24
3.2.4. A/B testing........................................................................ 27
3.3. Selección de requisitos: El backlog del producto ......................... 29
3.3.1. Requisitos no funcionales y el backlog........................... 30
3.3.2. El backlog y otros documentos de requisitos ................. 31
4. Gestión de los cambios en los requisitos..................................... 32

4.1. Factores de cambios en los requisitos ......................................... 32
4.2. Los cambios en el backlog............................................................ 33
5. Caso práctico....................................................................................... 35
5.1. Visión del producto .................................................................... 35
5.2. Obtención de requisitos candidatos ........................................... 35
5.3. Estimación de los requisitos ....................................................... 36
5.3.1. Estimación de la primera historia ................................. 36
5.3.2. Estimación de las siguientes historias ........................... 38
5.4. Priorización de los requisitos ...................................................... 38

5.5. Selección de requisitos ................................................................ 40
Resumen....................................................................................................... 41
Actividades.................................................................................................. 43
Ejercicios de autoevaluación.................................................................. 44
Solucionario................................................................................................ 45
Glosario........................................................................................................ 49
Bibliografía................................................................................................. 50
CC-BY-SA • PID_00191267 5 Gestión de requisitos
Introducción
En este módulo presentamos varias técnicas para decidir cuáles de los posibles
requisitos (requisitos candidatos) formarán parte del software que queremos
desarrollar.
A diferencia de la obtención de requisitos, donde el énfasis está en encontrar

el máximo número posible de éstos, en esta etapa tenemos que elegir cuáles
incorporamos a nuestro software y cuáles no. Este proceso es crítico para el
éxito del software como producto, puesto que la satisfacción de sus usuarios
depende directamente de ello.
Empezaremos viendo una introducción general a la gestión de requisitos y a

los factores básicos que hay que tener en cuenta a la hora de decidir qué re-
quisitos elegimos y cuáles descartamos. Uno de estos factores es la estimación
del coste. Veremos diferentes técnicas para estimar el coste de los requisitos,
como por ejemplo la triangulación o el planning poker.
Otro factor importante es la prioridad (o estimación del valor), por lo que ha-
remos una pequeña introducción a la gestión de productos (entendiendo el
software como un producto) y, a continuación, veremos algunas técnicas de
priorización de requisitos, como la visión de producto, las prioridades limita-
das o el modelo Kano.
Finalmente, hablaremos de la gestión de los cambios en los requisitos y de

cómo tiene que ir evolucionando la lista de requisitos a lo largo del proyecto
de desarrollo.
Todo esto lo ilustraremos, al final del módulo, con el caso práctico de Viajes
UOC.
Objetivos
El objetivo principal de este módulo es dar a conocer al estudiante las herra-

mientas necesarias para, a partir de un conjunto de requisitos candidatos, de-
cidir cuáles son los más prioritarios para el producto de software a desarrollar.
En concreto, al finalizar este módulo el estudiante tiene que alcanzar los ob-
jetivos siguientes:
1. Saber crear una lista priorizada y estimada de requisitos candidatos.
2. Saber elegir de la lista cuáles son los requisitos más adecuados y prioritarios
para el producto de software que hay que desarrollar.
3. Entender cómo tiene que evolucionar esta lista a lo largo del proceso de
desarrollo del software.
1. Factores que hay que considerar para la gestión de

requisitos
En los módulos anteriores nos hemos centrado en obtener el máximo número

posible de requisitos de manera que tengamos en cuenta todos los intereses de
los stakeholders. Antes de poder planificar el proyecto de desarrollo, sin embar-
go, hay que saber cuáles de estos requisitos candidatos son los que finalmente
formarán parte de nuestro software.
Denominamos gestión�de�requisitos al proceso mediante el cual deci-

dimos cuáles de los requisitos candidatos de nuestro software formarán
parte del conjunto definitivo de requisitos.
1.1. Factores básicos para la gestión de requisitos
Para tomar esta decisión necesitamos más información de la que disponemos

ahora mismo. Por ejemplo, necesitamos una estimación del coste que repre-
senta incluir cada uno de los requisitos (puesto que muchas veces la decisión
de incluirlo o no dependerá de este coste).
Supongamos que estamos considerando un requisito como por ejemplo “El usuario tiene
que poder compartir el plan de viaje en las redes sociales”.
Como casos extremos, si nos dicen que incorporar este requisito nos cuesta dos días de
desarrollo y que el proyecto, en total, lo hemos estimado en un año de trabajo, nuestra
predisposición a implementarlo será mayor que si nos dicen que nos cuesta un mes de
trabajo sobre un total de seis meses de duración del proyecto.
Otro factor básico para la gestión de requisitos es el valor aportado por los
mismos, puesto que, de forma parecida, el valor que aporta un requisito al
conjunto del software será decisivo a la hora de determinar si lo incorporamos
o no:
Volviendo al ejemplo anterior, aunque sea un mes de trabajo sobre seis, si entendemos
que ese requisito será nuestro gran valor añadido y que el éxito de la empresa depende de
esa funcionalidad, estaremos mucho más predispuestos a implementarlo que si, simple-
mente, se trata de una idea feliz de uno de los stakeholders, pero que en realidad sabemos
que nadie usará.
Hay requisitos que, con independencia del valor que aporten al producto en Estimación y priorización
sí, pueden sumar una gran ventaja para el equipo de desarrollo, que, precisa- de requisitos
mente por este motivo, puede decidir priorizarlos por delante de otros requi- A lo largo de este módulo a
sitos. Es el caso de los requisitos que nos ayudan a generar conocimiento o a menudo usaremos la expresión
estimación de requisitos para
reducir riesgos. hacer referencia a la estima-
ción del coste de los requisitos,
y la expresión priorización de
En nuestro ejemplo, si tenemos otros requisitos relacionados con las redes sociales y requisitos para hacer referencia
hemos identificado como riesgo la interacción con las mismas, tenemos que considerar a la estimación del valor de los
la posibilidad de priorizar el requisito de integración con las redes sociales como manera requisitos.
de mitigar este riesgo (una vez lo hayamos implementado, ya sabemos que podemos
implementar el resto).
Aunque no lo consideremos un riesgo para el éxito del proyecto, igualmente nos puede
interesar priorizarlo sólo por el conocimiento que genera (cómo integrarse con las redes
sociales).
A la hora de seleccionar los requisitos, tenemos que tener en cuenta cua-

tro factores básicos: el valor que aporta el requisito, su coste de desa-
rrollarlo y soporte, la capacidad de generar conocimiento a la hora de
desarrollarlo y el riesgo que eliminamos por haberlo desarrollado.
Tomamos como ejemplo la autenticación de usuarios en el nuevo sistema de

ventas de Viajes UOC.
Desde el punto de vista del valor, a pesar de que nuestros clientes esperan que
el nuevo sistema sea seguro, si sólo les damos la opción de autenticarse pero
no pueden hacer nada más, difícilmente estarán interesados en usar nuestro
sistema, por lo que, desde el punto de vista del valor, la autenticación de usua-
rios no es un requisito prioritario.
En cambio, el coste de desarrollar esta funcionalidad puede variar significati-

vamente si lo hacemos al principio respecto de si lo hacemos más adelante.
Como se trata de una funcionalidad que sabemos seguro que incluiremos, te-
nemos que valorar si nos vale más la pena incluirla desde un principio y desa-
rrollar el resto del sistema con la base de esta funcionalidad implementada o
bien desarrollar el sistema sin autenticación de usuarios y añadirla más ade-
lante.
Desde el punto de vista del conocimiento, a pesar de que esta funcionalidad

no nos ayudará a conocer mejor el producto que queremos desarrollar, nos
puede ayudar a conocer mejor la infraestructura de seguridad que tenemos
que usar. Se podría dar el caso, por ejemplo, de que tuviéramos que usar un
mecanismo de autenticación que no hemos usado nunca y que, por lo tanto,
se genere nuevo conocimiento al implementar esta funcionalidad.
El último factor es el riesgo. ¿Puede pasar que, si encontramos problemas a

la hora de implementar la autenticación de usuarios y no la podemos imple-
mentar como queríamos, se ponga en peligro la viabilidad del proyecto? Por
ejemplo, si hemos decidido usar cierto framework de seguridad que no hemos
usado antes y no tenemos ninguna alternativa pensada, quizás nos convenga

implementar la autenticación de usuarios al principio y comprobar que el fra-
mework cumple con lo que esperábamos.
De los cuatro factores que hemos visto, uno (el valor) lo tenemos que obtener
de los stakeholders, mientras que el resto (coste, conocimiento y riesgo) los
tenemos que determinar de manera colaborativa entre los stakeholders y los
desarrolladores. Por eso, la gestión de los requisitos es un trabajo que involucra
a todos los actores interesados en el desarrollo del sistema informático, sean
stakeholders o desarrolladores.
1.2. Impacto financiero de los requisitos
La mayoría de proyectos de desarrollo de software se llevan a cabo para generar

nuevos ingresos o para reducir gastos. Por eso, vale la pena que estudiemos
con algo más de detalle cómo se puede aproximar el impacto financiero de
los requisitos.
Una manera habitual de generar ingresos es mediante la ampliación de la cuota

de mercado del producto (aportando nuevos clientes).
En el caso de Viajes UOC, la posibilidad de vender viajes por Internet está claramente
enfocada a la ampliación de la cuota de mercado. Por lo tanto, habrá una serie de fun-
cionalidades que amortizaremos mediante la mencionada ampliación de la cuota.
En el caso del software que no se ha desarrollado pensando en su comercia-

lización, una posible manera de generar ingresos puede ser facilitando la co-
mercialización del mismo.
En todo momento hemos supuesto que el software que estamos desarrollando para Viajes
UOC será un software de uso interno, pero una posible vía de generación de ingresos
sería hacer que Viajes UOC pudiera vender este software a otras franquicias de agencias
de viajes.
También podemos aportar nuevos ingresos mediante el incremento de los in-

gresos por cliente, ya sea porque con una funcionalidad nueva los clientes
existentes están dispuestos a comprar más licencias, porque la funcionalidad se
comercialice como un paquete adicional o, simplemente, porque los clientes
estén dispuestos a pagar más por el producto si cierto requisito está presente.
En el caso de Viajes UOC, se ha planteado la posibilidad de que el nuevo sistema ayude

a ofrecer productos a otras empresas, como, por ejemplo, seguros de viajes.
Otro factor que cabe considerar desde el punto de vista financiero es el coste
de oportunidad de un requisito: el coste que supone que la funcionalidad no
esté presente en nuestro producto. Por ejemplo, podría pasar que si no imple-
mentamos cierta funcionalidad, los clientes actuales dejen de renovar sus li-
cencias y, por lo tanto, se produzca una reducción de los ingresos.
Por ejemplo, si decidimos no permitir que los clientes paguen por Internet y los obliga-
mos a ir a la agencia, tenemos que tener en cuenta que esto puede significar que dejemos
de vender algunos viajes, ya que no todos los clientes estarán dispuestos a presentarse
en la agencia físicamente.
Finalmente, debemos tener en consideración las mejoras en eficiencia para la

organización que supondrá la utilización del nuevo sistema o producto que
estamos desarrollando. Estas mejoras acostumbran a llegar mediante la auto-
matización (total o parcial) de procesos manuales o mediante mejoras en la
integración y la comunicación entre departamentos.
En Viajes UOC sabemos que una persona dedica tres días cada mes a integrar los datos
de ventas con el sistema de facturación. Si conseguimos automatizar este proceso, aho-
rraremos a la empresa tres días del sueldo de esta persona, que podrá dedicarse a tareas
con más valor añadido.
2. Estimación de requisitos
La estimación de requisitos es una tarea muy compleja, puesto que siempre Terminología
trabajamos con información incompleta (todavía no sabemos exactamente
En general, se usa la expresión
qué problemas nos encontraremos a la hora de implementar el requisito). Por estimación de requisitos para
este motivo, todas las técnicas que veremos a continuación tratan de determi- hacer referencia a la estima-
ción del coste de los requisitos,
nar el coste del requisito por aproximación. aunque hay otros factores a te-
ner en cuenta (como la prio-
ridad), que también tendre-
mos que estimar puesto que
no nos es posible conocerlos
La estimación de requisitos consiste, pues, en etiquetar cada requisito con exactitud.
con un valor que dé una idea de cómo afecta al coste total del proyecto
la inclusión de ese requisito.
Idealmente, este valor es un valor expresado en términos económicos (un im-

porte) a pesar de que, como este coste económico depende de muchos factores
que no están relacionados con el trabajo que hay que hacer (como por ejem-
plo, los costes por hora de trabajo de los desarrolladores), se suelen usar otras
magnitudes para expresar el coste.
2.1. Magnitudes para la estimación de requisitos
La magnitud más inmediata para estimar el coste de un requisito es la dura-

ción del mismo: la duración nos dice el número de horas de trabajo que su-
pondrá implementar el requisito. Una vez que sabemos el número de horas
necesarias (magnitud que necesitaremos para poder planificar el proyecto), es-
tas se pueden trasladar a coste aplicando un precio por hora.
Si hemos estimado el requisito “Publicar el plan de viaje en las redes sociales” en 23 horas
de trabajo, para calcular el coste sólo tenemos que multiplicar 23 por el precio/hora y ya
tenemos una estimación del coste de desarrollo del requisito.
El principal problema con que nos encontramos a la hora de estimar la dura-

ción es que esta depende de una serie de circunstancias muy difíciles de pre-
decir, como, por ejemplo, la moral de los desarrolladores, la materialización o
no de los riesgos del proyecto, cambios en el entorno, etc.
Por este motivo, a menudo se usan las “horas�ideales” (suponiendo que no

hay ninguna interrupción, que los riesgos no se materializan, etc.) y se les
aplica un factor de corrección en el momento de calcular el coste. Este factor
de corrección es el que recoge el impacto de estas circunstancias difíciles de
predecir.
Así, en el ejemplo anterior, si las 23 horas son 23 horas ideales, a la hora de calcular
el coste, este no será 23 × precio/hora sino 23 f × precio/hora, donde f es el factor de
corrección.
Uno de los problemas con la estimación en “horas ideales” es que, a la hora

de comunicar la estimación, se hace difícil justificar la diferencia entre “horas
ideales” y “horas reales” (¿cómo puede ser que tardemos 8 horas en hacer una
cosa que hemos estimado hacer en 3 horas ideales?).
Por este motivo, las metodologías ágiles proponen una manera alternativa de
estimar el coste de los requisitos: en lugar de estimar la duración estimamos el
tamaño (una medida arbitraria en función del volumen de trabajo y la com-
plejidad, que supone implementar un requisito en comparación con el resto
de requisitos).
Si hemos estimado que “Publicar el plan de viaje en las redes sociales” supone, a grandes
rasgos, el triple de trabajo que “Enviar el plan de viaje por correo electrónico”, podemos
estimar el coste de “Publicar el plan de viaje en las redes sociales” a partir del coste de
“Enviar el plan de viaje por correo electrónico” (multiplicando por tres).
Esta separación simplifica el problema de hacer estimaciones aplicando el prin-

cipio de “divide y conquistarás”. Ahora la persona o personas que hacen la
estimación sólo se tendrán que fijar en un concepto: el tamaño del requisito.
Para reforzar esta separación, la estimación del tamaño se suele hacer en una Lectura recomendada
unidad ficticia, que no tenga ninguna relación con la duración del requisito
Podéis encontrar más infor-
estimado. Mike Cohn los denomina puntos de historia. La estimación en pun- mación sobre los puntos de
tos de historia no solo nos ayuda a separarla de la estimación de la duración, historia en: M. Cohn, Agile
Estimating and Planning.
sino que nos centra en la comparación y triangulación como técnicas fiables
para estimar historias de usuario (y, por lo tanto, requisitos).
Ved también
Como por sí misma una estimación de 5 puntos de historia para un requisito no quiere
decir nada, nos fuerza a compararla con otros requisitos ya estimados. Entonces es cuando Veremos con más detalle las
podemos ver que 5 puntos de historia quiere decir que es algo más del doble que otro técnicas de comparación y
requisito que hayamos estimado en 2 puntos, y algo más de la mitad que otro requisito triangulación en el subaparta-
do 2.3.1 de este módulo.
que hayamos estimado en 8 puntos.
Finalmente, para obtener la duración (en horas reales) de un requisito a partir

de su tamaño (en puntos), se puede hacer a través de la velocidad del equipo:
La velocidad es una medida del progreso de un equipo por unidad de

tiempo.
Supongamos que estamos a punto de empezar un proyecto de desarrollo que hemos

estimado en 500 puntos.
Antes de finalizar la primera iteración todavía no hemos obtenido ningún beneficio res-
pecto a estimar en horas, ya que no sabemos cuánto se tarda en implementar 500 puntos
y, por lo tanto, nuestra estimación de duración es igual de fiable que si la hubiéramos
calculado en horas ideales o en horas reales.
Al finalizar la primera iteración, sin embargo, tenemos un dato muy importante: el nú-
mero de puntos que suman los requisitos implementados durante aquella iteración. Si
hemos implementado completamente, por ejemplo, requisitos por un total de 90 pun-
tos, ya podemos hacer una primera estimación basada en datos reales: a 90 puntos por
iteración, necesitaremos entre 5 y 6 iteraciones para finalizar el proyecto. En este caso,
decimos que la velocidad del equipo es de 90 puntos.
A medida que vamos completando iteraciones, tendremos más valores de ve-

locidad para estimar la velocidad de las iteraciones que nos quedan antes de
acabar el proyecto y, por lo tanto, la fiabilidad de nuestra estimación irá cre-
ciendo.
2.2. Precisión de las estimaciones
La estimación en el desarrollo de sistemas informáticos es un problema difí-

cil ya identificado desde hace mucho tiempo. Algunos autores (como Barry
Boehm, creador del ciclo de vida de desarrollo en espiral) ya hablaban de ello
en los años ochenta diciendo que las estimaciones en ingeniería del software
presentaban desviaciones importantes.
Las causas de estas dificultades son muchas, incluyendo la carencia de infor-

mación, la incertidumbre, la presencia de riesgos, etc. Es por eso por lo que
es importante ser capaces de estimar de forma pragmática conociendo cuál es
la precisión que podemos esperar de las estimaciones que hacemos. Por estas
razones, hay que elegir bien qué valores adjudicamos a nuestras estimaciones.
Los físicos, por ejemplo, cuando miden la realidad, indican los valores con un número de
dígitos significativos que refleja la precisión de la medición. Indicar que el peso de una
muestra es de 6,00 g no tiene sentido si el instrumento de medición tiene una precisión
de 0,1 g. En todo caso, dicen que el peso es de 6,0 g. De manera parecida, a la hora de
hacer estimaciones de requisitos, hay que elegir una forma de expresar las estimaciones
que refleje la precisión que tienen.
Por otro lado, las personas somos mejores haciendo estimaciones por compa- Lectura recomendada
ración y triangulación si la medida de aquello que estimamos es relativamente
Podéis encontrar más infor-
parecida. Mike Cohn propone los valores 1, 2, 3, 5 y 8 para estimar requisitos mación en la obra de Mike
de medida parecida. Cohn, Agile Estimating and
Planning.
Supongamos, por ejemplo, que estamos estimando la altura de la Torre Agbar de Barcelo-
na en una unidad ficticia, los “puntos de altura”. Saber que una persona tiene una altura
estimada de 1 punto no nos ayudaría mucho, puesto que nos cuesta comparar dos alturas Tallas de camiseta
tan diferentes. ¿Mide 50 veces lo que una persona? ¿100 veces?
Otra escala habitual es la de las
En cambio, si sabemos que la Torre Mapfre de Barcelona está estimada en 3 puntos de tallas de camiseta, donde esti-
altura, podemos llegar a la conclusión de que son de alturas similares y asignar también mamos los requisitos según si
un 3 a la Torre Agbar. son XS, S, M, L o XL.
Teniendo en cuenta que la Torre Agbar mide140 m de altura y la Torre Mapfre mide
150 m, el valor estimado es bastante bueno (el valor real sería 2,8) y, para muchos usos,
suficiente.
Por esta razón, a medida que los requisitos tienen granularidad más gruesa,
serán más grandes y difíciles de estimar por comparación. Habrá que tener
en cuenta, pues, que la precisión todavía será menor. Para reflejarlo, de nue-
vo, Mike Cohn propone añadir los valores 13, 20, 40 y 100 (redondeando y
añadiendo imprecisión a los 13, 21, 34, 55, 89 que seguirían en la escala de
Fibonacci).
Siguiendo con el ejemplo anterior, si estimamos alturas de elementos asignando 1 punto

de altura a la altura de una persona, diríamos que la altura de las torres Agbar y Mapfre
es de 100. No sería una estimación nada precisa, pero como, a diferencia de las torres,
los requisitos grandes se descompondrán en requisitos de granularidad más fina cuando
estemos más cerca de su implementación, entonces ya refinaremos la estimación calcu-

lando los requisitos en los que se ha descompuesto.
2.3. Técnicas de estimación
A continuación veremos algunas de las técnicas que podemos usar para estimar Nota
el coste (sea a partir de la duración o a partir de la medida) de un requisito.
En adelante, supondremos que
estamos estimando los requisi-
2.3.1. Comparación y triangulación tos a partir de su tamaño.
Una de las técnicas más básicas e importantes para la estimación de requisitos

es la comparación. Esta consiste, a la hora de estimar un requisito, en buscar
otro ya estimado que tenga un coste comparable, y establecer el coste del nue-
vo requisito por comparación con el requisito ya estimado.
Supongamos que queremos estimar el requisito “El usuario tiene que poder compartir el
plan de viaje en las redes sociales”.
Como no sabemos cuál puede ser el coste de este requisito, buscamos otro que ya tenga
un coste parecido, como por ejemplo, “El usuario tiene que poder compartir la ficha de
un destino en las redes sociales” y miramos cuál es la estimación de este requisito (por
ejemplo, seis días persona).
En lugar de estimar el nuevo requisito de cero por cualquier otra técnica, por comparación
podemos decir que también tendrá un coste de unos seis días/persona de desarrollo.
Días/persona
Los días/persona o días/hombre son otra forma de aproximar la duración de un requisito:

1 día/persona representa el trabajo que una persona hace en 1 día de 8 horas (sean ideales
o reales).
Así, un requisito estimado en 3 días/persona implica que una persona sola tardaría 3 días
en implementar el requisito.
Hay que tener en cuenta, sin embargo, que esto no quiere decir necesariamente que tres
personas lo implementen en 1 día. Cómo dice el dicho: “Nueve mujeres no hacen un
hijo en 1 mes”.
A menudo, es muy difícil encontrar un requisito del mismo tamaño y se usa

la técnica de triangulación para aproximar el coste del requisito. En este caso,
en lugar de comparar con un solo requisito, comparamos con dos: uno más
grande y otro más pequeño. Como estamos incorporando más información al
cálculo (ya no dependemos de una sola estimación, sino que dependemos de
dos), el resultado es más fiable que en el caso anterior.
Supongamos de nuevo que queremos estimar el requisito “El usuario tiene que poder
compartir el plan de viaje en las redes sociales”.
Si quisiéramos aplicar la técnica de triangulación, lo que haríamos sería encontrar uno

más pequeño (como por ejemplo, “El usuario tiene que poder consultar los datos de su
viaje”, 3 días/persona de trabajo) y uno más grande (como por ejemplo, “El usuario tiene
que poder identificarse en el sistema con las credenciales de las redes sociales a través del
protocolo OAuth”, 13 días/persona) y determinaríamos la relación respecto a estos dos:
“El usuario tiene que poder compartir el plan de viaje en las redes sociales” es el doble
de grande que “El usuario tiene que poder consultar los datos de su viaje” (3 × 2 = 6) y,
al mismo tiempo, es la mitad que “El usuario tiene que poder identificarse en el sistema
con las credenciales de las redes sociales a través del protocolo OAuth”) (13/2 = 6,5). Por
lo tanto, tomaremos como valor de la estimación 6 días/persona.
2.3.2. Estimación colaborativa: planning poker
Una manera de paliar el problema de la información incompleta es hacer uso

de las técnicas colaborativas de estimación, como por ejemplo, el planning
poker.
Mediante la estimación colaborativa, las diferentes personas involucradas en

la estimación comparten su conocimiento sobre el problema que hay que so-
lucionar, así como sobre el espacio posible de soluciones.
La estimación es mucho más fiable si participan en ella los desarrolladores que

tienen que implementar el requisito, puesto que son quienes mejor conocen
el espacio posible de soluciones. Como efecto colateral, el equipo de desarrollo
estará mucho más comprometido con una estimación que ellos mismos hayan
hecho que no con una estimación que les venga dada.
La técnica del planning poker, propuesta por James Grenning en el 2002, recibe Lectura recomendada
su nombre del hecho de que, igual que en el juego del póquer, cada persona
El artículo original de James
hace su estimación sin saber cuál será la estimación de los demás (y, de hecho, Grenning llevaba por título
a menudo se hace con una baraja de cartas especial). “Planning Poker or How to
avoid analysys paralysis whi-
le release planning”.
En una sesión de planning poker se reúne a un grupo de personas y se reparte a
cada participante un conjunto de cartas con los diferentes valores acordados
como posibles para las estimaciones.
Para estimar un requisito concreto, se comenta en voz alta el requisito para

que todo el mundo trabaje con la misma información. A continuación, cada
participante escoge una carta y la pone encima de la mesa boca abajo de ma-
nera que el resto de participantes no puedan ver el valor elegido.
Una vez que todos los participantes han elegido su carta, se descubren los
valores. En el caso de no coincidir, los participantes vuelven a hablar para
entender el motivo de la diferencia de criterio y se vuelve a repetir el paso
anterior hasta que se llega a una coincidencia en las diferentes estimaciones.
El diálogo que se produce antes de estimar el requisito, así como el que se

produce en caso de no coincidencia es el que nos permite paliar el problema
de la información incompleta. Por este motivo es muy importante que, en el
caso de no coincidir en las estimaciones, los participantes no se limiten a hacer
una media de las diferentes estimaciones, sino que hablen y vuelvan a estimar
hasta que todo el mundo coincida en el mismo valor.
2.4. Estimación de requisitos no funcionales
La estimación de cada requisito mediante las técnicas descritas es bastante cla-

ra para los requisitos funcionales que se van implementando de forma indivi-
dual. ¿Cómo se estiman, sin embargo, los requisitos no funcionales?
Algunos de estos requisitos no funcionales son locales a alguno o algunos re-

quisitos funcionales (es decir, solo afectan a un requisito funcional o a un nú-
mero reducido de ellos). Estos se consideran restricciones sobre el requisito
funcional y, por lo tanto, se tienen en cuenta a la hora de estimar el requisito
funcional, pero no se estiman por sí mismos.
Por ejemplo, si tenemos el requisito funcional “Publicar el plan de viaje en la red social
X”, podría ser que esta red nos obligara a cumplir algún requisito no funcional, como
por ejemplo, “cuando se publica algo en la red social, tenemos que enviar la petición de
publicación, la red nos enviará una petición de confirmación a una dirección predefinida
y, si la confirmamos, la publicará. Esta petición de confirmación tiene un tiempo máximo
de un segundo (y si en un segundo no se ha confirmado, se descartará la petición de
publicación)”.
En este caso, el tiempo de respuesta de la confirmación es un requisito local, puesto que

sólo afecta a la publicación en esta red en cuestión y, por lo tanto, lo podemos incorporar
a la estimación de tamaño del requisito “Publicar el plan de viaje en la red social X”.
Otros requisitos no funcionales son globales (es decir, afectan a todos los re-
quisitos funcionales o a la mayor parte de estos). Estos, de nuevo, se tendrán
en cuenta como restricciones que pueden tener efecto sobre qué soluciones
son válidas para resolver un requisito funcional y, por lo tanto, afectarán a las
estimaciones de los requisitos funcionales, pero no se estiman por sí mismos.
Supongamos, por ejemplo, que tenemos un requisito no funcional de rendimiento, que

dice que el sistema tiene que dar respuesta a cualquier consulta en menos de 2 segundos.
Este requisito será global y se tendrá en cuenta a la hora de estimar cualquier requisito
funcional, puesto que puede afectar a la estimación, haciéndola más costosa de imple-
mentar.
En algunos casos, sin embargo, un requisito no funcional puede requerir al-

guna tarea de desarrollo que se puede incluir en la lista de requisitos del pro-
ducto. En este caso, el requisito no funcional tiene una estimación propia y
es un requisito más a tener en cuenta.
Supongamos que tenemos un requisito que consiste en adaptar el diseño ya existente

para que la funcionalidad ya implementada también satisfaga este requisito. Esta tarea
vendrá dada por el propio requisito no funcional y, por lo tanto, el requisito no funcional
también tendrá que ser estimado y tenido en cuenta durante el resto del proceso de
gestión de requisitos.
3. Priorización y selección de requisitos
Otro elemento básico para decidir si un requisito formará parte o no del con-
junto de requisitos del software desarrollado es el valor que aporta. El valor
aportado es siempre una medida relativa al resto de requisitos y depende, como
hemos dicho anteriormente, de los stakeholders (diferentes stakeholders pueden
tener percepciones diferentes del valor de un requisito).
Supongamos que queremos estimar el valor del requisito “Una agencia tiene que poder
vender productos que no sean de Viajes UOC”. Para Dolores Sánchez (propietaria de una
agencia de viajes franquiciada) es muy importante que el sistema cumpla este requisito,
pero en cambio, para Sonia Cases (directora de marketing de Viajes UOC) es muy impor-
tante que no lo cumpla.
Terminología
Denominamos priorización de los requisitos al proceso mediante el
cual ordenamos por prioridad los requisitos. Como el factor principal pa-
ra determinar la prioridad de
un requisito es el valor relativo
(siendo más prioritarios aque-
llos que aportan más valor),
La priorización de requisitos es un elemento clave de la planificación de cual- a menudo se usa la expresión
quier proyecto, especialmente si seguimos el ciclo de vida incremental, puesto priorización de requisitos en re-
ferencia al proceso mediante el
que la priorización de requisitos nos dice en qué orden tenemos que ir imple- cual estimamos este valor rela-
tivo.
mentando las diferentes funcionalidades.
La selección�de�requisitos consiste en seleccionar, finalmente, cuál de los re- Ved también

quisitos candidatos incorporaremos al producto y cuál descartaremos.
Repasad la asignatura Ingenie-
ría del software.
Más allá de los conflictos evidentes, a menudo es muy difícil para los stakehol-
ders renunciar a un requisito que les aporta valor pero que no ha sido seleccio-
nado. Por este motivo, hay técnicas que nos ayudan a establecer la prioridad
relativa de los requisitos. A continuación veremos algunas de estas técnicas.
Hay que advertir que todas las técnicas que veremos tienen su origen en algún
método de desarrollo y, por eso, a veces la nomenclatura puede no ser cohe-
rente entre distintas técnicas. A la hora de estudiarlas, pues, es importante fi-
jarse en la finalidad de la técnica más que la nomenclatura.
Así, del mismo modo que sabemos que cuando hablamos del backlog de producto este
Ved también
término es habitual en los métodos ágiles para dar nombre a la lista de historias de usuario
pendientes de implementar, también podemos aplicar el mismo concepto a las listas de
requisitos o a los casos de uso. Muchas de estas técnicas se pueden combinar con las Veremos qué es el backlog de
técnicas descritas en otros métodos de desarrollo. producto en el subapartado
3.3 de este módulo.
Hemos clasificado las técnicas que estudiaremos en dos grupos: por un lado,
las relacionadas con la gestión de productos de software, que ven el producto
como un todo y están relacionadas con otras disciplinas diferentes a la inge-
niería de requisitos propiamente dicha. Por otro lado, las que hemos denomi-
nado “técnicas de priorización”, más enfocadas a, dado un conjunto concreto
de requisitos, determinar la prioridad relativa entre ellos.
3.1. Gestión de productos de software
Para establecer la prioridad de los requisitos, tenemos que tener en cuenta,

además del coste y el valor, otros factores relacionados con la gestión del pro-
ducto de software, como por ejemplo, cuál es la oportunidad de mercado, cuál
es el objetivo que se quiere lograr, etc.
Por este motivo, es importante que conozcamos algunas de las herramientas

básicas de la gestión de productos antes de estudiar las técnicas concretas que
usaremos para priorizar los requisitos.
3.1.1. La visión del producto
La visión del producto es la herramienta básica para asegurar que la colabora-

ción entre los diferentes stakeholders y los desarrolladores sea fructífera, pues-
to que nos asegura que todos los actores implicados comparten los mismos
objetivos y avanzan en la misma dirección: la que nos lleva hacia la materia-
lización de la visión del producto.
La visión del�producto describe por qué se está llevando a cabo el desa-

rrollo y cuál es el estado final deseado.
La visión del producto nos ayuda a determinar cómo queremos que sea el pro- Lectura recomendada
ducto que desarrollaremos y, por lo tanto, nos ofrece un primer criterio de
Podéis ver la obra Agile Pro-
priorización: son más prioritarios aquellos requisitos que nos ayudan a mate- duct Management with Scrum,
rializar la visión del producto. de Roman Pichler.
Más concretamente, la visión del producto tendría que poder responder las
siguientes preguntas:
• ¿A quién va dirigido el producto? ¿Quién lo comprará? ¿Quién lo usará?
• ¿Qué necesidad o qué oportunidad cubre? ¿Cuál es el valor añadido del

producto?
• ¿Qué atributos del producto son críticos para su éxito? ¿Cómo será, a gran-
des rasgos, el producto?
• ¿Cómo se compara el producto con los demás productos existentes? ¿Qué

es lo que lo hace diferente?
• ¿Cómo se recuperará la inversión? ¿Cuáles serán las fuentes de ingresos

que generará el producto?
• ¿Es factible pensar que lo podremos desarrollar y amortizar?
Esta visión, sin embargo, no tiene que ser un documento formal, sino, ideal- Lectura recomendada
mente, una frase que condense toda esta información. Jim Highsmith nos su-
Podéis ver el artículo “Pro-
giere esta plantilla: duct Vision”, de Jim Highs-
mith.
Para <clientes potenciales> que <explicación de la necesidad o de la oportuni-

dad>, el <nombre del producto> es un <categoría del producto> que <benefi-
cio clave, razón principal para la compra>. Al contrario que <principal alter-
nativa con la que compite el producto>, nuestro producto <explicación de la
diferenciación principal>.
En el caso del nuevo sistema de ventas de viajes, de Viajes UOC, podríamos usar la si-
guiente visión de producto:
Para las agencias de viajes que quieren vender viajes por Internet, el nuevo sistema es
un sistema de ventas que permite interactuar con los clientes a través de Internet. Al
contrario que el sistema actual, nuestro producto permite un modelo mixto entre compra
en línea y compra en la agencia.
La finalidad de la visión del producto es ayudarnos a mantener una lí-

nea coherente durante todo el proceso de desarrollo y asegurarnos de
que todos los actores implicados en el desarrollo (stakeholders y desarro-
lladores) avanzan en una misma dirección.
Para poder conseguir esto, es importante que la visión sea compartida y unifi-
cadora. Si la visión no es compartida, cada stakeholder (y también los desarro-
lladores) avanzará en una dirección diferente y se despilfarrarán los esfuerzos.
Es importante, pues, que todos los actores implicados en el desarrollo estén
comprometidos con la misma visión.
La visión del producto también tiene que dar margen para la creatividad in-
dividual. Una visión de producto demasiado restrictiva limita la capacidad de
las personas de implicarse en su consecución.
Finalmente, la visión del producto tiene que ser breve y concisa. Un ejemplo
es la llamada “prueba del ascensor”: tenemos que poder explicar la visión del
producto en el tiempo que se tarda en subir a la oficina en el ascensor. Es im-
portante resaltar los atributos clave del producto y no hacer una lista completa
de funcionalidades.
En este sentido, Jim Highsmith nos recuerda que “encontrar 15 o 20 caracte-

rísticas para un producto es fácil. Lo que es realmente difícil es decidir cuáles
son las 3 o 4 que harán que se decida comprar el producto”.
Jim Highsmith nos recomienda la técnica de “diseñar la caja” para encontrar

la visión del producto. Esta técnica consiste en hacer grupos de entre 4 y 6 per-
sonas (idealmente de varios perfiles) y, asumiendo que el producto se venderá
empaquetado en una caja, diseñarla por delante y por detrás. En la parte de
delante estará el nombre del producto, una ilustración y tres o cuatro puntos
que ayuden a “vender” el producto. En la parte de atrás, habrá una descripción
más detallada del producto, así como los requisitos.
Lo más habitual es que equipos diferentes acaben con cajas muy diferentes, lo
cual es un buen punto de partida para una discusión que ayude a identificar la
visión del producto y a conseguir que esta sea compartida por todo el mundo.
3.1.2. Producto mínimo entregable
Otra herramienta de gestión de productos es el producto mínimo entregable:

el producto mínimo entregable es el producto con la funcionalidad mínima
que cumple las necesidades de unos clientes concretos.
El producto mínimo entregable es el producto mínimo que cumple la

visión del producto.
Por lo tanto, los requisitos que forman parte del mismo son los que aportan
más valor y, en un desarrollo incremental, son los requisitos que priorizaría-
mos.
Entregar un producto de mínimos nos permite experimentar con el mercado

potencial y reaccionar en función de su respuesta en lugar de tener que pre-
decir su comportamiento. También nos ayuda a minimizar las pérdidas en el
supuesto de que el producto no tenga éxito y haya que cancelar su desarrollo.
Un buen ejemplo de producto mínimo es el teléfono móvil iPhone. Cuando se presentó

en el 2007, carecía de muchas de las funcionalidades que eran habituales en otros pro-
ductos de la competencia, como copiar y pegar texto o mandar un mensaje SMS a un
grupo de destinatarios.
A cambio de estas limitaciones, Apple pudo introducir el producto en el mercado antes

que la competencia (siendo, por ejemplo, uno de los primeros teléfonos en tener una
pantalla táctil capacitiva que cubriera casi toda la superficie del teléfono).
Más adelante, Apple pudo reaccionar al mercado e introducir las características que el
mercado realmente quería, como la tienda de aplicaciones, creando un nuevo mercado
capaz de mover miles de millones de dólares.
La experimentación con el mercado se tiene que hacer de manera organizada, Ciclo de Deming
siguiendo un proceso de cuatro etapas conocido como el “ciclo de Deming”:
El ciclo de Deming, de Edward
Deming, es una estrategia de
1)�Planificar�(plan). Establecemos una hipótesis (por ejemplo, que los clientes mejora continua de la cali-
dad, basada en los cuatro pa-
están interesados en pagar por Internet). sos aquí mencionados. Inspira-
da en el método científico de
Francis Bacon, esta estrategia
es aplicable a la mejora de la
2)�Hacer�(do). Implementamos la versión más básica de la funcionalidad para calidad de cualquier producto
sacarla al mercado y ver cómo reacciona este. También se podría aplicar a la o servicio y, por lo tanto, no es
exclusiva del software.
creación de modelos de la interfaz de usuario o prototipo, de modo que no
hubiera que implementar la funcionalidad completa (reduciendo así el coste
del experimento).
3)�Verificar�(check). Verificamos el resultado del experimento y determinamos

si ha tenido éxito o no. ¿Era correcta la hipótesis de partida? Si no lo era,
¿podemos determinar cuál era el error?
4)� Actuar� (act). Decidimos cuál será nuestro siguiente paso en función de
cómo haya ido el experimento. En caso de que no haya tenido suficiente éxito,
este paso podría ser el de eliminar la funcionalidad del producto, modificarla
para que funcione de manera diferente, desarrollarla algo más o probar algo
radicalmente diferente.
La ventaja de este proceso es que nos permite trabajar con información em-
pírica (datos que hemos recogido a través de un experimento) y no con supo-
siciones.
3.1.3. User-story mapping
Esta técnica nos ayuda a determinar cuáles son los requisitos que tienen que
formar parte del mínimo producto entregable. Se basa en la idea de organizar
las funcionalidades en dos dimensiones: el eje vertical determina la importan-
cia (grado de necesidad) de una funcionalidad concreta mientras que el eje
horizontal se utiliza para situar las funcionalidades de importancia similar al
mismo nivel.
Una columna de un mapa de historias incluye todas las tareas relacionadas

con una funcionalidad concreta ordenadas por prioridad. En la parte superior
están las más necesarias para cumplir la visión del producto mientras que en
la parte inferior están las menos necesarias.
Una fila de un mapa de historias incluye todas las tareas que tienen un nivel
de importancia similar. No implementaremos ninguna funcionalidad de una
fila del mapa hasta que no hayamos implementado todas las funcionalidades
de las filas superiores.
La principal ventaja de esta técnica es que permite maximizar el valor obteni-

do por el desarrollo, puesto que, al hacer el recorrido de la tabla a lo ancho,
evitamos situaciones en las que tenemos una funcionalidad muy desarrollada
pero otra igual de importante sin empezar.
3.2. Técnicas de priorización
En este subapartado, como indicamos, presentamos aquellas técnicas que, en

lugar de ver el producto como un todo, se centran en determinar la prioridad
relativa de los requisitos en un conjunto de requisitos determinado.
3.2.1. La técnica de los 100 dólares
La técnica de los 100 dólares (Leffingwell y Widrig, 2000) consiste en dar 100
dólares imaginarios a cada uno de los stakeholders y decirles que los repartan
entre los diferentes requisitos. Idealmente, cada stakeholder repartirá sus dóla-
res entre los requisitos según el valor de cada uno. Así, si un requisito es muy
importante, se le asignarán muchos dólares para asegurarse de que salga esco-
gido, mientras que si no lo es, se le asignarán menos (o ninguno).
De este modo daremos prioridad a aquellos requisitos que, o bien son muy
importantes para alguna de las partes (que habrá puesto una gran cantidad
de dólares para asegurarse de que el sistema cumple ese requisito) o bien son
importantes para muchas de las partes implicadas (y, por lo tanto, por acumu-
lación de pequeños importes al final consiguen sumar un importe elevado).
Supongamos, por ejemplo, que tenemos que priorizar estos tres requisitos:
• El cliente tiene que poder ver quién ha hecho una recomendación.

• El cliente tiene que poder compartir el plan de viaje en las redes sociales.
• El cliente tiene que poder pagar por transferencia bancaria.
Si nos piden, individualmente, si tenemos que incluir o no cada uno de los requisitos,
la respuesta será, probablemente, que sí.
En cambio, si nos dicen que sólo tenemos dos votos y que los tenemos que repartir entre
todos los requisitos, nos veremos obligados a decidir cuál de los tres es menos importante.
Si además añadimos que otros stakeholders también votarán, es probable que, incluso, nos
planteemos dar los dos votos al mismo requisito para asegurarnos de que salga escogido
(sólo en el supuesto de que este requisito sea realmente más importante que los otros).
3.2.2. Prioridades limitadas
Uno de los problemas que nos podemos encontrar a la hora de priorizar los
requisitos es decidir la prioridad relativa de requisitos que no tienen ninguna
relación entre ellos.
¿Es más prioritario mostrar la foto del hotel en la ficha de detalle de un hotel o mostrar
con un símbolo gráfico si una recomendación es positiva o negativa?
Para ahorrarnos largas discusiones sobre si una funcionalidad es, por ejemplo, Lectura recomendada
de prioridad 25 o 26, muchos métodos recomiendan limitar el número de
Podéis ver la obra Crystal
prioridades posibles. Así, Alistair Cockburn nos propone clasificar los diferen- Clear: A Human-Powered Met-
tes requisitos de un sistema en sólo tres categorías: hodology for Small Teams, de
Alistair Cockburn.
• Sacrificar otros requisitos por este.

• Intentar mantener.
• Sacrificar este requisito por otros.
Siguiendo esta clasificación, si decidimos que la facilidad de uso tiene la prio-

ridad de “Sacrificar otros por este”, salir al mercado lo antes posible tiene la
prioridad de “Intentar mantener”, y rendimiento tiene la prioridad de “Sacri-
ficar por otros”, estamos diciendo que estamos dispuestos a retrasar la salida
del producto al mercado a cambio de mejoras en la facilidad de su uso, pero
no a cambio de su rendimiento.
Otro ejemplo de prioridades limitadas es el llamado MoSCoW (el acrónimo

viene de los nombres de las prioridades que propone) propuesto por el método
DSDM (dynamic systems development method), donde, para cada iteración, se
decide qué requisitos son:
• Musthave (sin estos requisitos la iteración es un fracaso).
• Shouldhave (son igual de importantes que los musthave, pero podemos pa-
sar sin ellos temporalmente).
• Couldhave (también denominados nice to have en el sentido de que su pre-

sencia incrementa la satisfacción del cliente a pesar de ser menos priori-
tarios).
• Won’t have (no entran en la iteración actual y, por lo tanto, de momento

no los tenemos en cuenta).
3.2.3. El modelo Kano
El modelo Kano es una teoría de desarrollo de productos orientada a la satis-

facción del cliente. La finalidad de este modelo es predecir el nivel de satisfac-
ción del cliente (para poderlo maximizar) en función de cuáles sean las carac-
terísticas presentes en el producto.
Así pues, este modelo nos ayudará a determinar cuáles de las características
del producto (es decir, qué requisitos) son más importantes para garantizar el
éxito del producto desarrollado (y, por lo tanto, más prioritarias).
En la figura siguiente podemos ver tres líneas, que corresponden a las llamadas
características básicas, lineales y apasionantes.
Las características básicas son aquellas que el cliente espera del producto. Tam-
bién se las conoce como características obligatorias puesto que, si carece de
alguna de estas, el cliente considerará el producto incompleto. Su presencia,
en cambio, no aumenta significativamente la satisfacción del cliente.
Los clientes de Viajes UOC considerarán la posibilidad de buscar un hotel a partir del
nombre de la ciudad donde quieren ir como una funcionalidad básica, en el sentido de
que, si no pueden hacer la búsqueda, creerán que nuestro producto está incompleto y su
satisfacción será muy baja. En cambio, por muy bien que implementemos la búsqueda de
hotel a partir del nombre de la ciudad, es difícil que consigamos incrementar significati-
vamente su satisfacción más allá de cierto punto. Es por esto que, en la figura anterior,
la flecha correspondiente a las características básicas acaba plana.
El segundo grupo que encontramos, las lineales (en inglés, performance featu-
res) se caracterizan por tener una relación lineal entre la presencia de la carac-
terística y el nivel de satisfacción del cliente (“cuanto más, mejor”).
En el caso de Viajes UOC, la amplitud de la base de datos de hoteles y destinos podría ser
una característica lineal: cuanto más amplia sea la selección de hoteles y destinos más
satisfechos estarán nuestros clientes.
Hay, sin embargo, un tercer grupo de características: las apasionantes. Mien-

tras que las características lineales nos permiten lograr un buen nivel de satis-
facción del cliente, normalmente son características que el cliente espera del
producto. Por lo tanto, pueden no ser suficientes para hacer que el producto
destaque entre las alternativas. Las características apasionantes son las más di-
fíciles de encontrar, ya que se trata de encontrar una necesidad que el cliente
todavía no sabe que tiene; precisamente esto es lo que hace que aumente tanto
el nivel de satisfacción.
Poder compartir el plan de viaje en las redes sociales podría ser una característica “apa-
sionante” del nuevo sistema de ventas de Viajes UOC si consideramos que es una carac-
terística que los clientes no esperan, pero que, cuando esté implementada, utilizarán con
asiduidad. Sin embargo, el problema con este tipo de características es, tal como hemos
dicho antes, que hasta que no las ponemos en manos de los clientes no podemos saber
si son o no apasionantes.
El modelo Kano hace una predicción interesante: a lo largo del tiempo, las
características apasionantes se convierten en lineales y las lineales, en básicas,
por lo cual, con el paso del tiempo hay que revisar la clasificación de las dife-
rentes características.
Un ejemplo representativo de este hecho es la inclusión de la cámara de fotos en los

teléfonos móviles. En su momento, era una característica apasionante que distinguía
los teléfonos que la incorporaban del resto. En cambio, con el tiempo su presencia se
fue normalizando hasta convertirse en una característica lineal (cuanta más resolución
mejor) y, más adelante, en una característica básica: se espera de cualquier teléfono móvil
que incorpore una cámara de fotos y, si no la incorpora, consideramos que tenemos un
producto incompleto.
Lo que nos enseña este modelo es que, para maximizar la satisfacción de los
clientes, no basta con preguntar a los stakeholders qué esperan del producto
a desarrollar, sino que tenemos que hacer propuestas innovadoras que nos
permitan destacar positivamente.
La finalidad del modelo Kano es poder encontrar el punto de equilibrio

que nos permita combinar características básicas, lineales y apasionan-
tes de manera que maximicemos la satisfacción del cliente.
Clasificar un requisito concreto según el modelo Kano no es fácil, puesto que

lo que nos parece apasionante a nosotros puede dejar indiferente al resto. Por
eso, es importante poder contar con la opinión de los usuarios potenciales del
producto, habitualmente a través de un cuestionario.
El problema con los cuestionarios es que podemos perder información. Por

ejemplo, en el caso de la cámara en el teléfono móvil, seguramente si hubiéra-
mos preguntado si creíamos que era importante tener una cámara en el móvil,
hubiéramos contestado que no, pero esto no significa que esta característica
no fuera deseable.
Mike Cohn nos propone un tipo de cuestionario diseñado para evitar estos Lectura recomendada
problemas y que consiste en hacer dos preguntas al usuario potencial: una
Podéis ver la obra Agile Esti-
preguntando qué le parecería disponer de una característica y otra (en forma mating and Planning, de Mike
“disfuncional”) preguntando qué le parecería no disponer de la misma. La Cohn.
combinación de estas dos preguntas es la que nos dice cómo tenemos que
clasificar la característica.
En el caso de Viajes UOC, podríamos hacer a nuestros clientes potenciales dos preguntas:
“¿Qué piensas de tener la posibilidad de compartir el plan de viaje en las redes sociales?”
y dar cinco respuestas posibles: “Me gusta”, “Era de esperar”, “Me es indiferente”, “Puedo
convivir con esto” (con el hecho de poder compartir el plan de viaje) o “No me gusta”.
Después podemos hacer la pregunta de manera disfuncional: “¿Qué piensas de no tener

la posibilidad de compartir el plan de viaje en las redes sociales?” y dar las mismas cinco
opciones.
A partir de la información obtenida podemos cruzar las respuestas con las dos preguntas
para decidir dónde situamos el requisito en cuestión:
Esta figura introduce tres nuevos tipos de característica: contraria (el usua-
rio quiere la característica contraria a la propuesta), cuestionable (no tenemos
muy claro dónde clasificarla) e indiferente (no afecta a la satisfacción del clien-
te).
Finalmente, hay que agregar los resultados obtenidos de los diferentes clientes
para decidir en qué categoría clasificamos cada requisito. Podemos recoger los
resultados estadísticos y clasificar los requisitos según la distribución de las
respuestas:
Característica A L B I C Q Categoría
Generar el plan de viaje 10% 12% 52% 8% 10% 8% Básica
Compartir el plan de viaje 40% 20% 20% 10% 5% 5% Apasionante
Pagar en la agencia 2% 11% 15% 40% 7% 25% Indiferente
Amplitud de la base de datos de hoteles 6% 33% 32% 12% 0% 17% Lineal/Básica
3.2.4. A/B testing
La técnica A/B testing es una técnica que nos permite evaluar dos opciones (A y
B) para decidir cuál es más atractiva para los usuarios del software o más eficaz
para conseguir un objetivo concreto.
Esta técnica se basa en el siguiente proceso:
1) Se deciden cuáles son las dos alternativas (por ejemplo, dos maneras de
compartir el plan de viaje).
2) Se establece una manera de determinar la eficacia de cada métrica (por ejem-

plo, cuántos usuarios han compartido el plan de viaje con cada opción con-
creta).
3) Exponer un subconjunto de los usuarios a la opción A y otro a la B y medir.
A partir de los datos recogidos podemos ver fácilmente cuál de las dos alter-
nativas es más eficaz para conseguir nuestro objetivo de que los usuarios com-
partan su plan de viaje en Internet.
Esta técnica se usa mucho en desarrollo web, donde, por ejemplo, A es el diseño
actual de la aplicación/lugar web y B es el nuevo diseño. Se distribuye el tráfico
de usuarios entre las dos versiones y se recoge la medida de la métrica decidida.
Por ejemplo, supongamos que Viajes UOC se está planteando el diseño de la página
principal de la aplicación web y queremos decidir dónde situaremos el formulario de
inscripción.
Lo que haremos será dividir a los usuarios en dos grupos: al grupo A le mostraremos una
distribución de elementos y al grupo B otra:
A continuación, medimos el número de altas con la versión A y el número de altas con

la versión B y seleccionamos la versión que obtenga un número mayor de altas. Así, por
ejemplo, si el grupo A ha obtenido un 30% de altas y el grupo B un 60%, nos quedaremos
con la opción B.
Una prueba A/B se hace, pues, con un objetivo concreto, como por ejemplo
incrementar el número de inscripciones o incrementar la ratio de ventas por
visita.
Con este objetivo presente, se plantean diferentes alternativas (diferentes ubi-

caciones de los elementos del diseño, demanda de más o menos datos duran-
te el proceso de inscripción, etc.) y se lleva a cabo la prueba. Algunas de las
características que se prueban normalmente son:
• Diseño gráfico (colores, textos, ubicación de los diferentes elementos en

la pantalla) del elemento que tiene que usar el usuario para llevar a cabo
la acción concreta (botón de “Comprar”, botón de “Registrarse”, etc.).
• En general, los diferentes textos, tanto a nivel de títulos como de descrip-

ciones de los productos.
• Longitud de los formularios y tipos de campos de los formularios.
• Precio del producto y/o promociones especiales.
• Relación entre texto e imágenes en las pantallas.
Es importante probar las dos alternativas en el mismo momento del tiempo,

puesto que, de no hacerlo así, es posible que en las decisiones de los usuarios
influyan otros factores.
Por otro lado, como en cualquier estudio estadístico, es importante acumular Casos de estudio
una muestra significativa (es decir, no finalizar la prueba demasiado pronto),
En Smashing Magazine pode-
puesto que, de lo contrario, es posible que las conclusiones a las que lleguemos mos encontrar unos cuantos
no sean correctas. Hay que tener en cuenta, sin embargo, que tampoco es casos de estudio, como por
ejemplo el de 37 signals, don-
conveniente alargar demasiado el estudio, ya que, mientras tanto, tenemos de la combinación ganado-
ra consiguió un 30% más de
un porcentaje significativo de los usuarios usando una versión del software usuarios que la versión origi-
nal.
que tiene un rendimiento peor que la otra (por ejemplo, la ratio de ventas por
visita es menor).
También hay que evitar confusiones a los usuarios y mostrar una versión con-
sistente a cada persona. Un caso típico de error de A/B testing es aquel en el
que una persona puede ver dos precios diferentes para un mismo producto en
visitas diferentes de una tienda on-line. En este caso, esta diferencia generará
desconfianza y puede afectar negativamente a las ventas. En la misma línea,
hay que aplicar las variaciones a toda la aplicación. Por ejemplo, si estamos
probando colores para el botón de “Comprar”, es importante que, para una
persona en concreto, el botón en cuestión se muestre siempre del mismo co-
lor, que no se muestre de un color en una pantalla y de otro color en otra.
3.3. Selección de requisitos: El backlog del producto
El resultado de la selección de requisitos candidatos es una lista de los requisi- Ved también
tos priorizados y estimados que se tendrán en cuenta para el proyecto. Scrum,
Scrum es un método ágil de
uno de los métodos ágiles más populares, da el nombre de backlog de produc- desarrollo. Podéis repasarlo en
to a esta lista. Nosotros usaremos el mismo término para referirnos a ella. Así la asignatura Ingeniería del soft-
ware.
pues:
El backlog es una lista priorizada de trabajo pendiente para finalizar el

proyecto de desarrollo.
El contenido más habitual de un backlog son los requisitos funcionales. Habi- Ved también
tualmente, en los proyectos ágiles, estos requisitos se documentan en forma
En el módulo “Documentación
de historia de usuario; pero también se pueden documentar en forma de ca- de requisitos” veremos técni-
so de uso o utilizando cualquier otra técnica de documentación de requisitos cas de documentación de re-
quisitos, como por ejemplo, las
funcionales. historias de usuario o los casos
de uso.
Además, pero, un backlog tiene que incluir los requisitos no funcionales y, en

general, cualquier otra tarea necesaria para finalizar el proyecto, como por
ejemplo, tareas de preparación del entorno, tareas de lanzamiento, etc.
Denominamos entrada� de� backlog a cada uno de los elementos que

forman un backlog de producto, ya sean historias de usuario, casos de
uso, otros requisitos funcionales o no funcionales o tareas que hay que
hacer.
De hecho, no es necesario que todas las entradas del backlog sean homogéneas.
Podríamos tener un backlog donde se describen los requisitos funcionales co-
mo historias de usuario y donde también se describe un requisito de usabili-
dad, por ejemplo, mediante un pequeño esbozo a mano alzada de las pantallas.
Pichler dice que, además de estar estimado y priorizado, un buen backlog tiene Lectura recomendada
que tener las cualidades de estar detallado apropiadamente y de ser emergente.
Podéis ver la obra Agile Pro-
duct Management with Scrum,
Un backlog está priorizado, habitualmente, porque las entradas que contiene de Roman Pichler.
se ordenan de más a menos prioridad. En algunos casos, sin embargo, puede

ser útil etiquetar cada entrada con un número o descripción que indique la
prioridad.
Un backlog está estimado porque todas las entradas están estimadas de tal
modo que, para cada una, tenemos una estimación del coste de desarrollo que
aquella entrada implica.
Un backlog está detallado�apropiadamente cuando usa niveles de detalle di-

ferentes para las entradas que contiene (y el nivel de detalle es el adecuado
para cada entrada).
Un backlog es emergente porque puede evolucionar a medida que cambia el Ved también
conocimiento que tenemos sobre las necesidades de los stakeholders y las tareas
Veremos con más detalle las
que hay que hacer en cada momento. características d’un blacklog en
el apartado 4 de este módulo.
3.3.1. Requisitos no funcionales y el backlog
La dinámica del backlog consiste en una lista ordenada de requisitos y otras

tareas que se van consumiendo a medida que se desarrollan. ¿Cómo encajan
aquí los requisitos no funcionales?
Los requisitos no funcionales típicamente se documentan en el backlog en for-

ma de restricciones.
Así, por ejemplo, el requisito de que todas las pantallas de la aplicación tienen que mos-
trar el logo de Viajes UOC es una restricción, puesto que nos limita a la hora de imple-
mentar las pantallas.
Como hemos visto anteriormente, podemos distinguir entre requisitos no fun-

cionales locales y globales. Los requisitos no funcionales locales expresan res-
tricciones que afectan a un pequeño conjunto de los requisitos funcionales,
mientras que los requisitos globales afectan a gran parte o a todos los requisi-
tos funcionales.
El ejemplo antes mencionado, que indica que todas las pantallas tienen que tener el
logo de Viajes UOC, es evidentemente un requisito global. De manera parecida, también
podemos considerar que el requisito de que el sistema sea utilizable sin red es global.
En cambio, el requisito que nos indica que hay que guardar constancia de todos los acce-
sos a información personal de los clientes solo afectará a aquellos requisitos funcionales
que incluyan acceso a este tipo de datos.
Los requisitos no funcionales locales se considerarán, generalmente, parte del

requisito o requisitos funcionales a los cuales afectan. Así, cuando se haya
implementado el requisito funcional correspondiente y se consuma, también
daremos por consumida la restricción asociada. Los podemos considerar, por
lo tanto, anotaciones adicionales a la historia de usuario o caso de uso que
documente el requisito funcional.
Los requisitos no funcionales globales, sin embargo, no se pueden considerar

“implementados” y, por lo tanto, no se consumen. De hecho, cada vez que se
finaliza una iteración, habrá que satisfacer estos requisitos, pero siguen estan-
do presentes para la siguiente iteración.
Como están fuera de la lista de prioridades que vamos consumiendo al imple-

mentar el sistema, los requisitos no funcionales globales, a los que también
podemos denominar restricciones del sistema, se documentan, habitualmen-
te, en un apartado separado del backlog de producto.
3.3.2. El backlog y otros documentos de requisitos
El uso de un backlog no excluye al equipo de usar cualquier otro documento de Ved también
requisitos complementario que considere necesario. Así, además del backlog,
Veremos las técnicas de docu-
un equipo puede usar un modelo del dominio en forma de diagrama de clases mentación de requisitos en el
UML, esbozos de las pantallas a mano alzada, mapas navegacionales para in- módulo “Documentación de
requisitos”.
teracciones elaboradas entre el usuario y el sistema en forma de diagramas de
estados UML, o cualquier otro artefacto que sea útil para comunicar requisitos.
4. Gestión de los cambios en los requisitos
A pesar de que la situación ideal para el desarrollo del software sería partir de
un conjunto de requisitos estable y definitivo, la realidad es que esto sucede
en muy pocas ocasiones. Los motivos por los cuales cambian los requisitos son
muy diversos y hay que tenerlos en cuenta durante el desarrollo.
4.1. Factores de cambios en los requisitos
Dean Leffingwell y Don Widrig nos proporcionan una lista bastante extensa Lectura recomendada
de factores de cambio en los requisitos, y distinguen entre factores externos e
Podéis ver la obra Managing
internos al propio proceso de desarrollo. Software Requirements, de
Dean Leffingwell y Don Wi-
drig.
Los factores externos son aquellos sobre los cuales el equipo de desarrollo no
tiene ningún control. Por lo tanto, no hay nada que el equipo pueda hacer
para evitarlos y se tiene que organizar y planificar teniéndolos en cuenta como
una parte normal del proceso de desarrollo. Estos factores externos pueden ser:
• Cambios en el problema que estamos solucionando debidos a modifica-

ciones en la economía, regulaciones (aparición de nuevas leyes) o cambios
en el mercado (cambios en las preferencias de los clientes o la aparición
de un nuevo competidor).
• Cambios en la opinión de los clientes respecto a lo que quieren, como por

ejemplo, si cambiamos de interlocutor (debido a que nuestro interlocutor
deja el trabajo o cambia de departamento) y el nuevo interlocutor tiene
una idea diferente.
• Cambios en el entorno, como la aparición de nuevas tecnologías que ha-

cen que los requisitos sobre un sistema cambien (por ejemplo, al aparecer
la red Internet, muchas empresas se encontraron con la necesidad de dar
acceso remoto a sus aplicaciones, necesidad que antes no existía).
• Cambios debido al hecho de que los usuarios, al usar el software, se han

dado cuenta de que este no acaba de satisfacer del todo sus necesidades.
Estos factores, a pesar de no poder evitarse, pueden gestionarse como parte

del proceso de desarrollo de software, ya sea intentándolos congelar (como es
el caso del método en cascada) u organizando el desarrollo de manera que el
impacto de los cambios sea mínimo (como es el caso de los métodos ágiles).
Por otro lado, Leffingwell y Widrig también identifican factores internos de

cambio, como por ejemplo, no haber efectuado correctamente el proceso de
ingeniería de requisitos (no haber hecho correctamente la obtención de requi-
sitos o haber priorizado los requisitos equivocados) o no haber gestionado co-

rrectamente los cambios que se han ido detectando (por ejemplo, intentando
congelar los requisitos hasta que los cambios acumulados son demasiado im-
portantes como para ignorarlos).
4.2. Los cambios en el backlog
En el apartado anterior hemos dicho que una de las propiedades deseables de

un backlog es que este tiene que ser emergente; es decir, que ante los cambios
tenemos que poder añadir, modificar o eliminar entradas en los requisitos. Esto
es debido a que, como acabamos de ver, no podemos evitar completamente la
aparición de cambios en el software.
Cuando los requisitos cambien, habrá que añadir, modificar o eliminar entra-
das del backlog para reflejar estos cambios. Así, cuando se descubran nuevos
requisitos habrá que añadirlos como entradas en el backlog (estimándolos y
priorizándolos). Si un requisito cambia, puede ser necesario reestimarlo o re-
priorizarlo. Finalmente, podemos descubrir que un antiguo requisito deja de
serlo y habrá que eliminar la entrada de backlog pertinente.
Por todos estos motivos es importante dedicar cierto tiempo en cada iteración
a revisar y mantener el backlog, añadiendo, quitando o modificando las entra-
das que haga falta a medida que los diferentes factores de cambio (sean inter-
nos o externos) provoquen cambios en los requisitos o en la estimación de su
coste o valor.
Además, el backlog tiene que reflejar el trabajo hecho hasta ahora en el desa-
rrollo. Si una entrada de backlog ha sido ya desarrollada y verificada, se elimi-
nará del backlog e, inmediatamente, la siguiente entrada más prioritaria pasa-
rá a ocupar su lugar. Así, a medida que completamos entradas, las que eran
menos prioritarias van ganando prioridad relativa, en el sentido de que van
avanzando hacia arriba en la lista y pasan a ocupar las primeras posiciones.
Por otro lado, también hemos dicho que el backlog tenía que estar detallado
apropiadamente. La finalidad de esto es no dedicar esfuerzos a las entradas
que tienen más probabilidades de sufrir cambios (las menos prioritarias, que
son las que están más lejanas en el tiempo).
Así, las entradas más prioritarias tienen que ser requisitos con objetivos de
más bajo nivel, de granularidad más fina. Estas son entradas que se tendrán en
cuenta antes. A medida que tienen menos prioridad, las entradas tienen que
tener niveles de objetivo más generales, tienen que tener una granularidad
más gruesa.
Supongamos, por ejemplo, que tenemos en el backlog de Viajes UOC el requisito “Com-
prar un viaje por Internet”. Si este no fuera un requisito priotario, quedaría así, sin de-
tallar, en el backlog hasta que fuera más prioritario y se descompusiera en requisitos de
nivel de usuario, como por ejemplo “Ver información sobre un destino” o “Hacer el pago
de un viaje”.
Se dice que el backlog tiene que tener forma de iceberg, donde la parte de
arriba contiene las entradas sobre las que estamos trabajando actualmente,
pequeñas, de granularidad muy fina, y la parte de abajo, a medida que nos
alejamos de la punta, contiene entradas de granularidad cada vez más gruesa,
con menos nivel de detalle y, por lo tanto, más grandes.
El objetivo de esta manera de detallar el backlog es no destinar demasiado tiem-

po a detallar unas entradas de backlog que aún no se usarán porque no son
suficientemente prioritarias. A medida que se van consumiendo entradas de
backlog, se van descomponiendo, y detallando cada vez solo las entradas más
prioritarias que quedan en el backlog.
5. Caso práctico
En este apartado se ponen en práctica algunas de las técnicas que hemos visto a
lo largo del módulo. Para hacerlo, explicamos una historia ficticia sobre cómo
se llevó a cabo, en la práctica, parte de la planificación del desarrollo de Viajes
UOC. En esta historia intervienen los siguientes personajes:
• Alberto y Cristina, dos desarrolladores.

• Marta, especialista en experiencia de usuario.
• Luisa, product manager.
5.1. Visión del producto
Cuando Luisa recibió de la dirección de Viajes UOC el encargo de convertirse

en la product manager de la nueva plataforma de esta agencia, lo primero que
hizo fue redactar la visión del producto:
“Para las agencias de viajes que quieren vender viajes por Internet, Viajes UOC 2.0 es un
sistema de ventas que permite conseguir nuevos clientes a través de Internet sin renunciar
a su negocio tradicional (clientes de la agencia). Al contrario que el sistema actual, nuestro
producto permite un modelo mixto entre compra on-line y compra en la agencia.”
Es importante que tengamos presente esta visión a lo largo de todo el proceso

que seguiremos a continuación.
5.2. Obtención de requisitos candidatos
Una de las áreas funcionales que se tuvo en cuenta es la de la presentación de

información sobre los destinos. En concreto, se hizo una sesión de brainstor-
ming y surgieron las siguientes historias de usuario candidatas:
Descripción�textual
Como cliente, quiero ver la información que hay sobre un destino.
Como agente de viajes, quiero añadir una opinión sobre un destino.
Como cliente, quiero hacer una pregunta sobre un destino.
Como cliente, quiero recibir una alerta cada vez que se publique nueva información sobre
un destino.
Como cliente, quiero solicitar un chat en directo con un agente de viajes.
Como comercial, quiero hacer una oferta de viaje a un destino concreto.
Como usuario, quiero recibir una alerta cuando haya una oferta de viaje a un destino
concreto.
Como propietario de agencia, quiero poder hacer ofertas a usuarios concretos.

Como cliente, quiero solicitar un chat en directo con otros usuarios interesados en este
destino.
Como cliente, quiero comparar precios con otras agencias de viajes virtuales.
5.3. Estimación de los requisitos
Para estimar el tamaño de los requisitos, Alberto, Cristina, Marta y Luisa se

reunieron para llevar a cabo una sesión de estimación colaborativa.
Como Alberto y Cristina son quienes están más familiarizados con la técnica
del planning poker, Alberto es quien se encargó de explicar a Marta y a Luisa el
funcionamiento del planning poker y de los puntos de historia.
“Como no podemos estimar el volumen absoluto de trabajo que nos supondrá

este nuevo desarrollo, de momento nos conformaremos con estimar el coste
relativo de las diferentes historias de usuario y, para eso, usaremos los puntos
de historia. El único significado de los puntos de historia es que una historia
de 2 puntos es el doble de complicada de implementar que una de 1 punto (y
la mitad que una de 4 puntos)”.
5.3.1. Estimación de la primera historia
“Para la primera historia se nos presenta el problema de que no tenemos con

qué compararla y, por lo tanto, es difícil hacer la estimación. De momento
nos conformaremos con saber si es una de las grandes (complicadas) o de las
pequeñas (sencillas), y estimaremos el resto de historias basándonos en esta”.
“Empezaremos, si os parece bien, por ‘Como cliente, quiero ver la información

que hay sobre un destino’”. “¿Cuál es esta información?” preguntó Marta. “Es
importante saber cuál es la información a mostrar si tengo que pensar en cómo
quedaría en la pantalla”. Cristina añadió: “y para mí es muy importante saber
cuál es esta información puesto que me servirá para saber a cuántas fuentes
de datos tendré que acceder”.
Luisa respondió “La información sobre un destino es un conjunto de elemen-

tos multimedia (fotos, etc.), el nombre y ubicación del destino, las opiniones
que haya al respecto, así como las preguntas y respuestas que se hayan hecho
sobre el destino. Las opiniones incluyen el nombre de la persona que ha ex-
presado la opinión así como una valoración cualitativa en forma de comenta-
rio”. Dicho esto, Alberto propuso al resto si querían hacer más preguntas, y
como ya nadie tenía dudas procedieron a la primera ronda de estimación.
Para hacer la estimación, como solo Alberto, Cristina y Marta tendrán que
llevar a cabo las diferentes tareas, solo ellos estimarán el volumen de trabajo
que habrá que realizar. La primera ronda de estimaciones quedó de la siguiente
manera:
Persona Primera ronda
Alberto 5
Cristina 8
Marta 13
“¿Cómo puede ser esto?” preguntó Luisa. “Tranquila, es normal, puesto que
se trata de la primera historia y la primera ronda, y es probable que no todos
tengamos lo mismo en mente” respondió Alberto, “empezaré yo explicando
por qué creo que es un 5: me da la impresión de que esta funcionalidad es
de las más sencillas que tenemos para implementar, ya que solo se tienen que
consultar datos y mostrarlos por pantalla y, por lo tanto, un número mayor
hará que todo el resto de estimaciones quede demasiado grande. De todos
modos, creo que Marta ha considerado algunos factores que yo he ignorado y
por eso hay tanta diferencia. ¿Es posible?”.
Marta añadió: “Yo creo que es una de las funcionalidades más complicadas,
al menos para mí, puesto que es la pantalla más importante de la aplicación
y habrá que hacer pruebas de usabilidad antes de decidir el diseño definitivo.
Por lo tanto, no se trata sólo de programar las consultas, sino de hacer dos
o tres propuestas alternativas de organización de la información, probarlas y
entonces decidir con cuál nos quedamos”. Alberto respondió: “visto así, veo
que había subestimado el trabajo. De todos modos, ¿este problema no lo ten-
dremos con todas las funcionalidades?”. “No” respondió Marta, “sólo en esta,
que es la más importante”. “Entendido, si Cristina no tiene ninguna pregunta
más, podemos proceder a la segunda ronda”.
Persona Primera ronda Segunda ronda
Alberto 5 8
Cristina 8 8
Marta 13 13
“Yo continúo pensando que es una funcionalidad muy complicada y que trae-
rá mucho trabajo y un 8 me parece muy poco” dijo Marta. “Pero ten en cuenta
que esto es una estimación relativa” respondió Alberto, “un 8 puede ser mu-
cho o poco, ya veremos, en función del resto, pero piensa que una funciona-
lidad que sea el doble que esta será un 26 y, por lo tanto, cuatro veces esta será
ya prácticamente imposible de estimar. ¿Tan complicado es?”. “Sí. No habrá
ninguna más que sea cuatro veces esta, pero sí que tendremos algunas que
serán la cuarta parte”. “Entendido, volvemos a estimar”.
Persona Primera ronda Segunda ronda Tercera ronda
Alberto 5 8 13
Persona Primera ronda Segunda ronda Tercera ronda
Cristina 8 8 13
Marta 13 13 13
“Muy bien, ya tenemos consenso. Tomaremos como referencia esta historia

con 13 puntos”.
5.3.2. Estimación de las siguientes historias
Alberto explicó “La segunda historia es ‘Como agente de viajes, quiero añadir
una opinión sobre un destino’. Luisa nos dará los detalles”. “En este caso,
se trata de permitir que el agente de viajes pueda añadir una opinión sobre
un destino. La opinión es un texto donde explica su punto de vista y si es
positivo o negativo”. Marta preguntó: “si el agente ya ha opinado sobre el
destino, ¿tiene que poder editar la opinión que ya había dado?” “Sí”, respondió
Luisa. “¿Y puede llegar a tener dos? ¿O si vuelve a opinar tiene que modificar
forzosamente la que ya tenía?” preguntó Alberto. “Buena pregunta” dijo Luisa
“yo creo que es mejor que un agente sólo haya podido dar una opinión y si
la quiere modificar, que desaparezca la anterior”. “Entendido” dijo Alberto,
“procedemos, pues, a la estimación. Recordad que 13 puntos para la historia
anterior es la referencia”.
Persona Primera ronda
Alberto 5
Cristina 5
Marta 5
“Muy bien. Parece que esta vez hay consenso a la primera” dijo Alberto. “De
ahora en adelante ya podemos triangular (comparad con esta que son 5 y con
la anterior que son 13)”.
5.4. Priorización de los requisitos
Para la priorización de los requisitos se llevó a cabo otra reunión donde estaban
presentes las siguientes personas:
• Juan, un agente de viajes.

• Sonia, directora de marketing.
• Dolores, propietaria de una agencia.
• Ramón, ingeniero de requisitos.
Ramón les dijo, “queremos hacer un desarrollo incremental. Por lo tanto, que-
remos empezar por las funcionalidades más importantes. Os propongo aplicar
la técnica de los 100 dólares para que tengamos una idea de cuáles son estas
funcionalidades más críticas. Por si no la conocéis, la técnica de los 100 dó-

lares consiste en que cada uno de vosotros tiene 100 dólares de presupuesto
que puede repartir como quiera entre las diferentes funcionalidades. Al final
sumaremos el importe asignado a cada funcionalidad y las ordenaremos por
puntos. Las funcionalidades a considerar son:
1: Como cliente, quiero ver la información que hay sobre un destino.
2: Como agente de viajes, quiero añadir una opinión sobre un destino.
3: Como cliente, quiero hacer una pregunta sobre un destino.
4: Como cliente, quiero recibir una alerta cada vez que se publique nueva
información sobre un destino.
5: Como cliente, quiero solicitar un chat en directo con un agente de viajes.
6: Como comercial, quiero hacer una oferta de viaje a un destino concreto.
7: Como usuario, quiero recibir una alerta cuando haya una oferta de viaje a
un destino concreto.
8: Como propietario de agencia, quiero poder hacer ofertas a usuarios concre-

tos.
9: Como cliente, quiero solicitar un chat en directo con otros usuarios intere-
sados en este destino.
10: Como cliente, quiero comparar precios con otras agencias de viajes virtua-
les.
Avisadme cuando hayáis repartido los puntos.”
1 2 3 4 5 6 7 8 9 10
Juan 100
Sonia 10 10 10 10 20 10 10 10 10
Dolores 20 20 30 30
Total 30 110 30 10 20 40 10 40 10
En este caso, como Juan había puesto todos sus puntos en la misma funciona-
lidad, esta fue considerada la más prioritaria, mientras que Sonia, que aplicó la
estrategia contraria (repartir al máximo su voto) se encontró con que su voto
(por repartido) era prácticamente irrelevante.
5.5. Selección de requisitos
Como el requisito número 10 (“Como cliente, quiero comparar precios con

otras agencias de viajes virtuales”) no lo votó nadie, se decidió descartarlo y
no incorporarlo al backlog.
Finalmente, el backlog priorizado quedó así (tened en cuenta que en caso de

empate se ha optado por ordenar sobre la base de otro criterio que ahora no
viene al caso).
Cost
Como agente de viajes, quiero añadir una opinión sobre un destino. 5
Como comercial, quiero hacer una oferta de viaje a un destino concreto. 20
Como propietario de agencia, quiero poder hacer ofertas a usuarios concretos. 20
Como cliente, quiero hacer una pregunta sobre un destino. 3
Como cliente, quiero ver la información que hay sobre un destino. 13
Como cliente, quiero solicitar un chat en directo con un agente de viajes. 100
Como cliente, quiero recibir una alerta cada vez que se publique nueva información sobre un destino. 3
Como usuario, quiero recibir una alerta cuandohaya una oferta de viaje a un destino concreto. 3
Como cliente, quiero solicitar un chat en directo con otros usuarios interesados en este destino. 100
Resumen
Hemos visto que la gestión de requisitos es el proceso mediante el cual deci-

dimos cuáles de los requisitos candidatos de nuestro software implementare-
mos. Para tomar esta decisión, necesitamos estimar, como mínimo, el coste
y la prioridad.
La prioridad de un requisito vendrá determinada, principalmente, por el valor

aportado por el mismo, pero también por el conocimiento aportado o el riesgo
que podamos eliminar implementándolo.
También hemos visto que podemos simplificar el proceso de estimación del

coste de un requisito si nos limitamos a estimar el “tamaño” (medida arbitra-
ria de la complejidad relativa de este requisito comparado con el resto de es-
tos) usando unidades ficticias, como por ejemplo, los puntos de usuario. Una
escala como por ejemplo la serie de Fibonacci, además, nos permite ajustar
la precisión del valor estimado a nuestra capacidad de predecir con exactitud
este valor (ya que tiene menos precisión a medida que aquello que estamos es-
timando es más “grande”). También hemos visto que esta estimación se puede
hacer de manera colaborativa con la técnica del planning poker.
Para estimar la duración de un proyecto podemos usar la velocidad, que es la

medida de las unidades de estimación (puntos de historia) que completamos
en un periodo concreto (una iteración). Una de las ventajas de la velocidad es
que se puede medir empíricamente a partir del final de la primera iteración.
En cuanto al valor, hemos visto cómo la visión del producto nos ayuda a ase-
gurarnos de que todos los actores implicados en un desarrollo están alineados
en la misma dirección. También nos ayuda a determinar cuál es el conjunto
mínimo de requisitos que tenemos que implementar (el producto mínimo en-
tregable) para satisfacer la necesidad de nuestros clientes.
Para el resto de requisitos hemos visto técnicas, como las prioridades limitadas
(MoSCoW), los 100 dólares, el modelo Kano o las pruebas A/B, que nos ayudan
a encontrar cuáles son los requisitos más prioritarios dentro de una lista.
Finalmente, hemos hablado del backlog de producto (la lista priorizada de tra-
bajo pendiente para finalizar el proyecto de desarrollo) y de cómo este tiene
que evolucionar y cambiar frecuentemente a medida que evoluciona nuestro
conocimiento de las necesidades de los stakeholders.
Actividades
1. Supongamos que estamos practicando la estimación de tamaño y que nos piden estimar
el peso de los siguientes animales en “puntos de peso de animal”: un ciervo, una ardilla, un
elefante, un ratón, un zorro, un jabalí y un topo. Calculad una estimación relativa de pesos.
a) Hacedla estimación sin mirar el peso real de ningún animal.

b) Hacedla estimación suponiendo que un jabalí pesa unos 90 kg.
2. Supongamos que estamos calculando una estimación colaborativa mediante la técnica del
planning poker y nos encontramos con esta situación:
Juan: 5, Alberto: 5, María: 5, Pol: 5, Luisa: 20
a) ¿Cuál es el valor de la estimación que tenemos que tomar en este caso?

b) ¿Y si fuera Juan: 1, María: 5, Pol: 10?
3. En el módulo 1 describimos CrowdArt, una plataforma de crowdfunding de proyectos artís-

ticos donde los artistas proponen proyectos y los usuarios (a los que denominamos mecenas)
hacen aportaciones económicas a los mismos. Cada proyecto tiene un plazo determinado
para conseguir la financiación mínima y, sil lega al plazo, se hace el cobro a los usuarios y
se transfiere el importe al artista. Las aportaciones se hacen sobre la base de una serie de
recompensas que ofrece el artista (por ejemplo, por 10 € figurará su nombre en el programa
de la obra de teatro, por 20 € le regalamos una entrada y por 100 € se lo agradeceremos
públicamente el día del estreno).
Nos han pedido que les ayudemos a priorizar los requisitos mediante el modelo Kano. Con-
cretamente, los requisitos a considerar son:
• Que el artista pueda añadir una foto a un proyecto.

• Que el artista pueda añadir un vídeo a un proyecto.
• Que el artista pueda añadir un audio a un proyecto.
• Poder cancelar una aportación si todavía no se ha llegado a la fecha tope.
• Añadir nuevas recompensas a un proyecto que ya ha empezado a pedir financiación.
• Modificar las recompensas de un proyecto aunque algún mecenas ya se haya comprome-
tido (por ejemplo, habíamos dicho que regalaríamos una entrada y una camiseta pero
ahora nos lo hemos pensado mejor y sólo queremos regalar la entrada).
• Poder reducir el límite de la financiación solicitada una vez iniciado el proceso si vemos
que no podremos llegar a tiempo.
• Transferir el dinero al artista aunque no se llegue al mínimo.
a) Diseñad un cuestionario para pasar a los usuarios potenciales (tanto artistas como mece-
nas), que nos ayude a clasificar los requisitos según el modelo Kano (básico, lineal, apasio-
nante, contrario, cuestionable o indiferente).
b) Supongamos que hemos pasado el cuestionario de la solución al apartado a a 10 artistas y

hemos obtenido el resultado que se muestra en la siguiente tabla, ¿cuáles son los requisitos
que tenemos que priorizar? ¿Hay alguno que tengamos que descartar? ¿Por qué?
A1 A2 A3 A4 A5 A6 A7 A8 A9 A10
P1 A A E E E E E E E E
P2 N N N N N N I N P P
P3 I A A A E A E A E A
P4 E N E E I N I I N P
P5 E P I E A N E I E I
P6 P E E I E E P I I I
P7 E E P E P P I E P E
P8 A A E A E A I A A E
P9 E I I I E E I P I E
G=Me gusta, E=Era de esperar, I=Indiferente, P=Puedo vivir con esto, N=No me gusta
A1 A2 A3 A4 A5 A6 A7 A8 A9 A10
P10 N E N E N N P I N P
P11 A A E E I A P A A P
P12 I E A A A E A P P A
P13 I A A E A A I A I E
P14 N N N I N N P N E P
G=Me gusta, E=Era de esperar, I=Indiferente, P=Puedo vivir con esto, N=No me gusta
Ejercicios de autoevaluación
1. ¿Cuáles son los cuatro factores básicos de la gestión de requisitos?
2. ¿Cuál es la principal ventaja de estimar el tamaño de los requisitos respecto a estimar la

duración?
3. ¿Qué es la velocidad de un equipo de desarrollo? ¿Para qué sirve?
4. ¿Por qué motivo se usa la serie de Fibonacci para estimar el tamaño de los requisitos?
5. ¿Qué hay que hacer en una sesión de planning poker si no hay consenso entre las diferentes
estimaciones?
6. ¿Cuál es la finalidad de la visión del producto?
7. ¿Cuál es la principal ventaja de la técnica user story mapping?
8. ¿Qué son las características básicas según el modelo Kano?
9. ¿Qué dice el modelo Kano respecto a la evolución de la percepción de las características

de un producto a lo largo del tiempo?
10. ¿Qué es el backlog de producto?
11. ¿A qué nos referimos cuando decimos que el backlog de un producto es emergente?
12. ¿Qué queremos decir cuando decimos que el backlog tiene que estar detallado apropia-
damente?
Solucionario
Actividades
1. Esta es solo una de las posibles soluciones al ejercicio. Lo que es importante no es tanto
el resultado final como el proceso mediante el cual se ha llegado al mismo. También es in-
teresante reflexionar sobre la precisión de las estimaciones y sobre la relación entre margen
de error y magnitud estimada.
a) El primer paso es elegir un animal como punto de referencia. Un animal de peso intermedio
es el zorro, al cual le podemos asignar 10 puntos. A partir de aquí, estimamos el resto de
animales:
Animal Puntos
Ciervo 100
Ardilla 1
Elefante 1.000
Ratón 0
Zorro 10
Cerdo jabalí 100
Topo 5
Podemos observar los siguientes hechos interesantes: debido a la enorme diferencia de peso
entre los diferentes animales de la lista no hemos podido aplicar la serie de Fibonacci y hemos
tenido que estimar en órdenes de magnitud. De aquí podemos extraer una primera conclu-
sión: “Es muy difícil estimar en una misma escala elementos de medida muy diferente”.
b) En este apartado, podríamos volver a revisar nuestras estimaciones o bien partir de las
estimaciones anteriores y calcular el peso del resto de animales a partir del dato del jabalí:
Animal Estimación (puntos) Peso estimado Peso real
Ciervo 100 90 kg 70-150 kg
Ardilla 1 0,9 kg 0,2-0,3 kg
Elefante 1.000 900 kg 5.000-6.000 kg
Ratón 0 0 kg 0,01-0,03 kg
Zorro 10 9 kg 4,5-8,5 kg
Cerdo jabalí 100 90 kg 60-120 kg
Topo 5 4,5 kg 0,2 kg
Podemos observar los siguientes hechos interesantes:
• La estimación del ciervo era bastante acertada, probablemente debido a que tiene un
peso bastante similar al del jabalí.
• El peso de la ardilla, sin embargo, está bastante sobrestimado, debido, en parte, a la escala
utilizada. Como no hemos querido usar decimales, teníamos que elegir entre 0 gr y 1kg,
demasiada diferencia si tenemos en cuenta la escala de peso en la que nos movemos. Por
lo tanto, tendríamos que introducir los decimales en la escala o bien usar una unidad
más pequeña.
• El peso del elefante, en cambio, está subestimado por un motivo similar, a pesar de que,
en este caso, es posible que el error de estimación sea debido, en parte, a la carencia de
referencias intermedias con las que comparar (el animal que más se acerca al peso real
del elefante es unas 50 veces menos pesado).
• El zorro y el ratón están bastante aproximados pero el topo no (ni mucho menos). En este
caso, es evidente que la persona que hizo la estimación creía que un topo es un animal
bastante más grande delo que realmente es. En este caso, una estimación colaborativa
nos hubiera ayudado a detectar este déficit de información.
2. En los dos casos, hay que volver a discutir la funcionalidad hasta llegar a un consenso.
No es válido ni descartar una de las estimaciones por ser diferente del resto ni hacer una
media de las estimaciones, puesto que el hecho de que no haya consenso quiere decir que es
probable que no todo el mundo esté trabajando con la misma información.
3.
a) El cuestionario tiene que tener, para cada requisito, dos preguntas: Una en forma “fun-
cional” (qué pasa si se dispone de esta funcionalidad) y una “disfuncional” (qué pasa si no
se dispone de esta funcionalidad). Para cada una de estas preguntas, tenemos que dar cinco
respuestas posibles: “Me gusta”, “Era de esperar”, “Me es indiferente”, “Puedo convivir con
esto” y “No me gusta”. Por lo tanto, un posible cuestionario sería:
1. “¿Qué te parecería que el artista pudiera añadir una foto a un proyecto?”
2. “¿Qué te parecería que no hubiera la posibilidad de que los artistas pudieran añadir fotos
a los proyectos?”
3. “¿Qué te parecería que el artista pudiera añadir un vídeo a un proyecto?”
4. “¿Qué te parecería que no hubiera la posibilidad de que los artistas pudieran añadir vídeos
a los proyectos?”
5. “¿Qué te parecería que el artista pudiera añadir un audio a un proyecto?”
6. “¿Qué te parecería que no hubiera la posibilidad de que los artistas pudieran añadir audios
a los proyectos?”
7. “¿Qué te parecería que un mecenas pudiera cancelar una aportación a un proyecto si

todavía no se ha llegado a la fecha tope?”
8. “¿Qué te parecería que un mecenas no pudiera cancelar una aportación a un proyecto a

pesar de que todavía no se hubiera llegado a la fecha tope?”
9. “¿Qué te parecería que el artista pudiera añadir nuevas recompensas a un proyecto que ya
ha empezado a solicitar financiación?”
10. “¿Qué te parecería que el artista no pudiera añadir nuevas recompensas a un proyecto
una vez este ha empezado a solicitar financiación?”
11. “¿Qué te parecería que el artista pudiera modificar las recompensas de un proyecto aun-
que algún mecenas ya se haya comprometido a hacer una aportación a cambio de aquella
recompensa?”
12. “¿Qué te parecería que el artista no pudiera modificar las recompensas de un proyecto si
algún mecenas ya se ha comprometido a hacer una aportación a cambio de aquella recom-
pensa?”
13. “¿Qué te parecería que el artista pudiera reducir el límite de la financiación solicitada
antes de la fecha tope si ve que no llega?”
14. “¿Qué te parecería que el artista no pudiera reducir el límite de la financiación una vez
se ha empezado a solicitar?”
b) El primer paso para aplicar el modelo Kano es ver cómo ha clasificado cada artista cada
uno de los requisitos según la tabla de cruces del subapartado 3.2.3.
A1 A2 A3 A4 A5 A6 A7 A8 A9 A10
R1 L L B B B B I B I I
R2 I L A A I L I A B A
R3 I I I I A C I I I I
R4 C C I C I C I C C I
R5 B I B I B B I I B I
R6 A A C C C A C A A C
R7 L L L I L L I L I I
L=Lineal, B=Básico, I=Indiferente, A=Apasionante
A partir de esta información, calculamos la frecuencia de cada clasificación:
Q A L C I B
R1 0 0 2 0 3 5
R2 0 4 2 0 3 1
R3 0 1 0 1 8 0
R4 0 0 0 6 4 0
R5 0 0 0 0 5 5
R6 0 5 0 5 0 0
R7 0 0 6 0 4 0
Según esta tabla, el primer requisito (“poder añadir una foto a un proyecto”) ha sido clasifi-
cado, mayoritariamente, como básico, mientras que el segundo (“poder añadir un vídeo”) lo
ha sido como apasionante y el tercero (“poder añadir un audio”), como indiferente.
El cuarto (“poder cancelar una aportación”) ha sido clasificado como “contrario” (es decir,
que resta valor). El quinto (“poder añadir recompensas una vez iniciado el proceso de finan-
ciación”) en cambio, presenta división de opiniones: tenemos el mismo número de artistas
que lo consideran indiferente que de artistas que lo consideran básico.
El sexto requisito (“modificar las recompensas”) también presenta división de opiniones en-
tre “apasionante” y “contrario”, lo cual demuestra que tenemos un problema importante de
división y que, por lo tanto, lo deberíamos clasificar como “cuestionable”.
Finalmente, el séptimo (“poder reducir el límite de financiación”) lo consideraremos lineal.
Por lo tanto, la prioridad relativa es:
“Poder añadir una foto”, puesto que es básico y sin esta posibilidad el producto está incom-
pleto.
“Poder añadir un vídeo”, puesto que, como requisito apasionante, nos permitirá diferenciar
nuestro producto. En cuanto a prioridad, este requisito competiría con el de “poder añadir
recompensas una vez iniciado el proceso de financiación”, puesto que si lo consideramos
básico será más prioritario, pero si lo consideramos indiferente lo será menos.
“Poder reducir el límite de financiación” vendría a continuación como requisito lineal que es.
“Poder añadir un audio” es indiferente y, por lo tanto, ya veremos si se implementa o no.
“Poder cancelar una aportación” es un requisito que tenemos que descartar, puesto que se
ha clasificado como contrario.
Finalmente, no hemos podido decidir qué hacer con el requisito “poder modificar las recom-
pensas una vez iniciado el proceso de financiación”, puesto que tenemos tanto opiniones
a favor como en contra. Lo mejor será, pues, preguntar a más artistas o, mejor todavía, pre-
guntar a los mecenas qué piensan.
Ejercicios de autoevaluación
1.�Los cuatro factores básicos de la gestión de requisitos son: valor, coste, conocimiento y
riesgo. Ver el subapartado 1.1.
2.�La principal ventaja es que la persona o personas que hacen la estimación solo tienen que
fijarse en un concepto: el tamaño, y no tienen que tener en cuenta factores como el estado
anímico del equipo, riesgos que se pueden materializar, etc. Ver el subapartado 2.1.
3.�La velocidad es una medida del progreso de un equipo por unidad de tiempo y sirve para
estimar la duración de un proyecto a partir del tamaño de sus requisitos. Ver el subapartado
2.1.
4.�A medida que los requisitos tienen granularidad más gruesa, serán más grandes y difíciles
de estimar por comparación y, por lo tanto, la precisión será menor. La serie de Fibonacci
nos ayuda a reflejar este hecho. Ver el subapartado 2.2.
5.�En el caso de no coincidir, los participantes vuelven a hablar para entender el motivo de
la diferencia de criterio. Ver el subapartado 2.3.2.
6.�La visión del producto describe por qué se está llevando a cabo el desarrollo y cuál es el
estado final deseado. Ver el subapartado 3.1.1.
7.� La principal ventaja de esta técnica es que permite maximizar el valor obtenido por el
desarrollo, puesto que, al hacer el recorrido de la tabla en anchura, evitamos situaciones
en las que tenemos una funcionalidad muy desarrollada pero otra igual de importante sin
empezar. Ver el subapartado 3.1.3.
8.�Las características básicas son aquellas que el cliente espera del producto (...). Si carece de
alguna de estas, el cliente considerará el producto incompleto. Su presencia, en cambio, no
aumenta significativamente la satisfacción del cliente. Ver el subapartado 3.2.3.
9.�A lo largo del tiempo, las características apasionantes se convierten en lineales y las lineales,
en básicas, por lo cual hay que revisar la clasificación de las diferentes características con el
paso del tiempo. Ver el subapartado 3.2.3.
10.�El backlog es una lista priorizada de trabajo pendiente para finalizar el proyecto de desa-
rrollo. Ver el subapartado 3.3.
11.�Un backlog es emergente porque puede evolucionar a medida que cambia el conocimiento
que tenemos sobre las necesidades de los stakeholders y las tareas a hacer en cada momento.
Ver el subapartado 3.3.
12.�Un backlog está detallado apropiadamente cuando usa niveles de detalle diferentes para
las entradas que contiene (y el nivel de detalle es el adecuado para cada entrada). Ver el
subapartado 3.3.
Glosario
A/B testing m Técnica empírica de priorización de requisitos que consiste en implementar
dos requisitos alternativos (A y B), establecer una métrica que determine cuál de los dos tiene
más éxito y exponer a un subconjunto de los usuarios al requisito A y otro subconjunto al B.
backlog m Lista priorizada de trabajo pendiente para finalizar el proyecto de desarrollo.
comparación f Técnica de estimación consistente en buscar otro requisito ya estimado y

establecer el coste del requisito a estimar en función de coste del requisito estimado.
estimación (de requisitos) f Consiste en etiquetar los requisitos con un valor que dé
una idea de cómo afecta al coste total del proyecto la inclusión de aquel requisito.
gestión de requisitos f Proceso mediante el cual decidimos cuáles de los requisitos can-
didatos formarán parte del conjunto definitivo de requisitos.
Kano (modelo) m Teoría de desarrollo de productos orientada a la satisfacción del cliente,

que tiene como finalidad poder predecir el nivel de satisfacción del cliente en función de
cuáles sean las características presentes en el producto.
planning poker m Técnica de estimación colaborativa donde cada persona hace su esti-
mación sin saber cuál será la estimación de los demás.
priorización de requisitos f Proceso mediante el cual establecemos la prioridad relativa

de los requisitos del software.
producto mínimo entregable m Producto con la funcionalidad mínima, que cumple

las necesidades de unos clientes concretos.
puntos de historia m pl Unidad ficticia de estimación de tamaño de requisitos.
requisito candidato m Requisito que todavía no hemos decidido si tendremos o no en

consideración a la hora de desarrollar el software.
tamaño (de un requisito) f Dimensión de estimación relativa que no tiene en cuenta la

duración, sino la complejidad y los riesgos que comporta implementar un requisito.
triangulación f Técnica de estimación consistente en buscar un requisito de coste superior

y uno de coste inferior al requisito en cuestión y establecer el coste definitivo del requisito
en función de estos dos costes estimados.
velocidad (de un equipo de desarrollo) f Magnitud que mide el progreso de un equipo

por unidad de tiempo (típicamente en puntos de historia por iteración).
visión (del producto) f Punto de vista que describe por qué se está llevando a cabo el
desarrollo y cuál es el estado final deseado.
Bibliografía
Bibliografía principal
Cohn, Mike (2006). Agile estimating and planning. Prentice Hall Professional Technical Re-
ference.
En esta obra Mike Cohn ofrece un conjunto de herramientas ágiles y prácticas para la estima-
ción, priorización y planificación en entornos ágiles. A pesar de que está bastante centradaen
las historias de usuario, las herramientas que da son totalmente aplicables a cualquier forma
de documentación de requisitos.
Bibliografía complementaria
Leffingwell, D. (2010). Agile Software Requirements. Lean Requirements Practices for Teams,
Programs, and the Enterprise. Addison-Wesley.
La obra de Leffingwell presenta un enfoque ágil a la ingeniería de los requisitos. En el apartado

de priorización de requisitos documenta el modelo Kano.
Cohn, Mike (2006). I Didn’t Know I Needed That! Finding Features to Satisfy Your Customers.
Better Software – StickyMinds.com.
Mike Cohn explica en este artículo el modelo Kano de forma sencilla y con ejemplos prác-
ticos.
Pichler, Roman (2010). Agile Product Management with Scrum. Creating Products that Custo-
mers Love. Addison-Wesley.
Ken Shcwaber (2009). Agile Project Management with Scrum. O’Reilly Media, Inc.
Cockburn, Alistair (2005). Crystal clear: A Human-Powered Methodology for Small Teams.
Addison-Wesley.
Referencias bibliográficas
Chopra, Paras. The Ultimate Guide to A/B Testing. http://

www.smashingmagazine.com/2010/06/24/the-ultimate-guide-to-a-b-testing/ (última visita:
febrero del 2012).
Highsmith, Jim (23, agosto, 2001). “Design The Box”, “Agile Project Management E-mail
Advisor”. Se encuentra a través del post “Product Vision”, del blog de Joel Spolsky.
Cockburn, Alistair (2008). Walkingskeleton. http://alistair.cockburn.us/Walking+skeleton

(última visita: febrero del 2012).

Gestion de Requisitos

Cargado por

Información del documento

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Gestion de Requisitos

Cargado por

Copyright:

Formatos disponibles

Gestión de

Jordi Pradel Miquel

1. Factores que hay que considerar para la gestión de

3. Priorización y selección de requisitos.......................................... 17

4. Gestión de los cambios en los requisitos..................................... 32

5.4. Priorización de los requisitos ...................................................... 38

A diferencia de la obtención de requisitos, donde el énfasis está en encontrar

Empezaremos viendo una introducción general a la gestión de requisitos y a

Finalmente, hablaremos de la gestión de los cambios en los requisitos y de

El objetivo principal de este módulo es dar a conocer al estudiante las herra-

1. Saber crear una lista priorizada y estimada de requisitos candidatos.

1. Factores que hay que considerar para la gestión de

En los módulos anteriores nos hemos centrado en obtener el máximo número

Denominamos gestión�de�requisitos al proceso mediante el cual deci-

1.1. Factores básicos para la gestión de requisitos

Para tomar esta decisión necesitamos más información de la que disponemos

A la hora de seleccionar los requisitos, tenemos que tener en cuenta cua-

Tomamos como ejemplo la autenticación de usuarios en el nuevo sistema de

En cambio, el coste de desarrollar esta funcionalidad puede variar significati-

Desde el punto de vista del conocimiento, a pesar de que esta funcionalidad

El último factor es el riesgo. ¿Puede pasar que, si encontramos problemas a

usado antes y no tenemos ninguna alternativa pensada, quizás nos convenga

1.2. Impacto financiero de los requisitos

La mayoría de proyectos de desarrollo de software se llevan a cabo para generar

Una manera habitual de generar ingresos es mediante la ampliación de la cuota

En el caso del software que no se ha desarrollado pensando en su comercia-

También podemos aportar nuevos ingresos mediante el incremento de los in-

En el caso de Viajes UOC, se ha planteado la posibilidad de que el nuevo sistema ayude

Finalmente, debemos tener en consideración las mejoras en eficiencia para la

Idealmente, este valor es un valor expresado en términos económicos (un im-

2.1. Magnitudes para la estimación de requisitos

La magnitud más inmediata para estimar el coste de un requisito es la dura-

El principal problema con que nos encontramos a la hora de estimar la dura-

Por este motivo, a menudo se usan las “horas�ideales” (suponiendo que no

Uno de los problemas con la estimación en “horas ideales” es que, a la hora

Esta separación simplifica el problema de hacer estimaciones aplicando el prin-

Finalmente, para obtener la duración (en horas reales) de un requisito a partir

La velocidad es una medida del progreso de un equipo por unidad de

Supongamos que estamos a punto de empezar un proyecto de desarrollo que hemos

A medida que vamos completando iteraciones, tendremos más valores de ve-

2.2. Precisión de las estimaciones

La estimación en el desarrollo de sistemas informáticos es un problema difí-

Las causas de estas dificultades son muchas, incluyendo la carencia de infor-

Siguiendo con el ejemplo anterior, si estimamos alturas de elementos asignando 1 punto

estemos más cerca de su implementación, entonces ya refinaremos la estimación calcu-

2.3. Técnicas de estimación

Una de las técnicas más básicas e importantes para la estimación de requisitos

Los días/persona o días/hombre son otra forma de aproximar la duración de un requisito:

A menudo, es muy difícil encontrar un requisito del mismo tamaño y se usa

Si quisiéramos aplicar la técnica de triangulación, lo que haríamos sería encontrar uno

2.3.2. Estimación colaborativa: planning poker

Una manera de paliar el problema de la información incompleta es hacer uso

Mediante la estimación colaborativa, las diferentes personas involucradas en

La estimación es mucho más fiable si participan en ella los desarrolladores que

Para estimar un requisito concreto, se comenta en voz alta el requisito para

El diálogo que se produce antes de estimar el requisito, así como el que se

2.4. Estimación de requisitos no funcionales

La estimación de cada requisito mediante las técnicas descritas es bastante cla-

Algunos de estos requisitos no funcionales son locales a alguno o algunos re-

En este caso, el tiempo de respuesta de la confirmación es un requisito local, puesto que

Supongamos, por ejemplo, que tenemos un requisito no funcional de rendimiento, que

En algunos casos, sin embargo, un requisito no funcional puede requerir al-

Supongamos que tenemos un requisito que consiste en adaptar el diseño ya existente

3. Priorización y selección de requisitos