Você está na página 1de 5

Descrio do Negcio. A loja CdcomCarinho trabalha com a venda, vista e parcelada, de CDs de todos os gneros musicais.

. Ela oferece a seus clientes, do estado do Rio de Janeiro, um servio de delivery, permitindo que eles recebam, em casa, produtos requisitados pelo telefone. Seus clientes esto acostumados a uma abordagem diferencial, ou seja, a loja costuma mandar mala direta quando chega algum produto cujo gnero se encaixe com o perfil daquele cliente. H, tambm, ofertas promovidas durante datas especiais, por exemplo, no aniversrio dos clientes, no dia dos namorados, etc. Clientes que j compraram mais de 20 CDs na loja so classificados como Clientes Prata e recebem descontos de 10%. Clientes, com mais de 50 compras, so denominados Clientes Ouro, com descontos de 25%. O Gerente da loja precisa de uma anlise peridica de qual Gnero de CD est vendendo mais para planejar os prximos pedidos aos fornecedores. E deve saber, tambm, qual a regio do Estado do Rio que mais compra, para definir o foco da equipe de Marketing. Os vendedores (por telefone ou na loja) recebem salrio alm da comisso sobre as suas vendas. A CdcomCarinho deseja informatizar seu controle de vendas e de entregas. E, pretende, tambm, ampliar seu negcio atravs de vendas pela Internet. Sua funo: Imagine que voc est fazendo o Levantamento de Requisitos para um Sistema que automatizar as funcionalidades do negcio descrito anteriormente. Descreva os atores que devero interagir com o sistema e os casos de uso que especificam as funcionalidades do sistema. Descreva o fluxo de eventos de, pelo menos, dois casos de uso. Finalmente, esboce os Diagramas de Caso de Uso focados nestes casos de uso descritos e o Diagrama de Caso de Uso de contexto.

Para refletir... The primary actor of a use case The primary actor of a use case is the stakeholder that calls upon the system to deliver one of its services. The primary actor has a goal with respect to the system, one that can be satisfied by its operation. The primary actor is often, but not always, the actor who triggers the use case. Usually, the use case starts because the primary actor sends a message, pushes a button, enters a keystroke, or in some other way initiates the story. There are two common situations in which the initiator of the use case is not the primary actor. The first is when a company clerk or phone operator initiates the use case on behalf of the person who really cares; the second is when the use case is triggered by time. A company clerk or phone operator is often a technological convenience for the real person who cares, what I call the ultimate primary actor. With technology shifting, it becomes more likely that the ultimate primary actor will initiate the use case directly, using the web or an automated phone system. An example of this is the customer who currently phones in with a request. In a web redesign of the system, the customer may enter their request directly (as with Amazon.com). Similarly, the Marketing or Auditing Division might insist on the presence of use cases which are to be operated by a clerk. It is not really the clerks goal to have the use case run; they are a technological convenience for the Marketing managers. Under slightly different circumstances, the Marketing managers would run the use cases themselves. These days I write, "sales rep for the customer" or "clerk for Marketing Department" to capture that the user of the system is acting for someone else. This lets us know that the user interface and security clearances need to be designed for a clerk, but that the customer or Marketing Department are the ones who really care about the outcome. Time is the other example of a non-operator trigger. There is no clerk triggering the use cases that to run every midnight, or at the end of the month. It is easy, in this case, to see that the primary actor is whichever stakeholder cares that the use case runs at that time. It is easy to get into long arguments on the topic of users versus ultimate primary actors. I suggest you dont spend too much time on it, or else you argue in a pub. When the team starts investigating the user interface design, they will - or should - put a good deal of effort into studying the real users characteristics. When they review the requirements, they will find it useful to know the ultimate primary actor for each use case, who it is that really cares. As one student astutely asked, "How much damage is there if we get the primary actor wrong at this point?" The answer is, "Not much. Alistair Cockburn Writing Effective Use Cases" Diagrama de Casos de Uso Inicial

