Escrevendo Casos de

Uso Eficazes

por Jacques Robert Heckmann

a partir de Alistair Cockburn

Corpo de Cenário
Um cenário
“sequência de ações dos diversos atores para
alcançar um objetivo”

1
Corpo de Cenário
Qualquer um dos passos cai em uma das
seguintes categorias:
uma interação entre ator e sistema
“cliente entra com endereço”
um passo de validação para proteger um
interesse de um stakeholder
“sistema valida a senha”
uma mudança interna para satisfazer um
interesse de um stakeholder
“sistema deduz quantia do saldo”

Corpo de Cenário
Exemplo típico de cenário principal: Registrar uma perda.

1. atendente entra com o número da apólice ou com nome e data do incidente.

2. o sistema preenche informação disponível de apólice e indica que a reivindicação
corresponde à apólice.
3. atendente entra com informação básica de perda.
4. sistema confirma que não há reivindicações que competem e atribui um número de
reivindicação.
5. atendente continua entrando com informação específca de perda para linha de
reivindicação.
6. atendente tem sistema extraindo outra informação de cobertura de outros sistemas
computacionais.
7. atendente seleciona e designa um organizador.
8. atendente confirma que ele terminou.
9. sistema salva e dispara confirmação para ser enviada ao agente.

Legenda:
Interações
Validações
Mudanças internas

2
Corpo de Cenário
Cada passo é escrito para mostrar uma
ação simples e ativa.
Pode comparar-se isso à descrição de uma
partida de vôlei.
Qualquer cenário pode ser descrito
utilizando-se estes 3 tipos de passos
Interações
Validações
Mudanças internas

12 Diretrizes

Diretrizes para escrever bons passos de ação

3
Diretriz 1
Use gramática simples: a estrutura da
sentença deveria ser absurdamente
simples!
Sujeito... verbo... objeto direto... frase
preposicional.
Exemplo:
O sistema... deduz... a quantia... do saldo da
conta.
Erro comum:
esquecer-se do sujeito (quem está com a bola).

Diretriz 2
Mostre claramente “quem está com a
bola”!
Um cenário tem a mesma estrutura de um
jogo.
A cada passo um jogador está com a bola.
Pergunte a si próprio “ao final da sentença,
quem está com a bola?”

4
Diretriz 3
Escreva com uma visão geral!
Não escreva os cenários como se o sistema
estivesse conversando consigo mesmo.
Ao invés de
“pegar o cartão do caixa eletrônico e a senha.
Deduzir quantia do saldo da conta.”
Escrever com uma visão geral
“O cliente insere o cartão no caixa eletrônico e
digita a senha”
“O sistema deduz a quantia do saldo da conta”

Diretriz 4
Mostre o processo avançando!
Não descreva os passos em processos muito
pequenos.
Se um cenário tem 13 ou mais passos, é bem
provável que as sentenças não estejam avançando
muito o objetivo.
É raro encontrar casos de uso bem escritos com
mais do que 9 passos no cenário.
Tente elevar o nível de objetivo perguntando várias
vezes
“por que o ator está fazendo isso?”

5
Diretriz 4 (continuação)
Ex:
“o usuário pressiona a tecla Tab”
Mas por que ele está pressionando esta tecla?
Porque ele tem que chegar ao campo endereço.
Mas por que ele está tentando chegar ao campo
endereço?
Porque ele tem que entrar com o seu nome e endereço
antes do sistema fazer qualquer coisa.
Então, a sentença de ação que avança o processo é:
“o Usuário entra com o nome e endereço”

Diretriz 5
Mostre a intenção dos atores, não seus
movimentos!
Não cite a operação da interface.

6
Diretriz 5 (continuação)
Exemplo defeituoso:
1. o sistema pergunta o nome
2. o usuário entra com nome
3. sistema pede endereço
4. o usuário entra com o endereço
5. o usuário clica em OK
6. sistema apresenta o perfil do usuário
Exemplo correto:
1. o usuário entra com o nome e o endereço
2. o sistema apresenta o perfil do usuário.

Diretriz 5 (continuação)
Se houver mais de 3 campos, uma variante é ...
1. usuário entra com nome, endereço, telefone, informação
secreta, telefone de contato emergencial;
Um outra variante seria ...
1. o usuário entra com
nome
endereço
telefone
informação secreta
telefone de contato emergencial

7
Diretriz 6
Inclua um conjunto de ações razoável!
Você pode escrever cada pedaço com um
passo de ação separado ou combinar os
pedaços de várias maneiras
pondo até todos em um único passo de ação!
Dependerá:
de quão complicado é cada passo
onde as pausas naturais ocorrem no
processamento
A seguir: Cinco versões. Nenhuma errada!

