Aprendiendo a escribir Casos de Uso Efectivos

Escribiendo Casos de Uso Efectivos

Versión 4.0

Pag. 1 de 40

Escribiendo Casos de Uso EfectivosÍndice

................................................................................................................................................................1

I.- Introducción..................................................................................................................................4

1 El Modelado de Casos de Uso..............................................................................................51.1 Precaución con Sobre-Diagramar...........................................................................61.2 Actores y Casos de Uso Relacionados.................................................................6

2 ¿Qué es un Casos de Uso?...................................................................................................72.1 Metas e Historias.........................................................................................................72.2 Un Buen Caso de Uso es:.........................................................................................82.3 Un Buen Caso de Uso NO es:..................................................................................82.4 ¿Qué no hacen los Casos de Uso?........................................................................92.5 Resumiendo qué es un Caso de Uso.....................................................................9

3 ¿Para qué sirven los Casos de Uso?..................................................................................93.1 Unamos los conceptos aprendidos.......................................................................9

4 Requerimientos Para la Construcción de Software........................................................94.1 Requerimientos Funcionales...................................................................................94.2 Requerimientos No Funcionales:.........................................................................104.3 Metas.............................................................................................................................104.4 Metas de Sub-Función.............................................................................................13

5 Actores y sus Metas...............................................................................................................135.1 Un Actor.......................................................................................................................134.1 Un Caso de Uso es Iniciado por un Actor:.........................................................144.2 Actores son Roles.....................................................................................................154.3 El Tiempo como un Actor.......................................................................................15

6 ¿Cómo Se Escriben Los Casos de Uso?.........................................................................166.1 Identificando Actores y sus Metas.......................................................................166.1.1 La Lista Actor-Meta...................................................................................................166.1.2 Actores y Metas Vía Análisis de Eventos...........................................................176.2 El Flujo Básico...........................................................................................................176.2.1 Escenario Principal y Pasos (o Flujo Básico)...................................................186.3 El Sub Flujo.................................................................................................................196.4 Incluyendo Sub-Flujos Comunes (Include)........................................................206.5 Flujo Alterno...............................................................................................................216.6 Haciendo el Flujo Alterno una Extensión. (Extend).........................................226.7 Lista de Variaciones de Datos y Tecnología......................................................236.8 Valor Agregado..........................................................................................................236.9 Agrupando Funciones Dentro de Casos de Uso..............................................246.10 La Anatomía de una Interacción...........................................................................256.10.1 Agregando Interacción........................................................................................266.11 El Lenguaje de Texto del Caso de Uso................................................................276.12 Diagramas de Actividad..........................................................................................286.13 Prototipos de Pantalla..............................................................................................29

Pag. 2 de 40

Escribiendo Casos de Uso Efectivos6.14 Tipos Formatos..........................................................................................................306.14.1 Formato de Caja Negra.......................................................................................307.1 Tipos de Formalidad.................................................................................................317.2 Caso de Uso UC1: Procesar Ventas (Ejemplo en formato formal)..............327.3 Caja Negra o Dos Columnas..................................................................................35

7 El formato de usecases.org.................................................................................................37

8 ¿Cuál es el Mejor Formato?.................................................................................................37

9 Explicando las Secciones....................................................................................................379.1 Elementos de Prefacio.............................................................................................379.2 Actor Primario............................................................................................................379.3 Lista de Intereses y Stakeholders........................................................................389.4 Pre Condiciones y Post Condiciones (Garantías de Éxito)...........................389.5 Extensiones (Flujos Alternos)...............................................................................389.6 Requerimientos No Funcionales (o Requerimientos Especiales)...............40

Pag. 3 de 40


I.- Introducción.Los Casos de Uso son ampliamente usados y un excelente mecanismo para descubrir y registrar requerimientos (especialmente funcionales); ellos influencian en muchos aspectos de un proyecto incluyendo OOA/D de ahí la importancia de saber acerca de los Casos de Uso y como crearlos.

Escribir Casos de Uso – historias de “usando un sistema” – es una técnica excelente para entender y describir requerimientos. Veremos conceptos clave y presentaremos ejemplos de Casos de Uso para una aplicación que hemos titulado ProxGene.

El Proceso Unificado (UP por sus siglas en inglés) el Modelo de Casos de Uso dentro del flujo de trabajo de los requerimientos, esencialmente es un set de todos los Casos de Uso; esto es un modelo de la funcionalidad y ambiente del sistema.

Pag. 4 de 40


1 El Modelado de Casos de UsoSi todas las interacciones con un sistema están descritas en términos de procedimientos escritos como Casos de Uso, entonces el Modelado de Casos de Uso provee una completa (caja negra) perspectiva “desde afuera” de las funcionalidades del sistema. El Modelado de Casos de Uso no está planeado para ser una definición exhaustiva de las funcionalidades del sistema ya que esto se logra sólo con un modelo de sistema interno completo que resulta de un detallado análisis del sistema.El Modelado de Casos de Uso sirve de alcance a las funcionalidades que ejecutarán o no el sistema que se esté definiendo en suficiente detalle para que nosotros podamos estar seguros de que no hemos perdido nada importante. El Modelado de Casos de Uso consiste de:

Actores, Casos de Uso y sus relaciones

Un número de Diagramas de Casos de Uso los cuales juntos cubren todas las funcionalidades propuestas del sistema y son soportadas por:

Documentos de Casos de Uso, escritos explícitamente en texto, el cual describe el detalle del flujo de cada Caso de Uso

Prototipos de Pantalla o Prototipos de Interfases (Opcional) Diagramas de Actividad (Opcional)

Un set completo de diagramas de Casos de Uso muestra todos los procedimientos disponibles para una interacción con el sistema. Esto es un sumario de las funcionalidades del sistema. Recordemos que las flechas no muestran ningún tipo de proceso o flujo de datos, solamente qué procedimientos están disponibles y cómo ellos son agrupados por el actor.

Muestra la agrupación de servicios que el sistema brinda a los actores.Crea tantos diagramas como se necesiten para cubrir todas las funcionalidades del sistema.

El tamaño de los diagramas (sugerido) debe poder leerse en una pantalla de computadora o páginaIncluye todos los actores y Casos de Uso (al menos uno) en un diagrama.

Pag. 5 de 40

Escribiendo Casos de Uso EfectivosLos diagramas pueden estar “sobrecargados” pero no repiten actores o Casos

de Uso en el mismo diagrama.1.1 Precaución con Sobre-Diagramar

Para reiterar, la importancia de un trabajo de Casos de Uso es escribir texto, no diagramar o enfocarse en relaciones de Casos de Uso. Si una organización gasta muchas horas (o peor, días) trabajando en un diagrama de Casos de Uso y discutiendo las relaciones entre ellos en vez de primero enfocarse en escribir texto, un gran esfuerzo a sido desperdiciado.

1.2 Actores y Casos de Uso Relacionados.En el siguiente diagrama el Capturista de Datos es un actor activo el cual

inicia los Casos de Uso “Introducir Orden” y “Cancelar Orden”. Esto es denotado por las flechas sólidas que van del Actor a los Casos de Uso. (El origen de la flecha está en el Actor)

El Sistema de Contabilidad es un Actor pasivo para el Caso de Uso Introducir Orden. En este punto en el Caso de Uso filtrará las cuentas del Sistema para información de las cuentas de los clientes y el Sistema de Contabilidad responderá. Para el Caso de Uso “Obtener Direcciones” el Sistema de Contabilidad es un Actor activo ya que está iniciando el Caso de Uso requiriendo una dirección desde el sistema que se está definiendo.

Este diagrama no es un diagrama de Flujo de Datos. Las interacciones seguirán ocurriendo en ambas direcciones entre los Actores y el Sistema como parte de cada Caso de Uso. La flecha indica solamente cuál parte ha iniciado la potencialmente bi-direccional interacción.

Es un hecho que la cabeza de la flecha ni siquiera está definida en las especificaciones de UML. Esto ha venido simplemente a ser un “de facto” estándar a través del uso común. La relación es definida en UML como una relación estática llamada una “asociación” y muestra un diagrama de Caso de Uso como una línea sólida sin “cabeza de flecha”

Las líneas sólidas o flechas no son permitidas entre Casos de Uso. Más adelante veremos posibles relaciones entre Casos de Uso, pero ellos seguirán sin ser flujos de datos.

Pag. 6 de 40

Escribiendo Casos de Uso Efectivos2 ¿Qué es un Casos de Uso?

La motivación de la idea de Casos de Uso es la consideración y organización de requerimientos en el contexto de las metas y escenarios de usar un sistema. Eso es algo bueno – esto mejora la cohesión y comprensión. Sin embargo, los Casos de Uso no son los únicos artefactos de requerimientos necesarios. Algunos requerimientos no funcionales, reglas de dominio y contexto, y otros elementos “difíciles de colocar” son mejor capturados en Especificaciones Suplementarias.Una idea detrás de los Casos de Uso es recolocar detalladamente listas de características de bajo nivel (la cuales eran comunes en métodos de requerimientos tradicionales) con Casos de Uso (con algunas excepciones).Un Caso de Uso es:

Un excelente mecanismo para descubrir y registrar requerimientos. Una técnica excelente para entender requerimientos.

Pero agregaremos algunos puntos más específicos sobre lo que es un Caso de Uso.Un Caso de Uso es un procedimiento por el cual un actor puede usar el sistema. Esto es:Una colección de Escenarios compuesto inicialmente por un Flujo Básico, más alternativas al Flujo Básico Es siempre nombrado con la meta del actor y empieza con un verbo en infinitivo.Es un procedimiento completo contenido en sí mismo.Empieza con el sistema en un estado estable y lo deja en un estado estable.Por procedimiento es independiente de otros Casos de Uso.Puede ser usado como las bases para pruebas del sistema.

