Engenharia de Requisitos

Pular o entendimento do contexto gera retrabalho quase sempre, mesmo quando o pedido parece claro e a solução parece simples. Antes do erro aparecer, a decisão já foi tomada sem conhecer o cenário real onde o sistema vai funcionar. Quase sempre o retrabalho não começa no erro em si.Ele começa antes, quando o contexto ainda […]

Necessidade, objetivo e requisito costumam aparecer misturados nas primeiras conversas de um projeto. Muitas vezes, são usados como se significassem a mesma coisa, mesmo quando estão falando de níveis diferentes do problema. Mas elas não são a mesma coisa. E essa confusão costuma aparecer logo no começo, quando alguém tenta explicar um problema ainda meio

Quando alguém pede um sistema, quase sempre já chega com uma ideia pronta.Uma tela, um botão, um fluxo que “resolveria tudo”. Nos últimos tempos, essa ideia tem vindo com outro nome: IA. Não é raro ouvir que o sistema precisa “ter IA”, mesmo quando ninguém consegue explicar exatamente o que ela vai fazer ali. A

Em muitos projetos, a análise de requisitos começa já atrasada.Não porque alguém fez algo errado, mas porque ela foi confundida com outra coisa. Às vezes ela vira uma reunião rápida, às vezes um documento preenchido às pressas, às vezes um conjunto de telas desenhadas antes mesmo de entender o problema. Mas análise de requisitos não

A primeira vez que alguém me pediu um sistema, não pediu um sistema. Pediu algo que resolvesse um incômodo que ele já estava carregando há um tempo. Ele falava da tela, das funções, do que “precisava ter”.Mas, conforme a conversa avançava, ficava claro que o problema não estava ali. Estava no processo, no jeito como