Ingeniería de Requisitos: Casos de Uso en Sistemas

Diagrama de Casos de Uso del Sistema

1. Identificar los Requerimientos del Sistema

Requerimientos Funcionales

Son los requerimientos del usuario que el sistema a desarrollar debe satisfacer, indicando cuáles son las condiciones de entrada y las condiciones de salida.

• Especifican las condiciones que deben ser cumplidas por el sistema.
• Se identifican desde el punto de vista del cliente.
• Se redactan en lenguaje natural.
• Se capturan en dos artefactos:
  • Especificación de requerimientos de software.
  • Modelo de casos de uso de sistema.

Ejemplos:

• Asociados a los casos de uso del sistema:
  • El sistema debe actualizar la información de los profesores que dictan los cursos de baile del club.
  • El sistema permitirá registrar los horarios de dictado de clase definidos por el administrador.
  • Se podrá consultar la programación del rol de los campeonatos locales y regionales.
  • El sistema debe permitir cerrar un curso.
• Asociados a otros aspectos generales:
  • El sistema debe obligar al usuario a cambiar su contraseña cada 60 días.
  • Se debe incluir un mecanismo que permita su actualización automática sin la intervención del usuario.
  • El sistema deberá contener un registro de los errores y para cada uno debe registrar: el código del error, una descripción del error, la fecha y la hora del error.

Requerimientos No Funcionales

Son características que el sistema debe tener para poder asegurar la calidad del sistema.

Grupos:

• Uso: Fácil uso, estética y estándar de la interfaz, documentación de usuario, materiales de capacitación.
• Fiabilidad: Exactitud en los cálculos del sistema, seguridad contra fallas, capacidad de recuperación y/o corrección de errores del usuario, predicción de resultado antes de ejecutar la operación.
• Performance: Rapidez, tiempo de espera, demora en los cálculos, capacidad de memoria.
• Soporte: Capacidad de brindar soporte y mantenimiento al sistema, creación de procedimientos para reporte de errores, mejoras y nuevos requerimientos.

Ejemplos:

• Usabilidad:
  • El sistema debe permitir al administrador registrar una matrícula como promedio en 30 segundos.
  • El lenguaje empleado en la interfaz gráfica del sistema debe respetar los términos usados en el negocio.
  • El diseño de la interfaz gráfica del sistema debe alinearse al estándar definido en la empresa para las aplicaciones web.
• Supportability:
  • El cliente web del sistema debe soportar los siguientes navegadores:
    • Microsoft Internet Explorer 6.0 o superior.
    • Firefox 1.5 o superior para Linux y para Windows.
  • El sistema debe ser compatible con Windows 2000 Profesional y Windows XP.
  • El sistema debe permitir a un usuario su instalación sin entrenamiento previo.

Pseudo Requerimientos

Son aquellos requerimientos impuestos por el cliente que restringen la implementación del sistema.

2. Encontrar los Actores y Casos de Uso del Sistema

El Actor

• El actor representa un ROL, no es un usuario individual del sistema.
• Los actores se determinan observando:
  • Usuarios directos del sistema.
  • Trabajadores y/o actores del negocio.
  • Responsables del uso o mantenimiento del sistema.
  • Otros sistemas que interactúan con el sistema.
• El nombre del actor describe el papel desempeñado.

Identificando Actores: ¿Dónde empiezo a encontrar a los actores del sistema?

• Por cada trabajador del negocio con actividades a automatizar, identificar a un actor del sistema.
• Dar al actor del sistema el mismo nombre del trabajador del negocio.

Preguntas para ayudar a identificar más actores:

• ¿Quién usará la funcionalidad principal del sistema?
• ¿Quién está interesado en cierto requerimiento?
• ¿Quién se beneficia con el uso del sistema?
• ¿Quién administrará, soportará y mantendrá el sistema?
• ¿El sistema usa un recurso externo?
• ¿Alguna persona juega varios roles diferentes?
• ¿El sistema interactúa con otro sistema?

Sugerencias para identificar adecuadamente a los actores del sistema:

• Son roles (humanos, software o hardware), no personas con nombres propios.
• No siempre están asociados con el nombre de un cargo en la planilla de la organización objetivo.
• El nombre no debe representar áreas, departamentos o partes de una organización sino roles de ejecución.
• Cada actor debe estar asociado con al menos un caso de uso del sistema, caso contrario debe ser eliminado del modelo.

Caso de Uso

• Un caso de uso, es un proceso específico del sistema con identidad propia que define una secuencia de acciones que el sistema realiza para un actor en particular.
• Nombre: Verbo + objeto afectado, e.g., Generar Reporte.
• El proceso va relacionado con la identificación de actores.

Por cada actor identificado podemos preguntar:

• ¿Cuáles son las tareas automatizables del actor?
• ¿Qué información crea, guarda, modifica, destruye o lee?
• ¿El actor debe notificar al sistema los cambios externos?
• ¿El sistema debe informar al actor los cambios internos?

Caso de uso vs. Requerimiento funcional:

• Existe una correspondencia directa entre ambos.
• La diferencia radica en la manera en que describen la necesidad de funcionalidad.
  • Los requerimientos funcionales se describen desde la perspectiva del usuario o cliente del proyecto.
  • Los casos de uso se describen desde la perspectiva de la arquitectura del sistema.

Asociación

• Los actores se conectan a los casos de uso a través de una relación de asociación.
• Esta relación se estereotipa como <<communicates>> pero no es necesario indicarla.

Diagrama de Casos de Uso del Sistema

• Representa lo que hace el sistema y su relación con el entorno, desde el punto de vista del usuario.
  • Son iniciados por un agente externo: El Actor.
  • Describen lo que hace el actor y lo que hace el sistema al interactuar.
  • Están limitados a una sola tarea.
  • Muestra gráficamente los requerimientos funcionales del sistema.
• Se tiene en cuenta QUIÉN realiza QUÉ actividad.
  • ¿Quién? (actor del sistema identificado).
  • ¿Qué? (caso de uso del sistema identificado).
  • Relaciones entre ellos (Asociaciones).
• No constituye un diagrama de flujo de datos.
• Un diagrama de casos de uso muestra las relaciones entre los actores y los casos de uso dentro de un sistema.