2.1 Metas e HistoriasLos Clientes y los Usuarios Finales tienen metas (también conocidas como necesidades en el UP) y quieren que un sistema de computación les ayude a alcanzarlas, puede ser algo tan sencillo como sólo registrar ventas o tan complejo como estimar el flujo de petróleo de próximos pozos. Hay varias maneras de capturar estas metas y requerimientos de sistema, las mejores son aquellas que son simples y familiares porque estas se hacen fácilmente para - especialmente para clientes y usuarios finales – contribuir a su definición o evaluación. Es muy bajo el riesgo de perder la marca.

Los Casos de Uso son mecanismos para ayudar a mantener simple y entendible para todos los implicados (stakeholders) Informalmente ellos son historias de “usando un sistema para alcanzar metas”. A continuación se pone un ejemplo de un caso de uso utilizando un formato breve:

Proceso de venta: Un cliente se acerca al mostrador con los artículos que compró. El cajero usa el sistema POS para registrar cada artículo comprado. El sistema presenta una lista con todos los artículos comprados por el cliente mostrando el detalle del precio de cada artículo así como el total. El cliente introduce información del pago, el cual el sistema valida y registra. El sistema actualiza el inventario. El cliente obtiene su recibo de compra y se va con sus artículos.

Pag. 7 de 40

Escribiendo Casos de Uso EfectivosEs común que los Casos de Uso tengan que ser más elaborados que esto, pero la esencia es descubrir y registrar requerimientos funcionales escribiendo historias de “usando un sistema” para ayudar a alcanzar a varios involucrados (stakeholders) sus metas; esto es: Casos de Uso. Esto no se supone que deba ser una idea difícil, lo que pudiera llegar a serlo es el descubrir o decidir que se necesita y escribirlo coherentemente así como en el nivel de detalle que se requiera.

Se ha escrito mucho acerca de Casos de Uso, y mientras mas se escribe, pareciera que el riesgo de ser mas creativo y obscurecer una simple idea entre plantillas de sofisticación.Es posible que un modelador novato en Casos de Uso, se ocupen de mas en cosas secundarias como diagramas de Casos de Uso, relaciones de Casos de Uso, paquetes de Casos de Uso, atributos opcionales, etc.Se dice que un fuerte mecanismo de Casos de Uso, es la capacidad de escalar hacia arriba y hacia abajo en términos de la sofisticación y la formalidad dependiendo de la necesidad.

2.2 Un Buen Caso de Uso es:Un buen Caso de Uso es una secuencia de interacciones a través del contexto

del sistema entre el o los actores y el sistema mismo.Se debe usar un lenguaje natural de tal forma que tanto personas con

conocimientos técnicos como las que no los tienen puedan entenderlo. El Caso de Uso es un vehículo para obtener requerimientos funcionales de los usuarios y/o afectados y también es una poderosa herramienta para realizar las entrevistas, especialmente cuando es usado en conjunto con prototipos de pantalla.Un buen Caso de Uso también es:

Fácil de entender No es ambiguo Es completo incluyendo todos los flujos alternos. Se especifica en un documento separado del modelado de Casos de Uso. Es aquel en el que todos los interesados en el sistema están de acuerdo.

Está “mapeado” a un prototipo de pantalla o un prototipo de interfase.

2.3 Un Buen Caso de Uso NO es:El estilo de “receta” de escribir un Caso de Uso puede ser usado para

“figurar” un Caso de Uso en la fase temprana de alcance del proyecto pero las interacciones son ambiguas. “Introduce tarjeta” no dice de donde viene la tarjeta o a donde va. “El Cliente introduce la tarjeta dentro del cajero automático” define completamente la interacción.

Un buen Caso de Uso No Es: Un proceso de negocio Una pieza de código Una receta Una descripción del sistema Una lista de funciones

Pag. 8 de 40

Escribiendo Casos de Uso Efectivos2.4 ¿Qué no hacen los Casos de Uso?

Los Casos de Uso no: Muestran requerimientos de interfase. Capturan requerimientos de desempeño. Recolectan fórmulas, estados ni reglas de negocio.

2.5 Resumiendo qué es un Caso de Uso. Un mecanismo para descubrir y registrar requerimientos. Una técnica para entender requerimientos. Un procedimiento por el cual un actor puede usar el sistema. Esto es: Una colección de Escenarios compuesto inicialmente por un Flujo

Básico más alternativas al Flujo Básico Un procedimiento completo contenido en sí mismo.Y También: Empieza con el sistema en un estado estable y lo deja en un estado

estable. (Lo inicia un actor) Por procedimiento es independiente de otros Casos de Uso. Puede ser usado como las bases para pruebas del sistema.

3 ¿Para qué sirven los Casos de Uso?Sirven para descubrir, registrar y entender requerimientos. Pueden ser usados

como las pruebas para las bases del sistema.3.1 Unamos los conceptos aprendidos

1. Los Casos de Uso contienen requerimientos funcionales en formato de texto en una forma fácil de leer y fácil de darle seguimiento.

2. Un Caso de Uso recopila como lograr o fallar una meta; un Escenario muestra una condición específica; los Escenarios y los Casos de Uso se anidan.

3. Los Casos de Uso sólo muestran los requerimientos funcionales. 4. Ellos preparan el marco para los requerimientos no funcionales y

detalles del proyecto. 5. El diseño se realiza hasta que se tiene el incremento del Caso de Uso.

4 Requerimientos Para la Construcción de Software.4.1 Requerimientos Funcionales.

Los Casos de Uso son requerimientos, en primer término hay requerimientos funcionales que indican lo que el sistema hará. En términos de los tipos de requerimientos ellos enfatizan la “F” (functional or behavioral) FURPS+ pero pueden ser usados por otros tipos, especialmente cuando aquellos otros tipos se relacionan fuertemente al caso de uso. En el UP – y en la mayoría de los métodos modernos- los Casos de Uso son el mecanismo central que es recomendado para su descubrimiento y definición. Los Casos de Uso definen una promesa o un contrato de cómo el sistema se comportará.

Para ser claro, los Casos de Uso son requerimientos (aunque no todos los requerimientos). Existen requerimientos que dicen por ejemplo “el sistema debería

Pag. 9 de 40

Escribiendo Casos de Uso Efectivoshacer… (función o lista de características)”, esto no es así y una idea clave de Casos de Uso es para (usualmente) reducir la importancia o el uso de viejos estilos de detallar las características y en vez de esto, será siempre mejor escribir un caso de uso para requerimientos funcionales.

Los Casos de Uso son documentos de texto, no diagramas, y el modelado de Casos de Uso es primariamente un acto de escribir no de dibujar. Sin embargo, el UML define un diagrama de Caso de Uso para ilustrar los nombres de estos, actores y sus relaciones.

4.2 Requerimientos No Funcionales:Son todos aquellos requerimientos típicamente especiales que son

especificados en un Caso de Uso pero no pueden ser fácilmente o naturalmente explicados dentro del texto del flujo de eventos.

Ejemplos de requerimientos no funcionales incluyen requerimientos legales y mandatorios, estándares de aplicación y atributos de calidad para el sistema ha ser construido, incluyendo atributos de usability, reliability, performance o supportability.

Adicionalmente, otros requerimientos como sistema operativo y ambiente, requerimientos de compatibilidad y restricciones en el diseño también son requerimientos NO funcionales.

Algunos ejemplos más:- Monitor plano con pantalla sensible al tacto (touch screen)- El texto debe ser visible desde un metro de distancia.- La respuesta de las autorizaciones de crédito debe de ser de no más de 3 segundos

en el 90% de las transacciones.- Nosotros queremos robustecer la recuperación cuando los servicios de acceso

remoto, como el sistema de inventarios, esté fallando.- Queremos internacionalización del lenguaje en el texto que se esté desplegando.- Las reglas de negocio se debe aplicar en los pasos 3 y 7- …

4.3 Metas¿Cómo debe ser descubierto un Caso de Uso? Es común estar inseguro si algo es un Caso de Uso (o en un sentido más práctico, si es de utilidad) válido. Las tareas pueden ser agrupadas en diferentes niveles de detalle, desde uno o pequeños pasos hasta actividades de nivel corporativo.¿Cuál de estos es un caso de uso válido?

Negociar un contrato con un proveedor. Manejar Devoluciones Log In

Se puede argumentar que todos estos son Casos de Uso en diferentes niveles, dependiendo del contexto del sistema, los actores y las metas. Luego entonces, la pregunta general es:

¿Cuál es un nivel útil para expresar Casos de Uso para el análisis de requerimientos de una aplicación?

Pag. 10 de 40


Una tarea ejecutada por una persona en un lugar a un tiempo, en respuesta al evento del negocio el cual agrega un valor medible al negocio y niveles de datos en estado consistente. Ejemplo, Aprobación de Crédito o Precio de Orden [Fuente original perdida]

Los actores tienen metas (o necesidades) y usan aplicaciones para satisfacerlas. Consecuentemente, un Caso de Uso en nivel EBP es llamado un Caso de Uso nivel meta de usuario (user goal-level user case) para enfatizar que este sirve (o debe servir) para satisfacer una meta de un usuario o del sistema o del actor primario.Y esto da luz para procedimiento recomendado:

1. Encontrar metas de usuario.2. Definir Casos de Uso para cada una.

