Escrito sobre los Casos de Uso aplicados como metodología para diseño de la Construcción de Software.

1. DOCUMENTO O GUÍA
Casos de Uso
Casos de Uso
¿Cómo los defino?
¿Qué debo entender de ellos?
Fecha
Versión
Autor
Páginas
02/09/2011
1
Byron Quisquinay
1 / 15

2. DOCUMENTO O GUÍA
Casos de Uso
Fecha
Versión
Autor
Páginas
02/09/2011
1
Byron Quisquinay
2 / 15
CONTENIDO DE ESTE DOCUMENTO
CONTENIDO DE ESTE DOCUMENTO........................................................................2
OBJETIVO:.......................................................................................................................3
ALCANCE:.......................................................................................................................3
Casos de Uso (del inglés Use Cases) ¿Cómo interpretar el término?................................3
Casos de Uso en la Práctica...............................................................................................4
Casos de Uso – en un Proceso del negocio ..................................................................5
Casos de Uso – Aplicado a los Sistemas de Información pero no aún como un
requerimiento relacionado a los mismos ......................................................................6
Casos de Uso – Aplicado a los Sistemas de forma técnica y derivada de una solicitud
de cambio.......................................................................................................................6
Levantando Requerimientos..............................................................................................7
¿Algo unilateral? ..........................................................................................................7
¿Alguna idea de cómo iniciar? .....................................................................................8
¿Usuario?...................................................................................................................8
¿Entorno?...................................................................................................................8
¿A qué nivel de detalle y bajo qué enfoque? ................................................................9
¿Técnicas para construir los Casos de Uso?....................................................................10
Ejemplos..........................................................................................................................11
¿Después de todo esto qué debo de entender por caso de uso?.......................................15

3. DOCUMENTO O GUÍA
Casos de Uso
Fecha
Versión
Autor
Páginas
02/09/2011
1
Byron Quisquinay
3 / 15
OBJETIVO:
Cuando nos embarcamos en la utilización de normas o estándares, nos resulta
complicado el empleo de esas técnicas o herramientas. Y es que cuando leemos sus
definiciones nos parece muy sencillo y fácil de aplicar. Pero cuando nos enfrentamos a
una realidad, no resulta tan fácil como lo pensamos.
El presente documento tiene como fin el naturalizar los términos de los Casos de
Uso y ser una guía para la definición de los mismos, dado un requerimiento o problema
que requiere solución basada en Software o no.
ALCANCE:
Se involucra la unidad de Desarrollo de Sistemas.
Casos de Uso (del inglés Use Cases) ¿Cómo interpretar el término?
En lo personal no logro formar en mí una idea clara de los casos de uso. Y es que no
me resulta familiar, mucho menos natural. Es decir, cuando empleamos el idioma
español por lo regular logramos formar un esquema mental (idea) sobre lo dicho.
Bien, pero entonces logremos familiarizarnos con el tema. Formemos oraciones
con "Caso":
1. Lo que me decís no viene al "caso".
2. El "caso" es que ese día...
3. En referencia al presente proceso tomaremos como antecedente el "caso"
de...
Y si nos vamos a los sinónimos de "caso":
1. Asunto.
1.1 Tema.
2. Sumario
2.1 Proceso
2.2 Juicio
2.3 Procedimiento
3. Suceso
3.1 Circunstancia
3.2 Situación
Entonces ya en términos un tanto más familiares podríamos decir que "Caso de Uso"
= "Tema de Uso", "Proceso o Procedimiento en que se Usa", "Circunstancia o situación
de Uso".
Bien, entonces definamos que cuando estamos estipulando los "Casos de Uso"
estamos tratando de estipular:

