Consolidação de Requisitos, Feedbacks e Estratégia de Validação
1. Estratégia de Validação e Feedback Contínuo
Adotamos uma estratégia baseada em Pontos de Inflexão Estratégica. A validação concentrou-se na concepção, prototipagem de fluxos críticos de negócio e na entrega consolidada, garantindo que o tempo do cliente fosse utilizado para decisões estratégicas, enquanto a equipe mantinha autonomia técnica para o desenvolvimento operacional.
Os feedbacks recebidos durante as reuniões com stakeholders (clientes, professores e monitores) foram diretamente incorporados ao Backlog do Produto e à arquitetura do software, resultando em ajustes precisos no direcionamento da solução.
2. Tabela Consolidada de Feedbacks e Validações
A tabela abaixo registra todo o ciclo de vida da validação, diferenciando se a etapa avaliou o Problema, o Protótipo, um Requisito (Regra de Negócio) ou o Software Funcional.
| Data | US/RF Apresentado | Artefato Apresentado | Feedback do Stakeholder | Decisão | Ajuste Realizado | Status | Evidência (O que o registro comprova) |
|---|---|---|---|---|---|---|---|
| 12/04 | Visão Geral do Produto | Validação de Problema Proposta de Valor e Entendimento do Domínio |
O controle de horas voluntárias hoje é ineficiente e propenso a fraudes na ONG; um aplicativo centralizado será essencial. | O projeto tem forte aderência ao problema real e o escopo deve focar estritamente na gestão de presenças e vagas. | Escopo inicial delineado nos Épicos CP01, CP02 e CP03 no backlog. | ✅ Aprovado | Ata 01 e Vídeo - Entrevista, Elicitação e Descoberta junto ao cliente |
| 02/05 | RF02 (Cadastrar org) / US1.2 | Validação de Requisito Diagrama e Arquitetura de Acesso |
O cadastro aberto para organizações pode gerar riscos críticos de segurança e perfis falsos. | Restringir o cadastro direto; a aprovação definitiva da ONG será feita via painel de administração interno. | Inclusão do RF06 (Aprovar organização) no Backlog do Produto. | ✅ Aprovado | Ata 02 e Vídeo - Planejamento da Sprint e Alinhamento Técnico de Arquitetura |
| 02/05 | RF21 (Criar Vaga) / US2.1 | Validação de Protótipo Wireframes e Telas do Figma |
A humanização das vagas é importante; galerias de fotos nas oportunidades são vitais para engajar os estudantes. | Manter a funcionalidade de upload e exibição de imagens para as vagas, assumindo o custo de infraestrutura (S3). | Inclusão de suporte a Storage AWS S3 na pipeline de desenvolvimento. | ✅ Aprovado | Ata 02 e Vídeo - Planejamento da Sprint e Discussão de Protótipo |
| 02/05 | RF03 (Autenticar) / US1.3 | Validação de Requisito Fluxo e Protocolo de Segurança |
O modelo JWT é prático e simplifica a implementação mobile e backend, além de prover segurança suficiente. | Seguir com a implementação base de JWT para a autenticação de estudantes e organizações. | Adição do simplejwt nas bibliotecas backend. | ✅ Aprovado | Ata 02 e Vídeo - Planejamento da Sprint e Organização Interna |
| 19/05 | Todo o Backlog e MVP | Validação de Requisito Matriz ICE e MoSCoW |
O RF20 (Validar certificado) tem baixa urgência técnica para o MVP, enquanto o cadastro e login são prioridade crítica. | O RF20 foi rebaixado (ICE 120) para Sprints finais; os fluxos de CP01 foram puxados para o topo. | Atualização oficial do Backlog Priorizado e da Matriz Facilidade × Valor. | ✅ Aprovado | Ata 04 e Vídeo - Workshop de Priorização de Requisitos (MVP) |
| 19/05 | US1.1 a US1.7 | Validação de Requisito Métricas de Aceite e Qualidade |
A métrica de Definition of Done (DoD) precisa estar estritamente vinculada às RFs para rastrear entregas reais. | Adotar rastreabilidade exata de 1:1 entre RF e US no repositório e no Design do Figma. | Refatoração das issues no GitHub e atualização da Matriz de Rastreabilidade. | ✅ Aprovado | Ata 05 e Vídeo - Acompanhamento, Revisão de Sprints e Alinhamento Técnico |
| 02/06 | RF03 e Pipeline (DevOps) | Software Funcional Processo de Integração Contínua |
A ausência de um papel específico focado em estabilidade de servidor estava atrasando a homologação. | Criação formal do papel de "Infraestrutura/DevOps" dentro da equipe para desafogar os desenvolvedores backend. | Realocação ágil da equipe e documentação dos novos papéis. | ✅ Aprovado | Ata 07 e Vídeo - Acompanhamento, Revisão de Sprints e Alinhamento Técnico |
| 09/06 | RF04, RF05 (Painel Admin) | Software Funcional Código Frontend e Backend |
Problemas de hardware com um membro da equipe impactaram a integração do painel administrativo. | Aceitar o atraso parcial no painel web, remanejando tarefas para a próxima Sprint e fazendo pair programming. | Reorganização das issues no Kanban e estabelecimento de pareamento. | ⚠️ Aprovado c/ ressalvas | Ata 08 e Vídeo - Acompanhamento, Revisão de Sprints e Alinhamento Técnico |
| 16/06 | Rastreabilidade e GitPages | Validação de Processo Documentação e Rastreio |
As evidências de protótipo e rastreabilidade estão excelentes, porém o uso nominal do Scrum pode gerar cobranças irreais se os ritos não existirem. | Seguir exclusivamente com o Kanban XP, documentando as evidências de forma aderente à realidade do time. | N/A (Ajuste evitado) | ✅ Aprovado | Ata 09 e Vídeo - Revisão de Sprints e Alinhamento Técnico |
| 23/06 | Issues do MVP e DoD | Validação de Requisito Critérios de Aceite (DoD) |
Os critérios de aceite antigos não estão no padrão BDD esperado. Além disso, o prazo foi encurtado e o cliente desmarcou a reunião presencial de validação. | Refatorar os DoDs para o formato BDD/Gherkin. Usar formulário assíncrono para colher a validação do cliente que estava ausente. | Atualização em massa do formato dos Critérios de Aceite (DoD) nas Issues ativas. | ⚠️ Aprovado c/ ressalvas | Ata 10 e Vídeo - Revisão de Sprints e Adaptação de Escopo |
| 30/06 | Software Final (MVP) | Software Funcional Fluxos Principais da Aplicação |
Reta final para a entrega antecipada; o foco deve ser unicamente em fechar os Pull Requests cruciais (Must Have) e demonstrar o sistema. | Mutirão para o fechamento dos últimos PRs pendentes e agendamento da demonstração do software rodando para o cliente no dia seguinte. | Fechamento intensivo das issues restantes de desenvolvimento. | ✅ Aprovado | Ata 11 e Vídeo - Validação Funcional e Planejamento de Entrega |
| 01/07 | Sistema Completo (App Mobile + Backend) | Software Funcional Homologação e Entrega de Valor |
O aplicativo funciona bem na prática. Cadastrar ONGs e gerir frequências e certificados se mostrou intuitivo, com problemas mínimos e contornáveis. | O projeto atinge o critério de sucesso (DoD) da entrega final com o cliente. Mínimos ajustes de UI foram registrados como débito técnico pós-disciplina. | Entrega formal (MVP) e encerramento da fase principal do ciclo de vida. | ✅ Aprovado | Ata 12 e Vídeo - Validação Final com Cliente |
3. Impacto no Backlog e Qualidade
O processo de feedback gerou mutações constantes e saudáveis no artefato principal de requisitos (o Backlog do Produto):
- Priorização Atualizada (Ajuste Realizado): Requisitos como o RF20 (Validação via QRCode) tiveram suas notas reduzidas (ICE = 120) após feedbacks e discussões de priorização (MoSCoW), liberando esforço para os RFs mais críticos do MVP.
- Mapeamento 1:1 (Decisão de Processo): Comentários sobre a complexidade de validação geraram uma grande refatoração na forma de escrever requisitos: hoje, cada
RFmapeia diretamente para uma únicaUS, facilitando o rastreio na Matriz de Rastreabilidade. - Gestão de Risco: Não houve incidências severas que exigissem rollback do código-fonte; os feedbacks incidiram majoritariamente sobre priorização no Kanban e regras de negócio.