flowchart LR
A[Requisitos] --> B[Projeto]
B --> C[Codificação]
C --> D[Testes]
D --> E[Produção]
A -. custo x1 .-> A
style A fill:#d1e7dd,stroke:#0f5132
style B fill:#cfe2ff,stroke:#084298
style C fill:#fff3cd,stroke:#664d03
style D fill:#ffe5b4,stroke:#8a5a00
style E fill:#f8d7da,stroke:#842029
Módulo 05 — Análise de Requisitos: conceitos iniciais
Onde estamos. Nos módulos anteriores combinamos o que é fazer engenharia de software e como um processo se organiza em torno de especificar, projetar, validar e evoluir. Chegou a hora de mergulhar na primeira dessas frentes, a que sustenta todas as outras: entender o que o sistema precisa fazer antes de construí-lo. Quero que você chegue à aula convencido de que a maior parte dos fracassos de projeto começa aqui, muito antes da primeira linha de código.
Deixe-me abrir com uma pergunta desconfortável. Imagine que você recebeu a tarefa de construir um sistema e o cliente lhe disse apenas: “quero um sistema rápido e fácil de usar”. Você começaria a programar? Se a resposta for sim, este módulo existe para você. “Rápido” quanto? Responder em menos de um segundo, ou aguentar mil usuários simultâneos? “Fácil de usar” para quem, um operador treinado ou uma pessoa idosa que nunca tocou num computador? Essas duas frases inocentes escondem dezenas de decisões que, se não forem esclarecidas agora, voltarão como retrabalho, frustração e custo. Descobrir, esclarecer e registrar essas decisões é o trabalho da engenharia de requisitos, e é sobre ele que vamos conversar.
O que é um requisito, afinal
Antes de qualquer processo, precisamos combinar o vocabulário. Um requisito é uma declaração do que o sistema deve fazer ou de uma restrição sob a qual ele deve operar. Repare que essa definição tem duas metades igualmente importantes. A primeira metade é sobre funções: cadastrar um cliente, calcular um imposto, enviar uma notificação. A segunda metade é sobre qualidades e restrições: responder em determinado tempo, proteger dados sensíveis, funcionar em determinado navegador. Estudantes tendem a lembrar só da primeira metade, e é por isso que constroem sistemas que fazem tudo o que foi pedido e, ainda assim, são inaceitáveis por serem lentos, inseguros ou impossíveis de manter.
Sommerville chama a atenção para um detalhe que muda a forma como pensamos o trabalho: a própria palavra “requisito” é usada de maneira inconsistente na indústria. Às vezes ela designa uma frase abstrata e geral, do tipo “o sistema deve controlar o estoque”. Outras vezes designa uma especificação detalhada, formal, com todas as restrições explícitas. Essa ambiguidade não é acidental, ela reflete que existem níveis diferentes de requisito, escritos para leitores diferentes, e confundi-los é uma das primeiras fontes de mal-entendido num projeto.
ImportanteA ideia central que você deve carregar
Requisito não é apenas “o que o sistema faz”. É toda declaração sobre o que o sistema deve fazer, como deve se comportar, e sob quais restrições deve operar. Engenharia de requisitos é o conjunto de atividades sistemáticas de descobrir, analisar, documentar, validar e gerenciar essas declarações ao longo da vida do projeto. O objetivo não é escrever muito, é escrever o certo, sem ambiguidade, para que o time construa o sistema que o cliente realmente precisa.
Por que requisitos mal compreendidos custam tão caro
Aqui está o fato que, se você guardar apenas um deste módulo, já terá valido a pena: requisitos mal compreendidos são a maior fonte isolada de retrabalho em software. Não é o algoritmo errado, não é a linguagem inadequada. É o time construir, com competência técnica impecável, exatamente a coisa errada. Pressman e Sommerville, cada um a seu modo, insistem que os defeitos mais caros de um projeto são aqueles introduzidos na fase de requisitos, porque eles se propagam. Um requisito ambíguo contamina o projeto, que contamina o código, que contamina os testes. Quando o engano finalmente aparece, meio sistema já foi construído sobre ele.
E isso nos leva a um princípio que atravessa toda a engenharia de software: o custo de corrigir um erro cresce quanto mais tarde ele é descoberto. Um requisito mal entendido, se percebido durante a própria conversa com o cliente, custa uma frase para corrigir. O mesmo engano percebido durante o projeto custa remodelar. Percebido durante a codificação, custa reescrever. Percebido em produção, custa reescrever, mais o prejuízo do defeito em operação, mais a perda de confiança do cliente. A curva não é linear, ela é acentuada, e entendê-la muda a forma como você prioriza seu tempo.
O diagrama acima ordena as fases; a tabela a seguir traduz, em termos qualitativos, por que o mesmo erro fica progressivamente mais caro conforme desce por elas. Não decore números — a literatura reporta ordens de grandeza, mas o que importa para você é a forma da curva e sua razão de ser.
| Fase em que o erro é descoberto | Por que corrigir sai mais caro |
|---|---|
| Durante a elicitação | Basta reformular a conversa; nada foi construído sobre o engano. |
| Durante o projeto | É preciso refazer modelos e decisões de arquitetura já tomadas. |
| Durante a codificação | Reescreve-se código e possivelmente vários módulos acoplados. |
| Durante os testes | Refaz-se código e todos os testes que dependiam da premissa errada. |
| Em produção | Soma-se ao retrabalho o prejuízo operacional e o dano à confiança do cliente. |
NotaPor que a curva sobe tão rápido
A cada fase que passa, mais artefatos foram construídos assumindo o requisito errado como verdadeiro. Corrigir o requisito tarde significa desfazer, um a um, todos esses artefatos dependentes. Descobrir cedo é barato justamente porque quase nada ainda foi construído sobre a suposição equivocada.
Requisitos de usuário e requisitos de sistema
Vamos resolver agora aquela ambiguidade que mencionei sobre os níveis de requisito, porque ela organiza boa parte do trabalho. É útil distinguir dois níveis, e Sommerville faz essa separação de forma clara.
Os requisitos de usuário são declarações em linguagem natural, na linguagem do cliente, descrevendo o que o sistema deve oferecer e sob quais restrições. São escritos para serem lidos por pessoas que entendem do negócio, mas não necessariamente de tecnologia: gestores, usuários finais, patrocinadores do projeto. Eles são gerais de propósito, porque seu papel é comunicar intenção, não implementação.
Os requisitos de sistema são versões detalhadas e precisas desses mesmos desejos, escritos para quem vai projetar e construir. Eles decompõem cada requisito de usuário em declarações específicas sobre funções, entradas, saídas, dados e restrições. Onde o requisito de usuário diz “o sistema deve permitir consultar o saldo”, o requisito de sistema especifica quais dados entram, quais validações se aplicam, o que acontece quando a conta não existe e qual formato tem a resposta. Um é o desejo; o outro é o contrato técnico que torna o desejo construível e verificável.
| Aspecto | Requisito de usuário | Requisito de sistema |
|---|---|---|
| Leitor pretendido | Cliente, gestor, usuário final | Analista, projetista, desenvolvedor |
| Linguagem | Natural, do negócio | Precisa, técnica, detalhada |
| Nível de detalhe | Geral, descreve intenção | Específico, descreve comportamento e dados |
| Papel | Comunicar o que se deseja | Servir de base para projeto e verificação |
| Risco típico | Vago demais para construir | Detalhado demais para o cliente validar |
Perceba a tensão na última linha da tabela. Se você mostra ao cliente apenas requisitos de sistema, ele não consegue validar, porque estão técnicos demais. Se você entrega ao desenvolvedor apenas requisitos de usuário, ele não consegue construir sem preencher lacunas por conta própria — e cada lacuna preenchida por suposição é um risco. Por isso os dois níveis coexistem: um serve à validação com o cliente, o outro serve à construção pelo time.
Quem são os stakeholders e por que discordam
Nenhum sistema tem um único dono das necessidades. Chamamos de stakeholders — partes interessadas — todas as pessoas e grupos afetados pelo sistema ou que têm influência sobre seus requisitos. Num sistema hospitalar, por exemplo, são stakeholders os médicos, os enfermeiros, os pacientes, o setor administrativo, a área de tecnologia, os órgãos reguladores e quem paga a conta. E aqui está o ponto que iniciantes subestimam: essas visões conflitam, e não por má vontade.
Conflitam porque cada stakeholder olha o sistema a partir de seus próprios objetivos. O médico quer registrar informações da forma mais rápida possível durante o atendimento; o setor de auditoria quer campos obrigatórios e trilhas de controle que tornam o registro mais lento. O usuário quer uma tela simples; o gestor quer relatórios ricos que exigem coletar mais dados. Nenhum está errado sob sua própria perspectiva. O trabalho da engenharia de requisitos inclui descobrir esses conflitos, torná-los explícitos e negociar soluções, porque um conflito ignorado não desaparece — ele reaparece na entrega, quando um grupo rejeita o sistema que o outro aprovou.
flowchart TB
S1[Usuário final] --> R((Requisitos))
S2[Gestor] --> R
S3[Área de TI] --> R
S4[Órgão regulador] --> R
S5[Patrocinador] --> R
R --> N[Análise e negociação]
N --> D[Requisitos acordados]
style R fill:#fff3cd,stroke:#664d03
style N fill:#e2d9f3,stroke:#59359a
style D fill:#d1e7dd,stroke:#0f5132
Repare no diagrama que os requisitos não brotam prontos de uma única fonte; eles convergem de muitas vozes e só se tornam utilizáveis depois de passarem pela análise e pela negociação. Essa é uma das razões por que a comunicação, tema que atravessa toda a disciplina, é tão central: elicitar requisitos é, antes de tudo, uma atividade humana de escuta, tradução e mediação.
O processo de engenharia de requisitos
Agora que temos o vocabulário, quero mostrar como esse trabalho se organiza. A engenharia de requisitos não é um momento único no começo do projeto; é um processo com etapas que se realimentam. Sommerville as descreve em torno de quatro grandes atividades, às quais a gestão de mudanças dá continuidade ao longo de toda a vida do sistema.
A primeira etapa é a elicitação, também chamada de levantamento ou descoberta. Aqui trabalhamos com os stakeholders para entender o domínio, os serviços que o sistema deve prestar e as restrições. Não é um interrogatório passivo; envolve entrevistas, observação de como as pessoas trabalham hoje, análise de documentos e, muitas vezes, protótipos que ajudam o cliente a perceber o que realmente quer. As pessoas frequentemente não sabem articular suas necessidades até verem algo concreto, e boa elicitação leva isso em conta.
A segunda etapa é a análise. Aqui examinamos o que foi elicitado em busca de conflitos, sobreposições, omissões e inviabilidades. É o momento de perguntar se dois requisitos se contradizem, se algum é impossível dentro do orçamento, se falta alguma coisa que ninguém mencionou por parecer óbvia. É também aqui que negociamos as prioridades e resolvemos os conflitos entre stakeholders que discutimos há pouco.
A terceira etapa é a especificação e documentação. Traduzimos o que foi analisado em declarações claras e organizadas, nos dois níveis que estudamos, produzindo um registro que servirá de referência para todo o time. Documentar não é burocracia: é transformar entendimento efêmero, que vive na cabeça das pessoas, em conhecimento durável e compartilhável, que sobrevive à saída de um membro da equipe.
A quarta etapa é a validação, na qual verificamos se os requisitos documentados de fato correspondem ao que os stakeholders querem e se são consistentes, completos e realistas. Validar cedo é a forma mais barata de descobrir os erros que, como vimos, ficam exponencialmente mais caros com o tempo. E, envolvendo tudo isso, existe a gestão de mudanças, porque requisitos mudam — sempre mudam — e o processo precisa acolher essas mudanças de forma controlada, sem que cada alteração vire caos.
flowchart LR
E[Elicitação] --> A[Análise]
A --> S[Especificação e Documentação]
S --> V[Validação]
V -. requisitos incompletos ou conflitantes .-> E
G[Gestão de Mudanças] -. atravessa todo o ciclo .-> E
G -. .-> V
style E fill:#cfe2ff,stroke:#084298
style A fill:#e2d9f3,stroke:#59359a
style S fill:#d1e7dd,stroke:#0f5132
style V fill:#fff3cd,stroke:#664d03
style G fill:#f8d7da,stroke:#842029
Observe que as setas de retorno não são acidente de desenho. A validação frequentemente devolve o trabalho à elicitação, porque descobrir uma inconsistência revela que faltou perguntar algo. E a gestão de mudanças permeia todas as etapas, do começo ao fim. Requisitos não são um documento que se assina e se esquece; são um organismo vivo que acompanha o sistema enquanto ele existir.
Os problemas típicos que você vai encontrar
Se a engenharia de requisitos fosse fácil, não precisaríamos de um módulo sobre ela. Três problemas aparecem em praticamente todo projeto, e reconhecê-los é o primeiro passo para combatê-los.
O primeiro é a ambiguidade: uma declaração que pode ser interpretada de mais de uma maneira. A linguagem natural, que é a matéria-prima dos requisitos de usuário, é generosa em ambiguidade. “O sistema deve processar rapidamente os pedidos” — rapidamente é uma palavra que cada leitor preenche com um número diferente na cabeça. O segundo é a incompletude: requisitos que faltam, porque ninguém pensou neles ou porque eram tão óbvios para o cliente que ele não os mencionou. O que acontece quando dois usuários editam o mesmo registro ao mesmo tempo? Frequentemente ninguém disse, e o time descobre o problema tarde. O terceiro é a volatilidade: requisitos mudam ao longo do projeto, porque o negócio muda, porque o cliente aprende ao ver o sistema tomando forma, porque leis e mercados se movem. A volatilidade não é falha do cliente; é a natureza do trabalho, e um bom processo a antecipa em vez de reclamar dela.
Um requisito ambíguo em código
Quero tornar a ambiguidade concreta, porque ela parece abstrata até você sentir o estrago. Considere um requisito de usuário aparentemente inocente: “o sistema deve aplicar um desconto de 10% para pedidos acima de 100 reais”. Parece claro? Entregue essa frase a dois desenvolvedores e você pode receber duas implementações incompatíveis, ambas defensáveis à luz do texto.
// Desenvolvedor B entendeu "acima de 100" como maior ou igual a 100.
// E aplicou o desconto apenas sobre o excedente de 100 reais.
double descontoInterpretacaoB(double valorPedido) {
if (valorPedido >= 100) {
final excedente = valorPedido - 100;
return 100 + (excedente * 0.90);
}
return valorPedido;
}Para um pedido de exatamente 100 reais, A não dá desconto e B dá. Para um pedido de 200 reais, A cobra 180 e B cobra 190. As duas versões estão “corretas” em relação ao texto do requisito, e é exatamente esse o problema: o requisito não determinava a resposta, então cada um a completou com sua própria suposição. Num sistema real, essa divergência vira uma discrepância financeira que só aparece quando o cliente reclama do valor cobrado. Note que nenhum desenvolvedor errou por incompetência técnica — o erro está no requisito, e é lá que ele precisava ter sido corrigido, com uma frase que dissesse com precisão a condição e a base de cálculo.
DicaComo desarmar a ambiguidade
A cura da ambiguidade quase nunca é escrever mais texto; é escrever texto verificável. Sempre que um requisito usar uma palavra elástica — “rápido”, “acima de”, “amigável”, “seguro” —, pergunte-se: existe um teste objetivo que decida, sem opinião, se o sistema atende ou não? Se a resposta for não, o requisito ainda não está pronto.
Guarde este critério prático, porque ele o acompanhará em todos os módulos seguintes: um bom requisito é aquele para o qual você consegue imaginar, de antemão, o teste que provaria seu cumprimento. Se nenhum teste objetivo é imaginável, o requisito ainda está no terreno do desejo, e não da engenharia.
Como este módulo se conecta ao restante do curso
Este módulo abriu a porta da especificação, aquela primeira atividade fundamental que mapeamos lá no início do curso. Aqui você entendeu o que é um requisito, por que o custo de corrigi-lo cresce com o tempo, como se distinguem os níveis de usuário e de sistema, quem são os stakeholders e como se organiza o processo de requisitos. Adiante, aprofundaremos a classificação dos requisitos em funcionais e não funcionais, aprenderemos a modelar comportamento e estrutura com UML e casos de uso, e conectaremos tudo isso ao projeto e aos testes. Cada uma dessas frentes depende de você ter entendido, agora, que construir a coisa certa vem antes de construí-la bem.
Síntese
Quero que você retenha três ideias desta conversa. A primeira é que requisito não se resume ao que o sistema faz: abrange também suas qualidades e restrições, e ignorar essa segunda metade produz sistemas que funcionam e mesmo assim são inaceitáveis. A segunda é que o custo de um erro de requisito cresce acentuadamente quanto mais tarde ele é descoberto, o que torna a validação precoce a atividade de maior retorno em todo o processo. A terceira é que a engenharia de requisitos é um processo humano e cíclico — elicitar, analisar, especificar, validar e gerenciar mudanças — cujo maior desafio é traduzir e conciliar as vozes conflitantes dos stakeholders numa especificação sem ambiguidade. Chegue à aula com essas três ideias assentadas, porque a partir delas vamos construir a modelagem de requisitos.
Para consolidar antes da aula: pegue um requisito vago do seu cotidiano — “o app precisa ser rápido”, por exemplo — e reescreva-o de forma que exista um teste objetivo capaz de decidir se ele foi ou não atendido. Se você conseguir transformar um desejo elástico numa afirmação verificável, absorveu o essencial deste módulo.