Diretriz 6 (continuação)
Versão 1:
1. O cliente entra com o número do pedido. O
sistema detecta que ele corresponde ao número
premiado do mês, registra o usuário e o
número do pedido como esse ganhador do mês,
envia um e-mail para o gerente de vendas,
cumprimenta o cliente e dá instruções a ele de
como receber o prêmio.
muito complicada para ler!

8
Diretriz 6 (continuação)
Versão 2:
1. O cliente entra com o número do pedido.
2. O sistema detecta que ele corresponde ao
número premiado do mês, registra o usuário e
o número do pedido como esse ganhador do
mês, envia um e-mail para o gerente de
vendas, cumprimenta o cliente e dá instruções
a ele de como receber o prêmio.
pedaços simples, porém, um pouco longo
demais para trabalhar.

Diretriz 6 (continuação)
Versão 3:
1. O cliente entra com o número do pedido.
2. O sistema detecta que ele corresponde ao número premiado do
mês.
3. O sistema registra o usuário e o número do pedido como esse
ganhador do mês, envia um e-mail para o gerente de vendas,
cumprimenta o cliente e dá instruções a ele de como receber o
prêmio.
Versão 4:
1. O cliente entra com o número do pedido.
2. O sistema detecta que ele corresponde ao número premiado do
mês.
3. O sistema registra o usuário e o número do pedido como esse
ganhador do mês, envia um e-mail para o gerente de vendas.
4. O sistema cumprimenta o cliente e dá instruções a ele de como
receber o prêmio.
boas, porém não servem se o propósito é teste.

9
Diretriz 6 (continuação)
Versão 5:
1. O cliente entra com o número do pedido.
2. O sistema detecta que ele corresponde ao número
premiado do mês.
3. O sistema registra o usuário e o número do pedido como
esse ganhador do mês.
4. Envia um e-mail para o gerente de vendas.
5. O sistema cumprimenta o cliente e dá instruções a ele de
como receber o prêmio.
passos muito pequenos
ótimos para testar
adequados para um desenvolvimento mais formal!

Diretriz 7
Diretriz 7: “Valide”, não “Verifique se”!
Um dos três tipos de passos de ação é a
verificação do sistema de alguma regra de negócio
é satisfeita.

“verificar” uma condição:

Não leva o processo adiante!
Não é realmente o objetivo do UC!
Deixa em aberto qual é o resultado da verificação.

Por que o sistema está verificando algo?

Ele está determinando, ou validando, ou assegurando
algo.

10
Diretriz 7 (continuação)
Ao invés de ...
2. “O sistema verifica se a senha está correta”.
3. “Se estiver, o sistema apresenta as ações disponíveis para o
usuário”.
Usar ...
2. “O sistema valida que a senha está correta”.
3. “O sistema apresenta as ações disponíveis para o usuário”.
Observar que o segundo caso considera que o cenário tem
sucesso.
Leva à pergunta natural: “mas se em 2 a senha não for
correta?”
O que leva à procura de um cenário para esta situação.
Deixa o caso de uso com um ritmo consistente de revisão e
leitura.

Diretriz 8
Mencione o tempo, opcionalmente!
Geralmente o tempo é obvio: não precisa ser
mencionado.
Nomalmente, um passo segue o anterior.
Assim mesmo...
... ocasionalmente, você terá que dizer algo como
“A qualquer hora entre os passos 3 e 5, o usuário irá”
ou
“Assim que o usuário tiver..., o sistema irá ...”

11
Diretriz 9
Expressão “Usuário tem Sistema A chama Sistema
B”!
Ao invés de usar
1. “o usuário sinaliza ao sistema para recuperar dados do sistema
B”.
2. “o sistema recupera os dados secundários do sistema B”.
É aceitável, porém, são redundantes.
Usar:
1. “o usuário tem o sistema recuperando os dados secundários do
sistema B”.
Note:
o usuário continua controlando o tempo;
é dito que a bola passa do sistema A para o B;
os detalhes de como o usuário inicia a ação não são
especificados (e realmente não devem!)

Diretriz 10
Expressão “faça passos x-y até condição”!
Como se usa prosa simples, apenas escreva que o(s) passo(s)
irão se repetir.
Procure escrever a repetição após os passos a repetir.
Facilita a leitura.
Exemplo:

1. Cliente fornece identificador da conta ou nome e endereço.

2. Sistema traz a informação preferencial do cliente.
3. Cliente seleciona um item para comprar, marca o item para
aquisição.
4. Sistema adiciona o item ao “carrinho de compras” do cliente.
Cliente repete os passos 3-4 até indicar que terminou.*
5. Cliente adquire os itens no “carrinho de compras”.

*A sentença da repetição não foi numerada!

