Understand OPR, URS and Basis of Design in Data Center projects: ownership, user requirements, design response, traceability, commissioning and document governance.
Check it out!
The OPR, URS, and the Basis of Design organize three different perspectives of a Data Center project. The OPR records what the owner intends to achieve; the URS details users’ functional and operational needs; and the Basis of Design documents how the engineering team interprets those requirements and develops the technical solution.
These documents should not be treated as interchangeable names. The Owner’s Project Requirements (OPR) belongs to owner governance and should express objectives, performance criteria, operations, maintenance, expansion, risks, and acceptance conditions. The User Requirements Specification (URS) brings together requirements from users, operators, technology teams, security, facilities, and other parties that will use or support the facility. The Basis of Design (BoD) is produced by the design team to record assumptions, criteria, calculations, decisions, interfaces, and justifications adopted to meet the OPR and approved needs.
When this documentation chain is consistent, drawings, technical specifications, proposals, tests, and procedures can be linked to verifiable requirements. When it does not exist, the project tends to accumulate implicit decisions, contradictory criteria, and gaps that only emerge during contracting, construction, or commissioning.
Technical summary
| Document | Main question | Primary responsibility | Core content | Use in acceptance |
| OPR | What does the owner need to achieve? | Owner, sponsor, and governance | objectives, performance, risks, operations, expansion, and success criteria | defines the intent that must be demonstrated |
| URS | What do users and operators need to do and receive? | users, IT, operations, facilities, and functional areas | functions, capacities, interfaces, operating conditions, and constraints | originates verifiable functional and operational requirements |
| Basis of Design | How does engineering intend to meet the requirements? | designers and responsible engineers | assumptions, criteria, architectures, calculations, selections, and justifications | explains the solution that will be inspected and tested |
| Specifications and drawings | What must be supplied and built? | design team | contractual requirements, details, materials, equipment, and installation | establishes supply and execution obligations |
| Commissioning plan and procedures | How will compliance be demonstrated? | commissioning authority and project team | inspections, tests, evidence, responsibilities, and criteria | produces documented verification |
The correct sequence is not necessarily linear because requirements and decisions mature throughout the project. However, the direction of authority should remain clear: the design responds to the requirements; requirements should not be silently rewritten to justify a solution already selected.
What is Owner’s Project Requirements?
The Owner’s Project Requirements, or OPR, is the document that records the project’s functional requirements and the owner’s expectations for use and operation. OPR terminology and function are well established in ASHRAE’s commissioning process. ASHRAE itself emphasizes that the OPR should guide verification of success from pre-design through operations.
In a Data Center, the OPR transforms investment objectives into criteria that engineering, contracting, construction, and commissioning can use. It should not be limited to statements such as “high availability,” “maximum security,” or “high efficiency.” These expressions need to be translated into conditions, priorities, limits, and verification methods.
The OPR belongs to the owner
Consultants may facilitate workshops, organize information, and draft the document, but authority over the requirements remains with the owner. This is important because decisions about fault tolerance, investment, growth, residual risk, and operations cannot be transferred entirely to the designer or supplier.
The owner is also not a single person. In a Data Center project, this role may involve investors, executives, technology, facilities, operations, security, sustainability, finance, legal, compliance, and business users. The OPR should consolidate these perspectives and record conflicts that require a decision.
OPR is more than a space or program brief
A program brief describes areas, capacities, and uses. The OPR is broader: it includes performance, quality, operations, maintenance, documentation, training, expansion, risks, and acceptance criteria. It should also indicate priorities when requirements conflict, for example:
- reduce initial CAPEX versus preserve expansion;
- increase availability versus limit operational complexity;
- reduce water consumption versus reduce energy consumption;
- standardize equipment versus preserve supplier competition;
- bring shared infrastructure forward versus implement only occupied capacity.
These tensions are not resolved by an equipment list. They require governance and explicit decisions.
What is a User Requirements Specification?
The User Requirements Specification, or URS, describes what users and operators expect the solution to enable them to do. The term is widely used in requirements engineering, systems validation, and regulated sectors, but its documentary position may vary by organization. In Data Center projects, the URS may exist as a standalone document, a set of functional specifications, or a structured layer within the OPR.
For this reason, it is not correct to state that every project must necessarily have a document called URS. What is necessary is for user needs to be identified, approved, transformed into clear requirements, and traced through verification.
Who are the users of a Data Center?
The concept includes more people and processes than the end users of applications. Relevant groups include:
| Group | Examples of needs |
| IT and platform | power per rack, connectivity, spaces, deployment, access, and capacity |
| infrastructure operations | monitoring, alarms, switching, maintenance, parts, and documentation |
| security | zones, credentialing, investigation, image retention, and response |
| facilities | utilities, contracts, inspections, cleaning, water, and facility management |
| commissioning | measurement points, test modes, loads, access, and evidence |
| sustainability | metering, energy, water, emissions, reporting, and targets |
| business or customers | capacity, schedule, availability, SLA, segregation, and expansion |
| audit and compliance | records, traceability, segregation of duties, and document retention |
A need may be legitimate without being automatically approved. The URS should record origin, justification, priority, and approval owner.
A user requirement is not a solution preference
“We need to install UPS systems from manufacturer X” is generally a solution preference, not a user requirement. The underlying requirement may be compatibility with existing maintenance, parts availability, standardization, efficiency, autonomy, or regional support. By separating need from solution, the project preserves alternatives and reduces unjustified technology lock-in.
What is a Basis of Design?
The Basis of Design, or BoD, is the design-team document that records the concepts, criteria, assumptions, calculations, and decisions used to meet the owner’s requirements. It explains the logic of the solution and creates a bridge among the OPR, URS, drawings, technical specifications, specifications, and tests.
ASHRAE relates the BoD to the commissioning process: the owner establishes the requirements and the design team documents the means by which it intends to meet them. In Data Centers, the BoD should demonstrate how capacity, availability, maintenance, security, efficiency, expansion, and operations were translated into multidisciplinary architectures.
BoD is not a generic descriptive specification
A descriptive specification may describe systems and equipment. The Basis of Design should explain why the configuration was adopted, which assumptions support the calculations, which alternatives were rejected, which interfaces are critical, and how performance will be verified.
For example, it is not enough to state that there will be A/B electrical distribution. The BoD should clarify:
- which loads receive two paths;
- where the paths remain independent;
- which elements are shared;
- how each path is maintained;
- which failures were considered;
- how transfers and returns occur;
- which temporary conditions arise during expansion;
- how tests will demonstrate expected behavior.
The BoD should evolve with the design
At concept stage, it records high-level criteria and architectures. During basic design, it incorporates configurations, capacities, interfaces, and contracting requirements. During detailed design, it consolidates calculations, selected equipment, sequences, and actual installation conditions. Relevant changes need to update the BoD and the traceability matrix.
OPR, URS, and Basis of Design are not synonyms
| Aspect | OPR | URS | Basis of Design |
| perspective | owner | user and operations | designer |
| nature | project objectives and criteria | functional and operational needs | technical response and justification |
| initial stage | pre-design | requirements gathering | conceptual design |
| dominant language | performance, risk, and outcome | function, use, and interface | engineering, architecture, and calculation |
| approval authority | owner | owner and functional owners | responsible engineer and owner, according to governance |
| relationship with suppliers | guides the scope | informs required functions | supports specifications and drawings |
| relationship with testing | defines what must be demonstrated | defines behaviors and uses | defines how the solution should respond |
The documentation model may vary. Some organizations adopt a single OPR with user-requirement appendices. Others maintain separate URSs by discipline or functional group. They may also use Employer’s Requirements, Project Requirements, Design Criteria, or Technical Requirements. The name matters less than clarity of authorship, hierarchy, approval, and traceability.
Recommended documentation architecture
A practical structure for Data Centers can be organized into five levels.
- Objectives and investment decision: business case, feasibility study, strategic requirements, and project boundaries.
- Owner requirements: OPR, policies, targets, risk criteria, availability, security, sustainability, and operations.
- User and functional requirements: URS, flows, capacities, interfaces, data, access, alarms, reports, and maintenance.
- Engineering response: Basis of Design, design criteria, calculations, diagrams, layouts, and interface matrix.
- Contractual and verification documents: specifications, drawings, RFP, submittals, FAT, SAT, integrated tests, as-built documentation, and operational documentation.
This architecture does not require five isolated files. It requires five identifiable and governed layers of information.
When should each document be developed?
| Phase | OPR | URS | Basis of Design |
| opportunity and feasibility | initial version with objectives, capacity, risks, and criteria | preliminary needs of critical groups | concepts or alternatives study only |
| site selection | updates external requirements, schedule, and expansion | includes access, operations, and connectivity | records criteria used in the comparison |
| conceptual design | approved initial baseline | prioritized functional requirements | architectures and conceptual decisions |
| basic design | controlled revision | consolidation for contracting | configurations, capacities, interfaces, and performance |
| detailed design | changes only through formal control | detailing of affected functions | calculations, equipment, sequences, and final criteria |
| construction | update through approved changes | validation of functional deviations | incorporates submittals and field decisions |
| commissioning | primary verification reference | basis for operational scenarios | reference for designed behavior |
| handover and operations | converted into current facility requirements | consolidated procedures and uses | technical baseline and decision record |
The OPR should neither be frozen too early nor remain undefined until the end. Governance should establish baselines by gate and a formal process for subsequent changes.
Minimum content of an OPR for a Data Center
Project objectives
The document should explain why the Data Center exists, which services it supports, which operating model will be adopted, and which outcomes justify the investment. This prevents disciplines from developing technically correct solutions that are misaligned with the purpose.
Capacity and growth
Initial and ultimate ICT load, densities, number of racks, occupancy, horizon, expansion blocks, and triggers should be recorded. The requirement needs to distinguish rated capacity, available capacity, and effectively usable capacity.
Availability and continuity
The OPR should define tolerance for interruptions, the need for concurrent maintainability, acceptable degraded modes, recovery, and dependencies between physical infrastructure and application architecture. A Tier or Rated classification does not replace the definition of the owner’s services and risks.
Operations and maintenance
Staffing, coverage, training, inventory, support, access, maintenance windows, procedures, switching capability, and maintenance philosophy should be considered. A highly redundant solution may be inappropriate when its complexity exceeds operational capability.
Security and compliance
The owner needs to specify area classification, access profiles, records, retention, investigation, privacy, segregation, audit, and applicable regulatory requirements.
Efficiency and sustainability
Energy, water, emissions, metering, reporting, and load-condition targets should have clear boundaries. A PUE value without utilization condition, climate, and measurement boundary is not a verifiable requirement.
Expansion, flexibility, and lifecycle
The OPR should state which interfaces need to be prepared, which assets may be brought forward, how new phases will be built, and which technologies should remain replaceable.
Commissioning and acceptance
The document should establish system scope, test levels, supplier participation, load availability, evidence, criteria, training, and documentation required for acceptance.
Turn approved requirements into a coordinated and verifiable multidisciplinary architecture.
A3A Engenharia develops conceptual, basic, and detailed designs while preserving the OPR, Basis of Design, interfaces, performance criteria, and acceptance requirements.
Content of a URS for a Data Center
The URS should transform needs into functional statements. It may be organized by users, areas, or systems, but it needs to avoid duplication and conflicts.
ICT capacity and deployment
Examples include equipment dimensions and weights, power per rack, A/B feeds, connectors, positions, occupancy, deployment flow, staging, docks, elevators, and movement routes.
Networks and interconnection
The number and diversity of entrances, carriers, MMRs, backbone, fibers, cabling, patching, identification, latency, capacity, growth, and certification requirements should be defined.
Operations and monitoring
The URS may specify alarms, priorities, points, dashboards, histories, reports, integrations, time synchronization, remote access, out-of-band access, and behavior during loss of communication.
Physical security
This includes access journeys, visitors, contractors, dual custody, critical areas, video surveillance, retention, investigation, credentials, biometrics, interlocks, and contingency.
Maintenance
Access, spaces, lifting, replacement, isolation, drainage, lighting, outlets, test points, tools, parts, and work restrictions in active areas should be recorded.
Documentation and training
The URS may define formats, language, coding, models, as-built documentation, asset lists, manuals, videos, simulators, training, competency assessment, and post-change updates.
How to write verifiable requirements
A quality requirement should be necessary, clear, singular, feasible, traceable, and verifiable. ISO/IEC/IEEE 29148 provides general requirements-engineering principles that can be adapted to the project.
Recommended structure
| Field | Function |
| ID | unique and stable identification |
| statement | requirement in objective language |
| source | owner, user, standard, risk, or decision |
| rationale | reason and consequence |
| priority | mandatory, desirable, or optional |
| owner | who decides and maintains |
| verification method | analysis, inspection, demonstration, or test |
| verification phase | design, FAT, SAT, IST, or operations |
| evidence | document, report, record, or measurement |
| status | proposed, approved, changed, met, or pending |
Obligation language
Contractual requirements should use consistent language. A common formulation uses “shall” for obligations and avoids vague expressions such as “where possible,” “adequate,” “preferably,” or “high quality” without a criterion.
Weak: the cooling system should be highly reliable.
Better: the loss of one cooling unit in the block shall not raise the ICT equipment inlet temperature above the approved limit under design conditions and for the period defined for operational response.
The formulation still needs to indicate the limit, load condition, environment, duration, measurement method, and evidence.
Requirements traceability matrix
The matrix connects each requirement to decisions, documents, and verifications. It does not need to be a standalone spreadsheet; it may exist in a requirements platform or common data environment. The essential point is to maintain auditable relationships.
| Requirement | Source | BoD | Design document | Supply | Verification | Status |
| OPR-AV-001 | business continuity | BOD-EL-03 | single-line diagram and electrical specification | UPS, switchboards, and controls | FAT, SAT, and IST | approved |
| URS-OPS-014 | operations | BOD-AUT-08 | point list and cause-and-effect matrix | BMS/EPMS | demonstration and test | under review |
| OPR-SEC-006 | security policy | BOD-SEG-02 | zone architecture | access control and video surveillance | inspection and scenario | approved |
| URS-MAN-021 | maintenance | BOD-MEC-12 | layout and details | HVAC equipment | access inspection | pending |
The matrix should support bidirectional traceability: from a requirement to its evidence and from a test or equipment item back to the requirements that justify its existence.
Coverage and gaps
Simple indicators support governance:
- requirements with no BoD response;
- design decisions without a source requirement;
- requirements without a verification method;
- tests without an associated requirement;
- changes without impact analysis;
- approved requirements still lacking evidence of compliance.
The number of links does not replace technical review. A relationship may exist and still be inadequate.
Example of a complete requirement chain
Consider the need to maintain the electrical supply without shutting down critical loads.
- Owner objective: critical services must remain available during planned maintenance of the electrical infrastructure.
- OPR: each block shall allow planned removal of the defined components without interruption of loads classified as critical, within approved conditions and exceptions.
- Operations URS: the team needs to perform isolation, transfer, lockout, testing, and return through controlled procedures, with states visible in the EPMS.
- Basis of Design: the solution uses A/B paths, isolation devices, bypass, transfer logic, and metering according to the analyzed modes.
- Design: single-line diagrams, interlocks, signal lists, specifications, selectivity, layouts, and routes detail the solution.
- Verification: design review, control FAT, SAT, transfer testing, and IST demonstrate the approved scenarios.
- Operations: MOP, SOP, and training consolidate the procedure and known constraints.
Without this chain, the phrase “concurrent maintainability” may be interpreted differently by the owner, designer, manufacturer, installer, and operator.
How to develop the Basis of Design
Assumptions and boundaries
The document should begin with scope, references, design conditions, received data, assumptions, exclusions, and responsibilities. Each relevant assumption needs a source and status. Information that has not yet been confirmed should not disappear inside a calculation.
Capacity criteria
The BoD records load models, factors, margins, diversity, growth, derating, reserves, and usable capacity. It should explain how ICT load is translated into electrical demand, thermal load, water, space, weight, and telecommunications.
Architecture and redundancy
Topologies should be justified by requirements and risk analysis. The document needs to identify redundant and shared components, common modes, degraded states, recovery, and limitations.
Technology selection
The decision among chilled water, direct expansion, InRow, liquid cooling, lead-acid or lithium batteries, centralized or distributed UPS, and other alternatives should record technical and operational criteria, not merely brands or preferences.
Sequences and interlocks
The BoD should describe expected behavior during startup, shutdown, failure, transfer, emergency, maintenance, and return. Sequences need to be consistent across electrical, mechanical, automation, fire, and security systems.
Maintainability and replacement
Isolation, access, disassembly, lifting, drainage, parts, tools, lighting, safety, and impact on other systems should be considered. Geometric space without a viable procedure does not represent maintainability.
Expansion and temporary states
The document needs to record initial condition, phases, ultimate capacity, prepared interfaces, and transient states. The final architecture may be resilient while an intermediate stage has different vulnerabilities.
Testability
Measurement points, loads, simulations, test modes, bypasses, temporary connections, and test safety should be planned. A requirement that cannot be verified in the field needs another approved evidence method.
Relationship with standards and technical references
The series ISO/IEC 22237 organizes principles, classifications, and infrastructure requirements for Data Centers. The ANSI/TIA-942-C covers architecture, telecommunications, power, cooling, security, and other systems for facilities of different types and scales.
These references do not write the owner’s OPR. They provide requirements, classifications, and good practices that need to be selected according to risks, legislation, and project purpose. Adopting a standard does not eliminate the need to state the edition, scope, exceptions, and specific criteria.
The article on Tier I, II, III, and IV in Data Centers explains why classification, redundancy, and service availability should not be confused.
Relationship with conceptual, basic, and detailed design
The article How to design a Data Center: stages, disciplines, and deliverables presents the complete multidisciplinary process. Within it, requirements documents and the BoD serve different functions in each phase.
| Phase | Requirements function | BoD function |
| conceptual | select objectives, priorities, and constraints | compare alternatives and establish principles |
| basic | consolidate criteria for contracting | define configurations, performance, and interfaces |
| detailed | control changes and affected details | record calculations, selections, and final behavior |
| construction | assess deviations and proposals | incorporate submittals and approved decisions |
| commissioning | define what must be demonstrated | explain how the solution should operate |
| operations | preserve intent and limits | form the technical baseline for future changes |
A detailed design does not compensate for inadequate requirements. It merely details, with greater precision, a solution that may be wrong.
OPR, URS, and BoD in the RFP and contracting
A consistent RFP should state which requirements are mandatory, which allow alternatives, and how deviations will be presented. The supplier should not have to infer owner objectives from incomplete drawings.
Contractual hierarchy
The documentation needs to establish precedence among the OPR, specifications, drawings, lists, standards, and proposals. The OPR may guide intent without necessarily being incorporated in full as a contractual document. The organization should avoid conflicts in which a high-level requirement contradicts a detailed obligation without a resolution mechanism.
Compliance matrix
Each bidder may be required to respond:
| Response | Meaning |
| complies | solution fully meets the requirement |
| complies with clarification | complies, but requires a recorded interpretation |
| alternative | offers a different solution with demonstrated impact |
| deviation | does not comply and requests formal acceptance |
| not applicable | requirement is outside scope, with justification |
Silence should not automatically be interpreted as compliance.
Technical deviations
The deviation needs to identify the affected requirement, proposed solution, reason, impact on capacity, availability, operations, maintenance, schedule, cost, testing, and documentation. Approval should update traceability and the BoD.
Keep requirements, decisions, deviations, and changes traceable throughout contracting and implementation.
Owner’s Engineering represents the owner’s interests in reviewing designs, proposals, submittals, interfaces, changes, and compliance evidence.
Change governance
Changes are inevitable; untraceable changes are not. A minimum process includes:
- identification of the change and affected requirements;
- rationale and alternatives;
- multidisciplinary impact analysis;
- assessment of cost, schedule, risk, operations, and testing;
- decision by a defined authority;
- update of OPR, URS, BoD, and associated documents;
- communication to stakeholders and review of the traceability matrix;
- verification of implementation and closure of the change.
The decision should preserve history. Silently replacing an assumption erases the reason previous choices were made.
Baselines and gates
At each gate, specific versions are approved as the baseline. New requirements enter through controlled change, not through scattered comments in minutes, emails, or drawings. This makes it possible to distinguish legitimate evolution from scope creep.
OPR quality review
Before approval, the OPR should be checked for:
| Criterion | Review question |
| completeness | are objectives, capacity, operations, security, expansion, and acceptance covered? |
| clarity | do vague terms have a definition and limit? |
| consistency | do requirements contradict one another? |
| feasibility | are schedule, technology, budget, and operations compatible? |
| priority | do conflicts have a decision rule? |
| verifiability | is a method and evidence possible? |
| traceability | are source, owner, and version recorded? |
| applicability | are standards and external requirements correctly selected? |
The review should involve functional owners, not only the engineering team.
URS quality review
The URS should be tested against real journeys and scenarios. Workshops may use flows such as deployment of a new rack, UPS maintenance, contractor entry, leak response, communication loss, sensor failure, access investigation, and capacity expansion.
This approach reveals requirements that generic lists do not capture: response time, permissions, visibility, space, sequence, data, documentation, and responsibilities.
Basis of Design quality review
The BoD needs to be reviewed by discipline and by interface. An adequate review cross-checks requirements, diagrams, calculations, layouts, sequences, and test methods.
Critical questions
- Does each architecture respond to approved requirements?
- Do capacities use consistent assumptions across disciplines?
- Have common modes and degraded states been identified?
- Can maintenance be performed safely?
- Can equipment be replaced?
- Are temporary phases represented?
- Are control sequences consistent?
- Does the design have test points and test conditions?
- Are exceptions and residual risks explicit?
A clash-detection review does not answer these questions.
Integration with BIM and the common data environment
BIM can associate requirements with spaces, systems, and assets, but it does not replace governance. The common data environment should control codes, versions, status, approvals, comments, and transmittals.
A possible structure relates:
- requirement to system and space;
- BIM object to specification and submittal;
- asset to test and report;
- change to affected documents;
- open item to owner and gate;
- as-built documentation to the operational asset register.
The links need to survive export, handover, and operations. A platform without a data plan can concentrate information that is lost during handover.
Integration with commissioning
Commissioning should not begin by writing tests at the end of construction. The ASHRAE/IES Standard 202 describes an integrated process for delivering facilities that meet the OPR.
Design review
The commissioning authority verifies whether the BoD and documents respond to the requirements, identifying gaps in testability, operations, metering, access, and sequence.
Submittals and FAT
Manufacturer proposals and drawings are evaluated against specifications and requirements. FATs can verify functions, controls, alarms, and performance before shipment, reducing discoveries on site.
SAT and functional testing
In the field, inspections and tests confirm installation, configuration, and behavior of individual systems. Each procedure should indicate requirements, preconditions, instruments, steps, criteria, and evidence.
Integrated systems testing
ISTs demonstrate interactions during failures and transitions: utility loss, generator start, UPS transfer, cooling failure, fire, loss of communication, maintenance, and return to normal condition.
Define verification criteria before procurement, installation, and testing.
Commissioning connects the OPR, Basis of Design, specifications, FAT, SAT, functional tests, and integrated tests to produce objective evidence of compliance.
Handover to operations
At the end, requirements and the BoD should be reconciled with the as-built facility. Operational documentation needs to reflect approved deviations, limitations, configurations, and evidence.
Current Facility Requirements
In the commissioning process, requirements of the existing facility may be consolidated as Current Facility Requirements. For Data Centers, this logic helps maintain an up-to-date reference after changes, expansions, and modernizations.
Operational baseline
The handover should connect:
- current requirements;
- final BoD;
- as-built documentation and diagrams;
- asset lists and configurations;
- tests and open items;
- MOPs, SOPs, and EOPs;
- training and competency;
- operating limits;
- maintenance plan;
- alarm and escalation matrix.
Without this reconciliation, operations receive historical documents that do not represent the actual facility.
Example OPR structure
| Section | Content |
| 1. governance | purpose, scope, authorities, approvals, and change control |
| 2. context | business, users, services, and operating model |
| 3. capacity | ICT, racks, density, growth, and phases |
| 4. availability | criticality, maintenance, failures, and recovery |
| 5. implementation | site, buildings, expansion, access, and logistics |
| 6. infrastructure | power, thermal systems, telecom, automation, and utilities |
| 7. security | physical, cyber, fire, and compliance |
| 8. operations | staff, procedures, maintenance, parts, and support |
| 9. sustainability | energy, water, emissions, metering, and reporting |
| 10. quality and testing | reviews, FAT, SAT, IST, and evidence |
| 11. documentation | formats, coding, BIM, as-built documentation, and handover |
| 12. risks and exceptions | conditions, accepted risks, and pending decisions |
Example Basis of Design structure
| Section | Content |
| 1. scope and references | boundaries, standards, input documents, and interfaces |
| 2. assumptions | data, design conditions, margins, and open items |
| 3. general criteria | capacity, availability, safety, and efficiency |
| 4. architecture | implementation, blocks, redundancy, and expansion |
| 5. disciplines | electrical, mechanical, telecom, automation, and security bases |
| 6. operating modes | normal, maintenance, failure, emergency, and return |
| 7. calculations and selections | models, factors, derating, and alternatives |
| 8. coordination | spaces, routes, loads, interfaces, and responsibilities |
| 9. testability | points, loads, procedures, and criteria |
| 10. risks and exceptions | limitations, deviations, and residual risk |
| 11. changes | decisions, revisions, and impacts |
| 12. appendices | diagrams, matrices, tables, and records |
Common mistakes
| Mistake | Consequence |
| copying the OPR from another project | requirements incompatible with business and operations |
| using vague terms | suppliers and designers adopt different interpretations |
| confusing requirement and solution | technology lock-in and limited competition |
| leaving users out of the process | operations receive a facility that is difficult to use and maintain |
| producing the BoD after the drawings | the document becomes a retrospective justification |
| failing to record assumptions | calculations appear precise despite uncertain data |
| failing to define verification methods | requirements cannot be objectively accepted |
| failing to control changes | design, contract, and tests use different versions |
| treating a standard as the OPR | owner-specific objectives are absent |
| disconnecting commissioning | tests are improvised at the end of construction |
| failing to reconcile as-built documentation and the BoD | the operational baseline does not represent the facility |
| creating excessive documents without hierarchy | duplication and conflict increase instead of decrease |
Documentation governance checklist
- Are the Data Center objective and operating model defined?
- Is there formal authority to approve requirements and changes?
- Does the OPR distinguish objectives, requirements, and preferences?
- Did IT, operations, security, and facilities users participate?
- Do requirements have IDs, source, priority, and owner?
- Were vague criteria converted into measurable conditions?
- Does each requirement have a verification method and phase?
- Does the BoD record assumptions and still-pending data?
- Do architecture choices have justification linked to requirements?
- Are capacities and margins consistent across disciplines?
- Are normal, maintenance, failure, and emergency modes described?
- Were expansions and temporary states considered?
- Does the matrix connect requirements, documents, supplies, and tests?
- Does the RFP require compliance and declaration of deviations?
- Are submittals reviewed against requirements and the BoD?
- Do changes update all affected documents?
- Do FAT, SAT, and IST reference verifiable requirements?
- Do open items have an owner, due date, and impact on acceptance?
- Was the as-built documentation reconciled with the final BoD?
- Did operations receive an updated baseline, procedures, and limits?
A3A Engenharia Consulting Engineering scope
A3A Engenharia supports owners and operators in structuring requirements and design bases for new Data Centers, expansions, modernizations, Edge environments, corporate facilities, colocation, and modular solutions.
The scope may include stakeholder workshops, needs assessment, preparation or review of the OPR and URS, development of the Basis of Design, traceability matrix, contracting criteria, multidisciplinary review, interface management, commissioning requirements, and reconciliation of final documentation.
The work can integrate the Data Center Feasibility Study, the Data Center Design, Owner’s Engineering for Data Centers and Data Center Commissioning and Acceptance.
Technical summary
OPR, URS, and Basis of Design have complementary functions. The OPR records owner objectives and criteria; the URS structures the needs of users and operators; and the BoD documents how engineering responds to those requirements through assumptions, criteria, architectures, calculations, and decisions.
Quality depends less on file names and more on governance: authorship, approval, hierarchy, identification, verifiability, traceability, and change control. Requirements should guide design, contracting, and testing; the BoD should explain the choices; and commissioning should produce evidence of compliance.
When this chain is maintained through as-built documentation and operations, the project preserves its technical intent. When it breaks, the project tends to accumulate implicit decisions, unevaluated deviations, and acceptance criteria defined too late.
Technical references
[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. Data Center Design: study, basic design, and detailed design. Ponta Grossa: A3A Engenharia.
Frequently asked questions
The OPR records owner objectives and criteria; the URS details users’ functional and operational needs; and the Basis of Design documents how the design team intends to meet those requirements.
Not necessarily. The organization may keep user requirements within the OPR or in separate documents. The essential point is to ensure authorship, approval, clarity, and traceability.
The owner is responsible for the content and approval. Consultants may facilitate workshops and draft the document, but decisions about objectives, risks, operations, and investment belong to the owner.
The design team and responsible engineers develop the BoD, recording the assumptions, criteria, calculations, architectures, and justifications used to meet approved requirements.
It depends on the contracting strategy. It may guide intent without being incorporated in full as a contractual document. The hierarchy among the OPR, specifications, drawings, and proposals should be explicit.
It should begin during pre-design or feasibility and mature through the gates. After each baseline, changes should follow a formal evaluation and approval process.
The requirement should indicate a condition, limit, and possible verification method, such as analysis, inspection, demonstration, or testing, as well as the expected evidence and verification phase.
No. The BoD explains the logic and basis of the solution. Calculation reports, technical specifications, specifications, diagrams, plans, and details develop and contractualize that solution.
The OPR defines what must be achieved; the BoD explains how the design intends to comply; and commissioning reviews, inspects, and tests the solution to produce evidence of compliance.
It is the mechanism that relates each requirement to its origin, BoD response, design documents, supplies, verification methods, evidence, and status.
Additional technical resources
Fundamentals and planning
- Data Center: what it is, how it works, and which systems make up the infrastructure
- Data Center feasibility study: power, connectivity, site, and risks
- How to choose a Data Center location
Requirements, architecture, and design
- How to design a Data Center: stages, disciplines, and deliverables
- Data Center Design
- Tier I, II, III, and IV in Data Centers
- Modular Data Center: design, risks, and when to use it
Governance, contracting, and change control
- Owner’s Engineering for Data Centers
- Integrated Engineering for Data Centers
- Stage-gate in engineering projects
- Risk management in engineering projects
Commissioning, verification, and acceptance
- Data Center Commissioning and Acceptance
- Commissioning of critical systems
- SLA: how to define and calculate service level
Specialized disciplines and systems
- Networks and Telecommunications for Data Centers
- Data Center Cooling
- DCIM for Data Centers
- Physical Security for Data Centers
- Fire Detection and Suppression in Data Centers
Deployment models and scales
- Hyperscale Data Center: what it is and how it works
- Colocation Data Center: how to evaluate a provider
- Edge Data Center: applications and architecture
- Micro Data Center: applications and specification criteria