Esto es donde debe enfatizar el modelador de Casos de Uso. En lugar de preguntar ¿Cuáles son los Casos de Uso?, uno empieza por preguntar: ¿Cuáles son tus metas?En efecto, el nombre de los Casos de Uso por la meta de un usuario debe reflejar dicho nombre. Para enfatizar este punto de vista- meta: capturar o procesar una venta; Caso de Uso: Procesar Venta.Obsérvese el por qué de esta simetría, la guía EBP puede ser igualmente aplicada para decidir si una meta o un Caso de Uso está en un nivel adecuado.Esto es, acá hay una idea clave referente a: investigar metas de usuario vs. investigar Casos de Uso:

Pag. 11 de 40

El Caso de Uso EBPEl análisis de requerimientos para una aplicación de computadora, se enfoca en los Casos de Uso en el nivel de procesos elementales de negocio.

(Elementary Business Processes EBPs)

Supongamos que estamos juntos en un taller de requerimientos. Podríamos hacer cualquiera de las siguientes dos preguntas:

¿Qué hace Usted? (refiriéndonos a una pregunta orientada a caso de uso) o

¿Cuáles son tus metas?

Las respuestas a la primera pregunta son más para reflejar la solución actual los procedimientos y las complicaciones asociadas con ellas.

Las respuestas a la segunda pregunta, especialmente combinada con una investigación para moverse a un nivel mas alto de herencia (¿Cuál es la meta de esa meta?) abre la visión para soluciones nuevas y mejoradas, enfocándose en agregar valor al negocio y obtener el corazón de lo que el stakeholder quiere desde la perspectiva del sistema bajo discusión.


Ejemplo: Aplicando la Guía EBPComo el analista de sistemas responsable para los requerimientos del sistema ProxGen, usted está investigando metas de usuario. La conversación es como esta durante un taller de requerimientos:Analista de sistemas: ¿Cuáles son algunas de sus metas en el contexto de usar un sistema POS?Cajero: “Uno es loguearme rápidamente. También, para capturar ventas”Analista de sistemas: ¿Cuál piensa usted que es la meta de mas alto nivel que motiva a “loguearse”?Cajero: “Estoy intentando identificarme al sistema, así que éste pueda validar que estoy autorizado para capturar ventas y otras tareas"Analista de sistemas: “¿Mas alto que eso?”Cajero: “Para prevenir fraude, corrupción de datos y evitar mostrar información privada de la compañía”

Observe que la estrategia del analista de buscar herencia de las metas hacia arriba para encontrar el más alto nivel de las metas del usuario, satisface la guía EBP, para obtener un intento real detrás de la acción y también para entender el contexto de las metas.

“Prevenir fraude,…” es mas alto que la meta de un usuario; esto puede ser llamada una meta corporativa, y no es un EBP. Por lo tanto, a través de que esto puede inspirar nuevas formas de pensar acerca del problema y las soluciones (tales como eliminar el sistema POS y a los cajeros completamente) nosotros dejaremos este asunto hasta acá por ahora.

Bajando de nivel la meta a “identificarme y ser validado” se parece mas a una meta a nivel de usuario. Pero ¿Es este un nivel EBP? Esto no agrega valor cuantificable u observable al negocio. Si el Presidente de la compañía pregunta: “¿Qué hiciste hoy?” y usted responde “¡Ingresé al sistema 20 veces!”, él no se va a

Pag. 12 de 40

Escribiendo Casos de Uso Efectivosimpresionar. Consecuentemente, esta es una meta secundaria, siempre en el servicio de hacer algo de utilidad, y no es un EBP o meta de usuario.

Como otro ejemplo, en algunas tiendas hay un proceso llamado “cashing in”, en cuyo caso el cajero introduce su propia caja de efectivo dentro de la Terminal de punto de venta, se loguea y le dice al sistema cuanto efectivo hay en su caja. Cashing In es un Caso de Uso nivel-EBP (o meta a nivel usuario); el paso log in, en vez de ser un inicio de un Caso de Uso nivel-EBP, es una meta de sub función en soporte a la meta de cashing in.

4.4 Metas de Sub-Función.“Identificarme y ser validado” (o “log in”) ha sido eliminado como una meta de usuario, esta es una meta de bajo nivel, llamada una meta de sub función (sub-metas que soportan una meta de usuario) Los Casos de Uso debería ocasionalmente se escritos para estas metas de sub-funciones, ya que es un problema común que los expertos en Casos de Uso observan cuando se les pregunta para evaluar y mejorar (usualmente simplificar) un set de Casos de Uso.

No es ilegal escribir Casos de Uso para metas de sub función, pero no es siempre de mucha ayuda, esta agrega complejidad al modelo de Casos de Uso; puede haber cientos de metas de sub-funciones – o Casos de Uso de sub-funciones- para un sistema.

Punto importante: El número y el detalle de los Casos de Uso tienen influencia en el tiempo y la dificultad para entender, mantener y manejar requerimientos.

La motivación más común para expresar una meta de sub función como un Caso de Uso es cuando la sub función es repetida en o es una precondición para múltiples Casos de Uso con la misma meta de usuario. Esto en efecto es cierto “identificarme y validarme” el cual es una precondición de mas, si no de todos, los otros Casos de Uso con meta de usuario.

Consecuentemente, esto puede ser escrito como el Caso de Uso: Autenticar Usuario.

5 Actores y sus Metas5.1 Un Actor

Definiendo un actor definimos el contexto del sistema, no cualquier cosa del sistema que nosotros estemos definiendo es un actor. Así que nosotros no ponemos la base de datos que guardará la información como un actor en el diagrama de Casos de Uso: esto es parte del sistema pero no puede ser un actor.

Un actor esta siempre fuera del sistema que está siendo modelado.Pag. 13 de 40

Escribiendo Casos de Uso Efectivos Caracteriza un rol Un actor puede ser una persona, un sistema o cualquier entidad externa. Un actor se liga a uno o más Casos de Uso del sistema No es un símbolo de agrupación lógica de Casos de Uso.

Un actor es cualquier cosa o persona con un comportamiento o conducta, incluyendo el sistema bajo discusión por si mismo cuando lo llama el servicio de otro sistema. Actores no son sólo roles de personas.

Actor Primario- tiene metas de usuario satisfechas a través de usar servicios del sistema bajo discusión. Por ejemplo, el cajero.

o ¿Por qué identificado? Para encontrar metas de usuario, lo cual nos dirige a los Casos de Uso.

Actor de soporte – provee un servicio (por ejemplo, información) para el sistema que estamos tratando. El servicio de autorización de pagos automatizado es un ejemplo. Seguido un sistema de cómputo, pero puede ser una organización o persona.

o ¿Por qué identificado? Para clarificar interfases externas y protocolos.

Actor fuera de escena – Tiene interés en la conducta del Caso de Uso, pero no es primario o de soporte; por ejemplo, Hacienda y Crédito Público.

o ¿Por qué identificarlo? Para asegurar que todos los intereses necesarios son identificados y satisfechos. Los intereses del actor fuera de escena algunas veces son fáciles de perder a menos que estos actores sean explícitamente nombrados.

4.1 Un Caso de Uso es Iniciado por un Actor:El Actor inicia el Caso de Uso porque quiere algo desde el sistema.

Nombra el Caso de Uso en términos de la meta (valor) para el usuario. El nombre de Caso de Uso inicia con un verbo en infinitivo. El Actor proporciona el evento que inicia el Caso de Uso El Actor es la fuente del evento que ha de ser la primera línea en el Caso

de Uso La flecha indica que el Actor inicia la interacción entre el Actor y el

Caso de UsoPag. 14 de 40

Escribiendo Casos de Uso Efectivos Este Actor es entonces el “Actor Primario” para el Caso de Uso.

4.2 Actores son RolesEl Señor Venegas como Presidente de Best-Up necesita acceso a información de la administración. Liliana Lara como capturista de datos necesita introducir órdenes. Algunas veces, el Sr. Venegas puede necesitar introducir una orden cuando Liliana no esté. Esto no quiere decir que nosotros dibujamos una flecha entre el Sr. Venegas y el Caso de Uso “Introducir Orden”. Introducir órdenes no es el rol del Presidente de Best-Up. Esto es que el Sr. Venegas toma el rol de “Capturista de datos”, (un “mapeo” ocurrirá de acuerdo a los settings de seguridad del sistema), cuando se firme en el sistema y obtenga acceso al Caso de Uso “Introducir Órdenes”.

Ultimadamente, un actor la única propiedad que tiene es que se liga a Casos de Uso. La mayoría de los títulos en el trabajo involucran el colocarse un “número diferente de sombreros en diferentes situaciones”, así que debemos nombrar el actor con su rol en vez de su título de trabajo. Si hay alguna confusión con esto… ¡piensa en sombreros!

4.3 El Tiempo como un ActorEl tiempo es un factor externo fuera del control del sistema. Cuando un cierto

tiempo es alcanzado, ese evento es detectado por el reloj de tiempo-real (real – time clock) que está dentro del sistema y del Caso de Uso y éste último es iniciado “automáticamente”.

El que el sistema siempre inicie en un tiempo en particular demasiado inflexible en un código “demasiado duro”, así que normalmente un actor, a través de otro Caso de Uso o a través del mismo Caso de Uso, debe haber una opción que nos permita encender o apagar la hora en que ha de “dispararse” el evento o bien nos permita modificar la hora.

Pag. 15 de 40


6 ¿Cómo Se Escriben Los Casos de Uso?6.1 Identificando Actores y sus Metas.

Es artificial el intentar “politizar” estrictamente el encontrar actores primarios antes que metas de usuario; en un taller de requerimientos, lluvia de ideas y generar una mezcla de ambas, algunas veces las metas revelan los actores o viceversa.Guía: Enfatice en la lluvia de ideas primero los actores primarios, las siguientes preguntas ayudan a identificar otros que pueden estar perdidos:

¿Quién inicia y para el sistema? ¿Quién administra el sistema? ¿Quién crea los usuarios y administra la seguridad? ¿Es el “tiempo” un actor porque el sistema hace algo en

