A especificação funcional SAP (FS) descreve o que o processo de negócio precisa fazer e por quê. A especificação técnica (TS) descreve como o sistema vai fazer: objetos, lógica, interfaces e testes. Juntas, elas traduzem uma demanda de negócio em desenvolvimento SAP. Quando uma das duas chega incompleta, o custo raramente aparece no documento. Aparece depois, em retrabalho no código, ajuste em QAS ou correção emergencial em produção.

Este guia reúne o que cada documento precisa ter, onde ele costuma falhar e como a especificação se conecta ao resto da mudança, até o transporte.

O que é a especificação funcional (FS) no SAP

A FS é escrita, em geral, pelo consultor ou analista funcional a partir da conversa com a área de negócio. Ela registra o contexto, o processo atual e o desejado, as regras de negócio e os critérios que vão dizer se a entrega está certa.

Em projetos de implantação, ela costuma nascer depois do desenho de processos. Se o seu projeto ainda está nessa etapa, vale ler também como construir um BPD eficiente em projetos S/4HANA, porque uma FS consistente depende de um processo bem desenhado antes dela.

O que é a especificação técnica (TS) no SAP

A TS é a tradução da FS para a linguagem do desenvolvimento. Normalmente é escrita pelo desenvolvedor ABAP ou pelo arquiteto técnico e define quais objetos serão criados ou alterados, onde a lógica entra, como os dados trafegam e como a solução será testada.

É na TS que se decide, por exemplo, se a necessidade será atendida com configuração, com uma extensão nos pontos previstos pela SAP ou com código Z. Essa decisão pesa no longo prazo, como mostramos ao falar do modelo A-B-C-D de classificação de extensões.

Por que tanto retrabalho em SAP começa antes do código

Quando um desenvolvimento volta de QAS com um “não era bem isso”, a primeira suspeita costuma ser o código. Muitas vezes, a causa está um passo antes: uma regra de negócio que ficou implícita, uma exceção que ninguém escreveu ou um impacto em outro módulo que não foi mapeado.

A especificação passa por várias mãos. O negócio explica para o funcional, o funcional escreve para o ABAP, o ABAP desenvolve e o Basis transporta. Cada troca de mão é uma oportunidade de perder contexto. E quanto mais tarde essa perda é descoberta, mais caro fica corrigir.

Esse custo se acumula em silêncio. Código escrito para atender a uma especificação ambígua tende a virar código Z difícil de manter, que entra no cálculo de quanto custa o seu código Z e pesa na preparação para o Clean Core.

O que uma especificação funcional SAP precisa ter

Não existe um modelo único de especificação funcional SAP, e cada empresa ou integradora tem o seu. Mas alguns blocos aparecem em quase toda especificação que chega inteira ao desenvolvimento:

• Contexto e objetivo. Qual problema de negócio a demanda resolve e quem é afetado por ela.
• Processo atual e processo desejado (AS-IS e TO-BE). O que acontece hoje e o que precisa acontecer depois da mudança.
• Regras de negócio explícitas. Inclusive as óbvias para quem pede. É justamente o óbvio que costuma ficar de fora.
• Exceções e cenários alternativos. O que fazer quando o dado não existe, quando o valor está fora da faixa, quando o documento é estornado.
• Dados de entrada e saída. Campos, origem, formato e destino.
• Impactos em outros módulos e integrações. Uma alteração em vendas pode afetar fiscal, financeiro ou uma interface com outro sistema.
• Autorizações. Quem pode executar a nova funcionalidade, considerando as regras de segregação de funções (SoD).
• Critérios de aceite. Como o negócio vai dizer, de forma verificável, que a entrega está correta.

O que uma especificação técnica SAP precisa ter

A TS precisa permitir que outro desenvolvedor entenda e mantenha a solução sem depender de quem a escreveu. Os blocos mais comuns são:

• Referência à FS de origem. A rastreabilidade entre os dois documentos é o que permite saber, anos depois, por que aquele código existe.
• Abordagem técnica escolhida e alternativas descartadas. Configuração, extensão ou desenvolvimento Z, com a justificativa.
• Lista de objetos. Programas, classes, enhancements, CDS views, tabelas e o que será criado ou alterado em cada um.
• Lógica de processamento. Descrita no nível suficiente para revisão, sem virar o próprio código.
• Interfaces e tratamento de erros. O que acontece quando uma integração falha.
• Cuidados de performance. Volume esperado, acessos a tabelas grandes e pontos sensíveis.
• Plano de testes. Testes unitários e cenários derivados dos critérios de aceite da FS.
• Dependências de transporte. Objetos que precisam subir juntos ou em sequência pelo sistema de transporte da SAP (TMS).

