Ferramenta 5W2H para levantameto de requisitos e elaboração de User Stories

Veja nesse artigo como a adaptação da ferramenta 5W2H pode auxiliar no levantamento de requisitos para a elaboração de User Stories.

Ter os requisitos funcionais bem definidos e entendidos pelo time faz toda a diferença no desenvolvimento de um produto de software. Entretanto, isso nem sempre é algo fácil de ser feito. Aqui será demonstrada uma técnica para o entendimento de requisitos e assim permitir a elaboração de user stories utilizando a ferramenta 5w2h.

INTRODUÇÃO

Em um meio ágil e competitivo, como é o ambiente corporativo, um maior entendimento do que precisa ser feito contribui muito nas atividades que serão desenvolvidas por colaboradores de setores ou áreas diferentes. Quando se desenvolve um produto, a sua concepção deve conter o mínimo de erros, pois isto gera custos, tanto para o cliente quanto para a empresa.

No desenvolvimento de software com boas práticas ágeis o foco é na entrega de valor ao cliente. Sendo assim, necessita-se que as definições de requisitos sejam realizadas de forma eficaz, para que as necessidades do cliente sejam atendidas. Uma prática bastante difundida é o uso de User Stories para escrever os requisitos, pois é uma forma resumida para descrever as funcionalidades que trarão valor ao produto. Para auxiliar no entendimento dos requisitos e na criação das suas respectivas user stories, pode ser utilizada a técnica 5W2H.

E DE ONDE VEM?

A user story deriva da metodologia ágil e foca mais na comunicação verbal do que na documentação. Esta técnica traz uma comunicação clara entre o time de desenvolvimento e o Product Owner (cliente).

É composta por 3 aspectos: descrição usada para planejamento, discussão para concretizar detalhes e critérios de aceitação, que indicam quando a história está pronta. As histórias são independentes, negociáveis, necessitam de valor, estimáveis e pequenas.

Exemplo:

Como hóspede, quero cancelar minha reserva.

FERRAMENTA 5W2H

O 5w2h é considerado uma ferramenta de planejamento, que é muito utilizada em Administração de Empresas. É um checklist contendo determinadas atividades que os colaboradores da organização precisam desenvolver com o máximo de clareza. Tem um destaque relevante na solução dos problemas, pois elimina por completo qualquer dúvida que possa surgir sobre um processo ou atividade.

O nome desta ferramenta foi definido por juntar as primeiras letras dos nomes (em inglês) das diretrizes utilizadas neste processo. Abaixo você pode ver cada uma delas e o que elas representam:

ADAPTAÇÃO DO 5W2H PARA O CONTEXTO DE DESENVOLVIMENTO ÁGIL

O atual processo de desenvolvimento da NeoGrid está baseado em boas práticas de métodos ágeis utilizando user stories como forma para descrever os requisitos funcionais. Entretanto, quando começamos a utilizar as user stories, em algumas vezes nos deparávamos com a falta de aprofundamento na descrição. Mesmo tendo um padrão de escrita, nem sempre os dados descritos auxiliavam a concepção correta do requisito. Então, foi preciso inovar!

Adaptamos o 5W2H para o nosso contexto para compor as user stories, onde foi possível conceber os requisitos de forma eficaz e criar critérios de aceitação, que permitem identificar os cenários dos testes a serem realizados. A utilização não é complexa. Na concepção do requisito, basta aplicar as perguntas e coletar as informações. De posse dos dados já é possível compor a user story.

EXEMPLO PRÁTICO

Contexto do Projeto

# O Cliente:

# Descrição do Problema:

Um dos problemas da rede está no controle de produção...

# Objetivos de Negócio:

# Objetivo Específico do Sistema:

A TÉCNICA 5W2H ADAPTADA...

  1. Qual é o objetivo do requisito?
  2. Por que o requisito deve ser implementado?
  3. Onde poderá ser visualizado o requisito?
  4. Quais são os pré-requisitos para este requisito?
  5. Qual é o perfil de acesso para este requisito?
  6. Quais são os critérios de aceitação para este requisito?
  7. Quais serão as mensagens de validação para este requisito?

