Skip to main content
All resources

Articles

Why requirement review needs source context

Extracted requirement lists lose the conditions around them. Reviewing beside the source is what keeps meaning intact.

What extraction removes

Turning twelve pages of prose into thirty numbered rows is genuinely useful — and lossy. The sentence before a requirement often says who it applies to; the sentence after often says when it can be waived. A row that reads "provide three comparable references" is not the same requirement as "provide three comparable references completed within the last five years, at least one in the client's own governorate".

A requirement list is a summary. Summaries drop conditions, and conditions are where tenders are won and lost.

Review beside the document, not instead of it

The practical fix is not better extraction. It is keeping the page open next to the list, so confirming a row takes a glance rather than a search. Reviewers who can see the clause approve faster and change more of what they approve — because they can see what the summary dropped.

Three checks worth making on every extracted row

None of these takes more than a few seconds when the source is on screen.

  • Is it actually mandatory, or does the clause use "should" rather than "shall"?
  • Does a condition elsewhere in the document narrow or widen it?
  • Is it one requirement, or two that were written in a single sentence?