Basis of Design, OPR e URS em Data Centers

Entenda as diferenças entre OPR, URS e Basis of Design em projetos de Data Center, como estruturar requisitos, rastreabilidade, mudanças, testes e aceite.

Confira!

O OPR, a URS e o Basis of Design organizam três perspectivas diferentes do projeto de um Data Center. O OPR registra o que o proprietário pretende alcançar; a URS detalha necessidades funcionais e operacionais dos usuários; e o Basis of Design documenta como a equipe de engenharia interpreta esses requisitos e desenvolve a solução técnica.

Esses documentos não devem ser tratados como nomes intercambiáveis. O Owner’s Project Requirements (OPR) pertence à governança do proprietário e deve expressar objetivos, critérios de desempenho, operação, manutenção, expansão, riscos e condições de aceite. A User Requirements Specification (URS) reúne requisitos dos usuários, operadores, equipes de tecnologia, segurança, facilities e demais partes que utilizarão ou sustentarão a instalação. O Basis of Design (BoD) é produzido pela equipe de projeto para registrar premissas, critérios, cálculos, decisões, interfaces e justificativas adotadas para atender ao OPR e às necessidades aprovadas.

Quando essa cadeia documental é consistente, desenhos, memoriais, especificações, propostas, testes e procedimentos podem ser relacionados a requisitos verificáveis. Quando ela não existe, o empreendimento tende a acumular decisões implícitas, critérios contraditórios e lacunas que aparecem apenas durante a contratação, a obra ou o comissionamento.

Síntese técnica

Documento	Pergunta principal	Responsabilidade dominante	Conteúdo central	Uso no aceite
OPR	O que o proprietário precisa alcançar?	Proprietário, patrocinador e governança	objetivos, desempenho, riscos, operação, expansão e critérios de sucesso	define a intenção que deve ser demonstrada
URS	O que os usuários e operadores precisam fazer e receber?	usuários, TI, operação, facilities e áreas funcionais	funções, capacidades, interfaces, condições de uso e restrições	origina requisitos funcionais e operacionais verificáveis
Basis of Design	Como a engenharia pretende atender aos requisitos?	projetistas e responsáveis técnicos	premissas, critérios, arquiteturas, cálculos, seleções e justificativas	explica a solução que será inspecionada e testada
Especificações e desenhos	O que deve ser fornecido e construído?	equipe de projeto	requisitos contratuais, detalhes, materiais, equipamentos e instalação	estabelece obrigações de fornecimento e execução
Plano e procedimentos de comissionamento	Como será comprovado o atendimento?	autoridade de comissionamento e equipe do projeto	inspeções, testes, evidências, responsabilidades e critérios	produz a verificação documentada

A sequência correta não é necessariamente linear, pois requisitos e decisões amadurecem ao longo do empreendimento. Entretanto, a direção de autoridade deve permanecer clara: o projeto responde aos requisitos; os requisitos não devem ser reescritos silenciosamente para justificar uma solução já escolhida.

O que é Owner’s Project Requirements?

O Owner’s Project Requirements, ou OPR, é o documento que registra os requisitos funcionais do projeto e as expectativas do proprietário sobre uso e operação. A terminologia e a função do OPR são consolidadas no processo de commissioning da ASHRAE. A própria ASHRAE destaca que o OPR deve orientar a verificação do sucesso desde o pré-projeto até a operação.

Em um Data Center, o OPR transforma objetivos do investimento em critérios que a engenharia, a contratação, a construção e o comissionamento possam utilizar. Ele não deve se limitar a declarações como “alta disponibilidade”, “máxima segurança” ou “eficiência elevada”. Essas expressões precisam ser traduzidas em condições, prioridades, limites e métodos de verificação.

O OPR pertence ao proprietário

Consultores podem facilitar workshops, organizar informações e redigir o documento, mas a autoridade sobre os requisitos permanece com o proprietário. Isso é importante porque decisões sobre tolerância a falhas, investimento, crescimento, risco residual e operação não podem ser transferidas integralmente ao projetista ou ao fornecedor.

O proprietário também não é uma pessoa única. Em um empreendimento de Data Center, essa função pode envolver investidores, diretoria, tecnologia, facilities, operações, segurança, sustentabilidade, finanças, jurídico, compliance e usuários de negócio. O OPR deve consolidar essas perspectivas e registrar conflitos que exigem decisão.

OPR não é apenas programa de necessidades

O programa de necessidades descreve áreas, capacidades e usos. O OPR é mais amplo: inclui desempenho, qualidade, operação, manutenção, documentação, treinamento, expansão, riscos e critérios de aceite. Ele também deve indicar prioridades quando requisitos entram em tensão, por exemplo:

reduzir CAPEX inicial versus preservar expansão;
elevar disponibilidade versus limitar complexidade operacional;
reduzir consumo de água versus reduzir energia;
padronizar equipamentos versus preservar competição entre fornecedores;
antecipar infraestrutura comum versus implantar somente a capacidade ocupada.

Essas tensões não são resolvidas por uma lista de equipamentos. Elas exigem governança e decisão explícita.

