Exibir código-fonte para Necessidades e requisitos

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.

== Estórias de usuários ==

A estó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 estó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 estória, na planilha, deve ser contada em primeira pessoa.

Segue um exemplo de uma estó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”.''

[[Arquivo:UserStory_HQ_Dilbert.jpg | 600px ]]


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


[[Arquivo:AtorAcaoFuncionalidade.jpg | 600px ]]


*'''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 é 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. [http://www.devmedia.com.br/introducao-a-requisitos-de-software/29580]


Na MSTECH, de forma geral, utilizaremos três 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. [http://engenhariadesoftware.blogspot.com.br/2007/05/requisitos-de-software.html]
*'''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. [http://www.devmedia.com.br/introducao-a-requisitos-de-software/29580]
*'''Integração:''' Esses requisitos são relacionados à integrações entre sistemas, internos ou externos.


'''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 estó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:

*Estó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 estórias, requisitos e cenários ==

[[Arquivo:US_Requisitos_Cenarios.jpg | 700px]]

== Outras referências ==
'''CULTURA ÁGIL.''' Estória de usuário. Você saberia contar? [http://www.culturaagil.com.br/estoria-de-usuario-voce-saberia-contar/]