Explorando a Documentação de Requisitos em Projetos Ágeis de Software
Conhecendo as Histórias de Usuário
A documentação de requisitos é uma parte fundamental do processo de desenvolvimento de software. Ela descreve as necessidades, funcionalidades e restrições do sistema que está sendo desenvolvido. No Scrum, a abordagem para documentar requisitos é um pouco diferente em comparação com metodologias tradicionais de desenvolvimento de software. Em vez de criar documentos extensivos e detalhados no início do projeto, o Scrum enfatiza a comunicação direta e colaborativa entre os membros da equipe ao longo do ciclo de desenvolvimento.
Apesar de não existir uma documentação tradicional, existem algumas estratégias para documentar requisitos com clareza e simplicidade.
Conduzimos uma pesquisa com profissionais do mercado de tecnologia para identificar quais são os artefatos mais gerados ao trabalhar com requisitos no contexto ágil. De acordo com os resultados, quase 90% dos participantes utiliza as histórias de usuário para documentar requisitos ágeis.
Artefatos gerados ao documentar requisitos ágeis
62 respostas
No Data Found
O que são histórias de usuário?
Uma história de usuário descreve uma funcionalidade ou um requisito do sistema de uma maneira simples e concisa, geralmente na perspectiva do usuário final. Essa técnica enfatiza a comunicação direta entre os membros da equipe de desenvolvimento e os stakeholders do projeto.
Uma história de usuário segue uma estrutura simples, composta por três elementos principais:
- Quem: Representa o papel do usuário ou cliente que se beneficiará da funcionalidade descrita na história.
- O que: Descreve a funcionalidade desejada ou o objetivo a ser alcançado pelo usuário.
- Por que: Explica o motivo pelo qual o usuário precisa dessa funcionalidade e qual é o valor ou benefício que ele espera obter dela.
As histórias do usuário em geral são escritas de forma simples e resumida, podendo seguir o seguinte modelo:
“Como [persona], eu [quero], [para que].”
Esta estrutura não é obrigatória, mas é útil para auxiliar a escrever a definição de “pronto”, ou seja, definir os critérios de aceite. Quando essa persona pode obter seu valor desejado, então a história está completa e aquela tarefa/história pode ser considerada como aceita.
As histórias de usuário são escritas em linguagem natural e são adaptadas de acordo com a necessidade das partes envolvidas, para o melhor entendimento e otimização do processo, na verdade as equipes podem e devem definir a sua própria estrutura.
Mas que tal um exemplo?
-
Como
um analista de requisitos,
-
Eu quero
adquirir conhecimento sobre as habilidades necessárias para praticar a engenharia de requisitos ágeis,
-
Para
otimizar o processo de captura e documentação de requisitos, promovendo mais colaboração com a equipe e garantindo uma contínua entrega de valor ao cliente.
E agora quais seriam os critérios de aceitação para essa história de usuário?
- Deve ser possível acessar conteúdos educacionais que eduquem sobre o conhecimento necessário para a prática da engenharia de requisitos no contexto ágil através de um website.
- Os recursos educacionais devem ser organizados de forma clara e intuitiva, permitindo que os visitantes naveguem facilmente pelo conteúdo relevante.
- Os recursos educacionais devem ser facilmente compreensíveis e acessíveis para que os analistas de requisitos possam adquirir conhecimento de forma eficaz.
Que tal mais alguns exemplos de histórias de usuário dentro de um projeto?
Imagine que uma certa loja online procurou sua equipe para uma melhoria em seu site.
Durante as reuniões de levantamento de requisitos você descobre que eles querem as seguintes mudanças:
Login com Conta Google: Facilita o acesso ao site, eliminando a necessidade de lembrar senhas adicionais e garantindo segurança através da autenticação do Google.
Motivação: facilidade de uso.Ajustar Funcionalidade de Recuperação de Senha: Ajustar alguns parâmetros da funcionalidade de acordo com boas práticas do mercado, para dar maior segurança aos clientes.
Motivação: mitigar falhas de segurança.Criar Funcionalidade de Abrir uma Reclamação no Site: Oferece aos clientes a possibilidade de registrar preocupações de forma transparente, demonstrando o comprometimento da empresa com a resolução ágil de problemas.
Motivação: alguns clientes reclamaram que é muito difícil abrir reclamações pelo telefone.Criar Lista de Desejos: Permite que os usuários organizem e acompanhem produtos desejados, facilitando e incentivando a compra.
Motivação: funcionalidade desejável.
Você poderia colocar todos esses pedidos dentro de uma só história de usuário? Provavelmente sim, mas não é o certo.
O certo é dividir o trabalho em partes menores, para que cada funcionalidade tenha seus próprios critérios de aceite e que o trabalho consiga ser priorizado de acordo com as necessidades do cliente, de forma que cada história de usuário possa ser alocada e entregue dentro de um dos ciclos do Scrum.
No exemplo acima, considere que os pedidos possuem a seguinte prioridade:
- Ajustar funcionalidade de recuperação de senha: Possui o maior nível de prioridade pois resolve uma falha de segurança;
- Abertura de Reclamações Diretamente no Site: Possui esse nível de prioridade pois vai resolver uma falha no processo de atendimento;
- Login com Conta Google: Possui esse nível de prioridade pois é uma melhoria nos parâmetros de login, para acompanhar os padrões de ferramentas similares no mercado;
- Lista de Desejos Personalizada: Possui esse nível de prioridade pois é uma funcionalidade considerada desejável pelo cliente, que pode ser usada como estratégia para aumentar o número de vendas de produtos.
É claro que as histórias de usuário podem variar de acordo com definições técnicas específicas de cada empresa e com os recursos disponíveis, porém abaixo temos um exemplo de como elas poderiam ficar para esse projeto.
Dê uma olhada!
Como um cliente da loja online, eu quero poder recuperar minha senha de acesso a conta de forma segura e rápida, para caso eu esqueça minha senha um dia tenha como recuperar acesso facilmente.
Critérios de Aceitação:
- O link de redefinição de senha deve expirar após 1 hora ou imediatamente após o uso;
- O usuário deve escolher uma nova senha forte, seguindo os seguintes parâmetros:
- A senha deve ter no mínimo 8 caracteres;
- A senha deve conter pelo menos 1 caractere especial (como !, @, #, $, %, etc.);
- A senha deve conter pelo menos 1 número;
- A senha deve conter pelo menos 1 letra maiúscula.
- A senha deve ser armazenada de forma segura e criptografada no banco de dados;
- Após redefinir a senha com sucesso, o usuário deve receber uma notificação por e-mail informando a ação, juntamente com os logs de data/hora.
Como um cliente insatisfeito com um produto ou serviço, eu quero poder abrir uma reclamação diretamente no site da loja, para que minha preocupação seja registrada de forma mais simples e rápida.
Critérios de Aceitação:
- Implementar um formulário de reclamação acessível através do site, que possua os seguintes campos:
- Nome do cliente -> Campo de texto obrigatório;
- E-mail do cliente -> Campo de e-mail obrigatório;
- Tipo de reclamação -> Caixa de seleção obrigatória com as opções “Pedido errado”, “Pedido atrasado”, “Problemas no pagamento”, “Outros”;
- Comentário -> Campo de texto longo obrigatório.
- O formulário deve ser acessível em todo o site, através de um link no rodapé que redirecione o cliente para a página de reclamação;
- Registrar as reclamações no sistema interno da empresa para acompanhamento e resolução;
- Notificar o cliente por e-mail sobre o recebimento da reclamação e fornecer um número de referência para acompanhamento.
Como um usuário de uma plataforma online, eu quero poder fazer login usando minha conta do Google para acessar os recursos do sistema de forma centralizada.
Critérios de Aceitação:
- Na tela de login do site, deve haver uma opção para fazer login usando uma conta do Google.
- Ao selecionar a opção de login com conta do Google, o usuário deve ser redirecionado para a página de autenticação do Google para inserir suas credenciais.
- Se o e-mail da conta do Google já estiver cadastrado no sistema, o sistema deve vinculá-lo a conta existente com o perfil do usuário.
Se o e-mail associado à conta do Google não estiver cadastrado no sistema, uma nova conta deve ser criada automaticamente usando as informações fornecidas pelo Google.
Como um cliente interessado em vários produtos, eu quero poder criar e gerenciar uma lista de desejos, para que eu possa salvar itens para comprar mais tarde ou compartilhá-los com outras pessoas.
Critérios de Aceitação:
- O cliente deve ser capaz de adicionar ou remover um item da sua lista de desejo clicando em um ícone na página de detalhamento do item. Essa ação requere login no sistema;
- O cliente deve ser capaz de acessar sua lista de desejos a partir de qualquer página do site, com um link no cabeçalho do site;
- Ao acessar a lista de desejos, o cliente visualizará os itens na ordem cronológica que foram adicionados. Porém, a lista deverá contar com opções de ordenação dos itens por:
- Preço crescente;
- Preço decrescente;
- Ordem alfabética;
- O sistema deverá notificar os clientes por e-mail sobre alterações de preço e disponibilidade dos itens da lista de desejos,. No caso dos preços, o sistema deve notificar quando o item tiver um valor menor do que quando foi adicionado a lista de desejos. E, no caso da disponibilidade, o sistema deve notificar quando o estoque do item é inferior a 10 unidades.