Grupo 3
Lista de verificação historias de usuário (Revisadas)
Tabela 1: Checklist preenchido - Histórias de Usuário do grupo 3
*
| ID | Item de Verificação | Cumpriu? |
|---|---|---|
| 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] | Sim |
| 2 | Cada história de usuário entrega valor de negócio perceptível ao cliente/usuário? [9] | Sim |
| 3 | As histórias focam em "O que" a funcionalidade deve fazer, e não em "Como" ela deve ser implementada? [10] | Sim |
| 4 | Cada história é independente e pode ser desenvolvida e estimada separadamente? [9] | Sim |
| 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] | Sim |
| 6 | As histórias de usuário são organizadas ou agrupadas e possuem rastreabilidade? [11] | Sim |
| 7 | Cada história de usuário está associada a critérios de aceitação claros, definidos pelo cliente e focados na funcionalidade? [12] | Sim |
| 8 | Há uma preocupação em complementar as histórias de usuário para cobrir Requisitos Não-Funcionais? [13] | Não |
| 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] | Sim |
| 10 | As histórias de usuários são priorizadas individualmente (ex: por valor ou risco)? [11] | Sim |
| 11 | As hisrórias de usuário foram validadas com usuários? [12] | Sim |
Fonte: Heyttor Augusto |
Lista de Verificação - Backlog
Tabela 1: Checklist preenchido - Backlog do grupo 3
| ID | Item de Verificação | Cumpriu? |
|---|---|---|
| 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] | Sim |
| 2 | Os itens do Product Backlog estão priorizados, com os itens de maior valor de negócio para o cliente no topo? [12] | Não |
| 3 | Foi utilizada alguma técnica explícita de priorização (ex: MoSCoW, RICE) para ordenar o backlog? [16] | Sim |
| 4 | O backlog é um artefato vivo, sendo permitido adicionar/atualizar itens e sendo refinado e re-priorizado regularmente? [15] | Sim |
| 5 | Os itens do Product Backlog são majoritariamente especificados como Histórias de Usuário? [10] | Sim |
| 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] | Sim |
| 7 | O Product Backlog é visível e acessível a todos os envolvidos no projeto? [17] | Sim |
| 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] | Sim |
| 9 | Os itens do backlog são classificados ou categorizados (ex: funcional, não-funcional, status)? [10] | Não |
Fonte: Samuel Felipe
Lista de Verificação - NFR Framework
Tabela 1: Checklist preenchido - NFR Framework do grupo 7
| ID | Item de Verificação | Cumpriu? |
|---|---|---|
| 1 | O modelo representa os Requisitos Não-Funcionais (RNFs) utilizando o NFR Framework conforme proposto por Chung et al. (2000)? [1] | Sim |
| 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] | Sim |
| 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] | Sim |
| 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] | Sim |
| 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] | Sim |
| 6 | Os softgoals e seus inter-relacionamentos são representados em um Grafo de Interdependência de Softgoals (SIG)? [1] | Sim |
| 7 | O SIG registra as decisões de desenvolvimento, justificativas e interdependências entre os softgoals de forma gráfica? [2] | Sim |
| 8 | O modelo utiliza os três tipos de softgoals: Softgoals NFR, Softgoals de Operacionalização e Softgoals de Afirmação? [2] | Sim |
| 9 | Os Softgoals NFR representam requisitos não funcionais abstratos? [3] | Sim |
| 10 | Os Softgoals de Operacionalização apresentam soluções ou alternativas técnicas para satisfazer os Softgoals NFR? [2] | Sim |
| 11 | Os Softgoals de Afirmação são utilizados para justificar decisões, apoiar ou negar o uso de outros softgoals? [2] | Sim |
| 12 | As interdependências entre softgoals são representadas através de refinamentos (decomposição) e contribuições? [4] | Sim |
| 13 | As decomposições de softgoals refinam/transformam as softgoals em outras menores? [4] | Não |
| 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] | Sim |
| 15 | O Framework possui um procedimento de avaliação qualitativa para determinar o grau de satisfação (status) dos softgoals? [6] | Sim |
| 16 | O modelo aplica rótulos de avaliação (ex: Satisfeito, Negado, Conflitante, Indeterminado) aos softgoals do SIG? [6] | Não |
| 17 | A representação gráfica dos softgoals segue o padrão (NFR: nuvem fina, Operacionalização: nuvem grossa, Afirmação: nuvem tracejada)? [2] | Sim |
| 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] | Sim |
| 19 | O grafo (SIG) possui uma legenda clara explicando os símbolos utilizados? [8] | Não |
Fonte: joão Pedro
Versionamento
| Versão | Data | Autor | Descrição | Revisor |
|---|---|---|---|---|
1.0 |
12/11/2025 | Luan Vinícius | Abertura do documento | |
2.0 |
11 e 12/11/2025 | Heyttor Augusto | adição da lista de verificação HU atualizada | -- |
3.0 |
12/11/2025 | Samuel Felipe | Lista Backlog | |
4.0 |
12/11/2025 | joão Pedro | Adição NFR | Rivadalvio Joaquim |