Listas de Verificações
Introdução
A etapa de verificação tem papel fundamental no desenvolvimento de um projeto, pois consiste na análise dos artefatos produzidos para assegurar que estejam em conformidade com os requisitos previamente definidos. Nesse contexto, o presente artefato tem como objetivo apresentar o planejamento destinado à verificação de cada um dos artefatos elaborados na quarta fase do projeto do grupo 7 (NFR, Histórias de Usuário e Backlog).
Lista de Verificação - NFR Framework
Tabela 1: Checklist de NFR Framework para o grupo 7
| ID | Descrição | Autor(es) | Referências |
|---|---|---|---|
| 1 | O modelo representa os Requisitos Não-Funcionais (RNFs) utilizando o NFR Framework conforme proposto por Chung et al. (2000)? [1] | Luan Vinícius, Miquéias Ezequiel | Ver Imagem |
| 2 | O NFR Framework é utilizado para apoiar a análise e implementação de soluções personalizadas, considerando as características do domínio e do sistema? [1] | Luan Vinícius, Samuel Felipe, Miquéias Ezequiel | Ver Imagem |
| 3 | A análise considera características específicas do sistema (como Requisitos Funcionais, prioridades, carga de trabalho e alternativas de desenvolvimento) para a modelagem dos RNFs? [2] | Samuel Felipe, Nayra Silva, Rivadalvio Joaquim | Ver Imagem |
| 4 | O NFR Framework utiliza o conceito de softgoal (um objetivo que não possui uma clara definição nem critérios de satisfação precisos) para representar os RNFs? [1] | Luan Vinícius, Samuel Felipe, Miquéias Ezequiel | Ver Imagem |
| 5 | Os catálogos são utilizados para organizar o conhecimento sobre RNFs específicos, suas interdependências, trade-offs e alternativas de desenvolvimento? [1] | Luan Vinícius, Samuel Felipe, Miquéias Ezequiel | Ver Imagem |
| 6 | Os softgoals e seus inter-relacionamentos são representados em um Grafo de Interdependência de Softgoals (SIG)? [1] | Luan Vinícius, Samuel Felipe, Miquéias Ezequiel | Ver Imagem |
| 7 | O SIG registra as decisões de desenvolvimento, justificativas e interdependências entre os softgoals de forma gráfica? [2] | Luan Vinícius, Samuel Felipe, Miquéias Ezequiel | Ver Imagem |
| 8 | O modelo utiliza os três tipos de softgoals: Softgoals NFR, Softgoals de Operacionalização e Softgoals de Afirmação? [2] | Luan Vinícius, João Pedro, Samuel Felipe, Heyttor Augusto, Miquéias Ezequiel | Ver Imagem |
| 9 | Os Softgoals NFR representam requisitos não funcionais abstratos? [3] | Heyttor Augusto, João Pedro | Ver Imagem |
| 10 | Os Softgoals de Operacionalização apresentam soluções ou alternativas técnicas para satisfazer os Softgoals NFR? [2] | Heyttor Augusto, João Pedro | Ver Imagem |
| 11 | Os Softgoals de Afirmação são utilizados para justificar decisões, apoiar ou negar o uso de outros softgoals? [2] | Heyttor Augusto, João Pedro | Ver Imagem |
| 12 | As interdependências entre softgoals são representadas através de refinamentos (decomposição) e contribuições? [4] | Luan Vinícius, Heyttor Augusto, Miquéias Ezequiel | Ver Imagem |
| 13 | As decomposições de softgoals refinam/transformam as softgoals em outras menores? [4] | Heyttor Augusto | Ver Imagem |
| 14 | O modelo especifica os tipos de contribuição (ex: MAKE, BREAK, HELP, HURT, AND, OR, SOME, etc.) para avaliar os impactos entre RNFs? [5] | Luan Vinícius, João Pedro, Miquéias Ezequiel | Ver Imagem |
| 15 | O Framework possui um procedimento de avaliação qualitativa para determinar o grau de satisfação (status) dos softgoals? [6] | Luan Vinícius, Samuel Felipe, Heyttor Augusto, Miquéias Ezequiel | Ver Imagem |
| 16 | O modelo aplica rótulos de avaliação (ex: Satisfeito, Negado, Conflitante, Indeterminado) aos softgoals do SIG? [6] | Luan Vinícius, João Pedro, Miquéias Ezequiel | Ver Imagem |
| 17 | A representação gráfica dos softgoals segue o padrão (NFR: nuvem fina, Operacionalização: nuvem grossa, Afirmação: nuvem tracejada)? [2] | Heyttor Augusto | Ver Imagem |
| 18 | A representação gráfica das interdependências segue o padrão (Decomposição: seta sólida, Contribuição: seta sólida com AND ou OR)? [7] | Heyttor Augusto | Ver Imagem 1 Ver Imagem 2 |
| 19 | O grafo (SIG) possui uma legenda clara explicando os símbolos utilizados? [8] | Heyttor Augusto | Ver Imagem |
Lista de Verificação - Histórias de Usuário
Tabela 2: Checklist de Histórias de Usuário para o grupo 7
| ID | Descrição | Autor(es) | Referências |
|---|---|---|---|
| 1 | A história de usuário é escrita na perspectiva do usuário (Quem), descrevendo a funcionalidade desejada (O quê) e o motivo (Porquê/Valor)? [9] | Luan Vinícius, João Pedro, Samuel Felipe, Miquéias Ezequiel | Ver Imagem |
| 2 | Cada história de usuário entrega valor de negócio perceptível ao cliente/usuário? [9] | Luan Vinícius, João Pedro | Ver Imagem |
| 3 | As histórias focam em "O que" a funcionalidade deve fazer, e não em "Como" ela deve ser implementada? [10] | Samuel Felipe, Heyttor Augusto | Ver Imagem |
| 4 | Cada história é independente e pode ser desenvolvida e estimada separadamente? [9] | Luan Vinícius | Ver Imagem |
| 5 | As histórias são pequenas o suficiente para serem implementadas em um ciclo curto (ex: Sprint) e, se forem muito grandes (Épicos), elas são divididas? [10] | João Pedro, Samuel Felipe, Heyttor Augusto | Ver Imagem |
| 6 | As histórias de usuário são organizadas ou agrupadas e possuem rastreabilidade? [11] | Samuel Felipe, Heyttor Augusto, Miquéias Ezequiel | Ver Imagem |
| 7 | Cada história de usuário está associada a critérios de aceitação claros, definidos pelo cliente e focados na funcionalidade? [12] | Luan Vinícius, Heyttor Augusto, Miquéias Ezequiel | Ver Imagem |
| 8 | Há uma preocupação em complementar as histórias de usuário para cobrir Requisitos Não-Funcionais? [13] | Miquéias Ezequiel, Nayra Silva | Ver Imagem |
| 9 | As histórias de usuários e os critérios de aceitação são a principal forma de especificar requisitos no projeto? [14] | Luan Vinícius, Rivadalvio Joaquim | Ver Imagem |
| 10 | As histórias de usuários são priorizadas individualmente (ex: por valor ou risco)? [11] | Luan Vinícius | Ver Imagem |
Lista de Verificação - Backlog
Tabela 3: Checklist de Backlog para o grupo 7
| ID | Descrição | Autor(es) | Referências |
|---|---|---|---|
| 1 | Existe um Product Backlog (criado e mantido pelo Product Owner) que contém a lista de todas as funcionalidades e requisitos desejados para o produto? [15] | Luan Vinícius, Samuel Felipe, Miquéias Ezequiel | Ver Imagem |
| 2 | Os itens do Product Backlog estão priorizados, com os itens de maior valor de negócio para o cliente no topo? [12] | Luan Vinícius, João Pedro, Samuel Felipe, Heyttor Augusto | Ver Imagem |
| 3 | Foi utilizada alguma técnica explícita de priorização (ex: MoSCoW, RICE) para ordenar o backlog? [16] | Heyttor Augusto | Ver Imagem |
| 4 | O backlog é um artefato vivo, sendo permitido adicionar/atualizar itens e sendo refinado e re-priorizado regularmente? [15] | Luan Vinícius, João Pedro, Miquéias Ezequiel | Ver Imagem |
| 5 | Os itens do Product Backlog são majoritariamente especificados como Histórias de Usuário? [10] | Samuel Felipe, Miquéias Ezequiel | Ver Imagem |
| 6 | Os itens do backlog (especialmente os mais prioritários) estão suficientemente detalhados, de tamanho adequado e são estimáveis pela equipe? [9] | João Pedro, Heyttor Augusto | Ver Imagem |
| 7 | O Product Backlog é visível e acessível a todos os envolvidos no projeto? [17] | João Pedro | Ver Imagem |
| 8 | O Product Backlog reflete o valor de negócio e serve como a única fonte de trabalho para o planejamento das Sprints (Sprint Backlog)? [18] | Luan Vinícius, Samuel Felipe | Ver Imagem |
| 9 | Os itens do backlog são classificados ou categorizados (ex: funcional, não-funcional, status)? [10] | Samuel Felipe | Ver Imagem |
Lista de Verificação da Plataforma Aprender Etapa 4 - Geral
Tabela 4: Checklist do professor para o grupo 7
| ID | Item de Verificação | Cumpriu? |
|---|---|---|
| 1 | As Histórias de Usuário? | |
| 2 | O “quem”, “o que” e o “por que” estão definidos na história de usuário? | |
| 3 | A validação das histórias de usuário de modo presencial com o usuário? | |
| 4 | A gravação da validação das histórias de usuário? | |
| 5 | Critério de aceitação para cada história possui? | |
| 6 | A validação dos critérios de aceitação das histórias de usuário de modo presencial com o usuário? | |
| 7 | A gravação da validação dos critérios de aceitação das histórias de usuário? | |
| 8 | A referência bibliográfica do modelo/estrutura da Histórias de Usuário? | |
| 9 | As Histórias de Usuário são rastreáveis a sua origem? | |
| 10 | O cartão de especificação do RNF | |
| 11 | Os softgoals condizem com o contexto? | |
| 14 | Os impactos foram corretamente propagados? | |
| 15 | Possui um tópico de agradecimento informando o uso de Inteligência Artificial (IA) Generativa no documento dos Léxicos1? | |
| 16 | Possui um tópico de agradecimento informando o uso de Inteligência Artificial (IA) Generativa no documento dos Cenários1? | |
| 17 | Os impactos foram corretamente propagados? | |
| 18 | possui um tópico de agradecimento informando o uso de Inteligência Artificial (IA) Generativa no documento da Especificação Suplementar? | |
| 19 | A equipe deve elaborar itens de verificação do conteúdo da disciplina dessa etapa com referência bibliográfica da fonte, foto do texto da referência e autor (História de Usuário, Backlog, Critério de Aceitação e NFR Framework) |
Referências Bibliográficas
1. SILVA, Reinaldo Antônio da. NFR4ES: um Catálogo de Requisitos Não-Funcionais para Sistemas Embarcados. 2019. Tese (Doutorado) – Universidade Federal de Pernambuco, Recife, 2019. Cap. 2, p. 30.
2. SILVA, Reinaldo Antônio da. NFR4ES: um Catálogo de Requisitos Não-Funcionais para Sistemas Embarcados. 2019. Tese (Doutorado) – Universidade Federal de Pernambuco, Recife, 2019. Cap. 2, p. 31.
3. Serrano milene, Requisitos - aula 17,UNB,Disponível em:https://aprender3.unb.br/pluginfile.php/3210673/mod_resource/content/1/Requisitos%20-%20Aula%20019a.pdf.
4. SILVA, Reinaldo Antônio da. NFR4ES: um Catálogo de Requisitos Não-Funcionais para Sistemas Embarcados. 2019. Tese (Doutorado) – Universidade Federal de Pernambuco, Recife, 2019. Cap. 2, p. 32.
5. SILVA, Reinaldo Antônio da. NFR4ES: um Catálogo de Requisitos Não-Funcionais para Sistemas Embarcados. 2019. Tese (Doutorado) – Universidade Federal de Pernambuco, Recife, 2019. Cap. 2, p. 34-35.
6. SILVA, Reinaldo Antônio da. NFR4ES: um Catálogo de Requisitos Não-Funcionais para Sistemas Embarcados. 2019. Tese (Doutorado) – Universidade Federal de Pernambuco, Recife, 2019. Cap. 2, p. 38.
7. SILVA, Reinaldo Antônio da. NFR4ES: um Catálogo de Requisitos Não-Funcionais para Sistemas Embarcados. 2019. Tese (Doutorado) – Universidade Federal de Pernambuco, Recife, 2019. Cap. 2, p. 33.
8. SILVA, Reinaldo Antônio da. NFR4ES: um Catálogo de Requisitos Não-Funcionais para Sistemas Embarcados. 2019. Tese (Doutorado) – Universidade Federal de Pernambuco, Recife, 2019. Cap. 2, p. 36.
9. PRESSMAN, Roger S. Desenvolvimento Ágil. In: ______. Engenharia de Software: uma abordagem profissional. 7. ed. Porto Alegre: AMGH, 2011. Cap. 3, p. 88.
10. Milene Serrano e Maurício Serrano, Requisitos - Aula 15.pdf, Requisitos, p. 10-12. Disponível em: https://aprender3.unb.br/pluginfile.php/3210661/mod_resource/content/1/Requisitos%20-%20Aula%2015a.pdf.
11. PRESSMAN, Roger S. Desenvolvimento Ágil. In: ______. Engenharia de Software: uma abordagem profissional. 7. ed. Porto Alegre: AMGH, 2011. Cap. 3, p. 89.
12. PRESSMAN, Roger S. Desenvolvimento Ágil. In: ______. Engenharia de Software: uma abordagem profissional. 7. ed. Porto Alegre: AMGH, 2011. Cap. 3, p. 90.
13. Milene Serrano e Maurício Serrano, Requisitos - Aula 15.pdf, Requisitos, p. 36. Disponível em: https://aprender3.unb.br/pluginfile.php/3210661/mod_resource/content/1/Requisitos%20-%20Aula%2015a.pdf.
14. PRESSMAN, Roger S. Desenvolvimento Ágil. In: ______. Engenharia de Software: uma abordagem profissional. 7. ed. Porto Alegre: AMGH, 2011. Cap. 3, p. 92.
15. PRESSMAN, Roger S. Desenvolvimento Ágil. In: ______. Engenharia de Software: uma abordagem profissional. 7. ed. Porto Alegre: AMGH, 2011. Cap. 3, p. 95.
16. Fonte: LuizTools, Product Backlog - Introdução, Youtube, 21/03/2020, Disponível em: https://youtu.be/z4ubaBwjCsU?si=wpgCIvgdgEw-SNh6 Acesso em: 04/10/2025 minutos 6:30
17. PRESSMAN, Roger S. Desenvolvimento Ágil. In: ______. Engenharia de Software: uma abordagem profissional. 7. ed. Porto Alegre: AMGH, 2011. Cap. 3, p. 91.
18. PRESSMAN, Roger S. Desenvolvimento Ágil. In: ______. Engenharia de Software: uma abordagem profissional. 7. ed. Porto Alegre: AMGH, 2011. Cap. 3, p. 96.
Versionamento
| Versão | Data | Autor | Descrição | Revisor |
|---|---|---|---|---|
1.0 |
20/10/2025 | Luan Vinícius | Abertura da documentação | |
1.1 |
22/10/2025 | Luan Vinícius | Adição das checklists |