Os sete equívocos dos casos de uso

P1030183

Longe de ser uma autoridade no assunto, sou um profissional que utiliza essa técnica de descoberta, comunicação e, eventualmente, documentação constantemente.
 
Trabalhando no SDC da Stefanini tenho me deparado com mais e mais casos de uso geralmente escritos por nossos clientes ou por empresas contratadas por eles para isso e apesar das boas intenções dos autores, é fácil me deparar com casos de uso que contém uma série de equívocos, o que, acaba fazendo com que eles não cumpram a sua função, ou pior, que sejam desprezados pelos clientes e odiados pelos desenvolvedores e pessoal de QA.
 
Se você trabalha escrevendo casos de uso, espero que esse post o ajude a identificar alguns equívocos que podem estar impedindo que você tire melhor proveito dessa técnica que considero poderosa. Se você utiliza os casos de uso escritos por outras pessoas para o seu trabalho, espero que esse post o convença a dar mais uma chance para eles e também, claro, que o ajude a cobrar um bom trabalho de quem os escreve.

Eu escrevi e reescrevi a introdução deste post algumas vezes. Ocorre que é muito difícil escrever algo que começa como “Os sete erros” sem ser arrogante. Dessa forma, troquei “erros” por “equívocos”. Ficou melhor? Bem, aí vai a lista:

  1. “Estufar” o caso de uso com informações relacionadas que tem a ver com o mesmo assunto, mas que estão fora do seu escopo.
  2. Inserir informações referentes à interface/usabilidade.
  3. Inserir informações técnicas referentes à solução.
  4. Disfarçar requisitos funcionais na forma de regras de negócio.
  5. Não fazer sentido em relação às entidades do negócio.
  6. Incorporar muitos objetivos do usuário em um único caso de uso.
  7. “Arte pela arte”.



1. “Estufar” o caso de uso com informações relacionadas que tem a ver com o mesmo assunto, mas que estão fora do seu escopo

É comum um caso de uso fazer parte de um contexto maior. Por exemplo, através de um caso de uso o usuário configura as funcionalidades as quais alguém tem acesso no sistema. Essa configuração impacta outros casos de uso como “Entrar no sistema”, o famoso, “login”.

É comum o autor do caso de uso querer explicar no documento como funciona o processo completo, da configuração do perfil de acesso ao login e uso do sistema. Dessa forma, “estufa” o caso de uso de configuração do perfil com descrições de regras de negócio que se aplicam, de fato, a outros casos de uso.

Do ponto de vista do desenvolvedor, no momento que está lendo o caso de uso, o que interessa é saber o que deve ser feito naquele caso de uso. Independente da metodologia usada, essa informação é necessária para estimativas de tempo ou pontos. Informações a mais viram “distração”, trazem ambiguidade e isso é “cobrado” pelo desenvolvedor com uma espécie de “taxa de ambiguidade”.

Certo, mas contextualizar o caso de uso é importante, afinal, sabemos que para desenvolver um bom sistema é necessário. Bem, existem três formas de fazer isso. A primeira é escrever um ou dois parágrafos sobre o caso de uso logo abaixo seu nome. Se você sempre fizer isso, ficará claro que se trata de texto livre para contextualização, ou seja, não “contamina” o caso de uso em si. A segunda é escrever um documento anexo de contextualização. A terceira é a que eu considero melhor, mas só é possível quando temos acesso aos desenvolvedores: conversa. Muita conversa.

2. Inserir informações referentes à interface/usabilidade

Apesar dos clientes costumarem interagir bem com telas, um caso de uso deve sempre, poder ser descrito, compreendido e executado como independente da plataforma, ou seja, as informações do caso de uso devem ser independentes de coisas como “botões”, “listas”, “tabelas” e, por favor, “cores”.

Pensar no layout enquanto modela o caso de uso traz riscos em duas frentes. Na primeira, o autor do caso de uso está deixando de pensar “no que” o usuário deve poder fazer através do caso de uso e está pensando no “como” ele vai fazer isso. Pode parecer bobo isso, mas já vi várias vezes as pessoas discutindo layout de um caso de uso que não tinha um objetivo claro.

Layout e usabilidade são impostantíssimos, mas cada um deve ser discutido ao seu tempo. Não adianta fazer um ótimo “como” sem ter um ótimo “o quê”. Meu artigo sobre a pirâmide de Maslow, ou teste do trabuco, fala bastante sobre isso.