4. DOCUMENTO O GUÍA
Casos de Uso
Fecha
Versión
Autor
Páginas
02/09/2011
1
Byron Quisquinay
4 / 15
"Los escenarios en que se desenvuelve el uso de la solución que deseamos
construir. Es decir, qué procesos o procedimientos se hacen necesarios para brindar la
solución a la situación o circunstancia que forma parte del problema planteado."
Casos de Uso en la Práctica
¿Entonces en la práctica y ante un proyecto, además del entorno de IT, cómo
deberían de ser empleados los Casos de Uso?
En el título anterior nos familiarizamos con el concepto. Más sin embargo los
Casos de Uso no son exclusivos del modelado de una solución basada en la
construcción de Software.
También son herramientas empleadas para describir en detalle comprensible y
de forma de un concepto lógico (es decir el patrón de respuesta) el flujo teórico de un
proceso de negocio.
Exploremos algunos conceptos:
A use case captures a contract between the stakeholders of a system about its
behavior1. The use case describes the system’s behavior under various conditions as it
responds to a request from one of the stakeholders, called the primary actor. The
primary actor initiates an interaction with the system to accomplish some goal. The
system responds, protecting the interests of all the stakeholders. Different sequences of
behavior, or scenarios, can unfold, depending on the particular requests made and
conditions surrounding the requests. The use case collects together those different
scenarios.
Use cases are fundamentally a text form, although they can be written using
flow charts, sequence charts, Petri nets, or programming languages. Under normal
circumstances, they serve to communicate from one person to another, often to people
with no special training. Simple text is, therefore, usually the best choice.
1.2 Your use case is not my use case
Use cases are a form of writing that can be put to use in different situations, to
describe
• a business' work process,
• to focus discussion about upcoming software system requirements, but not
be the requirements description,
• to be the functional requirements for a system, or
• to document the design of the system.
• They might be written in a small, close-knit group, or in a formal setting,
or in alarge or distributed group.2
1
Un caso de uso captura de un contrato entre las partes de un sistema sobre su comportamiento. Esta será una de las
únicas traducciones pues es menester que logremos leer en la lengua original.
2
WRITING EFFECTIVE USE CASES - Alistair Cockburn - Humans and Technology - copyright
A.Cockburn, 1999-2000.

5. DOCUMENTO O GUÍA
Casos de Uso
Fecha
Versión
Autor
Páginas
02/09/2011
1
Byron Quisquinay
5 / 15
Por cierto cuando se esté utilizando esta guía hay que recordar que no estoy abordando el tema
de UML como herramienta gráfica de modelado y que no estoy hablando de los Diagramas de Casos de
Uso de UML.
¿Entonces para qué esta guía? Puesto que la técnica de casos de uso, es una forma de expresar,
interpretar y comunicar el comportamiento de un Sistema (o funcionalidad del mismo) o bien el flujo de
actividades en un proceso de la empresa.
¿De qué sirve entonces tener noción de esta herramienta si lo que empleamos es UML? Pues
servirá para lograr captar la esencia de los casos de uso y luego ya podes emplear UML para modelar
los Casos de Uso que describen la solución al requerimiento o incidencia que es el objeto del desarrollo
que se esté realizando.
Casos de Uso – en un Proceso del negocio
¿Por qué se emplea la palabra proceso entornada a un negocio?
Dentro de las herramientas, técnicas, normas o estándares 3, se adopta un enfoque
de las empresas y estas se toman como un GRAN proceso que integrado por otros,
permite entregar un producto, bien o servicio a un cliente.
Es decir, ese enfoque no considera que la Gerencia de Ventas está integrada por
la Sub Gerencia de Canales, ese enfoque indica que dentro del Proceso de Ventas existe
un proceso de Inyección de Servicios, productos o bienes a los Canales de Distribución.
En resumen existe un enfoque basado en Procesos que permiten prestar un
servicio o crear un producto o un bien para satisfacer a un cliente.
¿Y cómo sería tomar ese enfoque? Pensemos en la introducción de una factura
en cada despacho de la red de ventas. ¿Qué implica esto, qué casos de uso debería
contemplar?
Pensemos que del proceso de Ventas se desgrana un proceso de distribución de
Producto y esta colocación es en dos tipos de Canales uno interno y otro externo.
Entonces para cada producto que se vende se factura, esto nos lleva a:
•
•
3
Si es una venta directa en un canal interno de la empresa se factura al cliente
en el momento de la venta.
Caso, contrario, si es en un canal externo, que se convierte en un distribuidor
o revendedor, se facturará según el tipo de despacho o venta:
o Como venta realizada final (liquidada). En este punto se
facturará todo el lote colocado.
o Como producto en consignación. Se facturará según el contrato
de liquidación.
Existen muchas modas, técnicas, herramientas, métodos, estándares, normas para emplearse en la
administración de los negocios, el estándar de ISO 9001:2000 por ejemplo utiliza el enfoque a procesos.

