Oi Leandro,

O modelo, acima de tudo, tem fins didáticos. Se me preocupei em torná-lo utilizável na “vida real”, foi para atender diversos pedidos de participantes de meus treinamentos.

Mas seu comentário parece sugerir que o analista trabalha sozinho. Eu sei, infelizmente é esta a realidade de 99% deles. Mas seguirei insistindo para que trabalhem em duplas. Sendo assim, é factível supor que uma boa especificação possa ser realizada no momento da entrevista. E este, claro, não é o único benefício (ou única motivação) para o trabalho em pares.

Muito obrigado pela participação. Abraços!

Paulo Vasconcellos

Puxa Renato,

Só agora, puxado por outro comentário, que vi sua participação. Imperdoável de minha parte… Sei lá pq não estou recebendo por email todas as notificações de novos comentários. Mas vamos lá…

Sigo não acreditando que especificações de casos de uso sejam adequadas para documentação de produtos. A informação contida neles é transiente – já foi evoluída em outros modelos. Modelos mais próximos do código, quando não são o próprio código. Talvez esteja aí o “carma” descrito por ti. Quando a evolução depende de uma informação já transformada, o caminho é longo (e muito acidentado). Pense nisso.

Abraços e, mais uma vez, me desculpe pela demora.

Paulo Vasconcellos

Muito engenhoso da sua parte. Definitivamente trata-se de um bom modelo.

Meu ponto de atenção é para seu posicionamento no tempo e espaço da analise. Acho ótimo se preenchido em conjunto com a equipe técnica, numa seção de planejamento. Acho péssimo se preenchido na entrevista com o usuário ou mesmo a partir dela, só com base nas percepções do analista. A simples preocupação de um analista (mais junior) com o preenchimento desse modelo tende a comprometer a dinamica da entrevista, o que é péssimo.

Sei que uma das suas preocupações ao incluir tantos campos de simples marcação no cabeçalho é fornecer pequenos lembretes para o analista no momento da entrevista. Acho isso importante, especialmente para quem está aprendendo, mas na pratica, nada que um pouquinho de experiencia não resolva. E se o analista esquecer de perguntar ou for incapaz de estabelecer o benefício de um caso na hora de descreve-lo, por que não perguntar ao cliente na próxima iteração?

Abs!

Achei muito interessante os modelos. Eu sofro com a documentação de requisitos. Temos um documento padrão que segue esta linha e as sugestões acima irão melhorar este modelo.
Porém, eu sofro aqui com a documentação de requisitos para Produto. Um projeto, tem começo, meio e fim.. Mas um produto sofre manutenção e evolução, quanto mais informação eu tiver documentada pior (ou melhor) é para eu manter e evoluir.
Gostaria muito de uma opinião sua quanto ao controle e documentação de requisitos para Produto. Se possível é claro. Toda a parte de levantamento e elucidação até não é tanto o problema. Ja consegui resolvi isto em seus cursos FAN. Mas a documentação dos requisitos, bem como sua manutenção e evolução esta um carma. E parece que ninguém sofre com isto, pois não vejo ninguém falar sobre esta parte dos requisitos. Parece que o problema todo é só no levantamento e elucidação.
Desculpe o desabafo..rsssss
Valeu Paulo.. Excelente artigo…
Renato.

1. Como cito no texto principal, Coplien e Cockburn sugerem um limite máximo de 7 ou 9 passos, respectivamente, no fluxo principal. Respeitando tal limite, acho o espaço original suficiente.
2. Por outro lado, o número de fluxos alternativos pode facilmente ultrapassar o espaço que dediquei. Usando o chute de outros, inclusive dos dois citados acima, em pelo menos 20% dos casos de um projeto tradicional um espaço adicional seria necessário. Por isso tentei um desenho que permitisse apenas a impressão do verso, que contempla aquelas partes do caso que realmente precisam ‘escalar’.
3. Você está certo, o espaço para regras é relativamente pequeno. Também por isso a aloquei no verso.
4. A colocação de instruções para testes no mesmo espaço dedicado para fluxos alternativos realmente pode causar confusão. Minha versão do modelo exige um pouco mais de cuidado do analista. Usei tal artifício para evitar um modelo com mais de duas páginas, só isso.
5. Também o coloquei no verso para ganhar escala.

Mas a intenção original era essa mesmo, que cada um adapte a sugestão de acordo com suas necessidades. E na adaptação, meu caro, não é pedido nem mesmo que sejam preservados minha logomarca e endereço. Apenas que você compartilhe o trampo através da mesma licença que utilizei.

Valeu! Abraços,

Paulo Vasconcellos

Gostei do modelo, mas tomei a liberdade de fazer algumas adaptações para ficar melhor (rsss) ou do jeito que eu preciso.
Minhas Alterações:
РAumentei o espa̤o para fluxo principal, pois achei o espa̤o muito pequeno.
РReduzi o espa̤o para fluxo alternativo
– Aumentei o espaço para regra de negócio
РCrie um espa̤o para instrṳ̣o de teste independente do fluxo alternativo.
РAumentei o espa̤o para requisitos complementares

Veja como ficou o modelo: http://dl.dropbox.com/u/18890235/caso_de_uso_pv_rfs.pdf

Abs,

Obrigado pela força.

Abraços. Até lá!

Paulo Vasconcellos