O que é User Requirements Specification?

A User Requirements Specification, ou URS, descreve aquilo que usuários e operadores esperam que a solução permita realizar. O termo é amplamente utilizado em engenharia de requisitos, validação de sistemas e setores regulados, mas sua posição documental pode variar conforme a organização. Em projetos de Data Center, a URS pode existir como documento próprio, conjunto de especificações funcionais ou camada estruturada dentro do OPR.

Por isso, não é correto afirmar que todo projeto deve obrigatoriamente possuir um documento chamado URS. O necessário é que as necessidades dos usuários sejam identificadas, aprovadas, transformadas em requisitos claros e rastreadas até a verificação.

Quem são os usuários de um Data Center?

O conceito inclui mais pessoas e processos do que os consumidores finais das aplicações. Entre os grupos relevantes estão:

Grupo	Exemplos de necessidades
TI e plataforma	potência por rack, conectividade, espaços, implantação, acesso e capacidade
operação de infraestrutura	supervisão, alarmes, manobras, manutenção, peças e documentação
segurança	zonas, credenciamento, investigação, retenção de imagens e resposta
facilities	utilidades, contratos, inspeções, limpeza, água e gestão predial
comissionamento	pontos de medição, modos de teste, cargas, acessos e evidências
sustentabilidade	medição, energia, água, emissões, relatórios e metas
negócio ou clientes	capacidade, prazo, disponibilidade, SLA, segregação e expansão
auditoria e compliance	registros, rastreabilidade, segregação de funções e retenção documental

Uma necessidade pode ser legítima sem ser automaticamente aprovada. A URS deve registrar origem, justificativa, prioridade e responsável pela aprovação.

Requisito do usuário não é preferência de solução

“Precisamos instalar UPS do fabricante X” geralmente é preferência de solução, não requisito do usuário. O requisito subjacente pode ser compatibilidade com manutenção existente, disponibilidade de peças, padronização, eficiência, autonomia ou suporte regional. Ao separar necessidade e solução, o projeto preserva alternativas e reduz bloqueios tecnológicos sem justificativa.

O que é Basis of Design?

O Basis of Design, ou BoD, é o documento da equipe de projeto que registra os conceitos, critérios, premissas, cálculos e decisões utilizados para atender aos requisitos do proprietário. Ele explica a lógica da solução e cria uma ponte entre OPR, URS, desenhos, memoriais, especificações e testes.

A ASHRAE relaciona o BoD ao processo de commissioning: o proprietário estabelece os requisitos e a equipe de projeto documenta os meios pelos quais pretende atendê-los. Em Data Centers, o BoD deve demonstrar como capacidade, disponibilidade, manutenção, segurança, eficiência, expansão e operação foram transformadas em arquiteturas multidisciplinares.

BoD não é um memorial descritivo genérico

Um memorial pode descrever sistemas e equipamentos. O Basis of Design deve explicar por que a configuração foi adotada, quais premissas sustentam os cálculos, quais alternativas foram descartadas, quais interfaces são críticas e como o desempenho será verificado.

Por exemplo, não basta registrar que haverá distribuição elétrica A/B. O BoD deve esclarecer:

quais cargas recebem dois caminhos;
onde os caminhos permanecem independentes;
quais elementos são compartilhados;
como cada caminho é mantido;
quais falhas foram consideradas;
como transferências e retornos ocorrem;
quais condições temporárias surgem durante expansão;
como os testes demonstrarão o comportamento esperado.

O BoD deve evoluir com o projeto

No conceito, ele registra critérios e arquiteturas de alto nível. No projeto básico, incorpora configurações, capacidades, interfaces e requisitos de contratação. No executivo, consolida cálculos, equipamentos selecionados, sequências e condições reais de instalação. Mudanças relevantes precisam atualizar o BoD e a matriz de rastreabilidade.

OPR, URS e Basis of Design não são sinônimos

Aspecto	OPR	URS	Basis of Design
perspectiva	proprietário	usuário e operação	projetista
natureza	objetivos e critérios do empreendimento	necessidades funcionais e operacionais	resposta técnica e justificativa
momento inicial	pré-projeto	levantamento de requisitos	projeto conceitual
linguagem dominante	desempenho, risco e resultado	função, uso e interface	engenharia, arquitetura e cálculo
autoridade de aprovação	proprietário	proprietário e responsáveis funcionais	responsável técnico e proprietário, conforme governança
relação com fornecedores	orienta o escopo	informa funções requeridas	fundamenta especificações e desenhos
relação com testes	define o que deve ser demonstrado	define comportamentos e usos	define como a solução deve responder

O modelo documental pode variar. Algumas organizações adotam OPR único com anexos de requisitos de usuários. Outras mantêm URS separadas por disciplina ou grupo funcional. Também podem utilizar Employer’s Requirements, Project Requirements, Design Criteria ou Technical Requirements. O nome é menos importante que a clareza de autoria, hierarquia, aprovação e rastreabilidade.

Arquitetura documental recomendada

Uma estrutura prática para Data Centers pode ser organizada em cinco níveis.

