Os processos de um negócio são definidos como uma série de
casos de usos de negócios diferentes, cada um representando um fluxo de trabalho específico no negócio. Um caso de uso
de negócios define o que deve acontecer no negócio quando ele é realizado; ele descreve o desempenho de uma seqüência
de ações que produz um resultado de valor a um determinado agente de negócios. Um processo de negócio gera valor para o
negócio ou reduz os custos para o negócio.
Um passageiro pode viajar individualmente ou com um grupo. Ao viajar com um grupo, um passageiro é acompanhado por um
guia turístico.
Um caso de uso de negócios descreve "uma seqüência de ações executadas em um negócio que produz um resultado de valor
observável para um agente individual do negócio". Portanto, do ponto de vista de um agente individual, um caso de uso
de negócios define o workflow completo que produz os resultados desejados. Isso é semelhante ao que é geralmente
chamado de "processo de negócios", mas um "caso de uso de negócios" tem uma definição muito mais precisa.
A definição do conceito de caso de uso de negócios contém várias palavras-chave, que são essenciais para entender o que
é um caso de uso de negócios:
-
Instância do caso de uso de negócios - a definição acima realmente descreve um fluxo de trabalho de negócio
específico; ou seja, uma instância. Na realidade, há um grande número de workflows possíveis, muitos deles
parecidos.
Para tornar o modelo de caso de uso compreensível, fluxos de trabalho semelhantes são agrupados em um caso de uso
de negócios - uma "classe" em termos do modelo de objeto. Identificar e descrever um caso de uso de negócios
significa identificar e descrever o caso de uso de negócios parecido com a classe, não as instâncias de caso de uso
individuais. Portanto, um caso de uso de negócios definirá pontos de decisão e fluxos alternativos; o caminho
tomado dependerá do estado do negócio, dos eventos do negócio e da entrada do agente comercial.
-
Um agente individual - O agente é provavelmente a chave real para localizar o caso de uso de negócios correto.
Iniciar com agentes individuais, ou realmente instâncias de atores, ajuda a evitar os casos de usos de negócios que
são muito grandes ou complexos.
Ao determinar os agentes adequados, tente primeiro identificar pelo menos duas ou três pessoas diferentes que
possam desempenhar o papel do agente em questão e, em seguida, avalie criticamente o suporte que cada indivíduo
exige. Por exemplo, suponha que você inicialmente identifique um agente chamado "cliente". Posteriormente, ao se
aprofundar no suporte que cada cliente individual requer, você poderá localizar três clientes diferentes: o
"usuário" normal do produto, o "comprador" e o "avaliador", que são competentes na comparação do produto com seus
concorrentes. Cada um pode exigir um caso de uso de negócios separado porque representam papéis diferentes que
podem ser desempenhados no negócio.
-
Um resultado de valor observável - Essa expressão é muito importante ao determinar a extensão correta de um caso de
uso de negócios, que não deve ser nem muito pequeno nem muito grande. Afirmar que o caso de uso de negócios deve
fornecer um resultado de valor observável, ou seja, que pode ser percebido e medido, ajuda a localizar um fluxo
completo e evita que os casos de uso de negócios sejam muito pequenos.
Um bom caso de uso de negócios ajuda um agente a realizar uma tarefa que tem um valor identificável. É possível
colocar um preço em um caso de uso de negócios realizado com sucesso. Um caso de uso de negócios muito pequeno terá
um escopo limitado, portanto, terá também um potencial de reengenharia pequeno.
-
Em um negócio - As palavras "ações executadas em um negócio", significam que o negócio fornece o caso de uso de
negócios para o agente e que o caso de uso de negócios cobre somente o que é, na verdade, feito em um negócio. O
trabalho de suporte realizado em outro lugar não está incluído.
-
Ação - As ações são chamadas a pedido de um agente para o negócio ou em um determinado momento. As ações incluem
tarefas internas e decisões, assim como pedidos para o agente chamado ou outros agentes.
Os casos de uso de negócios especificam as interações entre o negócio do indivíduo e seus agentes comerciais
(externos) e o efeito que eles têm sobre o negócio - o desempenho de um caso de uso de negócios pode alterar o
estado do negócio (e, portanto, alterar a forma como o negócio responde a eventos futuros ou interações) e o caso de
uso de negócios deve especificar essas alterações de estado.
O que o negócio fornece direta e explicitamente a seu ambiente são serviços (o negócio a partir dessa
perspectiva é simplesmente o Sistema de Negócio de nível superior e deve, portanto, encapsular seus recursos e fornecer
serviços bem definidos para seu ambiente - consulte Diretriz:
Sistema de Negócio) e a interação entre o Agente Comercial e o negócio, conforme descrito no Caso de Uso de
Negócios, ocorrerá através da chamada de um ou mais desses serviços. Observe que para um novo desenvolvimento de
negócio (criação
de negócio, por exemplo) ou ao alterar o negócio, os Casos de Uso de Negócios são uma forma de identificar
serviços que o negócio deve suportar.
O conjunto de casos de uso coletados constitui todas as maneiras possíveis de usar o negócio. Consulte também Diretriz: Modelo de Caso de Uso de Negócios.
Em um projeto de modelagem de negócios controlado por caso de uso, você desenvolve duas visões do negócio.
O caso de uso de negócios apresenta uma visualização externa do negócio, que define o que é essencial para
executar o negócio para entregar os resultados desejados para o agente. Ele define também que interação (a
seqüência de resposta de entrada do negócio do agente comercial) o negócio deve ter com os agentes quando o caso
de uso de negócios for executado. Essa visão deve ser desenvolvida quando você decidir o que deve ser feito em cada
caso de uso de negócios. Uma coleção de casos de uso de negócios fornece uma visão geral do negócio muito útil para
informar aos funcionários sobre as diferentes partes do negócio que estão sendo realizadas e os resultados esperados.
Uma descrição de um caso de uso de negócios faz isso sem referência à estrutura interna real do negócio. Observe que o
caso de uso de negócios também deve descrever todas as alterações de estado no negócio que ocorrem quando ele é
executado, bem como todos os eventos de negócio significativos que surgem ou são recebidos. O caso de uso de negócios
não prescreve como o estado do negócio deve ser estabelecido e mantido internamente ou como os eventos de negócio devem
ser comunicados internamente - mas especificam o que são as alterações de estado e o
que são os eventos de negócio significativos, para poder apresentar uma visualização completa do comportamento
requerido do negócio.
Uma realização de caso de uso de negócios, por outro lado, fornece uma visualização interna do caso de uso de negócios,
que define como o trabalho deve ser organizado e executado para alcançar os mesmos resultados desejados. Uma
realização abrange os trabalhadores de negócios, as entidades de negócios envolvidas na execução de um caso de uso de
negócios e os relacionamentos entre eles, que são necessários para o trabalho. Essas visões devem ser desenvolvidas
para decidir e concordar sobre como o trabalho em cada caso de uso de negócios deve ser organizado para alcançar os
resultados desejados. O Designer de Negócios assegura que há mapeamentos consistentes entre a especificação (o
que), no caso de uso de negócios, e a realização (como), na realização de caso de uso de
negócios, para as alterações no estado do negócio e eventos de negócio, a fim de alcançar o comportamento desejado em
todos os casos de uso de negócios.
As duas visões do caso de uso de negócios foram planejadas principalmente para as pessoas no negócio; a visão externa
para as pessoas que trabalham fora do caso de uso de negócios e a visão interna, para as pessoas que trabalham dentro
do caso de uso de negócios.
Enquanto um negócio estiver funcionando, você poderá identificar quase um número ilimitado de fluxos de trabalho
separados. Uma instância de casos de uso é simplesmente um workflow ou cenário específico. Ela corresponde ao trabalho
que vários membros de negócios de colaboração realizam em seus papéis definidos no modelo de objetos, e não a qualquer
membro de negócios particular ou papel que o membro esteja desempenhando.
Geralmente, um caso de uso de negócios é com o que você trabalha para que o modelo de casos de uso seja compreensível e
para evitar o excesso de detalhes. Ele representa a união de várias instâncias de casos de uso de negócios com fluxos
de trabalho que são semelhantes, mas normalmente não são idênticos.
Geralmente, um funcionário competente em determinado papel fará isso em vários casos de uso de negócios diferentes.
Exemplo:
No balcão de check-in do aeroporto, os dois casos de uso de negócios, Check-in Individual e Check-in de Grupo exigem as
mesmas competências do funcionário no balcão de check-in, e também acessam as mesmas informações sobre um determinado
departamento. Portanto, os dois casos de uso podem e devem ser projetados usando o mesmo trabalhador de negócios Agente
de Check-in e a mesma entidade Partida.
Às vezes, é difícil decidir se um serviço é composto de um ou vários casos de uso de negócios. Aplicar a definição de
um caso de uso de negócios ao processo de check-in do aeroporto. Um passageiro entrega a passagem e a bagagem ao agente
de check-in, que localiza o assento do passageiro, imprime um cartão de embarque e inicia a administração de bagagens.
Se o passageiro tiver bagagem normal, o agente de check-in imprime a identificação de bagagem e o comprovante do
cliente, e termina o caso de uso de negócios aplicando a identificação à bagagem e fornecendo o comprovante e o cartão
de embarque ao passageiro. Se a bagagem tem um formato ou conteúdo especial de maneira que não possa ser transportada
normalmente, o passageiro deve encaminhá-la a um balcão de bagagem especial. Se a bagagem é pesada, o passageiro deve
se encaminhar ao guichê do aeroporto para pagar por ela, já que os agentes de check-in não lidam com dinheiro.
Você precisa de um caso de uso de negócios no balcão de check-in, outro no balcão de bagagem especial e um terceiro no
guichê? Ou precisa apenas de um único caso de uso de negócios? Certamente, essa transação envolve três diferentes tipos
de ações. Mas a pergunta é, alguma delas terá valor para um passageiro com bagagem especial se ele não realizar as
outras? Não, é apenas o procedimento completo, a partir do momento em que o passageiro se aproxima do balcão de
check-in até o pagamento da despesa extra, que tem valor (e que faz sentido para o passageiro). Assim, o procedimento
completo, envolvendo os três balcões diferentes, é um caso completo de uso, um caso de uso de negócio.
Além desse critério, é mais prático manter juntas as descrições dos serviços relacionados, de maneira que você possa
revê-las ao mesmo tempo, modificá-las juntas, testá-las juntas, escrever manuais para elas e gerenciá-las em geral como
uma unidade.
Observe também que dois casos de uso de negócios independentes podem ter inícios semelhantes.
Exemplo:
Em uma companhia de seguros, os casos de uso de negócios Tratar Reclamação e Tratar Solicitação começam quando alguém
(um ator) faz um contato com um gerenciador de reclamações. O gerenciador de reclamações e o agente trocam algumas
informações para esclarecer se o agente está registrando uma reclamação ou solicitando alguma informação. Em seguida, é
possível decidir o caso de uso de negócios que está sendo realizado. Apesar de os dois casos de uso de negócios terem
começos semelhantes, eles não estão conectados.
O nome do caso de uso de negócios deve expressar o que acontece quando uma instância do caso de uso de negócios é
realizada. O formato do nome deve, portanto, estar ativo, normalmente um substantivo (Check-in) ou um verbo e um
substantivo juntos.
Os nomes também podem descrever as tarefas no caso de uso de negócios de um ponto de vista externo ou interno, por
exemplo, colocar uma ordem ou receber uma ordem. Embora um caso de uso de negócio descreva o que acontece dentro do
negócio, normalmente é mais natural denominar o caso de uso de negócios do ponto de vista do agente principal. Depois
de decidir o estilo que prefere no seu caso, você deve seguir a mesma regra de todos os casos de uso de negócios no
modelo de negócios.
A meta de um caso de uso de negócios deve ser especificada de pelo menos duas perspectivas:
-
Para os agentes de negócios com os quais o processo de negócios interage, especifique o valor que esses agentes de
negócios esperam do negócio (metas externas).
-
Do ponto de vista da organização que realiza os processos de negócios, defina os objetivos de ter esse processo de
negócios em andamento e o que você espera alcançar realizando-os (metas internas).
Algumas categorias de métricas comuns são:
-
Tempo - uma aproximação do tempo que deve durar a execução do workflow ou de parte do workflow.
-
Custo - uma aproximação do custo de execução do workflow, ou parte do workflow.
-
Qualidade - por exemplo, "não mais de 2% dos produtos deve estar defeituoso ao sair da linha de produção".
Um desafio maior é entender quais cenários (instâncias de caso de uso de negócio) são relevantes para a medição. O
critério que deve ser usado é a freqüência do cenário ou a relevância dos negócios do cenário. Se você pode determinar
que uma parte específica do workflow tem importância, você economizar algum esforço medindo apenas o custo ou o tempo
desse subfluxo.
A maioria dos fluxos de trabalho pode ser considerada como vários subfluxos, que juntos compõem o fluxo total. Às
vezes, vários casos de uso de negócios no negócio têm um subfluxo comum, ou o mesmo subfluxo aparece em partes
diferentes de um caso de uso de negócios. Se esse comportamento comum tem algum volume substancial, ele deve ser
realizado pelos mesmos trabalhadores de negócios.
Se um subfluxo é substancial, comum a vários casos de uso de negócios e também forma uma parte independente e
naturalmente delimitada, o modelo pode ser mais claro se esse comportamento for particionado em um caso de uso de
negócios separado. Este novo caso de uso de negócios é, então, incluído no caso de uso original (consulte Diretriz: Relacionamento de Inclusão no Modelo de Caso de Uso de Negócios), em uma
extensão dele (consulte Diretriz: Relacionamento de Extensão no Modelo de Caso de Uso de Negócios) ou em um
caso de uso pai (consulte Diretriz: Generalização de Caso de Uso no Modelo de Caso de Uso de Negócios).
Exemplo:
No balcão de check-in do aeroporto, os dois casos de uso de negócios, Check-in Individual ou Check-in em Grupo,
utilizam o mesmo procedimento para manipular a bagagem do passageiro individual. Como o subfluxo é independente da
administração de passagens, e é logicamente conectado, ele é modelado separadamente no caso de uso de negócios,
Administração de Bagagens.
O fluxo de trabalho de um caso de uso de negócios pode ser visualizado utilizando os diagramas de atividades, consulte
Diretriz: Diagrama de Atividades no Modelo de Caso de Uso de Negócios.
Para obter informações adicionais sobre a estruturação e a descrição do fluxo de trabalho de um caso de uso de
negócios, consulte Diretriz: Caso de Uso, as discussões sobre o Fluxo de Eventos.
A seguir, há uma descrição do workflow do caso de uso de negócios Processo de Propostas em uma organização que vende
soluções configuradas para cada cliente individual. Em Técnica: Diagramas de Atividades no Modelo de Caso de Uso de Negócios, a seção em
Exemplos de Utilização, você localiza um exemplo de um diagrama de atividades visualizando a estrutura deste fluxo de
trabalho:
1. Fluxo de Trabalho Básico
1.1. Contato Inicial
Este processo começa com um contato inicial entre o Cliente e A Empresa. Isso pode ocorrer de uma das seguintes
maneiras:
-
Os contatos do Cliente A Empresa com uma consulta ou um conjunto de requisitos
-
A Empresa decide que tem produtos que agregariam valor ao Cliente e receita à Empresa.
A Empresa interage com o Cliente para estabelecer:
-
Pessoa em contato com o Cliente
-
Pessoa em contato com a Empresa
-
Se este for um novo cliente para A Empresa
-
Qualquer informação competitiva sobre a proposta ou a situação de ordem em torno deste acordo.
1.2. Oportunidade de Trabalho Inicial
Esta seção tem duas finalidades principais:
-
Reunir requisitos do cliente
-
Decidir sobre ações adicionais sobre esta oportunidade.
Os passos Reunir requisitos preliminares do cliente, Criar plano de vendas (opcional) e Realizar Análise de
Oportunidade podem ser realizados de maneira iterativa e de alguma maneira em paralelo.
1.2.1 Reunir Requisitos Preliminares do Cliente
Reúna os requisitos do produto e os requisitos de negócios do cliente, fazendo o seguinte:
-
pergunte ao Cliente;
-
observe as entradas do cliente que houver;
-
execute um relatório sintético preliminar do site (opcional);
-
observe as informações disponíveis sobre o cliente.
Um conjunto completo de requisitos incluiria:
-
opção de tecnologia (podem ser várias, se os clientes desejarem que as alternativas sejam investigadas)
-
quaisquer preferências de produto
-
requisitos funcionais (análise de mercado)
-
construindo a estrutura e as características ambientais
-
demografia
-
mobilidade/capacidade
-
projeção de crescimento da rede
-
informações de base instaladas
-
linhas do tempo
-
requisitos de serviço
-
requisitos de preço
1.2.2 Criar Plano de Vendas (Opcional)
A Empresa trabalha com o Cliente para determinar como propor uma solução que atendas aos requisitos do cliente. Essa
criação é denominada plano de vendas e inclui a rede e as características de alternância da solução potencial. O
posicionamento estratégico da Empresa e sua rede também é discutido para que possamos nos preparar para as necessidades
futuras.
Esse plano de vendas é revisto com o Cliente para que seja preciso e completo. Ele será usado em todo o processo de
proposta como um guia, ao decidir produtos, pacotes de mercado e itens que serão propostos, e as suposições que devem
ser feitas ao juntar a proposta.
1.2.3 Executar Análise de Oportunidade
A Empresa obterá o preço de alto nível e custo da potencial solução. Isso é feito para entender o valor potencial dessa
oportunidade, não para fornecer uma quantidade precisa de dólares para um Cliente.
A Empresa examina os requisitos do cliente para determinar:
-
riscos na oportunidade (disponibilidade do produto, concorrência, risco do cliente)
-
custos comparados à receita
-
tipo de oportunidade (simples, complexo, etc.)
-
probabilidade das vendas
-
número antecipado para o tamanho das vendas
-
planejamento estimado
Com base nessa avaliação, a Empresa decide se continuará ou não a oportunidade.
1.3. Criar Plano de Projeto de Proposta
A Empresa criará um plano para criar e oferecer a proposta. O plano incluirá as atribuições aos indivíduos completando
as partes da proposta.
1.4. Criar Plano de Projeto de Entrega
A Empresa desenvolve uma tentativa de plano de projeto para liberar a solução com base em:
-
linhas do tempo nos requisitos do cliente
-
disponibilidade de recurso
-
capacidade do depósito de informações do provedor
-
nova disponibilidade do produto
-
disponibilidade de produtos de terceiros
Este plano de projeto será utilizado para futuro planejamento do depósito de informações do provedor.
Além disso, este plano de projeto será atualizado e modificado durante o Processo de Cotação.
1.5. Preparar uma Cotação
Este fluxo é definido em detalhes no Processo de Cota do caso de uso de negócio que é incluído.
O resultado do Processo de Cotação é uma solução de engenharia que pode ter vários níveis de certeza, junto com um
preço.
1.6. Compilar Informações Adicionais
A Empresa compila as informações para responder a qualquer pesquisa (geralmente referente ao desenvolvimento futuro dos
produtos) que possa ser uma parte dos requisitos de negócios de cliente. Também pode incluir as informações que A
Empresa supõe que o Cliente deve conhecer. Geralmente, as pesquisas são dos seguintes tipos:
-
recurso agora
-
recurso no futuro
-
conformidade com os padrões
-
conformidade com futuros padrões
-
serviços oferecidos agora
-
serviços oferecidos no futuro.
1.7. Analisar e Finalizar a Proposta
A Empresa compila uma proposta que inclui os seguintes itens:
-
a cota(s)
-
literatura de marketing (fora da prateleira)
-
informações do produto (fora da prateleira)
-
termos e condições de financiamento
-
informações de planejamento
-
levar a análise financeira ao nível de proposta
-
punições e confiabilidades do Cliente e da Empresa
-
instruções 'ambientais' legais
-
quaisquer suposições feitas ao criar as soluções na proposta
1.8. Apresentar a Proposta
A Empresa apresenta/propõe as informações acima para o Cliente.
1.9. Obter Decisão do Cliente
O Cliente fornecerá um feedback sobre a proposta. A Empresa obtém um acordo do Cliente sobre as cotações na proposta.
Tal acordo pode ter formato diferente, dependendo do caráter da solução e de quem é o Cliente.
Ele pode ser:
-
uma ordem de compra assinada
-
um acordo verbal ao qual o Cliente irá submeter uma ordem de compra
-
um contrato assinado
-
um acordo verbal
-
uma decisão negativa ocorre quando não há decisão e a validade expira
2. Fluxos de Trabalho Alternativos
2.1. Oportunidade de Negócios Rejeitada
Se em 1.2., a oportunidade de negócios for rejeitada, é possível adotar as seguintes medidas:
-
completamente rejeitada
-
tentativa de empreendimento conjunto com outro Fornecedor
-
redirecionar para outra região
-
transmitir o pedido para outro distribuidor/Fornecedor
-
tentativa de alterar os requisitos do cliente
2.2. Não é Possível Atender aos Requisitos do Cliente
Se em Realizar Análise de Oportunidade ou Preparar uma cotação, A Empresa não puder sugerir uma solução para os
requisitos do cliente, as seguintes ações podem acontecer:
-
sugerir outro equipamento do fabricante
-
reavaliar os requisitos do cliente
-
entrar em contato com A Empresa para descobrir produtos futuros
-
tentativa de alterar os requisitos do cliente
-
decidir desenvolver novos produtos
-
procurar empreendimento conjunto ou fornecedor
-
procurar formas alternativas de financiamento
-
aplicar política de desconto diferente
2.3. Informações Críticas Não Conhecidas
Se, a qualquer momento no Processo de Proposta, A Empresa identificar algumas informações importantes não conhecidas ou
disponíveis, ocorre uma das seguintes situações:
-
Obter as informações
-
Fazer suposição e continuar
Se alguma suposição for feita, ela será registrada e enviada ao Cliente em um documento anexo à proposta.
2.4. Perfil Geral do Cliente Novo/Incompleto ou Incorreto
Se a Empresa determina que o perfil de cliente geral está inexato por algum motivo, as seguintes medidas podem ser
tomadas.
-
Se o Cliente é novo, negocie um acordo
-
Incluir/determinar preferências do cliente
-
Determinar base instalada
-
Pedir uma atualização dos registros
As possibilidades de um caso de uso de negócios devem refletir o potencial de melhoria que você pode ver no caso de uso
de negócios, onde no processo, bem como a escala. Consulte as métricas especificadas para o caso de uso de
negócio.
Um ponto de extensão abre o caso de uso de negócios para a possibilidade de uma extensão. Ele tem um nome e uma
lista de referências para um ou mais locais no workflow do caso de uso de negócios.
Consulte também Diretriz: Relacionamento de Extensão no Modelo de Caso de Uso de Negócios.
-
Seu nome e breve descrição são claros e fáceis de entender, mesmo para as pessoas fora da equipe de modelagem de
negócios.
-
Cada caso de uso de negócio está completo da perspectiva externa (do ator). Por exemplo, o caso de uso de negócios
Tratar Reclamação em uma companhia de seguros começa quando um cliente registra uma reclamação. O caso de uso de
negócio Tratar Reclamação não está completo até que inclua uma notificação sobre a decisão da empresa de seguros
para o cliente e (se apropriado) um pagamento compensatório.
-
Cada caso de uso de negócio normalmente está envolvido com pelo menos um ator. Os casos de uso de negócios são
iniciados pelos agentes, interagem com agentes para executar as tarefas e entregar resultados.
-
É possível, mas incomum, para um caso de uso de suporte não interagir com um agente*. Isso é verdadeiro se um caso
de uso de negócios for iniciado por um evento interno e não tiver que interagir com um agente para executar suas
tarefas.
*Isso pode parecer oposto à definição UML do caso de uso, mas consulte Diretriz: Modelo de Caso de Uso de Negócios, na seção que descreve 'Caso de Uso de
Negócios Interno' para obter esclarecimento.
-
Deve estar claro e fácil de entender, mesmo para as pessoas fora da equipe de modelagem de negócios.
-
Ela descreve o workflow e não somente a finalidade do caso de uso de negócios.
-
Descreve apenas as tarefas internas ao negócio.
-
Descreve todas as tarefas possíveis no caso de uso de negócios. Por exemplo, o que acontece se uma condição for
atendida e o que acontece se ela não for.
-
Ela não menciona agentes que não se comunicam com ela. Se ela mencionasse outros atores, dificultaria o
entendimento e a manutenção da descrição.
-
Descreve apenas as tarefas que pertencem a ela, não o que está ocorrendo em outros casos de uso de negócios que
funcionam em paralelo.
-
Não menciona outros casos de uso de negócio com os quais não possui relacionamentos. Se o caso de uso de negócios
exige que haja algum resultado no negócio antes de poder começar, isso deve ser descrito como uma precondição. A
pré-condição não deve ter referências aos casos de uso de negócio em que o resultado foi criado.
-
Indica se a ordem de qualquer tarefa descrita para o caso de uso de negócios não está fixa.
-
É estruturada para que seja fácil de ler e entender.
-
A descrição mostra claramente o início e o fim do workflow.
-
Cada relacionamento de extensão é descrito com clareza para que fique óbvio como e quando o caso de uso de negócios
deve ser inserido.
-
É substancial. Lembre-se de que um caso de uso de negócios concreto deve ser fácil de ler, junto com seus casos de
uso de negócios abstratos. Portanto, um caso de uso de negócios abstrato não deve ser tão pequeno. Se um caso de
uso de negócios abstrato não for substancial, ele deve ser eliminado e suas tarefas devem ser descritas nos casos
de uso de negócios concretos afetados.
-
Contém as tarefas relacionadas logicamente.
-
Existe por uma razão específica. Um caso de uso de negócios abstrato deve conter qualquer um dos três tipos de
tarefas: as que são comuns em vários casos de uso de negócios; as que são opcionais ou as que são importantes o
suficiente que você deseja enfatizá-las no modelo.
|