Verificação

Introdução

Esta página é dedicada à lista de verificação criada para os artefatos da Segunda Entrega. A lista foi criada a partir das técnincas utilizadas pelo grupo.

Lista de Verificação

Tabela 1 - Verificação Pesquisa/Questionário

Tabela 1 - Lista de verificação para o artefato pesquisa/questionário.

Código	Descrição	Autor	Referência
LQ1	O questionário deve ser um formulário impresso ou on-line com perguntas estruturadas para coletar dados de pesquisa, análise ou avaliação. “Um questionário é um formulário impresso ou on-line com perguntas que os usuários e demais participantes devem responder, a fim de fornecer os dados necessários em uma pesquisa, análise ou avaliação.”	Gabriela Alves	BARBOSA, Simone D. J.; SANTANA DA SILVA, Bruno; SILVEIRA, Milene S.; GASPARINI, Isabela; DARIN, Ticianne; BARBOSA, Gabriel D. J. Interação Humano-Computador e Experiência do Usuário. p. 149.
LQ2	As perguntas devem ser formuladas com cuidado para evitar ambiguidades, indicando claramente se admitem resposta única ou múltipla. “Como o respondente não terá como tirar dúvidas sobre as perguntas no momento de responder ao questionário, a formulação da pergunta (e das respostas) deve ser ainda mais cuidadosa do que no caso de entrevistas, evitando ambiguidades e mal-entendidos.”	Gabriela Alves	BARBOSA, Simone D. J.; SANTANA DA SILVA, Bruno; SILVEIRA, Milene S.; GASPARINI, Isabela; DARIN, Ticianne; BARBOSA, Gabriel D. J. Interação Humano-Computador e Experiência do Usuário. p. 149.
LQ3	O questionário deve oferecer opções neutras ou “outros” para evitar vieses e dar voz a respostas não previstas. “Assim como entrevistas, questionários podem conter perguntas abertas e fechadas, mas costumam privilegiar as perguntas fechadas, de preenchimento rápido e de fácil análise.” “Perguntas fechadas geralmente incluem respostas neutras ou alternativas, como ‘não sei’, ‘não quero responder’ ou ‘outros’.”	Gabriela Alves	BARBOSA, Simone D. J.; SANTANA DA SILVA, Bruno; SILVEIRA, Milene S.; GASPARINI, Isabela; DARIN, Ticianne; BARBOSA, Gabriel D. J. Interação Humano-Computador e Experiência do Usuário. p. 149–150.
LQ5	Perguntas sobre valores (por exemplo, idade ou renda) devem usar faixas de resposta sem sobreposição, garantindo ambiguidade zero. “É comum oferecermos faixas de valores como opções de resposta. Nesse tipo de pergunta, é importante evitar a sobreposição de valores (e.g., 20–30 e 30–40), para que a ambiguidade não prejudique a acurácia dos dados coletados.”	Gabriela Alves	BARBOSA, Simone D. J.; SANTANA DA SILVA, Bruno; SILVEIRA, Milene S.; GASPARINI, Isabela; DARIN, Ticianne; BARBOSA, Gabriel D. J. Interação Humano-Computador e Experiência do Usuário. p. 150.
LQ6	Escalas de Likert devem usar um número ímpar de pontos (geralmente 5 ou 7) e incluir opção neutra (“não sei”) para medir opiniões, atitudes ou satisfação. “Em geral, utilizamos um número ímpar de valores, a menos que queiramos evitar que os usuários fiquem ‘em cima do muro’. Em escalas Likert, costumamos utilizar 5 ou 7 pontos, e em escalas de diferencial semântico utilizamos 5, 7 ou mesmo 9 pontos.”	Gabriela Alves	BARBOSA, Simone D. J.; SANTANA DA SILVA, Bruno; SILVEIRA, Milene S.; GASPARINI, Isabela; DARIN, Ticianne; BARBOSA, Gabriel D. J. Interação Humano-Computador e Experiência do Usuário. p. 151.
LQ7	A sequência das perguntas deve seguir estrutura lógica e ser agrupada por temas, para evitar que uma questão influencie a outra. “A ordem das perguntas deve ser cuidadosamente projetada, pois a resposta a uma pergunta pode ser influenciada por uma das perguntas anteriores. Quando um questionário é longo, suas perguntas podem ser agrupadas em tópicos relacionados, formando uma estrutura lógica e de preenchimento mais fácil.”	Gabriela Alves	BARBOSA, Simone D. J.; SANTANA DA SILVA, Bruno; SILVEIRA, Milene S.; GASPARINI, Isabela; DARIN, Ticianne; BARBOSA, Gabriel D. J. Interação Humano-Computador e Experiência do Usuário. p. 151.