6. DOCUMENTO O GUÍA
Casos de Uso
Fecha
Versión
Autor
Páginas
02/09/2011
1
Byron Quisquinay
6 / 15
Nótese entonces que este enfoque no implica la construcción de Software o que
IT tenga injerencia en la solución. Y esto es debido a que se está apenas explorando el
impacto dentro del Proceso total del Negocio de la introducción de esta variable.
Casos de Uso – Aplicado a los Sistemas de Información pero
no aún como un requerimiento relacionado a los mismos
Cuando exploramos en sesiones el impacto que tendrá una variante a los
procesos del negocio, también se evalúa la factibilidad técnica y el método a emplear de
cara a los Sistemas empleados como soporte a los procesos del negocio.
Sigamos pues con el ejemplo de la facturación del producto. En la sesión se
estaría evaluando o quedaría como tarea el evaluar que
•
•
Si es una venta directa en un canal interno de la empresa se factura al cliente
en el momento de la venta. Se empleará el Sistema así:
o En oficinas centrales se debería utilizar el Sistema A.
o En oficinas rurales a través de una pantalla Web nueva.
Caso, contrario, si es en un canal externo, que se convierte en un distribuidor
o revendedor, se facturará según el tipo de despacho o venta:
o Como venta realizada final (liquidada). En este punto se
facturará todo el lote colocado.
 La factura se emitirá en las bodegas a través de la pantalla
Web nueva.
o Como producto en consignación. Se facturará según el contrato
de liquidación.
 Lo facturará el Vendedor – liquidador y lo hará en
oficinas centrales y por ende en el Sistema A.
En este punto aún no se evalúa el requerimiento a IT como tal, simplemente se
explora a generalidad la posibilidad de realizarlo y en qué sistemas o si se necesitará
algo nuevo pero no especificado a detalle.
Esto se asemeja pues a una definición Funcional del cambio requerido por la
variable introducida a un proceso del negocio.
Casos de Uso – Aplicado a los Sistemas de forma técnica y
derivada de una solicitud de cambio
En este momento ya se está abordando la solicitud de cambio y hay que pensar
en los escenarios que presenta el requerimiento de cara a los Sistemas existentes o a la
necesidad de un elemento más.
Es en donde empieza la acción y se realiza una evaluación de Factibilidad
Técnica y Funcional, además de definir: recursos tales como el tiempo aproximado,

