Diretriz: Formatos de Casos de Uso
Esta diretriz descreve diferentes formatos de casos de uso e níveis de detalhe associados que você pode usar, dependendo da natureza do projeto.
Relacionamentos
Descrição Principal

Formatos de Casos de Uso

Os casos de uso diferem de projeto para projeto e de pessoa para pessoa. Um caso de uso que funciona em uma situação pode ser totalmente inadequado para outra. Diferentes projetos têm necessidades diferentes. (Veja [ADO04] para obter mais informações sobre formatos de casos de uso.)

Alguns projetos necessitam de documentação rigorosa, incluindo casos de uso de alta cerimônia, que são formais e altamente estruturados. Se os autores estiverem usando um template, então eles preencherão todos, ou quase todos, os campos para cada caso de uso. Os casos de uso de alta cerimônia são mais adequados para sistemas grandes, extremamente complexos e de segurança crítica, tais como sistemas de controle de vôo, centrais telefônicas, etc. Eles também são utilizados em culturas de desenvolvimento que têm elevados padrões de documentação.

Outros projetos podem ser mais ágeis e menos formais, beneficiando-se de casos de uso de baixa cerimônia, que são informais e com estruturação menos rígida. Se os autores estiverem usando um template, então eles poderão deixar a maioria dos campos em branco. Os casos de uso de baixa cerimônia são mais adequados para sistemas menores, menos complexos e de segurança não tão crítica, onde a maioria dos Stakeholders têm uma sólida experiência no domínio do problema. Algumas vezes, bastam simples descrições, tais como casos de uso resumos.

Como a Diretriz: Detalhar Casos de Uso e Cenários explica, faz sentido escrever casos de uso iterativamente. Começando com os detalhes básicos, e depois identificando os vários caminhos alternativos e de erro que o caso de uso possa seguir, você poderá avalia-los, reorganiza-los ou eliminá-los, e então, elaborar ou completar os detalhes dos cursos que pretenda utilizar. Em seguida, você pode escrever os casos de uso em um ou mais dos seguintes formatos, progressivamente, até chegar a um com o nível de detalhe desejado para um projeto específico:

  • Lista Ator-Meta: Um formato para uma visão geral
  • Resumos: Um formato para escrever casos de uso de forma resumida
  • Arranjo Improvisado: Um formato para escrever casos de uso menos formais e de baixa cerimônia
  • Arranjo Erudito: Um formato para escrever casos de uso mais formais e de alta cerimônia

Lista Ator-Meta

Contexto: Você identificou os atores e está tentando identificar os casos de uso.

Problema: Desenvolver um conjunto de casos de uso de forma “imediata” pode levar a trabalho desnecessário, esquecimento de funcionalidades e perda de características. O peso é um dos fatores mais importantes no vôo espacial - tão importante que a agência espacial dos Estados Unidos, NASA, não vai permitir nada em uma nave espacial que não seja absolutamente crucial para o vôo. Se algo não valer literalmente o seu peso, então não irá. Do memo modo, cada caso de uso acrescenta custo ao sistema; Portanto, é necessário que você não se esqueça de incluir apenas os casos de uso que acrescentam valor à sua coleção.

Forças:

  • Relacionar simplesmente os atores ou as metas não é suficientemente informativo, mas relacionar os atores e metas em conjunto é informativo. A abordagem clássica para escrever casos de uso é  definir uma lista de atores e, em seguida, encontrar casos de uso para cada um. Uma variação sobre este tema é discriminar o que o sistema deve fazer. Entretanto, nenhuma destas abordagens é suficiente por si só. Você precisa saber tanto quem está usando o sistema, quanto por que estão usando ele. Senão, você mesmo introduzirá a possibilidade de perda de características, ou de esquecimento de funcionalidades. Pelo menos, um conjunto de casos uso deve descrever esta associação.

  • Uma rápida visão de toda a estrutura do projeto é suficiente e necessária no início do ciclo de desenvolvimento dos casos de uso. Idealmente, esta visão geral deve ser o mas breve possível. Deve conter informações essenciais tais como quem necessita de cada serviço e por que precisa dele. A maioria das outras informações não é muito útil nesta fase do projeto, porque correm o risco de se tornarem obsoletas rapidamente, bem como desencorajar o pensamento criativo e inovador. Uma visão geral ajuda os escritores a trabalhar todo o conjunto com uma visão de alto nível, ampliando alguns casos de uso, eliminando outros e combinando outros em um agrupamento mais lógico.

  • Você precisa ser capaz de expandir cada caso de uso para ser completo. Um esboço de caso de uso constitui a base para a obtenção de um caso de uso completo, posteriormente no ciclo de desenvolvimento iterativo. Cada esboço de caso de uso necessita transmitir informações suficientes para que outra pessoa, que possivelmente não seja o escritor do esboço, possa facilmente expandi-lo para um caso de uso mais informativo.

