|
Nombre significativo
| ¿Cada caso de uso tiene un nombre significativo, que indica la funcionalidad que ofrece? |
Pre-condiciones
| ¿Las pre-condiciones están expresadas como condiciones válidas, no como datos de entrada? |
Pos-condiciones
| ¿Las pos-condiciones están expresadas como condiciones válidas, no como datos de salida? |
Información completa
| ¿Cada especificación de un caso de uso tiene toda la información que establece el estándar? (como mínimo: identificador,
nombre, descripción, pre-condiciones, pos-condiciones, flujo normal de eventos y flujos alternos) |
Datos de entrada
| ¿Se definen claramente los datos de entrada que se necesitan en el caso de uso? |
Información de salida
| ¿Se define claramente la información de salida que debe proporcionar el sistema? |
Validaciones
| ¿Se definen claramente las validaciones que se deben realizar? |
Cálculos o procedimientos
| ¿Se definen claramente los cálculos o procedimientos que debe efectuar el sistema? |
Errores o excepciones
| ¿Se han incluido los posibles errores o excepciones que se pueden presentar? |
Flujos alternos
| ¿En cada flujo alterno o excepción se indican concretamente las acciones que se deben realizar? |
Referencias a otros documentos
| En caso de tener referencias a otros documentos, ¿Están claramente identificados y pueden encontrarse fácilmente? |
Entendimiento por personal no técnico
| ¿Cada caso de uso puede ser entendido por personal no técnico? |
Derivación de flujos alternos y excepciones
| ¿Cada flujo alterno y excepción indica dónde se deriva del flujo normal y al finalizar las acciones, dónde continúa o si
termina el caso de uso? |
Identificación de acciones de los actores y el sistema
| ¿Están identificadas claramente las acciones que realizan los actores y las que realiza el sistema? |
Errores gramaticales
| ¿Cada especificación de un caso de uso está escrita sin errores gramaticales? |
Validaciones no genéricas
| ¿Se hace claridad en las validaciones y no se dejan genéricas? (Por ejemplo, no se tiene algo como: “se valida que los
datos sean correctos”) |
Verificación de la implementación de cada caso de uso
| ¿Se puede verificar la implementación de cada caso de uso mediante pruebas, inspección, demostración o análisis? |
Posibilidad de implementación del caso de uso
| ¿Todos los casos de uso se pueden implementar, con los recursos y las restricciones actuales? |
Descripción de flujo de eventos
| ¿La descripción del flujo de eventos se inicia con la descripción de una acción externa originada por un actor |
Claridad respecto al actor iniciador
| Si en el caso de uso interviene mas de un actor, ¿existe claridad en cuál de ellos es el actor iniciador? |
Separación del flujo básico y flujos alternos
| ¿Existe una adecuada separación entre el flujo básico de eventos y los flujos alternos y/o flujos subordinados? |
Exactitud de los verbos
| El nombre del caso de uso no tiene verbos vagos o ambiguos, como son “hacer” o “procesar”, en lugar de ello se deben
utilizar verbos exactos; “aprobar”, “notificar”, “supervisar”, “generar”, etc. |
Acciones CRUD en un solo caso de uso
| No hay casos de uso que describan varias acciones orientadas a bases de datos (crear, modificar, leer, eliminar), en un
solo caso de uso. |
Relación de CU con requisitos funcionales
| Cada caso de uso está relacionado por los menos con un requisito funcional. |
|