12
Diretriz 11
a condição de um cenário alternativo ou de
exceção deve dizer “o que” foi detectado!
Descreva o que o sistema detecta, não só o que
aconteceu.
Não escreva:
“cliente esqueceu a senha”
O sistema não pode detectar isso. Mas pode
detectar a inatividade do usuário.
“limite de tempo de entrada da senha expirado”

Diretriz 11 (continuação)
A condição deve ser uma frase curta, por
exemplo:
“Senha inválida”
“Rede inoperante”
“O cliente não responde”
“Dinheiro não foi ejetado corretamente”.

Ligue o novo cenário ao cenário de origem:

“no passo número X, do cenário tal, caso a
senha seja inválida, ...”

13
Diretriz 12
Alinhe o tratamento da condição!
Condição 1: Saldo insuficiente:
1a. Sistema notifica cliente, pede por uma nova
quantia
1b. Cliente entra com uma nova quantia.
Não considerada.
Fica complicado quando se necessita
renumerar estas condições.

Além das 12 Diretrizes:

a) Quando Terminamos?
1. Nomeou todos os atores primários e todos
os objetivos de usuário?
2. Capturou todas as condições de
acionamento do sistema?
3. Escreveu todos os casos de uso de objetivo
de usuário, além dos casos de uso resumo
ou subfunção necessários para suportá-
los?
4. Os responsáveis concordam que o conjunto
de caso de uso cobre tudo que eles querem?

14
Além das 12 Diretrizes:
a) Quando Terminamos? (continuação)
5. Cada UC é escrito de forma clara o
suficiente? Tal que:
1. Os responsáveis concordam que eles serão
capazes de dizer se ele está realmente entregue
ou não?
2. Os usuários concordam que é isso o que eles
querem (ou podem aceitar como o
comportamento do sistema)?
3. Os desenvolvedores concordam que eles
realmente podem desenvolver aquela
funcionalidade?

Além das 12 Diretrizes:

b) Como lidar com muitos UCs?
Dizer menos sobre cada um (adotar
representação de baixa precisão)
definir bem o que faz um caso de uso com o seu
nome e resumo.
Agrupar os UCs:
por ator;
por caso de uso resumo;
por equipe de desenvolvimento e versão;
por área de assunto.

15
Além das 12 Diretrizes:
c) UCs CRUD
Não há consenso em como organizar todos aqueles
pequenos UCs do tipo
C riar um <Qualquer>
R ecuperar um <Qualquer>
U pdate um <Qualquer>
D elete um <Qualquer>
Pergunta:
“todos são parte de um único UC maior (Gerenciar
<Qualquer>) ou são separados (Criar, Recuperar,
Update, Delete)?”
Sugestão de Alistair Cockburn:
começar com apenas um UC Gerenciar, para ter uma
desordem menor;
quebrar em outros UCs separados, caso uma seção
torne-se muito complexa.

Além das 12 Diretrizes:

d) UCs Parametrizados
E se tivermos um amontoado de UCs que
são quase os mesmos?
Escrever uma meia dúzia de UC similares
não é problema.
Porém, escrever 6 casos de uso
inteiramente similares é desagradável.
Não demora para os autores quererem um
atalho.

16
Além das 12 Diretrizes:
d) UCs Parametrizados (continuação)
Exemplo:
1. Usuário especifica <Qualquer> a ser encontrado;
2. sistema procura, traz a lista de possíveis equivalências;
3. usuário seleciona, talvez reorganize a lista, talvez mude
a pesquisa;
4. sistema encontra um ou mais <Qualquer>
O que difere de uso para uso?
1. O nome do <Qualquer> a ser encontrado;
2. As qualidades pesquisáveis do <Qualquer>
(campos de pesquisa);
3. O que exibir sobre o <Qualquer>
(campos de exibição, em sequência)
4. Como classificar as opções
(critério de classificação)

Além das 12 Diretrizes:

d) UCs Parametrizados (continuação)
Então, poderíamos ter um UC
que: Selecionar
Usuário identifica as qualidades <Qualquer>
pesquisáveis de <Qualquer>;
O sistema encontra todos os
equivalentes e exibe seus valores
de exibição em uma lista;
O sistema pode reclassificá-los de Selecionar
acordo com algum critério; Cliente
O usuário seleciona aquele de
interesse.
E a partir deste, fazer Selecionar
generalizações para UCs que Fornecedor
especificam os itens que
diferem entre UCs.

17
Escrevendo Casos de Uso
Eficazes
Referências:
COCKBURN, Alistair. Escrevendo casos
de uso eficazes: um guia prático para
desenvolvedores de software. Porto Alegre :
Bookman, 2005. viii, 254 p, il.

Fim.

18