7. DOCUMENTO O GUÍA
Casos de Uso
Fecha
Versión
Autor
Páginas
02/09/2011
1
Byron Quisquinay
7 / 15
humano e inversión monetaria. Con las definiciones anteriores se derivan objetivos
como Tiempo (de cara al reto del cambio del negocio, no siempre permite tomar el
tiempo necesario) y nivel del desarrollo (o nivel de calidad, se quiera o no muchas veces
la urgencia no permite la solución idónea, idealista o utópica).
Aquí se comienzan las preguntas de
℘ En qué Sistemas habrá impacto.
• En qué módulos del mismo.
• Impacta la Capa Visual, de datos, etc.
℘ Se necesita una nueva funcionalidad.
• Dentro de qué Sistemas.
o De esos Sistemas qué módulos.
℘ Se requiere el cambio a una funcionalidad existente.
• Dentro de qué Sistemas.
o De esos Sistemas qué módulos.
℘ ¿Qué impacto tiene este cambio con respecto del resto de Sistemas?
Ahora bien, no todos los desarrollos tienen que abordarse como un gran
proyecto, puesto que no todos lo son. Existirán algunos en los que las especificaciones
técnicas y funcionales no tendrán un gran detalle o suntuosidad.
Levantando Requerimientos
Tal como hemos visto en los temas anteriores los “Casos de Uso” al final de
cuentas son parte del levantado de un requerimiento. Pues es una técnica que permite
abarcar la mayor parte del detalle de una necesidad o problema dados. Esto, basado en
una comprensión aprendida por la investigación y/o evaluación del entorno de dicha
necesidad o problema.
¿Algo unilateral?
El mayor error del desarrollo de software es “asumir” y esto implica el modelado
y/o construcción de forma unilateral.
Y esto debido a que existe una necesidad derivada de una variante en las
actividades – procesos o procedimientos del negocio. Pero no solo eso, también puede
ser por variantes introducidas a los propios Sistemas, tales como una actualización de
Software o Hardware, quizá por un error fortuito. Lo cierto del caso es que hay una
necesidad.
Entonces la comprensión de la necesidad y quizá el bosquejo inicial de la
solución, deben ser consensuadas, si es que el caso lo amerita.
Ese consenso se busca con los expertos en el tema, organizados o no, esto último
por si existen burós de control o grupos de autorización, etc. Y no debe de existir nunca
la duda de si incluir o no al usuario, definitivamente si existe un “participante o actor”

8. DOCUMENTO O GUÍA
Casos de Uso
Fecha
Versión
Autor
Páginas
02/09/2011
1
Byron Quisquinay
8 / 15
del proceso que será el dueño de esa solución informática, será él parte fundamental de
la definición del problema, pero para no ser utópico, si dicho usuario no está en
capacidad de lo descrito anteriormente, definitivamente deberá estar enterado y
capacitado, además de estar de acuerdo.
¿Alguna idea de cómo iniciar?
Sin importar el tamaño y complejidad del proyecto en que uno se sumerja, es
muy importante comprender qué es lo que el usuario o el entorno esperarían como una
solución idónea. Y con eso se puede comenzar, por ejemplo:
¿Usuario?
Sí. El usuario definitivamente dará pautas inequívocas que si no son
preguntadas, serán parte del problema a la hora de la Explotación en Producción (live o
en vivo) de la solución.
Pautas de funcionalidad tales como:
1. En la pantalla yo debería de poderme “mover” solo con la tecla
TAB y con el teclado numérico.
2. Los reportes deberían salir en Excel.
Pautas de tradición o familiaridad:
Si se está migrando una funcionalidad (un Sistema completo o una
pantalla, etc.), definitivamente el usuario dará pautas de lo que espera como
solución:
1. En el otro Sistema yo tenía este o tal reporte.
2. Uno podía definir la información del cliente de tal o cual forma en el
otro Sistema.
3. El contrato se podía imprimir y siempre en tamaño carta.
Tenga muy presente que un proyecto puede caerse completamente y sin importar
su costo por falta de aceptación. Y en un proyecto o solución es muy importante que
todos los actores se sientan parte de la misma. Pero no solo de apariencia, que
realmente se viva la participación.
¿Entorno?
La solución puede estar basada en una comunicación con otro Software y quizá
esta solución no lo sea si no es bajo un estándar del mercado de informática. Entonces la
solución podrá ser muy bonita, muy eficiente y todo lo que se desee, pero si no la puede
interpretar el otro software o no puede ser administrada por la tercer parte involucrada,
simple y sencillamente no es funcional.
Por ello es de vital importancia tener conocimiento de los “requerimientos”
exigidos como mínimos o totales de la solución esperada.

