Reglas para escribir buenos casos de uso

Saludos a todos.

Desde principios de verano estoy colaborando con la empresa Icinetic (www.icinetic.com) aplicando algunas de mis ideas sobre pruebas para mejorar su proceso de fabricación de software y también desarrollando nuevos servicios.

Uno de los primeros pasos para poner en marcha un proceso de prueba es tener buenos casos de uso. Cuanto mejor sean los casos de uso, más fácil será fabricar el software y elaborar buenas pruebas. En Icinetic tienen su propio conjunto de reglas para desarrollar buenos casos de uso y, además, me han dado permiso para difundirlas. Estas reglas son:

1. El caso de uso se inicia con la acción de un actor.

2. El caso de uso tiene una precondición y una postcondición

3. Mostrar todas las excepciones posibles, así como los flujos alternativos. Al menos “datos incorrectos” y “error al guardar los datos”

4. Mantener el mismo nivel de abstracción.

5. Rastreabilidad hacia el requisito/s de información y el objetivo/s por el que se ha incluido el caso de uso.

6. Comprobar que las relaciones entre casos de uso (include y extends) sean consecuentes con diagramas de casos de uso.

7. Comprobar que los actores que inician los casos de uso sean consecuentes con los diagramas de caso de uso

8. En las eliminaciones comprobar revisando los requisitos de información si se debería eliminar más elementos en cascada. En tal caso detallarlo en la postcondición.

En general, este conjunto de reglas me parece muy bueno. A continuación incluyo los comentarios que les hice a ellos para que el conjunto de reglas fueran aún mejor.

Completamente de acuerdo con las reglas 1, 4, 6 y 8.
No estoy muy convencido de que un caso de uso deba tener siempre una precondición y una postcondición. Si no identificamos claramente una pre o postcondición vale más la pena no ponerla que forzar la situación.
Por regla general, una precondición expresa el estado que debe tener el sistema para poder ejecutar un caso de uso y una postcondición el estado en el que queda el sistema después de ejecutar un caso de uso. Por ejemplo, no se me ocurre ninguna postcondición para un caso de uso de realizar una búsqueda ya que no cambia nada en el sistema. Poner por poner es para nada.
La regla 5 puede hacerse más genérica. Es buena idea que cualquier requisito sea rastreable, y no solo los requisitos de almacenamiento de información.
La regla 7 me parece un poco ambigua. Cuando, en un diagrama de casos de uso hay más de un actor que participa en un caso de uso, no hay, que yo conozca, ninguna notación para saber cuál es el actor que comienza el caso de uso. Yo les propuse escribir esta regla de una forma más genérica: “comprobar que los actores participantes en un caso de uso son consecuentes con los diagramas de casos de uso”.

Además, les propuse añadir las siguientes reglas, la mayoría sacadas sobre todo del libro “Writting Effective Use Cases” de Cockburn.

9. Si el caso de uso se inicia por la acción de un actor, al final de dicho caso de uso el actor debe obtener un resultado (salvo que el caso de uso sea una inclusión o extensión de otro caso de uso. Entonces, probablemente, no se inicie con a acción de un actor.)
10. Comprobar que el caso de uso sea como un partido de tenis (El actor hace… El sistema hace…) y como un partido de fútbol (se sabe en todo momento qué pasa y quién lo hace)

11. Un caso de uso de 3 pasos o menos o de más de 10 pasos probablemente no sea un buen caso de uso (salvo que el caso de uso sea una inclusión o extensión de otro caso de uso).

12. Todas las acciones similares deben describirse con las mismas frases. Por ejemplo, enunciar todas las inserciones de datos con la frase “El actor X introduce los datos….”. No permitir variantes como “inserta datos”, “añade datos”, “incluye datos”, ni siquiera “introducir datos”, etc. Siempre igual, por muy aburrido que resulte.

Por cierto, la regla 12 es muy útil cuando varias personas distintas escriben casos de uso y también a la hora de utilizar herramientas software de análisis de casos de uso y de generación de pruebas.

Como resumen de todo lo visto: un buen requisito y caso de uso debe tener estas características: completo, correcto, no ambiguo, validado, verificable y rastreable.

a. Un requisito completo es aquel que lo cuenta todo, si hay un limite dice cuál es, si hay algo que hacer dice el qué, etc.

b. Un requisito correcto es aquel que está bien escrito, si faltas de ortografía, ni errores sintácticos y que, además, sigue correctamente las reglas para definir requisitos que se estén usando.

c. Un requisito validado es un requisito que ha sido visto y comprendido por el cliente (y ha dado su visto bueno).

d. Un requisito no ambiguo es aquel requisito que tiene el mismo significado para todo el que lo lea.

e. Un requisito verificable es un requisito que expresa cosas que se pueden probar. Un ejemplo de requisitos no verificables son los que dependen de que una persona haga algo determinado (llevar un paquete, comprobar que los códigos estén correctos, etc.).

f. Un requisito rastreable es un requisito que se sabe de dónde viene y se sabe a dónde va.


P.D.
Autonota. Ahora que retomo la actividad, sería buena idea terminar el curso de Cacuts, a ser posible, utilizando la herramienta Cactus.