Necessidades e requisitos

De MSTECH wiki
Ir para: navegação, pesquisa

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”.

UserStory HQ Dilbert.jpg


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


AtorAcaoFuncionalidade.jpg


  • 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

US Requisitos Cenarios.jpg

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.

Exemplo-req.png

Outras referências

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