A engenharia de requisitos sempre foi uma área importante da construção de um software. Construir bem uma aplicação começa por saber o problema que estamos tentando corrigir e se vale realmente a pena construir ele.
Qualquer pessoa com alguma experiência com software já percebeu que o problema da lentidão não é um problema causado unicamente pelos engenheiros. Os principais responsáveis costuman ser especificações mal feitas, foco em falso problemas ou em correção/automação de fluxos que ninguém se interessa. A Engenharia de Requisitos vem dar foco nestas questões e discutir estes problemas antes que qualquer desenvolvedor possa encostar no código. Ela vai te ajudar a responder por que fazer algo, o que deve ser feito e para quem. As fases da engenharia de requisitos são:
1. Estudo de viabilidade
No estudo de viabilidade a gente quer saber se o software ou o recurso que estamos trabalhando vale ou não a pena ser construído. Isto passa por estudar se o que estamos propondo realmente ajuda o usuário e a empresa a atingir seus objetivos.
Para isso precisamos saber qual é o problema real a ser atacado. Ir a fundo em conversas e pesquisas para descobrir se o problema declarado pelo usuário é realmente o problema que ele quer que seja corrigido ou automatizado. Também calculamos os prazos e custos estimados. Por fim, calculamos também se não vale mais a pena pra empresa re-investir aquele dinheiro em outro lugar.
O software, para valer a pena ser construído, deve performar melhor financeiramente que um investimento de baixo ou médio risco, em termos de um software privado, e corrigir um problema real e não imaginário.
2. Elicitação de requisitos
Tendo definido que vale a pena construir o software, o próximo passo é ir mais a fundo e descobrir quais são os requisitos necessários para se fazer aquela aplicação existir. Para isto, precisamos saber quem são os usuários, quais são os fluxos esperados por estes e seus padrões esperados de qualidade.
Para quem já foi um pouco mais a fundo na Engenharia de Requisitos, é aqui que começamos a discutir requisitos funcionais e não-funcionais, termos já conhecidos por não serem bons para explicitar o que realmente queremos, mas que são os usuais de mercado.
Funcionais: são os requisitos que implementam a funcionalidade esperada pelo usuário. Como cadastrar um usuário; fazer uma compra; ver o status de algum item;
Não-funcionais: são requisitos que não implementam funcionalidades esperadas pelo usuário, mas são responsáveis por qualidade, segurança, performance ou por fazer a aplicação estar dentro de alguma lei ou regulação
Com essas definições, começamos a responder mais sobre em que contexto o software será inserido, quem serão esses usuários, o que ele deve fazer para sanar as necessidades tanto funcionais como as não funcionais.
Para ajudar a responder estas coisas, temos ferramentas como: criação de personas representando potenciais usuários; entrevistas; questionários; jornada do usuário; criação de protótipos; brainstorm. A escolha das ferramentas dependerá do time e do produto a ser desenvolvido.
3. Especificação de requisitos
Com os requisitos já elicitados, o próximo passo é especificar eles de modo a descrever os comportamentos e restrições esperadas para o software em si.
Nesta etapa estamos falando da criação de Casos de Uso, História de Usuário, Regra de Negócio, Critério de Aceitação e escrever os Requisitos não-funcionais. Cada um desses documentos ajudam a entender como algo vai ser implementado. Num mundo onde usamos cada vez mais ferramentas de edição de código assistidas por LLM, esses documentos ajudam a ferramenta a calcular melhor o caminho a ser seguido. Sendo que cada um desses documentos respondem a diferentes perguntas.
Caso de uso: como o usuário interage com o sistema passo-a-passo;
História de usuário: quem quer cada funcionalidade, o motivo e o que em detalhes;
Regra de negócio: qual diretriz de negócio deve ser seguida;
Critério de aceitação: define se uma funcionalidade foi implementada corretamente;
Requisitos não-funcionais: quais são as retrições legais, de qualidade, de segurança e de performance o app deve seguir.
Outras etapas e conclusões
As próximas etapas da Engenharia de Requisitos são a validação e priorização dos requisitos e a etapa de gerenciamento dos requisitos. Não entrarei nessas etapas hoje.
Das etapas já faladas acima, todas já eram importantes dentro do sistema pré-LLM de construção de software. As etapas buscavam mitigar erros e evitar que construamos um software que não resolve um problema real dos nossos usuários. Contudo, com ferramentas como Claude Code e Codex, elas se tornam ainda mais relevantes. Escrever código virou um processo automatizado e ter boas definições separam o sucesso da falha.