Autor: Gabriela

Tabela 2 - Verificação Análise de Documentos

Tabela 2 - Lista de verificação para o artefato análise de documentos.

Código	Descrição	Autor	Referência
LD1	Os documentos analisados incluem especificações de requisitos, processos de negócio, manuais do usuário ou semelhantes? “Document analysis entails examining any existing documentation for potential software requirements. The most useful documentation includes requirements specifications, business processes, lessons learned collections, and user manuals for existing or similar applications.”	Luiz Morais	WIEGERS, K.; BEATTY, J. Software Requirements. 3. ed. Redmond: Microsoft Press, 2013. p. 128.
LD2	Os documentos analisados são documentos recentes? “A risk with this technique is that the available documents might not be up to date. Requirements might have changed without the specifications being updated, or functionality might be documented that is not needed in a new system.”	Luiz Morais	WIEGERS, K.; BEATTY, J. Software Requirements. 3. ed. Redmond: Microsoft Press, 2013. p. 129.

Autor: Luiz

Tabela 3 - Verificação Observação

Tabela 3 - Lista de verificação para o artefato observação.

Código	Descrição	Autor	Referência
LO1	Há um observador “O observador imerge no ambiente de trabalho onde a solução será usada observando o trabalho cotidiano e tirando notas das tarefas nas quais as partes interessadas estão envolvidas.”	Ana Clara Borges	VAZQUEZ, Carlos Eduardo; SIMÕES, Guilherme Siqueira. Engenharia de requisitos: software orientado ao negócio. Rio de Janeiro: Brasport Livros e Multimídia, 2016. p. 159.
LO2	Há uma pessoa ou um grupo de pessoas sendo observada(s) “... pela condução de uma avaliação no ambiente de trabalho das partes interessadas apropriadas.”	Ana Clara Borges	VAZQUEZ, Carlos Eduardo; SIMÕES, Guilherme Siqueira. Engenharia de requisitos: software orientado ao negócio. Rio de Janeiro: Brasport Livros e Multimídia, 2016. p. 159.
LO3	As atitudes da pessoa sendo observada contribuem para a elicitação dos requisitos funcionais “... para ver problemas no sistema atual e para identificar maneiras para que o novo sistema possa contribuir no fluxo de trabalho.”	Ana Clara Borges	WIEGERS, Karl E.; BEATTY, Joy. Software Requirements. 3. ed. Redmond: Microsoft Press, 2013. p. 126.
LO4	O observador assume uma postura passiva ou ativa “Também se deve definir qual tipo de postura o observador assumirá: Passiva ou Ativa.”	Ana Clara Borges	VAZQUEZ, Carlos Eduardo; SIMÕES, Guilherme Siqueira. Engenharia de requisitos: software orientado ao negócio. Rio de Janeiro: Brasport Livros e Multimídia, 2016. p. 160.
LO5	Há uma apresentação às pessoas que vão ser observadas “... apresenta-se às pessoas que serão observadas.”	Ana Clara Borges	VAZQUEZ, Carlos Eduardo; SIMÕES, Guilherme Siqueira. Engenharia de requisitos: software orientado ao negócio. Rio de Janeiro: Brasport Livros e Multimídia, 2016. p. 161.
LO6	Os objetivos da técnica foram explicados anteriormente aos usuários observados “Esclarece que as informações resultantes servirão como insumo para análise dos requisitos.”	Ana Clara Borges	VAZQUEZ, Carlos Eduardo; SIMÕES, Guilherme Siqueira. Engenharia de requisitos: software orientado ao negócio. Rio de Janeiro: Brasport Livros e Multimídia, 2016. p. 161.
LO7	Os usuários observados foram definidos “usuários cujo trabalho deve ser observado, como, por exemplo, especialistas e novatos.”	Ana Clara Borges	VAZQUEZ, Carlos Eduardo; SIMÕES, Guilherme Siqueira. Engenharia de requisitos: software orientado ao negócio. Rio de Janeiro: Brasport Livros e Multimídia, 2016. p. 160.

Autor: Ana Clara

Tabela 4 - Verificação Análise de Interface

Tabela 4 - Lista de verificação para o artefato análise de interface.

