Requerimientos versus casos de uso

Lo que voy a comentar puede no ser una novedad, pero es importante no perderlo de vista.
Un caso de uso con alcance sistema es una descripción de un conjunto de requerimientos organizados y pensados para ayudar a cumplir las metas de un actor. Si necesitas especificar requerimientos te sirven los casos de uso de alcance sistema.

Las definiciones enunciadas son parciales y mejorables, aunque espero te ayuden a entender hacia donde vamos. Como se dice por ahí: "los casos de uso son requerimientos y esencialmente de requerimientos funcionales"

Hoy en día no dudo en utilizar casos de uso como un método para especificar requerimientos y luego ir desarrollándolos (o completándolos).

Los casos de uso vinieron a cubrir ciertas necesidades de especificación y trabajo con los requerimientos, abandonando o dejando de lado la lista de requerimientos; pero la lista de requerimientos no ha muerto.

Hoy los casos de uso se han transformado en los favoritos de los analistas en sistemas de información, teniendo sobradas razones para serlo, pero la lista de requerimientos se sostendrá por mucho tiempo.

Los casos más significativos en donde la lista de reqeurimientos suele ser mejor especificación que los casos de uso se ven en:
no hay workflow, cuando los procesos no pueden precisar secuencias, cuando se trata de una serie de sub-características que debe poseer una aplicación, o cuando los requerimientos no funcionales son la razón de la aplicación, entonces allí la lista de requerimientos domina el territorio.

Pero atención no tienes que decidirte por una, puedes elegir cual usar según el momento, y por supuesto existirán variantes.

Ejemplo 1
Suponga que un actor, el recepcionista de una organización, en su trabajo diario debe escribir gran cantidad de texto sobre campos VARCHAR. El recepcionista en pos de mejorar su trabajo y mejorar el resultado solicita poder copiar y pegar texto, agregar negritas, itálicas, subrayados y cambios de tamaño.
Este tipo de requerimientos  o características es  mejor especificarlos en listas de requerimientos. Intentar organizar estos requerimientos bajo la imagen de un caso de uso no sirve.

Ejemplo 2
Un líder de proyecto indica que desea crear un proyecto y,  para ello define las tareas, luego los recursos, asigna recursos a tareas, las tareas a recursos, borra tareas, cambia recursos, indica costos, a veces decide calcularlos, otras no.
Este caso presenta otra complejidad. Aquí armar un caso de uso  presenta múltiples escenarios y se torna muy engorroso plantearlos a todos. Es más práctico una lista de requerimientos.

Debo reconocer que prefiero los casos de uso a la lista de requerimientos, pero no siempre es aplicable.
Es importante decidir cuando conviene una cosa y cuando otra.

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_.