Grupo 7
Lista de Verificação - Perfil de Usuário
Tabela 1: Checklist preenchido - Perfil de Usuário 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? | Não |
| 5 | O processo de elaboração do perfil de usuário foi iterativo, refinado ao longo do projeto? | Não |
| 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)? | Incompleto |
| 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? | Não |
Lista de Verificação - 100$
Tabela 2: 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 3: 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
Tabela 4: 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? | Sim |
| 2 | As definições foram validadas com os stakeholders ou especialistas do domínio? | Sim |
| 3 | Há registro de sinônimos, antônimos e abreviações para evitar interpretações múltiplas? | Sim |
| 4 | Foram incluídos apenas termos relevantes ao domínio do problema (evitando excesso de itens triviais)? | Sim |
| 5 | Cada termo possui uma fonte de referência (documento, norma, especialista ou reunião) que justifique sua definição? | Sim |
| 6 | O glossário cobre termos de negócio, técnicos e organizacionais utilizados no projeto? | Sim |
| 7 | As siglas e abreviações corporativas foram incluídas e explicadas integralmente? | Sim |
| 8 | Os termos incluídos estão alinhados ao escopo do projeto e não incluem definições externas desnecessárias? | Sim |
| 9 | A elaboração do glossário começou junto às atividades de elicitação de requisitos? | Sim |
| 10 | O analista de requisitos possui um processo documentado para identificar e registrar novos termos? | Sim |
| 11 | Há critérios claros para decidir quando um termo deve ser adicionado ao glossário? | Sim |
| 12 | O glossário é revisado periodicamente durante as fases de análise, validação e manutenção do sistema? | Sim |
| 9 | Existe um responsável formal (ou papel designado) pela atualização do glossário? | Sim |
| 10 | O glossário está armazenado em local acessível a toda a equipe e stakeholders? | Sim |
| 11 | Todos os stakeholders confirmaram que compreendem e utilizam o glossário durante as discussões de requisitos? | Sim |
| 12 | - Há consistência terminológica entre o glossário e os documentos de requisitos? | Sim |
Fonte: Miquéias Ezequiel.
Tabela 5: Checklist preenchido - Three level scale do grupo 7
| 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? | Não |
| 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? | Não |
Fonte: Samuel Felipe
Lista de Verificação - Observação
Tabela 6: Checklist preenchido de Observação do grupo 7
| ID | Descrição | Cumpriu? |
|---|---|---|
| 1 | Foram estabelecidos os objetivos da observação antes de iniciá-la? | Sim |
| 2 | O grupo de pessoas e a janela de tempo para observação foram escolhidos com base nas necessidades de informação? | Sim |
| 3 | A observação cobre tanto o escopo (tarefas e serviços existentes) quanto a profundidade (regras e interações)? | Sim |
| 4 | Foram consultados documentos como organogramas ou fluxos operacionais antes da observação? | Não |
| 5 | As questões a serem respondidas durante ou após a observação foram previamente formuladas? | Sim |
| 6 | A seleção de usuários observados contempla diferentes perfis de experiência (especialistas e novatos)? | Não |
| 7 | O período de observação foi definido para capturar eventos previsíveis e excepcionais? | Sim |
| 8 | O analista decidiu previamente se atuaria de forma passiva (apenas observando) ou ativa (interagindo)? | Sim |
| 9 | O processo foi observado em mais de uma oportunidade para garantir consistência? | Não |
| 10 | O analista se apresentou, explicou objetivos e garantiu que o trabalho não seria criticado? | Sim |
| 11 | Durante a observação, foram feitas anotações completas das tarefas e interações observadas? | Incompleto |
| 12 | Os achados foram documentados, revisados e discutidos com os participantes para confirmação? | Sim |
Autor da inspeção: Luan Vinícius
Tabela 8: Checklist Value, Cost and Risk do grupo 7
| ID | Descrição | Cumpriu? |
|---|---|---|
| 1 | Todos os itens listados para priorização (requisitos, casos de uso, user stories) estão no mesmo nível de abstração e sem mistura de categorias diferentes? | Sim |
| 2 | Foram identificadas dependências entre requisitos (A precisa de B antes, etc.) e apenas o requisito condutor foi incluído na priorização? | Não |
| 3 | Os representantes do cliente atribuíram notas de 1 a 9 para o benefício de cada requisito, de acordo com o valor para o negócio? | Não |
| 4 | Foi atribuída uma nota de 1 a 9 para a penalidade caso o requisito não seja implementado? | Não |
| 5 | Ao avaliar a penalidade, foram considerados impactos como concorrência, requisitos legais, padrões de mercado e expectativas dos usuários? | Não |
| 6 | A equipe de desenvolvimento atribuiu notas de 1 a 9 para o custo de implementação de cada requisito, considerando complexidade, interface, reutilização e testes? | Não |
| 7 | A equipe técnica atribuiu notas de 1 a 9 para o risco técnico de implementação (complexidade, ferramentas novas, incertezas de viabilidade)? | Não |
| 8 | A planilha calculou automaticamente o valor total, o percentual de valor, custo e risco de cada requisito? | Não |
| 9 | Foi utilizada a fórmula recomendada para cálculo da prioridade de cada requisito? | Não |
| 10 | A lista final foi ordenada em ordem decrescente de prioridade calculada, destacando os itens com melhor relação valor/custo/risco? | Sim |
| 11 | Foram considerados ajustes de pesos (benefício, penalidade, custo, risco) de acordo com a realidade do projeto? | Não |
| 12 | Os stakeholders revisaram e validaram os resultados da priorização, discutindo divergências e chegando a consenso? | Não |
| 13 | As escalas de 1 a 9 para benefício, penalidade, custo e risco foram definidas explicitamente (por exemplo, o que significa nota 1, 5 e 9) e comunicadas a todos os participantes antes da priorização? | Não |
| 14 | Há registro de justificativas (em comentários na planilha ou documento) para notas extremas de benefício ou penalidade, especialmente em requisitos legais, regulatórios ou críticos para o negócio? | Não |
| 15 | As notas de custo e risco passaram por pelo menos uma rodada de revisão ou calibração pela equipe técnica, para reduzir discrepâncias grandes de percepção entre os avaliadores? | Não |
Fonte: Nayra Nery
Versionamento
| Versão | Data | Autor | Descrição | Revisor |
|---|---|---|---|---|
1.0 |
12/11/2025 | Luan Vinícius | Abertura do documento | |
1.1 |
12/11/2025 | Miquéias Ezequiel | Listas Moscow,100$, Glossário preenchidas | |
1.2 |
12/11/2025 | Samuel Felipe | Lista Three Level Scale | |
1.3 |
12/11/2025 | Luan Vinícius | Lista Observação | |
1.4 |
12/11/2025 | Nayra Nery | Lista Value | |
1.5 |
22/11/2025 | Nayra Nery | Correção da lista Value | |
1.6 |
22/11/2025 | Nayra Nery | Correção da lista Value | |
1.7 |
23/11/2025 | Luan Vinícius | Pequenas correções |