Engineering Needs Program: How to Transform Demands into Design Requirements

Understand how to develop an Engineering Needs Program and transform user expectations into requirements, performance criteria, interfaces, and a basis for design development.

Check it out!

The Engineering Needs Program is the document or structured set of information that transforms user, operational, and organizational needs into requirements that will guide design development. It establishes what the solution must enable, meet, support, and demonstrate before designers define architecture, systems, equipment, dimensions, and other technical solutions.

In architectural projects, the Needs Program is traditionally associated with the list of spaces, users, activities, dimensions, occupancy, flows, furniture, equipment, and special requirements. In multidisciplinary Engineering projects, the concept needs to be expanded: it may also consolidate electrical capacities, HVAC requirements, connectivity, security, availability, redundancy, automation, maintenance, expansion, system integration, operating conditions, and performance criteria.

The Needs Program is not the design, nor should it be a list of solutions selected in advance. Its role is to provide a validated basis for design development. An organization may know that it needs “greater security,” “more capacity,” “a new technical room,” or “building modernization,” but these expressions are still generic. The Needs Program converts expectations into verifiable parameters: how many users will be served, which activities will occur, what performance is required, which constraints exist, which systems must integrate, and which conditions must be preserved.

This stage is especially valuable when there are many stakeholders, existing facilities, future expansion, or multiple disciplines. Without consolidated requirements, each designer tends to work from their own assumptions, and divergences that should have been resolved at the beginning appear later as design revisions, incompatibilities, scope changes, or construction rework.

What should an Engineering Needs Program contain

The composition varies according to the scope, but the document must gather enough information for the design team to understand how the facility is expected to function and to transform needs into Engineering decisions.

Technical documents from Brazilian public agencies treat the Needs Program as a preliminary definition stage based on user expectations and the activities that will take place in the spaces. Institutional references include aspects such as sectors, functional relationships, quantities, dimensions, occupancy, capacity, flows, equipment, and legal or standards-related requirements.

In a multidisciplinary approach, these elements can be organized into groups:

Group	Questions the Needs Program should answer
Users and activities	Who uses the facility? For what purpose? At what times and under what conditions?
Capacity	How many people, devices, loads, connections, vehicles, events, or processes must be supported?
Performance	What levels of availability, comfort, safety, quality, continuity, or response are expected?
Spaces	Which rooms, technical areas, accesses, circulation paths, and reserves are required?
Systems	Which disciplines and systems must exist or be modified?
Interfaces	Which systems depend on one another and which integrations are mandatory?
Constraints	What cannot be interrupted, removed, changed, or exceeded?
Expansion	What growth must be accommodated and what horizon should guide sizing?
Standards and policies	Which legal, regulatory, corporate, or sector requirements are already known?
Acceptance	How will it be demonstrated that the designed result meets the need?

The document does not need to determine the solution for each line in advance. Its function is to establish the conditions that the solution must satisfy.

Needs Program, briefing, DFD, ETP, and design: what is the difference

These documents may coexist, but they have different responsibilities.

A briefing is usually an initial collection of expectations and information provided by the client. It may be more open and exploratory. The Needs Program transforms this input into a more structured, consolidated, and verifiable basis for design.

In the public sector, the Demand Formalization Document for engineering works and services records the procurement need and feeds planning. It does not replace the development of technical requirements. When the demand is still generic, the Needs Program may be a necessary Engineering stage to mature it.

The Preliminary Technical Study for engineering works and services evaluates the need and alternatives to support selection of the most appropriate solution when applicable. The Needs Program provides requirements that can feed this analysis and, later, the design.

The design, in turn, transforms approved requirements into a technical solution: concept, calculations and sizing, drawings, design narratives, specifications, quantities, and other deliverables compatible with the applicable stage.

Document	Main responsibility
Briefing	Capture expectations and initial information
DFD	Formalize the procurement need
Needs Program	Consolidate needs and design requirements
ETP	Analyze alternatives and substantiate the solution
Conceptual Design / Preliminary Design	Conceive and organize the selected solution
Basic Design	Technically define the scope at a level suitable for procurement
Detailed Design	Detail the solution for execution

This separation prevents the designer from receiving only a one-line scope statement and being forced to discover, during development, what the client actually needed.

