{"id":73520,"date":"2026-08-31T16:04:11","date_gmt":"2026-08-31T19:04:11","guid":{"rendered":"https:\/\/a3aengenharia.com\/?post_type=articles&p=73520"},"modified":"2026-08-31T16:04:11","modified_gmt":"2026-08-31T19:04:11","slug":"dfd-engineering-works-services-formalize-demand-before-etp","status":"publish","type":"articles","link":"https:\/\/a3aengenharia.com\/en-us\/content\/technical-articles\/dfd-engineering-works-services-formalize-demand-before-etp\/","title":{"rendered":"DFD for Engineering Works and Services: How to Formalize the Demand Before the ETP"},"content":{"rendered":"\n

The Demand Formalization Document (DFD)<\/strong> 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<\/strong>, which institutional result is intended, which dependencies are already known, and what level of technical development will be required before procurement.<\/p>\n\n\n\n

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.<\/p>\n\n\n\n

For simple demands, the description may be relatively direct. In Engineering, the situation is usually different. Expressions such as \u201crenovate the electrical installation,\u201d \u201cmodernize CCTV,\u201d \u201cupgrade the building,\u201d \u201creplace the HVAC system,\u201d or \u201cexpand the network\u201d 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.<\/p>\n\n\n\n

Therefore, a good Engineering DFD should be understood as the starting point of a technical maturity chain<\/strong>. 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.<\/p>\n\n\n\n

What the DFD should contain in an Engineering demand<\/h2>\n\n\n\n

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.<\/p>\n\n\n\n

For Engineering, these fields need to be completed carefully because each one influences subsequent development. The \u201cconcise description of the scope,\u201d 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<\/strong> than to prematurely lock in equipment, technology, architecture, or quantities.<\/p>\n\n\n\n

A demand such as \u201cpurchase 120 cameras\u201d 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?<\/p>\n\n\n\n

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.<\/p>\n\n\n\n

Need, intended outcome, and scope are not the same thing<\/h3>\n\n\n\n

A practical way to separate these concepts is to observe three levels:<\/p>\n\n\n\n

Level<\/td>Question<\/td>Example<\/td><\/tr>
Need<\/td>Which institutional problem needs to be solved?<\/td>There are areas without adequate security coverage, and the current system has capacity limitations and obsolescence.<\/td><\/tr>
Intended outcome<\/td>What should improve at the end?<\/td>Increase coverage, availability, investigation capability, and integration of the security system.<\/td><\/tr>
Scope<\/td>What will actually be procured?<\/td>It may still be a survey, design, system modernization, implementation, or a combination of stages after technical maturation.<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

This separation helps prevent the Administration from attempting to contract execution before technically knowing what needs to be executed.<\/p>\n\n\n\n

DFD, ETP, Terms of Reference, and Basic Design: what is the difference<\/h2>\n\n\n\n

The DFD formalizes the demand. The Preliminary Technical Study for engineering works and services<\/a> deepens the need, examines alternatives, and substantiates the solution that best serves the public interest. The Terms of Reference in Engineering<\/a> structures the scope, requirements, execution, measurement, and acceptance when it is the appropriate instrument. The Engineering Basic Design<\/a> provides sufficient technical definition to characterize the engineering work or service when this level of development is required.<\/p>\n\n\n\n

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.<\/p>\n\n\n\n

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 \u2014 or, at the opposite extreme, to treat it as a bureaucratic form without enough information to guide planning.<\/p>\n\n\n\n

Technical maturation of an Engineering demand from formalization to procurement<\/title><\/path><\/marker><\/path><\/marker><\/circle><\/marker><\/circle><\/marker><\/path><\/marker><\/path><\/marker><\/g><\/path><\/path><\/path><\/path><\/path><\/path><\/path><\/g>
<\/span><\/div><\/foreignObject><\/g><\/g>
<\/span><\/div><\/foreignObject><\/g><\/g>
<\/span><\/div><\/foreignObject><\/g><\/g>
<\/span><\/div><\/foreignObject><\/g><\/g>
<\/span><\/div><\/foreignObject><\/g><\/g>
<\/span><\/div><\/foreignObject><\/g><\/g>
<\/span><\/div><\/foreignObject><\/g><\/g><\/g><\/rect><\/rect>

Need<\/p><\/span><\/div><\/foreignObject><\/g><\/g><\/rect><\/rect>

DFD<\/p><\/span><\/div><\/foreignObject><\/g><\/g><\/rect><\/rect>

PCA<\/p><\/span><\/div><\/foreignObject><\/g><\/g><\/rect><\/rect>

Surveys and requirements<\/p><\/span><\/div><\/foreignObject><\/g><\/g><\/rect><\/rect>

ETP and alternatives<\/p><\/span><\/div><\/foreignObject><\/g><\/g><\/rect><\/rect>

Design or TR<\/p><\/span><\/div><\/foreignObject><\/g><\/g><\/rect><\/rect>

Budget and tender documents<\/p><\/span><\/div><\/foreignObject><\/g><\/g><\/rect><\/rect>

Procurement<\/p><\/span><\/div><\/foreignObject><\/g><\/g><\/g><\/g><\/g><\/svg>

Technical maturation of an Engineering demand from formalization to procurement<\/figcaption><\/figure>\n\n\n\n

When the technical area should participate in demand formalization<\/h2>\n\n\n\n

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.<\/p>\n\n\n\n

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.<\/p>\n\n\n\n

For example, a demand to \u201creplace the generator\u201d 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.<\/p>\n\n\n\n

When the installed condition is not yet sufficiently known, an Engineering Site Survey<\/a> or an Existing-Conditions Survey of buildings and facilities<\/a> may be necessary before advancing to specifications and designs.<\/p>\n\n\n\n

How to describe a need without prematurely specifying the solution<\/h2>\n\n\n\n

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.<\/p>\n\n\n\n

Consider the difference between two formulations:<\/p>\n\n\n\n

Premature formulation:<\/strong> \u201cPurchase model X 48-port switches to replace the network.\u201d<\/p>\n\n\n\n

Need-oriented formulation:<\/strong> \u201cThe 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.\u201d<\/p>\n\n\n\n

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.<\/p>\n\n\n\n

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<\/strong>.<\/p>\n\n\n\n

Which technical information improves an Engineering DFD<\/h2>\n\n\n\n

There is no single list for every scope, but some groups of information substantially improve planning quality:<\/p>\n\n\n\n