Na segunda frente, temos um caso de uso que se “intromete” no trabalho dos desenvolvedores (ou, com sorte, dos especialistas em usabilidade). Se você coloca a palavra “combo-box” no caso de uso e a solução for desenvolvida usando outro item de interface, você diria que o desenvolvimento errou? Quem é você para dizer que “combo-box” é a melhor solução?

Enfim, faça o seguinte exercício: escreva seus casos de uso de forma que eles possam ser executados através do telefone através de uma URA (Unidade de Resposta Audível). Isso vai, com certeza livrá-lo dos botões, combos e outras coisas que não deveriam estar ali.

Um caso de uso é um problema a ser resolvido por uma solução. Quem escreve o caso de uso deve ter foco no problema.

3. Inserir informações técnicas referentes à solução

Esse equívoco é parecido com o número dois. A diferença é que ao invés de se intrometer no trabalho referente à solução no que tange ao layout e usabilidade, o autor se intromete em questões técnicas da solução, como banco de dados e algorítmos.

Um caso de uso é uma representação do sistema “caixa-preta”, ou seja, ele narra a interação do usuário com o sistema, entradas e saídas, sem o conhecimento de como as coisas funcionam internamente. Ao fazer referência à lógica de programação ou bancos de dados, o autor está se intrometendo no trabalho de quem deve definir como será a implementação.

4. Disfarçar requisitos funcionais na forma de regras de negócio

Levanta a mão quem sabe dizer em poucas palavras o que é uma regra de negócio! Ihh, ninguém levantou. Tudo bem, é difícil mesmo explicar.

Eu gosto da definição “é tudo aquilo que afeta os requisitos, mas que não é requisito”. Ok, apesar de ser filosoficamente correta, não diz muito, certo?

Acredito que o problema das regras de negócio seja a crença de que elas estão (ou devem ser) sempre representadas em texto. Isso está errado. A grande (ou pequena) minoria das regras de negócio devem ser representadas em texto, na verdade, elas são a excessão.

Acredito que 85% das regras de negócio estão em um diagrama de entidades (seja classes seja DER). Tudo, dos nomes das entidades até seus relacionamentos e cardinalidades passando pelos atributos, são regras de negócio. Existe algo “mais regra de negócio” do que saber se um funcionário pode ter apenas um, ou mais chefes? Acredito que não.

Outro exemplo de regras de negócio são os diagramas de máquina de estados. Essa é uma ferramenta poderosa quando você tem uma entidade no sistema que possui diferentes estados e inúmeras “regras” coordenando essas transições.

Essa crença de que um caso de uso deve ser recheado de regras de negócio no formato de texto faz com que os autores forcem a barra tanto colocando nele RNs que não dizem respeito (gerando aquela distração do equívoco 1) quanto do que chamo de “armadilhas”.

Essas armadilhas costumam ser requisitos funcionais disfarçados de regras de negócio. Ao invés de, por exemplo, criar um fluxo específico para uma determinada funcionalidade, o autor cria uma regra de negócio que diz que isso pode ser feito pelo usuário.

Em um exemplo recente o caso de uso era um CRUD (Create, Read, Update, Delete) simples, os fluxos estavam ok, contudo, lá no meio das regras de negócio existia algo assim: “o usuário poderá duplicar um item a partir de um item existente”. Opa… perigo, perigo.

Veja que tudo o que é funcional depende de verbos. Fique atento aos verbos contidos nas regras de negócio, nesse caso, duplicar, é uma FUNCIONALIDADE do sistema, ou seja, quem não ver isso, pode achar que o caso de uso possui menos funcionalidades do que realmente possui.

Sabe qual a quantidade média de regras de negócio expressadas em texto contidas nos meus casos de uso? Uma.

5. Não fazer sentido em relação às entidades do negócio

Eu já vi dois casos de uso de um mesmo sistema que separados faziam sentido, mas que quando lidos juntos, geravam uma enorme confusão.

Os casos de uso representam a visão “dinâmica” do sistema, ou seja, o que acontece, o que é feito, o que depende do tempo.

As entidades do negócio representam a visão “estática” do sistema, ou seja, o que é, o que diz como pode ser, tudo aquilo que não depende do tempo.

