O que Realmente Aprendemos: Nossas Lições na Engenharia de Requisitos¶
Desenvolver o Portal Entre Amigos foi muito além de entregar código ou preencher tabelas para cumprir o cronograma acadêmico. Foi um choque de realidade sobre o lado humano e prático do desenvolvimento de software.
Deixando o jargão puramente acadêmico de lado, aqui está o que a nossa equipe de fato internalizou, aprendeu e vai levar para a vida profissional:
1. A Real Importância de Requisitos¶
- Desejo é diferente de necessidade: No começo, é muito fácil se empolgar com ideias mirabolantes ou elementos visuais secundários. Aprendemos que o verdadeiro papel da Engenharia de Requisitos é escavar a dor real do usuário. A ONG precisava desesperadamente de controle rigoroso de estoque e integridade de saldos, e não de firulas estéticas.
- Alinhamento que poupa código: Descobrimos que um requisito bem declarado e estruturado não é perda de tempo; é economia de semanas de trabalho. Escrever histórias de usuário claras blindou o escopo do projeto e garantiu que o time estivesse construindo exatamente o que o negócio precisava.
2. Comunicação com o Cliente¶
- Falar a língua do usuário, não o "tecniquês": Lidar com stakeholders reais e não-técnicos foi nossa maior escola. De nada adianta falar sobre "arquitetura serverless", "APIs" ou "estados reativos" se o cliente só precisa ter certeza de que o feijão e o arroz doados foram computados corretamente. Aprendemos a traduzir engenharia complexa em valor perceptível.
- Empatia e transparência: Ouvir ativamente a rotina logística e as limitações operacionais da ONG nos ensinou a negociar o MVP com maturidade. Aprendemos a dizer "não" para excessos de escopo com respeito, construindo uma relação de confiança baseada em entregas reais e honestidade sobre os prazos.
3. Verificação e Validação¶
- V&V não é um checklist burocrático: No início da disciplina, o DoR (Definition of Ready) e o DoD (Definition of Done) pareciam apenas rituais chatos para ganhar nota. Na prática, aprendemos que eles são nossos melhores amigos para evitar o caos. Eles garantem que uma tarefa só avance se estiver madura e só seja dada como pronta se estiver de fato testada e funcional.
- O valor da discordância: Quando o cliente ou a própria equipe apontava uma falha em uma interface ou regra, aprendemos a abraçar esse feedback imediatamente. Cruzar a especificação declarativa com os protótipos visuais nos salvou de programar regras inconsistentes e mitigou brechas de segurança antes que virassem bugs em produção.
4. Adaptabilidade¶
- Nenhum framework sobrevive puro ao campo de batalha: A maior lição sobre metodologias foi entender que processos rígidos quebram. Tivemos que aprender a ter jogo de cintura para usar a estrutura da fase de Concepção do OpenUP no início do semestre e, logo em seguida, acelerar com os Ciclos RAD para prototipagem rápida. Adaptar o processo ao nosso contexto foi o que salvou a entrega do projeto.
Histórico de versão¶
| Versão | Data | Descrição | Autor(es) | Revisor(es) |
|---|---|---|---|---|
| 1.0 | 01/07/2026 | Criação do consolidado de Lições Aprendidas com a Disciplina | Artur Fernandes Galdino | Equipe |