Solução: Construa uma lista Ator-Meta, que é uma lista de atores e suas metas que lhe dará uma visão global de todas as necessidades do projeto.

  • Comece identificando os atores que irão utilizar o sistema e, em seguida, identifique pelo menos uma meta para cada um. Atores sem metas indicam que você não definiu adequadamente o sistema. O ator está fora do âmbito do sistema, não pertence ao sistema nem faz parte de um outro ator.

  • Da mesma forma, metas sem atores podem indicar que o sistema é muito complexo e que você está tentando realizar muita coisa, ou que não tenham sido adequadamente definidos todos os atores necessários. Avalie cuidadosamente os atores sem meta e as metas sem atores para ver se você está apenas esquecendo algum detalhe, ou se eles não pertencem ao sistema.

  • Remova da lista os atores e metas não associados.

As vezes, essa lista pode fornecer informações suficientes para definir os casos de uso, quando se tratar de equipes de projeto muito pequenas, com grande comunicação e baixa cerimônia. Geralmente, a lista ator-meta é o primeiro passo de identificação dos casos de uso.

Resumos

Contexto: Você escreveu uma lista Ator-Meta que descreve seus casos de uso.

Problema: Basear-se somente em uma visão geral para capturar as partes importantes do comportamento de um sistema é perigoso, porque ela fornece apenas informações de alto nível e pode facilmente introduzir ambigüidades no sistema.

Forças:

  • Embora valiosa, uma lista Ator-Meta não descreve claramente um sistema. Normalmente, um esboço não fornece precisão suficiente para evitar ambigüidade, que pode semear confusão em um projeto direcionando para desenvolvimento desnecessário ou errado. No entanto, um esboço é útil, porque você ainda tem uma visão geral que pode ser facilmente explorada. Infelizmente, com o passar do tempo ou com o grande volume de trabalho, é muito fácil esquecer detalhes que estavam evidentes anteriormente.

  • O desenvolvimento iterativo de casos de uso necessita da criação de lugares-marcados para expansão. Para desenvolver casos de uso iterativamente, você começa com casos de uso esparsos, reorganiza-os e desenvolve-os a medida que o sistema toma forma. Idealmente, estes lugares-marcados devem estar devidamente definidos, para: 1) descrever claramente o seu papel no sistema, e 2) permitir que alguém expanda o caso de uso, mesmo que não tenha se envolvido na sua criação.

  • Pelo fato dos esboços serem genéricos por natureza, não gaste muito tempo, energia ou dinheiro para escreve-los. Os esboços fornecem um método barato de documentar idéias complexas de forma que sejam fáceis de acompanhar. Eles fornecem um mecanismo para que as pessoas de fora do projeto entendam os conceitos de alto nível. Embora seja necessário algum esforço para pensar sobre as coisas, você não deve gastar recursos descrevendo suas idéias. Neste ponto, o sistema ainda está em um estado de fluxo, e ainda é muito cedo para gastar tempo documentando detalhes.

Solução: Escreva de duas a quatro sentenças por caso de uso, capturando os tratamentos de extensões e as atividades essenciais.

  • Expanda a lista Ator-Meta em Resumos escrevendo casos de uso com duas a quatro sentenças para cada entrada na lista.

  • Descreva brevemente o cenário principal e as extensões mais importantes de cada caso de uso.

  • Inclua informações suficientes para eliminar a ambigüidade, no mínimo, do cenário principal do sistema.

Arranjo Improvisado

Contexto: Você está trabalhando em domínios bem conhecidos ou em situações em que escrever casos de uso de alta cerimônia necessitariam da utilização de todo o tempo atribuído ao desenvolvimento.

Problema: Escrever casos de uso formais e de alta cerimônia, quando um menor detalhe seria suficiente, desperdiça tempo e recursos.

O Jazz é considerado "a música das músicas", e os tocadores de jazz são normalmente bem qualificados. Muitos músicos de Jazz preferem improvisar em equipes pequenas e altamente qualificadas, como os quartetos de Jazz. Para efetivamente improvisar, os músicos devem ter um profundo conhecimento das convenções que constituem o estilo musical, incluindo seqüências de cordas, padrões rítmicos e melodias. Estas convenções oferecem uma estrutura básica para os músicos interagirem como uma equipe, permitindo ainda um espaço para a criatividade espontânea.

Da mesma forma, os casos de uso nem sempre precisam ser especificados em detalhes excruciantes. Uma estratégia preferível é simplesmente a definição da estrutura básica de o que os desenvolvedores devem implementar. Os casos de uso agem como lugares-marcados que podem ser elaborados mais tarde ou simplesmente improvisados pelo desenvolvedor, que implementará o caso de uso.