Código	Descrição	Autor	Referência
LVAI01	Foram identificados requisitos funcionais relacionados à troca de dados e serviços entre o sistema em desenvolvimento e sistemas externos com os quais ele se conecta. “System interface analysis reveals functional requirements regarding the exchange of data and services between systems.”	Ana Joyce	WIEGERS, Karl; BEATTY, Joy. Software Requirements. 3. ed. [S. l.]: Microsoft Press, 2013. p. 127.
LVAI02	Para cada sistema externo identificado, foram analisadas funcionalidades que possam gerar requisitos para o sistema em desenvolvimento? “For each system that interfaces with yours, identify functionality in the other system that might lead to requirements for your system.”	Ana Joyce	WIEGERS, Karl; BEATTY, Joy. Software Requirements. 3. ed. [S. l.]: Microsoft Press, 2013. p. 127.

Autor: Ana Joyce

Tabela 5 - Verificação Perfil de Usuário

Tabela 5 - Lista de verificação para o artefato perfil de usuário.

Código	Descrição	Autor	Referência
LP1	Definir quem são os usuários (ex.: professores, estudantes, profissionais de saúde).	Fábio Gabriel	BARBOSA, Simone D. J.; SANTANA DA SILVA, Bruno; SILVEIRA, Milene S.; GASPARINI, Isabela; DARIN, Ticianne; BARBOSA, Gabriel D. J. Interação Humano-Computador e Experiência do Usuário. p. 165.
LP2	Cargo/função (ex.: professor, gerente, estudante). Nível de instrução (ex.: ensino médio, graduação, pós-graduação). Faixa etária (ex.: 18-25, 26-40, 41-60).	Fábio Gabriel	BARBOSA, Simone D. J.; SANTANA DA SILVA, Bruno; SILVEIRA, Milene S.; GASPARINI, Isabela; DARIN, Ticianne; BARBOSA, Gabriel D. J. Interação Humano-Computador e Experiência do Usuário. p. 166.
LP3	Classificar familiaridade tecnológica (leigo, intermediário, especialista).	Fábio Gabriel	BARBOSA, Simone D. J.; SANTANA DA SILVA, Bruno; SILVEIRA, Milene S.; GASPARINI, Isabela; DARIN, Ticianne; BARBOSA, Gabriel D. J. Interação Humano-Computador e Experiência do Usuário. p. 166.
LP4	Nível de expertise no assunto (iniciante, intermediário, avançado).	Fábio Gabriel	BARBOSA, Simone D. J.; SANTANA DA SILVA, Bruno; SILVEIRA, Milene S.; GASPARINI, Isabela; DARIN, Ticianne; BARBOSA, Gabriel D. J. Interação Humano-Computador e Experiência do Usuário. p. 166.
LP5	Listar tarefas principais que o usuário realizará no sistema (ex.: comprar, cadastrar dados).	Fábio Gabriel	BARBOSA, Simone D. J.; SANTANA DA SILVA, Bruno; SILVEIRA, Milene S.; GASPARINI, Isabela; DARIN, Ticianne; BARBOSA, Gabriel D. J. Interação Humano-Computador e Experiência do Usuário. p. 166.
LP6	Agrupar usuários por similaridade (ex.: faixa etária, experiência, objetivos).	Fábio Gabriel	BARBOSA, Simone D. J.; SANTANA DA SILVA, Bruno; SILVEIRA, Milene S.; GASPARINI, Isabela; DARIN, Ticianne; BARBOSA, Gabriel D. J. Interação Humano-Computador e Experiência do Usuário. p. 166.
LP7	Definir critérios mais relevantes para o projeto (ex.: em um app acadêmico, priorizar "nível de instrução").	Fábio Gabriel	BARBOSA, Simone D. J.; SANTANA DA SILVA, Bruno; SILVEIRA, Milene S.; GASPARINI, Isabela; DARIN, Ticianne; BARBOSA, Gabriel D. J. Interação Humano-Computador e Experiência do Usuário. p. 166.
LP8	Coletar dados reais (entrevistas, questionários, observação).	Fábio Gabriel	BARBOSA, Simone D. J.; SANTANA DA SILVA, Bruno; SILVEIRA, Milene S.; GASPARINI, Isabela; DARIN, Ticianne; BARBOSA, Gabriel D. J. Interação Humano-Computador e Experiência do Usuário. p. 166.

Autor: Fábio

Tabela 6 - Verificação Three Level Scale

Tabela 6 - Lista de verificação para o artefato three level scale.