Miha analogia preferida é a que diz que as entidades do negócio são o lago do qual todos os casos de uso bebem. É o que garante que um caso de uso faça sentido e que respeite as regras de negócio (veja o item 4).

Como disse, acredito que 85% das regras de negócio estão em um diagrama de entidades (seja classes seja DER). Tudo, dos nomes das entidades até seus relacionamentos e cardinalidades passando pelos atributos, são regras de negócio. Existe algo “mais regra de negócio” do que saber se um funcionário pode ter apenas um, ou mais chefes? Acredito que não.

Minha recomendação é anexar ao caso de uso um diagrama que represente as entidades. , mas somente aquelas diretamente envolvidas no caso de uso.

6. Incorporar muitos objetivos do usuário em um único caso de uso

Este é um dos mais comuns e graves equívocos dos casos de uso e a principal causa da sua obesidade. É comum eu ouvir alguém dizer algo como “os casos de uso estão bons, precisamos apenas dar uma revisada e quebrar alguns em casos de uso menores”.

Em outras palavras, isso quer dizer: “caramba, esses casos de uso estão enormes! Cada um parece um livro que cobre uma parte enorme do sistema. Vamos ter que jogar tudo fora e começar novamente com o tamanho certo”.

Um caso de uso é um objetivo independente que o usuário atinge (ou tenta atingir) através de um sistema e que traz valor tangível para o negócio.

Em outras palavras, um caso de uso é algo que você faz através do sistema que é pequeno o suficiente para ser atômico, ou seja, que não pode ser quebrado em partes menores, mas que, ao mesmo tempo, traz valor tangível para o negócio.

Por exemplo, selecionar um item em uma lista poderia ser considerado um objetivo do usuário através do sistema, contudo, como não traz valor tangível para o negócio, não se qualifica como caso de uso.

Por outro lado, um cadastro que pode envolver várias partes opcionais, deveria ser quebrado em diferentes casos de uso, sendo que o UC base seria estendido pelos opcionais. Vou usar o exemplo de um projeto atual, um cadastro de veículo. O usuário pode cadastrar um veículo e, opcionalmente, cadastrar fotografias.

Em um caso de uso “gordo”, teríamos tudo junto, com o cadastro de fotografias como fluxo alternativo. O correto é fazer um caso de uso específico para o cadastro de fotografia que estende o caso de uso base “cadastrar veículo”.

Quando usamos a regra “um objetivo, um caso de uso”, facilitamos a compreensão dos requisitos, afinal, é bem mais fácil ler um caso de uso com poucos passos e fluxos alternativos.

Também é mais fácil justificar o valor de cada caso de uso para o cliente, além de poder priorizar esses casos de uso e desenvolvê-los em diferentes momentos, afinal, são objetivos independentes, talvez valha a pena utilizar o cadastro sem fotos por um tempo, implementando outras funções importantes antes.

7. “Arte pela arte”

Este é, sem dúvidas, o mais nefasto equívoco cometido por alguém responsável pela modelagem de casos de uso.

No final do século XIX surgiu um estilo de poesia chamado parnasianismo. Os adéptos do parnasianismo primavam pela forma deixando o conteúdo meio de lado, ou seja, transformaram a poesia em ciência exata. No parnasianismo era mais importante, ou melhor, era indispensável seguir regras que iam da quantidade de letras de cada verso até a forma de rimar.

Isso nos brindou com uma série de poemas que possuem, na minha humilde opinião, como único atrativo, o valor histórico.

Os parnasianistas possuíam uma característica chamada “Arte pela arte”. Segundo a Wikipedia (e o professor Ezequiel): “A poesia vale por si mesma, não tem nenhum tipo de compromisso, e se justifica por sua beleza (…)”

É possível criar casos de uso parnasianistas? Sim, e como. Já me deparei com casos de uso inúteis, verdadeiros enígmas a serem desvendados, do tipo que não são compreendidos pelos clientes e que são desprezados pelos desenvolvedores.

O mais interessante é que eles são escritos com extrema atenção à forma. Sim, estou falando de templates e documentos padrão.

Não sou contra alguma padronização dos entregáveis (essa frase até soa bem), contudo, o meio não pode superar o fim.

A pergunta deve ser “por que estamos modelando casos de uso?”. Se a resposta for “para documentar os requisitos” ou “por que fomos contratados para isso”, fuja.

