MoSCoW
Histórico de versão
| Data | Versão | Descrição | Autor(es) |
|---|---|---|---|
| 27/09/2020 | 0.1 | Criação do documento | Lucas Gomes |
| 27/09/2020 | 0.2 | Adição da prioridade dos primeiros requisitos elicitados pelo Braimstorming e Introspecção | Lucas Gomes, Guilherme Leal |
| 28/09/2020 | 0.3 | Editou a introdução | Lucas Gomes |
| 28/09/2020 | 0.4 | Revisão de prioridades e adição de RNF | Guilherme Leal |
| 26/10/2020 | 0.5 | Adição de rastro RNF's | Guilherme Leal |
1. Introdução
MoSCoW é uma técnica de priorização com o objetivo de definir a importância dos requisitos elicitados de acordo com seu impacto na aplicação e no valor de mercado. Assim, sabendo a prioridade de cada requisito, é possível escolher a ordem em que serão implementados na aplicação. MoSCoW é um acrônimo para as prioridades possíveis nessa técnica e é dada pela seguinte ordem de prioridade:
- M - must have
- S - should have
- C - could have
- W - won't have
2. Priorização
2.1 Requisitos Funcionais
| Requisito | Descrição | Prioridade |
|---|---|---|
| RF01 | O usuário deve ser capaz de se cadastrar e realizar o login | Must |
| RF02 | A aplicação poderia ter um tutorial sobre a jogabilidade | Could |
| RF03 | A aplicação deve ter diferentes modos de jogo | Should |
| RF04 | O usuário deve ser capaz de cadastrar novas questões | Must |
| RF05 | A aplicação deve possuir diferentes categorias de questões | Should |
| RF06 | A aplicação poderia ter feedback com respostas comentadas | Won't |
| RF07 | A aplicação deve dar a possibilidade de integração com apps de Mídia Social | Should |
| RF08 | O jogo deverá ter dois modos: treino e ranqueado. | Should |
| RF09 | O usuário poderá jogar o modo treino sem cadastro. | Could |
| RF10 | O modo treino deverá ter a opção de se jogar sozinho até errar alguma questão ou um usuário contra outro. | Should |
| RF11 | O modo ranqueado deverá ter a opção de quem resolve mais questões. | Should |
| RF12 | O modo ranqueado dverá ter a opção de quem resolve mais questões dentro de uma quantidade limite de questões. | Should |
| RF13 | Cada questão deverá ter um tempo limite para a sua resolução. | Must |
| RF14 | No modo ranqueado deverá ser um usuário cadastrado contra outro. | Must |
| RF15 | No modo ranqueado a vitória deverá fazer com que o usuário ganhe pontos e a derrota fará com que perca-os. | Must |
| RF16 | O jogo deverá ter um ranking do modo ranqueado. | Should |
| RF17 | O usuário cadastrado deverá ter a possibilidade de jogar no modo treino. | Must |
| RF18 | O usuário cadastrado deverá ter a possibilidade de desafiar outros usuário cadastrados. | Should |
| RF19 | As questões criadas deverão ser disponibilizadas após avaliação de algum membro da staff. | Must |
| RF20 | O usuário deverá ter a possibilidade de reportar questões. | Must |
| RF21 | O usuário cadastrado deverá ter a possibilidade de visualizar o ranking. | Should |
2.2 Requisitos Não Funcionais
| Requisito | Descrição | Prioridade | Rastro |
|---|---|---|---|
| RNF00 | O aplicativo deverá ter baixo consumo de dados | Should | |
| RNF01 | O aplicativo deverá ter alta adesão de estudantes | Should | |
| RNF02 | O aplicativo deverá ter Praticidade: o sistema deve ter uma abordagem prática e intuitiva | Must | |
| RNF03 | O aplicativo deverá ter boa reputação e aceitação de estudantes e instituições de ensino | Must | |
| RNFSB04 | O app deverá auxiliar os estudos | Should | |
| RNFSB05 | O usuário deve ser capaz de utilizar o app sem acompanhamento | Could | |
| RNFSB06 | O app deve animar/estimular o usuário a estudar | Should | |
| RNF07 | O app deve ser acessível por dispositivos móveis | Must |
Rastreabilidade
Os requisitos Priorizados estão disponíveis em: Requisitos Elicitados
3. Referências
CORDEIRO, A.; FREITAS, A. L. Priorização de requisitos e avaliação da qualidade de software segundo a percepção dos usuários. Ciência da Informação, 2012.