Os desenvolvedores não entendem o domínio do problema (é importante os desenvolvedores estudarem o negócio em profundidade, não existe mais desenvolvedor “trancado numa sala”; eles precisam ter contato com a operação para amadurecerem e melhorarem seu entendimento sobre o negócio e sobre o mundo);

Bem, você percebeu como é importante ser analítico, crítico e lógico nessa nossa profissão. A
clareza e declaração sem ambiguidade são fundamentais quando estamos elicitando requisitos e/ou
desenvolvendo casos de uso.

Temos aqui a descrição do mesmo caso de uso totalmente documentado. Este é um exemplo
maravilhoso de um caso de uso bem construído, mas apresenta muito mais detalhes do que você
possivelmente precisa no primeiro momento.

Se você realmente precisa desse nível de detalhe e, na prática, raramente o faz, pode capturá-lo
quando realmente precisar.

Comunicação é tudo e, nesse caso, é preciso feedback com a equipe, porque quanto mais tempo
você passar sem pedir feedback para o cliente/usuário, maior será o perigo de se modelarem coisas
que não refletem o que as partes interessadas realmente precisam.

Dessa forma, na fase inicial do planejamento, use casos de uso simples como o do primeiro exemplo
para completar ou ilustrar os cartões de história do usuário para dar mais clareza.

Nas fases posteriores, declare analiticamente como no segundo exemplo, afinal, fica difícil para um
desenvolvedor saber o que ele tem que fazer sem as regras de negócios ou as telas da interface do
usuário (camada de apresentação) que foram criadas. Por isso vemos tanta coisa sem sentido por aí,
porque deixaram a critério do desenvolvedor algo que não é missão dele fazer. Lembre-se,
[interface do usuário, front end e back end] são grandes atividade que se deve trabalhar seguindo
padrões e metodologias porque uma depende da outra.

Caso você esteja no nível mais inicial possível, ainda pode recorrer ao bom e velho, e sem dúvida
alguma, muito útil, diagrama de caso de uso.

Recomendo que você crie, inicialmente, todos os diagramas de caso de uso, como o demonstrado
acima, para os cartões de história do usuário como requisitos e verifique se não falta nada, se há
lógica e complementaridade e principalmente se o “bicho tem cabeça tronco e membros”.

Tome cuidado porque há desafios no processo de levantar requisitos e convertê-los em artefatos.
Abaixo listo alguns, mas dê muita atenção a todos eles para não cometer essas faltas.

Acesso limitado às partes interessadas do projeto (clientes e usuários);

Partes interessadas do projeto geograficamente dispersas (estão distantes em outras
cidades, países ou regiões de difícil acesso. Nesse caso use reuniões remotas síncronas
ou documentos como questionários);

As partes interessadas do projeto não sabem o que querem (mais comum do que
parece, nesse caso, seja um guia ou “terapeuta”);

As partes interessadas do projeto mudam de ideia (negocie, eles fazem isso por causa
do item anterior, eles vão descobrindo conforme pensam no próprio negócio, coisa que
a rotina não deixa);

Prioridades conflitantes (saiba negociar com o sponsor, usuário ou product owner);

Muitos participantes do projeto desejam ter voz;

As partes interessadas do projeto prescrevem soluções de tecnologia (faça-os aterem-
se à área de domínio deles, ou seja, negócios);

As partes interessadas do projeto são incapazes de ver além da situação atual (em
tecnologia, chamamos a isso de paralisia de paradigma, crença limitante ou a popular);

As partes interessadas do projeto têm medo de ser fixadas (é uma questão cultural, às
vezes, é necessário tempo e confiança, afinal, as partes interessadas devem ter
responsabilidades pelo bom andamento do projeto);

As partes interessadas do projeto não entendem os artefatos de modelagem. (conte uma
história, pessoas se encantam com histórias, a técnica de story telling veio para ficar);

Os desenvolvedores não entendem o domínio do problema (é importante os
desenvolvedores estudarem o negócio em profundidade, não existe mais
desenvolvedor “trancado numa sala”; eles precisam ter contato com a operação para
amadurecerem e melhorarem seu entendimento sobre o negócio e sobre o mundo);

As partes interessadas do projeto estão excessivamente focadas em um tipo de
requisito (reuniões do tipo Delphy ou Brainstorming ajudam a tirar essas travas);

As partes interessadas do projeto exigem formalidade significativa em relação aos
requisitos (evite essa armadilha, partes interessadas muitas vezes não conhecem toda a
solução e querem garantias impossíveis, pedir por detalhamento é um tipo de
transferência de responsabilidade. Num projeto ágil, os requisitos e a própria arquitetura
vão se revelando aos poucos);

Os desenvolvedores não entendem os requisitos (convide os desenvolvedores a
passarem um tempinho na operação, de preferência fazendo o papel do usuário, uma
semana é o suficiente para eles entenderem tudo).

Diagrama de Classes

Vamos recordar os diagramas de classes?! Bem, eles mostram as classes do sistema, seus inter-
relacionamentos, incluindo herança, agregação e associação e as operações e atributos das classes.
Eles são usados para uma ampla variedade de propósitos, incluindo modelagem conceitual, de
domínio e modelagem de projeto detalhado.