Learn how to structure an Engineering technical requisition with scope, specifications, interfaces, vendor data, quality, tests and acceptance criteria.
Check it out!
A technical requisition in Engineering is the document package that releases an acquisition or contract to the Procurement process with a sufficiently defined technical baseline. It consolidates what will be supplied, which requirements must be met, which documents compose the solicitation, how proposals will be compared and which evidence will be required during manufacturing, installation, testing and acceptance.
In industrial, infrastructure, energy, Data Center, telecommunications and critical-system projects, the technical requisition acts as the bridge between Engineering and Procurement. If it is issued incomplete, competition begins with gaps that later emerge as supplier questions, heterogeneous proposals, exclusions, change orders, delays, interface conflicts or commissioning difficulties.
The requisition should not be confused with a simple bill of materials or with the RFP or RFQ. It is the technical input baseline used to assemble the market solicitation. Depending on the object, it may include specifications, data sheets, drawings, lists, design narratives, acceptance criteria, quality requirements, responsibility matrix and vendor data documentation.
What a technical requisition is for
The technical requisition is the maturity gate between Engineering and Procurement. Its function is to prevent formal contracting from beginning while requirements, interfaces and acceptance criteria remain undefined.
The technical requisition transforms a project need into a package that can be acquired on a comparable basis. Its purpose is to ensure that Procurement does not have to interpret the Engineering scope on its own and that suppliers receive the same technical reference.
The World Bank highlights in its Procurement resources that Terms of Reference and technical specifications need to be prepared in a way that can guide the market and evaluation. PMBOK, in turn, connects Statement of Work, estimates, solicitation documents and supplier evaluation within the Procurement flow.
In EPC/EPCM organizations, the term Technical Requisition is frequently used for the document that groups the technical specification, data sheets, lists and document requirements of a purchasing package.
What the technical requisition is not
The document boundary needs to be clear.
| Document | Main function |
| bill of materials | quantifies items, components or equipment |
| technical specification | defines technical and performance requirements |
| data sheet | records parameters applicable to an item or equipment |
| technical requisition | consolidates the package’s technical baseline for Procurement |
| RFP | requests a structured proposal for a complex object |
| RFQ | requests a quotation for a sufficiently defined object |
| contract/purchase order | formalizes commercial and legal obligations |
The requisition may incorporate or reference all of these technical documents, but it does not replace the commercial and contractual instrument.
When the requisition is mature enough for issue
The criterion should not be “the document is written,” but “can the market form a comparable and executable offer from this baseline?”
Before release, Engineering needs to verify whether:
- scope is bounded;
- battery limits are clear;
- interfaces with third parties are identified;
- mandatory requirements are distinguished from preferences;
- required design data are available;
- permitted alternatives are defined;
- tests and acceptance criteria follow a verifiable logic;
- required supplier documents have been specified;
- quantities and units are consistent;
- drawings and lists use the correct revisions;
- owner assumptions and exclusions are explicit.
When one of these gaps is material, issuing the requisition merely to “save time” can shift the delay into a more expensive phase.
Recommended structure of the technical requisition
There is no single template suitable for every sector. The structure should reflect the object, but an Engineering package may contain the following blocks.
Package identification
Code, title, discipline, system, project, installation location, revision, technical owner and reference to the procurement plan.
Scope of supply
Describes what the supplier must deliver, including equipment, materials, services, application Engineering, installation where applicable, testing, documentation, training, spares and support.
Boundaries and interfaces
Defines the points where supplier responsibility begins and ends. In integrated systems, this section is as relevant as the equipment specification itself.
Applicable technical documents
May include:
- specifications;
- design narratives;
- drawings;
- diagrams;
- data sheets;
- bills of materials;
- I/O lists;
- system architecture;
- Engineering studies;
- standards and codes;
- project reference documents.
Performance requirements
Measurable parameters that the solution must achieve. Whenever possible, they should be defined in a verifiable way and associated with the evidence that will demonstrate compliance.
Quality and inspection requirements
Include quality plan, ITP, certificates, traceability, inspections, witness points, hold points, FAT, special tests and nonconformity treatment where applicable.
Vendor data requirements
Define which documents the supplier must deliver, in which revision, format and deadline. This list should exist before contracting because some documents may be required to continue the design itself.
Acceptance criteria
Explain how the owner will confirm compliance: document approval, tests, inspections, SAT, commissioning, final documentation or other mechanisms.
The scope of supply needs to include invisible services
Many differences between proposals are not in the main equipment, but in the services and accessories needed to put it into operation.
The requisition should verify, according to the package:
- application Engineering;
- manufacturer drawings;
- accessories and mounting kits;
- connectors and interfaces;
- software licenses;
- configuration;
- integration;
- special tools;
- installation supervision;
- start-up;
- FAT and SAT;
- training;
- documentation;
- spares;
- warranty and support.
When these elements remain implicit, each bidder creates its own interpretation and the comparison loses validity.
Battery limits and interfaces
Battery limits define physical or functional boundaries of the supply. In multidisciplinary Engineering, the requisition should record connection points, power supply, communications, infrastructure, responsibility for cables, supports, software, civil works, integration and testing.
An interface matrix can be more effective than long paragraphs.
| Interface | Supplier | Owner/third party | Evidence |
| electrical power | equipment terminal | upstream circuit and protection | diagram and electrical load |
| data network | Ethernet interface | switch and infrastructure | port and protocol requirements |
| civil foundation | loads and anchors | foundation design and execution | load drawing |
| software | license and configuration | server infrastructure | requirements matrix |
| commissioning | equipment tests | system integration | SAT protocol |
This definition reduces later disputes over “scope by others.”
Prescriptive requirements and performance requirements
The requisition should balance two forms of specification.
Prescriptive requirements define materials, models, dimensions, architecture or method. They are suitable when interoperability, standardization or consolidated experience require a specific solution.
Performance requirements define the result that needs to be achieved and allow the supplier to propose how to achieve it. They are useful when legitimate room exists for innovation or equivalent solutions.
An excessively prescriptive specification may restrict the market without technical benefit. An excessively functional specification may transfer to the supplier decisions that should remain under Engineering control.
How to address applicable standards and documents
The requisition should list standards only when genuinely relevant to the object and to the edition applicable to the project. Copying an extensive standards list from another package creates conflicts and irrelevant requirements.
Document precedence also needs to be defined. If a drawing, data sheet and specification conflict, the supplier needs to know which document governs or how to issue a technical query.
An explicit hierarchy reduces ambiguities during bidding and execution.
Requirements matrix for comparable proposals
For complex packages, a compliance matrix may accompany the requisition. Each requirement receives an identifier and the supplier indicates compliance, evidence, deviation or alternative.
This matrix facilitates the future TBE because evaluation no longer begins with an unstructured reading of hundreds of pages.
A typical classification may use:
- compliant;
- clarification required;
- deviation;
- technical alternative;
- noncompliant.
The meaning of each status should be defined in the process.
How to prepare requirements for the TBE
The team preparing the requisition should think about the future evaluation. For each relevant requirement, it should be possible to answer:
- how the supplier will demonstrate compliance in the proposal;
- what evidence will be accepted;
- whether the requirement is mandatory or differentiating;
- whether alternatives are permitted;
- how the requirement will be verified after contracting.
This traceability connects specification, TBE and acceptance.
Technical requisition and RFI
When Engineering still cannot complete the requisition because questions remain about technology, market, capability or interfaces, an RFI may be issued first.
The consultation serves to mature the baseline, not to replace Engineering work. After consolidating responses, the team revises specifications and releases the requisition at an adequate level for RFP or RFQ.
Technical requisition and RFP
In an RFP, the technical requisition defines the reference against which differentiated solutions will be evaluated. It needs to indicate which requirements are fixed and where solution freedom exists.
If this boundary is unclear, suppliers may interpret any requirement as negotiable or, at the opposite extreme, assume that no alternative is permitted.
Technical requisition and RFQ
An RFQ assumes greater object stability. Therefore, the requisition supporting an RFQ needs to eliminate relevant differences in scope, quantity, performance and documentation.
When suppliers still need to design substantial parts of the solution to respond, the process is probably closer to an RFP than an RFQ.
Vendor data must be defined before award
The Vendor Data Requirement List, Vendor Document Register or equivalent structure specifies what the supplier must issue during the contract.
Typical documents may include:
- certified data sheets;
- dimensional drawings;
- loads and interfaces;
- diagrams;
- bills of materials;
- manuals;
- test procedures;
- certificates;
- inspection reports;
- software documentation;
- final documentation and manufacturer As-Built.
If these documents are negotiated only after award, the owner loses the leverage to establish deadlines and formats without commercial impact.
Submittals and approval cycles
The requisition should indicate which documents are submitted for information, review, approval or record. It should also define the effect of approval: reviewing a manufacturer drawing does not transfer responsibility for the supplier’s design to the owner, except where a specific contractual provision states otherwise.
The cycles need to account for review time and possible resubmittal. Late vendor data can block manufacturing or Engineering work in other disciplines.
Quality, inspection and FAT requirements
For critical packages, the requisition should establish the basis for quality control from the beginning. It is not enough to request “FAT included” without defining scope, reference, procedures, witnessing and approval criteria.
The same applies to inspections. The owner needs to define when hold points, witness points, mandatory certificates and nonconformity treatment will apply.
This logic connects to Quality Management in Procurement, which follows the supply through acceptance.
Delivery conditions and technical logistics
Some logistics aspects are technical in nature and need to be in the requisition: special packaging, preservation, environmental restrictions, storage guidance, loose parts, lifting, protection against vibration, moisture or corrosion.
These conditions can influence packaging design and even equipment configuration.
Revisions and baseline freeze
The technical requisition needs controlled revision. If Engineering changes after suppliers have started quoting, the process should record the impact and issue a formal revision or clarification to all participants according to the competition rules.
After award, changes should follow Engineering Change Management or contractual change control. Silently changing the specification destroys traceability among proposal, contract and supply.
Requisition release checklist
Before issue to Procurement, an independent review can confirm:
- complete scope;
- documents listed and at the correct revision;
- reconciled quantities;
- defined interfaces;
- measurable performance criteria;
- mandatory requirements identified;
- relevant standards;
- vendor data defined;
- coherent quality and testing requirements;
- acceptance criteria established;
- compatible RFI/RFP/RFQ strategy;
- evaluation owners defined.
For critical packages, this checklist can function as a formal gate.
Requisition quality indicators
Document quality can be observed through signals in the downstream process:
| Indicator | Possible root problem |
| large volume of supplier questions | ambiguous scope or requirements |
| many revisions during competition | baseline released too early |
| proposals with very different exclusions | incomplete supply boundaries |
| long TBE with many clarifications | insufficient requirements matrix |
| changes immediately after award | immature interfaces or design data |
| vendor data negotiated later | document requirements not defined |
These data can feed lessons learned and improve future templates.
Technical requisition for Engineering services
The concept can also be applied to services, even if the document is called Terms of Reference, Statement of Work or Scope of Services. The logic remains the same: define scope, deliverables, assumptions, expected methodology, interfaces, evaluation criteria, measurement and acceptance so that proposals can be compared.
For intellectual services, avoiding prescription of the final product itself in advance is especially important. The document should require sufficient methodology and evidence to assess capability without transferring free performance of the scope to the bidder during competition.
Integration with the procurement plan
The requisition release date is a procurement-plan milestone. If it slips, all downstream package activities shift: issue, proposals, TBE, award, vendor data, manufacturing, testing and delivery.
Project Controls should therefore monitor not only purchase orders already issued, but also requisitions still under preparation by Engineering.
Final considerations
The technical requisition is one of the most effective barriers against Procurement problems that appear commercial but originate in insufficiently defined Engineering. It transforms requirements, drawings, interfaces, quality, documentation and acceptance into a common baseline for the market.
When prepared with traceability and integrated with the procurement plan, TBE and vendor-data control, it reduces ambiguities before they become price, delay, change order or responsibility disputes.
Vendor data needs to be contracted before it is needed. If critical drawings and data sheets are negotiated only after award, Engineering loses predictability precisely in the documents that feed design, manufacturing and construction.
Technical references
[1] PROJECT MANAGEMENT INSTITUTE. A Guide to the Project Management Body of Knowledge (PMBOK® Guide). 8th ed. Newtown Square: PMI, 2025. Available at: [https://www.pmi.org/standards/pmbok](https://www.pmi.org/standards/pmbok)
[2] WORLD BANK. Procurement learning resources: Terms of Reference and Technical Specifications. Available at: [https://www.worldbank.org/en/scci/topic/procurement](https://www.worldbank.org/en/scci/topic/procurement)
[3] WORLD BANK. Procurement Regulations for IPF Borrowers. 7th ed. Washington, DC, 2025. Available at: [https://thedocs.worldbank.org/en/doc/c84273d1b230aeb2b0b8134de5dc8cd7-0290012025/original/Procurement-Regulations-7th-Edition-Sep-2025.pdf](https://thedocs.worldbank.org/en/doc/c84273d1b230aeb2b0b8134de5dc8cd7-0290012025/original/Procurement-Regulations-7th-Edition-Sep-2025.pdf)
[4] ISO; IAF. ISO 9001 Auditing Practices Group: Guidance on External Providers. Available at: [https://committee.iso.org/files/live/sites/tc176/files/PDF%20APG%20New%20Disclaimer%2012-2023/ISO-TC%20176-TF_APG-ExternalProviders.pdf](https://committee.iso.org/files/live/sites/tc176/files/PDF%20APG%20New%20Disclaimer%2012-2023/ISO-TC%20176-TF_APG-ExternalProviders.pdf)
Frequently asked questions
It is the document package that consolidates the technical baseline needed for Procurement to request and compare offers, including scope, specifications, interfaces, documents, quality requirements and acceptance criteria.
No. The requisition is the technical input prepared by Engineering. The RFP is the market solicitation that uses this baseline together with commercial, contractual and evaluation rules.
Scope, boundaries, specifications, data sheets, applicable drawings, performance requirements, quality, inspection, tests, vendor data, documentation and acceptance criteria, according to package complexity.
When the baseline allows the market to form comparable and executable offers without material gaps in scope, interface, performance or acceptance.
They are document requirements defining which drawings, data sheets, reports, manuals, certificates and other documents the supplier must deliver, with deadlines and review status.
Yes, when necessary, but the revision must be controlled and formally communicated to participants to preserve equal treatment, traceability and comparability.
Complementary technical materials
Related solutions
- Requirements, Evidence and Acceptance Criteria Management
- Contract, Scope and Deliverables Management
Related services
- Technical Procurement: specification, equalization, suppliers and contracting support
- Technical Support for Tendering and Engineering Bid Analysis: compliance, technical and price
Core content on the topic
- RFP in Engineering: how to structure scope, requirements and selection criteria
- RFQ in Engineering: how to request commercially comparable proposals