Forças:

  • Os Resumos não fornecem suficientes informações. Embora úteis, Os Resumos de casos de usos descrevem apenas a parte mais significativa do comportamento. Normalmente, os desenvolvedores precisam de mais informações, especialmente quando trabalham em domínios desconhecidos ou no coração do sistema, onde o ator tem muitas escolhas a fazer e muitos caminhos a seguir. Os Resumos não descrevem todos os eventos importantes que podem acontecer, nem descrevem os detalhes que irão fornecer escolhas ao longo do caminho.

  • Casos de uso altamente elaborados podem ser muito caros, demorados, textualmente longos e enfadonhos de ler. Gasta-se muito tempo e esforço para escrever um conjunto de casos de uso formais e totalmente descritivos, e a manutenção deste conjunto leva ainda mais tempo. Normalmente, uma coleção de casos de uso chega ao ponto de diminuir os retornos bem antes de ser completamente escrita, muito menos formalizada. Os leitores normalmente preferem os casos de uso mais curtos e simples ao invés dos mais longos, porque os casos de uso demasiadamente detalhados podem ficar enormes e, francamente falando, muito enfadonhos.

  • Muitos grupos se comunicam suficientemente bem para resolver ambigüidades em vôo. Embora os Resumos possam ser insuficientes, os Stakeholders nem sempre precisam que tudo seja explicado para eles. Os desenvolvedores normalmente são capazes de fazer perguntas e descrever os detalhes necessários a partir de seu próprio conhecimento do domínio. Muitas pessoas podem trabalhar com um nível razoável de ambigüidade, e a maioria das organizações possuem aquilo que é muitas vezes chamado como suas "competências essenciais". Organizações maduras com forte conhecimento do domínio podem sobreviver e mesmo prosperar, usando casos de uso mais informais e menos precisos.

Solução: Especifique os casos de uso em um nível baixo de precisão, permitindo aos desenvolvedores preencher os detalhes faltantes conforme necessário. O nível de precisão exigido depende da experiência da equipe de desenvolvimento. Pule as áreas menos significativas do template, e escreva a seção do Cenário Principal com um simples parágrafo. Descreva os tratamentos de extensão fundamentais nos próximos um ou dois parágrafos. Esteja preparado para resolver ambigüidades e expandir os detalhes em vôo por todo o projeto.

Quando você puder confiar em uma comunicação aberta e franca entre os desenvolvedores e cliente, escreva os casos de uso com menos detalhes e precisão. Os desenvolvedores podem preencher as lacunas, perguntando aos usuários ou usando seu conhecimento do domínio. Contudo, os desenvolvedores precisam de um conhecimento aprofundado do contexto empresarial para poder preencher os detalhes por conta própria. Mesmo o desenvolvedor com grande conhecimento necessitará ter acesso aos clientes e usuários para obter respostas às perguntas e esclarecer os requisitos.

Idealmente, o projeto será estruturado para permitir uma comunicação eficaz entre o cliente e os desenvolvedores. Tipicamente, isto implicará em ter uma equipe pequena e co-localizada, onde os desenvolvedores tenham acesso fácil aos usuários durante todo o projeto. O risco de equívocos pode ser resolvido através de entregas freqüentes e incrementais, se a organização de desenvolvimento  tiver uma cultura de baixa cerimônia.

A improvisação no Jazz nem sempre funciona. Ela pode se tornar enfadonha e desagradável de ouvir, mesmo para os ouvintes comprometidos. Por essa razão, você também precisará do feedback da platéia para determinar o sucesso das improvisações. As revisões de multi-nível ou de duas camadas são críticas para o sucesso (veja Diretriz: Revisões Eficazes dos Requisitos).

A improvisação pode nem sempre ser adequada para a cultura organizacional, um <s0>arranjo erudito</s0> completo, pode ser preferível para equipes grandes e de alta cerimônia (veja a seção a seguir). Por exemplo, uma vez eu vi um maestro movimentar seu bastão em desacordo quando um pianista improvisou de tal forma que a orquestra não pode acompanhar o arranjo. Se a organização considera que o risco de improvisar seja elevado e inaceitável, então você pode especificar os casos de usos com um maior nível de detalhe e precisão. Você pode começar com uma estratégia de especificar com baixos níveis de detalhe e precisão e, em seguida adaptar-se ao necessário.

Arranjo erudito

Contexto: Escrever estruturas em situações de alta cerimônia, como por exemplo quando há muitos desenvolvedores ou as equipes de desenvolvimento estão geograficamente dispersas.

Problema: Escrever casos de uso de baixa cerimônia para situações de alta cerimônia  aumenta o risco de erros de comunicação a níveis inaceitáveis.