How to identify user needs without turning the design into a wish list

A Needs Program should not simply compile everything each stakeholder requests. User areas see the problem from the perspective of their own responsibilities and may propose solutions that are conflicting, redundant, or incompatible with budget, standards, and existing infrastructure.

The Engineering task is to capture the intent behind the request. If a user asks for “two PTZ cameras,” the actual need may be to monitor large outdoor areas and respond to events. If they ask for “a larger UPS,” they may be trying to solve insufficient autonomy or availability. If they request “more air conditioning,” the problem may be increased heat load, poor air distribution, control failure, or lack of redundancy.

Therefore, interviews and workshops should separate four levels:

1. observed problem;
2. affected activity or process;
3. required outcome;
4. solution suggested by the user.

The first three are fundamental inputs. The fourth is a hypothesis to be analyzed, not an automatically approved requirement.

Which sources should feed the Needs Program

The quality of the document depends on the diversity and reliability of its inputs. In addition to user interviews, the team should review available technical and operational information.

Common sources include:

• strategic planning and institutional objectives;
• occupancy and growth data;
• inventory of existing assets and systems;
• previous designs, As Built documentation, and design narratives;
• maintenance and failure reports;
• load, capacity, or performance measurements;
• applicable legal and standards requirements;
• security, IT, operations, and continuity policies;
• existing contracts and their interfaces;
• expansion plans;
• sustainability or efficiency requirements;
• corporate standards and lessons learned.

In existing facilities, this documentary base must be checked against field conditions. A drawing may show an electrical panel that has already been modified; a floor plan may not reflect current partitions; an equipment register may be incomplete. In such cases, the Engineering Existing-Conditions Survey and the Site Survey become inputs to the process.

Needs Program in existing facilities and brownfield projects

In brownfield projects, requirements cannot be defined only from the desired future state. It is necessary to understand what already exists, what will remain in operation, which physical constraints must be respected, and how implementation will be phased.

An occupied building, for example, may not allow a total power shutdown. A server room may need to remain available during modernization. A renovation may proceed floor by floor. A legacy access-control system may need to coexist temporarily with the new one. These factors profoundly affect the design and must be included in the Needs Program.

The content on Brownfield Projects shows why surveys, As Built documentation, and intervention strategy are critical parts of Engineering in existing facilities.

When the overall condition of the assets is uncertain, an Engineering Technical Due Diligence may precede or complement the Needs Program, bringing risks, condition, compliance, and priorities into requirements definition.

How to transform needs into Engineering requirements

The main intellectual deliverable of the process is transforming a qualitative need into a requirement that can guide design and later be verified.

Consider a few examples:

Need	Possible Engineering requirement
“We cannot lose operations during a power outage.”	Critical loads must have autonomy and an emergency-power strategy defined according to criticality and required recovery time.
“We need to increase the number of users.”	The solution must support current capacity, projected growth, and the expansion margin established for the project horizon.
“The room is too hot.”	The design must consider current and future thermal loads, equipment environmental limits, and the redundancy conditions defined for the room.
“We need to improve security.”	Areas, threats, protection levels, and events requiring detection, identification, control, or recording must be defined and associated with performance criteria.
“Maintenance needs to be easier.”	Equipment must have access for inspection and maintenance, traceable documentation, identification, and a replacement strategy compatible with operations.

Wording should favor outcomes and performance instead of a brand or specific solution, except where there is a legitimate technical justification for standardization or compatibility.

A good requirement has a known origin, unambiguous meaning, and a means of verification. Terms such as “adequate,” “modern,” “robust,” “high quality,” or “sufficient” are not verifiable without additional criteria.

Functional, performance, interface, and constraint requirements

Not all requirements have the same nature. Classifying them helps prevent gaps.

Functional requirements

They define what the facility or system must do. An access-control system, for example, may need to authenticate users, record events, enforce access policies, and integrate with video surveillance.

Performance requirements

They define the expected level of operation: capacity, availability, latency, autonomy, accuracy, temperature, flow rate, illuminance, retention, or another measurable parameter.

Interface requirements

They define relationships between systems, disciplines, areas, or contracts. They are essential in multidisciplinary projects because many failures arise not within a system, but at the boundary between two systems.

