Pre-condiciones (para empezar el modelado de casos de uso)

Guía para la Elaboración de Casos de Uso
Disciplina de Requerimientos

Historial de Revisión
Fecha Versión Descripción Autor
01-Julio-08 1.1 Adecuacion del documento Susy Silva
28-Agosto-08 1.2 Redaccion Susy Silva
Guia Elaboracion Casos de Uso 01/06/2010 22:32:00 Página 2 de 16

Tabla de Contenido
INTRODUCCIÓN ........................................................................................................................ 4
PROPÓSITO ................................................................................................................................... 4
ALCANCE ..................................................................................................................................... 4
PRE-CONDICIONES (PARA EMPEZAR EL MODELADO DE CASOS DE USO) ......... 4
¿ ES UN PROYECTO NUEVO O UN MANTENIMIENTO ? .................................................................... 5
¿ EN QUÉ FASE DEL CICLO DE INGENIERÍA DEL SOFTWARE ESTÁS ? ............................................. 5
¿ CUÁNTA GENTE ESTÁ DEDICADA AL ESFUERZO DE INGENIERÍA DE REQUERIMIENTOS ? ............ 7
PLAN DE ACTIVIDADES ................................................................................................................. 7
PROCESO DE ELABORACIÓN DE CASOS DE USO ........................................................... 8
ENCONTRAR ACTORES ................................................................................................................. 8
Mecanismos para identificar actores...................................................................................... 8
Puntos de control .................................................................................................................... 9
ENCONTRAR CASOS DE USO........................................................................................................ 11
Elaborar el outline del escenario principal .......................................................................... 12
Flujos Alternos ...................................................................................................................... 12
Actualizar los documentos .................................................................................................... 12
ESTÁNDARES PARA LA ESCRITURA DE CASOS DE USO ............................................ 12
NOMBRE DE LOS CASOS DE USO ................................................................................................ 13
NOMBRE DE ARCHIVOS .............................................................................................................. 13
DESCRIPCIÓN DEL FLUJO BÁSICO .............................................................................................. 13
REFERENCIAS FLUJOS ALTERNOS .............................................................................................. 13
USO DE DICCIONARIO Y/O GLOSARIO DE TÉRMINOS .................................................................. 14
PRE-CONDICIONES Y POST-CONDICIONES ................................................................................... 14
REFERENCIAS A OTROS DOCUMENTOS ........................................................................................ 14
RELACIONES ENTRE CASOS DE USO ............................................................................................ 14
Guia Elaboracion Casos de Uso 01/06/2010 22:32:00 Página 3 de 16