Objetivos e decisão de investimento: business case, estudo de viabilidade, requisitos estratégicos e limites do empreendimento.
Requisitos do proprietário: OPR, políticas, metas, critérios de risco, disponibilidade, segurança, sustentabilidade e operação.
Requisitos dos usuários e funções: URS, fluxos, capacidades, interfaces, dados, acessos, alarmes, relatórios e manutenção.
Resposta de engenharia: Basis of Design, critérios de projeto, cálculos, diagramas, layouts e matriz de interfaces.
Documentos contratuais e de verificação: especificações, desenhos, RFP, submittals, FAT, SAT, testes integrados, as built e documentação operacional.

Essa arquitetura não exige cinco arquivos isolados. Ela exige cinco camadas de informação identificáveis e governadas.

Quando elaborar cada documento?

Fase	OPR	URS	Basis of Design
oportunidade e viabilidade	versão inicial com objetivos, capacidade, riscos e critérios	necessidades preliminares dos grupos críticos	apenas conceitos ou estudo de alternativas
seleção do site	atualiza requisitos externos, prazo e expansão	inclui acesso, operação e conectividade	registra critérios usados na comparação
projeto conceitual	baseline inicial aprovado	requisitos funcionais priorizados	arquiteturas e decisões conceituais
projeto básico	revisão controlada	consolidação para contratação	configurações, capacidades, interfaces e desempenho
projeto executivo	mudanças somente por controle formal	detalhamento de funções afetadas	cálculos, equipamentos, sequências e critérios finais
construção	atualização por mudanças aprovadas	validação de desvios funcionais	incorpora submittals e decisões de campo
comissionamento	referência principal de verificação	base de cenários operacionais	referência do comportamento projetado
entrega e operação	convertido em requisitos atuais da instalação	procedimentos e usos consolidados	baseline técnico e registro das decisões

O OPR não deve ser congelado cedo demais nem permanecer indefinido até o fim. A governança deve estabelecer baselines por gate e processo formal para mudanças posteriores.

Conteúdo mínimo de um OPR para Data Center

Objetivos do empreendimento

O documento deve explicar por que o Data Center existe, quais serviços atende, qual modelo operacional será adotado e quais resultados justificam o investimento. Isso evita que disciplinas desenvolvam soluções tecnicamente corretas, mas desalinhadas ao propósito.

Capacidade e crescimento

Devem ser registrados carga de TIC inicial e final, densidades, quantidade de racks, ocupação, horizonte, blocos de expansão e gatilhos. O requisito precisa diferenciar capacidade nominal, capacidade disponível e capacidade efetivamente utilizável.

Disponibilidade e continuidade

O OPR deve definir tolerância a interrupções, necessidade de manutenção concorrente, modos degradados aceitáveis, recuperação e dependências entre infraestrutura física e arquitetura de aplicações. Uma classificação Tier ou Rated não substitui a definição dos serviços e riscos do proprietário.

Operação e manutenção

Devem ser consideradas equipe, cobertura, treinamento, estoque, assistência, acessos, janelas, procedimentos, capacidade de manobra e filosofia de manutenção. Uma solução com redundância elevada pode ser inadequada quando sua complexidade excede a capacidade operacional.

Segurança e compliance

O proprietário precisa indicar classificação de áreas, perfis de acesso, registros, retenção, investigação, privacidade, segregação, auditoria e requisitos regulatórios aplicáveis.

Eficiência e sustentabilidade

Metas de energia, água, emissões, medição, relatórios e condições de carga devem possuir fronteiras claras. Um valor de PUE sem condição de utilização, clima e limite de medição não é requisito verificável.

Expansão, flexibilidade e ciclo de vida

O OPR deve declarar quais interfaces precisam ser preparadas, quais ativos podem ser antecipados, como novas fases serão construídas e quais tecnologias devem permanecer substituíveis.

Comissionamento e aceite

O documento deve estabelecer escopo de sistemas, níveis de teste, participação dos fornecedores, disponibilidade de cargas, evidências, critérios, treinamento e documentação necessária para o aceite.

Transforme requisitos aprovados em uma arquitetura multidisciplinar coordenada e verificável.

A A3A Engenharia desenvolve projetos conceituais, básicos e executivos preservando OPR, Basis of Design, interfaces, critérios de desempenho e requisitos de aceite.

Conheça o serviço de Projeto de Data Center

Conteúdo de uma URS para Data Center

A URS deve transformar necessidades em declarações funcionais. Ela pode ser organizada por usuários, áreas ou sistemas, mas precisa evitar duplicidades e conflitos.

Capacidade e implantação de TIC

Exemplos incluem dimensões e massas de equipamentos, potência por rack, alimentação A/B, conectores, posições, ocupação, fluxo de implantação, staging, docas, elevadores e rotas de movimentação.

Redes e interconexão

Devem ser definidos quantidade e diversidade de entradas, carriers, MMRs, backbone, fibras, cabeamento, patching, identificação, latência, capacidade, crescimento e requisitos de certificação.

Operação e supervisão

