A Engenharia de Requisitos sempre foi considerada a fase mais crítica do ciclo de desenvolvimento de software. Estudos clássicos demonstram que erros originados nesta fase custam de 10 a 200 vezes mais para corrigir quando descobertos em produção. Tradicionalmente, esta disciplina dependia exclusivamente de habilidades humanas: conduzir entrevistas, interpretar linguagem corporal, negociar prioridades entre stakeholders com interesses conflitantes.
Em 2024, a Thoughtworks documentou um caso emblemático: analistas usando IA para decompor épicos em user stories reduziram bugs em 10% via critérios de aceitação mais precisos — mas a revisão humana permaneceu essencial para detectar ambiguidades contextuais. Este caso ilustra a tensão central da Engenharia de Requisitos moderna: técnicas de NLP e LLMs prometem automação massiva, mas estudos mostram que 25% das ambiguidades sutis escapam à detecção algorítmica. Na fase onde 70% dos defeitos de software se originam, a pergunta não é se usar IA, mas como orquestrar sistemas híbridos que maximizem os pontos fortes de cada componente.
Nas discussões anteriores, vocês compreenderam como Large Language Models funcionam — arquitetura transformer, mecanismos de atenção, embeddings semânticos. Agora, aplicaremos esse conhecimento à primeira fase prática do SDLC. A Engenharia de Requisitos representa campo de teste ideal: grandes volumes de texto não-estruturado, padrões linguísticos identificáveis, necessidade de consistência que humanos frequentemente falham em manter. Contudo, também envolve contexto organizacional, política corporativa e ambiguidades intencionais que algoritmos não capturam.
Da Planilha ao Embedding: Evolução Quantificada
Tradicionalmente, a elicitação de requisitos consome 20-30% do tempo de projeto, dependendo de entrevistas manuais, workshops e análise de documentos. E, durante décadas, engenheiros de requisitos dependeram de técnicas essencialmente manuais. A análise de documentos envolvia leitura cuidadosa, marcações com canetas coloridas, e matrizes de rastreabilidade mantidas em planilhas. A detecção de inconsistências dependia da memória do analista e sua capacidade de manter coerência mental entre centenas de requisitos.
Estudos empíricos mostram que analistas humanos detectam entre 60-80% das inconsistências em documentos de requisitos — um número impressionante considerando a complexidade, mas insuficiente para sistemas críticos. Abordagens como MoSCoW ou Volere priorizam validação humana, mas falham em escala: em projetos com 500+ requisitos, inconsistências atingem 15-20%.
O advento de NLP4RE (Natural Language Processing for Requirements Engineering) transformou este cenário. A evolução foi de regras sintáticas (anos 2010) para LLMs como GPT-4 e Gemma 3 (2024-2025). Estudos recentes do WER2025 mostram que ChatGPT-4 extrai requisitos não-funcionais com 75-82% de precisão em entrevistas transcritas, superando humanos em atomicidade e consistência. Ferramentas modernas convertem requisitos em embeddings — representações vetoriais que capturam significado semântico, permitindo detecção automática de duplicatas com 87% de recall e 92% de precisão em datasets bancários.
| Aspecto | Abordagem Tradicional | Assistida por NLP/LLM | Trade-off Real |
|---|---|---|---|
| Tempo | 2-4 semanas | 2-3 dias | IA 5-7x mais rápida |
| Precisão | 65% | 75-82% | IA superior em padrões |
| Recall | 70% | 85-98% | IA detecta mais, com ruído |
| Falsos Positivos | Baixo | 20-30% | Custo de triagem humana |
Além disso, dois requisitos podem usar palavras completamente diferentes mas ter embeddings próximos se expressarem conceitos similares. Isso permite detecção automática de duplicatas, conflitos e dependências que escapariam à revisão humana.
| Aspecto | Abordagem Tradicional | Assistida por IA | Trade-off Real |
|---|---|---|---|
| Detecção de duplicatas | Memória + busca textual (60-75% recall) | Similaridade semântica (85-95% recall) | IA ganha precisão, mas gera falsos positivos |
| Análise de ambiguidade | Revisão manual (40h para 500 requisitos) | Automática (minutos) | IA detecta padrões, humano entende contexto |
| Rastreabilidade | Matrizes manuais (erro-prone) | Linking automático | IA sugere, humano valida |
| Tempo total | 2-4 semanas | 2-3 dias + validação | Economia real depende de taxa de erro |
A transição não é binária. Organizações maduras como a Thoughtworks implementam workflows híbridos, demonstrando o padrão emergente: IA para draft inicial e detecção de padrões, humanos para validação contextual e decisões de negócio. O engenheiro de requisitos evolui de executor para orquestrador — menos tempo revisando texto, mais tempo tomando decisões estratégicas.
Técnicas de NLP: NER, Parsing e Similaridade Semântica
Para aplicar IA efetivamente em requisitos, precisamos dominar três técnicas fundamentais. Named Entity Recognition (NER) identifica entidades relevantes: atores, sistemas, dados. Dependency parsing extrai relações gramaticais e estruturas sintáticas. Semantic similarity via embeddings detecta duplicatas e relacionamentos implícitos. Combinadas, essas técnicas permitem extrair estrutura de texto aparentemente não-estruturado.
Considere o requisito: "O gerente de vendas deve aprovar pedidos acima de R$10.000 em até 24 horas". Um pipeline de NLP identifica: ator (gerente de vendas), ação (aprovar), objeto (pedidos), condição (acima de R$10.000), restrição temporal (24 horas). Essa decomposição automática é o primeiro passo para análise sistemática.
/**
* Extrai entidades de um requisito usando análise de padrões
*
* Esta implementação demonstra os conceitos fundamentais de NER
* aplicado a requisitos de software. Em produção, usaríamos
* modelos treinados (spaCy, transformers), mas os padrões
* ilustram a lógica subjacente.
*/
interface RequirementEntity {
text: string;
type: 'actor' | 'action' | 'object' | 'condition' | 'constraint';
confidence: number;
startIndex: number;
endIndex: number;
}
interface ParsedRequirement {
original: string;
entities: RequirementEntity[];
structure: {
subject?: string;
verb?: string;
object?: string;
constraints: string[];
};
}
function parseRequirement(requirement: string): ParsedRequirement {
const entities: RequirementEntity[] = [];
const lowerText = requirement.toLowerCase();
// Padrões para identificação de atores (sujeitos típicos)
const actorPatterns = [
/(?:o|a)\s+([\w\s]+?)\s+(?:deve|deverá|precisa|pode)/gi,
/(usuário|administrador|gerente|sistema|cliente)(?:\s+de\s+[\w]+)?/gi,
];
// Padrões para ações (verbos modais + infinitivo)
const actionPatterns = [
/deve(?:rá)?\s+([\w]+(?:ar|er|ir))/gi,
/precisa\s+([\w]+(?:ar|er|ir))/gi,
/pode(?:rá)?\s+([\w]+(?:ar|er|ir))/gi,
];
// Padrões para restrições quantitativas
const constraintPatterns = [
/(?:em\s+)?(?:até|no\s+máximo)\s+([\d]+\s*(?:segundos?|minutos?|horas?|dias?))/gi,
/(?:acima|abaixo)\s+de\s+(?:R\$\s*)?([\d.,]+)/gi,
/(?:no\s+)?máximo\s+([\d]+)\s+([\w]+)/gi,
];
// Extrai atores
actorPatterns.forEach(pattern => {
let match;
while ((match = pattern.exec(requirement)) !== null) {
entities.push({
text: match[1]?.trim() || match[0].trim(),
type: 'actor',
confidence: 0.85,
startIndex: match.index,
endIndex: match.index + match[0].length
});
}
});
// Extrai restrições
constraintPatterns.forEach(pattern => {
let match;
while ((match = pattern.exec(requirement)) !== null) {
entities.push({
text: match[0].trim(),
type: 'constraint',
confidence: 0.90,
startIndex: match.index,
endIndex: match.index + match[0].length
});
}
});
// Monta estrutura simplificada
const structure = {
subject: entities.find(e => e.type === 'actor')?.text,
verb: undefined as string | undefined,
object: undefined as string | undefined,
constraints: entities.filter(e => e.type === 'constraint').map(e => e.text)
};
return {
original: requirement,
entities,
structure
};
}
// Exemplo de uso
const req = "O gerente de vendas deve aprovar pedidos acima de R$10.000 em até 24 horas";
const parsed = parseRequirement(req);
console.log("Requisito:", parsed.original);
console.log("Entidades encontradas:");
parsed.entities.forEach(e => {
console.log(` [${e.type}] "${e.text}" (confiança: ${(e.confidence * 100).toFixed(0)}%)`);
});
/* Output esperado:
Requisito: O gerente de vendas deve aprovar pedidos acima de R$10.000 em até 24 horas
Entidades encontradas:
[actor] "gerente de vendas" (confiança: 85%)
[constraint] "acima de R$10.000" (confiança: 90%)
[constraint] "em até 24 horas" (confiança: 90%)
*/
O código acima demonstra a lógica de extração, não uma solução de produção. Bibliotecas como compromise (JavaScript) ou modelos transformer oferecem precisão significativamente maior. O ponto pedagógico é: requisitos têm estrutura implícita que algoritmos podem explicitar.
Além disso, modelos como Sentence-BERT calculam similaridade cosseno entre requisitos, detectando duplicatas semanticamente equivalentes mesmo com vocabulário diferente.
Bibliotecas TypeScript modernas facilitam implementação. O wink-nlp oferece tokenização performática, node-nlp-typescript fornece classificação e intents, e Transformers.js (Hugging Face) permite embeddings diretamente em Node.js/browser.
/**
* Detecta requisitos duplicados via similaridade semântica
*
* Usa embeddings para capturar significado além de palavras exatas.
* Threshold típico: 0.85 (85% similaridade = provável duplicata)
*
* Em produção, embeddings viriam de Transformers.js ou API OpenAI
*/
interface Requirement {
id: string;
text: string;
embedding: number[]; // Vetor de 384-768 dimensões
}
interface DuplicateCandidate {
reqA: string;
reqB: string;
similarity: number;
recommendation: 'merge' | 'review' | 'distinct';
}
function cosineSimilarity(a: number[], b: number[]): number {
const dot = a.reduce((sum, val, i) => sum + val * b[i], 0);
const magA = Math.sqrt(a.reduce((sum, val) => sum + val * val, 0));
const magB = Math.sqrt(b.reduce((sum, val) => sum + val * val, 0));
return dot / (magA * magB);
}
function detectDuplicates(
requirements: Requirement[],
thresholds = { merge: 0.95, review: 0.85 }
): DuplicateCandidate[] {
const candidates: DuplicateCandidate[] = [];
for (let i = 0; i < requirements.length; i++) {
for (let j = i + 1; j < requirements.length; j++) {
const sim = cosineSimilarity(
requirements[i].embedding,
requirements[j].embedding
);
if (sim > thresholds.review) {
candidates.push({
reqA: requirements[i].id,
reqB: requirements[j].id,
similarity: sim,
recommendation: sim > thresholds.merge ? 'merge' : 'review'
});
}
}
}
return candidates.sort((a, b) => b.similarity - a.similarity);
}
// Exemplo de uso (embeddings simulados para demonstração)
const reqs: Requirement[] = [
{ id: 'REQ-001', text: 'Usuário deve fazer login com email', embedding: [0.8, 0.2, 0.5] },
{ id: 'REQ-047', text: 'Sistema requer autenticação via email', embedding: [0.79, 0.21, 0.48] },
{ id: 'REQ-102', text: 'Relatórios devem ser exportáveis em PDF', embedding: [0.1, 0.9, 0.3] },
];
const duplicates = detectDuplicates(reqs);
console.log('Candidatos a duplicata:', duplicates);
/* Output esperado:
Candidatos a duplicata: [
{ reqA: 'REQ-001', reqB: 'REQ-047', similarity: 0.997, recommendation: 'merge' }
]
*/
Em dataset PURE (34k sentenças de requisitos públicos), abordagens baseadas em embeddings atingem F1-score de 0.83 para detecção de ambiguidades. A limitação: falsos positivos atingem 30% em domínios específicos sem fine-tuning.
Detecção de Ambiguidades: Padrões e Limitações
Ambiguidades em requisitos são armadilhas silenciosas. O termo "rapidamente" significa 100 milissegundos para um desenvolvedor de sistemas real-time e 5 segundos para um desenvolvedor web. "Usuário" pode referir-se a pessoa física, conta de sistema, ou sessão ativa. Essas ambiguidades frequentemente passam despercebidas até gerarem bugs em produção.
Na prática, ambiguidade afeta 50% dos requisitos em linguagem natural. A taxonomia inclui: implicitude (pronomes sem referente claro), multiplicidade (verbos com múltiplas interpretações), e under-specification (termos vagos como "rápido", "eficiente"). Estudos com Gemma 3 (2025) mostram 82.5% de accuracy e 85% de recall para ambiguidades linguísticas — números impressionantes, mas insuficientes para contextos críticos.
Ferramentas de NLP detectam ambiguidades através de dicionários de termos vagos — palavras que indicam especificação incompleta. A detecção não é perfeita: termos como "adequado" podem ser vagos ou perfeitamente definidos dependendo do contexto. Por isso, ferramentas reportam candidatos a ambiguidade, não certezas. Ferramentas como QuARS e RETA usam padrões sintáticos, mas precision cai para 41-68% com altas taxas de falsos positivos. A abordagem moderna combina dicionários de termos vagos com análise contextual via LLMs.
/**
* Analisa ambiguidades em requisitos usando categorização de termos
*
* Tipos detectáveis automaticamente:
* - Quantificadores vagos: "rápido", "eficiente", "vários"
* - Temporais indefinidos: "logo", "frequentemente"
* - Comparativos sem baseline: "melhor", "maior"
* - Subjetivos: "fácil", "intuitivo", "amigável"
*/
interface AmbiguityAnalysis {
score: number; // 0.0 (claro) a 1.0 (muito ambíguo)
issues: Array<{
term: string;
category: string;
severity: 'low' | 'medium' | 'high';
suggestion: string;
}>;
requiresHumanReview: boolean;
}
const VAGUE_TERMS: Record<string, { category: string; severity: 'low' | 'medium' | 'high'; suggestion: string }> = {
'rápido': { category: 'temporal', severity: 'high', suggestion: 'Especifique tempo (ex: "em até 2 segundos")' },
'rapidamente': { category: 'temporal', severity: 'high', suggestion: 'Defina SLA numérico' },
'eficiente': { category: 'quantifier', severity: 'high', suggestion: 'Defina métrica (ex: "< 100MB RAM")' },
'adequado': { category: 'subjective', severity: 'medium', suggestion: 'Liste critérios objetivos' },
'vários': { category: 'quantifier', severity: 'medium', suggestion: 'Especifique quantidade mínima' },
'frequentemente': { category: 'temporal', severity: 'medium', suggestion: 'Defina intervalo (ex: "a cada 5 min")' },
'fácil': { category: 'subjective', severity: 'high', suggestion: 'Defina em termos de UX (ex: "em 3 cliques")' },
'intuitivo': { category: 'subjective', severity: 'high', suggestion: 'Especifique teste de usabilidade' },
'melhor': { category: 'comparative', severity: 'high', suggestion: 'Defina baseline e métrica de comparação' },
};
function analyzeAmbiguity(requirement: string): AmbiguityAnalysis {
const lowerText = requirement.toLowerCase();
const words = lowerText.split(/\s+/);
const issues: AmbiguityAnalysis['issues'] = [];
Object.entries(VAGUE_TERMS).forEach(([term, config]) => {
if (lowerText.includes(term)) {
issues.push({ term, ...config });
}
});
// Score ponderado por severidade
const weights = { low: 0.2, medium: 0.5, high: 1.0 };
const totalWeight = issues.reduce((sum, i) => sum + weights[i.severity], 0);
const score = Math.min(totalWeight / words.length * 4, 1.0);
return {
score,
issues,
requiresHumanReview: score > 0.3 || issues.some(i => i.severity === 'high')
};
}
// Exemplo com requisito problemático
const req = "O sistema deve processar transações rapidamente de forma eficiente";
const analysis = analyzeAmbiguity(req);
console.log(`Score: ${(analysis.score * 100).toFixed(0)}%`);
console.log(`Revisão humana: ${analysis.requiresHumanReview ? 'SIM' : 'Não'}`);
analysis.issues.forEach(i => {
console.log(` 🔴 "${i.term}": ${i.suggestion}`);
});
/* Output:
Score: 67%
Revisão humana: SIM
🔴 "rapidamente": Defina SLA numérico
🔴 "eficiente": Defina métrica (ex: "< 100MB RAM")
*/
Note que a ferramenta encontra candidatos, não resolve ambiguidades. A resolução requer conhecimento de domínio: "rapidamente" para um sistema de trading significa microssegundos; para um CRM, segundos são aceitáveis. O engenheiro de requisitos permanece essencial para interpretar alertas no contexto correto.
Elicitação via Chatbots: Escala com Ressalvas
Uma aplicação promissora de IA é a elicitação automatizada via chatbots. Em vez de agendar entrevistas com dezenas de stakeholders, um chatbot conversacional pode coletar requisitos de centenas de usuários simultaneamente.
Chatbots automatizam elicitação em escala impressionante: 50 stakeholders em 3 dias vs. 2 semanas para 15 entrevistas humanas. O framework LLMREI (2024) conduz entrevistas com prompts few-shot, gerando requisitos com 65% de equivalência a humanos segundo estudos recentes. ChatGPT-4 demonstra superioridade particular em requisitos não-funcionais (75% accuracy).
Chatbots seguem roteiros estruturados. Fazem perguntas predefinidas, registram respostas, e podem fazer follow-ups básicos. Porém, não capturam hesitações reveladoras, contradições sutis, ou requisitos que stakeholders não sabem que têm. Um entrevistador experiente percebe quando alguém evita um tema, quando há tensão política entre departamentos, quando um requisito "óbvio" esconde complexidade não articulada.Em caso de startup fast-food documentado, chatbot alcançou cobertura total de 50 franqueados, mas nuances sobre operação noturna e sazonalidade só emergiram em entrevistas de follow-up.
A abordagem híbrida emergente usa chatbots para triagem inicial e cobertura ampla, reservando entrevistas humanas para casos críticos e validação profunda. O chatbot coleta requisitos de 200 vendedores em uma semana; o engenheiro entrevista os 10 que reportaram casos extremos ou inconsistentes. Essa combinação maximiza cobertura sem sacrificar profundidade onde ela importa.
Workflows Híbridos: O Padrão Emergente
A implementação bem-sucedida de IA em requisitos exige workflows híbridos cuidadosamente desenhados. O princípio central: IA processa volume e detecta padrões; humanos validam contexto e tomam decisões. A divisão de responsabilidades deve ser explícita.
/**
* Workflow híbrido de análise de requisitos
*
* Demonstra o padrão de triagem automática + validação humana
* que maximiza eficiência sem comprometer qualidade
*/
interface RequirementReview {
requirementId: string;
text: string;
automatedAnalysis: {
ambiguityScore: number;
duplicateCandidates: string[];
missingElements: string[];
};
reviewDecision: 'auto-approved' | 'needs-review' | 'flagged-critical';
humanReviewRequired: boolean;
reasoning: string;
}
function triageRequirement(
reqId: string,
text: string,
ambiguityScore: number,
duplicates: string[],
missing: string[],
isCriticalDomain: boolean // Ex: saúde, financeiro, segurança
): RequirementReview {
// Regra 1: Domínios críticos SEMPRE requerem revisão humana
if (isCriticalDomain) {
return {
requirementId: reqId,
text,
automatedAnalysis: { ambiguityScore, duplicateCandidates: duplicates, missingElements: missing },
reviewDecision: 'flagged-critical',
humanReviewRequired: true,
reasoning: 'Domínio crítico: revisão humana obrigatória independente de score'
};
}
// Regra 2: Alta ambiguidade OU duplicatas → revisão humana
if (ambiguityScore > 0.5 || duplicates.length > 0) {
return {
requirementId: reqId,
text,
automatedAnalysis: { ambiguityScore, duplicateCandidates: duplicates, missingElements: missing },
reviewDecision: 'needs-review',
humanReviewRequired: true,
reasoning: ambiguityScore > 0.5
? `Ambiguidade elevada (${(ambiguityScore * 100).toFixed(0)}%): validar interpretação`
: `${duplicates.length} possível(is) duplicata(s): confirmar se são realmente distintos`
};
}
// Regra 3: Elementos faltantes → revisão humana
if (missing.length > 0) {
return {
requirementId: reqId,
text,
automatedAnalysis: { ambiguityScore, duplicateCandidates: duplicates, missingElements: missing },
reviewDecision: 'needs-review',
humanReviewRequired: true,
reasoning: `Elementos não detectados: ${missing.join(', ')}. Verificar se requisito está completo.`
};
}
// Regra 4: Baixa ambiguidade + sem problemas → aprovação automática
return {
requirementId: reqId,
text,
automatedAnalysis: { ambiguityScore, duplicateCandidates: duplicates, missingElements: missing },
reviewDecision: 'auto-approved',
humanReviewRequired: false,
reasoning: `Score baixo (${(ambiguityScore * 100).toFixed(0)}%), sem duplicatas, elementos completos`
};
}
// Simulação de análise de batch
const requirements = [
{ id: 'REQ-001', text: 'Sistema deve permitir login com email e senha', domain: 'auth' },
{ id: 'REQ-002', text: 'Sistema deve processar pagamentos rapidamente', domain: 'financial' },
{ id: 'REQ-003', text: 'Usuário pode visualizar histórico de pedidos', domain: 'ecommerce' },
];
console.log("=== Triagem Automatizada de Requisitos ===\n");
requirements.forEach(req => {
// Simula análise (em produção, viria de funções anteriores)
const isCritical = ['financial', 'health', 'security'].includes(req.domain);
const mockScore = req.text.includes('rapidamente') ? 0.7 : 0.15;
const review = triageRequirement(
req.id,
req.text,
mockScore,
[], // duplicatas
[], // elementos faltantes
isCritical
);
const icon = {
'auto-approved': '✅',
'needs-review': '⚠️',
'flagged-critical': '🔴'
}[review.reviewDecision];
console.log(`${icon} ${review.requirementId}: ${review.reviewDecision}`);
console.log(` Razão: ${review.reasoning}\n`);
});
/* Output esperado:
=== Triagem Automatizada de Requisitos ===
✅ REQ-001: auto-approved
Razão: Score baixo (15%), sem duplicatas, elementos completos
🔴 REQ-002: flagged-critical
Razão: Domínio crítico: revisão humana obrigatória independente de score
✅ REQ-003: auto-approved
Razão: Score baixo (15%), sem duplicatas, elementos completos
*/
O workflow acima ilustra um princípio crucial: a IA não decide em contextos críticos. Para sistemas de saúde, financeiros ou de segurança, 100% dos requisitos passam por revisão humana — a IA apenas prioriza quais revisar primeiro. Economia de tempo real vem de eliminar revisão manual em requisitos claramente bem especificados de domínios de baixo risco.
Limitações Fundamentais: O Que IA Não Faz
Seria negligente encerrar sem discutir o que IA não consegue fazer — pelo menos não com a tecnologia atual. Essas limitações não são bugs a serem corrigidos; são fronteiras fundamentais entre processamento algorítmico e cognição humana.
Contexto organizacional: IA não sabe que o "sistema legado" mencionado em requisitos é politicamente intocável porque foi projeto do atual CTO. Não detecta que dois departamentos usam o mesmo termo com significados diferentes porque nunca conversaram. Não percebe que um requisito foi escrito vagamente de propósito para evitar comprometimento prematuro.
Requisitos implícitos: Stakeholders frequentemente omitem requisitos "óbvios" que só se tornam explícitos quando violados. "O sistema não deve apagar dados do cliente" raramente aparece em documentos — mas sua violação é catastrófica. IA treinada em texto não infere o não-dito.
Viabilidade técnica: Um requisito pode ser linguisticamente perfeito e tecnicamente impossível. "Sistema deve prever demanda com 99.9% de precisão" é claro, mas irrealizável para a maioria dos domínios. Avaliar viabilidade requer expertise técnica que IA não possui.
Negociação e priorização: Quando recursos são limitados, requisitos competem. A decisão de priorizar funcionalidade A sobre B envolve estratégia de negócio, relacionamentos com clientes, capacidade da equipe — fatores que nenhum algoritmo pondera adequadamente.
Conclusão: Orquestradores, Não Operadores
A Engenharia de Requisitos assistida por IA transforma o papel profissional: menos tempo em tarefas mecânicas de revisão (IA detecta 75-85% dos padrões), mais tempo em decisões estratégicas que exigem julgamento humano. Os dados são claros — economia de 40% em tempo, redução de 10% em bugs — mas apenas quando humanos validam outputs e cobrem gaps que algoritmos não alcançam.
A pergunta para vocês, futuros engenheiros: não é se usar IA, mas como construir workflows que maximizem cada componente. O engenheiro de requisitos de 2030 será avaliado não por quantos requisitos escreve, mas por quão bem orquestra sistemas híbridos que entregam qualidade em escala.
REFERÊNÇÕES PARA APROFUNDAMENTO
Papers Acadêmicos
-
Ronanki et al. (2023). Investigating ChatGPT's Potential in RE. Euromicro Conf.
- Link: https://arxiv.org/abs/2307.07381
- Por que ler: Qualidade requisitos LLMs vs. humanos.
Almeida, C. el tal. (2025). From Elicitation Interviews to Software Requirements: Evaluating LLM Performance in Requirement Generation.
Por que ler: Precision/recall ChatGPT-4/DeepSeek.
Link: https://werpapers.dimap.ufrn.br/papers/WER2025/wer202511.pdf
-
Davila, A. et al. (2025). LLM-based ambiguity detection in natural language instructions for collaborative surgical robots. Accepted at 2025 IEEE International Conference on Robot and Human Interactive Communication (ROMAN)
- Por que ler: 82.5% accuracy Gemma 3.
- Link: https://arxiv.org/html/2507.11525v1
-
Zhang et al. (2023). ML for Ambiguity Detection.
- Por que ler: Precision 82.5% TF-IDF.
- Link: https://discovery.ucl.ac.uk/id/eprint/10174754/1/2023_EC3_revised_final.pdf
Ferramentas e Frameworks
- node-nlp-typescript
- Link: https://github.com/Leoglme/node-nlp-typescript
Por que usar: NER/intents TypeScript.
wink-nlp
Por que usar: Tokenização/performante.
Transformers.js (Hugging Face)
Por que usar: Embeddings browser/Node.
Datasets Públicos
- PURE Dataset
- Link: Zenodo
- Por que usar: 34k sentenças RE benchmark.
Top comments (0)