9. DOCUMENTO O GUÍA
Casos de Uso
Fecha
Versión
Autor
Páginas
02/09/2011
1
Byron Quisquinay
9 / 15
¿A qué nivel de detalle y bajo qué enfoque?
El nivel de detalle lo define la necesidad en sí misma. Y se sabrá solo de una
forma: Consultando a los expertos y conocedores técnicos u operativos. De no poderse
sondear de esa manera, la forma de realizarlo será ensayando modelos de prueba que se
inserten como si fueran la solución y verificar qué es lo que sucede.
El enfoque lo definirá el público destino del modelado, levantado de
requerimiento o presentación de casos de uso. Basado en lo anterior, será definirá
como un Proceso de Negocio, relacionado a un Sistema de Información pero en forma
funcional o bien como un requerimiento a un Sistema de Información.
Para ejemplificar lo anterior podemos decir que:
 Si hablamos de la creación de un botón, quizá el nivel de detalle será
lo que sucede en base a los parámetros de la pantalla. Y según ello el
botón hará tal o cual cosa. Este punto enfocado a la presentación
funcional al usuario.
o Pero funcionalmente ese botón y su impacto en la base de datos
es mucho, pero que mucho más. Y necesita un modelado de qué
sucede cuando afecta un registro en una tabla y el resultado que
tiene en cascada a otras tablas. En este punto como definición
técnica de la solución.
 Y quizá amerite evaluar el impacto de haber agregado un
valor a un catálogo.
• Quizá no saldrá en un reporte.
• Quizá los registros con ese nuevo “estado por
ejemplo” ya no será tomados en cuenta en los
datos contables.

10. DOCUMENTO O GUÍA
Casos de Uso
Fecha
Versión
Autor
Páginas
02/09/2011
1
Byron Quisquinay
10 / 15
¿Técnicas para construir los Casos de Uso?
Básicamente en lo personal diría que para pensar en el detalle de una solución,
hay que tener escrito:
1. Un breve título que describa el problema o solicitud. Por lo regular
se puede tomar el que el usuario describe como requerimiento.
2. Quienes o qué definen el problema y la solución. Ellos brindarán la
base del diseño. Puede tratarse de una ley o un estándar de uso
obligatorio, eso dará el material suficiente para la definición inicial.
3. Quienes o qué interactúan con la solución. Ellos brindarán la base
de la presentación y las salidas de la solución.
4. Qué esperan los actores del punto 1 y 2. Definirá los requisitos
totales o iniciales de la solución.
5. Flujos de comportamiento (toma de decisiones).
6. Si aplica: Un listado de insumos necesarios para que funcione.
Quizá materiales, quizá de procedimiento. Quizá de software
(licencias, manejador de colas, etc.) Quizá de hardware.
7. Cómo se integra la solución a lo que ya existe. Esto definirá los
requisitos técnicos de integración.
Esta es una estructura sugerida de documentación del Caso de Uso.
Caso de uso: <Escribir una breve descripción, leyenda o texto que identifique al caso de uso>
Actores:
<Escribir listado de usuarios que harán uso de la solución.
Usuario(s) Final(es):
Usuarios clave:
Grupo Consultivo:
Problema:
Descripción:
Flujos del entorno:
Requisitos:
Descripción:
Listado:
Solución:
Descripción:
Flujos del entorno:
Se
deberá escribir la forma de identificar a esas personas, ya sea
por puesto, departamento, etc.>
<Escribir el listado de usuarios que aportan valor a la definición
de la solución. Se deberá escribir la forma de identificar a esas
personas, ya sea por puesto, departamento, etc.>
<Escribir el listado de personas que aportan valor a la
definición de la solución y que no son usuarios. Se deberá
escribir la forma de identificar a esas personas, ya sea por
puesto, departamento, etc.>
<Escribir un texto que permita identificar claramente de qué se
trata el problema a solucionar.>
<Describa los caminos y decisiones que se recorren en el
entorno del problema. Esta es la estructura secuencial que se
recorre sin la solución y en donde se plantea un problema. >
<Escribir un texto que ayude a comprender de qué tipo de
requisitos se está hablando. Pueden ser recursos: materiales,
técnicos, humanos, de tiempo, etc. >
<Describir un listado de requisitos para la solución, es decir,
qué se necesita para que la solución pueda darse. Si amerita se
puede y debe escribir un conjunto de características de esos
requisitos.>
<Escribir un texto que permita identificar claramente de qué se
trata el problema a solucionar. >
<Describa los caminos y decisiones que se recorren con la
solución. Se pueden y deben describir todos los flujos y
decisiones que deberá seguir la solución. E identificar cómo se
integra al flujo anterior o cómo lo modifica. Así pues si amerita
la escritura y separación en más apartados que describan casos
excepcionales es permitido y exigido.>