respuesta al evento del tiempo? ¿Hay un proceso de monitoreo que reinicia el sistema si

falla? ¿Quién evalúa la actividad del sistema o su desempeño? ¿Cómo se maneja la actualización del software? ¿Quién evalúa logs?

Recapitulamos que el actor primario tiene metas de usuario satisfechas a través de usar servicios del sistema. Ellos llaman al sistema para ayudarlos.

Esto es en contraste a actores de soporte, los cuales proveen servicios al sistema bajo diseño

También que los actores primarios pueden ser – entre otras cosas – otros sistemas de computadora, tales como un proceso de software “watchdog”6.1.1 La Lista Actor-MetaRegistrar los actores primarios y sus metas de usuario en una lista de meta-usuario. En términos de artefactos UP esto debería ser la sección en el artefacto de Visión)

Pag. 16 de 40

Escribiendo Casos de Uso EfectivosPor ejemplo:

Actor Meta Actor MetaCajero Procesa ventas

Procesa rentasManeja devolucionesManejo de efectivo

Administrador del sistema

Agrega usuariosModifica usuariosElimina usuariosAdministra la seguridadAdministra las tablas del sistema

Gerente Inicia el sistemaApaga el sistema…

Sistema de actividad de ventas (1)

Analiza las ventas y el desempeño de los datos

… … … …(1) El Sistema de actividad de ventas es una aplicación remota que

frecuentemente requerirá datos de las ventas desde cada Terminal POS en la red.

Esta lista se mira sencilla, pero la realidad de su creación es otra. Muchas lluvias de ideas y basura acerca de esto se generaron en el taller de requerimientos. Consideremos el ejemplo que ilustró como aplicar la regla EBP para la meta de “log in”Durante el taller mientras creamos la lista el cajero puede ofrecer “log in” como una de sus metas de usuario. El analista de sistemas va a lo más profundo y encuentra el nivel de la meta más allá del mecanismo de bajo nivel de firmarse en el sistema (el cajero probablemente estaba pensando el uso de una caja de diálogo en un GUI) hasta el nivel de “identifica y valida usuario”.El analista entonces resuelve que esto no pasa la guía EBP y descarta la meta del usuario. Por supuesto en la realidad es mucho más diferente que esto porque un analista experimentado tiene un set de heurísticas de pasadas experiencias o estudio.6.1.2 Actores y Metas Vía Análisis de EventosOtra manera de auxiliarnos en encontrar actores, metas y Casos de Uso es identificar eventos externos. ¿Cómo son ellos, de donde y por qué? Seguido, un grupo de eventos pertenece al mismo nivel de meta EBP o Caso de Uso, por ejemplo:

Evento Externo Del Actor MetaIntroduce el articulo de venta

Cajero Procesar una venta

Introduce el pago Cajero o Cliente Procesar una venta…

6.2 El Flujo BásicoCuando hacemos el trabajo de escribir Casos de Uso, debemos iniciar por

describir el flujo básico. ¿Qué es el flujo básico?

Pag. 17 de 40

Escribiendo Casos de Uso Efectivos6.2.1 Escenario Principal y Pasos (o Flujo Básico)

Este ha sido llamado el escenario de “El día feliz” o de manera más prosaica, “Flujo Básico”. Esto describe el típico camino de éxito que satisface los intereses de los stakeholders. Es importante observar que es común que no se incluya ninguna condición, esto no es malo ni ilegal. Este flujo básico es más comprensible y entendible por ser más consistente y difiere de todo manejo de condicionantes, las cuales se aplican en las secciones de extensión.

El escenario registra los pasos, de los cuales hay tres tipos:

1.- Una interacción entre actores2.- Una validación (usualmente por el sistema)3.- Un cambio de estado por el sistema (por ejemplo: guardando o modificando algo)

El paso uno no siempre cae en esta clasificación pero indica el detonador del evento que inicia el escenario.

Esto es un idioma común que siempre capitaliza los nombres de los actores para una fácil identificación. Hay que observar también el idioma que es usado para indicar repetición:

1 El cliente se acerca al mostrador con artículos o servicios para comprar.2 El cajero empieza una nueva venta3 El cajero introduce el código del artículo4 … El cajero repite los pasos 3-4 hasta que ha registrado todos los artículos5 …

Es importante definir el flujo básico de un Caso de Uso antes de construir la estructura de varios flujos como parte de él. Si la velocidad con la cual el Caso de Uso es completado por el actor es importante, entonces debe ser optimizada para ser tan eficiente como sea posible para el usuario. Esto es especialmente verdadero si el caso de uso será usado por un actor bajo la presión del tiempo, por ejemplo, alguna respuesta a una llamada de un cliente y cuya expectativa es proveer respuestas en tiempo real a las preguntas del cliente

Usemos la siguiente guía: Escribe el curso de los eventos más importantes que pasan la mayoría del

tiempo:

Pag. 18 de 40

SugerenciaTodas las condicionales deben ser diferidas a la sección de Flujos Alternos


No incluyas complejas excepciones en flujo básico Simples excepciones con una simple condición y una línea de respuesta

puede ser incluida. Esto es mas simple que crear un flujo alterno Escribe en el Documento de Casos de Uso Los flujos alternos deben ser atendidos pero no gastes tiempo

elaborándolos en este punto.6.3 El Sub Flujo

Algunas veces es muy útil “partir” o bien el flujo básico u otro flujo, de tal manera que éste pueda ser re-usado con el Caso de Uso. Este flujo es creado en un párrafo separado del documento de Caso de Uso y sería llamado solamente como una sub-función si estuviéramos escribiendo código.

Al párrafo del sub flujo se le debe dar un título: “Sub Flujo: XXX”, donde XXX es el nombre del sub flujo e inicia con un verbo activo.

En el flujo el sub-flujo es invocado por referencia de su nombre. En el ejemplo las palabras del título del sub-flujo están en mayúsculas para indicar la llamada. Otras formas de llamado pueden ser: “El sub-flujo XXX inicia aquí” o “Do sub-flujo XXX” lo cual puede empezar a verse como muy técnico para el grueso de los usuarios no técnicos.

El sub-flujo siempre corre y regresa al punto del cual fue invocado, a menos que una excepción durante el sub-flujo prevenga el regreso. En cuyo caso el Caso de Uso continúa en el punto indicado.

Pag. 19 de 40

Escribiendo Casos de Uso Efectivos6.4 Incluyendo Sub-Flujos Comunes (Include)

Algunas veces hay un flujo que es común entre dos Casos de Uso. Si esto es así entonces ahí es necesario separar el flujo común del Caso de Uso donde este fue descubierto y colocarlo en un lugar que es accesible desde ambos Casos de Uso.

Para hacer esto nosotros creamos un nuevo “Caso de Uso” el cual realmente no es otra cosa que un “sub-flujo” y es accesible para ambos Casos de Uso que lo necesitan. Todo esto que está pasando aquí es que el sub-flujo está siendo movido a un documento nuevo, común y anexado a símbolo de un nuevo Caso de Uso en el diagrama de Caso de Uso.

En el diagrama un símbolo de nuevo Caso de Uso es creado para representar el sub-flujo común. Este símbolo no representa realmente un nuevo Caso de Uso, pero simplifica una parte de dos Casos de Uso que han sido separados en orden de ser documentados sólo una vez.

En el diagrama nosotros usamos una relación “include” que es una dependencia entre Casos de Uso con estereotipo “include”. Esto quiere decir que el Caso de Uso incluido (el señalado por la flecha) es dependiente del Caso de Uso que lo contiene y que la naturaleza de la dependencia es que “uno contiene al otro”. En otras palabras, cada uno de los dos Casos de Uso originales ahora requieren del tercero para poder ser completados.

La descripción del Caso de Uso incluido debe ser escrito en una forma tal que todo en él sea enteramente común a los dos Casos de Uso que lo incluyen. (Including) Si nosotros necesitamos incluir un “switch” el cual depende del Caso de Uso desde el cual fue llamado, entonces no estamos incluyendo cosas en común. El Caso de Uso hijo (child) debe ser independiente de ambos Casos de Uso padres (parents)

La referencia a un Caso de Uso <<Include>> es escrita en el padre exactamente de la misma manera que se haría normalmente con un sub-flujo, la única diferencia es que el sub-flujo está ahora en un documento separado.

Comúnmente se abusa de este mecanismo descomponiendo un Caso de Uso en pasos y mostrando cada paso como un “caso de uso” separado en el diagrama de Casos de Uso. Este tipo de descomposición funcional (yo diría infuncional) “infla” el Modelado de Casos de Uso y tiende a ignorar las reglas sobre Casos de Uso.

Un Modelo de Casos de Uso con muchos <<include> generalmente indica que el mecanismo <<include>> ha sido usado sin un propio entendimiento del contenido del flujo include.

Pag. 20 de 40


Administrar Detallesdel Cliente

Capturista de datos

Introducir Orden

Encontrar Registrodel Cliente

<<include>>

6.5 Flujo AlternoUn flujo alterno busca el evitar cargar y obscurecer con muchas condiciones

el flujo básico. (Altas, Bajas, Cambios, Modificaciones, Consultas, Impresiones… etc., etc.)

Un flujo alterno debe ser diseñado de tal forma que “sepa cómo insertarse por sí mismo” en el flujo que lo extiende. En otras palabras, la referencia para donde es insertado y la condición bajo la cual es insertado, deben ser definidas en flujo alterno por si mismas.

Para escribir un flujo alterno adecuadamente deben tomarse en cuenta siempre los siguientes cuatro elementos:

1) El lugar en el cual el flujo se inserta por sí mismo. En el siguiente ejemplo esto ha sido escrito como: “Si en 2, en Introducir Orden”. Si cada enunciado en el Caso de Uso tiene un único número de línea, entonces aún la referencia al nombre del flujo en el cual el flujo alterno es insertado puede ser omitida y la línea de referencia usada por sí misma.

Pag. 21 de 40


2) La condición bajo la cual se inserta por si mismo. En el ejemplo: “el número de artículo es invalido”

3) Qué pasa en el flujo alterno. Esto es escrito en exactamente la misma forma que debería escribirse en cualquier otro flujo, esto es, con enunciados numerados los cuales definen largas interacciones que cruzan el contexto del sistema.

4) Qué pasa al fin del flujo. Hay 4 opciones: El Caso de Uso termina; el Caso de Uso regresa de donde fue llamado y continúa, el Caso de Uso regresa previo a donde fue llamado; el Caso de Uso va hacia delante. En cada uno de los últimos tres, las líneas deben tener números únicos para indicar la línea a la cual se debe ir.

El flujo alterno es normalmente sólo otro párrafo en el documento de Caso de Uso.6.6 Haciendo el Flujo Alterno una Extensión. (Extend)

Si el flujo alterno es muy largo, esto es, más de una página o si es una funcionalidad opcional para el sistema, entonces puede ser el momento apropiado para partir (split out) el flujo y ponerlo en un documento de Caso de Uso separado. El documento entonces es anexado (attached) al símbolo de un nuevo Caso de Uso en el diagrama con una relación <<extend>> desde el Caso de Uso que se extendió al Caso de Uso que lo extiende.

Observa que la relación es una dependencia UML con el estereotipo <<extend>>, yendo desde el símbolo del Caso de Uso extendido hacía el Caso de Uso el cual lo extiende.

Nota que solamente “Introducir Orden” es un Caso de Uso. “Manejar Número de Producto Inválido” es solamente un flujo alterno.

No abuses de la sintaxis. Si haces cada flujo alterno una extensión, entonces tendrás de 5 a 10 veces el número de símbolos de Casos de Uso en el diagrama y muchos documentos de pequeños Casos de Uso.

Pag. 22 de 40


Capturista de datos

Introducir Orden

Manejar Número de Producto Invalido

<<extend>>

6.7 Lista de Variaciones de Datos y Tecnología.Es común que existan variaciones técnicas en cómo algo debe ser hecho, pero no qué, y es recomendado guardarlo como una nota en el Caso de Uso. Un ejemplo común es una restricción técnica impuesta por un stakeholder referente a tecnologías de entrada o salida.

Por ejemplo, un stakeholder puede decir: “El sistema POS debe soportar la entrada de las tarjetas de crédito usando un lector de tarjeta y un teclado” Obsérvese que hay decisiones tempranas acerca del diseño o restricciones; en general. Se trata de evitar las decisiones de diseño prematuras aunque a veces son o bien obvias o bien inevitables, especialmente en lo concerniente a I/O

Es también necesario entender las variaciones en los esquemas de los datos así como usar UPCs o EANs como identificadores de artículos codificados en la simbología de los códigos de barras.

Esta lista es el lugar para registrar dichas variaciones. Esto es también de mucha utilidad para registrar variaciones en los datos que pueden ser capturados en un paso en particular.

6.8 Valor Agregado.Algunas definiciones informales: un actor es alguien con un

comportamiento, como una persona (identificado por un rol), sistema de computación u organización; por ejemplo un cajero.Un escenario es una secuencia específica de acciones e interacciones entre actores y el sistema bajo discusión; esto es también llamado una instancia de caso de uso.

Esta es una historia particular de “usando un sistema” o un camino a través de un Caso de Uso.

Por ejemplo; el escenario de una compra satisfactoria en efectivo o la falla de la compra porque la tarjeta de crédito fue rechazada por el banco.Informalmente entonces, un Caso de Uso es una colección de sucesos relacionados y escenarios de falla que describen actores usando un sistema para soportar una

Pag. 23 de 40

Escribiendo Casos de Uso Efectivosmeta. Por ejemplo, a continuación se muestra un Caso de Uso en formato casual que incluye algunos escenarios alternos:

Manejando DevolucionesPrincipal escenario de éxito.

Un cliente llega al mostrador de servicio al cliente para regresar algunos artículos. El cajero usa el sistema POS para registrar cada artículo que se va a devolver.Escenario Alterno:

Si la autorización del crédito es rechazada informa al cliente y le pregunta por otra opción de pago.

Si el artículo no es encontrado en el sistema, informa al cajero y le sugiere que introduzca el código manualmente para identificar el artículo (quizá este corrupto)

Si el sistema encuentra una falla para comunicarse con el sistema que calcula los impuestos,…

Una definición alterna, pero similar de Caso de Uso es provista por el UP:

“Un set de instancias de Casos de Uso, donde cada instancia es una secuencia de acciones que un sistema ejecuta y que da un resultado observable de un valor particular para un actor” (RUP)

La frase “un resultado observable de valor” es realmente importante porque esta direcciona la actitud que el sistema debe enfatizar para proveer un valor al usuario.

Una actitud clave en un Caso de Uso es el enfocarse en la pregunta: ¿cómo puedo usar el sistema para que provea de un valor observable al usuario o cumplir sus expectativas?, en vez de pensar meramente en los requerimientos del sistema en términos de “una lista de lavandería” de características o funciones.

Quizá se mire obvio el decir que un caso de uso debe arrojar un valor observable, pero la industria del software está llena de proyectos fracasados porque no se enfocaron en lo que la gente necesitaba.

La lista de características y funciones que se usa para capturar requerimientos puede contribuir al resultado negativo, porque esto no fuerza a los involucrados (stakeholders) a considerar los requerimientos en un contexto largo de uso del sistema en un escenario que alcance algún resultado observable de valor o alguna meta. En contraste, los Casos de Uso colocan características y funciones en un contexto orientado-metas.

6.9 Agrupando Funciones Dentro de Casos de Uso.Recuerda que un Caso de Uso es siempre un procedimiento completo que

inicia y termina con el sistema estable. Algunas veces sin embrago, puede ser difícil decidir cuándo agrupar juntos o separados funciones relacionadas. No hay una regla para esto ya que se depende de un número de factores, acá hay alguna guía:

Pag. 24 de 40

Escribiendo Casos de Uso Efectivos Si el Caso de Uso es menos de una página, piensa en involucrarlo en otra

funcionalidad o procedimiento de un Caso de Uso relacionado. Si más de un Caso de Uso se relacionan a una pantalla, piensa en

acomodarlos juntos procurando que el Caso de Uso resultante no sea mayor de 5 páginas. Por ejemplo: los Casos de Uso: Agregar, Editar, y Eliminar deben ser considerados dentro de un Caso de Uso llamado “Administrar Entidades”

El flujo básico deberá empezar con un enunciado de Caso de Uso en el cual el usuario selecciona cual flujo desea ejecutar.

En un sistema de tamaño medio existen entre 25 y 75 Casos de Uso en total.

No definas cada flujo alterno en un Caso de Uso como un Caso de Uso. No definas cada paso en un Caso de Uso como un Caso de Uso. Debe ser posible correr el Caso de Uso en su propio entorno sin

necesidad de correr otro Caso de Uso como parte de la misma secuencia.

No se deben crear Casos de Uso que se sienten a esperar por horas o días en la mitad en espera de que algo pase. Finalízalo al inicio de la espera y define el evento que significa el final de la misma como el inicio del siguiente Caso de Uso.

6.10 La Anatomía de una InteracciónLa combinación de verbos y enunciados son insuficientes para definir una

interacción. Esto es solamente el mensaje que pasa desde la fuente al objetivo. Si la fuente y el objetivo no están definidos entonces la interacción es, a lo mucho, ambigua. Así que:

Pregunta qué datos o eventos pasan desde qué a qué cruzando el contexto del sistema.

Siempre incluye la fuente y el objetivo (target) Asegúrate que el enunciado no sea interpretado en más de una forma. No incluyas cosas como “El sistema verifica al cliente”, no es necesario

verificar la información en el flujo básico porque nosotros asumimos que toda la información introducida es correcta. Entradas incorrectas serán

Pag. 25 de 40

Fuente Acción (Parámetros) ObjetivoNinguna Introduce el apellido NingunoEl usuario Introduce el apellido dentro del sistema

INTERACCIÓN

MENSAJE

Escribiendo Casos de Uso Efectivosdetectadas y la respuesta será definida en los flujos alternos que manejan estas excepciones del sistema.

No uses verbos pasivos. Ejemplo, “El cliente es verificado”. ¿Qué quiere esto decir? ¡Si, es un cliente! ¿Y?

Nosotros estamos definiendo un posible flujo de eventos en términos de interacciones que cruzan el contexto del sistema así que solamente verbos activos nos serán de utilidad.

Define un completo, al punto y no ambiguo enunciado de qué pasa actualmente (hablando del problema que se está tratando de resolver) sin describir cómo es solucionado actualmente. Esto provee un alcance para el desarrollador para decidir cuál es el mejor camino para implementar una interacción

6.10.1 Agregando InteracciónParte del flujo básico en un Caso de Uso puede ser iterar a través de un

número de pasos. De ser así, entonces el problema es definir la interacción usando lenguaje natural y no el complejo idioma que usan los constructores de computadoras, de tal manera que nuestro documento quede entendible para personas como los usuarios que no conocen de “tecnicismos”. Esto requiere el uso de un enunciado, usualmente al final del ciclo (loop) el cual define la interacción en términos de dónde empieza, dónde termina y la condición para salir del ciclo (loop).

Esto puede ser hecho de varias maneras, la más simple es generalmente la más efectiva porque ellas son fáciles de entender.

