Outra coisa bacana a respeito de casos de uso que li no forum de UML. Segue o post na integra.
"Assino em baixo da resposta do nosso amigo MT...
Outra coisa importante (e que discutimos na minha aula de ontem) é que não é só na "fase" de levantamento que todos os requisitos são descobertos, ou melhor, não é só da equipe de requisitos a responsabilidade por todos os requisitos. Por exemplo, veja a narrativa a seguir:
Caso de Uso: Consultar Pedido - Versão: 1.2
Ator: Vendedor
1. O Ator inicia o caso de uso selecionando "Consultar Pedido";
2. O Sistema oferece a interface de consulta para pedidos;
3. O Ator informa o número do pedido desejado [A1];
4. O Sistema exibe os dados do pedido [A2];
Fluxo Alternativo A1 ? Consultar por Cliente
3. O Ator informa um cliente;
3.1. O Sistema exibe uma lista de pedidos do cliente selecionado em ordem cronológica decrescente;
3.2. O Ator seleciona um pedido do cliente; volta ao fluxo básico;
No passo 3 do fluxo básico, se o ator informar um número de pedido que não existe, o sistema deverá mostrar uma mensagem "Pedido Inexistente". Porém, esse tipo de "anomalia" não precisa estar necessariamente no caso de uso. Costumo dizer que esse requisito fica por responsabilidade do seu "caprichoso" programador.Algumas pessoas questionam sobre o teste desse "pedido inexistente". Mais
uma vez, não fica a cargo de quem escreveu o caso de uso captar todas as possibilidades e validações para que o teste seja 100%. Se o caso de uso sempre tiver que ter todos os requisitos, todos eles teriam mais de 20 páginas. O teste desse "pedido inexistente" também fica a cargo do seu "atencioso" tester. Um bom tester capta esse tipo de erro.Toda a equipe é responsável pelos requisitos. Os requisitos do caso de uso
são aqueles importantes para o negócio. Se algum desenvolvedor não for "caprichoso" e alguma vez falar "Não está no caso de uso então não vou implementar!", mande ele embora. A mesma coisa vale para o tester.
Valeu?!?!
Rodrigo Yoshima
ASPERCOM
Curso UML e Requisitos em São Paulo
www.aspercom.com."
"Assino em baixo da resposta do nosso amigo MT...
Outra coisa importante (e que discutimos na minha aula de ontem) é que não é só na "fase" de levantamento que todos os requisitos são descobertos, ou melhor, não é só da equipe de requisitos a responsabilidade por todos os requisitos. Por exemplo, veja a narrativa a seguir:
Caso de Uso: Consultar Pedido - Versão: 1.2
Ator: Vendedor
1. O Ator inicia o caso de uso selecionando "Consultar Pedido";
2. O Sistema oferece a interface de consulta para pedidos;
3. O Ator informa o número do pedido desejado [A1];
4. O Sistema exibe os dados do pedido [A2];
Fluxo Alternativo A1 ? Consultar por Cliente
3. O Ator informa um cliente;
3.1. O Sistema exibe uma lista de pedidos do cliente selecionado em ordem cronológica decrescente;
3.2. O Ator seleciona um pedido do cliente; volta ao fluxo básico;
No passo 3 do fluxo básico, se o ator informar um número de pedido que não existe, o sistema deverá mostrar uma mensagem "Pedido Inexistente". Porém, esse tipo de "anomalia" não precisa estar necessariamente no caso de uso. Costumo dizer que esse requisito fica por responsabilidade do seu "caprichoso" programador.Algumas pessoas questionam sobre o teste desse "pedido inexistente". Mais
uma vez, não fica a cargo de quem escreveu o caso de uso captar todas as possibilidades e validações para que o teste seja 100%. Se o caso de uso sempre tiver que ter todos os requisitos, todos eles teriam mais de 20 páginas. O teste desse "pedido inexistente" também fica a cargo do seu "atencioso" tester. Um bom tester capta esse tipo de erro.Toda a equipe é responsável pelos requisitos. Os requisitos do caso de uso
são aqueles importantes para o negócio. Se algum desenvolvedor não for "caprichoso" e alguma vez falar "Não está no caso de uso então não vou implementar!", mande ele embora. A mesma coisa vale para o tester.
Valeu?!?!
Rodrigo Yoshima
ASPERCOM
Curso UML e Requisitos em São Paulo
www.aspercom.com."
No comments:
Post a Comment