Hay tres cosas que debes entender para tener buenas prácticas en tus requerimientos:

• Qué son los Stakeholders
• Los niveles de requerimientos
• Los tipos de requerimientos

Comprender bien esto, te permitirá responder fácilmente a la pregunta: ¿Cuáles son las siguientes user stories a desarrollar? 

Identifica a tus Stakeholders

Un sistema de software impacta a diferentes personas y grupos. Entre esos individuos están tus usuarios, pero no son los únicos a los que debes considerar.

A toda la comunidad de interesados o impactados por el sistema le llamamos Stakeholders y representan la voz de las diferentes necesidades que se deben satisfacer con el software.

Entre tus stakeholders puedes encontrar:

• Patrocinadores del proyecto: quienes aportan los recursos para realizar el proyecto, o apoyan con entusiasmo su realización; contribuyen en la gestión de recursos
• Usuarios directos: individuos que utilizarán las funciones del software con frecuencia, para completar sus tareas habituales. En esta categoría encontramos también otros dispositivos o sistemas, que están empleando nuestro producto con frecuencia.
• Usuarios indirectos: individuos, organizaciones y otros sistemas que reciben un beneficio con el uso de nuestro producto. Por ejemplo, para una aplicación de mapas y GPS, un usuario indirecto es un negocio, que recibe el beneficio de que la aplicación lleve a personas a su local. En esta categoría también encontramos a quienes se benefician con al información producida por nuestro producto, ya sea que la puedan consultar periódicamente o que acceden a ella de alguna forma.
• Definidores de reglas de negocio: Individuos y entidades que establecen reglas, a los cuales el sistema se debe ajustar. Estos stakeholders podrían no utilizar el sistema, pero influyen en su comportamiento. Incluso, pueden ser externos, como instituciones de gobierno, reguladores u otras organizaciones.

Todos los usuarios y stakeholders consideran que sus necesidades y requerimientos son prioritarios e importantes, que todos deben ser incluidos en la solución final. Sin embargo, no es así: hay formas de encontrar los requerimientos que son importantes y prioritarios.

Para ello, te enseñaré el método DI NO

Tipos de requerimientos

DINO son las siglas de los tipos de requerimientos. Cada vez que encontramos uno debemos clasificarlo según lo siguiente:

• Deseables: Requerimientos estéticos, agregan alguna conveniencia en la usabilidad o en el ahorro de pasos. También los conocemos como “nice to have” y son los que se anotan para hacerse si tenemos el tiempo para hacerlos
• Importantes: Son requerimientos de gran valor, pero pueden esperar. Los requerimientos importantes se convierten en obligatorios con el tiempo, pero en el momento de registrarlos por primera vez son los que se negocian por otros prioritarios.
• No implementables: Requerimientos deseables por algunos usuarios, pero agregan poco valor con un alto costo de desarrollo. Estos requerimientos suelen ser para muy pocos usuarios, o uno o dos son los que perciben el valor, pero la mayoría no. Suelen estar fuera de la línea de los objetivos del producto.
• Obligatorios: Los requerimientos que le dan sentido al producto. Sin ellos, el producto no tiene razón de ser o se vuelve inútil. Estos requerimientos aportan el máximo valor, aún cuando su implementación tenga un alcance inicialmente pequeño.

Como un ejemplo:

Un requerimiento obligatorio es que puedas guardar y editar la información de los clientes. Importante que puedas guardar y editar varios registros a la vez, en lugar de hacerlo uno por uno. Deseable, el poder editar en línea los registros (sin presionar el botón editar) y No implementable el que haya una animación con sonido cada vez que guardas un registro.

Pero, te estarás preguntado, ¿cómo sé cuáles serán los obligatorios y cuáles los demás? Para eso nos ayudan los niveles de requerimientos.

Niveles de requerimientos

Los requerimientos están en una jerarquía:

1. De negocio: Representan la razón de ser del producto de software. Aquí se plantean los objetivos a gran escala para alcanzar. Nos indican la dirección que debe tomar el proyecto y contestan la pregunta ¿Qué se debe hacer?
   Los proveedores de estos requerimientos son los stakeholders del negocio, los tomadores de decisiones y los patrocinadores.
2. De usuario: Son las actividades de los usuarios, que se deberán incluir en el software. Estos describen los objetivos de trabajo que persigue el usuario y la forma de cumplirlos. Los procesos o actividades que se modelan en este nivel deben estar en línea con los objetivos planteados en los requerimientos del negocio. Suelen contestar a la pregunta ¿Para quién es el software?
3. De software: Describen lo que el software debe de hacer para incluir y completar las actividades de los usuarios, además de otros atributos del sistema, que conocemos como Requerimientos no funcionales. Estos describen con precisión las funciones que se deben incluir, y responden a la pregunta ¿cómo debe hacerse?

 

En todos los niveles encontraremos los tipos DINO; la forma de obtener los prioritarios y obligatorios será incluir los que se ayudan a alcanzar los objetivos de negocio (primer nivel). Todos los que no aportan a los objetivos serán clasificados como No implementables, y los que apoyan indirectamente son Deseables. 

Una observación: todos los requerimientos no funcionales son obligatorios. No los podemos omitir.

Conclusión

Para poder priorizar tus requerimientos, primero debes identificar a los stakeholders. Es una de tus primeras tareas.

Después, obtener los requerimientos y saber en qué nivel de la jerarquía se encuentran. 

Basándonos en esto, podremos clasificarlos por prioridad e importancia.

Así, podrás tener tu backlog siempre ordenado y con la información suficiente.