Como especificar controle de acesso por desempenho: requisitos, equivalência técnica, interfaces, critérios de aceitação, FAT/SAT e neutralidade de fabricante.
Confira!
Especificação por desempenho em controle de acesso é a forma de definir o que o sistema deve fazer, em quais condições, com qual nível de desempenho e como esse resultado será comprovado, sem transformar uma marca ou um catálogo comercial no próprio requisito técnico. Em vez de copiar características de um produto de referência, a engenharia converte necessidades de segurança, operação, integração e ciclo de vida em requisitos verificáveis.
Essa abordagem não significa escrever especificações genéricas nem aceitar qualquer solução. Uma boa especificação técnica de controle de acesso pode ser rigorosa em funções, disponibilidade, interfaces, segurança, classes ambientais, logs, comportamento offline, integração, testes e documentação. A diferença é que cada exigência precisa estar ligada a uma necessidade do projeto e possuir um critério de aceitação objetivo.
Especificar por desempenho começa pela necessidade, não pelo equipamento
Uma especificação forte não começa pelo modelo de equipamento: começa pela necessidade, converte-a em requisito e já define como a conformidade será comprovada.
Estruturar requisitos dentro do Projeto de Controle de Acesso
O ponto de partida é a pergunta: qual resultado o sistema precisa produzir? Se a necessidade é impedir acesso não autorizado a uma área crítica, o requisito não começa pelo modelo de leitor; começa pelo nível de autenticação, política de autorização, comportamento da porta, supervisão, rastreabilidade e resposta a falhas requeridos para aquele risco.
Só depois dessa camada funcional a engenharia transforma necessidades em requisitos de sistema e, por fim, em características mínimas dos componentes.
Uma cadeia de requisitos evita especificações arbitrárias
Uma estrutura útil conecta quatro níveis:
- necessidade operacional — o problema que precisa ser resolvido;
- requisito de sistema — o comportamento que a solução deve entregar;
- requisito de componente ou interface — o mínimo necessário para o sistema cumprir a função;
- critério de aceitação — a evidência que demonstrará conformidade.
Exemplo: a necessidade de detectar violação de uma porta pode gerar requisito de supervisão do estado da folha; isso gera necessidade de contato de porta e entrada apropriada; o critério de aceitação passa a ser provocar abertura não autorizada e verificar evento, timestamp, alarme e registro.
Requisito funcional descreve comportamento observável
Requisitos funcionais devem dizer o que acontece diante de uma condição. Em controle de acesso, isso inclui autenticar, autorizar, negar, liberar, bloquear, registrar, alarmar, sincronizar, integrar e operar em modos degradados ou extraordinários.
Um requisito funcional é mais útil quando contém condição, ação e resultado esperado. “Possuir anti-passback” é incompleto; é necessário definir onde a regra se aplica, se é hard ou soft, quais eventos atualizam estado, como usuários são reinicializados e o que ocorre em contingência.
Da mesma forma, “integrar com CFTV” não define uma interface verificável. O projeto precisa estabelecer se eventos de acesso devem chamar vídeo ao vivo, associar gravações, criar bookmarks, acionar presets, gerar alarmes no VMS ou simplesmente trocar identificadores por API.
A matriz funcional é um instrumento de especificação
A matriz funcional de controle de acesso permite separar regras de negócio e comportamento das plantas físicas. Ela pode registrar por ponto ou grupo de pontos funções como:
- leitor de entrada e/ou saída;
- anti-passback;
- dupla autenticação;
- horários e calendários;
- intertravamento;
- lockdown ou modo de emergência;
- integração com incêndio;
- alarmes de porta;
- CFTV/VMS;
- duress;
- operação offline.
Essa estrutura reduz a dependência de descrições vagas e facilita transformar requisitos em roteiro de teste.
Requisito de desempenho precisa ser mensurável quando o desempenho importa
“Alta disponibilidade”, “rápido”, “robusto” ou “seguro” não são especificações verificáveis. Quando uma característica é relevante, o projeto deve expressá-la de forma que possa ser demonstrada ou documentada.
Dependendo da função, podem ser definidos critérios como:
- tempo máximo para propagação de uma alteração de credencial;
- capacidade mínima de credenciais e eventos locais;
- comportamento durante perda de comunicação com o servidor;
- autonomia mínima de alimentação;
- tempo de retenção de eventos conforme política da organização;
- grau de proteção IP e resistência IK para ambiente externo;
- quantidade de portas por controladora dentro da arquitetura escolhida;
- número de transações ou eventos que o sistema deve processar;
- limites de latência de uma integração quando operacionalmente relevantes;
- recuperação após reinicialização ou perda de comunicação.
Nem todo requisito precisa virar um número. Alguns são binários e funcionais. O princípio é que a forma de verificação seja conhecida antes da compra.
Especificar “igual ou superior” sem método de equivalência cria ambiguidade
Equivalência técnica exige critérios prévios. Comparar propostas apenas contra um datasheet de referência pode transformar características incidentais em restrições sem valor para o sistema.
A expressão “ou equivalente” só é tecnicamente útil quando o documento define quais características determinam equivalência. Se uma proposta alternativa é avaliada comparando dezenas de campos de um datasheet de referência, atributos incidentais podem se transformar em barreiras sem relação com a necessidade real.
A engenharia deve separar:
| Tipo de atributo | Tratamento recomendado |
| requisito indispensável | deve ser atendido e comprovado |
| requisito mínimo de desempenho | admite valor igual ou superior quando tecnicamente comparável |
| faixa aceitável | deve permanecer dentro dos limites definidos |
| interface obrigatória | deve implementar padrão, protocolo ou API requeridos |
| atributo desejável | pode diferenciar tecnicamente sem bloquear habilitação mínima |
| característica incidental do produto de referência | não deve virar requisito sem justificativa |
Esse raciocínio é especialmente relevante quando se usa equipamento de referência durante projeto ou orçamento. O produto ajuda a testar viabilidade e custo, mas não deve ser convertido automaticamente em retrato obrigatório da futura solução.
A IEC 60839 ajuda a separar função, desempenho e método de ensaio
A IEC 60839-11-1 estabelece requisitos mínimos de funcionalidade e desempenho, além de métodos de ensaio, para sistemas eletrônicos de controle de acesso e seus componentes. Essa organização é valiosa porque evita tratar segurança apenas como lista de produtos.
A especificação do projeto pode usar normas como base para definir funções, classes e testes, complementando aquilo que a aplicação exige. A norma não elimina a necessidade de engenharia de requisitos: cada ambiente continua precisando de análise de risco, arquitetura, integrações e critérios de aceitação compatíveis com sua operação.
O artigo ABNT NBR IEC 60839: requisitos para sistemas de controle de acesso detalha como a norma se conecta ao projeto.
Norma técnica deve ser citada no nível correto
Não é adequado escrever apenas “atender às normas aplicáveis”. Quando uma norma realmente fundamenta um requisito, o projeto deve identificá-la e deixar claro em que parte ela é usada: função, ensaio, instalação, ambiente, interface ou documentação.
Isso facilita a análise de proposta e reduz disputas na fase de aceitação.
Interfaces e interoperabilidade devem ser especificadas pelo resultado necessário
Protocolos e perfis podem ser requisitos válidos quando respondem a uma necessidade de interoperabilidade, cibersegurança ou governança. O erro é exigir um nome tecnológico sem definir a função associada.
Para uma interface leitor-controladora, por exemplo, OSDP pode ser requerido juntamente com supervisão, comunicação bidirecional e Secure Channel quando esses recursos fizerem parte da arquitetura. Para integração entre plataformas, uma API deve ser acompanhada de operações, autenticação, eventos, objetos e responsabilidades esperadas.
Em cenários multivendor, ONVIF em controle de acesso é outro exemplo: não basta escrever “compatível com ONVIF”; o projeto precisa identificar Profile, papel device/client, funções requeridas e forma de comprovação.
Cibersegurança não pode ser reduzida a uma marca considerada “segura”
Requisitos de cibersegurança devem ser descritos em controles e comportamentos. Conforme o risco e a arquitetura, podem incluir:
- comunicação protegida;
- gestão de certificados;
- desativação de serviços desnecessários;
- segregação de privilégios administrativos;
- política de senhas e autenticação;
- logs administrativos;
- atualização segura de firmware;
- suporte a backup e restauração;
- sincronização de tempo;
- documentação de vulnerabilidades e ciclo de correções;
- possibilidade de integração com infraestrutura corporativa de identidade.
Exigir uma marca não comprova que esses controles estarão configurados corretamente no sistema entregue.
Requisitos ambientais precisam refletir o local de instalação
Especificar IP66 ou IK10 para todos os equipamentos pode parecer rigoroso, mas é tecnicamente inadequado quando não existe exposição correspondente. Além de restringir mercado, requisitos ambientais excessivos podem elevar custo sem reduzir risco.
A especificação deve derivar do ambiente: chuva, lavagem, poeira, impacto, vandalismo, temperatura, radiação solar, corrosão e localização protegida ou exposta.
O artigo sobre grau de proteção IP e IK no controle de acesso detalha como transformar condições ambientais em requisito de invólucro sem usar IP e IK como números decorativos.
Requisitos de capacidade devem considerar crescimento e arquitetura
Copiar a capacidade máxima de uma controladora de referência pode distorcer o projeto. O correto é avaliar quantos pontos cada unidade precisa atender, qual a reserva requerida, como ocorre expansão, quais funções são processadas localmente e o impacto de uma falha.
Uma arquitetura distribuída pode preferir controladoras menores para reduzir domínio de falha. Outra aplicação pode exigir concentração maior por características do prédio. A especificação por desempenho deve permitir a arquitetura que melhor atende ao requisito, desde que limites e consequências estejam documentados.
Licenças e software precisam fazer parte da equivalência técnica
Dois sistemas com hardware semelhante podem ter modelos de software muito diferentes. A proposta precisa contemplar tudo que é necessário para cumprir o escopo ao longo do período requerido.
Devem ser esclarecidos, conforme o caso:
- licenças de servidor;
- portas ou dispositivos;
- usuários operadores;
- módulos de integração;
- APIs;
- alta disponibilidade;
- mobile credentials;
- analíticos ou funções avançadas;
- manutenção e atualização;
- subscrições obrigatórias;
- custos para expansão.
Uma solução não é equivalente se atende o requisito apenas mediante módulos omitidos da composição comercial.
Critérios de aceitação precisam nascer junto com os requisitos
Se um requisito não possui método de verificação, sua fiscalização será subjetiva. A especificação deve definir desde o projeto quais evidências serão aceitas: datasheet, certificado, declaração do fabricante, demonstração, FAT, SAT, inspeção, ensaio de campo ou relatório do sistema.
Nem tudo deve ser comprovado da mesma forma
Uma classe IP pode ser verificada por documentação e certificação aplicável; comportamento de porta forçada precisa ser testado funcionalmente; integração por API exige demonstração; autonomia de bateria pode exigir memória de cálculo e teste; capacidade de armazenamento pode ser validada por documentação, configuração e evidência de operação.
A matriz de requisitos pode incluir colunas como:
| ID | Requisito | Criticidade | Evidência de proposta | Teste FAT | Teste SAT |
| RF-01 | negar acesso fora do horário autorizado | obrigatório | declaração de atendimento | sim | sim |
| RI-02 | comunicação leitor-controladora supervisionada | obrigatório | documentação técnica | sim | sim |
| RA-03 | proteção ambiental conforme área externa | obrigatório | ficha/certificação | não | inspeção |
| RL-04 | registrar alterações administrativas | obrigatório | documentação | sim | sim |
Essa matriz transforma especificação em mecanismo de governança do projeto.
FAT e SAT devem comprovar o resultado contratado
FAT e SAT não devem ser listas genéricas anexadas no fim do projeto. O roteiro deve derivar dos requisitos e preservar o ID de cada item para que exista rastreabilidade entre projeto, proposta, implantação e aceitação.
O FAT é especialmente útil para integrações, regras complexas, operação offline, importação de usuários, perfis, logs e cenários de falha que podem ser reproduzidos em bancada. O SAT confirma o desempenho no ambiente real: portas, rede, alimentação, cabeamento, integrações de campo e condições operacionais.
O comissionamento de sistemas de controle de acesso fecha essa cadeia ao produzir evidências de que a solução instalada cumpre os requisitos projetados.
Em contratação pública, indicação de marca é exceção que exige justificativa
A engenharia de desempenho é particularmente útil em licitações públicas, mas este artigo não substitui a análise jurídica do processo. A Lei nº 14.133/2021 trata a indicação de uma ou mais marcas ou modelos como possibilidade excepcional, condicionada às hipóteses e à justificativa previstas no art. 41. O art. 42 disciplina meios de comprovação da qualidade de produto apresentado como similar quando houver referência de marca.
Para a engenharia, a consequência prática é clara: quando a necessidade pode ser descrita por função, desempenho, interfaces, normas e critérios de aceitação, esses parâmetros devem aparecer no documento em vez de depender implicitamente de um catálogo de fabricante. Quando existe justificativa real de padronização ou compatibilidade, ela precisa estar documentada como decisão do projeto e do processo de contratação.
O TCU, em orientação técnica sobre especificações de obras públicas, também recomenda caracterizar materiais, equipamentos e serviços para o desempenho técnico pretendido, sem reproduzir catálogos de um fabricante e com condições de aceitação de similares. Embora essa publicação seja anterior à Lei 14.133, o raciocínio técnico continua útil para evitar especificações que confundem requisito com produto de referência.
“Sem amarrar fabricante” não significa neutralidade artificial
Existem situações em que compatibilidade com base instalada, padronização institucional, continuidade operacional ou propriedade intelectual de uma integração restringem tecnicamente alternativas. Esconder essa condição atrás de requisitos artificiais é pior do que documentá-la.
Uma especificação madura distingue:
- requisito tecnicamente aberto;
- requisito limitado por compatibilidade comprovada;
- interface proprietária existente que precisa ser mantida ou substituída;
- referência comercial usada apenas para orçamento;
- referência de qualidade acompanhada de método de equivalência;
- condição excepcional que exige justificativa formal no processo de contratação.
A função da engenharia é tornar essas decisões explícitas e auditáveis.
Como revisar uma especificação para identificar brand lock acidental
Antes de emitir o documento, cada requisito pode ser testado com perguntas simples:
- qual necessidade justifica este requisito?
- existe mais de uma forma técnica de atender ao resultado?
- o valor mínimo decorre de cálculo, norma, risco ou apenas de um datasheet?
- o requisito é indispensável ou apenas desejável?
- existe método de comprovação?
- uma alternativa tecnicamente equivalente seria rejeitada por detalhe sem impacto no sistema?
- a combinação de requisitos reduz o mercado a um único produto sem justificativa?
- o requisito continuará fazendo sentido quando o modelo de referência sair de linha?
Esse exercício não enfraquece a especificação. Ele remove detalhes sem valor e torna os requisitos realmente importantes mais defensáveis.
A especificação deve acompanhar todo o ciclo do Projeto de Controle de Acesso
O documento de requisitos não serve apenas para cotação. Ele alimenta projeto executivo, análise técnica de propostas, submittals, FAT, instalação, SAT, comissionamento, As Built e operação assistida.
Por isso, uma boa especificação deve ser organizada de forma rastreável, com IDs estáveis, revisão controlada e critérios que possam ser reutilizados nas etapas seguintes. Alterações feitas durante a implantação precisam retornar ao baseline documental para que a condição aceita seja conhecida.
A página de Projeto de Controle de Acesso apresenta essa especificação como parte de um processo maior de engenharia, integrado a arquitetura, interfaces, quantitativos e critérios de aceitação.
Considerações finais
Especificar por desempenho não é escrever menos: é escrever aquilo que realmente importa. Um projeto forte define comportamento, desempenho, interfaces, ambiente, capacidade, cibersegurança, documentação e testes com precisão suficiente para comparar propostas e aceitar o sistema entregue.
Quando requisitos são rastreáveis até necessidades e possuem evidências objetivas, a engenharia consegue ser simultaneamente mais aberta à concorrência e mais exigente tecnicamente. O resultado é uma especificação que permanece válida mesmo quando marcas e modelos mudam — porque o objeto contratado é o desempenho do sistema, não o catálogo que serviu de referência durante o projeto.
Requisito sem critério de aceitação é difícil de fiscalizar. Projeto, proposta, FAT, SAT e comissionamento devem compartilhar a mesma matriz de requisitos e evidências.
Referências técnicas
[1] BRASIL. Lei nº 14.133, de 1º de abril de 2021 — Lei de Licitações e Contratos Administrativos. Disponível em: https://www.planalto.gov.br/ccivil_03/_ato2019-2022/2021/lei/l14133.htm.
[2] TRIBUNAL DE CONTAS DA UNIÃO. Obras Públicas: Recomendações Básicas para a Contratação e Fiscalização de Obras de Edificações Públicas — 4ª edição. Disponível em: https://portal.tcu.gov.br/data/files/1E/26/8A/06/23DEF610F5680BF6F18818A8/Obras_publicas_recomendacoes_basicas_contratacao_fiscalizacao_obras_edificacoes_publicas_4_edicao.PDF.
[3] ADVOCACIA-GERAL DA UNIÃO. Modelos da Lei nº 14.133/21 para pregão e concorrência. Disponível em: https://www.gov.br/agu/pt-br/composicao/cgu/cgu/modelos/licitacoesecontratos/14133/pregao-e-concorrencia.
[4] INTERNATIONAL ELECTROTECHNICAL COMMISSION. IEC 60839-11-1:2013 — Alarm and electronic security systems — Part 11-1: Electronic access control systems — System and components requirements. Disponível em: https://webstore.iec.ch/en/publication/3662.
[5] INTERNATIONAL ELECTROTECHNICAL COMMISSION. IEC 60839-11-2:2014 — Alarm and electronic security systems — Part 11-2: Electronic access control systems — Application guidelines. Disponível em: https://webstore.iec.ch/en/publication/3663.
Perguntas frequentes
É a definição do resultado técnico esperado — funções, desempenho, interfaces, segurança, condições ambientais e critérios de aceitação — sem transformar características incidentais de uma marca ou modelo em requisitos obrigatórios.
Não. A especificação pode ser rigorosa e conter requisitos mínimos, normas, interfaces obrigatórias, classes ambientais, capacidade, cibersegurança e testes. A diferença é que cada exigência deve estar relacionada à necessidade e possuir forma objetiva de comprovação.
Primeiro identifique os requisitos indispensáveis e mínimos de desempenho. Depois separe faixas aceitáveis, interfaces obrigatórias e atributos apenas desejáveis. A equivalência deve ser julgada contra essa matriz, não pela cópia integral do datasheet de um modelo de referência.
A Lei 14.133/2021 prevê indicação de marca ou modelo em caráter excepcional nas hipóteses do art. 41 e exige justificativa. A análise jurídica deve considerar o caso concreto; tecnicamente, requisitos de função, desempenho e aceitação devem estar explicitados sempre que forem a verdadeira necessidade do objeto.
Os testes devem nascer dos requisitos. Cada requisito relevante deve indicar como será verificado e, quando aplicável, em qual etapa. Isso cria rastreabilidade entre projeto, proposta, FAT, instalação, SAT e comissionamento.
Sim, por exemplo para estudo de viabilidade, orçamento ou compreensão técnica. O cuidado é não converter automaticamente cada característica desse produto em requisito obrigatório. O projeto deve extrair apenas os atributos necessários ao desempenho pretendido ou justificar limitações de compatibilidade e padronização.
Materiais técnicos complementares
Serviços relacionados
Conteúdos principais sobre o tema
- Sistema de Controle de Acesso: tipos, tecnologias, normas e projeto
- ABNT NBR IEC 60839: requisitos para sistemas de controle de acesso