Caso de Uso - Pesquisar e Comprar Sumrio: Este caso de uso permite a um Cliente pesquisar o catlogo de CDs e efetuar uma compra. Ator Primrio: Cliente Ator Secundrio: Expedio Pr-Condio: Ator Cliente conectado ao Sistema Fluxo Principal: 1. O caso de uso tem incio quando o ator Cliente decide pesquisar o catlogo de oferta de produtos. {Seleo de Produto} 2. O sistema mostra as ofertas de produtos, destacando as categorias de produtos associadas ao perfil do Cliente. 3. O Cliente seleciona o produto a ser adquirido e o inclui no carrinho de compras, especificando a quantidade desejada. {Produto no disponvel} 4. Para cada item no carrinho, o sistema registra o identificador do produto e a quantidade desejada e faz a reserva dos mesmos no estoque. 5. Os passos 2, 3 e 4 so repetidos at que o ator Cliente selecione a opo Ir para o Caixa, quando ento o fluxo prossegue a partir do passo seguinte. {Ir para o Caixa} 6. Se o Cliente ainda no houver efetuado o login, executa o sub-fluxo Validar Usurio. 7. O sistema pede ao Cliente as instrues para a remessa. 8. O cliente entra com as instrues para a remessa.

9. O sistema captura as instrues para a remessa usando um protocolo seguro. 10. O sistema usa os dados da remessa e os pontos do programa de fidelidade, calcula o valor
a ser pago e informa ao Cliente.

11. O sistema pede ao Cliente os dados para pagamento 12. O Cliente entra com os dados do pagamento. 13. O sistema captura os dados do pagamento usando um protocolo seguro. 14. O sistema valida os dados do pagamento 15. O sistema informa ao cliente do sucesso da operao e envia um e-mail ao mesmo contendo
os dados da compra

16. O sistema credita os pontos do Cliente no programa de fidelidade (RN01). 17. O sistema envia os dados da compra para a expedio.
S1: Validar Usurio 1. O sistema oferece ao Cliente as opes: Entrar com conta e senha, Efetuar Cadastro ou Esqueci minha Senha 2. Se o Cliente optar por efetuar um novo cadastro, inclui o caso de uso Manter Informaes de Clientes a fim de que o Ator Cliente possa cadastrar seus dados. 3. Se o Cliente houver esquecido sua senha, envia a senha para o e-mail cadastrado. 4. Caso contrrio, o Cliente digita sua conta e senha 5. O Sistema valida a conta e senha do Cliente 6. Continua no passo seguinte Fluxos Alternativos A1 O item desejado no existe no estoque Em {Produto no Disponvel} se o item escolhido pelo usurio, na quantidade desejada, no existe no estoque. 1. O sistema informa ao Cliente que o pedido no pode ser atendido 2. O sistema informa ao Cliente se h possibilidade de atender parcialmente o pedido A2 Busca por palavra chave Em qualquer ponto entre {Seleo de Produto} e {Ir para o Caixa} se o Cliente decide efetuar uma busca de produto usando uma palavra chave 1. O sistema pede ao Cliente que especifique o critrio de busca 2. O cliente entra o critrio de busca 3. O sistema apresenta o resultado da busca 4. Os passos a. at c. se repetem at o momento em que o usurio decide efetuar uma compra quando ento retorna ao fluxo principal

Caso de Uso Registrar Sugestes e Reclamaes Fluxo Bsico 1. O caso de uso tem incio quando o ator Cliente liga para o Servio de Atendimento ao Cliente 2. O sistema abre um documento de atendimento ao cliente (DAC) e registra a data e hora da chamada 3. O sistema obtm o nmero do telefone onde a chamada foi gerada

4. O sistema registra este nmero no DAC


5. O sistema usa este nmero de telefone para determinar se houve chamadas anteriores do mesmo telefone 6. Se houve chamadas anteriores, o sistema registra as referncias para estas chamadas no DAC e ento redireciona a chamada para o primeiro operador disponvel. 7. O operador do Servio de Atendimento ao Cliente pede algumas informaes de identificao ao Cliente e tenta localizar seus dados. 8. Se o cliente for localizado, o sistema determina se houve chamadas anteriores do Cliente. Se houver, o sistema registra as referncias para estas chamadas no DAC. 9. Se o Cliente no for localizado, incluir o caso de uso Manter Informaes de Clientes a fim de que o operador do Servio de Atendimento ao Cliente possa registrar os dados do Cliente. 10. O sistema adiciona o nmero de identificao do cliente ao DAC. 11. O operador do Servio de Atendimento ao Cliente registra de forma textual a dvida ou reclamao do Cliente 12. O sistema grava a solicitao 13. O caso de uso se encerra.

Glossrio
Instrues para remessa endereo para entrega, preferncia pelo tipo de envio (correio normal, SEDEX, DHL, etc.) e opes de envio (carto, embrulho para presente, etc.).

Você também pode gostar