Listas de verificações
| Aluno | Contribuição |
|---|---|
| Luan Vinícius | Revisão da lista de observação |
| Miqueias | Criação da lista Glossario e revisão da lista de Moscow e $100 dolares e inspeção do grupo 3 das respectivas listas |
| Samuel | Three level scale e inspeção do grupo 3 das respectivas listas |
| Heyttor | Revisão da lista de perfil de usuário e inspeção do grupo 3 |
| Nayra | Revisão da lista de valor custo e risco |
Lista de Verificação - Perfil de Usuário
Tabela 1: Checklist Perfil de Usuário do grupo 7
Todas os itens de verificação foram tirados do livro Organização do Espaço de Problema Livro IHC: Barbosa e Silva [1]
Todos os itens dessa lista foram feito pelo estudante Miqueias Ezequiel
| ID | Descrição | Referencia |
|---|---|---|
| 1 | O perfil de usuário identifica claramente os objetivos do usuário? | clique aqui |
| 2 | As características de interesse (cargo, função, experiência, nível de instrução etc.) foram coletadas e analisadas? | clique aqui |
| 3 | Os dados foram agrupados em faixas e categorias (ex.: idade, experiência) para facilitar priorização? | clique aqui |
| 4 | Foi calculada a proporção de usuários que se encaixam em cada perfil, permitindo priorizar grupos mais representativos? | clique aqui |
| 5 | O processo de elaboração do perfil de usuário foi iterativo, refinado ao longo do projeto? | clique aqui |
| 6 | As características do perfil de usuário foram priorizadas conforme a relevância para o produto e projeto? | clique aqui |
| 7 | Os recursos foram direcionados para capturar as características-chave mais importantes para o projeto? | clique aqui |
| 8 | Foram consideradas múltiplas dimensões do usuário (dados pessoais, relação com tecnologia, conhecimento do domínio, tarefas)? | clique aqui |
| 9 | Os usuários foram categorizados em grupos significativos (idade, experiência, atitudes, tarefas primárias)? | clique aqui |
| 10 | O perfil de usuário cobre a maioria dos grupos, evitando deixar uma porcentagem significativa de usuários sem representação? | clique aqui |
Lista de Verificação – Técnica dos 100 Dólares
Tabela 2: Checklist de técnica de 100$ dólares para o grupo 1
| ID | Descrição | Autor(es) | Referências |
|---|---|---|---|
| 1 | Cada participante recebeu a instrução clara de que dispõe de 100 dólares fictícios para distribuir? [1] | Luan Vinícius, Samuel Felipe, Miquéias Ezequiel, Heyttor Augusto, João Pedro | Ver Imagem |
| 2 | Foi explicado que o valor alocado a um requisito deve refletir sua importância relativa em relação aos outros? [1] | Luan Vinícius, Samuel Felipe, Miquéias Ezequiel, Heyttor Augusto, João Pedro | Ver Imagem |
| 3 | Foi impedido que um participante alocasse todos os 100 dólares em um único requisito? [1] | Luan Vinícius, Samuel Felipe, Miquéias Ezequiel, Heyttor Augusto, João Pedro | Ver Imagem |
| 4 | A alocação inicial foi feita individualmente, sem influência ou debate prévio? [1] | Luan Vinícius, Samuel Felipe, Miquéias Ezequiel, Heyttor Augusto, João Pedro | Ver Imagem |
| 5 | Após a alocação individual, os valores atribuídos a cada requisito por todos os participantes foram somados? [1] | Luan Vinícius, Samuel Felipe, Miquéias Ezequiel, Heyttor Augusto, João Pedro | Ver Imagem |
| 6 | O resultado da soma foi usado para criar um ranking visual (lista ordenada) dos requisitos? [1] | Luan Vinícius, Samuel Felipe, Miquéias Ezequiel, Heyttor Augusto, João Pedro | Ver Imagem |
| 7 | Foi realizado um debate após a votação para discutir e validar o ranking resultante? [1] | Luan Vinícius, Samuel Felipe, Miquéias Ezequiel, Heyttor Augusto, João Pedro | Ver Imagem |
| 8 | Foi consenso entre os participantes que a técnica prioriza valor percebido, e não esforço de desenvolvimento? [1] | Luan Vinícius, Samuel Felipe, Miquéias Ezequiel, Heyttor Augusto, João Pedro | Ver Imagem |
| 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? [1] | Luan Vinícius, Samuel Felipe, Miquéias Ezequiel, Heyttor Augusto, João Pedro | Ver Imagem |
| 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? [1] | Luan Vinícius, Samuel Felipe, Miquéias Ezequiel, Heyttor Augusto, João Pedro | Ver Imagem |
Lista de Verificação – Moscow
Tabela 3: Checklist de Moscow para o grupo 1
| ID | Descrição | Autor(es) | Referências |
|---|---|---|---|
| 1 | Os requisitos classificados como Must satisfazem a solução para que ela seja considerada um sucesso? [2] | Luan Vinícius, Samuel Felipe, Miquéias Ezequiel, Heyttor Augusto, João Pedro | Ver Imagem |
| 2 | Os requisitos classificados como Should estão incluídos na solução sempre que possível? [2] | Luan Vinícius, Samuel Felipe, Miquéias Ezequiel, Heyttor Augusto, João Pedro | Ver Imagem |
| 3 | Os requisitos classificados como Could são capacidades desejáveis identificadas no projeto? [2] | Luan Vinícius, Samuel Felipe, Miquéias Ezequiel, Heyttor Augusto, João Pedro | Ver Imagem |
| 4 | Os requisitos classificados como Could podem ser adiados ou eliminados se houver falta de tempo ou recursos? [2] | Luan Vinícius, Samuel Felipe, Miquéias Ezequiel, Heyttor Augusto, João Pedro | Ver Imagem |
| 5 | Os requisitos classificados como Won’t não serão implementados nesta entrega? [2] | Luan Vinícius, Samuel Felipe, Miquéias Ezequiel, Heyttor Augusto, João Pedro | Ver Imagem |
| 6 | Está registrado que os requisitos classificados como Won’t podem ser incluídos em uma versão futura? [2] | Luan Vinícius, Samuel Felipe, Miquéias Ezequiel, Heyttor Augusto, João Pedro | Ver Imagem |
| 7 | Foi esclarecido se os requisitos classificados como Won’t significam “não na próxima entrega” ou “nunca serão implementados”? [2] | Luan Vinícius, Samuel Felipe, Miquéias Ezequiel, Heyttor Augusto, João Pedro | Ver Imagem |
| 8 | Todos os stakeholders compartilham o mesmo entendimento sobre o significado de cada classificação (Must, Should, Could, Won’t)? [2] | Luan Vinícius, Samuel Felipe, Miquéias Ezequiel, Heyttor Augusto, João Pedro | Ver Imagem |
| 9 | Existe um número adequado de requisitos Must, evitando que quase todos recebam essa classificação? [2] | Luan Vinícius, Samuel Felipe, Miquéias Ezequiel, Heyttor Augusto, João Pedro | Ver Imagem |
| 10 | Os usuários e stakeholders entendem claramente as diferenças entre Should, Could e Won’t? [2] | Luan Vinícius, Samuel Felipe, Miquéias Ezequiel, Heyttor Augusto, João Pedro | Ver Imagem |
| 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? [2] | Luan Vinícius, Samuel Felipe, Miquéias Ezequiel, Heyttor Augusto, João Pedro | Ver Imagem |
| 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”)? [2] | Luan Vinícius, Samuel Felipe, Miquéias Ezequiel, Heyttor Augusto, João Pedro | Ver Imagem |
Lista de Verificação – Glossário
Tabela 4: Checklist de Glossário para o grupo 1
| ID | Descrição | Autor(es) | Referências |
|---|---|---|---|
| 1 | Cada termo do glossário possui uma definição única, objetiva e livre de ambiguidades? [3] | Luan Vinícius, Samuel Felipe, Miquéias Ezequiel, Heyttor Augusto, João Pedro | Ver Imagem |
| 2 | As definições foram validadas com os stakeholders ou especialistas do domínio? [3] | Luan Vinícius, Samuel Felipe, Miquéias Ezequiel, Heyttor Augusto, João Pedro | Ver Imagem |
| 3 | Há registro de sinônimos, antônimos e abreviações para evitar interpretações múltiplas? [3] | Luan Vinícius, Samuel Felipe, Miquéias Ezequiel, Heyttor Augusto, João Pedro | Ver Imagem |
| 4 | Foram incluídos apenas termos relevantes ao domínio do problema (evitando excesso de itens triviais)? [3] | Luan Vinícius, Samuel Felipe, Miquéias Ezequiel, Heyttor Augusto, João Pedro | Ver Imagem |
| 5 | Cada termo possui uma fonte de referência (documento, norma, especialista ou reunião) que justifique sua definição? [3] | Luan Vinícius, Samuel Felipe, Miquéias Ezequiel, Heyttor Augusto, João Pedro | Ver Imagem |
| 6 | O glossário cobre termos de negócio, técnicos e organizacionais utilizados no projeto? [3] | Luan Vinícius, Samuel Felipe, Miquéias Ezequiel, Heyttor Augusto, João Pedro | Ver Imagem |
| 7 | As siglas e abreviações corporativas foram incluídas e explicadas integralmente? [3] | Luan Vinícius, Samuel Felipe, Miquéias Ezequiel, Heyttor Augusto, João Pedro | Ver Imagem |
| 8 | Os termos incluídos estão alinhados ao escopo do projeto e não incluem definições externas desnecessárias? [3] | Luan Vinícius, Samuel Felipe, Miquéias Ezequiel, Heyttor Augusto, João Pedro | Ver Imagem |
| 9 | A elaboração do glossário começou junto às atividades de elicitação de requisitos? [3] | Luan Vinícius, Samuel Felipe, Miquéias Ezequiel, Heyttor Augusto, João Pedro | Ver Imagem |
| 10 | O analista de requisitos possui um processo documentado para identificar e registrar novos termos? [3] | Luan Vinícius, Samuel Felipe, Miquéias Ezequiel, Heyttor Augusto, João Pedro | Ver Imagem |
| 11 | Há critérios claros para decidir quando um termo deve ser adicionado ao glossário? [3] | Luan Vinícius, Samuel Felipe, Miquéias Ezequiel, Heyttor Augusto, João Pedro | Ver Imagem |
| 12 | O glossário é revisado periodicamente durante as fases de análise, validação e manutenção do sistema? [3] | Luan Vinícius, Samuel Felipe, Miquéias Ezequiel, Heyttor Augusto, João Pedro | Ver Imagem |
| 13 | Existe um responsável formal (ou papel designado) pela atualização do glossário? [3] | Luan Vinícius, Samuel Felipe, Miquéias Ezequiel, Heyttor Augusto, João Pedro | Ver Imagem |
| 14 | O glossário está armazenado em local acessível a toda a equipe e stakeholders? [3] | Luan Vinícius, Samuel Felipe, Miquéias Ezequiel, Heyttor Augusto, João Pedro | Ver Imagem |
| 15 | Todos os stakeholders confirmaram que compreendem e utilizam o glossário durante as discussões de requisitos? [3] | Luan Vinícius, Samuel Felipe, Miquéias Ezequiel, Heyttor Augusto, João Pedro | Ver Imagem |
| 16 | Há consistência terminológica entre o glossário e os documentos de requisitos? [3] | Luan Vinícius, Samuel Felipe, Miquéias Ezequiel, Heyttor Augusto, João Pedro | Ver Imagem |
Técnica de Priorização - Three Level Scale
Tabela 5: Checklist Three Level Scale do grupo 7
| ID | Descrição | Autor(res) | Referências |
|---|---|---|---|
| 1 | Os requisitos foram separados nos níveis de alta, média e baixa prioridade? [5] | Heyttor Augusto | Ver Imagem |
| 2 | Os requisitos de alta prioridade são de extrema urgência e importância? [5] | Heyttor Augusto | Ver Imagem |
| 3 | Os requisitos de alta prioridade podem ser implementados em outro momento? [5] | Heyttor Augusto | Ver Imagem |
| 4 | Os requisitos de média prioridade podem ser feitos em outro momento? [5] | Heyttor Augusto | Ver Imagem |
| 5 | Os requisitos considerados de baixa prioridade podem ser implementados em outro momento, além de não serem importantes para o cliente? [5] | Heyttor Augusto | Ver Imagem |
| 6 | Foi incluída a prioridade do requisito junto ao próprio documento de requisitos de usuário? [5] | Heyttor Augusto | Ver Imagem |
| 7 | Foram feitas subdivisões de requisitos por prioridade? [5] | Heyttor Augusto | Ver Imagem |
| 8 | Os requisitos dependentes de outros estão em um nível igual ou inferior de prioridade? [5] | Heyttor Augusto | Ver Imagem |
Lista de Verificação - Observação
Todos os itens de verificação foram elaborados do livro Engenharia de Requisitos: Software orientado ao négocio, cap. 7 [3]
Tabela 6: Checklist de Observação do grupo 7
| ID | Descrição | Autor(es) | Referência/descrição |
|---|---|---|---|
| 1 | Foram estabelecidos os objetivos da observação antes de iniciá-la? [3] | Luan Vinícius | Ver Imagem |
| 2 | O grupo de pessoas e a janela de tempo para observação foram escolhidos com base nas necessidades de informação? [3] | Luan Vinícius | Ver Imagem |
| 3 | A observação cobre tanto o escopo (tarefas e serviços existentes) quanto a profundidade (regras e interações)? [3] | Luan Vinícius | Ver Imagem |
| 4 | Foram consultados documentos como organogramas ou fluxos operacionais antes da observação? [3] | Luan Vinícius | Ver Imagem |
| 5 | As questões a serem respondidas durante ou após a observação foram previamente formuladas? [3] | Luan Vinícius | Ver Imagem |
| 6 | A seleção de usuários observados contempla diferentes perfis de experiência (especialistas e novatos)? [3] | Luan Vinícius | Ver Imagem |
| 7 | O período de observação foi definido para capturar eventos previsíveis e excepcionais? [3] | Luan Vinícius | Ver Imagem |
| 8 | O analista decidiu previamente se atuaria de forma passiva (apenas observando) ou ativa (interagindo)? [3] | Luan Vinícius | Ver Imagem |
| 9 | O processo foi observado em mais de uma oportunidade para garantir consistência? [3] | Luan Vinícius | Ver Imagem |
| 10 | O analista se apresentou, explicou objetivos e garantiu que o trabalho não seria criticado? [3] | Luan Vinícius | Ver Imagem |
| 11 | Durante a observação, foram feitas anotações completas das tarefas e interações observadas? [3] | Luan Vinícius | Ver Imagem |
| 12 | Os achados foram documentados, revisados e discutidos com os participantes para confirmação? [3] | Luan Vinícius | Ver Imagem |
Técnica de Priorização - Value, Cost and Risk
Tabela 7: 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? | |
| 2 | Foram identificadas dependências entre requisitos (A precisa de B antes, etc.) e apenas o requisito condutor foi incluído na priorizaçã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? | |
| 4 | Foi atribuída uma nota de 1 a 9 para a penalidade caso o requisito não seja implementado? | |
| 5 | Ao avaliar a penalidade, foram considerados impactos como concorrência, requisitos legais, padrões de mercado e expectativas dos usuários? | |
| 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? | |
| 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)? | |
| 8 | A planilha calculou automaticamente o valor total, o percentual de valor, custo e risco de cada requisito? | |
| 9 | Foi utilizada a fórmula recomendada para cálculo da prioridade de cada requisito? | |
| 10 | A lista final foi ordenada em ordem decrescente de prioridade calculada, destacando os itens com melhor relação valor/custo/risco? | |
| 11 | Foram considerados ajustes de pesos (benefício, penalidade, custo, risco) de acordo com a realidade do projeto? | |
| 12 | Os stakeholders revisaram e validaram os resultados da priorização, discutindo divergências e chegando a consenso? | |
| 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? | |
| 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? | |
| 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? |
Referências Bibliográficas
- 1. Wiegers, K. E., & Beatty, J. (2013). Software Requirements (3rd ed.). Redmond, WA: Microsoft Press. Acesso em: 11 Nov. 2025.
- 2. Wiegers, K. E., & Beatty, J. (2013). Software Requirements (3rd ed., p. 317-324). Redmond, WA: Microsoft Press. Acesso em: 11 Nov. 2025.
- 3. VAZQUEZ, Carlos Eduardo; SIMÕES, Guilherme Siqueira. Engenharia de Requisitos: Software Orientado ao Negócio. Rio de Janeiro: Brasport, 2016. Acesso em: 11 Nov. 2025.
- 4. BARBOSA, Simone Diniz Junqueira et al. Identificação de Necessidades dos Usuários e Definição dos Requisitos de IHC. In: BARBOSA, Simone Diniz Junqueira et al. Interação Humano-Computador e Experiência do Usuário. 1. ed. Rio de Janeiro: Autopublicação, 2021. Cap. 7. Disponível em: https://aprender3.unb.br/pluginfile.php/3210605/mod_resource/content/4/ihc-ux%20cap%207.pdf.
- 5. Wiegers, K. E., & Beatty, J. (2013). Software Requirements (3rd ed., p. 319-320). Redmond, WA: Microsoft Press. Acesso em: 11 Nov. 2025.
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 | |
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 | Heyttor augusto | Lista Perfil de usuario | |
1.5 |
23/11/2025 | Luan Vinícius | Atualização da referência/descrição de observação |