Código	Descrição	Autor	Referência
LT1	A técnica de priorização deve ser feita com stakeholders concordando com as prioridades dos requisitos. “To make the scale useful, the stakeholders must agree on what each level means in the scale they use.”	Luiz Morais	WIEGERS, K; BEATTY, J. Software Requirements. 3. ed. Redmond: Microsoft Press, 2013. p. 319.
LT2	A técnica deve separar os requisitos em quatro categorias de prioridade: alta, média, baixa, não fazer. Figura: Requirements prioritization based on importance and urgency	Luiz Morais	WIEGERS, K; BEATTY, J. Software Requirements. 3. ed. Redmond: Microsoft Press, 2013. p. 319.

Autor: Luiz

Tabela 7 - Verificação Moscow

Tabela 7 - Lista de verificação para o artefato moscow.

Código	Descrição	Autor	Referência
LM1	Os requisitos Must realmente são essenciais para o sucesso do projeto?	Davi Emanuel	Software Requirements, Third edition - Tópico MoSCow
LM2	Os requisitos Should são importantes, mas não impedem o sucesso do projeto caso não sejam incluídos?	Davi Emanuel	Software Requirements, Third edition - Tópico MoSCow
LM3	Os requisitos Could foram identificados como desejáveis e viáveis apenas se houver tempo e recursos?	Davi Emanuel	Software Requirements, Third edition - Tópico MoSCow
LM4	Os requisitos Won’t foram conscientemente excluídos por não serem prioritários neste momento?	Davi Emanuel	Software Requirements, Third edition - Tópico MoSCow
LM5	Todos os stakeholders participaram da classificação dos requisitos?	Davi Emanuel	Requisitos – Aula 07 - Milene Serrano e Mauricio Serrano
LM6	Os itens classificados como Could foram avaliados quanto à sua relação com a satisfação do cliente?	Davi Emanuel	Requisitos – Aula 07 - Milene Serrano e Mauricio Serrano
LM7	A técnica foi usada com linguagem simples e acessível a todos os envolvidos?	Davi Emanuel	Requisitos – Aula 07 - Milene Serrano e Mauricio Serrano
LM8	As decisões sobre o que será Won’t foram baseadas em retorno sobre investimento ou impacto estratégico?	Davi Emanuel	Requisitos – Aula 07 - Milene Serrano e Mauricio Serrano
LM9	A classificação foi feita com base no conhecimento real do negócio pelos interessados?	Davi Emanuel	Requisitos – Aula 07 - Milene Serrano e Mauricio Serrano
LM10	A exclusão dos requisitos não compromete a entrega ou o uso do produto?	Davi Emanuel	Requisitos – Aula 07 - Milene Serrano e Mauricio Serrano

Autor: Davi

Tabela 8 - Verificação In Or Out

Tabela 8 - Lista de verificação para o artefato in or out.

Código	Descrição	Autor	Referência
LI1	Fazer decisão binária de todos os requisitos elicitados (in ou out)	Fábio Gabriel	Software Requirements, 3. ed. Redmond: Microsoft Press, 2013. p. 318
LI2	Basear-se nos objetivos do negócio	Fábio Gabriel	Software Requirements, 3. ed. Redmond: Microsoft Press, 2013. p. 318
LI3	Reduzir à quantidade mínima para o primeiro release	Fábio Gabriel	Software Requirements, 3. ed. Redmond: Microsoft Press, 2013. p. 318
LI4	Guardar requisitos “out” para o próximo release	Fábio Gabriel	Software Requirements, 3. ed. Redmond: Microsoft Press, 2013. p. 318
LI5	Facilitar reunião com stakeholders para decisão coletiva	Fábio Gabriel	Software Requirements, 3. ed. Redmond: Microsoft Press, 2013. p. 318
LI6	Designar um stakeholder para decisão final em caso de conflito	Fábio Gabriel	Software Requirements, 3. ed. Redmond: Microsoft Press, 2013. p. 318
LI7	Criar um ambiente leve e motivador	Fábio Gabriel	Software Requirements, 3. ed. Redmond: Microsoft Press, 2013. p. 318

Autor: Fábio

Tabela 9 - Verificação QFD

Tabela 9 - Lista de verificação para o artefato QFD.