Guía de Elaboración de Casos de Uso
Introducción
El propósito de este documento es presentar las guías para la elaboración de los Casos
de Uso a utilizar dentro de los proyectos.
Propósito
Este documento describe cómo identificar y elaborar los Reportes de Caso de Uso y
pretende ser una ayuda para todos aquellos que tengan que elaborar o interpretar
casos de uso .
Para los Ingenieros de Requerimientos representa una norma a seguir para la
elaboración del artefacto, que implica que se homologuen criterios y enriquecer el
documento de acuerdo a las peticiones del cliente y su experiencia, durante las fases
que el proceso unificado de rational implique.
Este documento complementa las especificaciones descritas en el template de
Especificación de Casos de Uso siguiendo la metodología de la disciplina de
requerimientos del proceso unificado de Rational, el cual deberá tomarse como formato
oficial para la elaboración de este artefacto.
El propósito de este documento es definir los estándares y proporcionar las mejores
prácticas para la elaboración de los Casos de Uso dentro de un proyecto.
Alcance
Este documento únicamente cubre guías para hacer casos de uso que empiezan de cero
(nuevos proyectos o mantenimientos adaptativos (es decir, cuando el mantenimiento
involucra nueva funcionalidad completamente).
Pre-condiciones (para empezar el modelado de casos de
uso)
Antes de Iniciar el esfuerzo de Ingeniería de Requerimientos es necesario identificar lo
siguiente:
Guia Elaboracion Casos de Uso 01/06/2010 22:32:00 Página 4 de 16

• ¿ Es un proyecto nuevo o un mantenimiento ?
• ¿ En qué fase del ciclo de Ingeniería del SW se encuentra ?
• ¿ Cuánta gente está dedicada al esfuerzo de Ingeniería de Requerimientos ?
• Sobre el plan de actividades
Analizar el plan de actividades y tiempos del proyecto
Identificar la duración y término de la Fase de Inception
Identificar la duración y término la Fase de Elaboration
¿ Es un proyecto nuevo o un mantenimiento ?
Si es un Proyecto Nuevo
Deberá generarse el documento de Visión enfocándose principalmente en los siguientes
puntos:
Descripción de Stakeholders
Necesidades
Definición del problema
Restricciones al proyecto
Esto con la finalidad de conocer las necesidades de negocio y mapear los casos de uso
para que cubran exactamente las necesidades de los Stakeholders.
Así mismo deberá empezarse con el modelo de casos de uso de manera general.
Si es un mantenimiento
Implica funcionalidad nueva (desde cero)
Deberá empezarse con el modelo de Casos de Uso
Implica cambiar funcionalidad específica
Si se cuenta con el modelo de casos de uso deberá modificarse el reporte de caso de
uso y analizarse con cuáles otros casos de uso puede tener relación para realizar su
modificación, si es que aplica.
¿ En qué fase del ciclo de Ingeniería del Software estás ?
Dependiendo de la Fase de Ingeniería en la que se encuentre el proyecto, se deben
enfocar los esfuerzos de modelado de casos de uso (y del resto de la Ingeniería de
Requerimientos).
Guia Elaboracion Casos de Uso 01/06/2010 22:32:00 Página 5 de 16

Fase de Incepcion
Por ejemplo, en la fase de Inception, no se debe intentar levantar todo el detalle de los
requerimientos del proyecto (se estaría cayendo en el ciclo clásico y antiguo de
cascada). Se debe empezar por tener una idea general del proyecto centrándose en los
siguientes puntos: modelo de casos de uso, bosquejo de los casos de uso principales,
priorizar las características del producto, medir los riesgos y obtener las restricciones del
proyecto.
A continuación se define las actividades principales que debes hacer en cada una de las
fases.
Inception
Primer bosquejo del modelo de casos de uso
Glosario (Vocabulario Inicial)
Flujo de eventos (bosquejo) de los casos de uso críticos
Boceto de la Interfaz de Usuario de los CU principales (si aplica)
Visión (principales necesidades de los usuarios involucrados y los usuarios finales y
características del producto)
Elaboration
Refinamiento del Modelo de Casos de Uso (Gráfico) (Revisado y aceptado
formalmente)
Detalle del 80% de los Casos de Uso (Revisados e idealmente aceptados
formalmente)
Reporte de Casos de Uso terminados y verificados (de los CU Principales / Críticos )
Prototipo del Sistema (si aplica)
Glosario (Vocabulario Incial)
Construction
Administración formal de cambios (analizar impacto del cambio)
Flujos de Eventos Modificados
Glosario modificado
Guia Elaboracion Casos de Uso 01/06/2010 22:32:00 Página 6 de 16

¿ Cuánta gente está dedicada al esfuerzo de Ingeniería de
Requerimientos ?
La meta principal de todos los proyectos deberá ser:
Crear software de calidad en el tiempo, con los recursos asignados y
cubriendo las necesidades reales de nuestros Stakeholders
De ahí que es importante NO COMPROMETERSE A HACER MÁS DE LO QUE SE
PUEDA con base en los recursos y tiempo que tenemos.
Es importante analizar la complejidad del software, la importancia que éste tiene para la
organización y se definan en forma adecuada los tiempos y recursos asignados. Si con
base en el análisis del problema y con la detección de algunos de los casos de uso se
observa que es casi imposible sacar el proyecto es importante ajustar las expectativas
de los Stakeholders.
Plan de actividades
Todo proyecto deberá contar con un plan de trabajo que determine actividades y
tiempo y que será administrado y controlado por un Líder de Proyecto, Gerente o
cualquier otro responsable asignado.
El área de Requerimientos deberá:
Analizar el plan de actividades y tiempos del proyecto
Conocer las responsabilidades y el alcance de las mismas
Identificar los puntos de verificación y los criterios de evaluación
Identificar los hitos, productos o cualquier otro artefacto que se espere como
entregable en cada una de estas actividades
Conocer la duración y término de la Fase de Inception
Conocer la duración y término de la Fase de Elaboration
De ser posible, deberá establecerse un plan de trabajo interno para completar
estas actividades y tiempos así como reportar el avance de las mismas al
administrador
Guia Elaboracion Casos de Uso 01/06/2010 22:32:00 Página 7 de 16

Proceso de Elaboración de Casos de Uso
Las actividades generales que deberán ser cubiertas para la Elaboración de los Casos de
Uso son:
Encontrar actores
Encontrar Casos de uso (identificar metas de los actores)
Describir las interacciones entre actores y casos de uso
Empaquetar a los casos de uso y actores
Crear los diagramas de casos de uso necesarios
Desarrollar borradores de Casos de Uso
Evaluar los resultados
Encontrar Actores
Un actor es todo aquello que tiene interacción directa con el sistema. Un actor puede ser
una persona, dispositivo u otro sistema.
Mecanismos para identificar actores
Para encontrar actores se recomienda:
1. De los Stakeholders identificados, verificar cuáles de ellos interactuarán en forma
directa (mediante algún desarrollo o como operadores) con el sistema de
información. Ese subconjunto de Stakeholders son actores.
2. Responder las siguientes preguntas:
¿ Quién utilizará el sistema ?
¿ Quién entregará información al sistema ?
¿ A quién le debe entregar información el sistema ?
¿ Quién mantendrá la información del sistema? (quién trabajará con todos
esos caso de uso de soporte dedicados a la administración de catálogos)
¿ Quién soportará y administrará el sistema? (quién trabajará con los casos
de uso de administración de usuarios, configuración del sistema, respaldos,
etc..)
¿ El sistema interactuará con otros sistemas ?
¿ El sistema utilizará algún dispositivo (hardware) ?
Guia Elaboracion Casos de Uso 01/06/2010 22:32:00 Página 8 de 16

¿ En qué lugar de la organización se utilizará principalmente el sistema ? 1
Puntos de control
Usuarios Multifacéticos vs. Actores
Una misma persona (especificador) puede estar jugando al mismo tiempo más de un rol
en la organización.
La diferencia entre un actor y un usuario, es que el actor representa un tipo de usuario
más que a la persona misma. Muchos usuarios pueden jugar el mismo rol, lo que
significa que todos ellos deben estar representados por un solo actor.
Acciones:
Identificar los roles que juega un usuario y separarlos en el diagrama de actores
Especificar en forma detallada lo que cada rol requiere del sistema
Nombramiento
Un actor aunque representa a un grupo de personas en una organización no debe
nombrarse en plural.
Acciones:
Nombrar los actores en singular
Los nombres de los actores deben corresponder a un rol. Si no es así, cambiar los
nombres.
Un actor no debe tener el nombre de una persona
Validación de Cobertura
Para validar la cobertura en el análisis de actores es importante que tomar en cuenta la
siguiente clasificación:
Actores Primarios
Usuarios que ejecutan la funcionalidad principal del sistema (la razón de ser de la
aplicación).
1 Una buena práctica para esto es localizar el organigrama del área y obtener los puestos y responsables, ya que
regularmente algunos de ellos tienden a ser actores potenciales del sistema. Regularmente estos organigramas
proporcionan información para la mejor comprensión del problema que se intenta resolver y además son una
referencia, en algunos casos, para resolver dudas.
Guia Elaboracion Casos de Uso 01/06/2010 22:32:00 Página 9 de 16

Actores Secundarios
Usuarios que ejecutan funcionalidad secundaria del sistema (administrar usuarios,
administrar catálogos, cargar datos, hacer respaldos, etc...).
Acciones:
Verificar con respecto al tamaño del proyecto y áreas en la organización (en las que
estará operando el sistema), si el número actual de actores es realmente
significativo con respecto al tamaño y tipo de proyecto.
o Muchos actores para un proyecto pequeño (10 C.U). Deberán revisarse y
ajustarse los casos de uso utilizando la generalización, por ejemplo.
o Muy pocos actores para un proyecto pequeño (10-20 C.U) puede que
necesite revisar y ajustar.
o Etc... (definan sus propias métricas de tamaño de proyecto)
Verificar si existen actores de ambas clasificaciones (principales y secundarios).
Verificar si el proyecto tiene relaciones con dispositivos u otros sistemas y validar
que estos se encuentran definidos como actores
Realizar una verificación final una vez concluida la definición de los casos de uso ya
que podrían haber surgido nuevos actores no identificados en el primer esfuerzo.
Verificar, una vez modelados los casos de uso, si cada actor está relacionado con al
menos un caso de uso
Eliminar actores que no sean mencionados en la descripción de los casos de uso o
que no tengan al menos una relación con algún caso de uso
Verificar si se puedes mencionar al menos a 2 personas (instancias reales) que
jueguen el rol de cada uno de los actores. Si esto no pasa, verificar si el actor no es
real ya que más bien puede ser parte de otro actor.
Verificar si varios actores juegan roles similares con respecto al sistema. Si esto
pasa, deberá intentarse fusionar a los actores en un solo actor utilizando
generalización (herencia).
Verificar si varios actores juegan roles similares con respecto a un mismo caso de
uso. Si es así, utilizar la generalización entre actores.
Verificar si un actor en particular tiene varios propósitos para utilizar (de diversas
formas) un caso de uso. Si esto es así, analizar si debe dividirse el actor y/o caso de
uso.
Validación de Alcance
La definición de actores permite identificar los límites del sistema en desarrollo. Deberán
identificarse como actores únicamente aquellos quienes se comuniquen en forma directa
con el sistema. Si se está incluyendo roles que están alrededor del sistema pero que no
interactúan en forma directa, se está cayendo en el error de mezclar el negocio con el
sistema.
Acciones:
Guia Elaboracion Casos de Uso 01/06/2010 22:32:00 Página 10 de 16

Verficiar para cada uno de los actores que estos tengan interacción directa con el
sistema. Si no es así deberán ser elimínados del modelo de casos de uso
Validación de Especificador
Si la definición del sistema completo (actores, funcionalidad, característica, etc.) se está
llevando a cabo por una sola persona deberá ser considerado como un riesgo potencial.
Acciones:
Verificar si se cuenta con un solo especificador. De ser así definirlo desde un inicio
como un riesgo potencial y comunicarlo al líder de proyecto.
Identificar posibles especificadores por parte del área usuaria.
Generales
Algunas características que debes tener bien claras del actor:
Alcance del actor en el proyecto
Ambiente en el cual el actor estará utilizando el sistema (grandes errores en la Ing.
de SW, es crear aplicaciones que no podrán ser utilizadas en forma óptima en el
ambiente real del actor).
El número de usuarios representado por éste actor. Este número denotará el factor
de relevancia del actor con respecto al resto de los actores y con respecto al
proyecto.
La frecuencia en la cual el actor utilizará el sistema.
Nivel de experiencia del actor (especificador) en el dominio del problema.
Nivel general del actor en conocimientos de sistemas (cómputo)
Conocer cuáles otras aplicaciones utiliza el actor.
Encontrar casos de uso
La actividad de definición de Casos de Uso se centra básicamente en identificar para
cada uno de los actores, las diversas formas en las que espera utilizar el sistema.
Las actividades generales pueden centrarse en:
Hacer una lista de las metas del actor
Identificar para qué va a utilizar el actor el sistema
Identificar si el actor obtendrá, cambiará, modificará o eliminará información del
sistema
Guia Elaboracion Casos de Uso 01/06/2010 22:32:00 Página 11 de 16

Elaborar el outline del escenario principal
Elaborar el bosquejo del flujo básico de los casos de uso principales (en caso de que
el sistema incluya menos de 6 casos de uso elaborar el bosquejo de cada uno de
ellos)
Revisar y Validar estos artefactos con el usuario
Flujos Alternos
Para poder identificar los posibles flujos alternos se sugiere apoyar de las siguientes
preguntas:
¿Qué puede estar mal?¿ Cómo deberá responder el sistema ante los posibles
errores?
¿Cuáles son algunas de las situaciones opcionales que se pueden presentar en el
caso de uso?
¿Cuáles son algunas de las situaciones no comunes en el caso de uso pero que
puedan llegar a presentarse?
¿El actor del caso de uso, es la persona indicada para resolver los posibles
errores?
¿Deberá estar relacionado algún otro actor que entre en acción en ciertas
ocasiones?
Condiciones de falla
Completar el escenario principal y realizar una lluvia de ideas de todas las
fallas que pueden ocurrir en cada una de las actividades. En primera
instancia deberán identificarse las fallas sin enfocarse en el cómo deberán
manejarse estos eventos por el sistema
Identificar los flujos alternos opcionales
Manejo de errores
Describir obligatoriamente la forma en que el sistema responderá a cada una
de las condiciones de falla
Actualizar los documentos
Actualizar y completar el reporte de casos de uso con las pre y pos condiciones,
requerimientos especiales y referencias a otros documentos
Estándares para la escritura de casos de uso
Las siguientes secciones definen la estandarización para la escritura de los casos de
uso.
Guia Elaboracion Casos de Uso 01/06/2010 22:32:00 Página 12 de 16

Nombre de los Casos de Uso
Describir todos los casos de uso desde la perspectiva del actor y no del sistema
Describir todos los casos de uso mediante un nombre representativo utilizando un
verbo en infinitivo al inicio, el cual deberá estar acompañado obligatoriamente por
el sustantivo al que el verbo califica. Ejem. Generar Cotización
Nombre de archivos
Describir los archivos generados para la documentación de los casos de uso bajo el
siguiente nomenclatura:
CUMOD001 Nombre del caso de uso
| | |---- Consecutivo numérico del caso de uso
| |---- Módulo del sistema XXXX (ver estándares de módulos del sistema)
|---- Identificador del artefacto Casos de Uso
Descripción del Flujo Básico
Cada una de las actividades del flujo básico debe representar una interacción
completa entre el usuario y el sistema
El nivel de detalle debe ser suficiente para que el diseñador no tenga que realizar
más investigaciones con el usuario, ese detalle no debe ir necesariamente incluido
en la descripción de las actividades, sino que debe complementarse con el
documento de Reglas de Negocio, Diccionario de Datos y Glosario de Términos
(deben estar muy bien descritas las relaciones con los otros documentos)
o El sistema valida que el cliente cubre los requisitos para otorgarle el crédito
(ver Reglas Negocio, BR010. Otorgamiento de Crédito)
o Si el proyecto está utilizando RequisitePro, debe hacer la liga en las matrices
El descripción de los flujos dentro del caso de uso debe describirse en tiempo
presente:
o El sistema solicita los sig. datos del cliente: Nombre, Dirección
o El vendedor captura los datos
En las descripciones del flujo básico no deberán usarse términos técnicos como
tabla, campo, subrutina, grid, pantalla, ya que este documento debe ser
suficientemente claro tanto para usuarios de negocio como para el equipo de
desarrollo.
Referencias Flujos Alternos
Cuando se haga referencia a algún flujo alterno, en la descripción de las actividades del
flujo básico, deberá colocares de la siguiente forma según el caso:
Guia Elaboracion Casos de Uso 01/06/2010 22:32:00 Página 13 de 16

Para hacer mención a los flujos alternos, se deberá utilizar un prefijo formado
por dos caracteres que identifica el tipo de flujo alterno y dos números que
corresponden a un consecutivo por tipo de flujo alterno.
Los prefijos a utilizar de acuerdo al tipo de flujo alterno son los siguientes:
o AO## Flujo alterno opcional
o AG## Flujo alterno general
o AE## Flujo alterno de excepción.
Si es un flujo opcional se representa de la siguiente manera: Si Condición se
ejecuta el flujo alterno “AO01”.
Si es un flujo de excepción o general se representa solamente una referencia de
la siguiente forma: [AE01 ], [AG01], donde 01 es un numero consecutivo.
Dichas referencias deben tener una hiperliga a la descripción del flujo alterno.
Uso de Diccionario y/o Glosario de Términos
En el reporte del caso de uso se PROHIBE escribir sentencias como: “ Se captura
la información del cliente “, “Se capturan los datos del cliente”. Se debe documentar
exactamente cuál es la información del cliente que se requiere:
o Ejem. Nombre, Dirección.
Si se coloca solo la leyenda de campos del cliente y dichos datos se encuentran en
un diccionario de datos o en el glosario, debe existir una referencia al documento en
cuestión.
Pre-condiciones y Post-condiciones
Tanto las precondiciones como las poscondiciones deben ser expresadas también en
términos de negocio y/o estados que deben tener los objetos de negocio para que
pueda iniciarse el caso de uso o que deben existir al concluir la ejecución de este
Solo se colocan las pre-condiciones y post-condiciones si son estrictamente
necesarios para que el caso de uso inicie
Referencias a otros documentos
En esta sección deben colocarse las referencias (preferentemente hiperligas) a los
documentos que complementan la información del caso de uso. Normalmente debe
existir referencia al Glosario de Términos correspondiente, al documento de reglas
de negocio, al diccionario de datos, a formatos de impresión, y a documentos que
detallen algoritmos
No deberán incluirse pantallas, diagramas de casos de uso o diagramas de
comunicación en los reportes de casos de uso. Esto evitará la posible inconsistencia
entre los que se usan en los Storyboards
Las pantallas y diagramas de comunicación deben de estar en el Storyboard del flujo
del proyecto
Relaciones entre casos de uso
Guia Elaboracion Casos de Uso 01/06/2010 22:32:00 Página 14 de 16

Todos los casos de uso deben de tener relación al menos con un actor ( Los casos
de uso base).
Si existen casos de uso de administración de catálogos, debe existir un caso de uso
para cada función administrativa de cada uno de ellos (Altas, bajas, cambios,
consultas, etc..)
No son permitidas las relaciones entre casos de uso a excepción de:
o Include
Siempre se van ha ejecutar cuando se ejecute el paso del caso de uso
base en el que se hace referencia al caso de uso .
Un include puede invocarse en el flujo principal o en un alterno opcional.
No puede ejecutarlo un actor
No es un caso de uso completo (es parte de otro caso de uso)
Es siempre invocado por el caso de uso base
El caso de uso debe estar relacionado al menos con 2
casos de uso, si no es así no es un include y los pasos deben ser
regresados al caso de uso base.
o Extends
Agrega funcionalidad al caso de uso base, pero no es determinante para
que se ejecute (es potencialmente opcional).
Cuándo un flujo alterno opcional es muy grande y complejo se puede
sacar como un caso de uso
Es opcional (no siempre se ejecutan).
o Generalization.
Guia Elaboracion Casos de Uso 01/06/2010 22:32:00 Página 15 de 16

La estructura de los casos de uso hijos es la misma, solo la forma en la
que se deben ejecutar algunos de los pasos cambia de uno a otro.
Se crea un padre que tenga el mismo outline de los dos hijos (todos
iguales, tanto los hijos como el padre) y los pasos que son iguales
conservan la descripción en el padre, los pasos que son diferentes son
descritos en los hijos.
La generalización se aplica mayormente a los actores.
Guia Elaboracion Casos de Uso 01/06/2010 22:32:00 Página 16 de 16