💻 computer science

From Requirements to Production: Governing AI-Assisted Software Delivery through a Canonical Requirements Model

Este artigo apresenta um estudo de ciência do design introduzindo uma estrutura de governança para a entrega de software assistida por IA que utiliza um modelo de requisitos canônico, um ciclo de construção e revisão de dois fornecedores e documentação executável para alcançar alta rastreabilidade e conformidade através de dois sistemas de produção independentes, ao mesmo tempo em que redefine o papel do analista de negócios.

Autores originais: Mohamed Zahran

Publicado 2026-07-21

📖 7 min de leitura🧠 Leitura aprofundada

CC BY 4.0

Autores originais: Mohamed Zahran

Artigo original sob licença CC BY 4.0 (https://creativecommons.org/licenses/by/4.0/). ✨ Esta é uma explicação gerada por IA do artigo abaixo. Não foi escrita nem endossada pelos autores. Para precisão técnica, consulte o artigo original. Ler aviso legal completo

As Novas Regras da Estrada para Construtores de Robôs

Imagine que você é um arquiteto mestre que passou anos desenhando plantas para equipes de construção humanas. Você sabe que, se deixar uma pequena lacuna nos planos — como esquecer de especificar a cor da porta da frente — um construtor humano habilidoso apenas perguntará: "Ei, de que cor você quer?" ou adivinhará com base no estilo do bairro. Eles preenchem as lacunas com seu próprio senso comum e experiência. É assim que o desenvolvimento de software funcionou por décadas: um humano escreve os requisitos e uma equipe humana constrói o software, preenchendo os detalhes ausentes conforme avançam.

Mas agora, imagine que você contrata uma frota de construtores robôs super rápidos e super inteligentes. Esses robôs são incríveis; eles podem assentar tijolos e instalar circuitos em segundos. No entanto, eles têm uma grande falha: são literalistas. Eles não têm senso comum, não adivinham e certamente não fazem perguntas. Se você disser a um robô para "construir uma porta", mas não especificar a cor, ele pode pintá-la de verde neon porque essa é a cor mais lógica em seu banco de dados, ou pode parar e travar porque não sabe o que fazer. No mundo do software, este é o desafio do desenvolvimento assistido por IA. Os "requisitos" (as instruções) que funcionavam perfeitamente para humanos agora são perigosos para robôs porque os robôs não conseguem preencher as lacunas. Se as instruções não forem perfeitas, os robôs constroem a coisa errada, e isso acontece tão rápido que o erro já está no produto final antes que alguém perceba. Este artigo explora como reescrever as regras da estrada para que esses construtores robôs possam ser confiados para construir software seguro e funcional sem precisar que um humano segure sua mão a cada segundo.

De "Talvez" para "Deve": Uma Nova Maneira de Construir com IA

O artigo, escrito por Mohamed Zahran, aborda um grande problema: agentes de codificação de IA são rápidos, mas são perigosos se as instruções não forem perfeitas. O autor argumenta que a antiga maneira de escrever requisitos — documentos projetados para equipes humanas que conseguem "ler nas entrelinhas" — está quebrada quando o construtor é uma máquina. Se um humano lê uma instrução incompleta, ele usa seu cérebro para corrigi-la. Se um robô lê uma instrução incompleta, ele apenas adivinha, e esse palpite frequentemente se transforma em um bug ou uma brecha de segurança.

Para resolver isso, o autor não apenas escreveu uma nova teoria; ele realmente construiu dois sistemas de software reais e funcionais usando um novo método que ele mesmo projetou. Pense nisso como um chef que, em vez de apenas escrever um livro de receitas, realmente cozinhou duas refeições complexas diferentes em uma cozinha de alta pressão para provar que sua nova receita funciona.

A Ideia Central: A "Fonte Única de Verdade"
A solução do autor é um "Framework de Entrega Governado e Pronto para IA". A maior mudança é o afastamento de documentos soltos (como arquivos do Word) que podem se tornar bagunçados e ter versões diferentes da mesma coisa. Em vez disso, eles criaram um Modelo de Requisitos Canônico.

A Analogia: Imagine uma planta digital mestra que vive em um cofre seguro. Esta planta é a única versão verdadeira do plano.
A Magia: A partir desta única planta mestra, o sistema gera automaticamente duas "visões" diferentes:
1. A Visão Humana: Um documento legível e agradável para o Analista de Negócios e gestores aprovarem.
2. A Visão do Robô: Um pacote de instruções estrito e legível por máquina para os agentes de codificação de IA.
Por que isso importa: Como ambas as visões vêm da mesma planta mestra, elas nunca podem divergir. O humano não pode aprovar um plano que o robô não esteja realmente seguindo. É como ter uma única fonte de verdade que atualiza todos instantaneamente.

A Regra dos "Quatro Olhos" para Robôs
O artigo introduz uma verificação de segurança inteligente chamada Separação de Deveres, mas para robôs.

A Configuração: O autor utilizou duas ferramentas de codificação de IA diferentes de duas empresas (fornecedores) distintas.
O Processo: Uma IA (Fornecedor A) foi o "Construtor". Ela escreveu o código com base nas instruções. Uma IA completamente diferente (Fornecedor B) foi o "Inspetor". Ela analisou o código para verificar erros, brechas de segurança e se ele correspondia ao plano.
O Resultado: Isso impediu que a IA construísse uma casa e depois desse a si mesma uma nota de aprovação. A IA "Inspetor" detectou coisas que a IA "Construtor" deixou passar, exatamente como uma equipe humana faria.

As Descobertas: Velocidade Sem Caos
O autor testou este framework em dois projetos muito diferentes:

Caso 1: Uma plataforma de salvaguarda para 170 organizações nacionais (um projeto grande, complexo e de movimento lento).
Caso 2: Um espaço de trabalho de análise multilocatário para analistas de negócios (um projeto mais rápido, menor, com regras de segurança extras para cartões de crédito).

Os resultados foram impressionantes. O framework permitiu que a IA trabalhasse incrivelmente rápido, mantendo tudo sob controle:

Rastreabilidade: O sistema rastreou de onde cada peça de código veio. No Caso 1, 94,9% dos requisitos estavam perfeitamente vinculados ao código e aos testes; no Caso 2, era de 97,8%.
Sem Edições Não Autorizadas: Em ambos os casos, a taxa de mudanças não autorizadas foi de 0,00%. O sistema era tão rigoroso que ninguém (ou nenhum robô) poderia alterar o código secretamente sem que o sistema soubesse.
Menos Erros: A "taxa de escape de defeitos" (bugs que chegaram ao produto final) foi de 9,1% no primeiro caso e 4,7% no segundo. O segundo caso foi, na verdade, melhor do que a média da indústria "best-in-class".
Velocidade: O framework não atrasou as coisas. Na verdade, o segundo projeto foi entregue em apenas 31 dias corridos (com apenas 12 dias de construção ativos), o que é incrivelmente rápido para esse nível de complexidade.

O Que o Autor Diz que Não é a Resposta
O artigo é muito claro sobre o que não funciona. Ele argumenta contra a ideia de que você pode simplesmente dar um comando vago para uma IA e deixar que ela resolva o resto. Também alerta que adicionar IA a um projeto apenas porque é "da moda" é uma má ideia; às vezes, uma simples mudança de processo é melhor do que usar IA. O autor enfatiza que a IA não pode substituir o julgamento humano, a clareza de negócios ou a necessidade de um humano aprovar o resultado final.

O Quão Certos Estamos?
O autor é cuidadoso ao não afirmar que isso é uma solução mágica que resolve tudo para sempre. O estudo baseia-se em dois casos específicos entregues pela mesma pessoa (o autor). Embora os resultados sejam muito fortes e consistentes entre dois tipos de projetos muito diferentes, o autor admite que, como ele foi o único realizando o trabalho, não podemos ter 100% de certeza de que isso funcionaria exatamente da mesma forma para uma equipe inteira de pessoas diferentes sem mais testes. Eles também descobriram que, embora o sistema fosse ótimo para detectar erros óbvios, às vezes perdia "falhas silenciosas" (bugs que não aparecem imediatamente), o que significa que os humanos ainda precisam fazer uma verificação profunda ocasionalmente.

A Grande Conclusão
O artigo conclui que o papel do Analista de Negócios está mudando. Eles não são mais apenas escritores de documentos para outros humanos. Eles estão se tornando os arquitetos de sistemas de controle. Seu trabalho é projetar o "framework de entrega governado" — as regras, as verificações e a planta mestra — que permite que a IA construa software com segurança. O futuro não é sobre humanos vs. IA; é sobre humanos projetando as instruções perfeitas para que a IA possa realizar o trabalho pesado sem quebrar nada. Como o autor coloca, "Na era da IA, o Analista de Negócios não é definido apenas pelo que ele escreve, mas pelo que ele permite que outros — humanos e IA — entreguem."

Resumo Técnico: Governando a Entrega de Software Assistida por IA através de um Modelo de Requisitos Canônico

1. Declaração do Problema

O artigo identifica uma desconexão fundamental entre a engenharia de requisitos tradicional e a entrega de software assistida por IA. Os Analistas de Negócios (BAs) historicamente produziram artefatos (ex: Documentos de Requisitos de Negócio, histórias de usuário) projetados para equipes de entrega humanas. Esses documentos dependem de "conhecimento tácito", julgamento de domínio e conversação para preencher lacunas de especificação. Quando o executor muda de um desenvolvedor humano qualificado para um agente de codificação autônomo de IA, esse contrato implícito se quebra. Agentes de IA não inferem detalhes ausentes; eles procedem com base na "interpretação mais plausível", transformando especificações incompletas em fontes de defeitos.

Além disso, o artigo argumenta que o foco atual da indústria na velocidade leva à suposição perigosa de que a análise de negócios estruturada é desnecessária. Evidências sugerem que, sem uma definição de problema rigorosa e governança, projetos de IA sofrem altas taxas de falha devido ao ajuste inadequado ao fluxo de trabalho, insuficiência de dados e fraqueza na propriedade. O problema central é a falta de um framework de governança que permita aos agentes de IA executar requisitos de forma confiável, preservando a responsabilidade humana, a rastreabilidade e a separação de deveres.

2. Metodologia

O estudo emprega uma abordagem de Pesquisa de Ciência do Design (DSR). A contribuição é um artefato operacional proposital — um framework de entrega governado — construído, aplicado e refinado durante a entrega de dois sistemas independentes em produção real.

Cenário de Pesquisa: Dois casos distintos entregues por um único operador solo (o autor):
- Caso 1: Uma plataforma de avaliação de salvaguarda multilíngue para 170 organizações nacionais (conformidade GDPR/OWASP). Entregue ao longo de 17 semanas (~320 horas).
- Caso 2: Um produto SaaS de workspace de análise multi-inquilino para analistas de negócios (conformidade GDPR + PCI DSS SAQ A). Entregue em 31 dias corridos (~165 horas).
Fontes de Dados: O estudo analisou o histórico completo de controle de versão, artefatos de governança (pacotes de módulos, prompts de agentes, checklists de revisão) e o código-fonte de ambos os sistemas.
Estratégia de Avaliação: O framework foi avaliado contra seis medidas operacionais computadas a partir dos registros de entrega. O estudo reconhece limitações metodológicas, incluindo a falta de controles pré-framework correspondentes e o viés de operador único, enquadrando os resultados como demonstrações de viabilidade em vez de alegações causais estatisticamente generalizáveis.

3. O Artefato Projetado: Um Framework de Entrega Governado e Pronto para IA

A contribuição central é um framework que reengenharia os requisitos de auxílios de comunicação para instrumentos de controle executáveis. Ele repousa sobre três elementos projetados:

A. O Modelo de Requisitos Canônico

O framework substitui documentos díspares por um único modelo canônico versionado, $M(m, v)$ , para qualquer módulo $m$ na linha de base $v$ . Este modelo contém:

R: Requisitos e critérios de aceitação.
D: Decisões de arquitetura e design.
C: Restrições (de negócio, técnicas, segurança, acessibilidade).
T: Casos de teste e evidência de validação.
P: Proveniência e relações de rastreabilidade.
A: Estado de aprovação e tomadores de decisão responsáveis.
H: Histórico de versão e mudanças.

Projeções Controladas: Documentos legíveis por humanos (Pacotes de Garantia/Assurance Packs) e arquivos legíveis por máquina (Pacotes de Agente/Agent Packs) não são fontes de verdade separadas. Eles são gerados como projeções controladas, $O(i, m, v)$ , do único modelo canônico usando perfis de exportação específicos. Isso garante que o documento que um stakeholder assina e o código que um agente executa sejam comprovadamente consistentes.

B. Separação de Deveres via Ciclo de Dual-Vendor

Para aplicar o princípio de "quatro olhos" a agentes autônomos, o framework impõe um ciclo de construção e revisão de dual-vendor:

Agente de Construção (Build Agent): Um fornecedor de IA (ex: Fornecedor A) é designado para gerar código e artefatos de implementação.
Agente de Revisão (Review Agent): Um segundo fornecedor de IA independente (ex: Fornecedor B) realiza a revisão independente, validação de segurança e detecção de defeitos.
Portão Humano (Human Gate): Humanos responsáveis assinam em cada etapa. O agente de revisão não aprova a produção; ele fornece evidências para os tomadores de decisão humanos.

C. Documentação como uma Superfície de Controle Executável

Os requisitos são reengenheirados para serem explícitos, testáveis e rastreáveis. O framework inclui artefatos específicos, tais como:

Pacote de Governança de Construção de IA (AI Build Governance Pack): Define limites, ações proibidas e regras de validação para o agente de construção.
Prompt/Contrato de Revisor Independente: Um contrato governado para o agente de revisão validar contra a linha de base aprovada.
Manifesto de Pacote (Pack Manifest): Um registro legível por máquina que vincula arquivos gerados à sua linha de base de origem, garantindo a proveniência e detectando o desvio (drift).

Controle de Mudanças: Se um requisito muda, a proposta retorna ao modelo canônico. Após a aprovação, uma nova linha de base ( $v+1$ ) é criada, e todos os outputs afetados (humanos e de máquina) são regenerados simultaneamente. Isso evita o "desvio de especificação", onde documentos humanos e instruções de agentes divergem.

4. Resultados

O framework foi avaliado nos dois casos usando seis medidas operacionais. Os resultados demonstram consistência através de diferentes domínos, escalas e ritmos de entrega:

Medida	Caso 1 (Plataforma de Salvaguarda)	Caso 2 (SaaS de Workspace de Análise)
Cobertura de Rastreabilidade	94,9% (185/195 requisitos)	97,8% (496/507 requisitos)
Divergência de Output	0,5 divergências substantivas por baseline	0,0 divergências substantivas por baseline
Conformidade de Baseline	99,2% das atividades contra a baseline atual	99,7% das atividades contra a baseline atual
Taxa de Edição Não Autorizada	0,00% (0/924 outputs)	0,00% (0/343 outputs)
Taxa de Escape de Defeitos	9,1% (31/341 defeitos)	4,7% (8/169 defeitos)
Propagação de Mudança	Mediana 16 min	Mediana 0 min (commit único)

Rastreabilidade: Alta cobertura foi alcançada, sendo que a única lacuna sistemática foi o vínculo de testes automatizados para funcionalidades menores de UI.
Consistência: A abordagem de "projeção controlada" resultou em quase zero divergência entre artefatos humanos e de agentes.
Governança: A imposição estrutural do pipeline (ex: descartar mudanças locais não commitadas) alcançou uma taxa de edição não autorizada de 0,00%.
Defeitos: As taxas de escape de defeitos ficaram dentro ou ligeiramente acima das faixas de excelência da indústria. No entanto, o estudo observou que os defeitos de vida mais longa foram "falhas silenciosas" (controles ausentes sem erros visíveis), que o loop interno rápido não detectou, surgindo apenas durante revisões deliberadas de todo o repositório.

5. Significância e Alegações

O artigo afirma fornecer uma arquitetura de governança para entrega assistida por IA e uma correspondente redefinição do papel do Analista de Negócios (BA).

Redefinição do BA: O BA não é mais definido unicamente pelo que escreve, mas pelo que permite que outros (humanos e IA) entreguem. O papel muda de autoria de especificações para colegas para a autoria de instrumentos de controle para executores de máquina e governança do pipeline de entrega de IA.
Viabilidade de Velocidade + Controle: O estudo demonstra que adicionar governança rigorosa (separação de deveres, rastreabilidade, controle de baseline) não anula a vantagem de velocidade da IA. No Caso 2, o framework entregou o dobro de contagem de módulos em um quarto do tempo do Caso 1, mantendo maior conformidade e zero edições não autorizadas.
Fonte Única de Verdade: O artigo valida que um único modelo canônico pode servir tanto para garantia humana quanto para execução de máquina sem criar fontes de verdade divergentes, desde que os outputs sejam gerados como projeções controladas.

Modéstia das Alegações:
O artigo declara explicitamente que estes resultados são demonstrações de viabilidade de um estudo de caso de dois casos por um único operador. Não pretende alegar generalização estatística. Os autores reconhecem que a avaliação carece de controles pré-framework correspondentes e que a métrica de "escape de defeito" depende do julgamento do autor. A principal contribuição é o design de um método que torna a entrega assistida por IA governável, segura e rastreável, transferindo o ônus da clareza do intérprete humano para o artefato de requisito estruturado.