Código	Descrição	Autor	Referência
LQFD1	É definido os Requisitos do consumidor à esquerda da Casa da Qualidade.	Mateus Villela	SHORT, Michael. Lecture 4: Quality Function Deployment (QFD) and House of Quality. MIT OpenCourseWare, 2011. (4 min 16s)
LQFD2	Há um ranking de importância para o consumidor, respectivamente aos requisitos do consumidor.	Mateus Villela	SHORT, Michael. Lecture 4: Quality Function Deployment (QFD) and House of Quality. MIT OpenCourseWare, 2011. (5 min 58s)
LQFD3	O ranking de importância para o consumidor possui uma delimitação de intervalos (uma escala).	Mateus Villela	SHORT, Michael. Lecture 4: Quality Function Deployment (QFD) and House of Quality. MIT OpenCourseWare, 2011. (6 min 50s)
LQFD4	O ranking de importância para o consumidor também é representado em termos de porcentagem (%).	Mateus Villela	SHORT, Michael. Lecture 4: Quality Function Deployment (QFD) and House of Quality. MIT OpenCourseWare, 2011. (8 min 30s)
LQFD5	Há a definição dos requisitos técnicos na parte superior da Casa da Qualidade.	Mateus Villela	SHORT, Michael. Lecture 4: Quality Function Deployment (QFD) and House of Quality. MIT OpenCourseWare, 2011. (9 min 00s)
LQFD6	Linha superior da Casa da Qualidade associando requisitos técnicos à direção da melhoria.	Mateus Villela	SHORT, Michael. Lecture 4: Quality Function Deployment (QFD) and House of Quality. MIT OpenCourseWare, 2011. (12 min 00s)
LQFD7	Há o 'telhado' da Casa da Qualidade com a expressão das correlações entre os requisitos técnicos.	Mateus Villela	SHORT, Michael. Lecture 4: Quality Function Deployment (QFD) and House of Quality. MIT OpenCourseWare, 2011. (13 min 32s)
LQFD8	Contém a legenda dos símbolos para a correlação utilizada no 'telhado' da Casa da Qualidade.	Mateus Villela	SHORT, Michael. Lecture 4: Quality Function Deployment (QFD) and House of Quality. MIT OpenCourseWare, 2011. (14 min 52s)
LQFD9	Corpo de relações entre requisitos técnicos e requisitos dos consumidores.	Mateus Villela	SHORT, Michael. Lecture 4: Quality Function Deployment (QFD) and House of Quality. MIT OpenCourseWare, 2011. (21 min 20s)
LQFD10	Legenda dos símbolos no corpo de relação da Casa da Qualidade.	Mateus Villela	SHORT, Michael. Lecture 4: Quality Function Deployment (QFD) and House of Quality. MIT OpenCourseWare, 2011. (21 min 50s)
LQFD11	Atribuição dos pesos dos requisitos do consumidor com os Stakeholders.	Mateus Villela	SHORT, Michael. Lecture 4: Quality Function Deployment (QFD) and House of Quality. MIT OpenCourseWare, 2011. (4 min 30s)
LQFD12	Preenchimento do 'Telhado' e da linha de direções por Stakeholders especialistas.	Mateus Villela	SHORT, Michael. Lecture 4: Quality Function Deployment (QFD) and House of Quality. MIT OpenCourseWare, 2011. (12 min 50s), link 2 (15 min 10s)
LQFD13	Preenchimento do Corpo de relações com atribuição dos símbolos pelos Stakeholders.	Mateus Villela	SHORT, Michael. Lecture 4: Quality Function Deployment (QFD) and House of Quality. MIT OpenCourseWare, 2011. (21 min 22s), link 2 (22 min 40s)
LQFD14	'Piso' da Casa da Qualidade com cálculo do fator Importância.	Mateus Villela	SHORT, Michael. Lecture 4: Quality Function Deployment (QFD) and House of Quality. MIT OpenCourseWare, 2011. (31 min 00s)
LQFD15	Representação percentual do fator Importância.	Mateus Villela	SHORT, Michael. Lecture 4: Quality Function Deployment (QFD) and House of Quality. MIT OpenCourseWare, 2011. (31 min 16s)
LQFD16	Benchmark à direita da Casa da Qualidade preenchido pelos stakeholders.	Mateus Villela	SHORT, Michael. Lecture 4: Quality Function Deployment (QFD) and House of Quality. MIT OpenCourseWare, 2011. (34 min 48s)

Autor: Mateus

Data	Versão	Descrição	Autor	Revisor
04/05/2025	0.1	(#D04) Criação da página das listas de verificação.	Ana Borges	Gabriela
05/07/2025	1.0	(#D04) Adição das legendas das tabelas e seus autores. Ajuste de hiperlinks na referencia dos vídeos do QFD	Luiz	Mateus