Aconselhamento sobre a divisão de um processo que envolve múltiplos atores em Casos de Uso

Question

Vamos dizer que estou modelando um processo que envolve uma conversa ou exchnage entre dois atores. Para este exemplo, vou usar algo facilmente compreensível: -

1. Fornecedor cria uma lista de preços,
2. O comprador escolhe alguns itens para comprar e envia uma ordem de compra,
3. Fornecedor recebe a ordem de compra e envia as mercadorias.
4. Fornecedor envia uma fatura
5. Comprador receber a factura e faz um pagamento

É claro que cada uma dessas etapas em si poderia ser rápida complicado. Como você dividir isso em casos de uso em seu documento de requisitos?

Se este processo foi tratado como um único caso de uso poderia encher um livro.

Como alternativa, fazendo um caso de uso de cada um dos passos acima iria esconder um pouco da interação essencial e fluxo que deve ser capturado. Será que faz sentido ter um caso de uso que começa em "recebeu uma ordem de compra" e termina em "Enviar uma Fatura" e depois outro que começa em "Receba uma Fatura" e termina em "Faz um pagamento"?

Qualquer conselho?

Answer 1

A forma como eu costumo abordar tais tarefas é de apenas começando a criar diagramas de atividades Casos de Uso UML e de alto nível para o processo. Não se preocupe com detalhes, apenas dar o seu melhor tiro.

Quando você terá um rascunho que iria ver quase imediatamente a partir dele como ele poderia ser melhorado. Você poderia, então, continuar a refatoração-lo - ficando o caso de uso menor, estruturação de grandes atividades e assim por diante. Alternativamente, você pode agrupar um par de Casos de Uso em conjunto, se eles são muito pequenos.

Sem saber os detalhes do seu projeto que eu seria apenas ir em frente e fazer cada etapa um Caso de Uso separado - todos eles parecem ser auto-suficiente e poderia ser descrito sem quaisquer referências cruzadas. Se ao fazê-lo você vai encontrar todas as dependências você poderia sempre repensar a abordagem.

Considere também uso 'estender' e 'incluir' blocos para elementos comuns, como logging, segurança etc.

Answer 2

Sim, há muitas possibilidades aqui. No seu exemplo acima pode ser ainda mais complicada pelo Comprador fazer vários pagamentos parciais para pagar a conta.

Você provavelmente precisará criar casos completos de uso workflow. Dividindo cada um dos passos acima em seus próprios casos de uso pode não ser útil como algumas das etapas terá pré e pós condições.

Eu trabalho no código fonte QuickBooks e o número de maneiras que uma transação pode fluir através do sistema é assustador. É quase impossível para os nossos rapazes QA para testar cada combinação.