Grupo 3
Lista de Verificação - Perfil de Usuário
Tabela 1: Checklist Perfil de Usuário do grupo 7
| ID | Descrição | Cumpriu? |
|---|---|---|
| 1 | O perfil de usuário identifica claramente os objetivos do usuário? | Sim |
| 2 | As características de interesse (cargo, função, experiência, nível de instrução etc.) foram coletadas e analisadas? | Sim |
| 3 | Os dados foram agrupados em faixas e categorias (ex.: idade, experiência) para facilitar priorização? | Sim |
| 4 | Foi calculada a proporção de usuários que se encaixam em cada perfil, permitindo priorizar grupos mais representativos? | Sim |
| 5 | O processo de elaboração do perfil de usuário foi iterativo, refinado ao longo do projeto? | Sim |
| 6 | As características do perfil de usuário foram priorizadas conforme a relevância para o produto e projeto? | Sim |
| 7 | Os recursos foram direcionados para capturar as características-chave mais importantes para o projeto? | Sim |
| 8 | Foram consideradas múltiplas dimensões do usuário (dados pessoais, relação com tecnologia, conhecimento do domínio, tarefas)? | Sim |
| 9 | Os usuários foram categorizados em grupos significativos (idade, experiência, atitudes, tarefas primárias)? | Sim |
| 10 | O perfil de usuário cobre a maioria dos grupos, evitando deixar uma porcentagem significativa de usuários sem representação? | Sim |
Lista de Verificação - 100$
Tabela 1: Checklist preenchido - 100$ do grupo 3
| ID | Item de Verificação | Cumpriu? |
|---|---|---|
| 1 | Cada participante recebeu a instrução clara de que dispõe de 100 dólares fictícios para distribuir? | Sim |
| 2 | Foi explicado que o valor alocado a um requisito deve refletir sua importância relativa em relação aos outros? | Sim |
| 3 | Foi impedido que um participante alocasse todos os 100 dólares em um único requisito? | Sim |
| 4 | A alocação inicial foi feita individualmente, sem influência ou debate prévio? | Sim |
| 5 | Após a alocação individual, os valores atribuídos a cada requisito por todos os participantes foram somados? | Sim |
| 6 | O resultado da soma foi usado para criar um ranking visual (lista ordenada) dos requisitos? | Sim |
| 7 | Foi realizado um debate após a votação para discutir e validar o ranking resultante? | Sim |
| 8 | Foi consenso entre os participantes que a técnica prioriza valor percebido, e não esforço de desenvolvimento? | Sim |
| 9 | Foi considerado o risco de enviesamento (“game the process”), em que participantes poderiam distorcer os resultados ao concentrar os 100 dólares em um requisito? | Sim |
| 10 | Houve discussão ou reconhecimento de que a técnica não leva em conta o esforço ou custo de implementação dos requisitos? | Sim |
Fonte: Miquéias Ezequiel.
Lista de Verificação - Moscow
Tabela 1: Checklist preenchido - Moscow do grupo 3
| ID | Item de Verificação | Cumpriu? |
|---|---|---|
| 1 | Os requisitos classificados como Must satisfazem a solução para que ela seja considerada um sucesso? | Sim |
| 2 | Os requisitos classificados como Should estão incluídos na solução sempre que possível? | Sim |
| 3 | Os requisitos classificados como Could são capacidades desejáveis identificadas no projeto? | Sim |
| 4 | Os requisitos classificados como Could podem ser adiados ou eliminados se houver falta de tempo ou recursos? | Sim |
| 5 | Os requisitos classificados como Won’t não serão implementados nesta entrega? | Sim |
| 6 | Está registrado que os requisitos classificados como Won’t podem ser incluídos em uma versão futura? | Sim |
| 7 | Foi esclarecido se os requisitos classificados como Won’t significam “não na próxima entrega” ou “nunca serão implementados”? | Sim |
| 8 | Todos os stakeholders compartilham o mesmo entendimento sobre o significado de cada classificação (Must, Should, Could, Won’t)? | Sim |
| 9 | Existe um número adequado de requisitos Must, evitando que quase todos recebam essa classificação? | Sim |
| 10 | Os usuários e stakeholders entendem claramente as diferenças entre Should, Could e Won’t? | Sim |
| 11 | Foi definido um critério objetivo para decidir a prioridade de cada requisito, já que o método não fornece essa orientação de forma explícita? | Sim |
| 12 | Foi considerada a limitação da técnica quanto à sua ambiguidade temporal (por exemplo, “Won’t” pode significar “não na próxima versão” ou “nunca”)? | Sim |
Fonte: Miquéias Ezequiel.
Lista de Verificação - Glossário (Não utilizado pelo grupo 3)
Tabela 1: Checklist preenchido - Glossário do grupo 3
| ID | Item de Verificação | Cumpriu? |
|---|---|---|
| 1 | Cada termo do glossário possui uma definição única, objetiva e livre de ambiguidades? | |
| 2 | As definições foram validadas com os stakeholders ou especialistas do domínio? | |
| 3 | Há registro de sinônimos, antônimos e abreviações para evitar interpretações múltiplas? | |
| 4 | Foram incluídos apenas termos relevantes ao domínio do problema (evitando excesso de itens triviais)? | |
| 5 | Cada termo possui uma fonte de referência (documento, norma, especialista ou reunião) que justifique sua definição? | |
| 6 | O glossário cobre termos de negócio, técnicos e organizacionais utilizados no projeto? | |
| 7 | As siglas e abreviações corporativas foram incluídas e explicadas integralmente? | |
| 8 | Os termos incluídos estão alinhados ao escopo do projeto e não incluem definições externas desnecessárias? | |
| 9 | A elaboração do glossário começou junto às atividades de elicitação de requisitos? | |
| 10 | O analista de requisitos possui um processo documentado para identificar e registrar novos termos? | |
| 11 | Há critérios claros para decidir quando um termo deve ser adicionado ao glossário? | |
| 12 | O glossário é revisado periodicamente durante as fases de análise, validação e manutenção do sistema? | |
| 9 | Existe um responsável formal (ou papel designado) pela atualização do glossário? | |
| 10 | O glossário está armazenado em local acessível a toda a equipe e stakeholders? | |
| 11 | Todos os stakeholders confirmaram que compreendem e utilizam o glossário durante as discussões de requisitos? | |
| 12 | - Há consistência terminológica entre o glossário e os documentos de requisitos? |
Fonte: Miquéias Ezequiel.
Técnica de Priorização - Three Level Scale
Tabela 7: Checklist Three Level Scale do grupo 3
| ID | Descrição | Cumpriu? |
|---|---|---|
| 1 | Os requisitos foram separados nos níveis de alta, média e baixa prioridade? | Sim |
| 2 | Os requisitos de alta prioridade são de extrema urgência e importância? | Sim |
| 3 | Os requisitos de alta prioridade podem ser implementados em outro momento? | Sim |
| 4 | Os requisitos de média prioridade podem ser feitos em outro momento? | Sim |
| 5 | Os requisitos considerados de baixa prioridade podem ser implementados em outro momento, além de não serem importantes para o cliente? | Sim |
| 6 | Foi incluída a prioridade do requisito junto ao próprio documento de requisitos de usuário? | Sim |
| 7 | Foram feitas subdivisões de requisitos por prioridade? | Não |
| 8 | Os requisitos dependentes de outros estão em um nível igual ou inferior de prioridade? | Sim |
Fonte: Samuel Felipe
Versionamento
| Versão | Data | Autor | Descrição | Revisor |
|---|---|---|---|---|
1.0 |
12/11/2025 | Luan Vinícius | Abertura do documento | |
2.0 |
12/11/2025 | Miquéias Ezequiel | Listas Moscow,100$, Glossário preenchidas | |
3.0 |
12/11/2025 | Samuel Felipe | Lista Three Level Scale | |
4.0 |
12/11/2025 | Heyttor augusto | Lista Perfil de usuario |