MoSCoW

Introdução

  A técnica de priorização MoSCoW é uma ferramenta essencial no gerenciamento de projetos, empregada para ordenar os requisitos do projeto em termos de prioridade. No âmbito deste projeto, adotamos o método de priorização MoSCoW para categorizar nossos requisitos em quatro segmentos cruciais: Must Have (Deve Ter), Should Have (Deveria Ter), Could Have (Poderia Ter) e Won't Have (Não Terá).

Must Have (Deve Ter): Esses requisitos são vitais para o êxito e o propósito central do projeto, sendo inegociáveis. A priorização destes é fundamental para assegurar que a solução satisfaça os requisitos primordiais dos nossos stakeholders.

Should Have (Deveria Ter): Requisitos importantes e desejáveis, embora não tão críticos quanto os "Must Have". A inclusão destes aprimorará a experiência dos usuários e agregará valor ao projeto, sendo considerados para implementação após a conclusão dos requisitos "Must Have".

Could Have (Poderia Ter): Estes requisitos representam funcionalidades com potencial para enriquecer ainda mais a solução, embora não sejam essenciais para seu funcionamento básico. São considerados opções que podem ser exploradas em fases subsequentes do projeto.

Won't Have (Não Terá): Funcionalidades deliberadamente excluídas do escopo do projeto, muitas vezes devido a restrições de tempo, recursos ou estratégia de priorização. É crucial que todos os stakeholders estejam cientes de que esses requisitos não serão implementados na versão inicial da solução.

  A classificação dos requisitos baseou-se em uma análise abrangente das necessidades dos stakeholders, considerações técnicas, viabilidade e alinhamento com os objetivos do projeto. Essa abordagem de priorização nos permite tomar decisões informadas sobre como alocar recursos e garantir que nosso projeto atenda às expectativas e metas estabelecidas.

Objetivo

  O objetivo da técnica de priorização MoSCoW é classificar as prioridades do projeto ou do produto, permitindo que a equipe e as partes interessadas identifiquem e concentrem seus esforços nos requisitos mais críticos e fundamentais. Isso ajuda a garantir que os recursos sejam alocados de forma eficaz e a manter o foco nas áreas que terão o maior impacto no sucesso geral do projeto. Além disso, a técnica MoSCoW pode ajudar a gerenciar expectativas e comunicar de forma eficaz quais funcionalidades ou requisitos são considerados mais importantes em um determinado momento.

Metodologia

   Após aplicarmos as técnicas de elicitação escolhidas pelo grupo e listar todos os requisitos, realizamos uma análise utilizando personas para classificar cada um de acordo com a técnica MoSCoW: Must Have(essenciais), Should Have (importantes), Could Have(opcionais) e Won't Have(exclusões intencionais).

Must Have

   A tabela 1 apresenta os requisitos classificados como Must Have.

Tipo	Requisito	Elicitação
RF	O usuário deve ser capaz de compartilhar sua tela durante as reuniões	BR02
RF	Deve permitir a gravação de chamadas	BR03
RF	Deve permitir que o anfitrião tenha a capacidade de remover um participante específico da reunião	BR07
RNF	Deve oferecer uma interface simples e objetiva, permitindo que o usuário consiga realizar qualquer atividade com menos de 5 cliques	BR17
RF	Os usuários devem poder compartilhar suas telas durante as reuniões	ENT01
RF	Os usuários devem ser capazes de criar uma videoconferência	ENT02
RF	Deve permitir a gravação de chamadas	ENT04
RNF	Deve ter uma interface clara e intuitiva, permitindo que o usuário consiga realizar qualquer atividade com menos de 5 cliques	EN08 e OB18
RF	Deve permitir fazer autenticação através de outros aplicativos, como Google ou Facebook	OB01
RF	Dever permitir convidar participantes através de compartilhamento de link por meio de outros aplicativos	OB02
RF	Deve possuir a opção de mutar o áudio	OB04
RF	Deve permitir a gravação de chamadas	OB05
RF	Deve permitir enviar menssagem de texto durante a videochamada	OB06
RF	Os usuários devem poder compartilhar suas telas durante as chamadas	OB07
RF	Deve permitir configuração de perfil	OB11
RNF	Deve garantir a segurança dos dados confidenciais compartilhados durante as reuniões por vídeoconferência	OB12
RNF	Deve ser um aplicativo que ocupe pouco menos de 100mb de memória	OB17
RF	Deve permitir a configuração de controles de acesso	IN01
RNF	Ser compatível com sistemas operacionais Android e IOS	IN05
RNF	Deve ser de código aberto e gratuito	IN07

