{"id":81789,"date":"2026-09-19T18:42:31","date_gmt":"2026-09-19T21:42:31","guid":{"rendered":"https:\/\/a3aengenharia.com\/?post_type=articles&#038;p=81789"},"modified":"2026-09-19T18:43:08","modified_gmt":"2026-09-19T21:43:08","slug":"basis-of-design-opr-urs-data-center-projects","status":"publish","type":"articles","link":"https:\/\/a3aengenharia.com\/en-us\/content\/technical-articles\/basis-of-design-opr-urs-data-center-projects\/","title":{"rendered":"Basis of Design, OPR and URS in Data Center Projects"},"content":{"rendered":"\n<p class=\"wp-block-paragraph\">The <strong>OPR, URS, and the Basis of Design organize three different perspectives of a Data Center project<\/strong>. The OPR records what the owner intends to achieve; the URS details users\u2019 functional and operational needs; and the Basis of Design documents how the engineering team interprets those requirements and develops the technical solution.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">These documents should not be treated as interchangeable names. The <strong>Owner\u2019s Project Requirements (OPR)<\/strong> belongs to owner governance and should express objectives, performance criteria, operations, maintenance, expansion, risks, and acceptance conditions. The <strong>User Requirements Specification (URS)<\/strong> brings together requirements from users, operators, technology teams, security, facilities, and other parties that will use or support the facility. The <strong>Basis of Design (BoD)<\/strong> is produced by the design team to record assumptions, criteria, calculations, decisions, interfaces, and justifications adopted to meet the OPR and approved needs.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">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.<\/p>\n\n\n\n\n<h2 class=\"wp-block-heading\">Technical summary<\/h2>\n\n\n\n<figure class=\"wp-block-table\"><table><tbody><tr><td>Document<\/td><td>Main question<\/td><td>Primary responsibility<\/td><td>Core content<\/td><td>Use in acceptance<\/td><\/tr><tr><td>OPR<\/td><td>What does the owner need to achieve?<\/td><td>Owner, sponsor, and governance<\/td><td>objectives, performance, risks, operations, expansion, and success criteria<\/td><td>defines the intent that must be demonstrated<\/td><\/tr><tr><td>URS<\/td><td>What do users and operators need to do and receive?<\/td><td>users, IT, operations, facilities, and functional areas<\/td><td>functions, capacities, interfaces, operating conditions, and constraints<\/td><td>originates verifiable functional and operational requirements<\/td><\/tr><tr><td>Basis of Design<\/td><td>How does engineering intend to meet the requirements?<\/td><td>designers and responsible engineers<\/td><td>assumptions, criteria, architectures, calculations, selections, and justifications<\/td><td>explains the solution that will be inspected and tested<\/td><\/tr><tr><td>Specifications and drawings<\/td><td>What must be supplied and built?<\/td><td>design team<\/td><td>contractual requirements, details, materials, equipment, and installation<\/td><td>establishes supply and execution obligations<\/td><\/tr><tr><td>Commissioning plan and procedures<\/td><td>How will compliance be demonstrated?<\/td><td>commissioning authority and project team<\/td><td>inspections, tests, evidence, responsibilities, and criteria<\/td><td>produces documented verification<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n<p class=\"wp-block-paragraph\">The correct sequence is not necessarily linear because requirements and decisions mature throughout the project. However, the direction of authority should remain clear: <strong>the design responds to the requirements; requirements should not be silently rewritten to justify a solution already selected<\/strong>.<\/p>\n\n\n\n\n<h2 class=\"wp-block-heading\">What is Owner\u2019s Project Requirements?<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">The <strong>Owner\u2019s Project Requirements<\/strong>, or OPR, is the document that records the project\u2019s functional requirements and the owner\u2019s expectations for use and operation. OPR terminology and function are well established in ASHRAE\u2019s commissioning process. ASHRAE itself emphasizes that the OPR should guide verification of success from pre-design through operations.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">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 \u201chigh availability,\u201d \u201cmaximum security,\u201d or \u201chigh efficiency.\u201d These expressions need to be translated into conditions, priorities, limits, and verification methods.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">The OPR belongs to the owner<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">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.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">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.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">OPR is more than a space or program brief<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">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:<\/p>\n\n\n\n<ul class=\"wp-block-list\"><li>reduce initial CAPEX versus preserve expansion;<\/li><li>increase availability versus limit operational complexity;<\/li><li>reduce water consumption versus reduce energy consumption;<\/li><li>standardize equipment versus preserve supplier competition;<\/li><li>bring shared infrastructure forward versus implement only occupied capacity.<\/li><\/ul>\n\n\n\n<p class=\"wp-block-paragraph\">These tensions are not resolved by an equipment list. They require governance and explicit decisions.<\/p>\n\n\n\n\n<h2 class=\"wp-block-heading\">What is a User Requirements Specification?<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">The <strong>User Requirements Specification<\/strong>, 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.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">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.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Who are the users of a Data Center?<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">The concept includes more people and processes than the end users of applications. Relevant groups include:<\/p>\n\n\n\n<figure class=\"wp-block-table\"><table><tbody><tr><td>Group<\/td><td>Examples of needs<\/td><\/tr><tr><td>IT and platform<\/td><td>power per rack, connectivity, spaces, deployment, access, and capacity<\/td><\/tr><tr><td>infrastructure operations<\/td><td>monitoring, alarms, switching, maintenance, parts, and documentation<\/td><\/tr><tr><td>security<\/td><td>zones, credentialing, investigation, image retention, and response<\/td><\/tr><tr><td>facilities<\/td><td>utilities, contracts, inspections, cleaning, water, and facility management<\/td><\/tr><tr><td>commissioning<\/td><td>measurement points, test modes, loads, access, and evidence<\/td><\/tr><tr><td>sustainability<\/td><td>metering, energy, water, emissions, reporting, and targets<\/td><\/tr><tr><td>business or customers<\/td><td>capacity, schedule, availability, SLA, segregation, and expansion<\/td><\/tr><tr><td>audit and compliance<\/td><td>records, traceability, segregation of duties, and document retention<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n<p class=\"wp-block-paragraph\">A need may be legitimate without being automatically approved. The URS should record origin, justification, priority, and approval owner.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">A user requirement is not a solution preference<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">\u201cWe need to install UPS systems from manufacturer X\u201d 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.<\/p>\n\n\n\n\n<h2 class=\"wp-block-heading\">What is a Basis of Design?<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">The <strong>Basis of Design<\/strong>, or BoD, is the design-team document that records the concepts, criteria, assumptions, calculations, and decisions used to meet the owner\u2019s requirements. It explains the logic of the solution and creates a bridge among the OPR, URS, drawings, technical specifications, specifications, and tests.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">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.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">BoD is not a generic descriptive specification<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">A descriptive specification may describe systems and equipment. The Basis of Design should explain <strong>why<\/strong> the configuration was adopted, which assumptions support the calculations, which alternatives were rejected, which interfaces are critical, and how performance will be verified.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">For example, it is not enough to state that there will be A\/B electrical distribution. The BoD should clarify:<\/p>\n\n\n\n<ul class=\"wp-block-list\"><li>which loads receive two paths;<\/li><li>where the paths remain independent;<\/li><li>which elements are shared;<\/li><li>how each path is maintained;<\/li><li>which failures were considered;<\/li><li>how transfers and returns occur;<\/li><li>which temporary conditions arise during expansion;<\/li><li>how tests will demonstrate expected behavior.<\/li><\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">The BoD should evolve with the design<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">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.<\/p>\n\n\n\n\n<h2 class=\"wp-block-heading\">OPR, URS, and Basis of Design are not synonyms<\/h2>\n\n\n\n<figure class=\"wp-block-table\"><table><tbody><tr><td>Aspect<\/td><td>OPR<\/td><td>URS<\/td><td>Basis of Design<\/td><\/tr><tr><td>perspective<\/td><td>owner<\/td><td>user and operations<\/td><td>designer<\/td><\/tr><tr><td>nature<\/td><td>project objectives and criteria<\/td><td>functional and operational needs<\/td><td>technical response and justification<\/td><\/tr><tr><td>initial stage<\/td><td>pre-design<\/td><td>requirements gathering<\/td><td>conceptual design<\/td><\/tr><tr><td>dominant language<\/td><td>performance, risk, and outcome<\/td><td>function, use, and interface<\/td><td>engineering, architecture, and calculation<\/td><\/tr><tr><td>approval authority<\/td><td>owner<\/td><td>owner and functional owners<\/td><td>responsible engineer and owner, according to governance<\/td><\/tr><tr><td>relationship with suppliers<\/td><td>guides the scope<\/td><td>informs required functions<\/td><td>supports specifications and drawings<\/td><\/tr><tr><td>relationship with testing<\/td><td>defines what must be demonstrated<\/td><td>defines behaviors and uses<\/td><td>defines how the solution should respond<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n<p class=\"wp-block-paragraph\">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\u2019s Requirements, Project Requirements, Design Criteria, or Technical Requirements. The name matters less than clarity of authorship, hierarchy, approval, and traceability.<\/p>\n\n\n\n\n<h2 class=\"wp-block-heading\">Recommended documentation architecture<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">A practical structure for Data Centers can be organized into five levels.<\/p>\n\n\n\n<ol class=\"wp-block-list\">\n<li><strong>Objectives and investment decision:<\/strong> business case, feasibility study, strategic requirements, and project boundaries.<\/li>\n\n\n\n<li><strong>Owner requirements:<\/strong> OPR, policies, targets, risk criteria, availability, security, sustainability, and operations.<\/li>\n\n\n\n<li><strong>User and functional requirements:<\/strong> URS, flows, capacities, interfaces, data, access, alarms, reports, and maintenance.<\/li>\n\n\n\n<li><strong>Engineering response:<\/strong> Basis of Design, design criteria, calculations, diagrams, layouts, and interface matrix.<\/li>\n\n\n\n<li><strong>Contractual and verification documents:<\/strong> specifications, drawings, RFP, submittals, FAT, SAT, integrated tests, as-built documentation, and operational documentation.<\/li>\n<\/ol>\n\n\n\n<p class=\"wp-block-paragraph\">This architecture does not require five isolated files. It requires five identifiable and governed layers of information.<\/p>\n\n\n\n\n<h2 class=\"wp-block-heading\">When should each document be developed?<\/h2>\n\n\n\n<figure class=\"wp-block-table\"><table><tbody><tr><td>Phase<\/td><td>OPR<\/td><td>URS<\/td><td>Basis of Design<\/td><\/tr><tr><td>opportunity and feasibility<\/td><td>initial version with objectives, capacity, risks, and criteria<\/td><td>preliminary needs of critical groups<\/td><td>concepts or alternatives study only<\/td><\/tr><tr><td>site selection<\/td><td>updates external requirements, schedule, and expansion<\/td><td>includes access, operations, and connectivity<\/td><td>records criteria used in the comparison<\/td><\/tr><tr><td>conceptual design<\/td><td>approved initial baseline<\/td><td>prioritized functional requirements<\/td><td>architectures and conceptual decisions<\/td><\/tr><tr><td>basic design<\/td><td>controlled revision<\/td><td>consolidation for contracting<\/td><td>configurations, capacities, interfaces, and performance<\/td><\/tr><tr><td>detailed design<\/td><td>changes only through formal control<\/td><td>detailing of affected functions<\/td><td>calculations, equipment, sequences, and final criteria<\/td><\/tr><tr><td>construction<\/td><td>update through approved changes<\/td><td>validation of functional deviations<\/td><td>incorporates submittals and field decisions<\/td><\/tr><tr><td>commissioning<\/td><td>primary verification reference<\/td><td>basis for operational scenarios<\/td><td>reference for designed behavior<\/td><\/tr><tr><td>handover and operations<\/td><td>converted into current facility requirements<\/td><td>consolidated procedures and uses<\/td><td>technical baseline and decision record<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n<p class=\"wp-block-paragraph\">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.<\/p>\n\n\n\n\n<h2 class=\"wp-block-heading\">Minimum content of an OPR for a Data Center<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Project objectives<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">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.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Capacity and growth<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">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.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Availability and continuity<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">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&#8217;s services and risks.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Operations and maintenance<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">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.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Security and compliance<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">The owner needs to specify area classification, access profiles, records, retention, investigation, privacy, segregation, audit, and applicable regulatory requirements.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Efficiency and sustainability<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">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.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Expansion, flexibility, and lifecycle<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">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.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Commissioning and acceptance<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">The document should establish system scope, test levels, supplier participation, load availability, evidence, criteria, training, and documentation required for acceptance.<\/p>\n\n\n\n<div class=\"wp-block-a3a-destaque\">\n<p class=\"wp-block-paragraph\"><strong>Turn approved requirements into a coordinated and verifiable multidisciplinary architecture.<\/strong><\/p>\n\n\n\n<p class=\"wp-block-paragraph\">A3A Engenharia develops conceptual, basic, and detailed designs while preserving the OPR, Basis of Design, interfaces, performance criteria, and acceptance requirements.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><a href=\"\/servicos\/planejamento\/projeto-de-data-center\/\"><strong>Learn about the Data Center Design service<\/strong><\/a><\/p>\n<\/div>\n\n\n\n\n<h2 class=\"wp-block-heading\">Content of a URS for a Data Center<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">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.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">ICT capacity and deployment<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">Examples include equipment dimensions and weights, power per rack, A\/B feeds, connectors, positions, occupancy, deployment flow, staging, docks, elevators, and movement routes.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Networks and interconnection<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">The number and diversity of entrances, carriers, MMRs, backbone, fibers, cabling, patching, identification, latency, capacity, growth, and certification requirements should be defined.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Operations and monitoring<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">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.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Physical security<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">This includes access journeys, visitors, contractors, dual custody, critical areas, video surveillance, retention, investigation, credentials, biometrics, interlocks, and contingency.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Maintenance<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">Access, spaces, lifting, replacement, isolation, drainage, lighting, outlets, test points, tools, parts, and work restrictions in active areas should be recorded.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Documentation and training<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">The URS may define formats, language, coding, models, as-built documentation, asset lists, manuals, videos, simulators, training, competency assessment, and post-change updates.<\/p>\n\n\n\n\n<h2 class=\"wp-block-heading\">How to write verifiable requirements<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">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.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Recommended structure<\/h3>\n\n\n\n<figure class=\"wp-block-table\"><table><tbody><tr><td>Field<\/td><td>Function<\/td><\/tr><tr><td>ID<\/td><td>unique and stable identification<\/td><\/tr><tr><td>statement<\/td><td>requirement in objective language<\/td><\/tr><tr><td>source<\/td><td>owner, user, standard, risk, or decision<\/td><\/tr><tr><td>rationale<\/td><td>reason and consequence<\/td><\/tr><tr><td>priority<\/td><td>mandatory, desirable, or optional<\/td><\/tr><tr><td>owner<\/td><td>who decides and maintains<\/td><\/tr><tr><td>verification method<\/td><td>analysis, inspection, demonstration, or test<\/td><\/tr><tr><td>verification phase<\/td><td>design, FAT, SAT, IST, or operations<\/td><\/tr><tr><td>evidence<\/td><td>document, report, record, or measurement<\/td><\/tr><tr><td>status<\/td><td>proposed, approved, changed, met, or pending<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n<h3 class=\"wp-block-heading\">Obligation language<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">Contractual requirements should use consistent language. A common formulation uses \u201cshall\u201d for obligations and avoids vague expressions such as \u201cwhere possible,\u201d \u201cadequate,\u201d \u201cpreferably,\u201d or \u201chigh quality\u201d without a criterion.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>Weak:<\/strong> the cooling system should be highly reliable.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>Better:<\/strong> 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.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">The formulation still needs to indicate the limit, load condition, environment, duration, measurement method, and evidence.<\/p>\n\n\n\n\n<h2 class=\"wp-block-heading\">Requirements traceability matrix<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">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.<\/p>\n\n\n\n<figure class=\"wp-block-table\"><table><tbody><tr><td>Requirement<\/td><td>Source<\/td><td>BoD<\/td><td>Design document<\/td><td>Supply<\/td><td>Verification<\/td><td>Status<\/td><\/tr><tr><td>OPR-AV-001<\/td><td>business continuity<\/td><td>BOD-EL-03<\/td><td>single-line diagram and electrical specification<\/td><td>UPS, switchboards, and controls<\/td><td>FAT, SAT, and IST<\/td><td>approved<\/td><\/tr><tr><td>URS-OPS-014<\/td><td>operations<\/td><td>BOD-AUT-08<\/td><td>point list and cause-and-effect matrix<\/td><td>BMS\/EPMS<\/td><td>demonstration and test<\/td><td>under review<\/td><\/tr><tr><td>OPR-SEC-006<\/td><td>security policy<\/td><td>BOD-SEG-02<\/td><td>zone architecture<\/td><td>access control and video surveillance<\/td><td>inspection and scenario<\/td><td>approved<\/td><\/tr><tr><td>URS-MAN-021<\/td><td>maintenance<\/td><td>BOD-MEC-12<\/td><td>layout and details<\/td><td>HVAC equipment<\/td><td>access inspection<\/td><td>pending<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n<p class=\"wp-block-paragraph\">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.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Coverage and gaps<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">Simple indicators support governance:<\/p>\n\n\n\n<ul class=\"wp-block-list\"><li>requirements with no BoD response;<\/li><li>design decisions without a source requirement;<\/li><li>requirements without a verification method;<\/li><li>tests without an associated requirement;<\/li><li>changes without impact analysis;<\/li><li>approved requirements still lacking evidence of compliance.<\/li><\/ul>\n\n\n\n<p class=\"wp-block-paragraph\">The number of links does not replace technical review. A relationship may exist and still be inadequate.<\/p>\n\n\n\n\n<h2 class=\"wp-block-heading\">Example of a complete requirement chain<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Consider the need to maintain the electrical supply without shutting down critical loads.<\/p>\n\n\n\n<ol class=\"wp-block-list\">\n<li><strong>Owner objective:<\/strong> critical services must remain available during planned maintenance of the electrical infrastructure.<\/li>\n\n\n\n<li><strong>OPR:<\/strong> each block shall allow planned removal of the defined components without interruption of loads classified as critical, within approved conditions and exceptions.<\/li>\n\n\n\n<li><strong>Operations URS:<\/strong> the team needs to perform isolation, transfer, lockout, testing, and return through controlled procedures, with states visible in the EPMS.<\/li>\n\n\n\n<li><strong>Basis of Design:<\/strong> the solution uses A\/B paths, isolation devices, bypass, transfer logic, and metering according to the analyzed modes.<\/li>\n\n\n\n<li><strong>Design:<\/strong> single-line diagrams, interlocks, signal lists, specifications, selectivity, layouts, and routes detail the solution.<\/li>\n\n\n\n<li><strong>Verification:<\/strong> design review, control FAT, SAT, transfer testing, and IST demonstrate the approved scenarios.<\/li>\n\n\n\n<li><strong>Operations:<\/strong> MOP, SOP, and training consolidate the procedure and known constraints.<\/li>\n<\/ol>\n\n\n\n<p class=\"wp-block-paragraph\">Without this chain, the phrase \u201cconcurrent maintainability\u201d may be interpreted differently by the owner, designer, manufacturer, installer, and operator.<\/p>\n\n\n\n\n<h2 class=\"wp-block-heading\">How to develop the Basis of Design<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Assumptions and boundaries<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">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.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Capacity criteria<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">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.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Architecture and redundancy<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">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.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Technology selection<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">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.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Sequences and interlocks<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">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.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Maintainability and replacement<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">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.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Expansion and temporary states<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">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.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Testability<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">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.<\/p>\n\n\n\n\n<h2 class=\"wp-block-heading\">Relationship with standards and technical references<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">The series <a href=\"https:\/\/www.iso.org\/standard\/78550.html\">ISO\/IEC 22237<\/a> organizes principles, classifications, and infrastructure requirements for Data Centers. The <a href=\"https:\/\/tiaonline.org\/resource\/tia-942-c-data-center-infrastructure-standard\/\">ANSI\/TIA-942-C<\/a> covers architecture, telecommunications, power, cooling, security, and other systems for facilities of different types and scales.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">These references do not write the owner\u2019s 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.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">The article on <a href=\"\/conteudo\/artigos-tecnicos\/data-center-tier-3\/\">Tier I, II, III, and IV in Data Centers<\/a> explains why classification, redundancy, and service availability should not be confused.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Relationship with conceptual, basic, and detailed design<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">The article <a href=\"\/conteudo\/artigos-tecnicos\/como-projetar-data-center\/\">How to design a Data Center: stages, disciplines, and deliverables<\/a> presents the complete multidisciplinary process. Within it, requirements documents and the BoD serve different functions in each phase.<\/p>\n\n\n\n<figure class=\"wp-block-table\"><table><tbody><tr><td>Phase<\/td><td>Requirements function<\/td><td>BoD function<\/td><\/tr><tr><td>conceptual<\/td><td>select objectives, priorities, and constraints<\/td><td>compare alternatives and establish principles<\/td><\/tr><tr><td>basic<\/td><td>consolidate criteria for contracting<\/td><td>define configurations, performance, and interfaces<\/td><\/tr><tr><td>detailed<\/td><td>control changes and affected details<\/td><td>record calculations, selections, and final behavior<\/td><\/tr><tr><td>construction<\/td><td>assess deviations and proposals<\/td><td>incorporate submittals and approved decisions<\/td><\/tr><tr><td>commissioning<\/td><td>define what must be demonstrated<\/td><td>explain how the solution should operate<\/td><\/tr><tr><td>operations<\/td><td>preserve intent and limits<\/td><td>form the technical baseline for future changes<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n<p class=\"wp-block-paragraph\">A detailed design does not compensate for inadequate requirements. It merely details, with greater precision, a solution that may be wrong.<\/p>\n\n\n\n\n<h2 class=\"wp-block-heading\">OPR, URS, and BoD in the RFP and contracting<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">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.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Contractual hierarchy<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">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.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Compliance matrix<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">Each bidder may be required to respond:<\/p>\n\n\n\n<figure class=\"wp-block-table\"><table><tbody><tr><td>Response<\/td><td>Meaning<\/td><\/tr><tr><td>complies<\/td><td>solution fully meets the requirement<\/td><\/tr><tr><td>complies with clarification<\/td><td>complies, but requires a recorded interpretation<\/td><\/tr><tr><td>alternative<\/td><td>offers a different solution with demonstrated impact<\/td><\/tr><tr><td>deviation<\/td><td>does not comply and requests formal acceptance<\/td><\/tr><tr><td>not applicable<\/td><td>requirement is outside scope, with justification<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n<p class=\"wp-block-paragraph\">Silence should not automatically be interpreted as compliance.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Technical deviations<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">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.<\/p>\n\n\n\n<div class=\"wp-block-a3a-destaque\">\n<p class=\"wp-block-paragraph\"><strong>Keep requirements, decisions, deviations, and changes traceable throughout contracting and implementation.<\/strong><\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Owner\u2019s Engineering represents the owner\u2019s interests in reviewing designs, proposals, submittals, interfaces, changes, and compliance evidence.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><a href=\"\/servicos\/contratacao-integrada\/owners-engineering-para-data-centers\/\"><strong>Learn about Owner\u2019s Engineering for Data Centers<\/strong><\/a><\/p>\n<\/div>\n\n\n\n\n<h2 class=\"wp-block-heading\">Change governance<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Changes are inevitable; untraceable changes are not. A minimum process includes:<\/p>\n\n\n\n<ol class=\"wp-block-list\">\n<li>identification of the change and affected requirements;<\/li>\n\n\n\n<li>rationale and alternatives;<\/li>\n\n\n\n<li>multidisciplinary impact analysis;<\/li>\n\n\n\n<li>assessment of cost, schedule, risk, operations, and testing;<\/li>\n\n\n\n<li>decision by a defined authority;<\/li>\n\n\n\n<li>update of OPR, URS, BoD, and associated documents;<\/li>\n\n\n\n<li>communication to stakeholders and review of the traceability matrix;<\/li>\n\n\n\n<li>verification of implementation and closure of the change.<\/li>\n<\/ol>\n\n\n\n<p class=\"wp-block-paragraph\">The decision should preserve history. Silently replacing an assumption erases the reason previous choices were made.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Baselines and gates<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">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.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">OPR quality review<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Before approval, the OPR should be checked for:<\/p>\n\n\n\n<figure class=\"wp-block-table\"><table><tbody><tr><td>Criterion<\/td><td>Review question<\/td><\/tr><tr><td>completeness<\/td><td>are objectives, capacity, operations, security, expansion, and acceptance covered?<\/td><\/tr><tr><td>clarity<\/td><td>do vague terms have a definition and limit?<\/td><\/tr><tr><td>consistency<\/td><td>do requirements contradict one another?<\/td><\/tr><tr><td>feasibility<\/td><td>are schedule, technology, budget, and operations compatible?<\/td><\/tr><tr><td>priority<\/td><td>do conflicts have a decision rule?<\/td><\/tr><tr><td>verifiability<\/td><td>is a method and evidence possible?<\/td><\/tr><tr><td>traceability<\/td><td>are source, owner, and version recorded?<\/td><\/tr><tr><td>applicability<\/td><td>are standards and external requirements correctly selected?<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n<p class=\"wp-block-paragraph\">The review should involve functional owners, not only the engineering team.<\/p>\n\n\n\n\n<h2 class=\"wp-block-heading\">URS quality review<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">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.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">This approach reveals requirements that generic lists do not capture: response time, permissions, visibility, space, sequence, data, documentation, and responsibilities.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Basis of Design quality review<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">The BoD needs to be reviewed by discipline and by interface. An adequate review cross-checks requirements, diagrams, calculations, layouts, sequences, and test methods.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Critical questions<\/h3>\n\n\n\n<ul class=\"wp-block-list\"><li>Does each architecture respond to approved requirements?<\/li><li>Do capacities use consistent assumptions across disciplines?<\/li><li>Have common modes and degraded states been identified?<\/li><li>Can maintenance be performed safely?<\/li><li>Can equipment be replaced?<\/li><li>Are temporary phases represented?<\/li><li>Are control sequences consistent?<\/li><li>Does the design have test points and test conditions?<\/li><li>Are exceptions and residual risks explicit?<\/li><\/ul>\n\n\n\n<p class=\"wp-block-paragraph\">A clash-detection review does not answer these questions.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Integration with BIM and the common data environment<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">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.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">A possible structure relates:<\/p>\n\n\n\n<ul class=\"wp-block-list\"><li>requirement to system and space;<\/li><li>BIM object to specification and submittal;<\/li><li>asset to test and report;<\/li><li>change to affected documents;<\/li><li>open item to owner and gate;<\/li><li>as-built documentation to the operational asset register.<\/li><\/ul>\n\n\n\n<p class=\"wp-block-paragraph\">The links need to survive export, handover, and operations. A platform without a data plan can concentrate information that is lost during handover.<\/p>\n\n\n\n\n<h2 class=\"wp-block-heading\">Integration with commissioning<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Commissioning should not begin by writing tests at the end of construction. The <a href=\"https:\/\/www.ashrae.org\/technical-resources\/bookstore\/commissioning\">ASHRAE\/IES Standard 202<\/a> describes an integrated process for delivering facilities that meet the OPR.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Design review<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">The commissioning authority verifies whether the BoD and documents respond to the requirements, identifying gaps in testability, operations, metering, access, and sequence.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Submittals and FAT<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">Manufacturer proposals and drawings are evaluated against specifications and requirements. FATs can verify functions, controls, alarms, and performance before shipment, reducing discoveries on site.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">SAT and functional testing<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">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.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Integrated systems testing<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">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.<\/p>\n\n\n\n<div class=\"wp-block-a3a-destaque\">\n<p class=\"wp-block-paragraph\"><strong>Define verification criteria before procurement, installation, and testing.<\/strong><\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Commissioning connects the OPR, Basis of Design, specifications, FAT, SAT, functional tests, and integrated tests to produce objective evidence of compliance.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><a href=\"\/servicos\/servicos-complementares\/comissionamento-aceite-data-centers\/\"><strong>Learn about Data Center Commissioning and Acceptance<\/strong><\/a><\/p>\n<\/div>\n\n\n\n\n<h2 class=\"wp-block-heading\">Handover to operations<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">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.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Current Facility Requirements<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">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.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Operational baseline<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">The handover should connect:<\/p>\n\n\n\n<ul class=\"wp-block-list\"><li>current requirements;<\/li><li>final BoD;<\/li><li>as-built documentation and diagrams;<\/li><li>asset lists and configurations;<\/li><li>tests and open items;<\/li><li>MOPs, SOPs, and EOPs;<\/li><li>training and competency;<\/li><li>operating limits;<\/li><li>maintenance plan;<\/li><li>alarm and escalation matrix.<\/li><\/ul>\n\n\n\n<p class=\"wp-block-paragraph\">Without this reconciliation, operations receive historical documents that do not represent the actual facility.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Example OPR structure<\/h2>\n\n\n\n<figure class=\"wp-block-table\"><table><tbody><tr><td>Section<\/td><td>Content<\/td><\/tr><tr><td>1. governance<\/td><td>purpose, scope, authorities, approvals, and change control<\/td><\/tr><tr><td>2. context<\/td><td>business, users, services, and operating model<\/td><\/tr><tr><td>3. capacity<\/td><td>ICT, racks, density, growth, and phases<\/td><\/tr><tr><td>4. availability<\/td><td>criticality, maintenance, failures, and recovery<\/td><\/tr><tr><td>5. implementation<\/td><td>site, buildings, expansion, access, and logistics<\/td><\/tr><tr><td>6. infrastructure<\/td><td>power, thermal systems, telecom, automation, and utilities<\/td><\/tr><tr><td>7. security<\/td><td>physical, cyber, fire, and compliance<\/td><\/tr><tr><td>8. operations<\/td><td>staff, procedures, maintenance, parts, and support<\/td><\/tr><tr><td>9. sustainability<\/td><td>energy, water, emissions, metering, and reporting<\/td><\/tr><tr><td>10. quality and testing<\/td><td>reviews, FAT, SAT, IST, and evidence<\/td><\/tr><tr><td>11. documentation<\/td><td>formats, coding, BIM, as-built documentation, and handover<\/td><\/tr><tr><td>12. risks and exceptions<\/td><td>conditions, accepted risks, and pending decisions<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n\n<h2 class=\"wp-block-heading\">Example Basis of Design structure<\/h2>\n\n\n\n<figure class=\"wp-block-table\"><table><tbody><tr><td>Section<\/td><td>Content<\/td><\/tr><tr><td>1. scope and references<\/td><td>boundaries, standards, input documents, and interfaces<\/td><\/tr><tr><td>2. assumptions<\/td><td>data, design conditions, margins, and open items<\/td><\/tr><tr><td>3. general criteria<\/td><td>capacity, availability, safety, and efficiency<\/td><\/tr><tr><td>4. architecture<\/td><td>implementation, blocks, redundancy, and expansion<\/td><\/tr><tr><td>5. disciplines<\/td><td>electrical, mechanical, telecom, automation, and security bases<\/td><\/tr><tr><td>6. operating modes<\/td><td>normal, maintenance, failure, emergency, and return<\/td><\/tr><tr><td>7. calculations and selections<\/td><td>models, factors, derating, and alternatives<\/td><\/tr><tr><td>8. coordination<\/td><td>spaces, routes, loads, interfaces, and responsibilities<\/td><\/tr><tr><td>9. testability<\/td><td>points, loads, procedures, and criteria<\/td><\/tr><tr><td>10. risks and exceptions<\/td><td>limitations, deviations, and residual risk<\/td><\/tr><tr><td>11. changes<\/td><td>decisions, revisions, and impacts<\/td><\/tr><tr><td>12. appendices<\/td><td>diagrams, matrices, tables, and records<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n<h2 class=\"wp-block-heading\">Common mistakes<\/h2>\n\n\n\n<figure class=\"wp-block-table\"><table><tbody><tr><td>Mistake<\/td><td>Consequence<\/td><\/tr><tr><td>copying the OPR from another project<\/td><td>requirements incompatible with business and operations<\/td><\/tr><tr><td>using vague terms<\/td><td>suppliers and designers adopt different interpretations<\/td><\/tr><tr><td>confusing requirement and solution<\/td><td>technology lock-in and limited competition<\/td><\/tr><tr><td>leaving users out of the process<\/td><td>operations receive a facility that is difficult to use and maintain<\/td><\/tr><tr><td>producing the BoD after the drawings<\/td><td>the document becomes a retrospective justification<\/td><\/tr><tr><td>failing to record assumptions<\/td><td>calculations appear precise despite uncertain data<\/td><\/tr><tr><td>failing to define verification methods<\/td><td>requirements cannot be objectively accepted<\/td><\/tr><tr><td>failing to control changes<\/td><td>design, contract, and tests use different versions<\/td><\/tr><tr><td>treating a standard as the OPR<\/td><td>owner-specific objectives are absent<\/td><\/tr><tr><td>disconnecting commissioning<\/td><td>tests are improvised at the end of construction<\/td><\/tr><tr><td>failing to reconcile as-built documentation and the BoD<\/td><td>the operational baseline does not represent the facility<\/td><\/tr><tr><td>creating excessive documents without hierarchy<\/td><td>duplication and conflict increase instead of decrease<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n\n<h2 class=\"wp-block-heading\">Documentation governance checklist<\/h2>\n\n\n\n<ol class=\"wp-block-list\">\n<li>Are the Data Center objective and operating model defined?<\/li>\n\n\n\n<li>Is there formal authority to approve requirements and changes?<\/li>\n\n\n\n<li>Does the OPR distinguish objectives, requirements, and preferences?<\/li>\n\n\n\n<li>Did IT, operations, security, and facilities users participate?<\/li>\n\n\n\n<li>Do requirements have IDs, source, priority, and owner?<\/li>\n\n\n\n<li>Were vague criteria converted into measurable conditions?<\/li>\n\n\n\n<li>Does each requirement have a verification method and phase?<\/li>\n\n\n\n<li>Does the BoD record assumptions and still-pending data?<\/li>\n\n\n\n<li>Do architecture choices have justification linked to requirements?<\/li>\n\n\n\n<li>Are capacities and margins consistent across disciplines?<\/li>\n\n\n\n<li>Are normal, maintenance, failure, and emergency modes described?<\/li>\n\n\n\n<li>Were expansions and temporary states considered?<\/li>\n\n\n\n<li>Does the matrix connect requirements, documents, supplies, and tests?<\/li>\n\n\n\n<li>Does the RFP require compliance and declaration of deviations?<\/li>\n\n\n\n<li>Are submittals reviewed against requirements and the BoD?<\/li>\n\n\n\n<li>Do changes update all affected documents?<\/li>\n\n\n\n<li>Do FAT, SAT, and IST reference verifiable requirements?<\/li>\n\n\n\n<li>Do open items have an owner, due date, and impact on acceptance?<\/li>\n\n\n\n<li>Was the as-built documentation reconciled with the final BoD?<\/li>\n\n\n\n<li>Did operations receive an updated baseline, procedures, and limits?<\/li>\n<\/ol>\n\n\n\n\n<h2 class=\"wp-block-heading\">A3A Engenharia Consulting Engineering scope<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">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.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">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.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">The work can integrate the <a href=\"\/servicos\/planejamento\/estudo-de-viabilidade-de-data-center\/\">Data Center Feasibility Study<\/a>, the <a href=\"\/servicos\/planejamento\/projeto-de-data-center\/\">Data Center Design<\/a>, <a href=\"\/servicos\/contratacao-integrada\/owners-engineering-para-data-centers\/\">Owner\u2019s Engineering for Data Centers<\/a> and <a href=\"\/servicos\/servicos-complementares\/comissionamento-aceite-data-centers\/\">Data Center Commissioning and Acceptance<\/a>.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Technical summary<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">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.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">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.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">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.<\/p>\n\n\n\n<details class=\"wp-block-details is-layout-flow wp-block-details-is-layout-flow\"><summary>Technical references<\/summary>\n<p class=\"wp-block-paragraph\">[1] ASHRAE. ASHRAE Guideline 0-2019 \u2014 The Commissioning Process. Atlanta: ASHRAE, 2019.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">[2] ASHRAE; IES. ANSI\/ASHRAE\/IES Standard 202-2024 \u2014 The Commissioning Process Requirements for New Buildings and New Systems. Atlanta: ASHRAE, 2024.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">[3] INTERNATIONAL ORGANIZATION FOR STANDARDIZATION. ISO\/IEC 22237-1:2021 \u2014 Information technology \u2014 Data centre facilities and infrastructures \u2014 Part 1: General concepts. Geneva: ISO, 2021.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">[4] INTERNATIONAL ORGANIZATION FOR STANDARDIZATION. ISO\/IEC TS 22237-7:2018 \u2014 Information technology \u2014 Data centre facilities and infrastructures \u2014 Part 7: Management and operational information. Geneva: ISO, 2018.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">[5] TELECOMMUNICATIONS INDUSTRY ASSOCIATION. ANSI\/TIA-942-C \u2014 Telecommunications Infrastructure Standard for Data Centers. Arlington: TIA, 2024.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">[6] BICSI. ANSI\/BICSI 002-2024 \u2014 The Standard for Data Center Design. Tampa: BICSI, 2024.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">[7] INTERNATIONAL ORGANIZATION FOR STANDARDIZATION; IEEE. ISO\/IEC\/IEEE 29148:2018 \u2014 Systems and software engineering \u2014 Life cycle processes \u2014 Requirements engineering. Geneva: ISO, 2018.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">[8] UPTIME INSTITUTE. Tier Standard: Topology for Data Center Site Infrastructure. Uptime Institute.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">[9] ASHRAE. Thermal Guidelines for Data Processing Environments. 5. ed. Atlanta: ASHRAE.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">[10] INTERNATIONAL ORGANIZATION FOR STANDARDIZATION. ISO 31000:2018 \u2014 Risk management \u2014 Guidelines. Geneva: ISO, 2018.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">[11] INTERNATIONAL ORGANIZATION FOR STANDARDIZATION. ISO 9001:2015 \u2014 Quality management systems \u2014 Requirements. Geneva: ISO, 2015.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">[12] A3A ENGENHARIA. Data Center Design: study, basic design, and detailed design. Ponta Grossa: A3A Engenharia.<\/p>\n<\/details>\n\n\n\n<details class=\"wp-block-details is-layout-flow wp-block-details-is-layout-flow\"><summary>Frequently asked questions<\/summary>\n<div class=\"schema-faq wp-block-yoast-faq-block\"><div class=\"schema-faq-section\" id=\"faq-question-qual-a-diferen-a-entre-opr-urs-e-basis-of-design-1316d1fc\"><strong class=\"schema-faq-question\">What is the difference between OPR, URS, and Basis of Design?<\/strong> <p class=\"schema-faq-answer\">The OPR records owner objectives and criteria; the URS details users\u2019 functional and operational needs; and the Basis of Design documents how the design team intends to meet those requirements.<\/p><\/div><div class=\"schema-faq-section\" id=\"faq-question-todo-projeto-de-data-center-precisa-de-uma-urs-s-7f3b90ee\"><strong class=\"schema-faq-question\">Does every Data Center project need a separate URS?<\/strong> <p class=\"schema-faq-answer\">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.<\/p><\/div><div class=\"schema-faq-section\" id=\"faq-question-quem-deve-elaborar-o-opr-417a1e66\"><strong class=\"schema-faq-question\">Who should develop the OPR?<\/strong> <p class=\"schema-faq-answer\">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.<\/p><\/div><div class=\"schema-faq-section\" id=\"faq-question-quem-elabora-o-basis-of-design-4cd39170\"><strong class=\"schema-faq-question\">Who develops the Basis of Design?<\/strong> <p class=\"schema-faq-answer\">The design team and responsible engineers develop the BoD, recording the assumptions, criteria, calculations, architectures, and justifications used to meet approved requirements.<\/p><\/div><div class=\"schema-faq-section\" id=\"faq-question-o-opr-faz-parte-do-contrato-43568199\"><strong class=\"schema-faq-question\">Is the OPR part of the contract?<\/strong> <p class=\"schema-faq-answer\">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.<\/p><\/div><div class=\"schema-faq-section\" id=\"faq-question-quando-o-opr-deve-ser-criado-8f1b1daf\"><strong class=\"schema-faq-question\">When should the OPR be created?<\/strong> <p class=\"schema-faq-answer\">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.<\/p><\/div><div class=\"schema-faq-section\" id=\"faq-question-como-saber-se-um-requisito-verific-vel-853ba592\"><strong class=\"schema-faq-question\">How can you tell whether a requirement is verifiable?<\/strong> <p class=\"schema-faq-answer\">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.<\/p><\/div><div class=\"schema-faq-section\" id=\"faq-question-o-basis-of-design-substitui-os-memoriais-e-desen-ad5c7837\"><strong class=\"schema-faq-question\">Does the Basis of Design replace technical specifications and drawings?<\/strong> <p class=\"schema-faq-answer\">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.<\/p><\/div><div class=\"schema-faq-section\" id=\"faq-question-como-opr-e-bod-se-relacionam-com-o-comissionamen-344e2541\"><strong class=\"schema-faq-question\">How do the OPR and BoD relate to commissioning?<\/strong> <p class=\"schema-faq-answer\">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.<\/p><\/div><div class=\"schema-faq-section\" id=\"faq-question-o-que-uma-matriz-de-rastreabilidade-63a4b7b5\"><strong class=\"schema-faq-question\">What is a traceability matrix?<\/strong> <p class=\"schema-faq-answer\">It is the mechanism that relates each requirement to its origin, BoD response, design documents, supplies, verification methods, evidence, and status.<\/p><\/div><\/div>\n<\/details>\n\n\n\n<details class=\"wp-block-details is-layout-flow wp-block-details-is-layout-flow\"><summary>Additional technical resources<\/summary>\n<h3 class=\"wp-block-heading\">Fundamentals and planning<\/h3>\n\n\n\n<ul class=\"wp-block-list\"><li><a href=\"\/conteudo\/artigos-tecnicos\/data-center-o-que-e-como-funciona-infraestrutura\/\">Data Center: what it is, how it works, and which systems make up the infrastructure<\/a><\/li><li><a href=\"\/conteudo\/artigos-tecnicos\/estudo-viabilidade-data-center\/\">Data Center feasibility study: power, connectivity, site, and risks<\/a><\/li><li><a href=\"\/conteudo\/artigos-tecnicos\/como-escolher-localizacao-data-center\/\">How to choose a Data Center location<\/a><\/li><\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Requirements, architecture, and design<\/h3>\n\n\n\n<ul class=\"wp-block-list\"><li><a href=\"\/conteudo\/artigos-tecnicos\/como-projetar-data-center\/\">How to design a Data Center: stages, disciplines, and deliverables<\/a><\/li><li><a href=\"\/servicos\/planejamento\/projeto-de-data-center\/\">Data Center Design<\/a><\/li><li><a href=\"\/conteudo\/artigos-tecnicos\/data-center-tier-3\/\">Tier I, II, III, and IV in Data Centers<\/a><\/li><li><a href=\"\/conteudo\/artigos-tecnicos\/data-center-modular\/\">Modular Data Center: design, risks, and when to use it<\/a><\/li><\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Governance, contracting, and change control<\/h3>\n\n\n\n<ul class=\"wp-block-list\"><li><a href=\"\/servicos\/contratacao-integrada\/owners-engineering-para-data-centers\/\">Owner\u2019s Engineering for Data Centers<\/a><\/li><li><a href=\"\/solucoes\/gestao-e-governanca-de-engenharia\/engenharia-integrada-para-data-centers\/\">Integrated Engineering for Data Centers<\/a><\/li><li><a href=\"\/conteudo\/artigos-tecnicos\/stage-gate-projetos-engenharia\/\">Stage-gate in engineering projects<\/a><\/li><li><a href=\"\/conteudo\/artigos-tecnicos\/gestao-riscos-projetos-engenharia\/\">Risk management in engineering projects<\/a><\/li><\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Commissioning, verification, and acceptance<\/h3>\n\n\n\n<ul class=\"wp-block-list\"><li><a href=\"\/servicos\/servicos-complementares\/comissionamento-aceite-data-centers\/\">Data Center Commissioning and Acceptance<\/a><\/li><li><a href=\"\/conteudo\/artigos-tecnicos\/comissionamento-sistemas-criticos-prontos-para-operar\/\">Commissioning of critical systems<\/a><\/li><li><a href=\"\/conteudo\/artigos-tecnicos\/sla-o-que-e-como-definir-calcular\/\">SLA: how to define and calculate service level<\/a><\/li><\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Specialized disciplines and systems<\/h3>\n\n\n\n<ul class=\"wp-block-list\"><li><a href=\"\/solucoes\/engenharia-de-redes-e-telecomunicacoes\/redes-telecomunicacoes-para-data-centers\/\">Networks and Telecommunications for Data Centers<\/a><\/li><li><a href=\"\/solucoes\/engenharia-de-sistemas-hvac\/climatizacao-de-data-centers\/\">Data Center Cooling<\/a><\/li><li><a href=\"\/solucoes\/gestao-de-ti\/data-center-infrastructure-management-dcim\/\">DCIM for Data Centers<\/a><\/li><li><a href=\"\/solucoes\/engenharia-de-sistemas-de-seguranca-eletronica\/seguranca-fisica-para-data-centers\/\">Physical Security for Data Centers<\/a><\/li><li><a href=\"\/solucoes\/engenharia-de-seguranca-contra-incendio-e-panico\/incendio-em-data-centers\/\">Fire Detection and Suppression in Data Centers<\/a><\/li><\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Deployment models and scales<\/h3>\n\n\n\n<ul class=\"wp-block-list\"><li><a href=\"\/conteudo\/artigos-tecnicos\/hyperscale-data-center-o-que-e\/\">Hyperscale Data Center: what it is and how it works<\/a><\/li><li><a href=\"\/conteudo\/artigos-tecnicos\/como-avaliar-provedor-colocation\/\">Colocation Data Center: how to evaluate a provider<\/a><\/li><li><a href=\"\/conteudo\/artigos-tecnicos\/edge-data-center-o-que-e\/\">Edge Data Center: applications and architecture<\/a><\/li><li><a href=\"\/conteudo\/artigos-tecnicos\/micro-data-center\/\">Micro Data Center: applications and specification criteria<\/a><\/li><\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Standards and official sources<\/h3>\n\n\n\n<ul class=\"wp-block-list\"><li><a href=\"https:\/\/www.ashrae.org\/technical-resources\/bookstore\/commissioning\">ASHRAE \u2014 commissioning, OPR, and Basis of Design<\/a><\/li><li><a href=\"https:\/\/www.iso.org\/standard\/78550.html\">ISO\/IEC 22237-1 \u2014 general concepts for Data Centers<\/a><\/li><li><a href=\"https:\/\/www.iso.org\/standard\/73014.html\">ISO\/IEC TS 22237-7 \u2014 management and operations<\/a><\/li><li><a href=\"https:\/\/tiaonline.org\/resource\/tia-942-c-data-center-infrastructure-standard\/\">TIA-942-C \u2014 Data Center infrastructure<\/a><\/li><\/ul>\n<\/details>\n","protected":false},"excerpt":{"rendered":"<p>Understand OPR, URS and Basis of Design in Data Center projects: ownership, user requirements, design response, traceability, commissioning and document governance.<\/p>\n","protected":false},"author":1,"featured_media":78775,"parent":0,"template":"","meta":{"_a3a_global_related_solutions":[],"_a3a_global_related_services":[],"_a3a_global_related_materials":[],"_a3a_post_lang":"en-us","_a3a_translation_group_id":"741250b7-11c7-4550-af09-dabdff453507","_a3a_i18n_canonical_slug":"basis-of-design-opr-urs-data-center-projects","_a3a_prod_post_id":"","_a3a_lang_url_en-us":"","_a3a_lang_url_es-es":""},"categories":[],"segments":[],"mercados":[],"etapas":[],"class_list":["post-81789","articles","type-articles","status-publish","has-post-thumbnail","hentry"],"_links":{"self":[{"href":"https:\/\/a3aengenharia.com\/en-us\/wp-json\/wp\/v2\/articles\/81789","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/a3aengenharia.com\/en-us\/wp-json\/wp\/v2\/articles"}],"about":[{"href":"https:\/\/a3aengenharia.com\/en-us\/wp-json\/wp\/v2\/types\/articles"}],"author":[{"embeddable":true,"href":"https:\/\/a3aengenharia.com\/en-us\/wp-json\/wp\/v2\/users\/1"}],"version-history":[{"count":1,"href":"https:\/\/a3aengenharia.com\/en-us\/wp-json\/wp\/v2\/articles\/81789\/revisions"}],"predecessor-version":[{"id":81795,"href":"https:\/\/a3aengenharia.com\/en-us\/wp-json\/wp\/v2\/articles\/81789\/revisions\/81795"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/a3aengenharia.com\/en-us\/wp-json\/wp\/v2\/media\/78775"}],"wp:attachment":[{"href":"https:\/\/a3aengenharia.com\/en-us\/wp-json\/wp\/v2\/media?parent=81789"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/a3aengenharia.com\/en-us\/wp-json\/wp\/v2\/categories?post=81789"},{"taxonomy":"segments","embeddable":true,"href":"https:\/\/a3aengenharia.com\/en-us\/wp-json\/wp\/v2\/segments?post=81789"},{"taxonomy":"mercados","embeddable":true,"href":"https:\/\/a3aengenharia.com\/en-us\/wp-json\/wp\/v2\/mercados?post=81789"},{"taxonomy":"etapas","embeddable":true,"href":"https:\/\/a3aengenharia.com\/en-us\/wp-json\/wp\/v2\/etapas?post=81789"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}