A URS pode especificar alarmes, prioridades, pontos, dashboards, históricos, relatórios, integrações, sincronismo de tempo, acesso remoto, out-of-band e comportamento durante perda de comunicação.

Segurança física

Inclui jornadas de acesso, visitantes, contratados, dupla custódia, áreas críticas, CFTV, retenção, investigação, credenciais, biometria, intertravamentos e contingência.

Manutenção

Devem ser registrados acessos, espaços, içamento, substituição, isolamento, drenagem, iluminação, tomadas, pontos de teste, ferramentas, peças e restrições de trabalho em áreas ativas.

Documentação e treinamento

A URS pode definir formatos, idioma, codificação, modelos, as built, listas de ativos, manuais, vídeos, simuladores, treinamento, avaliação de competência e atualização pós-mudança.

Como redigir requisitos verificáveis

Um requisito de qualidade deve ser necessário, claro, singular, viável, rastreável e verificável. A ISO/IEC/IEEE 29148 fornece fundamentos gerais de engenharia de requisitos que podem ser adaptados ao empreendimento.

Estrutura recomendada

Campo	Função
ID	identificação única e estável
declaração	requisito em linguagem objetiva
origem	proprietário, usuário, norma, risco ou decisão
justificativa	motivo e consequência
prioridade	obrigatório, desejável ou opcional
responsável	quem decide e mantém
método de verificação	análise, inspeção, demonstração ou teste
fase de verificação	projeto, FAT, SAT, IST ou operação
evidência	documento, relatório, registro ou medição
status	proposto, aprovado, alterado, atendido ou pendente

Linguagem de obrigação

Requisitos contratuais devem usar linguagem consistente. Uma formulação comum utiliza “deve” para obrigação e evita expressões vagas como “quando possível”, “adequado”, “preferencialmente” ou “alta qualidade” sem critério.

Fraco: o sistema de climatização deve ser altamente confiável.

Melhor: a perda de uma unidade de climatização do bloco não deve elevar a temperatura de entrada dos equipamentos de TIC acima do limite aprovado durante a condição de projeto e pelo período definido para resposta operacional.

A formulação ainda precisa indicar limite, condição de carga, ambiente, duração, método de medição e evidência.

Matriz de rastreabilidade de requisitos

A matriz conecta cada requisito a decisões, documentos e verificações. Ela não precisa ser uma planilha isolada; pode existir em plataforma de requisitos ou ambiente comum de dados. O essencial é manter relações auditáveis.

Requisito	Origem	BoD	Documento de projeto	Fornecimento	Verificação	Status
OPR-AV-001	continuidade do negócio	BOD-EL-03	unifilar e especificação elétrica	UPS, painéis e controles	FAT, SAT e IST	aprovado
URS-OPS-014	operação	BOD-AUT-08	lista de pontos e causa e efeito	BMS/EPMS	demonstração e teste	em revisão
OPR-SEC-006	política de segurança	BOD-SEG-02	arquitetura de zonas	acesso e CFTV	inspeção e cenário	aprovado
URS-MAN-021	manutenção	BOD-MEC-12	layout e detalhes	equipamentos HVAC	inspeção de acesso	pendente

A matriz deve permitir rastrear nos dois sentidos: de um requisito até a evidência e de um teste ou equipamento até os requisitos que justificam sua existência.

Cobertura e lacunas

Indicadores simples ajudam a governança:

requisitos sem resposta no BoD;
decisões de projeto sem requisito de origem;
requisitos sem método de verificação;
testes sem requisito associado;
mudanças sem análise de impacto;
requisitos aprovados ainda sem evidência de atendimento.

A quantidade de vínculos não substitui revisão técnica. Uma relação pode existir e ainda ser inadequada.

Exemplo de cadeia completa de requisito

Considere a necessidade de manutenção da alimentação elétrica sem desligamento das cargas críticas.

Objetivo do proprietário: serviços críticos devem permanecer disponíveis durante manutenção planejada da infraestrutura elétrica.
OPR: cada bloco deve permitir retirada planejada dos componentes definidos sem interrupção das cargas classificadas como críticas, dentro das condições e exceções aprovadas.
URS de operação: a equipe precisa realizar isolamento, transferência, bloqueio, teste e retorno por procedimentos controlados, com estados visíveis no EPMS.
Basis of Design: a solução utiliza caminhos A/B, dispositivos de isolamento, bypass, lógica de transferência e medição conforme os modos analisados.
Projeto: unifilares, intertravamentos, lista de sinais, especificações, seletividade, layouts e rotas detalham a solução.
Verificação: revisão de projeto, FAT de controles, SAT, teste de transferência e IST demonstram os cenários aprovados.
Operação: MOP, SOP e treinamento consolidam o procedimento e as restrições conhecidas.

Sem essa cadeia, a frase “manutenção concorrente” pode ser interpretada de formas diferentes por proprietário, projetista, fabricante, instalador e operador.

Como elaborar o Basis of Design

Premissas e limites

O documento deve iniciar com escopo, referências, condições de projeto, dados recebidos, premissas, exclusões e responsabilidades. Cada premissa relevante precisa de origem e status. Uma informação ainda não confirmada não deve desaparecer dentro de um cálculo.