Tabela 1: Must Have.
Autor(a):Catlen Cleane e Júlia Vitória

Should Have

   A tabela 2 apresenta os requisitos classificados como Should Have.

Tipo	Requisito	Elicitação
RF	Deve ser possível baixar as gravações das reuniões	BR08
RF	O anfitrião deve ser capaz de controlar a entrada em uma sala por meio de senha	BR11
RF	O sistema deve permitir a transcrição do áudio de chamada	BR05 EN05
RF	Deve permitir que o anfitrião de uma reunião consiga desligar o microfone e a câmera de qualquer participante	BR06
RF	Deve fornecer ao usuário a capacidade de visualizar todas as salas em que ele participou anteriormente	BR10
RF	Os usuários devem poder compartilhar emojis pré definidos durante as chamadas	ENT03 e OB09
RF	Deve permitir a utilização de quadro de anotação durante a chamada	ENT06
RF	Os usuários devem ser capaz de alterar seu fundo durante a chamada de vídeo	ENT07 e BR04
RF	Os usuários possam compartilhar arquivos durante as reuniões	OB08
RF	Deve possuir um calendário com chamadas agendadas	OB13
RF	Deve permitir que o calendário de um usuário seja sincronizado ao de outros	OB14
RF	Deve permitir agendar reuniões com outros usuários atraves do calendário	OB15
RF	Deve possuir uma lista das reuniões que o usuário já participou	OB16
RNF	Deve ter acesso facilitado para instalação, sem levar mais de 30 segundos de pesquisa direta para encontrar a aplicação nas lojas de aplicativos	IN06
RNF	Deve ser estável, tendo no máximo 1 queda de funcionamento por dia	IN12
RNF	Deve oferecer um desempenho responsivo, se adaptando mediante o tamanho da tela	IN13

Tabela 2: Should Have.
Autor(a):Catlen Cleane e Júlia Vitória

Could Have

   A tabela 3 apresenta os requisitos classificados como Could Have.

Tipo	Requisito	Elicitação
RF	Deve oferecer um modo claro ou escuro de interface como parte de suas funcionalidades de acessibilidade	BR16
RNF	Deve possuir um bom contraste entre as cores afim aprimorar a legibilidade	BR18
RNF	Deve ser possível ingressar em uma reunião sem a necessidade de um login	BR12
RF	Deve possuir um mecanismo de busca a partir da data da reunião	BR09
RF	O anfitrião deve ser capaz de conceder permissões diferentes, a cada participante, para a utilização das ferramentas durante a reunião	BR13
RF	Deve possuir um link de ajuda para explicar como se convida outros participantes	OB03
RF	Deve ser possível deletar reuniões armazenadas	IN08

Tabela 3: Could Have.
Autor(a):Catlen Cleane e Júlia Vitória

Won't Have

   A tabela 4 apresenta os requisitos classificados como Won't Have.

Tipo	Requisito	Elicitação
RNF	Deve ser possível a integração com aplicativos de calendário afim de possibilitar a visualização dos compromissos do usuario no aplicativo	BR15
RF	O anfitrião conseguir atraveS do compartilhamento de tela interagir no celular de outro usuário	OB10

Tabela 4: Won't Have.
Autor(a):Catlen Cleane e Julia Vitoria

Legenda

RF(Requisitos Funcionais): descrevem as funcionalidades e operações que o sistema deve realizar para atender às necessidades dos usuários.

RNF(Requisitos Não Funcionais): definem a qualidade e o desempenho de um sistema.

Identificação(ENT + N°) : Requisito Elicitado pela Entrevista + Número.

Identificação(BR + N°) : Requisito Elicitado pela Brainstorming + Número

Identificação(IN + N°) : Requisito Elicitado pela Introspecção + Número

Identificação(OB + N°) : Requisito Elicitado pela Observação + Número

Histórico de Versão

  A tabela 5 representa o histórico de versão do documento.

Versão	Data	Descrição	Autor(es)	Revisor(es)
1.0	04/10/2023	Elaboração do artefato	Catlen Cleane e Júlia Vitória	Carolina Barbosa
1.1	04/10/2023	Correções do artefato	Catlen Cleane e Bruno Henrique	Carolina Barbosa

Tabela 5: Histórico de Versão.
Autor(a): Catlen Cleane e Júlia Vitória

Bibliografia

[1] MoSCoW em Simplenote. Acesso em 04 de Outubro de 2023.

[2] Requisitos - Aula 06. Acesso em 04 de Outubro de 2023.