Os casos de uso devem ser modelados com o objetivo de compreender as necessidades do negócio de modo a produzir software rodando que auxilie o negócio da melhor forma. Todo o resto é secundário.

Dessa forma sou contrário a um modelo no qual quem modela os casos de uso esteja distanciado e sem interação com quem desenvolve o sistema. Essa situação leva à arte pela arte e a um descompromisso com o objetivo final do processo.

Seu trabalho se torna uma etapa e não um produto final. Fica muito fácil no final dar de ombros e dizer “fiz a minha parte”. Coisa de galinha, não de porco.

A melhor forma de trabalhar com casos de uso é em um processo iterativo, ou seja, você modela casos de uso que serão utilizados pelo desenvolvimento e QA em seguida. Além de você estar envolvido de fato no processo de criação de software, entre uma iteração e outra aprende com seus erros e aplica o aprendizado nos próximos casos de uso, afinal, o melhor caso de uso é aquele que cumpre o seu objetivo da melhor maneira.

Não existe padrão que sobreviva a colocar os casos de uso “para rodar”. Você sempre aprende algo e melhora. Em alguns casos, a melhoria pode levar você a caminhos nem imaginados, como, até mesmo, abandonar os casos de uso.

Algo que deixaria os parnasianistas muito irritados também se aplica aos casos de uso: “só se atinge o progresso quando se abre mão da ordem”. Processos padronizados e amarrados são um perigo.

Conclusão

Espero que esse post tenha contribuído com o seu trabalho. Se você discorda de algum dos equívocos, conhece um equívoco que não coloquei aqui ou simplesmente gostaria de me elogiar, por favor, comente aqui no blog.

Desejo muito sucesso para você nos seus projetos e, por sucesso, quero dizer, software rodando que traz ROI, afinal, “Above us, only ROI”.

 

