Nobody reads a 300-page tender package from the first page to the last. People read the sections they own: the mechanical engineer reads the mechanical spec, QA reads the inspection spec, the bid manager reads the instructions. The requirements that fall between sections fall between people.
Where requirements hide
In prose. "The vendor shall ensure that all pressure-retaining components are suitable for the design life stated herein" is a requirement without a clause number, in a paragraph about something else.
In data-sheet footnotes. Line 14 says 150 bar at 120 °C; note 3 at the bottom says "at 100 °C for carbon steel bodies". Which governs is a clarification question nobody asks because nobody saw note 3.
In the documentation annex. Annex C specifies the buyer's document numbering and native CAD formats. It is a requirement with IP implications, and it is in an annex.
In the addendum. Issued on day five, revising the design temperature. If the register was a spreadsheet typed on day one, the addendum is a manual diff nobody has time for.
Extraction as a discipline
Reading every document in the package for normative language — shall, must, minimum, in accordance with — and extracting each occurrence with its source and location produces a register that is over-inclusive on purpose. The bid manager strikes the false positives in an hour; that is far cheaper than discovering a missed requirement in the buyer's scoring.
Duplicates across documents are linked so the decision is made once. Conflicts — the spec says one value, the data sheet another — are flagged as clarification questions. Addenda are diffed against the register, and the lines whose status changed are highlighted.
What the register is for
Everything downstream — the matrix, the deviation table, the draft, the question list — is only as complete as the register. Getting the reading right is the unglamorous first step, and it is the step that was never done completely by hand.