Frank Coelho de Alcantara -2020
Transformar requisitos e requerimentos em uma ferramenta de suporte ao desenvolvimento do sistema.
Os casos de uso são ferramentas para as análises de negócio e sistemas.
O jogador joga os dados e se sair o número 7 ele ganha o jogo.
Extensão: diz respeito ao uso, ou não, de um caso de uso, por outros casos de uso. (as vezes!)
Inclusão: diz respeito ao uso de um caso de uso, por outros casos de uso. (sempre!)
Um caso de uso, chamado de concreto, herda características de um casos de uso chamado de abstrato.
Podem ocorrer relações múltiplas entre atores e casos de uso e entre casos de uso.
Na prática: em um ambiente de práticas ágeis, partimos de um caso de uso do tipo sumário e detalhamos todos os seus casos de uso, para encontrar os que são de sistema, internos e contextuais. Depois analisamos os casos de uso do tipo abuso.
Efetivo significa permanente, que tem caráter definitivo.
Análise do domínio do problema, definindo o objetivo geral do sistema, as características específicas do domínio do problema, e os principais stakeholders.
Precisa ser sucinto mas deve conter a ideia principal do sistema. Geralmente são as primeiras frases que o stakeholder usa para definir seu problema.
A empresa FraldasVerdes, uma fabricante de fraldas ecológicas precisa que todas as suas vendas sejam controladas pelo sistema FraldasVerdes Vende, um sistema de vendas ao consumidor final, online, móvel e acessível. Este sistema irá permitir que o usuário final da fralda ecológica entenda o processo de fabricação e possa fazer seus pedidos sem a necessidade de sair de casa.
Você vai responder a pergunta quem quer o quê? O ator primário de cada caso de uso deve ter sido explicitado na análise de requisitos.
Além do ator primário deste caso de uso, você precisa identificar o trigger, a ação que ele executa. E o valor que ele irá obter do sistema. No caso das FraldasVerdes, um dos atores primários é o cliente. Qual o trigger? Qual o valor?
Precisaremos documentar o caminho para o sucesso deste caso de uso.
O sucesso ocorre quando a interação produz o valor desejado.
A documentação pode ser um passo-a-passo, mas precisa ser validada com stakeholders e desenvolvedores.
Hora de verificar os caminhos alternativos para o sucesso. Os caminhos alternativos para o fracasso.
Documentar as extensões e inclusões. Talvez repetindo todo o processo para cada novo caso de uso.
Extensão, inclusão e exceção. Todos estes casos estão na responsabilidade do analista.
Hora de detalhar a história que estamos contando destacando os casos de extensão e inclusão.
Você precisa responder a pergunta o que mais precisa acontecer para que isso dê certo?
É a hora de ver os casos de uso, com funcionalidades que você pode criar, ou utilizar. Também é a hora de pensar em falhas. Todo mundo falha, inclusive os sistemas.
Em práticas de desenvolvimento ágil, substituímos todo o digrama de casos de uso e análise de requisitos por Histórias de Usuário.
Histórias de Usuário são uma descrição sucinta, porém efetiva, de uma interação de um stakeholder com o sistema.
A análise de requisitos primeiro, e o diagramas de casos de uso depois, foram criados para permitir o entendimento e congelar os requisitos durante o desenvolvimento da solução.
As Histórias de Usuário fazem exatamente isso se existir colaboração entre equipe de desenvolvimento e stakeholders e se o tempo de desenvolvimento da funcionalidade for curto.
Em práticas de desenvolvimento ágil, substituímos todo o digrama de casos de uso e análise de requisitos por Histórias de Usuário.
Histórias de Usuário são uma descrição sucinta, porém efetiva, de uma interação de um stakeholder com o sistema.
Eu, como um <insira o ator>, quero <insira o objetivo> já que <insira a razão>.
Esta é a frase típica. Comece com ela, mas não fique restrito a ela. As histórias de usuário precisam ser simples, diretas, claras e, principalmente, completas.
Desconfie de histórias de usuários muito curtas. e muito longas.
A história de usuário deve conter uma descrição da interação com o sistema que permita o entendimento das características desta interação, dos recursos necessários e do tempo que será utilizado para a sua construção.
Em práticas ágeis, criamos histórias de usuários em fichas ou post-its.
Isso permite que, por exemplo, seja possível escrever as exceções no verso da ficha. Ordenar as fichas por prioridade e criar o backlog. Alterar as histórias a medida que o sistema fica pronto.
Lembre-se: em práticas ágeis, tudo pode, e deve, ser negociado.
Independentes: cada história deve ser independente das outras histórias e da ordem em que serão construídas. As histórias dependentes de outras histórias, ou da ordem de construção adicionam níveis de complexidade desnecessários ao desenvolvimento de software.
Negociáveis: as histórias não são contratos nem detalhamento de requisitos. Tanto a equipe de desenvolvimento quanto os stakeholders devem se envolver na definição da história. Ela não deve ser muito detalhada justamente para não criar a sensação de que todos os detalhes são conhecidos.
Valorosas: as histórias devem agregar valor ao sistema que está sendo desenvolvido. Este valor deve ser percebido pela equipe de desenvolvimento e pelos stakeholders. Se a história não tiver um valor claro, será difícil determinar sua prioridade no backlog.
Estimáveis: todas as histórias devem ser estimadas em termos de tempo e recursos necessários para a sua conclusão. Esta estimação precisa ser justa. Uma história muito grande é difícil de estimar, difícil de priorizar e irá causar problemas no desenvolvimento por quebra de expectativas.
Tamanho apropriado: eventualmente as histórias precisarão ser divididas, ou reduzidas, para caber no tempo de desenvolvimento de uma determinada versão do software. Este é o momento em que serão negociados os requerimentos de cada história, a ordem de sua execução e a prioridade.
Testáveis: todas as histórias devem permitir que tanto os desenvolvedores quanto os stakeholders sejam capazes de testar o resultado do processo de desenvolvimento e determinar se o valor esperado foi atingido.
Você pode baixar o material de apoio clicando aqui