Critérios de capacidade

O BoD registra modelos de carga, fatores, margens, simultaneidade, crescimento, derating, reservas e capacidade utilizável. Deve explicar como carga de TIC se transforma em demanda elétrica, carga térmica, água, espaço, peso e telecomunicações.

Arquitetura e redundância

As topologias devem ser justificadas por requisitos e análise de risco. O documento precisa identificar componentes redundantes, compartilhados, modos comuns, estados degradados, recuperação e limitações.

Seleção de tecnologias

A decisão entre água gelada, expansão direta, InRow, resfriamento líquido, baterias de chumbo-ácido ou lítio, UPS centralizada ou distribuída e outras alternativas deve registrar critérios técnicos e operacionais, não apenas marcas ou preferências.

Sequências e intertravamentos

O BoD deve descrever comportamento esperado durante partida, parada, falha, transferência, emergência, manutenção e retorno. Sequências precisam ser coerentes entre elétrica, mecânica, automação, incêndio e segurança.

Manutenibilidade e substituição

Devem ser considerados isolamento, acesso, desmontagem, içamento, drenagem, peças, ferramentas, iluminação, segurança e impacto sobre outros sistemas. Espaço geométrico sem procedimento viável não representa manutenibilidade.

Expansão e estados temporários

O documento precisa registrar condição inicial, fases, capacidade final, interfaces preparadas e estados transitórios. A arquitetura final pode ser resiliente enquanto uma etapa intermediária possui vulnerabilidades diferentes.

Testabilidade

Pontos de medição, cargas, simulações, modos de teste, bypass, conexões temporárias e segurança dos ensaios devem ser previstos. Um requisito não verificável no campo precisa de outro método de evidência aprovado.

Relação com normas e referências técnicas

A série ISO/IEC 22237 organiza princípios, classificações e requisitos de infraestrutura de Data Centers. A ANSI/TIA-942-C abrange arquitetura, telecomunicações, energia, climatização, segurança e demais sistemas para instalações de diferentes tipos e portes.

Essas referências não escrevem o OPR do proprietário. Elas oferecem requisitos, classificações e boas práticas que precisam ser selecionadas conforme riscos, legislação e finalidade do empreendimento. Adotar uma norma não elimina a necessidade de declarar edição, escopo, exceções e critérios específicos.

O artigo sobre Tier I, II, III e IV em Data Centers explica por que classificação, redundância e disponibilidade do serviço não devem ser confundidas.

Relação com projeto conceitual, básico e executivo

O artigo Como projetar um Data Center: etapas, disciplinas e entregáveis apresenta o processo multidisciplinar completo. Dentro dele, os documentos de requisitos e o BoD assumem funções diferentes em cada fase.

Fase	Função dos requisitos	Função do BoD
conceitual	selecionar objetivos, prioridades e restrições	comparar alternativas e fixar princípios
básico	consolidar critérios para contratação	definir configurações, desempenho e interfaces
executivo	controlar mudanças e detalhes afetados	registrar cálculos, escolhas e comportamento final
construção	avaliar desvios e propostas	incorporar submittals e decisões aprovadas
comissionamento	definir o que deve ser comprovado	explicar como a solução deveria funcionar
operação	preservar intenção e limites	formar baseline técnico para mudanças futuras

Um projeto executivo detalhado não compensa requisitos inadequados. Ele apenas detalha com maior precisão uma solução que pode estar errada.

OPR, URS e BoD na RFP e na contratação

Uma RFP consistente deve declarar quais requisitos são obrigatórios, quais permitem alternativas e como desvios serão apresentados. O fornecedor não deve precisar inferir objetivos do proprietário a partir de desenhos incompletos.

Hierarquia contratual

A documentação precisa estabelecer precedência entre OPR, especificações, desenhos, listas, normas e propostas. O OPR pode orientar a intenção sem necessariamente ser incorporado integralmente como documento contratual. A organização deve evitar conflitos em que um requisito de alto nível contradiz uma obrigação detalhada sem mecanismo de resolução.

Matriz de conformidade

Cada proponente pode ser obrigado a responder:

Resposta	Significado
atende	solução cumpre integralmente o requisito
atende com esclarecimento	cumpre, mas exige interpretação registrada
alternativa	oferece solução diferente com impacto demonstrado
desvio	não atende e solicita aceitação formal
não aplicável	requisito não pertence ao escopo, com justificativa

Silêncio não deve ser interpretado automaticamente como conformidade.

Desvios técnicos

O desvio precisa indicar requisito afetado, solução proposta, motivo, impacto em capacidade, disponibilidade, operação, manutenção, prazo, custo, testes e documentação. A aprovação deve atualizar rastreabilidade e BoD.

Mantenha requisitos, decisões, desvios e mudanças rastreáveis durante contratação e implantação.

A Owner’s Engineering representa os interesses do proprietário na revisão de projetos, propostas, submittals, interfaces, mudanças e evidências de atendimento.

Conheça Owner’s Engineering para Data Centers

Governança de mudanças

Mudanças são inevitáveis; alterações sem rastreabilidade não são. Um processo mínimo inclui:

