Transformado requerimientos no verificables en verificables

Un cliente llama al teléfono temprano en la mañana del lunes y dice:

-- No te olvides que el "programa" debe tener una mayor seguridad.

Desafortunadamente colgó antes de poder reaccionar o re-preguntarle.
¿Qué habrá querido decir con mayor seguridad?

Cuando ocurre un caso como este, lo mejor es esperar, no adelantarse y reconocer que se debe investigar un poco más.

Pensemos:

• Restringir el acceso a la aplicación a usuarios autorizados.
• Establecer permisos y roles para el acceso a la funcionalidad.
• Encriptar los datos de la base de datos
• Establecer un control de accesos realizados por los usuarios

Adelantemos el tiempo, imaginemos e idealicemos que sucedió realmente:

Se le pregunta al cliente que quiso significar con mayor seguridad. El cliente comenta:

-- Durante años quise tener una aplicación, pero ahora tengo miedo que alguien entre por internet y me robe los datos.

Al comprender mejor, se entienden mejor los requerimientos. Se puede afirmar que mayor seguridad es: impedir el acceso por internet a los datos de la organización por personas no autorizadas.

Por supuesto y sin dudarlo esto debe quedar registrado en algún documento, más tarde se deberá volver sobre el requerimiento para asegurar su cumplimiento. Si es posible demostrar que no es posible acceder a los datos de la organización a través de internet, entonces el requerimientos será verificable.

Para determinar que se cumple con el requerimiento debe poder ser verificado. Dicho de otro modo, debe ser posible demostrar que existe y se ajusta a la especifificación. Un requerimiento no verificable trae problemas siempre.

Algunos ejemplos malos

1. La aplicación debe ser rápida. --> ¿qué es rápido?
2. Las interfaces de usuario deben ser fáciles.  --> ¿qué es fácil?
3. El código debe ser mantenible.--> ¿qués mantenible?

Ejemplos mejorados y verificables

1. Las respuestas de la aplicación deben ser menores a 3 segundos en el 80% de los casos en horario diurno. Nota: el horario abarca desde las 9:00 am y hasta las 4:00 pm
2. Las interfaces de usuario deben tener homogeneidad presentando los títulos, datos y acciones en las posiciones definidas en minuta 05/12/2014. Ver estándar versión 1.04 de IU.
3. El código usa una sólo instrucción por línea, las variables locales comienzan con el prefijo l_, las variables globales con el prefijo g_.