Uma versão de arranjo erudito para o maestro contém a música de toda a orquestra, bem como qualquer acompanhamento vocal. As partes a serem executadas por diferentes vozes ou instrumentos são escritas em equipes separadas, com todas as partituras alinhadas, uma sobre a outra. Esse arranjo especifica cada nota e seus tempos associados, com detalhes precisos, de modo que a orquestra possa executar uma sinfonia como o compositor planejou.

Tal como acontece com os casos de uso, o arranjo diz ao músico o que tocar, e não como tocar. Para a maioria das sinfonias, a orquestra não poderá se encontrar com o compositor, então em vez disso, eles devem confiar no maestro para interpretar o arranjo e alcançar as intenções do compositor.

Forças:

  • Determinadas situações e culturas de desenvolvimento exigem alto grau de formalidade. Algumas organizações operam de  uma maneira altamente formal, o que exige um processo altamente formal. Embora esta formalidade possa não ser desejável, ela é a forma da empresa tocar seus negócios, por isso as coisas têm de ser feitas desta forma. Outras organizações são altamente formais, porque elas executam um trabalho altamente complexo e crítico para a vida, onde até mesmo pequenas falhas poderiam ter conseqüências desastrosas. Por exemplo, ninguém se sentiria confortável em voar com uma companhia aérea que tivesse um sistema de gestão de vôo de propósito geral que tivesse sido desenvolvido para qualquer avião.

  • O custo do reparo de erros de comunicação é elevado. É fácil escrever casos de uso vagos e inadequados, cheios de ambigüidades. Os casos de uso podem ser muito curtos e ambíguos, ou conter detalhes específicos do domínio que podem estar além da compreensão dos Stakeholders. De qualquer modo, eles oferecem oportunidades para que equívocos levem a uma implementação incorreta. O custo para corrigir estes erros depende de quando eles são descobertos. Cedo é mais barato do que mais tarde, especialmente quando mais tarde, significa o cliente encontrando o problema no produto entregue. Para evitar erros de comunicação, escreva casos de uso que sejam suficientemente genéricos para que todos os Stakeholders possam acompanhar, porem precisos o bastante para que os desenvolvedores possam utiliza-los na construção do sistema.

  • Os desenvolvedores necessitam dos detalhes para implementar as atividades, as regras de negócio, os campos de dados e, especialmente, para a  manipulação de extensões. Ninguém ainda desenvolveu um programa que pegue um conjunto de casos de uso como entrada e gere um sistema completo. Mesmo as melhores ferramentas case necessitam da intervenção humana para aperfeiçoar os detalhes e resolver as ambigüidades. Da mesma forma, os desenvolvedores que não entendem o contexto empresarial ou tem falta de experiência no domínio podem não ser capazes de compreender totalmente um produto. Em um projeto ideal, os desenvolvedores de software deveriam ter acesso aos peritos do domínio para fazer perguntas, de forma que eles pudessem preencher quaisquer áreas que estivessem faltando (veja Arranjo Improvisado, acima). Mas, normalmente, eles não perguntam. Portanto, eles não compreendem os casos de uso mais complexos e ambíguos do conjunto. Para desenvolver um sistema corretamente, a equipe precisa ter acesso aos peritos do domínio ou à informações adicionais que descrevam as atividades, as regras de negócio, os campos de dados, e a manipulação de extensões que deverão implementar.

Solução: Especifique os casos de uso, com um alto nível de precisão, preenchendo explicitamente todos os detalhes do template de caso de uso, embora permanecendo tecnologicamente neutro. O nível de precisão necessário depende da experiência da equipe de desenvolvimento.

A intuição poderá lhe dizer que, se algum detalhe é bom então mais deve ser melhor. No entanto, seja cuidadoso para não cair cair na armadilha do excesso de especificação de detalhes. É ingênuo acreditar que qualquer pessoa que leia os casos de uso seja capaz de compreendê-los. Diferentes pessoas podem interpretar casos de uso de formas diferentes. Prepare-se para essa eventualidade em seu processo e evite a tendência de super-especificar os casos de uso. Se você tentar especificar um caso de uso com muito detalhe, você poderá cair na clássica armadilha da paralisia analítica.

As pessoas são muitas vezes tentadas a resolver o problema de comunicação, tentando explicar o domínio de negócio nos casos de uso. De forma semelhante, eles incluem muitos detalhes técnicos. Sucumbir a essas tentações, explicando o domínio de negócio ou incluindo detalhes técnicos é sempre um erro, uma vez que complica o processo e obscurece os requisitos. O leitor dos casos de uso não poderá distinguir os verdadeiros requisitos da informação enfadonha, e assim irá rapidamente se distrair e perder o interesse. Em vez disso, inclua essas informações em uma seção extra.

Se estiver entregando os requisitos para uma equipe de desenvolvimento, cujos membros não estejam familiarizados com o domínio, você vai precisar de uma estratégia alternativa para lhes passar o conhecimento do domínio.