Un requerimiento no funcional verificable

Los requirimientos deben tener ciertas caracteristicas, una de ellas es que deben ser verificables. Esto es, el requerimiento debe ser contrastable en la realidad por el usuario y antes debería serlo por alguien ( o alguienes) del equipo de desarrollo.
Un requerimiento funcional es mas fácil de verificar que uno no funcional. Así que en esta oportunidad me encargaré de los no funcionales

Miremos algunos ejemplos de requerimientos no verificables, luego mostraré un ejemplo:

• El sistema debe tener interfaces de usuarios amigables.
• La aplicación debe ser ligera.
• Los listados deben ser generados rápidamente.
• El software debe ser seguro.
• La aplicación WEB correspondiente al sector ventas-online debe funcionar en todos las navegadores.

Los requerimientos mencionados arriba son especificaciones que traerán problemas en el corto plazo para el proyecto y /o el producto.

Tomemos el primer requerimiento:
¿Qué significa que las interfaces de usuario sean amigables? ¿Qué significado tiene en la expresión la palabra "amigable"?¿Cómo está seguro el equipo de desarrollo, que ha realizado interfaces amigables?¿Se puede estar seguro que hemos conseguido el requerimiento?¿Se cumplen las expectativas del usuario?
Y por último, ¿qué diablos es una interface de usuario amigable?

En nuestro proyecto una interface de usuario  amigable es un interface fácil de usar y aprender y conseguirá estos objetivos si cumple con:

1. Una descripción de etiquetas para los datos clara y de acuerdo al negocio.
2. Botones de acción al pie de las ventanas con texto y gráficos
3. Una ayuda on-line sobre la meta y uso de la ventana que está usando el usuario.
4. Cada ventana tiene un titulo.

Las etiquetas serán provistas por el stakeholder definido en la organización cliente. 

Los gráficos serán tomados de las aplicaciones utilizadas actualmente por los stakeholders-usuarios representativos de cada sector.

El título será propuesto por el analista y verificado por el stakeholder definido en la organización.

Ahora sí, está descripción que acompaña al enunciado del requerimiento lo completa y en un principio lo hace verificable. Dejo en negrita señalando todo el requerimiento.

Ejemplifiquemos:
Tomemos un caso, si las ventanas no tienen títulos entonces no son amigables. Si los títulos no son los establecidos por el stakeholder definido por la organización entonces no se cumple con el requerimiento.
Si el título dice a, b, o c según lo definido por el stakeholder ( y se cumple con el resto de los criterios) entonces la interface es amigable.

Debo reconocer que algunas descripciones son débiles, por ejemplo cuando se considera una etiqueta clara....pero el impacto de equivocarse será menos.

Anímate a pensar el resto.....