Casos de uso qué - cómo... por byron quisquinay

DOCUMENTO O GUÍA Fecha 02/09/2011Versión 1

Casos de Uso Autor Byron QuisquinayPáginas 1 / 15

Casos de Uso¿Cómo los defino?

¿Qué debo entender de ellos?



CONTENIDO DE ESTE DOCUMENTO

CONTENIDO DE ESTE DOCUMENTO........................................................................2OBJETIVO:.......................................................................................................................3ALCANCE:.......................................................................................................................3Casos de Uso (del inglés Use Cases) ¿Cómo interpretar el término?...............................3Casos de Uso en la Práctica...............................................................................................4

Casos de Uso – en un Proceso del negocio...................................................................5Casos de Uso – Aplicado a los Sistemas de Información pero no aún como un requerimiento relacionado a los mismos.......................................................................6Casos 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?....................................................................10Ejemplos..........................................................................................................................11¿Después de todo esto qué debo de entender por caso de uso?.......................................14



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 Proceso2.2 Juicio2.3 Procedimiento

3. Suceso3.1 Circunstancia3.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:



"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 caseUse 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

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.

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.



¿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ándares3, 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:

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.

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.

3 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.



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, 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 RequerimientosTal 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” 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.



¿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.



¿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:

Usuario(s) Final(es): <Escribir listado de usuarios que harán uso de la solución. Se deberá escribir la forma de identificar a esas personas, ya sea por puesto, departamento, etc.>

Usuarios clave: <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.>

Grupo Consultivo: <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.>

Problema:Descripción: <Escribir un texto que permita identificar claramente de qué se

trata el problema a solucionar.>

Flujos del entorno: <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. >

Requisitos:Descripción: <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. >

Listado: <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.>

Solución:Descripción: <Escribir un texto que permita identificar claramente de qué se

trata el problema a solucionar. >

Flujos del entorno: <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.>



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 work-months 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 WEBPrimary Actor: PurchaserScope: Personal Advisors / Finance package ("PAF")

4 WRITING EFFECTIVE USE CASES - Alistair Cockburn - Humans and Technology - copyright A.Cockburn, 1999-2000.




Level: User goalStakeholders and Interests:

Purchaser - wants to buy stocks, get them added to the PAF portfolio automatically.Stock agency - wants full purchase information.

Precondition: User already has PAF open.Minimal guarantee: sufficient logging information that PAF can detect that

something went wrong and can ask the user to provide details.

Success guarantee: 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 ACCIDENTPrimary Actor: The ClaimantScope: The insurance company ("MyInsCo")Level: SummaryStakeholders and Interests:

the claimant - to get paid the most possibleMyInsCo - to pay the smallest appropriate amountthe dept. of insurance - to see that all guidelines are followed.

Precondition: noneMinimal guarantees: MyInsCo logs the claim and all activities.Success guarantees: Claimant and MyInsCo agree on amount to be paid,

claimant gets paid that.Trigger: Claimant submits a claimMain success scenario:

1. Claimant submits claim with substantiating data.2. Insurance company verifies claimant owns a valid policy3. Insurance company assigns agent to examine case4. Insurance company verifies all details are within policy guidelines5. Insurance company pays claimant and closes file.



Main success scenario:1a. Submitted data is incomplete:1a1. Insurance company requests missing information1a2. Claimant supplies missing information2a. 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 time3a1. (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 bemade.

USE CASE 3: REGISTER ARRIVAL OF A BOXRA means "Receiving Agent".RO means "Registration Operator"Primary Actor: RAScope: Nightime Receiving Registry SoftwareLevel: user goalMain success scenario:

1. RA receives and opens box (box id, bags with bag ids) from TransportCompany TC2. RA validates box id with TC registered ids.3. RA maybe signs paper form for delivery person4. RA registers arrival into system, which stores:

RA iddate, timebox idTransportCompany<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 company4a. fire alarm goes off and interrupts registration4b. computer goes down leave the money on the desk and wait for computer to come back up.

Variations:4'. with and without Person id4''. with and without estimated value5'. 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 itremoves 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: RequestorGoal in Context: Requestor buys something through the system, gets it.

Does not include paying for it.Scope: Business - The overall purchasing mechanism, electronic

and non-electronic, as seen by the people in the company.Level: SummaryStakeholders and Interests:

Requestor: wants what he/she ordered, easy way to do that.Company: wants to control spending but allow needed purchases.Vendor: wants to get paid for any goods delivered.Precondition: noneMinimal guarantees: 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.

Success guarantees: Requestor has goods, correct budget ready to be debited.Trigger: Requestor decides to buy something.Main success scenario:

1. Requestor: initiate a request2. Approver: check money in the budget, check price of goods, complete request for submission3. Buyer: check contents of storage, find best vendor for goods234. Authorizer: validate Approver’s signature5. Buyer: complete request for ordering, initiate PO with Vendor6. Vendor: deliver goods to Receiving, get receipt for delivery (out of scope of system underdesign)7. Receiver: register delivery, send goods to Requestor8. 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 signs2c. Approver declines: send back to Requestor for change or deletion3a. 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 beingmerged.6a. Vendor does not deliver on time: System does alert of non-delivery7a. Partial delivery: Receiver marks partial delivery on PO and continues7b. 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. (whatdoes this mean?)8b. Requestor has quit the company: Buyer checks with Requestor's manager, either reassignRequestor, or return goods and cancel request.

Technology and Data Variations List: (none)Priority- variousReleases - severalResponse time - variousFreq of use - 3/day

Channel to primary actor: Internet browser, mail system, or equivalentSecondary Actors: VendorChannels to Secondary Actors: fax, phone, carOpen issues:

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


Casos de uso qué - cómo... por byron quisquinay

Education

Transcript of Casos de uso qué - cómo... por byron quisquinay