Usa la siguiente guía:

1.- El usuario introduce el número de artículo al sistema2.- El sistema muestra los detalles del artículo al usuario3.- El usuario introduce la cantidad requerida al sistema4.- El sistema muestra el precio del artículo y el valor total de la orden al usuario.5.- Pasos 1 a 5 pueden ser repetidos6.- El usuario introduce los detalles del pago al sistema

Numera cada enunciado en el flujo y refiere a ellos en la interacción en los puntos de principio y fin.

La condición de salida del ciclo (loop) es seguido por la ocurrencia del siguiente evento, si es un evento externo que causa la salida del loop entonces la condición puede no ser necesario que sea especificada en el enunciado de interacción.

Si la condición que causa la salida del loop es internamente calculada, entonces un enunciado de esa condición necesitará ser incluido en la sentencia de interacción.

Cualquier simple excepción al flujo básico normalmente es especificada en un flujo alterno en un párrafo separado del flujo básico.

Si la interacción y la selección son múltiples y anidadas entonces el mejor acercamiento es no intentar describirla usando palabras. En vez de

Pag. 26 de 40

Escribiendo Casos de Uso Efectivoseso, define cada flujo como un sub-flujo separado y unas un diagrama de actividad el cual se refiere a cada flujo.

6.11 El Lenguaje de Texto del Caso de Uso.Cuando escribas el flujo considera interacciones actuales con el sistema.

Piensa en términos de qué información, comandos o eventos están yendo dentro y fuera del sistema y describe cada uno en un enunciado numerado y sencillo.

No continúes el enunciado con comas o “y”. Esto implicaría que la interacción ha sido combinada. De ser necesario, crea un prototipo de la pantalla o una interfase de usuario con miras a asegurar que el texto del Caso de Uso empata (match) con las interacciones actuales del sistema.

¡ATENCION! Esto no quiere decir diseñar la interfase de usuario como el prototipo, es meramente una sugerencia, a menos que un diseño detallado de la interfase de usuario sea importante para el él, en cuyo caso esto es un requerimiento y no solamente diseño.

Sigue la siguiente guía: Inicialmente incluye solamente interacciones actuales que crucen el

contexto del sistema. Intenta hacer cada interacción como parte de “un algo” que será

implementado en el sistema. Recuerda que el sistema son eventos controlados y cualquier cosa será una respuesta a una interacción.

La funcionalidad interna que no cruza el contexto del sistema puede ser incluida si es esencial para especificar qué el sistema debería hacer. Ejemplo: El sistema deberá salvar un registro de la orden. Sin embargo cuando especificamos funcionalidad interna usamos el menor número de palabras posibles. Si esto requiere más de un enunciado entonces este algoritmo debe ser especificado en el Modelo de Análisis del Sistema.

Sé consistente en la terminología. Si usas diferentes palabras para la misma cosa entonces cuando creas un modelo de datos para el sistema deberá haber una lista de “alias”. Usa un diccionario para el sistema para definir cada palabra en orden a producir especificaciones no ambiguas

No “seas tentado” a incluir interacciones “fuera de alcance” que no crucen el contexto del sistema sólo para proveer un “alcance de diseñador”. Esto sólo lo puedes hacer en modelado de negocio.

Pag. 27 de 40


6.12 Diagramas de Actividad.Un diagrama de actividad puede ser usado como suplemento del texto en los

Casos de Uso con la intención de mostrar actividades de interacción complejas y obtener una vista del flujo del Caso de Uso. Sin embargo, no permitas que los diagramas de actividad remplacen el texto de los Casos de Uso.

Las actividades, en cajas ovaladas, se nombran iniciando con un verbo activo.

Pag. 28 de 40


La flecha indica el orden en el cual las actividades ocurren. Este es el thread de actividad.

Una condición, en corchetes, puede ser usada para apoyar el thread hasta que la condición se vuelva verdadera.

Si hay múltiples salidas desde una actividad, como desde “Encontrar Registro del Cliente” entonces todas las salidas de los threads no deben estar saturadas de condiciones. Esto indicaría un switch dentro de la actividad.

Lo anterior también aplica para una desición, un símbolo de desición, puede ser usado para indicar un switch entre actividades.

El diagrama de actividad debe contener un “Estado de Inicio” y puede contener un “Estado Final”

6.13 Prototipos de PantallaUn prototipo de pantalla es una muy útil segunda vista del Caso de Uso.

Es otra ayuda para usuarios que “cuelgan sus ideas” cuando están tratando de explicar lo que ellos quieren.

Pag. 29 de 40


Esto provee un aspecto estructural al aspecto de proceso del texto de Caso de Uso

Esto provee un espacio para indicar formatos detallados de datos y restricciones de información que no pertenecen al texto del Caso de Uso.

El prototipo de pantalla debe ser consistente con el texto de Caso de Uso No tiene que ser construido con tecnología de punta. El que está en el

ejemplo se elaboró con las figuras que están en Word. El monto de detalle en el diseño de la pantalla en este punto debe ser

proporcional a la importancia de los usuarios. En otras palabras, esto debe contener solamente lo que es un requerimiento de usuario no detallado las decisiones en el diseño que no son importantes para los usuarios.

6.14 Tipos Formatos.

6.14.1 Formato de Caja NegraCasos de Uso de caja negra (Black-box use cases) son el tipo mas usado y recomendado, ellos no describen el trabajo interno del sistema, sus componentes o su diseño. En vez de eso, el sistema es descrito como teniendo responsabilidades lo

cual es tema de una metáfora común unificada en orientado-objetos, pensando qué elementos del software tienen responsabilidades y colaboran con otros elementos que también tienen responsabilidades.

Definiendo responsabilidades del sistema con Casos de Uso de caja negra, es posible especificar qué el sistema debe hacer (Requerimientos funcionales) sin decidir cómo hacerlo (el diseño). Por lo tanto, la definición de “Análisis” V.S. “Diseño” es algunas veces sumarizada como “Qué” V.S. “Cómo”

Esto es un tema importante en el buen desarrollo de software. Durante el análisis de requerimientos evita hacer decisiones del “cómo” y especifica la conducta externa del sistema, como una caja negra. Mas tarde, durante el diseño crea una solución que satisfaga la especificación.

Pag. 30 de 40

Escribiendo Casos de Uso EfectivosEstilo de Caja Negra Evita esto

El Sistema registra la venta. El sistema escribe la venta a la base de datos. … (o peor aún) :El sistema genera un enunciado SQL INSERT para la venta …

7.1 Tipos de FormalidadLos Casos de Uso son escritos en diferentes formatos, dependiendo de la necesidad. En adición a la caja negra V.S. caja blanca tipo de visibilidad, hay varios grados de formalidad.

Breve.- Un párrafo sumarizado, usualmente el primer escenario de éxito. o Flujo Básico: Introducir Orden:

1.- El usuario Encuentra un Registro del Cliente; 2.- El usuario introduce el número de artículo al sistema. 3.- El sistema muestra …

Casual.- Formato de párrafo informal. Múltiples párrafos que cubren varios escenarios

o Manejar Devoluciones Principal escenario de éxito.

Un cliente llega al mostrador de servicio al cliente para regresar algunos artículos. El cajero usa el sistema POS para registrar cada artículo que se va a devolver.

Escenario Alterno: Si la autorización del crédito es rechazada informa al

cliente y le pregunta por otra opción de pago. Si el artículo no es encontrado en el sistema, informa

al cajero y le sugiere que introduzca el código manualmente para identificar el artículo (quizá este corrupto)

Si el sistema encuentra una falla para comunicarse con el sistema que calcula los impuestos,…

Formato Formal.- Es el mas elaborado. Todos los pasos y variaciones son escritos en detalle y hay secciones de soporte tales como pre condiciones y garantías de éxito.

Los Casos de Uso en formato formal muestran el detalle y son estructurados. Ellos son de mucha utilidad en orden de obtener un profundo entendimiento de las metas, tareas y requerimientos. En el caso de estudio de nuestro sistema ProxGen Pos ellos deben ser creados en una etapa temprana de los workshops de requerimientos en colaboración con el analista del sistema, los expertos de la materia y los desarrolladores

Pag. 31 de 40

Escribiendo Casos de Uso EfectivosEl siguiente ejemplo es un caso en Formato Formal para nuestro ProxGen caso de estudio:

7.2 Caso de Uso UC1: Procesar Ventas (Ejemplo en formato formal)Actor Primario: Cajero.Stakeholders e intereses:

- Cajero: Quiere calcular, entradas rápidas y no errores en los pagos. Como cajero, los faltantes le son descontados de su salario.

- Personal de Ventas: Quiere las comisiones de sus ventas actualizadas en todo momento.

- Cliente: Quiere comprar y un servicio rápido con el mínimo esfuerzo. Quiere comprobantes de sus compras por si necesita hacer una devolución.

- Compañía: Quiere calcular las transacciones de los registros y satisfacer las necesidades del cliente. Quiere asegurarse que las autorizaciones de los servicios de pago son registrados. Quiere alguna tolerancia a fallas para permitir capturar ventas aún si componentes del servidor (ej. Validación remota del crédito) no están disponibles. Quiere actualizaciones instantáneas de la contabilidad y del inventario.

- Agencias del Gobierno: Quieren recabar los impuestos de cada venta- Servicio de Autorización de Pagos: Quieren recibir autorización digital en el

formato correspondiente y protocolo. Quiere calcular el monto de sus pagos a la tienda.

Precondiciones: El cajero es identificado y autorizado a ingresar al sistema.Garantía de Éxito (Post condición): La venta es guardada. El impuesto es correctamente calculado. El inventario y la contabilidad son actualizados. La comisión es guardada. El recibo es generado. Escenario Principal de Éxito (o Flujo Básico):

