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.

Photo by Kaboompics .com from Pexels

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.

Photo by cottonbro from Pexels

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?