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 recomendada pelo professor
| Nº | Descrição | Autor | Referência |
|---|---|---|---|
| 1 | A Especificação do Perfil do usuário possui informação de: idade (criança, jovem, adulto, terceira idade etc.); experiência (leigo/novato, especialista); atitudes (tecnófilos, tecnófobos); e tarefas primárias (compra, venda). | André Barros de Sales |  |
| 2 | Um cronograma (data e horário) e local para realização da elicitação de requisitos com o cliente e/ou persona do projeto. | André Barros de Sales | |
| 3 | No mínimo quatro técnicas de elicitação foram utilizadas (quanto mais, melhor)? Técnica(s): Análise de Documentos; Observação; Entrevista; Análise de protocolo; Prototipação; Brainstorming; Entrevista em grupo; Storytelling; Análise de discurso; Introspecção; Etnografia; JAD; Questionários; Reuniões; Grupo Focal; Workshops; Outra técnica? | André Barros de Sales | |
| 4 | A participação do cliente e/ou persona na elicitação de requisitos. | André Barros de Sales | |
| 5 | A gravação e o(s) registro(s) da elicitação de requisitos (pré-rastreabilidade). | André Barros de Sales | |
| 6 | Cada requisito possui ao menos uma fonte de origem? | André Barros de Sales | |
| 7 | São apresentados requisitos implementados e não implementados para a aplicação? | André Barros de Sales | |
| 8 | Está sendo apresentado como requisito pode ser verificado na aplicação (critério de aceitação). | André Barros de Sales | |
| 9 | Um cronograma (data e horário) e local para realização da priorização de requisitos com o cliente e/ou persona do projeto. | André Barros de Sales | |
| 10 | No mínimo quatro técnicas de priorização (quanto mais, melhor)? MoSCoW; 100 $; First Thing First; ROI; QFD; TQM; Outra técnica? (MoSCoW/100 $ só após uso de outras duas técnicas.) | André Barros de Sales | |
| 11 | A participação do cliente e/ou persona no processo de priorização. | André Barros de Sales |  |
| 12 | A gravação e o(s) registro(s) da atividade de priorização de requisitos. Importante: cada integrante deve elaborar ao menos um item de conteúdo da disciplina com referência bibliográfica e foto do texto da referência. | André Barros de Sales | |
Tabela 2 - Verificação 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. |
Tabela 3 - Verificação 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. |
Tabela 4 - Verificação 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. |
Tabela 5 - Verificação 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. |
Tabela 6 - Verificação 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. |
Tabela 7 - Verificação 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. |
Tabela 8 - Verificação 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 |
Tabela 9 - Verificação 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 |
Tabela 10 - Verificação 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. Disponível em: YouTube. Acesso em: 02 maio 2025. (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. Disponível em: YouTube. Acesso em: 02 maio 2025. (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. Disponível em: YouTube. Acesso em: 02 maio 2025. (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. Disponível em: YouTube. Acesso em: 02 maio 2025. (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. Disponível em: YouTube. Acesso em: 02 maio 2025. (9 min 00s) |
| LQFD6 | Possui uma linha na parte superior da Casa da Qualidade associando os requisitos técnicos com a direção desejada da melhoria. | Mateus Villela | SHORT, Michael. Lecture 4: Quality Function Deployment (QFD) and House of Quality. MIT OpenCourseWare, 2011. Disponível em: YouTube. Acesso em: 02 maio 2025. (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. Disponível em: YouTube. Acesso em: 02 maio 2025. (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. Disponível em: YouTube. Acesso em: 02 maio 2025. (14 min 52s) |
| LQFD9 | Há a delimitação do corpo de relações da Casa da Qualidade entre os requisitos técnicos e os requisitos dos consumidores. | Mateus Villela | SHORT, Michael. Lecture 4: Quality Function Deployment (QFD) and House of Quality. MIT OpenCourseWare, 2011. Disponível em: YouTube. Acesso em: 02 maio 2025. (21 min 20s) |
| LQFD10 | Contém a legenda dos símbolos utilizados no corpo de relação da Casa da Qualidade, em que associa o valor numérico a seus símbolos (forte, médio, fraco ou nulo). | Mateus Villela | SHORT, Michael. Lecture 4: Quality Function Deployment (QFD) and House of Quality. MIT OpenCourseWare, 2011. Disponível em: YouTube. Acesso em: 02 maio 2025. (21 min 50s) |
| LQFD11 | A atribuição dos pesos dos requisitos do consumidor foi realizada em conjunto com os Stakeholders: consumidores/clientes. | Mateus Villela | SHORT, Michael. Lecture 4: Quality Function Deployment (QFD) and House of Quality. MIT OpenCourseWare, 2011. Disponível em: YouTube. Acesso em: 02 maio 2025. (4 min 30s) |
| LQFD12 | O preenchimento do 'Telhado' e da linha de direções do aprimoramento dos requisitos técnicos foi executado por Stakeholders especialistas. | Mateus Villela | SHORT, Michael. Lecture 4: Quality Function Deployment (QFD) and House of Quality. MIT OpenCourseWare, 2011. Disponível em: YouTube. Acesso em: 02 maio 2025. (12 min 50s e 15 min 10s) |
| LQFD13 | O preenchimento do Corpo de relações da Casa da Qualidade foi executado por Stakeholders especialistas com a atribuição dos símbolos. | Mateus Villela | SHORT, Michael. Lecture 4: Quality Function Deployment (QFD) and House of Quality. MIT OpenCourseWare, 2011. Disponível em: YouTube. Acesso em: 02 maio 2025. (21 min 22s e 22 min 40s) |
| LQFD14 | No 'piso' (parte inferior) da Casa da Qualidade, contém os valores obtidos na linha do fator Importância, associado ao cálculo da soma dos produtos entre o Corpo de relações e os pesos dos consumidores. | Mateus Villela | SHORT, Michael. Lecture 4: Quality Function Deployment (QFD) and House of Quality. MIT OpenCourseWare, 2011. Disponível em: YouTube. Acesso em: 02 maio 2025. (31 min 00s) |
| LQFD15 | Há a representação em termos de porcentagem (%) do fator Importância. | Mateus Villela | SHORT, Michael. Lecture 4: Quality Function Deployment (QFD) and House of Quality. MIT OpenCourseWare, 2011. Disponível em: YouTube. Acesso em: 02 maio 2025. (31 min 16s) |
| LQFD16 | Contém à direita da Casa da Qualidade o Benchmark (análise comparativa com produtos concorrentes) preenchidos pelos stakeholders. | Mateus Villela | SHORT, Michael. Lecture 4: Quality Function Deployment (QFD) and House of Quality. MIT OpenCourseWare, 2011. Disponível em: YouTube. Acesso em: 02 maio 2025. (34 min 48s) |
| 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 |