Priorización de requisitos

Requerimientos de Software
¿Qué es la priorización de requisitos?

• Es la actividad en la cual se identifican los requisitos más

importantes para el sistema.

• La priorización es la característica que identifica a un

requisito que tiene mayor ponderación en importancia y
menor costo.

• La priorización es un proceso dinámico y continuo.

¿Por qué priorizar?

• Para asegurar que el producto de software ofrece las

funcionalidades más importantes o valiosas lo antes posible.

• Permite planificar la construcción para proporcionar el valor

más alto al menor costo.

• Ayuda a entregar el máximo valor comercial lo más rápido

posible dentro de las limitaciones del proyecto

• Ayuda a esclarecer los objetivos, a resolver conflictos, a definir

un plan de entregas incrementales, controlar el avance del
proyecto y tomar decisiones para compensar en caso
necesario el plan.
¿Qué considerar para priorizar?

• Las necesidades de los interesados.

• La importancia relativa de los requisitos para los interesados.

• El momento en que las funciones deben ser entregadas.

• Requisitos que sirven como predecesores para otros

requisitos y otras relaciones entre los requisitos.

• Los requisitos deben implementarse como un grupo.

• El costo para satisfacer cada requisito.

¿Cómo priorizar?

• En un proyecto pequeño, los interesados deberían poder

acordar las prioridades de los requisitos de manera
informal.

• Los proyectos grandes con muchos interesados exigen

un enfoque más estructurado.

• Existen técnicas analíticas y matemáticas para priorizar.

Técnicas de Priorización de Requisitos
Algunas técnicas

• Adentro o afuera

• Método de los 100 puntos

• Escala de tres niveles

• MoSCoW

• Método de valor, costo, riesgo

Adentro o Afuera

• Es el método más simple.

• Un grupo de interesados trabaja en una lista de

requisitos y toma una decisión binaria:

• ¿Está dentro, o está afuera de este lanzamiento?

• Se reduce la lista al mínimo necesario para el primer

lanzamiento o primera versión.

• Se repite el proceso para las siguientes lanzamiento o

versiones.
Método de los $100 (100 puntos)
• Consiste en una votación que es usada en ejercicios de lluvia de ideas.

• A cada interesado se le dan $100 que puedan utilizar para votar por los
requisitos que considere más importantes.

• El interesado puede usarlos de la manera que él considere más

pertinente.

• Por ejemplo, si existen cuatro requisitos que él considera son igual de

prioritarios, entonces podrá asignarle a cada uno $25.

• Si existe un requisito que él considera de importancia primordial podría

darle los $100.

• Los más importantes serán los que se queden con más dinero.
Escala de Tres
Niveles

• Agrupa requisitos en tres categorías:

• Prioridad alta
• Prioridad media
• Prioridad baja

• Considerar dos dimensiones:

importancia (para alcanzar objetivos
de negocio) y urgencia (lanzamiento
en la que debe estar).
• Prioridad alta (Importante-Urgente)
• Son tanto importantes (se necesita la capacidad) como urgentes (se necesita el siguiente

lanzamiento).

• Si una capacidad puede esperar su implementación a un segundo lanzamiento sin

consecuencias para el negocio, entonces no son de prioridad alta.

• Prioridad media (Importante-no urgente)

• Son importantes (se necesita la capacidad) pero pueden esperar hasta una siguiente

versión o lanzamiento.

• Prioridad baja (No importante-no urgente)

• Los clientes pueden vivir sin ellos si es necesario y éstos pueden esperar por ellos (quizás

para siempre).

• No importante y Urgente

• Los requisitos en el cuarto cuadrante parecen ser urgentes para algunos stakeholders, tal

vez por razones políticas, pero en realidad no son importantes para la consecución de

los objetivos de negocio. Ponerlos en prioridad baja o eliminarlos

Escala de Tres Niveles (cont.)

• Este proceso puede realizarse de manera iterativa en

proyectos grandes.

• Si el numero de requisitos de prioridad alta es muy

grande, aplicar nuevamente el mismo proceso solo con
estos requisitos.

• Considerar las dependencias entre requisitos.

• Un requisito de prioridad alta podría depender de otro

que tiene prioridad baja.
MoSCoW
Las cuatro letras en mayúscula representan cuatro posibles
prioridades :

• Must - Debe: El requisito debe cumplirse para que la solución se

considere un éxito.

• Should - Debería: El requisito es importante y debería incluirse en

la solución si es posible, pero no es obligatorio para el éxito.

• Could - Podría: Es una capacidad deseable, pero que podría

