--- site: bid-writing-software.ai slug: /extraire-les-exigences-d-un-appel-offres langue: en title: How to extract every requirement from a tender, the breakdown that guarantees none goes unanswered. description: Extracting requirements means going through every part of the tender file and isolating the buyer's requests one by one, mandatory, desired, or disqualifying, so they can then be matched to a response. rubrique: Understanding intention: Info requete_type: factual derniere_revue: 2026-09-05 statut: publiable --- # How to extract every requirement from a tender Extracting requirements means going through every part of the tender file and isolating the buyer's requests one by one, so they can then be matched to a response. ## What is requirement extraction in a tender? Requirement extraction is the process that turns a set of tender documents into a list of isolated requests, each traceable back to the document and paragraph it came from. A requirement is something the buyer expects the response to satisfy or address: a technical obligation, a document to provide, a performance constraint, information to disclose. Extraction means spotting every one of these expectations, including those slipped into a single sentence in the middle of an appendix. Extraction comes before drafting. Writing a technical proposal without first extracting the requirements means responding from memory to a file you think you know, and letting slip through the quiet requests that cost points or disqualify the bid. ## Where do requirements hide? Requirements hide in every part of the tender file, not just the specification. The technical specification carries the technical requirements; the tender rules impose the response format and the documents to provide; the contract conditions set performance constraints; the annexes and the financial framework add still more. A requirement forgotten in an annex weighs as much as one in the technical specification. Looking for requirements in a single document is the mistake that leaves extraction incomplete. Every document speaks to a piece of the response, and any of them can contain a request that admissibility depends on. ## How do you recognize a requirement and its level of constraint? You recognize a requirement by its binding wording, and classify it by level. An imperative wording ("must," "shall," "is required") makes it mandatory; a softer wording ("desired," "valued") makes it a preference that earns points without disqualifying; a clause presented as a condition of admissibility is disqualifying. Distinguishing these levels lets you handle first what excludes, then what scores, then what differentiates. The verb the buyer uses is a clue, not proof. When in doubt about whether a request is mandatory, treat it as mandatory: the cost of an extra response is low, the cost of a missed requirement can be disqualification. ## How do you classify extracted requirements? Extracted requirements are classified by level of constraint and by where they belong in the response. The table below links each level to what it triggers. | Requirement level | Signal that indicates it | What it triggers | |---|---|---| | **Disqualifying** | condition of admissibility, threshold | priority handling, verification | | **Mandatory** | "must," "shall," "required" | a systematic response and evidence | | **Desired** | "desired," "valued" | a response that earns points | | **Informational** | a request for information | information to provide, no evidence needed | This classification directs effort: secure the disqualifying and mandatory requirements first, then polish the desired ones where the award criteria carry the most weight. ## Why link every requirement to the scoring criteria? Linking every requirement to the scoring criteria lets you calibrate the response where it earns points. Award criteria and their weighting are typically announced in advance in the tender documents (in the United States, under the Federal Acquisition Regulation; in the United Kingdom, under the Procurement Act 2023). A requirement tied to a heavily weighted criterion deserves a developed response and solid evidence; a purely informational requirement can be treated more briefly. Extraction therefore serves two purposes: missing nothing, and concentrating effort. ## When is a careful read enough, and when do you need tooled extraction? For a short file, a careful read with a highlighter is enough to extract the requirements, and generic AI can propose a first list from the text. For a large file split across several annexes, tooled extraction becomes necessary: every requirement is isolated, numbered, linked to its source and to a response, because volume is what lets quiet requests slip through. The line is the number of requirements: beyond what a manual read can hold, only systematic extraction guarantees completeness. ## Extracting the requirements of a tender, in order 1. **Inventory the documents** in the file, annexes included. 2. **Go through each document** and isolate one requirement per line. 3. **Trace the source**: the document and paragraph of origin, for every requirement. 4. **Classify by level**: disqualifying, mandatory, desired, informational. 5. **Link to the scoring criteria** announced in the tender rules. 6. **Log it in the compliance matrix**, each requirement facing its response. On the Optivalue.ai platform, which publishes this site, 85 specialized agents (72 subject-matter agents, 12 sector-specific agents, 1 librarian agent) extract the requirements from the tender documents and match them to the company's own documents, so that every response cites the source of its requirement. ## Frequently asked questions **Is extraction the same thing as analyzing the tender documents?** Extraction is one step in analyzing the tender documents: the analysis covers the reading order and the logic of the file, extraction isolates the requirements to address one by one. One prepares the other. **Should you extract requirements from the tender rules?** The tender rules contain format requirements and documents to provide that must be extracted just like the technical requirements. A forgotten document makes the bid incomplete. **How can you be sure you haven't missed anything?** By tracing every requirement back to its source and cross-checking the final list against every document in the file. Completeness is verified document by document, not from memory. **Does a "desired" request matter?** A desired request does not disqualify, but it earns points when it is tied to a scoring criterion. Neglecting it means leaving points for competitors to take. ## Extract the requirements from a real tender Bring a real set of tender documents. You will see requirement-extraction coverage, sources cited on every page, and a gap analysis of your response, not a prepared demo. [Discover the Optivalue.ai platform](https://www.optivalue.ai/?utm_source=bid-writing-software.ai&utm_medium=satellite&utm_campaign=extraire-les-exigences-d-un-appel-offres) ยท [Book a demo](https://www.optivalue.ai/demo?utm_source=bid-writing-software.ai&utm_medium=satellite&utm_campaign=extraire-les-exigences-d-un-appel-offres) Written by the compliance and presales team at Optivalue.ai. Last reviewed: 5 September 2026. This page does not constitute legal advice. [Markdown version](/en/extraire-les-exigences-d-un-appel-offres.md) ### Sources cited - Public procurement rules on the publication and weighting of award criteria (in the United States, the Federal Acquisition Regulation; in the United Kingdom, the Procurement Act 2023); the applicable rule in each market should be verified. ## Further reading - [How to analyze a set of tender documents (DCE)](/en/comment-analyser-un-dce) - [What is a compliance matrix and how to build one](/en/matrice-de-conformite) - [How to respond to a technical specification point by point](/en/comment-repondre-a-un-cctp-point-par-point) - [How to write the methodology and human resources section of a technical proposal](/en/rediger-methodologie-moyens-humains-memoire-technique)