3.2. Requisitos e arquitetura
Requisitos dizem o que o sistema faz; arquitetura é o esqueleto que a construção vai seguir.
Resumo
- Requisitos mudam: cerca de 25% ao longo do projeto (~1% ao mês). Planeje para a mudança.
- Lidar com mudança: checklist de requisitos, controle de mudanças, custo explícito, desenvolvimento iterativo.
- Arquitetura: organização do programa, classes principais, dados, regras de negócio, UI, segurança, desempenho.
- Boa arquitetura explica por quê (alternativas rejeitadas) e define a estratégia de mudança.
- Gaste cerca de 10–20% do esforço e 20–30% do prazo em requisitos e arquitetura.
Perguntas-chave
responda de cabeça, depois abraO que fazer quando o cliente pede mudança no meio do projeto?
Registrar via controle de mudanças, estimar custo e prazo, e decidir de forma consciente; não aceitar em silêncio.
Cite itens que a arquitetura deve tratar.
Organização em subsistemas, classes principais, dados, regras de negócio, interface, recursos, segurança, desempenho, escalabilidade, erros, comprar ou construir.
Por que a arquitetura deve justificar decisões?
Para que quem vier depois entenda as alternativas descartadas e não desfaça uma decisão boa por desconhecer o motivo.
Exercícios de fixação
0/5 respondidas1.
Segundo dados citados no livro, os requisitos de um projeto típico mudam aproximadamente:
2.
O cliente pede uma nova tela no meio do sprint final. Qual reação segue o capítulo?
3.
Uma arquitetura descreve as classes principais, mas não diz por que escolheu um banco relacional em vez de arquivos. O que falta?
4.
Qual item é responsabilidade da arquitetura, e não da construção?
5.
Quanto do esforço o livro sugere investir em requisitos e arquitetura num projeto bem conduzido?