29 ideias sobre “Os sete equívocos dos casos de uso

  1. Excelente post Claudio. É cada absurdo que a gente encontra por aí quando o assunto é levantamento de caso de uso. E a história quase sempre é a mesma: "mas o cliente/usuário não soube me explicar". Cabe a nós/analistas "sugar" os casos de uso, seguindo claro boas práticas e evitando os equívocos mais comuns, como você explicou brilhantemente aqui.Parabéns e obrigado por compartilhar sua experiência conosco.Abraço.Helbert Miranda@helbertm

  2. Parabéns Claudio. Excelente post.Realmente, é assustador e infelizmente, MUITO COMUM encontrarmos essas falhas citadas por você nos UC´s. Falta de preparo dos profissionais? Pouca importância destinada para a modelagem do negócio?Mais uma vez, parabéns pelo artigo, que nos ajuda a fazer uma auto-critica, evitando "equivocos" que as vezes não percebemos.AbraçosThiago

  3. Cláudio, parabéns pela a iniciativa de explanar os principais erros que cometem com essa ferramenta poderosa. Já cometi todos e acredito que só há evolução com os erros.Acredito também que uma ferramenta só se torna muito boa e estável com o tempo de uso. Passou a moda do RUP? Quem soube usá-lo corretamente? Vai passar a moda do ágil? Com certeza. Quem está no mercado há mais tempo vai lembrar da análise estruturada, essencial e a da orientação a objetos que está aí. O fato é que esses erros acontecem, ainda, porque as pessoas não aprenderam a usar o caso de uso ou foram muito mal ensinadas.Tecerei alguns comentários que julgo importantes:1 – No item 6 você dá um exemplo de como definir casos de uso com objetivos específicos. Aqui deve-se tomar muito cuidado para não realizar a tal da "decomposição funcional", que representa a separação de funcionalidades que deveriam estar agrupadas em um único caso de uso. Talvez o ponto mais importante na engenharia de requisitos é este, onde define-se a estrutura dos casos de uso. Erros podem acontecer aqui e devem ser corrigidos aqui;2 – No item 1 você cita três formas para contextualizar sobre o caso de uso: "A primeira é escrever um ou dois parágrafos sobre o caso de uso logo abaixo seu nome". Isso é fundamental e deve estar contido em uma lista de requisitos funcionais (alguém faz isso? Eu faço.). Se não houver essa lista deve haver um diagrama de caso de uso (apenas ele) que representa a fronteira do sistema e o relacionamento entre os casos de uso. Sou adpeto que uma figura fala mais que mil palavras;3 – No item 4, onde você fala sobre regras de negócios eu tenho alguns pontos importantes a relevar: concordo que cerca de 85% das regras estão no modelo. No entanto, estas regras advém do processo na qual o sistema se apóia para realizar as tarefas. Portanto, eu acredito que só chegamos ao MER após as definições das regras de negócio, juntamente com os casos de uso. Definir se algo é um passo ou um fluxo de um caso de uso, uma regra de negócio, ou simplesmente outro caso de uso não é fácil mesmo e requer muita experiência (saber como as coisas funcionam no desenvolvimento, banco de dados, projeto e requisitos). O que tenho observado é que muitos analistas de negócios que fazem levantamento de requisitos, na verdade, são escribas. A capacidade analítica para realizar a modelagem dos casos de uso está aquém do que realmente precisamos no mercado de trabalho.Bem, poderia escrever durante dias aqui; vamos esperar outras opiniões para desenvolver o assunto.Léo Araújo

  4. Paolo, não concordo que caso de uso seja desnecessário. Hehe, me desculpe, corrigindo: o caso de uso é uma ferramenta para requisitos, dentre várias existentes. Garanto que qualquer ferramenta mal utilizada será desnecessária.Realmente confunde e muito desde que todos os sete erros que o Claduio citou aconteçam. Aliás, nem precisa acontecer todos. Basta um!E concordo, não é ágil.

  5. Gustavo, na verdade o caso de uso independe de tecnologia. Só lembrando que o caso de uso descreve o comportamento do sistema em termos de seqüências de ações e deve produzir um resultado de valor observável para um agente (Alguém ou algo, fora do sistema que interage com ele).Para SOA existem outras documentações (o RUP 7 trata SOA).

  6. @tfpereira, pois é, não posso escapar de dizer que falta qualificação dos profissinais. É falta de cursos? Não sei, acho que é falta de oportunidade em trabalhar em ambientes onde tenham bons exemplos.

  7. Léo Araújo, seus comentários foram muito coerentes. Estou com a impressão de que você tem a mesma ou maior experiência com casos de uso do que eu. Temos que trocar umas ideias. Acho que vou "roubar" coisas do seu comentário para aperfeiçoar o post.

  8. Oi Paolo! Eu imagino que você tenha participado de projetos que se viraram muito bem sem casos de uso. Eu acho isso saudável e totalmente possível, porém, acredito que existem muitos casos nos quais a melhor forma de ser ágil (talvez a única possível) seja utilizar casos de uso. Bons casos de uso, claro, não os monstrinhos.Acho muito legal esse posto do Tyner Blain sobre documentação ágil que ele começa com: "Agile values working software over comprehensive documentation – it is 1/4th of the original manifesto. That doesn’t mean don’t document! It means don’t document more than you need to document. Documentation does have value, but the practice of documenting got excessive – that’s why a reaction to the bad stuff earned a spot as one of the pillars of agile. How do you avoid over-reacting when changing a culture of over-documentation?"http://tynerblain.com/blog/2010/11/16/agile-documentation/?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+TynerBlain+%28Tyner+Blain%29Grande abraço! Espero poder te mostrar um projeto legal com casos de uso no futuro!

  9. Oi Gustavo, é como o Leo falou mesmo. A SOA é solução. Estou em um projeto no qual podemos resolver as coisas de três formas, acesso direto ao banco de outra aplicação, arquivos batch ou a publicação de um serviço. O que fazemos? Esquecemos isso. Primeiro temos que saber o que o usuário deve ser capaz de fazer através do sistema. Primeiro o "o quê", depois o "como".Grande abraço!

  10. Cláudio, gostei de suas colocações. Creio que uma parcela de culpa desse estado de coisas deva-se ao fato de muitos acharem que tem que (ou devem) ser muito bem explicadinhos, e nesta hora pecam por excesso e pelas divagações, e acabam colocando na receita ingredientes que absolutamente não fazem parte dela. Acrescente-se a isso o fato de muitos escreverem muito mal em termos de construir, articular e passar para o papel as idéias, e o que se vê é um conjunto bastante confuso, muito pouco claro, o que só atrapalha o resultado final.Creio que no item 7 quando você escreveu …No final do século IXX… estaria querendo dizer XIX, certo ? Apenas um detalhe e que não tirou em absoluto o brilho do artigo. Parabens !!! Rui Natal

  11. Claudio, fique à vontade para "roubar" o que desejar do comentário.Eu já fiz alguns projetos com casos de uso. Uns deram certo; outros deram mais certo ainda. É que eu realmente aprendi a usar um caso de uso.Se quiser trocar idéias pode entrar em contato comigo ou enviar um post para o grupo an.br.

  12. Claudio, ia comentar seu post ontem, logo que li… Mas ainda bem que deixei pra hoje. Acredito que o unico erro que ainda pratico (mesmo que contra minha vontade) é o "Arte pela arte". O cliente define quais serão os casos de uso e qual o template que deverá ser utilizado, engessando bastante o processo por aqui. Ainda assim, muitas vezes consigo um acordo com o analista de negócio para quebrar um caso de uso grande em mais casos de uso, diminuindo a ambiguidade e fazendo com que a leitura fique mais fácil. E que o caso de uso sirva para o desenvolvedor trabalhar (principal objetivo, mas ignorado por aqui)Outro ponto que fiquei em dúvida, é o das interfaces: É claro que não estou falando de itens ou opções (combo-box). Mas hoje não vejo o papel de quem vai "desenhar" o sistema senão o do próprio analista que fez o caso de uso, ou seja, a documentação necessária é o caso de uso, diagrama e protótipo, sem dar maiores detalhes sobre a implementação. Neste caso, quem o faria? (no ultimo projeto que participei, fiz tudo)Ainda mais, concordo e muito com o que o Leo disse sobre analistas serem escribas, que não conhecem análise e os demais componentes de um software. Também concordo sobre a lista de requisitos (e rastreabilidade também!). Fica fácil dizer "fiz minha parte" e deixar o desenvolvedor apanhar. De qualquer forma, acho a discussão bastante válida e faz com que aumente a auto-critica de muitos BAs. Assim, é possível melhorar nossa capacidade analítica dia-a-dia.Parabéns pelo post!Abraço!

  13. Concordo com as palavras da Priscila, muitas vezes ficamos "engessados" porque o cliente define o que quer e como quer. Passei por essa situação a pouco tempo e admito que não me senti nada confortável, uma situação bem delicada. Há muito tempo não lia um post tão bacana, parabéns pela iniciativa!

  14. ClaudioPeguei o link deste seu post na lista an-br. Gostaria de sugerir mais posts sobre o tema, já que você é um divulgador influente de boas práticas.Hoje atuo em projetos com funcionalidades bastante complexas e os casos de uso acabaram tendo as seguintes características:- Público alvo: > área de negócios: a partir do caso de uso validam não só o requisito que será implementado pelo sistema mas revisam o processo de negócio relacionado e as regras de negócio relacionadas, o caso de uso virou documentação para eles.> analistas de testes: a partir das rotas mapeadas no caso de uso, definem os cenários que serão testados (casos de testes)> desenvolvedores: analisam o fluxo da aplicação com as diversas rotas alternativas. Muitas vezes estas rotas alternativas são melhor visualizadas em um diagrama de atividades, elaborado a partir do caso de uso e vice versa. As rotas alternativas são numeradas e citadas nos comentários dos códigos fontes que as implementam (para facilitar as manutenções).> Analista de requisitos (autor), Analista de negócios e gerente de projetos: controlar alterações de escopo durante o projeto com base nas alterações/inclusões de novas rotas alternativas (cenários).- Vida útil do caso de uso: Além do projeto. Após o projeto existem manutenções mensais de algumas regras de negócio, já que temos com freqüência alteração de regra de negócios devido ao dinamismo do mercado que atuamos.No geral tenho um bom feedback (cliente, analistas de testes, desenvolvedores) sobre os casos de uso gerados desta forma, mas gostaria de ouvir sua opinião sobre ser ou não ser uma boa prática o caso de uso ter múltiplos públicos e objetivos para o projeto (e além do projeto). Além da repulsa que alguns agilistas tem a casos de uso, existem algumas opiniões divergentes no mercado quanto ao tempo de vida do caso de uso. Algumas pessoas afirmam que o caso de uso no final de projeto vira lixo. Você concorda? A cada projeto de manutenção evolutiva (em sistemas legados) deve-se escrever novos casos de uso (mesmo que a evolutiva seja alteração em rotas alternativas já mapeadas anteriormente)?

  15. Oi Debora, desculpe, o e-mail que avisa novo comentário simplesmente não chegou, só vi porque você avisou.Bem, a primeira pergunta é: "gostaria de ouvir sua opinião sobre ser ou não ser uma boa prática o caso de uso ter múltiplos públicos e objetivos para o projeto (e além do projeto)."Sim, o projeto precisa de um ponto único de referência. Mesmo que o caso de uso não seja perfeito (apesar de muito bom) para comunicar todos os aspectos do projeto para todas as partes interessadas, imagine o custo e o risco de ter que manter a mesma informação em formatos diferentes. Por incrível que pareça, estamos fazendo isso com estórias do usuário. A questão não é a forma, mas o fato de que colocamos todos juntos na mesma sala para escrever a história, assim, pontos de vista não são perdidos, mas isso é outra conversa.A segunda pergunta é: "Além da repulsa que alguns agilistas tem a casos de uso, existem algumas opiniões divergentes no mercado quanto ao tempo de vida do caso de uso. Algumas pessoas afirmam que o caso de uso no final de projeto vira lixo. Você concorda? A cada projeto de manutenção evolutiva (em sistemas legados) deve-se escrever novos casos de uso (mesmo que a evolutiva seja alteração em rotas alternativas já mapeadas anteriormente)?"Ai ai. Eu passava mal quando o Paulo Vasconcellos falava em atear fogo sobre os casos de uso após o projeto, mas hoje não acho mais tão absurdo.Acredito que o que você faz com os casos de uso depende do seu envolvimento com o sistema. Se você foi chamado para fazer uma melhoria pontual, dentro de um projeto, você pode escrevê-los, implementá-los e esquecê-los. Se você está trabalhando com o sistema de forma evolutiva, pode trabalhar sobre os mesmos casos de uso.Contudo, lembro que se você trabalhar com casos de uso magrinhos, você terá poucas alterações em casos de uso existentes, pois as funcionalidades estão distribuídas em inclusões e extensões.Um caso de uso gordo, difícil de atualizar não deve ser mantido para que você possa reaproveitá-lo, ele deve ser quebrado em unidades atômicas de funcionalidade (que tragam valor sozinhas), isso vai deixar seu gerenciamento bem mais fácil.Quebre os UCs no tamanho certo e você não terá problemas em gerenciá-los.Sobre a repulsa dos agilistas aos casos de uso, acredito que tenha mais a ver com a forma com a qual eles costumam ser usados do que a sua formatação em si. Escrever o caso de uso em uma sala escura e depois entregá-lo para o desenvolvedor como se fosse um contrato, sem permitir interação com as partes interessadas nem que eles apliquem sua criatividade sobre os fluxos transforma o trabalho de desenvolvimento algo alienado e estéril. Eu não gostaria de desenvolver assim.

  16. Claúdio muito legal a sua inciativa. Sou iniciante nesta área de especificação de requisitos. Já estudei e li muitos artigos sobre casos de uso e a maioria utiliza uma abordagem mais acadêmica. Gostei muito do seu post porque é uma abordagem do mundo real, ou seja, você já vivenciou a utilização de casos de uso e compartilhou a sua experiência. Seria possível você disponibilizar um exemplo de caso de uso (básico) que você considera funcional, ou seja, atende o objetivo proposto sem cometer os equívocos relatados neste post? Parabéns pelo post!

    • Rodrigo, quer apostar que mais quatro anos vão se passar e ainda vamos encontrar esses equívocos? As suas causas continuam por aí, em salas de reunião, em propostas comerciais e pior, em cursos.

  17. Claudio bom dia
    Sou analista de testes e recentemente me foi atribuída a atividade de analista de processos por caso de uso, não tenho experiencia nesse processo, gostaria de saber se você tem algum material para iniciante para entender melhor esse mundo de caso de uso.
    muito obrigado
    Roberval

    • Ihh meu amigo, acho que da forma com a qual o uso de casos de uso ainda é ensinado/imposto vamos ver esses equívocos (você escreveu pecados!) por muito tempo em muitos lugares. O importante é você trabalhar com eles esses pontos e todo mundo pensar na real razão para escrever esses casos de uso e se eles são ajudando vocês a atendê-la da forma como estão.

Deixe uma resposta

O seu endereço de email não será publicado Campos obrigatórios são marcados *

Você pode usar estas tags e atributos de HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

Current day month ye@r *