identificação da mudança e dos requisitos afetados;
justificativa e alternativas;
análise multidisciplinar de impacto;
avaliação de custo, prazo, risco, operação e testes;
decisão por autoridade definida;
atualização de OPR, URS, BoD e documentos associados;
comunicação às partes e revisão da matriz de rastreabilidade;
verificação da implantação e fechamento da mudança.

A decisão deve preservar o histórico. Substituir silenciosamente uma premissa apaga a razão pela qual escolhas anteriores foram feitas.

Baselines e gates

Em cada gate, versões específicas são aprovadas como baseline. Novos requisitos entram por mudança controlada, não por comentários dispersos em atas, e-mails ou desenhos. Isso permite distinguir evolução legítima de scope creep.

Revisão de qualidade do OPR

Antes da aprovação, o OPR deve ser verificado quanto a:

Critério	Pergunta de revisão
completude	objetivos, capacidade, operação, segurança, expansão e aceite estão cobertos?
clareza	termos vagos possuem definição e limite?
consistência	requisitos se contradizem?
viabilidade	prazo, tecnologia, orçamento e operação são compatíveis?
prioridade	conflitos possuem regra de decisão?
verificabilidade	existe método e evidência possíveis?
rastreabilidade	origem, responsável e versão estão registrados?
aplicabilidade	normas e requisitos externos estão corretamente selecionados?

A revisão deve envolver proprietários funcionais, não apenas a equipe de engenharia.

Revisão de qualidade da URS

A URS deve ser testada contra jornadas e cenários reais. Workshops podem usar fluxos como implantação de novo rack, manutenção de UPS, entrada de contratado, resposta a vazamento, perda de comunicação, falha de sensor, investigação de acesso e expansão de capacidade.

Essa abordagem revela requisitos que listas genéricas não capturam: tempo de resposta, permissões, visualização, espaço, sequência, dados, documentação e responsabilidades.

Revisão de qualidade do Basis of Design

O BoD precisa ser revisado por disciplina e por interface. Uma revisão adequada confronta requisitos, diagramas, cálculos, layouts, sequências e métodos de teste.

Perguntas críticas

Cada arquitetura responde a requisitos aprovados?
As capacidades usam premissas consistentes entre disciplinas?
Modos comuns e estados degradados foram identificados?
A manutenção pode ser executada com segurança?
Equipamentos podem ser substituídos?
As fases temporárias estão representadas?
As sequências de controle são coerentes?
O projeto possui pontos e condições de teste?
Exceções e riscos residuais estão explícitos?

Uma revisão de clash detection não responde a essas perguntas.

Integração com BIM e ambiente comum de dados

BIM pode associar requisitos a espaços, sistemas e ativos, mas não substitui a governança. O ambiente comum de dados deve controlar códigos, versões, status, aprovações, comentários e transmittals.

Uma estrutura possível relaciona:

requisito ao sistema e ao espaço;
objeto BIM à especificação e ao submittal;
ativo ao teste e ao relatório;
mudança aos documentos afetados;
pendência ao responsável e ao gate;
as built ao cadastro operacional.

Os vínculos precisam sobreviver à exportação, entrega e operação. Uma plataforma sem plano de dados pode concentrar informação que se perde no handover.

Integração com comissionamento

O commissioning não deve começar pela redação de testes ao fim da obra. A ASHRAE/IES Standard 202 descreve um processo integrado para entregar instalações que atendam ao OPR.

Revisão de projeto

A autoridade de comissionamento verifica se o BoD e os documentos respondem aos requisitos, identificando lacunas de testabilidade, operação, medição, acesso e sequência.

Submittals e FAT

Propostas e desenhos de fabricantes são avaliados contra especificações e requisitos. FATs podem verificar funções, controles, alarmes e desempenho antes do envio, reduzindo descobertas no site.

SAT e testes funcionais

No campo, inspeções e testes confirmam instalação, configuração e comportamento de sistemas individuais. Cada procedimento deve indicar requisitos, pré-condições, instrumentos, passos, critérios e evidências.

Testes integrados de sistemas

Os ISTs demonstram interações durante falhas e transições: perda de rede, partida de geradores, transferência de UPS, falha de climatização, incêndio, perda de comunicação, manutenção e retorno à condição normal.

Defina os critérios de verificação antes da compra, da instalação e dos testes.

O comissionamento conecta OPR, Basis of Design, especificações, FAT, SAT, testes funcionais e testes integrados para produzir evidências objetivas de atendimento.

Conheça Comissionamento e Aceite de Data Centers

Entrega para operação

Ao final, requisitos e BoD devem ser reconciliados com a instalação construída. A documentação de operação precisa refletir desvios aprovados, limitações, configurações e evidências.

Current Facility Requirements

No processo de commissioning, requisitos da instalação existente podem ser consolidados como Current Facility Requirements. Para Data Centers, essa lógica ajuda a manter uma referência atualizada após mudanças, expansões e modernizações.

Baseline operacional

O handover deve conectar:

requisitos vigentes;
BoD final;
as built e diagramas;
listas de ativos e configurações;
testes e pendências;
MOPs, SOPs e EOPs;
treinamento e competência;
limites operacionais;
plano de manutenção;
matriz de alarmes e escalonamento.

Sem essa reconciliação, a operação recebe documentos históricos que não representam a instalação real.

Exemplo de estrutura de OPR

Seção	Conteúdo
1. governança	propósito, escopo, autoridades, aprovações e controle de mudanças
2. contexto	negócio, usuários, serviços e modelo operacional
3. capacidade	TIC, racks, densidade, crescimento e fases
4. disponibilidade	criticidade, manutenção, falhas e recuperação
5. implantação	site, edifícios, expansão, acessos e logística
6. infraestrutura	energia, térmica, telecom, automação e utilidades
7. segurança	física, cibernética, incêndio e compliance
8. operação	equipe, procedimentos, manutenção, peças e suporte
9. sustentabilidade	energia, água, emissões, medição e relatórios
10. qualidade e testes	revisões, FAT, SAT, IST e evidências
11. documentação	formatos, codificação, BIM, as built e handover
12. riscos e exceções	condicionantes, riscos aceitos e decisões pendentes

Exemplo de estrutura de Basis of Design

Seção	Conteúdo
1. escopo e referências	limites, normas, documentos de entrada e interfaces
2. premissas	dados, condições de projeto, margens e pendências
3. critérios gerais	capacidade, disponibilidade, segurança e eficiência
4. arquitetura	implantação, blocos, redundância e expansão
5. disciplinas	bases elétricas, mecânicas, telecom, automação e segurança
6. modos de operação	normal, manutenção, falha, emergência e retorno
7. cálculos e seleções	modelos, fatores, derating e alternativas
8. coordenação	espaços, rotas, cargas, interfaces e responsabilidades
9. testabilidade	pontos, cargas, procedimentos e critérios
10. riscos e exceções	limitações, desvios e risco residual
11. mudanças	decisões, revisões e impactos
12. anexos	diagramas, matrizes, tabelas e registros

Erros comuns

Erro	Consequência
copiar OPR de outro empreendimento	requisitos incompatíveis com o negócio e a operação
usar termos vagos	fornecedores e projetistas adotam interpretações diferentes
confundir requisito e solução	bloqueio tecnológico e competição limitada
deixar usuários fora do processo	operação recebe instalação difícil de usar e manter
produzir BoD após os desenhos	documento vira justificativa retrospectiva
não registrar premissas	cálculos parecem precisos sobre dados incertos
não definir métodos de verificação	requisitos não conseguem ser aceitos objetivamente
não controlar mudanças	projeto, contrato e testes usam versões diferentes
tratar norma como OPR	objetivos específicos do proprietário ficam ausentes
desconectar comissionamento	testes são improvisados ao final da obra
não reconciliar as built e BoD	baseline operacional não representa a instalação
criar documentos excessivos sem hierarquia	duplicidade e conflito aumentam em vez de reduzir

Checklist de governança documental

O objetivo e o modelo de operação do Data Center estão definidos?
Existe autoridade formal para aprovar requisitos e mudanças?
O OPR diferencia objetivos, requisitos e preferências?
Usuários de TI, operação, segurança e facilities participaram?
Requisitos possuem IDs, origem, prioridade e responsável?
Critérios vagos foram transformados em condições mensuráveis?
Cada requisito possui método e fase de verificação?
O BoD registra premissas e dados ainda pendentes?
As escolhas de arquitetura possuem justificativa ligada a requisitos?
Capacidades e margens são consistentes entre disciplinas?
Modos normais, manutenção, falha e emergência estão descritos?
Expansões e estados temporários foram considerados?
A matriz conecta requisitos, documentos, fornecimentos e testes?
A RFP exige conformidade e declaração de desvios?
Submittals são revisados contra requisitos e BoD?
Mudanças atualizam todos os documentos afetados?
FAT, SAT e IST citam requisitos verificáveis?
Pendências possuem responsável, prazo e impacto no aceite?
O as built foi reconciliado com o BoD final?
A operação recebeu baseline, procedimentos e limites atualizados?

Escopo de engenharia consultiva da A3A Engenharia

A A3A Engenharia apoia proprietários e operadores na estruturação de requisitos e bases de projeto para novos Data Centers, expansões, modernizações, ambientes Edge, instalações corporativas, colocation e soluções modulares.

O escopo pode incluir workshops com stakeholders, levantamento de necessidades, elaboração ou revisão de OPR e URS, desenvolvimento do Basis of Design, matriz de rastreabilidade, critérios de contratação, revisão multidisciplinar, gestão de interfaces, requisitos de comissionamento e reconciliação da documentação final.

A atuação pode integrar o Estudo de Viabilidade de Data Center, o Projeto de Data Center, a Owner’s Engineering para Data Centers e o Comissionamento e Aceite de Data Centers.

Resumo técnico

OPR, URS e Basis of Design possuem funções complementares. O OPR registra objetivos e critérios do proprietário; a URS estrutura necessidades dos usuários e operadores; o BoD documenta como a engenharia responde a esses requisitos por meio de premissas, critérios, arquiteturas, cálculos e decisões.