Constraints

They establish conditions that limit alternatives: available space, operational continuity, shutdown window, budget, existing assets, licensing, standards, or systems that must be retained.

Operations, maintenance, and life-cycle requirements

They define conditions that would otherwise appear only after handover: maintenance access, spare parts, training, documentation, software updates, monitoring, efficiency, consumption, and service life.

This taxonomy helps the designer see the scope as an integrated system rather than a set of discipline-specific drawings.

How to handle multiple stakeholders and requirement conflicts

More complex projects involve areas with different objectives. IT may prioritize availability; maintenance, simplicity and standardization; security, control and traceability; users, comfort and flexibility; finance, investment; facilities, preservation; and management, schedule and continuity.

These needs may conflict. More redundancy can increase CAPEX and technical-area requirements. Greater security may reduce convenience. Greater flexibility may require spare capacity. Standardization may restrict alternatives.

The Needs Program needs to record and resolve these conflicts before detailed design. Techniques such as decision matrices, multicriteria analysis, and validation workshops help make trade-offs explicit. Multicriteria Analysis in Engineering projects is useful when alternatives need to be compared against multiple criteria.

The approved decision must be traceable: who requested it, why the requirement exists, what priority it has, and which assumption was adopted.

How to create a traceable requirements matrix

An isolated requirements list loses value when its origin and where it will be addressed in the design are unknown. Traceability can be created through a matrix that follows the requirement throughout the life cycle.

ID	Origin	Requirement	Criterion	Design deliverable	Verification
R-001	Operations	Maintain service during utility-power failure	Defined autonomy for critical load	Emergency-power diagram, narrative, and specification	Calculation + functional test
R-002	Security	Record access to restricted area	All events associated with user and time	Access-control architecture and specification	FAT/SAT or acceptance test
R-003	IT	Allow network growth	Defined minimum spare capacity for ports, uplinks, and rack	Network and cabling design	Design review + inspection

Requirements, Evidence, and Acceptance Criteria Management extends this logic to connect requirements, deliverables, verifications, evidence, deviations, and technical acceptance.

How the Needs Program guides a multidisciplinary design

In a multidisciplinary project, the Needs Program provides a common basis for disciplines that might otherwise adopt different assumptions.

Consider a new Operations Center. Architecture needs to know the number of operators, ergonomics, circulation, and technical spaces. Electrical needs loads, availability, and autonomy. HVAC needs occupancy, thermal loads, and environmental limits. Telecom needs network capacity and connectivity. Electronic security needs zones, protection levels, and integrations. Automation needs to know which variables will be monitored and controlled.

These disciplines cannot be defined independently. The capacity of a technical room affects area, power, and cooling. A rack changes the thermal load. A set of cameras changes network and storage requirements. A UPS system affects electrical systems, ventilation, weight, and maintenance.

The Needs Program creates the common starting point. Design Coordination and Integration acts later to coordinate the developed solutions, while BIM Designs can integrate geometry, information, and multidisciplinary coordination where applicable.

Needs Program and Conceptual Design

After requirements, constraints, and performance criteria have been consolidated, the Engineering Conceptual Design can develop and compare solution architectures.

This sequence matters. If concept development occurs before requirements are clear, the team tends to defend the first solution drawn and then adjusts the needs to fit it. When the Needs Program comes first, alternatives can be evaluated against previously agreed criteria.

The article on Conceptual Design in Engineering develops this phase further, in which architecture, capacity, technology, interfaces, and assumptions must be structured before detailing.

How the Needs Program feeds the ETP in the public sector

Law No. 14,133/2021 establishes that the preparatory phase is characterized by planning and must address technical, market, and management considerations. SEGES Normative Instruction No. 58/2022 defines the ETP as the first stage in planning a specific procurement, characterizing the public interest and the best solution.

The Needs Program is not a universally mandatory document under Law No. 14,133 and should not be presented as a substitute for the ETP. Its function is different: when the scope depends on a structured definition of users, capacities, flows, performance, and interfaces, it can provide qualified technical input for the analysis of alternatives.

For example, before comparing alternatives for modernizing a building, the ETP needs to know how many people will be served, which systems are critical, which areas must remain operational, what growth horizon will be considered, and which performance requirements apply. Without this, alternatives are compared against a poorly defined need.