APLICANDO A TÉCNICA NO CONTEXTO DO PROJETO

1. Qual é o objetivo do requisito?
R: Implementar um ambiente de controle de produção de medicamentos manipulados.

2. Por que o requisito deve ser implementado?
R: Para permitir a identificação precisa da necessidade de matéria-prima e controlar o seu uso eliminando o alto grau de desperdício.

3. Onde poderá ser visualizado o requisito?
R: Em um item de menu específico, conforme layout de tela Homes.

4. Quais são os pré-requisitos para este requisito?
4.1. Ter sido identificado o fluxo de produção.
4.2. Ter acesso às fórmulas dos medicamentos.

5. Qual é o perfil de acesso para este requisito?
R: Responsável pelo controle da produção, por exemplo: técnico em manipulação.

6. Quais são os critérios de aceitação para este requisito?
6.1. O estoque de segurança para matérias-primas críticas deverá ser de 5 dias de produção e para matérias prima simples deverá ser de 3 dias de produção.
6.2. O sistema deverá sinalizar a necessidade de compra de matéria-prima quando tiver estoque para produção para, pelo menos, 7 dias úteis, sem considerar o prazo do estoque de segurança.
6.3. O sistema não deverá disparar um aviso de compra de matéria-prima crítica se não houver produção de medicamentos que utilizem este tipo de insumo nos últimos 30 dias.

7. Quais serão as mensagens de validação para este requisito?
Para o critério de aceitação: O sistema deverá sinalizar a necessidade de compra de matéria-prima quando tiver estoque para produção para, pelo menos, 7 dias úteis, sem considerar o prazo do estoque de segurança.

A mensagem de validação deverá ser:
"Há estoque de matéria-prima X para produção de medicamento durante 7 dias úteis. Deseja efetuar novo pedido de compra? Sim/Não"

CRIANDO UMA USER STORY...

"Como técnico de manipulação, necessito que seja implementado um ambiente de controle de produção de medicamentos manipulados, pois assim poderei identificar de forma precisa a necessidade de matéria-prima e controlar o seu uso."

Para aceitar:

  1. O estoque de segurança para matérias-primas críticas deverá ser de 5 dias de produção e para matérias prima simples deverá ser de 3 dias de produção.
  2. O sistema deverá sinalizar a necessidade de compra de matéria-prima quando tiver estoque para produção para, pelo menos, 7 dias úteis, sem considerar o prazo do estoque de segurança.
  3. Conforme item anterior, quando houver a necessidade de compra, o sistema deverá exibir a seguinte mensagem:
    "Há estoque de matéria-prima X para produção de medicamento durante 7 dias úteis. Deseja efetuar novo pedido de compra? Sim/Não"
  4. O sistema não deverá disparar um aviso de compra de matéria-prima crítica se não houver produção de medicamentos que utilizem este tipo de insumo nos últimos 30 dias.
  5. O usuário terá acesso ao menu Produção > Controle da Produção.

Para considerar:

CONCLUSÃO

Ao adotar a ferramenta para compor as user stories, obtivemos resultados significativos no entendimento dos requisitos funcionais. Ganhamos mais habilidade crítica, pois conseguimos captar mais no detalhe o que o Product Owner queria nos dizer. Também conseguimos melhorar a cobertura de testes, uma vez que foi possível ter uma maior abrangência dos critérios de aceitação a partir das perguntas e assim poder sinalizar quando está efetivamente “pronta”. Nossas user stories estão com tamanho mais adequado, onde já se consegue identificar um “épico” e assim fracionar em requisitos menores. Para os requisitos não funcionais também é utilizado do mesmo procedimento, o que possibilitou uma melhoria na qualidade da escrita e, consequentemente, na implementação destes requisitos. Como estamos em um ambiente de melhoria contínua, identificamos a necessidade de ampliar a utilização da ferramenta para demais as áreas da empresa que trabalham com a ferramenta de SGR.

Autoras: Dieine da Silva e Patrícia Araújo Gonçalves.

Artigos relacionados