APRENDER. PRATICAR. EVOLUIR.Conceito e mecanismo
A gestão de requisitos acompanha o trabalho de arquitetura de forma contínua. Um requisito deve ter significado compreendido, origem, responsável e forma de verificar satisfação. Liga-o às decisões e aos elementos que o realizam. Quando surge informação nova, avalia impacto no que já foi acordado; não basta editar uma frase num documento. Requisitos funcionais e de qualidade podem entrar em tensão. Por exemplo, diminuir o tempo de resposta por cache pode introduzir desatualização incompatível com uma decisão de negócio. Explicita a tolerância e as condições antes de escolher tecnologia. A aprovação de um requisito não elimina a necessidade de demonstrar que foi implementado.
Aplicação guiada
Num caso fictício, o negócio altera a perda máxima aceitável de dados de quinze para cinco minutos. Identifica decisões de replicação, contratos, testes e procedimentos afetados; confirma viabilidade e custo com os responsáveis. Atualiza a baseline autorizada e comunica a alteração às equipas dependentes. Distingue RPO, relacionado com perda de dados no tempo, de RTO, relacionado com restabelecimento do serviço. Uma demonstração de recuperação rápida não prova automaticamente o novo RPO. Mantém também requisitos que foram rejeitados ou substituídos com a respetiva razão, para evitar que reapareçam sem contexto. A rastreabilidade permite perguntar o que muda, quem precisa de decidir e que evidência será necessária para aceitar a solução.
Recuperação em oito minutos não demonstra perda máxima de cinco minutos.
Armadilhas comuns
Requisito sem condição; mudança local sem impacto; rastreabilidade como mera numeração.
Tópicos relacionados: Contexto, mandato e valor · Stakeholders, conflitos e vistas · Visão, âmbito e viabilidade
Liga necessidade, decisão, implementação e aceitação.
Referência: Practitioner competency-to-role mapping · OGEA-102; TOGAF Standard, 10th Edition