Understand how to structure a DFD for engineering works and services, distinguish need from solution, and prepare the demand for ETP, design, and procurement.
Check it out!
The Demand Formalization Document (DFD) is the record that evidences and details a procurement need and, within the federal framework governed by Decree No. 10,947/2022, supports preparation of the Annual Procurement Plan (PCA). For engineering works and services, however, its value is not limited to initiating an administrative workflow: it should allow the organization to clearly recognize which problem needs to be solved, which institutional result is intended, which dependencies are already known, and what level of technical development will be required before procurement.
A DFD does not replace a Preliminary Technical Study, Terms of Reference, preliminary design, Basic Design, or Detailed Design. Nor should it anticipate a solution before the need is sufficiently understood. Its function is to record the demand at a level compatible with the planning stage, allowing the requesting, technical, and procurement areas to decide how that need should mature.
For simple demands, the description may be relatively direct. In Engineering, the situation is usually different. Expressions such as “renovate the electrical installation,” “modernize CCTV,” “upgrade the building,” “replace the HVAC system,” or “expand the network” describe an intention, but normally do not yet define a technically procurable scope. Before reaching the tender stage, it may be necessary to survey existing conditions, consolidate requirements, compare alternatives, size systems, estimate costs, define interfaces, and produce designs.
Therefore, a good Engineering DFD should be understood as the starting point of a technical maturity chain. The better the need is formalized, the easier it becomes to decide whether the next stage requires a Site Survey, existing-conditions survey, diagnosis, Needs Program, ETP, feasibility study, preliminary design, Basic Design, or another Engineering deliverable.
What the DFD should contain in an Engineering demand
Under Decree No. 10,947/2022, the DFD used for the PCA contains, among other elements, justification of the need, a concise description of the scope, quantity when applicable, preliminary value estimate, intended date for completion of the procurement, priority level, dependencies on other demands, and identification of the responsible area.
For Engineering, these fields need to be completed carefully because each one influences subsequent development. The “concise description of the scope,” for example, should not be confused with a final specification. When uncertainty about the solution still exists, it is technically safer to record the need and intended outcome than to prematurely lock in equipment, technology, architecture, or quantities.
A demand such as “purchase 120 cameras” may conceal unanswered questions: has current coverage been analyzed? Have risks been mapped? Can the network and power infrastructure support the expansion? Is there a minimum recording-retention requirement? Does the VMS have sufficient capacity? Are there areas requiring analytics, low-light performance, or identification requirements? Does the number 120 come from a design or only from an initial estimate?
The DFD can record the problem and the modernization need without pretending to a level of precision that Engineering has not yet produced. This distinction reduces the risk of turning an initial hypothesis into a contractual requirement.
Need, intended outcome, and scope are not the same thing
A practical way to separate these concepts is to observe three levels:
| Level | Question | Example |
| Need | Which institutional problem needs to be solved? | There are areas without adequate security coverage, and the current system has capacity limitations and obsolescence. |
| Intended outcome | What should improve at the end? | Increase coverage, availability, investigation capability, and integration of the security system. |
| Scope | What will actually be procured? | It may still be a survey, design, system modernization, implementation, or a combination of stages after technical maturation. |
This separation helps prevent the Administration from attempting to contract execution before technically knowing what needs to be executed.
DFD, ETP, Terms of Reference, and Basic Design: what is the difference
The DFD formalizes the demand. The Preliminary Technical Study for engineering works and services deepens the need, examines alternatives, and substantiates the solution that best serves the public interest. The Terms of Reference in Engineering structures the scope, requirements, execution, measurement, and acceptance when it is the appropriate instrument. The Engineering Basic Design provides sufficient technical definition to characterize the engineering work or service when this level of development is required.
Law No. 14,133/2021 treats the preparatory phase as a planning stage and requires technical, market, and management issues to be considered. Article 18 connects the description of the need to the ETP and provides that the scope be defined, as applicable, through Terms of Reference, preliminary design, Basic Design, or Detailed Design.
This means there is a progression of maturity. The most common error is to compress all these stages into a single initial description and demand from the DFD a level of definition it does not yet have — or, at the opposite extreme, to treat it as a bureaucratic form without enough information to guide planning.
When the technical area should participate in demand formalization
Decree No. 10,947/2022 distinguishes the requesting area from the technical area and allows the DFD to be forwarded to the technical area for analysis, supplementation, consolidation of demands, and standardization. In Engineering, this participation is especially relevant when the demand depends on existing physical conditions, system integration, technical standards, installed capacity, asset service life, operational risks, or definition of design disciplines.
The requesting area may understand the operational problem very well, but not necessarily its technical causes or solution alternatives. Engineering’s role is to translate the need into verifiable questions without prematurely eliminating options that still need to be studied.
For example, a demand to “replace the generator” may result from insufficient power, recurring failures, low reliability, inadequacy of the transfer system, fuel problems, lack of redundancy, or changes in the critical-load profile. Each cause leads to a different technical path. Initial formalization should preserve this diagnostic possibility.
When the installed condition is not yet sufficiently known, an Engineering Site Survey or an Existing-Conditions Survey of buildings and facilities may be necessary before advancing to specifications and designs.
How to describe a need without prematurely specifying the solution
Demand formulation should be concrete enough to justify planning and open enough to allow technical analysis. A good description normally combines context, problem, consequence, and expected outcome.
Consider the difference between two formulations:
Premature formulation: “Purchase model X 48-port switches to replace the network.”
Need-oriented formulation: “The network infrastructure has port saturation, unsupported equipment, lack of redundancy at critical points, and expansion limitations. It is necessary to assess the current architecture and structure a solution that ensures capacity, availability, security, and growth.”
The second wording does not prevent switches from being purchased later. It simply prevents the organization from turning an unproven conclusion into the starting point.
The same reasoning applies to construction, electrical systems, HVAC, telecommunications, electronic security, Data Centers, SPDA, and other systems. When the solution depends on study, the DFD should make clear that there is an Engineering need to be technically developed.
Which technical information improves an Engineering DFD
There is no single list for every scope, but some groups of information substantially improve planning quality:
- location and affected sites;
- description of the current condition and observed problems;
- operational, institutional, safety, or continuity impact;
- users, areas, and processes dependent on the infrastructure;
- existing documents such as designs, As Built documentation, reports, and technical assessments;
- schedule, operations, access, and shutdown constraints;
- interfaces with other systems or contracts;
- legal, standards, or corporate requirements already known;
- dependencies on other works, purchases, or designs;
- expansion horizon or capacity change;
- likely need for survey, diagnosis, study, or design before execution.
This information does not turn the DFD into a Basic Design. It makes it possible to decide which Engineering work needs to be produced next.
From administrative demand to the Needs Program
When the need exists but users, capacities, interfaces, constraints, and verifiable criteria are still missing, specifying execution directly creates the risk of contracting a solution before defining the problem.
The Needs Program organizes these inputs and creates a traceable basis for studies and designs.
When the organization understands the need but still has to consolidate users, performance, capacities, interfaces, constraints, and design criteria, an intermediate step may be an Engineering Needs Program and Requirements.
This deliverable is especially useful in multidisciplinary or modernization projects in which several internal areas participate in definition. Instead of each stakeholder supplying an isolated wish list, needs are consolidated, verified, and transformed into traceable requirements for subsequent phases.
Imagine modernization of an administrative building. IT may request new racks and connectivity; security requests CCTV and access control; maintenance identifies obsolete electrical panels; users request space adaptations; management wants to reduce downtime; and leadership needs to estimate investment and phasing. The problem is not merely “renovate the building.” It is to coordinate needs that compete for space, power, budget, schedule, and priority.
The DFD records the demand. The Needs Program helps transform that demand into a common technical basis for studies and designs.
When the DFD should indicate surveys or diagnosis before design
In existing facilities, available documentation does not always represent actual conditions. When there is uncertainty about assets, interferences, capacity, or infrastructure, that uncertainty needs to be reduced before design.
Field surveys transform assumptions into technical evidence.
Designing from incomplete information is one of the most recurring sources of rework, amendments, and changes in existing facilities. In brownfield projects, available documentation may not represent actual conditions, and important constraints only become visible in the field.
In these cases, demand planning should consider intermediate deliverables. Engineering Technical Due Diligence is appropriate when the decision depends on diagnosis of assets, risks, compliance, and priorities. The Site Survey is more focused on structured technical field data collection. The existing-conditions survey organizes the geometry, installations, and existing infrastructure. Each deliverable resolves a different type of uncertainty.
Contracting design directly without these inputs when they are necessary transfers uncertainty to the designer and then to construction. The result usually appears as weak assumptions, inconsistent quantities, unidentified interferences, and scope changes.
How the DFD connects to the Annual Procurement Plan
Decree No. 10,947/2022 defines the DFD as the document that supports the PCA. The plan consolidates demands for the following fiscal year and should help rationalize procurement, align needs with planning, support budgeting, prevent expenditure splitting, and signal intentions to the market.
For Engineering, this connection has a practical consequence: it is not enough to list future works. The technical maturation time of each one must be considered.
If a construction project first depends on a survey, then design, then budgeting, and only then bidding, these stages need to be recognized in the schedule. The Decree also provides that, when consolidating the PCA, a calendar be prepared by priority, considering the start of the procurement process and budgetary and financial availability.
A well-structured Engineering portfolio distinguishes, for example:
- demands ready for procurement;
- demands that require an ETP;
- demands requiring survey or diagnosis;
- demands that still require design;
- demands dependent on other interventions;
- demands that should be phased according to risk, budget, or operational continuity.
This view transforms the PCA from an administrative list into an instrument for actual preparation of the investment portfolio.
Frequent mistakes when preparing Engineering DFDs
Some errors reduce the quality of the preparatory phase even when the form is formally complete.
Describing only the desired solution
When the document begins with a brand, model, quantity, or technology without demonstrating the need that led to that choice, the subsequent stage may become constrained by a solution that has not yet been studied.
Confusing a preliminary estimate with a design budget
The estimate used for planning does not replace the technical budget that will be developed with the level of accuracy appropriate for procurement. The lower the scope maturity, the greater the caution required with apparently exact numbers.
Ignoring dependencies
Renovating a technical room may depend on electrical systems, HVAC, fire protection, network, civil works, and operational migration. The Decree requires indication of linkage or dependency between DFDs precisely to support procurement sequencing.
Failing to record impact and priority in a verifiable way
“High priority” without a technical reason does little to support comparison among demands. Service continuity, risk to life, obsolescence, unavailability, legal requirement, capacity, and institutional impact are more useful criteria for justifying prioritization.
Contracting execution when the need still requires Engineering
This is the highest-impact error. When sufficient technical definition does not exist, the organization should first contract the stage required to produce it — survey, diagnosis, study, or design — instead of requiring execution to determine simultaneously what must be done and how it must be done.
How to structure the next step after the DFD
The ETP should not merely confirm the solution imagined at the outset. It should begin with the need, evaluate alternatives, and demonstrate the suitability of the procurement.
Once the Engineering demand has been formalized, the next stage is to mature the decision technically.
The next document is not always the same. The decision depends on the level of available knowledge and the nature of the need.
| Situation | Likely next technical step |
| Existing condition unknown | Site Survey or existing-conditions survey |
| Risks, failures, and priorities not yet understood | Due Diligence or technical diagnosis |
| Users and requirements need consolidation | Needs Program |
| Relevant solution alternatives exist | ETP or feasibility study |
| Solution needs to be conceived and compared | Conceptual Design or preliminary design |
| Work/service needs definition for procurement | Basic Design |
| Execution requires complete detailing | Detailed Design |
| Scope is technically defined and needs to be procured | Terms of Reference, tender documents, and applicable attachments |
This sequence is not rigid. Simple projects may not require some stages; complex projects may require several in parallel. The criterion should be the maturity needed for the next decision to be made with sufficient evidence.
How Consulting Engineering can support without replacing the Administration’s responsibility
Contracting technical support does not transfer the administrative responsibilities of the authority, requesting area, or public agents to the consultant. Consulting Engineering contributes by producing and reviewing the technical basis used to support decisions.
This support may involve field surveys, diagnosis, requirements consolidation, alternatives analysis, feasibility studies, designs, estimates, interface matrices, technical-document review, and support in defining measurement and acceptance criteria.
When the demand involves multiple disciplines or existing facilities, Consulting Engineering can function as a structuring layer between the institutional need and the technical packages that will later be procured.
The main gain is not “filling out the DFD.” It is reducing the distance between what the organization says it needs and what it can actually specify, budget, procure, supervise, and accept.
What to require from technical support used to structure the demand
When specialized support is contracted at this stage, the scope should provide for verifiable deliverables. Depending on complexity, these may include:
- existing-condition survey and report;
- stakeholder and needs matrix;
- record of assumptions and constraints;
- technical requirements matrix;
- interface and dependency map;
- solution alternatives and comparison criteria;
- preliminary estimates with explicit assumptions;
- technical risk matrix;
- phasing strategy;
- definition of required studies and designs;
- support for structuring the ETP, Basic Design, or TR in the strictly technical portion.
Acceptance should be associated with the completeness, traceability, and consistency of this information, not merely with delivery of a textual document.
Final considerations
The DFD is the beginning of planning, not the end of technical definition. For engineering works and services, its greatest value lies in correctly recording the need and allowing the organization to identify the maturation path required before procurement.
A well-formalized demand avoids two extremes: detailing too early a solution that has not yet been studied, or advancing to bidding with insufficient information. Between these extremes lies an Engineering sequence — surveys, requirements, studies, designs, budgeting, execution criteria, and acceptance — that transforms an administrative intention into a technically procurable scope.
When this sequence is planned from the DFD onward, procurement no longer begins with the tender documents and instead begins with a correct understanding of the problem.
In multidisciplinary demands, the difficulty rarely lies in filling out a document. It lies in coordinating technical information, risks, interfaces, designs, and procurement criteria without losing traceability.
Consulting Engineering can structure this basis before uncertainty reaches the tender documents or execution.
Technical references
[1] BRASIL. Presidency of the Republic. Decree No. 10,947, January 25, 2022. Regulates the Annual Procurement Plan and establishes the Procurement Planning and Management System within the federal direct, autonomous, and foundation public administration. Available at: https://www.planalto.gov.br/ccivil_03/_ato2019-2022/2022/decreto/d10947.htm
[2] 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
[3] BRASIL. Ministry of Management and Innovation in Public Services. SEGES Normative Instruction No. 58, August 8, 2022. Provides for preparation of Preliminary Technical Studies — ETP. Available at: https://www.gov.br/compras/pt-br/acesso-a-informacao/legislacao/instrucoes-normativas/instrucao-normativa-seges-no-58-de-8-de-agosto-de-2022
Frequently asked questions
DFD is the Demand Formalization Document. Within the federal framework regulated by Decree No. 10,947/2022, it evidences and details the procurement need and supports the Annual Procurement Plan.
No. The DFD formalizes the need at an earlier stage. The ETP deepens the need, analyzes alternatives, and substantiates the solution considered most appropriate when its preparation is applicable.
Not necessarily. If the solution still needs to be developed, the DFD may record the need and indicate that surveys, studies, preliminary design, Basic Design, or other technical deliverables will be required before contracting execution.
Responsibility and workflow depend on the regulations applicable to the agency. Under Decree No. 10,947/2022, the requester completes the DFD and the document may be forwarded to the technical area for analysis, supplementation, consolidation of demands, and standardization.
Yes, when specialized technical support is required. The support may produce surveys, diagnoses, requirements, studies, designs, and analyses that assist the Administration without replacing the decision-making and administrative responsibilities of public agents.
It depends on the maturity of the demand. A Site Survey, existing-conditions survey, Needs Program, ETP, feasibility study, preliminary design, Basic Design, Detailed Design, or preparation of the technical procurement instrument may be necessary.
Additional technical materials
Related solutions
- Project, Program, and Portfolio Governance
- Contracts, Scope, and Deliverables Management
- Requirements, Evidence, and Acceptance Criteria Management
Related services
- Preliminary Technical Study (ETP) for Engineering Works and Services
- Engineering Needs Program and Requirements
- Site Survey: technical survey, field diagnosis, and design requirements
- Engineering Technical Due Diligence
- Engineering Basic Design
- Terms of Reference for Engineering Works and Services
Main content on this topic
- Preliminary Technical Study (ETP) for Engineering Works and Services: how to structure a technically feasible procurement
- Terms of Reference in Engineering: scope, technical criteria, measurement, and acceptance
- Engineering Basic Design: what it is, stages, and readiness criteria
- Complete Guide to Public Procurement and Engineering Contracts