posponerse o eliminarse. Implementar solo si el tiempo y los
recursos lo permiten.

• Won’t - No: El requisito no se implementará en este momento,

pero podría incluirse en una siguiente versión.
MoSCoW (cont.)

• Cambia la escala de 3 a 4 niveles.

• No ofrece ninguna justificación para tomar la decisión

sobre como calificar.

• Es ambiguo, la calificación “NO”, podría significar que se

incluye en la próxima versión o que nunca se incluirá

• No es recomendable.
Método Valor, Costo, Riesgo

• Cuando los stakeholders no pueden ponerse de acuerdo

sobre las prioridades mediante otras técnicas
relativamente informales, se utiliza un método analítico.

• Este método se basa en la técnica denominada Quality

Function Deployment, o QFD (Cohen, 1995), lo que
implica asumir el rigor de esta técnica, para obtener un
método estructurado, que ha demostrado ser de utilidad.
Método Valor, Costo, Riesgo (cont.)

• La técnica se basa en los beneficios proporcionados al

cliente, el costo que se paga si no se alcanza la
característica y el riesgo técnico que se tiene.

• Para ello se utiliza la siguiente tabla:

NOTA: Las ponderaciones relativas pueden cambiarse, por default se ponderan igual.
Generalmente los beneficios se ponderan al doble de la penalización y costo y el riesgo a la mitad
Método Valor, Costo, Riesgo (cont.)
1. Listar en la hoja de cálculo todas las características, casos de
uso, las historias de usuario o los requisitos funcionales que desea
dar prioridad, unos contra otros, sin mezclarlos.

2. Los stakeholders colocan un valor de 1-9 (menos valioso-más

valioso) con respecto a los beneficios que tendrá en los objetivos
del negocio.

3. Los stakeholders estiman la penalidad relativa que el cliente o la

empresa sufriría si cada característica no fuera incluidos. En una
escala de 1 a 9 (nadie se molesta si no se incluye o es muy grave
si no se incluye).

4. Calcular el valor total de los beneficios y las penalidades de cada

uno y calcular el porcentaje del valor total de cada una (el valor en
% ).
Método Valor, Costo, Riesgo (cont.)
5. Los desarrolladores estiman el costo relativo de la ejecución de cada
función, en una escala de 1 (rápido y fácil) a 9 (lento y caro) y se calcula
el porcentaje de los gastos totales de cada característica. El costo se
basada en la complejidad, la interfaz de usuario requerida, la posibilidad
de reutilizar código existente, la cantidad de pruebas necesarias.

6. Los desarrolladores determinan el riesgo técnico asociado a cada uno de

los elementos en una escala de 1 a 9, donde 1 significa que se puede
programar sin problemas y 9 indica zozobra acerca de la viabilidad, la
falta de conocimientos técnicos necesarios en el equipo, el uso de
herramientas y tecnologías desconocidas. La hoja de cálculo calculará el
porcentaje del riesgo total que proviene de cada característica.

7. Calcular el valor de la prioridad para cada función mediante la siguiente

fórmula:
Método Valor, Costo, Riesgo (cont.)

• 8. Finalmente, ordenar la lista de características en orden

descendente de acuerdo a la prioridad calculada, es decir
primero quedaran las que tiene un valor, costo y riesgo
mayor.

• Wiegers proporciona una hoja de cálculo que ya

contiene las fórmulas necesarias para los
cálculos, en caso necesario solo se deben ajustar
las ponderaciones.
Método Valor, Costo, Riesgo (cont.)

• Este método es más efectivo que muchos de los otros

métodos (informales).

• Una característica es directamente proporcional al valor

que proporciona e inversamente proporcional a su costo
y riesgo técnico asociado a su implementación.

• Proporciona un Producto con el máximo valor comercial,

con el mínimo costo.
Método Valor, Costo, Riesgo (cont.)

¿Quiénes deben participar?

• Gerente del proyecto o analista del negocio (líder del

proyecto).

• Representantes de clientes (product champions,

gerente de producto, propietario del producto, quien
proporciona calificaciones de beneficio-penalización).

• Representantes del equipo de desarrollo (proporcionan

calificación de costo-riesgo).
Conclusiones

• Debe considerar que algunos requisitos deben

implementarse juntos o en una secuencia específica.

• Al evaluar la prioridades, verifique las conexiones e

interrelaciones entre los requisitos y su alineación con los
objetivos del negocio.

• Generalmente surgen conflictos entre los interesados,

cada uno considera sus requisitos como los más
importantes.

• Los usuarios favorecidos deben tener preferencia en

caso de conflictos.
Gracias por su atención