Mudanças entre as edições de "Necessidades e requisitos"

Edição atual tal como às 12h12min de 9 de fevereiro de 2017

A partir do mês de setembro/2016, o levantamento de requisitos será realizado através do método de estórias de usuário, baseadas nas necessidades do cliente. Veja a seguir alguns conceitos importantes para esse tipo de levantamento.

User Stories

A história de usuário, também chamada de “User story”, é uma descrição simples das necessidades do cliente para o produto. Ela precisa ser escrita a partir do ponto de vista de quem precisa da nova necessidade, como por exemplo um perfil de usuário, o cliente do sistema ou um representante de negócios do cliente.

Outro ponto importante é que a história deve explicar com clareza para quem, o que e por que ela está sendo criada. Na planilha de necessidades, esses campos são representados pelas colunas “Como um”, “Eu quero”, “Para”, consecutivamente, já que a história, na planilha, deve ser contada em primeira pessoa.

Segue um exemplo de uma história contada nestes parâmetros:

“Como um aluno eu quero curtir as notícias do mural do meu professor, para demonstrar apoio ao conteúdo publicado”.

Desta forma, teremos sempre em uma user story três elementos principais:

• Ator: De forma simplista é o usuário, o interessado naquela funcionalidade. Mas é recomendado descrever de forma específica quem é o ator para ser mais fácil identificar o contexto da história dentro do sistema.

• Ação: É o que o ator quer fazer. Utilizando aquela ação ele espera alcançar seu objetivo dentro do sistema.

• Funcionalidade: É o que o ator espera que aconteça ao realizar a ação. Ou seja, é o resultado de executar a ação segundo a ótica do ator. Também pode ser visto como justificativa.

Requisitos

Antigamente dizia-se que requisitos eram sinônimos de funções, ou seja, tudo que o software deveria fazer funcionalmente. No entanto, atualmente assumiu-se que requisitos de software são muito mais do que apenas funções. Requisitos são, além de funções, objetivos, propriedades, restrições que o sistema deve possuir para satisfazer contratos, padrões ou especificações de acordo com o(s) usuário(s). De forma mais geral um requisito é uma condição necessária para satisfazer um objetivo. [1]

Na MSTECH, de forma geral, utilizaremos quatro tipos de classificação de requisitos, são eles:

• Funcionais (RF): Os requisitos funcionais são a descrição das diversas funções que clientes e usuários querem ou precisam que o software ofereça. Eles definem a funcionalidade desejada do software. [2]
• Não funcionais (RNF): Já os requisitos não funcionais, referem-se aos critérios que qualificam os requisitos funcionais. Esses critérios podem ser de qualidade para o software, ou seja, os requisitos de performance, usabilidade, confiabilidade, robustez, etc. Ou então, os critérios podem ser quanto a qualidade para o processo de software, ou seja, requisitos de entrega, implementação, etc. [3]
• Integração: Esses requisitos são relacionados à integrações entre sistemas, internos ou externos.
• Bug: Requisitos classificados como bugs são especificações de defeitos encontrados, para que então sejam corrigidos.

Importante: No campo "Critérios de aceite" devem ser descritos os resultados esperados para que o requisito seja aceito ao término da sprint.

Cenários

Os cenários têm por objetivo descrever comportamentos de um determinado requisito, sendo que um único requisito pode ter n cenários.

Dessa forma, os requisitos das nossas histórias de usuário ficam mais descritivos, possuindo cenários que indicam o seu funcionamento esperado. As palavras chave "Dado que", "Quando" e "Então" nos apoiam na criação de cenários para descrever o seu comportamento.

Veja um exemplo utilizando um requisito já exemplificado:

• História: “Como um aluno eu quero curtir as notícias do mural do meu professor, para demonstrar apoio ao conteúdo publicado”.
  • Requisito: Habilitar opção curtir no mural do professor.
    • Cenário 1: "Dado que o aluno acessa o mural do professor, quando clicar sobre o botão "Curtir", então um ícone ilustrativo deverá aparecer abaixo da notícia e o contador de curtidas deverá ser incrementado".
    • Cenário 2: "Dado que o professor acesse o próprio mural, quando clicar sobre o botão "Curtir", então deverá aparecer a lista de alunos que curtiram a sua notícia".

Conforme demonstrado, o "DADO QUE" é utilizado para indicar o cenário atual, o "QUANDO", para a ação do usuário e o "ENTÃO" para indicar o comportamento esperado.

Relação entre user stories, requisitos e cenários

Estimativas

Para criação das estimativas de requisitos, devem ser utilizadas as informações da aba "CRITÉRIOS". Na aba "BACKLOG", caso algum requisito apresente a necessidade de uso de mais de um critério, as células da planilha podem ser mescladas desde que o ID do requisito permaneça com as células divididas, sendo copiado em todas as linhas que possuem critérios para aquele requisito. No final da planilha, são apresentados os totais por tipo de requisito e os totais por requisito.

Outras referências

CULTURA ÁGIL. Estória de usuário. Você saberia contar? [4]