DISCIPLINA DE REQUISITOS APLICANDO

CASOS DE USO DE SISTEMA

ANALISIS Y DISEÑO DE SISTEMAS I

DOCENTES DEL CURSO 1

 ÍNDICE

OBJETIVOS ..................................................................................................................................... 3
MAPEO ENTRE MODELOS ............................................................................................................. 4
REQUERIMIENTOS FUNCIONALES ................................................................................................. 5
REQUERIMIENTOS NO FUNCIONALES ........................................................................................... 6
SRS – ESPECIFICACION DE REQUERIMIENTOS DE SOFTWARE ...................................................... 7
ACTOR............................................................................................................................................ 9
CASOS DE USO ............................................................................................................................. 11
IDENTIFICAR LOS PAQUETES DEL SISTEMA ................................................................................. 12
DIAGRAMA DE CASOS DE USO DEL SISTEMA .............................................................................. 13
BUENAS PRÁCTICAS PARA EL MODELADO DE CASOS DE USO .................................................... 14
BIBLIOGRAFIA .............................................................................................................................. 16
OBJETIVOS
_ Llegar a un acuerdo formal con los clientes y usuarios finales sobre lo que el
sistema debe de hacer.
_ Proporcionar a los miembros del proyecto una idea clara de los requerimientos
del sistema.
_ Delimitar las fronteras del sistema.
_ Proporcionar las bases para la planificación del contenido técnico de las
iteraciones, los costos y el tiempo para el desarrollo del sistema.
_ Definir la interface gráfica del sistema.
MAPEO ENTRE MODELOS

¿Dónde buscar los requerimientos?

Nota:
_ También están los pseudo_requerimientos, que son aquellos requerimientos impuestos por el
cliente que restringen la implementación del sistema.
REQUERIMIENTOS FUNCIONALES
Son los requerimientos del usuario que el sistema a desarrollar debe satisfacer,
indicando cuales son las condiciones de entrada (inputs) y las condiciones de
salida (outputs).

Definición:
_ 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.

_ Asociados a los casos de uso del sistema

_ Ejemplo:
_ 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 definidas 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.

_ Ejemplo:
_ 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 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

Métricas para especificar Requerimientos No Funcionales

_ Los podemos agrupar como:

_ 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 cálculos, capacidad de
memoria.
_ Soporte: Capacidad de brindar soporte y mantenimiento al sistema, creación
de procedimiento para reporte de errores, mejoras y nuevos requerimientos.
SRS – ESPECIFICACION DE REQUERIMIENTOS DE SOFTWARE
_ ¿Para qué sirve un SRS?
_ Un cliente describa claramente lo que quiere
_ Un proveedor entienda claramente lo que el cliente quiere
_ Se establezcan bases para un contrato de desarrollo (o de compra-venta)
_ Se reduzca el esfuerzo de análisis, diseño, y programación (evitando re-
trabajos)

Características
_ Correcto
_ No ambiguo
_ Completo
_ Consistente
_ Ordenado por importancia y/o estabilidad
_ Verificable
_ Modificable
_ Trazable

_ Un requisito especifica un función o atributo externamente visible de un sistema

Mapeo para obtener casos de Uso de Sistema
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

_ Preguntas para ayudar a identificar más actores:

_ ¿Quién usará la funcionabilidad 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 asociado 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.
Ejemplos
CASOS DE USO

IDENTIFICANDO CASOS DE USO

_ 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 RF se describen desde la perspectiva del usuario o cliente del proyecto.
_ Los CUS se describen desde la perspectiva de la arquitectura del sistema.

Ejemplos:
IDENTIFICAR LOS PAQUETES DEL SISTEMA

ENCONTRAR LOS MODULOS DEL SISTEMA

_ Un Paquete.
_ Hace más fácil la definición de la arquitectura.
_ Facilita la asignación de responsabilidades y tareas a los miembros del equipo
de proyecto.
_ ¿Cuándo utilizar paquetes dentro del Modelo de Casos de Uso del Sistema.
_ Si el número de actores y casos de uso es elevado.

_ ¿Cómo definir los paquetes del sistema?

_ Por cada grupo de casos de uso del sistema.
_ Manejado por un mismo actor.
_ Que respondan a una funcionalidad similar.
_ Por complejidad de desarrollo.
_ Los procesos del negocio (casos de uso del negocio) pueden ayudar a
identificar los paquetes.
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.

Ejemplos
BUENAS PRÁCTICAS PARA EL MODELADO DE CASOS DE USO
RESPECTO A LA PROPUESTA DE CASOS DE USO.- CASOS DE USO BASE
(CUB)
 Los Casos de Uso Base son iniciados por un Actor del sistema.

 Un caso de Uso Base puede incluir a varios Casos de Uso Incluidos. CASOS
DE USO INCLUIDOS (CUI)
 Los Casos de Uso Incluidos son invocados por los CUB.

 Los CUI son reutilizables, es por ello que su creación se justifica si son
utilizados por más de un CUB.
 No pueden ser iniciados por un Actor del Sistema.
CASOS DE USO EXTENDIDOS (CUE)
 Dependiendo de las Reglas de Negocio, pueden ser invocados desde un
CUB o iniciados por un Actor

RESPECTO A LA NOMENCLATURA.-
El uso de los verbos en los Casos de Uso dependerá mucho de las reglas de
negocio. Se debe considerar los siguientes criterios:
 El uso del verbo “Mantener” o “Actualizar”, cuando el CU manipula datos
maestros, asociados a alguna operación de mantenimiento: registro,
modificación, y/o desactivación (cambio de estado a “desactivado” o
“inhabilitado”, pero no “eliminado”).
 El uso del verbo “Administrar” o “Gestionar”, cuando el CU manipula datos de
tipo transaccional para realizar operaciones de mantenimiento.
 El uso del verbo “Buscar”, cuando nos referimos a los Casos de Uso Incluidos
que realizan búsquedas de datos.
 El uso del verbo “Consultar”, los utilizaremos para referirnos a Casos de Uso
Base que realizan búsquedas de datos.
 El uso del verbo “Procesar”, lo utilizamos para representar una funcionalidad
compleja.
 El uso del verbo “Hacer”, lo utilizamos como complemento a una funcionalidad.
Ejemplo: Hacer Pedido de Producto.
 El uso del verbo “Validar”, lo utilizamos para referirnos a la comprobación de
una condición (regla de negocio)
Ejemplo: Validar saldo de Tarjeta.
 Es muy importante hacer una aclaración en el uso del verbo “Registrar” y
“Generar”: o El uso del verbo “Registrar”, cuando el Actor que inicia el CU, NO
tiene la responsabilidad directa sobre la creación del dato transaccional.
Ejemplo: El Asistente de Compras debe “Registrar cotización de proveedores”
BIBLIOGRAFIA
UML 2.0 PARA DESARROLLADORES
DAT CIBERTEC