1. El cliente se acerca al mostrador con artículos o servicios para comprar.2. El cajero empieza una nueva venta3. El cajero introduce el código del artículo4. El sistema registra la línea de venta y presenta la descripción del artículo, precio, y

el total hasta ese momento. El cajero repite los pasos 3-4 hasta que ha registrado todos los artículos5. El sistema presenta el total con los impuestos calculados6. El cajero le dice al cliente el total y pregunta por la forma de pago.7. El cliente paga y el sistema maneja el pago8. El sistema encapsula la venta completa y la envía junto con la información de forma

de pago al sistema externo de contabilidad (para contabilidad y comisiones) y sistema de inventario (para actualizar el inventario)

9. El sistema presenta el recibo10. El cliente se va con sus cosas (si las hay)

Extensiones (o Flujos Alternos):*a. En cualquier momento, el sistema falla:

Para soportar y corregir la contabilidad asegura todas las transacciones a un estado sensitivo y los eventos pueden ser recuperados desde cualquier paso del escenario.1. El cajero reinicia el sistema, ingresa (log in) y hace una petición de recuperar el

estado previo del sistemaPag. 32 de 40

Escribiendo Casos de Uso Efectivos2. El sistema reconstruye el estado previo

2a El sistema detecta anomalías previniendo el recuperar el estado actual:1. El sistema firma un error al cajero, registra el error, introduce un estado

limpio2. El cajero inicia una nueva venta

3a Identificador invalidado1.- El sistema informa un error y rechaza la entrada

3b Hay muchos artículos de la misma categoría y registrarlos como un único artículo no es realmente importante (Ej., 5 paquetes de pan para hamburguesa):

1. El cajero puede introducir el identificador del artículo y la cantidad3-6a: El cliente pide al cajero que quite unos artículos de su compra:

1. El cajero introduce el identificador del artículo para borrarlo de la venta2. El sistema muestra el total actualizado

3-6b: El cliente le dice al cajero que cancele la venta1. El cajero cancela la venta en el sistema

3-6c: El cajero suspende la venta1 El sistema registra la venta axial que es esta está disponible en cualquier Terminal del sistema POS

4a: El precio generado por el sistema a la hora de introducir el artículo no es el deseado (Ejemplo, el cliente se queja acerca de algo y se le ofrece un bajo precio):

1 El cajero introduce un precio y sobrescribe el anterior2 El sistema presenta el nuevo precio

5a El sistema detecta una falla para comunicarse con un servicio externo para calcular impuestos:

1. El sistema reinicia el servicio en el nodo POS y continua1a El sistema detecta que el servicio no reinicia

1. El sistema señala el error2. El cajero puede calcular el impuesto manualmente e introducirlo o

cancelar la venta5b El cliente dice que él es elegible para un descuento (ejemplo, empleado, cliente preferencial):

1. El cajero requiere el descuento 2. El cajero introduce la identificación del cliente3. El sistema presenta el descuento total, basado en las reglas de negocio

5c El cliente dice que él tiene un crédito en su cuenta para aplicar a la venta:1. El cajero requiere el crédito2. El cajero introduce la identificación del cliente3. El sistema aplica el crédito hasta que el precio sea =0, y reduce el crédito

remanente.6a El cliente dice tener la intención de pagar con efectivo pero no tiene suficiente:

1a El cliente usa un método de pago alterno1b El cliente dice al cajero que cancele la venta. El cajero cancela la venta en el

sistema7a Pagos con efectivo

1. El cajero teclea la cantidad de dinero recibida del cliente2. El sistema presenta la cantidad que se debe o el cambio a regresar

Pag. 33 de 40

Escribiendo Casos de Uso Efectivos3. El cajero deposita el dinero y regresa el balance al cliente en efectivo4. El sistema registra el pago en efectivo

7b. Pago a crédito.1. El cliente introduce la información de la cuenta de crédito2. El sistema envía la requisición del pago a un sistema de Servicio de Pagos

externo y solicita la aprobación del pago.2a El sistema detecta una falla para colaborar con el sistema externo

1. El sistema envía un error al cajero2. El cajero pregunta al cliente por una forma alterna de pago.

3. El sistema recibe la aprobación del pago y señala la aprobación al cajero3a El sistema recibe negación del pago:

1. El sistema muestra la negación al cajero2. El cajero pregunta al cliente por un pago alterno

4. El sistema registra el pago con crédito, el cual incluye la aprobación del crédito5. El sistema presenta el pago a crédito e imprime el recibo para que lo firme el cliente.6. El cajero solicita al cliente su firma. El cliente firma el recibo (baucher)

7c. Pagando con cheque…7d. Pagando con débito…:7e. El cliente presenta cupones:

1. Antes de manejar el pago, el cajero registra cada cupón y el sistema reduce el precio según sea para cada artículo. El sistema registra los cupones usados por razones de contabilidad.1a El cupón introducido no es para cualquier artículo que se compra

1. El sistema muestra un error al cajero9a Hay productos con descuento

2. El sistema presenta las formas de descuento y rebaja el precio para cada artículo con descuento

9b El cliente solicita su recibo de regalo (el precio no está visible)2. El cajero solicita un recibo de regalo y el sistema lo presenta

Lista de Tecnología y lista de Variaciones de Datos:

3 a. Los identificadores de los artículos deben ser introducidos por un scanner láser y código de barras (si este código está presente) o teclado3b. El identificador del artículo puede ser un código en el esquema de UPC, EAN, JAN, SKU.7 a. La información de la tarjeta de crédito debe ser introducida por un lector de tarjeta o por el teclado.7b. La firma de la tarjeta de crédito la debemos capturar en un recibo de papel. Pero dentro de dos años, nosotros predecimos que muchos clientes querrán capturar su firma digital

Temas abiertos:- ¿Qué sucede con las variaciones en la ley de impuestos?- Explora el tema de recuperación de servicios remotos.- ¿Debe llevar un cajero su caja de efectivo cuando salga del sistema?

Pag. 34 de 40

Escribiendo Casos de Uso Efectivos- ¿Puede el cliente desplazar por sí mismo la tarjeta de crédito o lo debe hacer el

cajero?

Este caso de uso es mas ilustrativo que exhaustivo (ha pesar de que está basado en requerimientos reales de un sistema de POS) No importa, hay suficiente detalle y complicación para ofrecer un sentido real de que un caso de uso en un formato completo puede registrar muchos detalles del requerimiento. Este ejemplo nos servirá como modelo para muchos problemas de Casos de Uso.

¿Por qué es el cajero y no el cliente el actor primario en el Caso de Uso Procesar Venta? ¿Por qué el cliente no aparece en la lista de metas de actores?

La respuesta depende del contexto del sistema bajo diseño, como se ilustra en la siguiente figura:

¿Por qué el Cajero y no el Cliente es el Actor Primario?

Sistema POS

Caja

Cajero

Meta: Procesar Ventas

Empresa Vendiendo Cosas

Sistema deVentas

Meta:Analizar Ventas yDesempeño de Datos

Cliente

Meta: ComprarCosas

Meta: RecolectarImpuestos de Ventas

Secretaria de Impuestos

Si vemos la corporación, el servicio de registro como un sistema agregado, el cliente es un actor primario, con la meta de obtener bienes o servicios e irse. Sin embargo, desde el punto de vista solamente del sistema POS (el cual es la selección del contexto del sistema para este caso de estudio), le sirve a la meta del cajero (y la tienda) para procesar la venta del cliente.

7.3 Caja Negra o Dos ColumnasAlgunos prefieren el formato de dos columnas o conversacional, el cual enfatiza el hecho de que hay una interacción activa entre los actores y el sistema. Este formato fue propuesto por Rebecca Wirfs-Brock in [Wirfs-Brock93] y es también promocionado por Constantine y Lockwood para ayudar al análisis de la usabilidad y la ingeniería.

Pag. 35 de 40

Escribiendo Casos de Uso EfectivosAcá presentamos el mismo contenido del caso de uso anterior pero en formato de dos columnas:

Caso de Uso UC1: Procesar Ventas (Ejemplo)Actor Primario: Cajero.

Stakeholders e intereses:- Cajero: Quiere calcular, entradas rápidas y no errores en los pagos. Como cajero, los

faltantes le son descontados de su salario.- Personal de Ventas: Quiere las comisiones de sus ventas actualizadas en todo

momento.- Cliente: Quiere comprar y un servicio rápido con el mínimo esfuerzo. Quiere

comprobantes de sus compras por si necesita hacer una devolución.- Compañía: Quiere calcular las transacciones de los registros y satisfacer las

necesidades del cliente. Quiere asegurarse que las autorizaciones de los servicios de pago son registrados. Quiere alguna tolerancia a fallas para permitir capturar ventas aún si componentes del servidor (ej. Validación remota del crédito) no están disponibles. Quiere actualizaciones instantáneas de la contabilidad y del inventario.

- Agencias del Gobierno: Quieren recabar los impuestos de cada venta- Servicio de Autorización de Pagos: Quieren recibir autorización digital en el

formato correspondiente y protocolo. Quiere calcular el monto de sus pagos a la tienda.

Precondiciones: El cajero es identificado y autorizado a ingresar al sistema.Garantía de Éxito (Poscondición): La venta es guardada. El impuesto es correctamente calculado. El inventario y la contabilidad son actualizados. La comisión es guardada. El recibo es generado.

Escenario Principal de Éxito (o Flujo Básico): Procesar Ventas

Intención del Actor Responsabilidad del Sistema

1.El cliente se acerca al mostrador con artículos o servicios para comprar2.El cajero empieza una nueva venta3.El cajero introduce el código del artículo

