Li isso no fórum sobre UML e achei muito interessante. Resolvi pulicar. São as opniões de um dos membros sobre casos de uso. O nome do autor esta logo abaixo do texto.

1. Caso de uso de "cadastro" (CRUD): não é caso de uso, a não ser que teu sistema faça SÓ isto. Ponto.

2. "Caso de uso de sistema", "Caso de uso de negocio", etc.: não é caso de uso. Caso de uso é "caso de uso" e pronto.

3. Include e Extend: NÃO USE. Um dia você vai entender o porquê. E neste dia você pode começar a usar.

4. Subfluxo, fluxo de exceção, fluxo reverso, refluxo, etc.: O que não é fluxo básico, é alternativo !

5. Query SQL na descrição UC: Caso de uso NÃO É ESPECIFICAÇÃO SISTÊMICA (URGH!). Foque no "o quê". O "como" vai para o modelo de projeto.

Por fim, para saber se um caso de uso "está certo" entregue para o usuário e veja a sua reação: se ele se interessar (a sombrancelha direita inclina-se 15 graus) significa que está certo. Se ele se entediar (ele lerá o documento com uma mão e devolverá rapidamente dizendo "ok, ok!") algo está errado. Procure por termos técnicos, por um fluxo macarrônico e/ou nome de caso de uso "Manter ".
Casos de usos são MUITO simples, beirando o simplório. Além do cliente/usuário/patrocinador não ter tempo para ler algo com mais de duas páginas, ele só quer saber como o sistema vai funcionar e não como (pra mim pouco importa se dentro do caixa eletronico tem um dispensador de cédulas super moderno ou gnomos-escravos-contadores-de-cédulas).
Um sistema com um caso de uso não é uma aberração (por trás deste simples caso de uso, podem haver dez telinhas de cadastro, necessários para que o caso de uso funcione). O que importa é que TODO o foco de desenvolvimento vai estar centralizado neste único ponto que REALMENTE proporciona valor para o ator-cliente-usuário-patrocinador.

Ou seja: na dúvida, seja econômico e simples.

Rodolpho Ugolini Neto
Software Engineering Specialist
IBM Software Group