O último item costuma ser esquecido e está entre os que mais geram incidente. Uma request importada fora de ordem pode sobrescrever objeto em produção, tema que detalhamos no guia de governança de transportes SAP.

Os erros mais comuns em FS/TS

Documento escrito depois do código. Quando o prazo aperta, a especificação vira formalidade para fechar o chamado. Nesse caso, ela descreve o que foi feito, não o que foi pedido, e deixa de servir como referência para teste e auditoria.

Versões diferentes circulando. FS em um arquivo de texto, ajustes por e-mail e decisões em conversa. O desenvolvedor trabalha em uma versão, o testador valida outra.

Critério de aceite vago. “O relatório deve trazer as informações corretas” não é critério. Critério é algo que um teste consegue confirmar ou negar.

Código existente ignorado. Em ambientes com muitos anos de customização, a nova demanda quase sempre conversa com algo que já existe. Especificar sem olhar o código atual aumenta a chance de duplicar lógica ou quebrar uma dependência.

Especificação desconectada da request. Quando não há ligação entre a FS, a TS e as requests que foram para produção, a empresa perde a capacidade de responder por que uma mudança foi feita, quem aprovou e como ela foi testada.

FS/TS na era da IA no ABAP

Com a IA gerando código ABAP em minutos, a especificação ganhou um papel ainda mais central. A IA executa o que recebe. Uma FS/TS vaga vira código vago mais rápido, e cada nova tentativa consome tempo e, em ferramentas cobradas por uso, orçamento. Discutimos isso no artigo sobre o que muda com a IA agêntica no ABAP e com o custo por uso.

A IA também pode ajudar a escrever a especificação, desde que trabalhe com o contexto real do ambiente: o processo, o código existente e o padrão de desenvolvimento da casa. Uma especificação gerada sem esse contexto parece completa, mas carrega as mesmas lacunas de antes. Explicamos esse ponto no artigo sobre por que gerar código ABAP com IA é a parte fácil.

Há ainda uma questão de segurança da informação. Colar FS, TS ou código Z em ferramentas públicas de IA pode expor regra de negócio e propriedade intelectual. Vale definir onde a IA roda e quem tem acesso ao que ela produz.

Especificação, transporte e auditoria são a mesma mudança

Especificar, desenvolver e transportar costumam ter donos, ferramentas e documentos diferentes. Mas, para o negócio e para a auditoria, são etapas de uma única mudança. Quando elas não estão conectadas, é na passagem entre uma e outra que o contexto se perde.

Na prática, cada request que chega à produção deveria responder a quatro perguntas: qual demanda a originou, qual especificação a descreve, como foi testada e quem aprovou. Na Döhler, por exemplo, cada objeto ABAP passou a ser analisado antes do transporte, com aprovação rastreável entre desenvolvedor, analista funcional e liderança técnica.

Onde a QAMetrik entra

Foi dessa constatação que nasceu o MoveOn, plataforma da QAMetrik que conecta a especificação com IA, o desenvolvimento ABAP no padrão da casa e a governança de cada request até a produção. Se a sua empresa terceiriza parte do desenvolvimento, também vale entender o que separa uma entrega de qualidade de um novo problema na fábrica de software.

Se a dúvida é por onde começar, o QA Assessment mostra como estão o código, a documentação e o processo de mudança do seu ambiente hoje. Para conversar sobre um caso real, fale com a nossa equipe.

Perguntas frequentes

Qual a diferença entre especificação funcional SAP e especificação técnica?

A especificação funcional descreve o que o processo de negócio precisa e por quê. A especificação técnica descreve como o sistema vai atender a essa necessidade: objetos, lógica, interfaces e testes.

Quem escreve a FS e a TS?

Em geral, a FS é escrita pelo consultor ou analista funcional, e a TS pelo desenvolvedor ABAP ou arquiteto técnico. Em times menores, a mesma pessoa pode escrever as duas, mas os conteúdos continuam diferentes.

Toda demanda SAP precisa de FS e TS?

Não necessariamente com o mesmo nível de detalhe. Ajustes simples de configuração podem ter um registro mais curto. Mas toda mudança que chega à produção deveria ter, ao menos, a justificativa, o que foi alterado, como foi testada e quem aprovou.

Dá para usar IA para escrever especificação funcional SAP?

Dá, e ela pode acelerar a escrita. O cuidado é garantir que a IA trabalhe com o contexto real do ambiente, que o resultado seja revisado por quem conhece o processo e que os dados não sejam expostos em ferramentas fora do controle da empresa.

Quem governa a mudança entrega mais rápido. Quem não governa entrega risco.