4.- El sistema registra la línea de venta y presenta la descripción del artículo, precio, y el total hasta ese momento.

El cajero repite los pasos 3-4 hasta que ha registrado todos los artículos

5. El sistema presenta el total con los impuestos calculados

6. El cajero le dice al cliente el total y pregunta por la forma de pago.

7. El cliente paga

8. El sistema encapsula la venta completa y la envía junto con la información de forma de pago al sistema externo de contabilidad

Pag. 36 de 40

Escribiendo Casos de Uso Efectivos(para contabilidad y comisiones) y sistema de inventario (para actualizar el inventario)9. El sistema presenta el recibo

… …

7 El formato de usecases.orgExisten varias plantillas de formatos para escribir Casos de Uso en formato formal. Sin embargo, quizá el mas ampliamente extendido y usado sea la plantilla disponible en www.usecases.org El siguiente ejemplo ilustra este estilo.

Por favor nota que este es el ejemplo del caso de estudio primario de un caso de uso detallado esto muestra muchos elementos comunes.

8 ¿Cuál es el Mejor Formato?No hay “un mejor formato”, algunos prefieren el estilo de una columna, algunos otros el dos columnas. Las secciones pueden ser agregadas o eliminadas, los nombres de los encabezados pueden cambiar, nada de esto es particularmente importante; el punto en el que hay que pensar, el que realmente hay que tomar en cuenta es el de escribir los detalles del principal escenario de éxito y las extensiones en la misma forma. Cockburn sumariza muchos formatos usables.

9 Explicando las Secciones9.1 Elementos de Prefacio

Muchos elementos de prefacio son posibles. Hay que colocar elementos al inicio los cuales son importantes para leer antes de describir el escenario principal de éxito. El material con “extraños encabezados” se coloca al final del Caso de Uso.

9.2 Actor PrimarioEl actor principal que invoca a los servicios del sistema para llenar una meta.

9.3 Lista de Intereses y Stakeholders.Esta es la lista mas importante y práctica que puede aparecer en el primer “vistazo” Esta sugiere que es lo que debe hacer el sistema. Es decir:

Pag. 37 de 40

Práctica PersonalEsta es mi práctica, no una recomendación. Por muchos años usé el formato de dos columnas por su clara separación visual en la conversación. Sin embargo, he regresado al formato de una columna, por ser un estilo mas compacto y fácil cosa que no me otorga el formato de dos columnas. Yo encuentro esto simple para visualizar las dos partes de la conversación (Cliente, Sistema…,) si las respuestas de cada parte y del Sistema están usualmente localizadas en sus propios pasos.

http://www.usecases.org/

Escribiendo Casos de Uso EfectivosEl [Sistema] opera un contrato entre el stakeholder, con el Caso de Uso detallando la conducta de las partes de ese contrato… El Caso de Uso, como contrato de la conducta, captura todas y solamente las conductas relacionadas a satisfacer los intereses de los stakeholders.

Esto contesta la pregunta: ¿Qué debe estar en el Caso de Uso? La respuesta es: Lo que satisface los intereses del stakeholder. En adición, hay que empezar con aquello que satisface las necesidades del stakeholder antes de escribir el remanente del Caso de Uso. Con esto nosotros tenemos un método para recordarnos que es lo que deben hacer las responsabilidades más detalladas del sistema. Por ejemplo: ¿Se debe identificar una responsabilidad para el manejo de comisiones de la fuerza de ventas si no se tiene una lista de stakeholders que representan a esa fuerza y sus intereses?El punto de vista del stakeholder en la entrevista, provee del conocimiento de un procedimiento metódico para descubrir y registrar todas las conductas requeridas.

Stakeholders e intereses:- Cajero: Quiere calcular, entradas rápidas y no errores en los pagos. Como cajero, los

faltantes le son descontados de su salario.- Personal de Ventas: Quiere las comisiones de sus ventas actualizadas en todo

momento.- …9.4 Pre Condiciones y Post Condiciones (Garantías de Éxito)

El estado de las precondiciones debe ser siempre verdadero antes de empezar un escenario en el Caso de Uso. Las precondiciones no deben ser probadas dentro del Caso de Uso, en vez de eso ellas son condiciones que se asumen como verdaderas. Típicamente, una precondición implica un escenario de otro Caso de Uso que se ha completado satisfactoriamente, como un log in o el mas general, “el usuario ha sido identificado y permitido su acceso al sistema”. Es importante tomar en cuenta que a pesar que el valor de la precondición debe ser verdadera, no siempre es una precondición con valor práctico o escrito, ejemplo: “El sistema tiene corriente”. Las precondiciones comunican información por parte quien escribe el caso de uso sobre la cual éste piensa que el lector del caso de uso debe ser informado o alertado.El estado de Garantía de Éxito (o Post Condición) debe ser verdadero. Es decir, debe haber terminado satisfactoriamente el caso de uso – ya sea en el escenario de éxito principal o algún camino alterno.La garantía debe cubrir las necesidades de todos los stakeholders

9.5 Extensiones (Flujos Alternos)Las extensiones son muy importantes, ellas indican todos los otros escenarios, tanto de falla como de éxito. Observe en el ejemplo del caso de uso en formato completo que la sección de Extensiones fue más larga y compleja que la sección de escenario de éxito; esto es común y esperado. Las Extensiones son también conocidas como Flujos Alternos.La combinación de escenarios de “días felices” y escenarios de Flujos Alternos deben satisfacer por mucho las necesidades de los stakeholders. Este punto es calificado porque algunos intereses pueden ser mejor capturados como

Pag. 38 de 40

Escribiendo Casos de Uso Efectivosrequerimientos no funcionales expresados en el documento de Especificaciones Suplementarias en vez de en un caso de uso.Los escenarios de extensión son saltos desde el principal escenario de éxito. Por ejemplo, en el paso 3 del escenario principal de éxito puede ser invalidado el identificador de un artículo, ya sea porque fue incorrectamente introducido o bien por ser desconocido por el sistema. Una extensión es etiquetada “3a” Primero identifica la condición y entonces la respuesta. Extensiones alternas en el paso 3 son etiquetadas “3b” y así consecutivamente.

Extensiones:3a Identificador invalidado1.- El sistema informa un error y rechaza la entrada3b Hay muchos artículos de la misma categoría y registrarlos como un único artículo no es realmente importante (Ej., 5 paquetes de pan para hamburguesa):2. El cajero puede introducir el identificador del artículo y la cantidad

Una extensión tiene dos partes. La condición y el manejo.La condición se escribe como algo que puede ser detectado por el sistema o un actor. Ejemplo:

5a El sistema detecta una falla para comunicarse con un servicio externo para calcular impuestos:

Este estilo es preferido porque es algo que el sistema puede detectar.

El manejo de extensiones puede ser sumarizado en un paso o incluir una secuencia, como en este ejemplo el cual también indica la notación para indicar una condición puede incluirse dentro de un rango de pasos:

3-6a: El cliente pide al cajero que quite unos artículos de su compra:1. El cajero introduce el identificador del artículo para borrarlo de la venta2. El sistema muestra el total actualizado

Al final del manejo de la extensión, por default el escenario regresa al principal escenario de éxito a menos que la extensión indique otra cosa. (Ejemplo, abortar el sistema.) Algunas veces, un punto de extensión en particular es complejo como en la extensión “Pago a Crédito”. Esto puede ser motivo para expresar la extensión como un Caso de Uso separado.

Este ejemplo de extensión, también demuestra la notación para expresar fallas dentro de las extensiones.7b. Pago a crédito.1. El cliente introduce la información de la cuenta de crédito2. El sistema envía la requisición del pago a un sistema de Servicio de Pagos

externo y solicita la aprobación del pago.2a El sistema detecta una falla para colaborar con el sistema externo

Pag. 39 de 40

Escribiendo Casos de Uso Efectivos1. El sistema envía un error al cajero2. El cajero pregunta al cliente por una forma alterna de pago.

3. …

Es deseable escribir una extensión tanto como sea posible durante cualquier paso, las etiquetas *a, *b,… pueden ser usadas.

*a. En cualquier momento, el sistema falla:Para soportar y corregir la contabilidad asegura todas las transacciones a un estado sensitivo y los eventos pueden ser recuperados desde cualquier paso del escenario.3. El cajero reinicia el sistema, ingresa (log in) y hace una petición de recuperar el

estado previo del sistema4. El sistema reconstruye el estado previo

9.6 Requerimientos No Funcionales (o Requerimientos Especiales)Si un requerimiento no funcional, atributo de calidad, o restricción se relaciona específicamente a un caso de uso, debe registrarse esto con del caso de uso. Esto incluye atributos de calidad como de Performance, Reliability Usability y restricciones en el diseño (lo cual es común en dispositivos de I/O) que han sido mandatorios o considerados como tales.

Requerimientos No Funcionales:- Monitor plano con pantalla sensible al tacto (touch screen) El texto

debe ser visible desde un metro de distancia.- La respuesta de las autorizaciones de crédito debe de ser de no más

de 3 segundos en el 90% de las transacciones.- Nosotros queremos robustecer la recuperación cuando los servicios

de acceso remoto, como el sistema de inventarios, esté fallando.

Lista de Tecnología y lista de Variaciones de Datos:3 a. Los identificadores de los artículos deben ser introducidos por un scanner láser y código de barras (si este código está presente) o teclado3b. El identificador del artículo puede ser un código en el esquema de UPC, EAN, JAN, SKU.7 a. La información de la tarjeta de crédito debe ser introducida por un lector de tarjeta o por el teclado.

Pag. 40 de 40

Aprendiendo a escribir Casos de Uso Efectivos

Documents

Transcript of Aprendiendo a escribir Casos de Uso Efectivos