Likewise, the new article on the Annual Procurement Plan in Engineering shows how immature demands can be scheduled to receive Engineering work before contracting execution.

Needs Program, Preliminary Design, and Basic Design

The next level depends on the delivery model, scope, and adopted strategy. The Engineering Preliminary Design develops requirements, parameters, and the solution at a level compatible with its purpose. The Engineering Basic Design deepens the technical definition to characterize the work or service when this document applies.

The Needs Program must remain traceable through these stages. If requirement R-017 established minimum availability for a given system, the design must show how that availability will be achieved. If requirement R-023 requires future expansion, drawings and calculations must reserve the corresponding capacity.

This control prevents a common failure: the Needs Program is approved at the beginning but stops being consulted as the design progresses. Requirements disappear, are reinterpreted, or are sacrificed without a formal decision.

How to validate and approve the Needs Program

Validation should involve the stakeholders responsible for the needs and the technical team capable of assessing consistency, feasibility, and interfaces. Purely administrative approval does not replace technical review.

The process can follow this sequence:

1. consolidate sources and stakeholders;
2. record needs and assumptions;
3. convert needs into requirements;
4. classify requirements by discipline and type;
5. identify conflicts and gaps;
6. conduct validation workshops;
7. record decisions and outstanding items;
8. issue a controlled version;
9. approve the requirements baseline;
10. establish a process for future changes.

The baseline does not mean that no requirement can ever change. It means that any subsequent change will have an identifiable impact on scope, design, schedule, cost, and interfaces.

Frequent mistakes in Needs Programs

Turning the document into a room list

In complex buildings, rooms are only one part of the need. Systems, capacities, performance, interfaces, operations, and maintenance must also be addressed.

Copying the program from a previous project

Similar projects may have different users, loads, risks, and growth. A document reused without validation merely transfers assumptions from another context.

Writing requirements that cannot be verified

“High availability,” “modern technology,” and “excellent quality” need to be translated into objective criteria or verifiable technical references.

Prescribing solutions before understanding the problem

When the program is created with brands, models, and fixed architectures already defined, it stops functioning as a requirements basis and becomes an early specification.

Ignoring interfaces between disciplines

A security requirement may affect network, electrical, architecture, and software. Without an interface map, the design distributes responsibilities ambiguously.

Failing to consider expansion and life cycle

The design meets the needs on handover day but quickly loses capacity or becomes difficult to maintain because the future horizon was never defined.

Approving without involving users and technical owners

Unvalidated requirements reappear as changes during design or construction.

What to require when contracting preparation of a Needs Program

When the Needs Program is prepared with external support, the scope must define the method and deliverables. It is not enough to contract “meetings and a report.”

A robust technical scope may include:

• information-gathering plan;
• stakeholder identification and matrix;
• structured interviews and workshops;
• document analysis;
• site inspection or field survey when necessary;
• characterization of users, processes, and operations;
• inventory of needs by discipline;
• functional and performance requirements matrix;
• interface requirements;
• assumptions and constraints;
• current and future capacities;
• applicable standards and institutional criteria;
• traceability matrix;
• record of conflicts and decisions;
• preliminary version for comments;
• validation workshop;
• approved final baseline.

Acceptance should assess consistency and traceability. A lengthy document may still be weak if it is impossible to relate a requirement to its origin, decision, and consequence for the design.

When to contract specialized support

Internal preparation is entirely possible when the organization has the technical team, data, and availability to coordinate stakeholders. Specialized support becomes valuable when the project is multidisciplinary, has many interfaces, involves existing facilities, requires standardization across multiple sites, or when needs must be converted into a sequence of designs and investments.

Consulting Engineering operates precisely at the boundary between the client’s problem and the Engineering products that will solve it. The Engineering Needs Program and Requirements service materializes this work through requirements gathering, consolidation, validation, and traceability.

The expected result is not a bureaucratic document. It is a basis that reduces ambiguity, improves decision quality, and allows designers to work from approved requirements rather than scattered assumptions.

Final considerations