A qualidade depende menos do nome dos arquivos e mais da governança: autoria, aprovação, hierarquia, identificação, verificabilidade, rastreabilidade e controle de mudanças. Requisitos devem orientar projeto, contratação e testes; o BoD deve explicar as escolhas; e o comissionamento deve produzir evidências de atendimento.

Quando essa cadeia é mantida até o as built e a operação, o empreendimento preserva sua intenção técnica. Quando ela se rompe, o projeto tende a acumular decisões implícitas, desvios não avaliados e critérios de aceite definidos tarde demais.

Referências técnicas

[1] ASHRAE. ASHRAE Guideline 0-2019 — The Commissioning Process. Atlanta: ASHRAE, 2019.

[2] ASHRAE; IES. ANSI/ASHRAE/IES Standard 202-2024 — The Commissioning Process Requirements for New Buildings and New Systems. Atlanta: ASHRAE, 2024.

[3] INTERNATIONAL ORGANIZATION FOR STANDARDIZATION. ISO/IEC 22237-1:2021 — Information technology — Data centre facilities and infrastructures — Part 1: General concepts. Geneva: ISO, 2021.

[4] INTERNATIONAL ORGANIZATION FOR STANDARDIZATION. ISO/IEC TS 22237-7:2018 — Information technology — Data centre facilities and infrastructures — Part 7: Management and operational information. Geneva: ISO, 2018.

[5] TELECOMMUNICATIONS INDUSTRY ASSOCIATION. ANSI/TIA-942-C — Telecommunications Infrastructure Standard for Data Centers. Arlington: TIA, 2024.

[6] BICSI. ANSI/BICSI 002-2024 — The Standard for Data Center Design. Tampa: BICSI, 2024.

[7] INTERNATIONAL ORGANIZATION FOR STANDARDIZATION; IEEE. ISO/IEC/IEEE 29148:2018 — Systems and software engineering — Life cycle processes — Requirements engineering. Geneva: ISO, 2018.

[8] UPTIME INSTITUTE. Tier Standard: Topology for Data Center Site Infrastructure. Uptime Institute.

[9] ASHRAE. Thermal Guidelines for Data Processing Environments. 5. ed. Atlanta: ASHRAE.

[10] INTERNATIONAL ORGANIZATION FOR STANDARDIZATION. ISO 31000:2018 — Risk management — Guidelines. Geneva: ISO, 2018.

[11] INTERNATIONAL ORGANIZATION FOR STANDARDIZATION. ISO 9001:2015 — Quality management systems — Requirements. Geneva: ISO, 2015.

[12] A3A ENGENHARIA. Projeto de Data Center: estudo, projeto básico e executivo. Ponta Grossa: A3A Engenharia.

Perguntas frequentes

Qual é a diferença entre OPR, URS e Basis of Design?

O OPR registra objetivos e critérios do proprietário; a URS detalha necessidades funcionais e operacionais dos usuários; e o Basis of Design documenta como a equipe de projeto pretende atender a esses requisitos.

Todo projeto de Data Center precisa de uma URS separada?

Não necessariamente. A organização pode manter requisitos de usuários dentro do OPR ou em documentos separados. O essencial é garantir autoria, aprovação, clareza e rastreabilidade.

Quem deve elaborar o OPR?

O proprietário é responsável pelo conteúdo e pela aprovação. Consultores podem facilitar workshops e redigir o documento, mas decisões sobre objetivos, riscos, operação e investimento pertencem ao proprietário.

Quem elabora o Basis of Design?

A equipe de projeto e os responsáveis técnicos elaboram o BoD, registrando premissas, critérios, cálculos, arquiteturas e justificativas utilizadas para atender aos requisitos aprovados.

O OPR faz parte do contrato?

Depende da estratégia contratual. Ele pode orientar a intenção sem ser incorporado integralmente como documento contratual. A hierarquia entre OPR, especificações, desenhos e propostas deve ser explicitada.

Quando o OPR deve ser criado?

Ele deve começar no pré-projeto ou na viabilidade e amadurecer ao longo dos gates. Depois de cada baseline, mudanças devem seguir processo formal de avaliação e aprovação.

Como saber se um requisito é verificável?

O requisito deve indicar condição, limite e método possível de comprovação, como análise, inspeção, demonstração ou teste, além da evidência esperada e da fase de verificação.

O Basis of Design substitui os memoriais e desenhos?

Não. O BoD explica a lógica e as bases da solução. Memórias de cálculo, memoriais, especificações, diagramas, plantas e detalhes desenvolvem e contratualizam essa solução.

Como OPR e BoD se relacionam com o comissionamento?

O OPR define o que deve ser alcançado; o BoD explica como o projeto pretende atender; e o comissionamento revisa, inspeciona e testa a solução para produzir evidências de atendimento.

O que é uma matriz de rastreabilidade?

É o mecanismo que relaciona cada requisito à sua origem, resposta no BoD, documentos de projeto, fornecimentos, métodos de verificação, evidências e status.