MoSCoW
Histórico de versão
| Data | Versão | Descrição | Autor(es) |
|---|---|---|---|
| 17.02.2021 | 0.1 | Criação do documento | Geraldo Victor |
| 27.02.2021 | 0.2 | Adição de novos requisitos a partir do documento de Reuniões | Lucas Lopes, Bruna Almeida |
| 03.03.2021 | 0.2 | Revisão do documento | Isabella Carneiro |
| ## Participantes | |||
| - Geraldo Victor | |||
| - Lucas Lopes | |||
| - Bruna Almeida | |||
| - Isabella Carneiro (Revisão) |
Considerações iniciais
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. Os requisitos analisados são os levantados no brainstorming, dessa forma poderemos ter visão do quanto cada requisito deve ser priorizado.
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)
Resultado
| Número | Requisito | MoSCoW |
|---|---|---|
| BS01 | O usuário deve ser capaz de realizar o login | Must |
| BS02 | O usuário deve ser capaz de realizar o cadastro | Must |
| BS03 | O usuário deve ser capaz de alterar e recuperar a senha | Must |
| BS04 | O visitante deve ser capaz de consultar horários e dias disponíveis | Must |
| BS05 | O visitante deve ser capaz de visualizar tabelas de preços | Must |
| BS06 | O visitante deve ser capaz ver a lista de funcionários | Must |
| BS07 | O cliente deve ser capaz avaliar funcionários | Should |
| BS08 | O visitante deve ser capaz de visualisar perfil do funcionário | Should |
| BS09 | O visitante deve ser capaz de visualizar galeria de serviços | Must |
| BS10 | O sistema deve ser capaz de consumir a api externa de fotos para mostrar serviços realizados | Should |
| BS11 | O cliente deve poder receber e enviar notificação de atraso no agendamento | Must |
| BS12 | O cliente pode solicitar um agendamento ou reagendar um horário | Must |
| BS13 | O funcionário deve poder marcar os seus horários de trabalhos disponíveis | Must |
| BS14 | O funcionário deve poder visualizar os agendamentos marcados | Must |
| BS15 | O administrador deve ser capaz de cadastrar serviços | Must |
| BS16 | O administrador deve gerenciar permissões de usuário | Must |
| BS17 | O administrador deve ser capaz de gerenciar os usuários | Must |
| BS18 | O sistema deve ser capaz de gerenciar os serviços de filas de atendimento por funcionário | Must |
| BS19 | O sistema deve ser capaz de realizar um orçamento de uma ordem de serviço | Should |
| BS20 | O sistema deve ser capaz de calcular o tempo de uma ordem de serviço | Should |
| BS21 | O sistema deve ser capaz de organizar serviços simultâneos | Must |
| BS22 | O sistema deve ser capaz de enviar notificação de agendamento de serviços | Must |
| BS23 | O sistema deve ser capaz de disponibilizar uma agenda de horários disponíveis | Must |
| RE01 | Adicionar avaliações por serviço prestado | Could |
| RE02 | Adicionar uma confirmação por pedido de serviços concluidos | Could |
| RE03 | Adicionar curtidas por atendimento de funcionário | Could |
Referências
SERRANO, Maurício; SERRANO, Milene; Requisitos - Aula 07;