11. DOCUMENTO O GUÍA
Casos de Uso
Fecha
Versión
Autor
Páginas
02/09/2011
1
Byron Quisquinay
11 / 15
Precision is not the same as accuracy. If someone tells you, " π is
4.141592," they are using a lot of precision. They are, however, quite far off, or
inaccurate. If they say, "π is about 3," they are not using much precision (there
aren't very many digits) but they are accurate for as much as they said. The
same ideas hold for use cases.
You will eventually add details to each use case, adding precision. If
you happen to be wrong (inaccurate) with your original, low-precision
statement of goals, then the energy put into the highprecision description is
wasted. Better to get the goal list correct before expending the dozens of workmonths of energy required for a fully elaborated set of use cases.
I divide the energy of writing use cases into four stages of precision,
according to the amount of energy required and the value of pausing after each
stage:
1 Actors & Goals. List what actors and which of their goals the system will
support. Review this list, for accuracy and completeness. Prioritize and assign
to teams and releases. You now have the functional requirements to the first
level of precision.
2 Use case brief or main success scenario. For the use cases you have selected
to pursue, write the trigger and sketch the main success scenario. Review these
in draft form to make sure that the system really is delivering the interests of
the stakeholders you care about. This is the second level of precision on the
functional requirements. It is fairly easy material to draft, unlike the next two
levels.
3 Failure conditions. Complete the main success scenario and brainstorm all
the failures that could occur. Draft this list completely before working out how
the system must handle them all. Filling in the failure handling takes much
more energy than listing the failures. People who start writing the failure
handling immediately often run out of energy before listing all the failure
conditions.
4 Failure handling. Finally, write how the system is supposed to respond to
each failure. This is often tricky, tiring and surprising work. It is surprising
because, quite often, a question about an obscure business rule will surface
during this writing. Or the failure handling will suddenly reveal a new actor or
a new goal that needs to be supported. Most projects are short on time and
energy. Managing the precision to which you work should therefore be a
project priority. I strongly recommend working in the order given above.4
Ejemplos5
USE CASE 1: BUY STOCKS OVER THE WEB
Primary Actor:
Purchaser
4
WRITING EFFECTIVE USE CASES - Alistair Cockburn - Humans and Technology - copyright
A.Cockburn, 1999-2000.
5
WRITING EFFECTIVE USE CASES - Alistair Cockburn - Humans and Technology - copyright
A.Cockburn, 1999-2000.

12. DOCUMENTO O GUÍA
Casos de Uso
Scope:
Level:
Stakeholders and Interests:
Precondition:
Minimal guarantee:
Success guarantee:
Fecha
Versión
Autor
Páginas
02/09/2011
1
Byron Quisquinay
12 / 15
Personal Advisors / Finance package ("PAF")
User goal
Purchaser - wants to buy stocks, get them added to the PAF
portfolio automatically.
Stock agency - wants full purchase information.
User already has PAF open.
sufficient logging information that PAF can detect that
something went wrong and can ask the user to provide
details.
remote web site has acknowledged the purchase, the logs
and the user's portfolio are updated.
Main success scenario:
1. User selects to buy stocks over the web.
2. PAF gets name of web site to use (E*Trade, Schwabb,
etc.) from user.
3. PAF opens web connection to the site, retaining control.
4. User browses and buys stock from the web site.
5. PAF intercepts responses from the web site, and updates
the user's portfolio.
6. PAF shows the user the new portfolio standing.
Extensions:
2a. User wants a web site PAF does not support:
2a1. System gets new suggestion from user, with option to
cancel use case.
3a. Web failure of any sort during setup:
3a1. System reports failure to user with advice, backs up to
previous step.
3a2. User either backs out of this use case, or tries again.
4a. Computer crashes or gets switched off during purchase
transaction:
4a1. (what do we do here?)
4b. Web site does not acknowledge purchase, but puts it on
delay:
4b1. PAF logs the delay, sets a timer to ask the user about
the outcome.
4b2. (see use case Update questioned purchase)
5a. Web site does not return the needed information from
the purchase:
5a1. PAF logs the lack of information, has the user Update
questioned purchase.
USE CASE 2: GET PAID FOR CAR ACCIDENT
Primary Actor:
Scope:
Level:
Stakeholders and Interests:
Precondition:
Minimal guarantees:
Success guarantees:
Trigger:
Main success scenario:
The Claimant
The insurance company ("MyInsCo")
Summary
the claimant - to get paid the most possible
MyInsCo - to pay the smallest appropriate amount
the dept. of insurance - to see that all guidelines are
followed.
none
MyInsCo logs the claim and all activities.
Claimant and MyInsCo agree on amount to be paid,
claimant gets paid that.
Claimant submits a claim
1. Claimant submits claim with substantiating data.
2. Insurance company verifies claimant owns a valid policy
3. Insurance company assigns agent to examine case

13. DOCUMENTO O GUÍA
Casos de Uso
Fecha
Versión
Autor
Páginas
02/09/2011
1
Byron Quisquinay
13 / 15
4. Insurance company verifies all details are within policy
guidelines
5. Insurance company pays claimant and closes file.
Main success scenario:
1a. Submitted data is incomplete:
1a1. Insurance company requests missing information
1a2. Claimant supplies missing information
2a. Claimant does not own a valid policy:
2a1. Insurance company declines claim, notifies claimant,
records all this, terminates proceedings.
3a. No agents are available at this time
3a1. (What does the insurance company do here?)
4a. Accident violates basic policy guidelines:
4a1. Insurance company declines claim, notifies claimant,
records all this, terminates proceedings.
4b. Accident violates some minor policy guidelines:
4b1. Insurance company begins negotiation with claimant as
to degree of payment to be
made.
USE CASE 3: REGISTER ARRIVAL OF A BOX
RA means "Receiving Agent".
RO means "Registration Operator"
Primary Actor:
Scope:
Level:
Main success scenario:
RA
Nightime Receiving Registry Software
user goal
1. RA receives and opens box (box id, bags with bag ids)
from TransportCompany TC
2. RA validates box id with TC registered ids.
3. RA maybe signs paper form for delivery person
4. RA registers arrival into system, which stores:
RA id
date, time
box id
TransportCompany
<Person name?>
# bags (?with bag ids)
<estimated value?>
5. RA removes bags from box, puts onto cart, takes to RO.
Extensions:
2a. box id does not match transport company
4a. fire alarm goes off and interrupts registration
4b. computer goes down leave the money on the desk and
wait for computer to come back up.
Variations:
4'. with and without Person id
4''. with and without estimated value
5'. RA leaves bags in box
USE CASE 4: BUY SOMETHING (CASUAL VERSION)
The Requestor initiates a request and sends it to her or his Approver. The Approver checks that
there is money in the budget, check the price of the goods, completes the request for submission, and
sends it to the Buyer. The Buyer checks the contents of storage, finding best vendor for goods. Authorizer:
validate Approver’s signature. Buyer: complete request for ordering, initiate PO with Vendor. Vendor:
deliver goods to Receiving, get receipt for delivery (out of scope of system under design). Receiver:
register delivery, send goods to Requestor. Requestor: mark request delivered.
At any time prior to receiving goods, Requestor can change or cancel the request. Canceling it

14. DOCUMENTO O GUÍA
Casos de Uso
Fecha
Versión
Autor
Páginas
02/09/2011
1
Byron Quisquinay
14 / 15
removes it from any active processing. (delete from system?)Reducing the price leaves it intact in process.
Raising the price sends it back to Approver.
___________________________________________
USE CASE 5: BUY SOMETHING (FULLY DRESSED VERSION)
Primary Actor:
Goal in Context:
Scope:
Level:
Stakeholders and Interests:
Company:
Vendor:
Precondition:
Minimal guarantees:
Success guarantees:
Trigger:
Main success scenario:
Requestor
Requestor buys something through the system, gets it.
Does not include paying for it.
Business - The overall purchasing mechanism, electronic
and non-electronic, as seen by the people in the company.
Summary
Requestor: wants what he/she ordered, easy way to do that.
wants to control spending but allow needed purchases.
wants to get paid for any goods delivered.
none
Every order sent out has been approved by a valid
authorizer. Order was tracked so that company can only be
billed for valid goods received.
Requestor has goods, correct budget ready to be debited.
Requestor decides to buy something.
1. Requestor: initiate a request
2. Approver: check money in the budget, check price of
goods, complete request for submission
3. Buyer: check contents of storage, find best vendor for
goods23
4. Authorizer: validate Approver’s signature
5. Buyer: complete request for ordering, initiate PO with
Vendor
6. Vendor: deliver goods to Receiving, get receipt for
delivery (out of scope of system under
design)
7. Receiver: register delivery, send goods to Requestor
8. Requestor: mark request delivered.
Extensions:
1a. Requestor does not know vendor or price: leave those
parts blank and continue.
1b. At any time prior to receiving goods, Requestor can
change or cancel the request.
Canceling it removes it from any active processing. (delete
from system?)
Reducing price leaves it intact in process.
Raising price sends it back to Approver.
2a. Approver does not know vendor or price: leave blank
and let Buyer fill in or call back.
2b. Approver is not Requestor's manager: still ok, as long as
approver signs
2c. Approver declines: send back to Requestor for change
or deletion
3a. Buyer finds goods in storage: send those up, reduce
request by that amount and carry on.
3b. Buyer fills in Vendor and price, which were missing: gets
resent to Approver.
4a. Authorizer declines Approver: send back to Requestor
and remove from active processing.
(what does this mean exactly?)
5a. Request involves multiple Vendors: Buyer generates
multiple POs.
5b. Buyer merges multiple requests: same process, but
mark PO with the requests being
merged.
6a. Vendor does not deliver on time: System does alert of
non-delivery

15. DOCUMENTO O GUÍA
Casos de Uso
Technology and Data Variations List:
Channel to primary actor:
Secondary Actors:
Channels to Secondary Actors:
Open issues:
Fecha
Versión
Autor
Páginas
02/09/2011
1
Byron Quisquinay
15 / 15
7a. Partial delivery: Receiver marks partial delivery on PO
and continues
7b. Partial delivery of multiple-request PO: Receiver assigns
quantities to requests and continues.
8a. Goods are incorrect or improper quality: Requestor does
refuse delivered goods. (what
does this mean?)
8b. Requestor has quit the company: Buyer checks with
Requestor's manager, either reassign
Requestor, or return goods and cancel request.
(none)
Priority- various
Releases - several
Response time - various
Freq of use - 3/day
Internet browser, mail system, or equivalent
Vendor
fax, phone, car
When is a canceled request deleted from the system?
What authorization is needed to cancel a request?
Who can alter a request's contents?
¿Después de todo esto qué debo de entender por caso
de uso?
Que es una forma de describir lo que se debería hacer para dar solución a un
problema o solicitud dados.
Use cases are popular largely because they tell coherent stories about how the
system will behave in use. The users of the system get to see just what this new system
will be. They get to react early, to fine-tune or reject the stories ("You mean we’ll have
to do what?"). That is, however, only one of ways they contribute value, and possibly
not the greatest.
The first moment at which they create value is when they are named as user
goals that the system will support and collected into a list. That list of goals announces
what the system will do. It reveals the scope of the system, its purpose in life. It
becomes is a communication device between the different stakeholders on the project.6
6
WRITING EFFECTIVE USE CASES - Alistair Cockburn - Humans and Technology - copyright
A.Cockburn, 1999-2000.