| Data | Versão | Descrição | Autor(es) |
|---|---|---|---|
| 19.09.2020 | 0.1 | Criação do documento | Lucas Lopes |
| 27.09.2020 | 0.2 | Revisão | Isabella Carneiro |
| 05.10.2020 | 0.3 | Adição de itens | Isabella Carneiro |
| 24.11.2020 | 0.4 | Revisão do documento | Isabella Carneiro |
MoSCoW
Metodologia
As quatro letras maiúsculas no esquema de priorização MoSCoW representam quatro classificações prioritárias possíveis para os requisitos em um conjunto (IIBA 2009):
Must: A exigência deve ser satisfeita para que a solução seja considerada um sucesso.
Should: O requisito é importante para o produto final, mas não é vital. Se deixado de lado, a aplicação ainda funciona. Mas, quando incluído, acrescenta um valor significativo.
Could: não é necessário para o funcionamento do projeto. Implementá-lo somente se o tempo e os recursos permitirem.
Won’t Isto indica um requisito que não será implementado neste momento, mas que poderia ser incluído em um lançamento futuro.
(Wiegers e Beatty, 2013)
Participantes
- Lucas
- Isabella
Nota Importante
Este será o método de priorização que o grupo utilizará para basear os artefatos das fases de modelagem, análise e pós-rastreabilidade.
Resultado
| Número | Requisito | MoSCoW |
|---|---|---|
| 1 | O usuário poderá acessar o aplicativo sem ter login | Must |
| 2 | O usuário pode ser capaz de ver os campeonatos cadastrados | Must |
| 3 | O usuário terá uma função de favoritar um campeonato | Should |
| 4 | O usuário poderá visualizar tabela de pontuação e rodadas ao clicar em campeonato | Should |
| 5 | O usuário, ao selecionar um campeonato, poderá escolher classificação, ranking e notícias dentro daquele campeonato | Could |
| 6 | O usuário, ao selecionar um campeonato, poderá escolher classificação, ranking e notícias dentro daquele campeonato | Must |
| 7 | O usuário poderá selecionar a visualização de classificações e eliminatórias dentro de um campeonato | Could |
| 8 | Deverá ser disponilbilizado um link para acesso ao site | Could |
| 9 | O usuário poderá buscar e filtrar campeonatos | Could |
| 10 | O login só será permitido àqueles usuários que receberam o acesso/cadastro via email | Must |
| 11 | Só será disponibilizado login e recuperação de senha | Should |
| 12 | O envio de convites para cadastrados só será permitido a perfis de treinadores ou administradores | Could |
| 13 | O usuário poderá visualizar o placar de um jogo em tempo real | Won’t |
| 14 | O usuário poderá pesquisar um jogador e ver suas informações | Could |
| 15 | O usuário cadastrado poderá criar campeonatos | Should |
| 16 | O usuário poderá fazer sugestões via comunicação | Won’t |
| 17 | O cadastro terá informações básicas como nome, email, contato e senha | Should |
| 18 | O login será por email e senha | Must |
| 19 | A recuperação de senha poderá ser enviada por email ou mensagem | Could |
| 20 | O usuário poderá compartilhar por link informações de um time, campeonato ou jogador | Won’t |
| 21 | O usuário administrador/treinador poderá alterar o status de seu link como offline/ online | Won’t |
| 22 | O usuário administrador/treinador poderá restringir o compartilhamento de suas informações | Could |
| 23 | o usuário administrador/treinador poderá preencher informações de um campeonato quando responsável ou delegado | Should |
| 24 | O usuário administrador de um campeonato poderá criar rodadas e alterar chaves | Must |
| 25 | O usuário administrador de um campeonato poderá editar, excluir times e rodadas | Must |
| 26 | O usuário administrador de um campeonato poderá abrir inscrições para campeonato | Must |
| 27 | O usuário administrador de um campeonato poderá editar/visualizar pagantes em um campeonato | Must |
| 28 | O sistema poderá enviar links de mensagens por media social | Won’t |
| 29 | O usuário administrador de um campeonato pode fazer upload de arquivos | Must |
| 30 | Um usuário logado poderá fazer logout | Should |
| 31 | O usuário elite deve poder adicionar notícias a um campeonato | Must |
| 32 | O usuário elite deve poder adicionar patrocinadores e produtos | Must |
| 33 | O sistema deve ser capaz de gerar súmula digital | Should |
| 34 | O usuário premium /ELITE deve poder ter acesso a súmula digital | Should |
| 35 | O usuário poderá filtrar jogadores em um ranking | Could |
| 36 | O perfil de JOGADOR deverá armazenar os times que ele participa | Must |
| 37 | O perfil de JOGADOR deverá armazenar e exibir estatísticas e não exibir informações pessoais | Must |
| 38 | O sistema de tabelas deve ser auto gerenciável a cada rodada | Should |
| 39 | O atualização de tabelas, ranking, resultados e estatísticas deverá ser feito de forma automática da cada fim de rodada | Should |
| 40 | O usuário deve ser capaz de ver os anúncios dos parceiros e interagir com os mesmos | Must |
| 41 | O usuário deve ser capaz de visualizar a sua agenda de jogos | Won’t |
| 42 | O sistema pode ter otimização para ter SEO e para identificação por mecanismo de busca dentro de lojas de App | Must |
| 43 | O App deverá estar disponível para IOS e ANDROID | Should |
| 44 | O App deverá ser compatível com normas de acessibilidade e compatilibidade, com solução assistência/ajuda para debilidades | Could |
| 45 | O App CLIENT deverá requisitar dados ao final de cada partida ao server | Could |
| 46 | O App CLIENT deverá requisitar dados ao final de cada partida ao server | Should |
| 47 | O App deverá ser construído em um Framework Multiplataforma | Could |
| 48 | O usuário poderá navegar pelos menus | Could |
| 49 | O usuário pode verificar o extrato do jogo, assim como sua escalação. | Should |
| 50 | O usuário pode checar quem são os jogadores de um time, assim como os jogos que ele jogou e suas estatísticas. | Should |
Referências
- SERRANO, Maurício; SERRANO, Milene; Requisitos - Aula 07;