ENGENHARIA / 01 — DESCOBERTA E REQUISITOS / FABRÍCIO CASTRO
Antes de programar,
compreender o problema.
Requisitos não são uma lista de telas solicitadas. São acordos verificáveis sobre objetivos, comportamentos, regras, restrições e qualidade. A análise começa com pessoas e processos, atravessa arquitetura e testes e continua quando o sistema entra em operação.
01 / ORIGEM DO PROJETO
O pedido é uma hipótese. O problema precisa ser descoberto.
Uma organização fictícia solicita uma tela com botão de aprovação de compras. Se a equipe implementar apenas o botão, poderá automatizar uma operação incoerente: alçadas indefinidas, ausência de substitutos, pedidos duplicados e decisões impossíveis de auditar. Este caso é exclusivamente didático.
“Precisamos aprovar compras mais rápido.”
Essa frase expressa uma necessidade percebida, mas não especifica quem aprova, por qual valor, em que prazo, com qual evidência ou o que fazer quando o responsável estiver ausente. Também não demonstra que desenvolver uma aplicação seja a única alternativa viável.
Decisão inicial: comparar ajustes de processo, configuração de uma solução existente e desenvolvimento específico antes de comprometer o orçamento.
Quem participa, por que falha e como medir?
Solicitantes, gestores, financeiro, identidade e operação podem possuir perspectivas diferentes. Entrevistas e observação devem distinguir problema real, exceções, restrições legais, objetivos e indicadores que a organização esteja preparada para medir.
Portão de aceite: responsáveis pelo processo reconhecem a descrição do problema, os limites do escopo e o que caracterizará uma melhoria.
02 / INVESTIGAÇÃO E MODELAGEM DO PROCESSO
Entrevistar, observar, confrontar hipóteses.
Uma entrevista revela interpretações; a observação mostra o fluxo efetivo. Documentos e registros ajudam a descobrir exceções. Nenhuma fonte isolada garante que o processo declarado seja o processo realmente executado.
- 01Identificar partes interessadas e decisões
Registrar solicitante, aprovador, gestor substituto, financeiro, administração de identidade e suporte. Para cada ator, distinguir objetivo, decisão autorizada, informação que utiliza e evento que dispara sua atuação.
- 02Mapear AS-IS sem presumir a solução
Descrever como a compra é pedida, registrada, corrigida, aprovada e conciliada hoje. Investigar pedidos que voltam, decisões por mensagem, ausência de alçada e documentos armazenados fora de um repositório controlado.
- 03Propor TO-BE e testar alternativas
Comparar simplificação de regras, parametrização do ERP atual e uma aplicação adicional. Não escolher microsserviços, banco ou framework durante a entrevista. O alvo é reduzir risco e esforço total com valor verificável.
- 04Priorizar o que é necessário validar
Separar requisitos obrigatórios de melhorias posteriores, riscos e hipóteses ainda abertas. Revisar dependências, limites contratuais e custo de mudança com os responsáveis, sem transformar uma priorização provisória em promessa definitiva.
Perguntas que esclarecem
Quem pode criar e decidir? O solicitante pode aprovar o próprio pedido? Existe limite por centro de custo? O que ocorre se o gestor sair da empresa? Uma solicitação pode ser alterada durante a análise? Há obrigação de integração ou auditoria?
Informações que ainda faltam
Volume real, duração das decisões, disponibilidade esperada, política de retenção, metas de recuperação, categorias sensíveis e responsabilidade por aprovar mudanças. Nenhum número de desempenho deve ser inventado para preencher essas lacunas.
03 / CONTRATO DE COMPORTAMENTO E QUALIDADE
Especificar é tornar o acordo verificável.
Requisitos funcionais descrevem capacidades e respostas do sistema; regras de negócio impõem políticas; requisitos não funcionais definem atributos e restrições de qualidade. Uma mesma regra pode exigir medidas em diferentes camadas sem perder sua identidade de negócio.
O que o sistema deve permitir?
RF-01: pessoa autorizada registra solicitação com itens, valor e centro de custo. RF-02: solicita a análise. RF-03: aprovador autorizado decide sobre versão ainda pendente. RF-04: interessado autorizado consulta status e histórico.
Teste: cada capacidade possui um resultado observável, inclusive quando dados são inválidos ou indisponíveis.
Quais invariantes nunca podem ser ignoradas?
RN-01: ninguém aprova a própria solicitação. RN-02: somente quem possui alçada vigente pode decidir. RN-03: uma versão já decidida não admite segunda decisão conflitante. As regras precisam valer mesmo se o frontend for contornado.
Teste: autorização, estado e concorrência são avaliados pelo servidor, não pelo botão de interface.
Como o sistema deve se comportar sob restrições?
RNF-01: não revelar dados entre organizações. RNF-02: permitir operação por teclado com critérios aplicáveis de WCAG 2.2 AA. RNF-03: manter registros de decisão necessários à auditoria, respeitando políticas de privacidade e retenção.
Definição pendente: latência, disponibilidade e objetivos de recuperação exigem números negociados e medição real, não metas arbitrárias.
O que influencia a arquitetura antes da escolha da stack?
Integração com ERP legado, identidade corporativa, organização multiempresa, sigilo de dados, orçamento, experiência da equipe, forma de implantação e obrigações de continuidade. Cada restrição deve apontar para quem a confirmou e para o critério que a torna relevante.
Erro comum: escrever “usar Kafka” como RNF sem explicar qual necessidade funcional ou operacional exige mensageria distribuída.
04 / COMPORTAMENTO, ALTERNATIVAS E EXCEÇÕES
Um caso de uso não é um desenho de tela.
O UC-01 descreve a intenção do aprovador e as garantias do sistema. O fluxo alternativo é parte do contrato; uma implementação que só funciona no caminho feliz ainda não atende à necessidade.
UC-01 / APROVAR SOLICITAÇÃO
Uma decisão válida, rastreável e concorrente com segurança.
Ator: gestor com alçada vigente. Pré-condições: identidade confirmada, organização autorizada, solicitação pendente e versão informada. Pós-condição: estado e decisão coerentes, com identificação do responsável e evidência de auditoria.
01 / CONSULTAGestor abre a solicitação que tem permissão para visualizar.
02 / CONFERÊNCIASistema verifica versão atual, alçada, vínculo e estado pendente.
03 / DECISÃOGestor confirma aprovação com dados e motivo quando exigido.
04 / INVARIANTESServidor rejeita autoaprovação, acesso indevido e alteração concorrente.
05 / REGISTROTransação grava estado e decisão sem duplicidade.
06 / RESPOSTAUsuário recebe confirmação ou erro compreensível e recuperável.
Solicitação incompleta
O gestor devolve para ajustes conforme regra definida. O sistema conserva histórico, registra motivo e não informa falsamente que houve aprovação.
Pedido alterado durante a decisão
Se a versão recebida não corresponder ao estado persistido, a operação falha de modo controlado. A interface apresenta o novo estado; o backend não tenta aprovar silenciosamente a versão antiga.
Gestor sem alçada ou de outra empresa
A API rejeita a operação sem revelar detalhes da solicitação de outro tenant. A política de resposta pública deve ser definida no modelo de ameaças e validada por testes adversariais.
Integração não respondeu
É preciso decidir se a aprovação local depende da confirmação externa ou pode ser sincronizada posteriormente. Essa definição é requisito de consistência e muda arquitetura, mensagens, testes e comunicação com o usuário.
05 / REQUISITO → COMPORTAMENTO → TESTE → ACEITE
Sem rastreabilidade, o acordo se perde.
Um identificador só tem valor se permitir localizar a regra, o cenário afetado, a decisão técnica e sua evidência. Mudanças de requisito devem atualizar cenários, documentação e testes, não apenas um texto em uma issue.
- RFRF-03 — Registrar decisão autorizada
Relação: UC-01; dependências RN-01, RN-02 e RN-03. A operação exige que a solicitação ainda esteja pendente e que o gestor possua alçada.
- ADRDecisão arquitetural — transação e concorrência
Avaliar operação transacional única com controle de versão como alternativa inicial. Fila, CQRS ou Saga não são requisitos automáticos; só entram quando problemas demonstrados tornarem a complexidade útil.
- QACasos positivos e adversariais
Uma aprovação válida altera estado uma única vez; autoaprovação e cross-tenant são negados; duas decisões concorrentes não geram resultados contraditórios; indisponibilidade do ERP segue política definida.
- ACEITEAprovação baseada em evidência
Responsáveis revisam cenários, exceções e tratamento de falha. Um build bem-sucedido não substitui teste de regras, experiência do usuário, recuperação nem validação de processo.
06 / QUALIDADE DESDE A DESCOBERTA
DevOps e segurança começam antes do deploy.
Disponibilidade, observabilidade, privilégio mínimo, recuperação e custo pertencem às perguntas iniciais. Se forem lembrados apenas quando o código estiver pronto, podem exigir retrabalho de domínio, infraestrutura e fluxo.
Quem pode ver e alterar?
O levantamento identifica tenant, papéis, política de alçada, autenticação, revogação de acesso, dados pessoais e requisitos de auditoria. A autorização é validada no servidor e no acesso ao dado, inclusive em buscas e caches.
Evidência: cenários de IDOR/cross-tenant, concessão/revogação e acesso negado.
Como a mudança chega com segurança?
Os requisitos indicam ambientes, estratégia de release, janela de mudança, migração de dados e rollback. Git, testes automatizados e CI/CD apoiam entrega; não eliminam aprovação nem tornam qualquer deploy seguro.
Evidência: pipeline executado no mesmo commit, smoke e reversão ensaiada quando necessário.
Como reconhecer uma falha?
Definir quais eventos e indicadores são relevantes: erro ao decidir, tentativa duplicada, latência, fila pendente e indisponibilidade da integração. Metas de serviço precisam ser negociadas conforme criticidade e capacidade de medição.
Evidência: logs sem dados sensíveis, correlação de eventos, alertas e runbook de recuperação.
O que nos faz revisar a decisão?
Feedback de usuários, incidentes, alterações de regra, custos de integração e tempo de atendimento podem levar a novas prioridades. A mudança deve atualizar requisitos e seu histórico, sem atribuir a arquitetura anterior um defeito sem medição.
Evidência: backlog ligado a RF/RNF, ADRs, testes e fatos observados em operação.
07 / ARTEFATOS E ESTUDO
Documentar o que se sabe. Revisar o que não se sabe.
O modelo de especificação é um ponto de partida para entrevistas e acordos, não uma norma obrigatória nem prova de implantação. As fontes abaixo apoiam aprofundamento; seus critérios precisam ser adaptados a cada contexto.
Material existente da Fanpage em Markdown para orientar estrutura de documento, requisitos, casos de uso e critérios de validação. Adaptar conforme o problema real.
IREB — fundamentos de requisitos
Referência para elicitação, documentação, validação e gestão de requisitos. Não substituir diálogo e verificação do problema por um formulário padrão.
W3C — WCAG 2.2
Critérios para requisitos e testes de acessibilidade. Uma auditoria automática auxilia, mas não prova por si só conformidade de toda a experiência.
PRÓXIMO PASSO / ENGENHARIA INTEGRADA
Requisitos orientam as decisões seguintes.
Depois de descobrir o problema, retorne ao processo de 12 etapas para acompanhar modelagem, arquitetura, banco, frontend, backend, testes, entrega e operação. Conhecimento novo não exige reconstruir a identidade do portfólio.