The Needs Program occupies a critical stage between recognizing a demand and developing the solution. It organizes what users, operations, maintenance, management, and technical disciplines expect from the project and transforms those expectations into requirements capable of guiding design and acceptance.

The more complex the scope, the higher the cost of skipping this stage. Without consolidated requirements, decisions are made using different assumptions, interfaces emerge late, and changes accumulate as stakeholders finally see what is being designed.

A well-structured Needs Program does not eliminate the need for an ETP, Conceptual Design, Preliminary Design, Basic Design, or Detailed Design. On the contrary: it improves the quality of these stages by establishing a common reference for comparing alternatives, developing the solution, and later verifying whether what was delivered corresponds to the problem that needed to be solved.

Technical references

[1] CONSELHO NACIONAL DE ARQUIVOS — CONARQ. Recommendations for construction and adaptation of archives. Technical document with guidelines for defining the Needs Program, sectors, activities, occupancy, capacity, flows, equipment, and special requirements. Available at: https://www.gov.br/conarq/pt-br/composicao/copy_of_camaras-tecnicas-setoriais-inativas/CTC_AU_Minuta_pos_consulta_publica_03.12.2023.pdf

[2] BRASIL. Ministry of Health. Cold Chain of the National Immunization Program: guide for designs and infrastructure. Institutional reference that treats the Needs Program as a set of information and conditions required for development of activities and designs. Available at: https://www.gov.br/saude/pt-br/centrais-de-conteudo/publicacoes/guias-e-manuais/2025/rede-de-frio-pni.pdf/@@download/file

[3] BRASIL. Law No. 14,133, April 1, 2021. Public Procurement and Administrative Contracts Law. Available at: https://www.planalto.gov.br/ccivil_03/_ato2019-2022/2021/lei/l14133.htm

Frequently asked questions

What is an Engineering Needs Program?

It is the structured basis that consolidates user, operational, and organizational needs and transforms them into requirements to guide design development, including capacities, performance, spaces, systems, interfaces, constraints, and acceptance conditions.

Is a Needs Program the same as a briefing?

Not exactly. A briefing is normally an initial collection of expectations and information. The Needs Program organizes, analyzes, and validates those inputs, converting them into a more structured technical basis for design.

Does the Needs Program replace the ETP?

No. The Needs Program structures requirements. The ETP, when applicable, analyzes the need and alternatives to substantiate the solution. The Program can provide technical inputs to the ETP, but it does not replace its legal and administrative functions.

Should the Needs Program specify brands and models?

As a rule, its function is to define needs, performance, and constraints, not to prescribe brands in advance. Specific solutions may appear when there is legitimate technical justification, such as compatibility, standardization, or another duly substantiated condition.

Who should participate in preparing the Needs Program?

Stakeholders who understand users, operations, maintenance, management, and institutional requirements should participate, together with the Engineering team capable of transforming those needs into consistent and coordinated technical parameters.

When is it worthwhile to commission a Needs Program?

It is especially useful in multidisciplinary projects, renovations and modernizations, projects with many users, multiple sites, existing facilities, expansion requirements, or when the scope is not yet sufficiently defined to begin design.

Additional technical materials

Related solutions

• Requirements, Evidence, and Acceptance Criteria Management
• Project, Program, and Portfolio Governance
• Contracts, Scope, and Deliverables Management
• Processes, Workflows, and Technical Approvals Management

Related services

• Engineering Needs Program and Requirements
• Engineering Site Survey
• Engineering Existing-Conditions Survey
• Engineering Technical Due Diligence
• Engineering Conceptual Design
• Engineering Preliminary Design
• Engineering Basic Design
• BIM Designs
• Design Coordination and Integration

Main content on this topic

• DFD for Engineering Works and Services
• Annual Procurement Plan in Engineering
• Engineering Designs: types, stages, disciplines, documents, and deliverables
• Conceptual Design in Engineering: what it is, stages, and deliverables
• Preliminary Technical Study for Engineering Works and Services

Related technical content

• Brownfield Projects: engineering in existing facilities
• Project Readiness in Engineering
• PDRI — Project Definition Rating Index in Engineering
• Multicriteria Analysis in Engineering Projects
• Complete Guide to Consulting Engineering
• Owner’s Engineering: Executive Framework for Procurement, Governance, and Acceptance