WHY ENGLISH?
Turn a purchasing need into fair, testable requirements
Use the routes to frame the outcome, separate needs from preferences, invite comparable offers and connect every promise to acceptance.
Open the full contents · See the How English Works hub
Full contents
Define the need
Structure requirements
Invite evidence
Test acceptance
Manage delivery
Practice and next steps
Practice and next steps
Practice and next steps
A procurement specification translates a real organisational need into requirements that suppliers can understand, price and satisfy. English matters because one vague adjective—fast, secure, user-friendly, robust or best—can hide several incompatible interpretations. Clear specification writing makes competition fairer and later acceptance more objective.
People searching for procurement specifications, tender requirements, scope of work, technical specifications, service levels, request for proposal requirements or acceptance criteria often start with a product they already know. A stronger document begins with the outcome, users, constraints, evidence and test. It leaves room for a better solution without leaving basic needs uncertain.
Singapore's Ministry of Finance overview of government procurement says requirements, procedures and evaluation criteria are published on GeBIZ so suppliers can understand what is needed and how bids will be assessed. The MOF procurement-process page describes value for money, open and fair competition, transparency and public accountability, while the GeBIZ guide for suppliers explains the procurement process and common participation questions. These public-sector sources do not automatically govern a private purchase; use the applicable rules for the organisation and procurement.
Use the specification map need, outcome, user, scope, boundary, quantity, location, interface, standard, mandatory, desirable, performance, capacity, availability, security, privacy, accessibility, sustainability, evidence, response, assumption, dependency, service level, acceptance, test, defect, warranty, change, transition, handover and owner. The aim is a requirement that can be understood before award and verified after delivery.
Start with the business need
Begin the requirement with the problem, service gap or operational outcome prompting procurement. Procurement language should reveal the need before it narrows the solution.
Competition becomes unclear when the incumbent product becomes the unexamined requirement.
Return to outcome and state the need in user and organisational terms.
Need example. A school needs reliable attendance confirmation, not a particular brand of scanner Suppliers can now understand the real problem.
Did You Know? Singapore's Ministry of Finance states that public procurement requirements, procedures and evaluation criteria are published on GeBIZ to support transparency and understandable competition. This is why the problem, service gap or operational outcome prompting procurement needs a precise, dated record.
Name the procurement authority
Write the policy, approval and decision roles that govern the purchase as an atomic, controlled requirement.
Interpretations multiply when a project team writes commitments it cannot authorise.
Use one identifier and record sponsor, procurement lead and technical owner.
Specification example. The service owner approves outcomes while procurement controls the sourcing process The statement can receive a comparable response.
Keep mandatory, desirable and optional language consistent across every schedule.
Describe users and contexts
Ask for evidence about the people, environments and moments in which the supply must work in a form the evaluator can compare fairly.
The evaluation drifts when an average user in an ideal office replaces real operating conditions.
Align response field, criterion and include relevant accessibility, language and location needs.
Evidence example. A kiosk must work for seated users and in a bright public lobby The claim has a reviewable basis.
Stage expensive evidence where possible and do not request confidential material without a controlled need.
State outcomes before features
Connect the result the organisation needs rather than a favoured implementation with delivery, acceptance and operation.
Contract ambiguity appears when a feature list blocks alternative solutions without justification.
Trace the requirement through test and write measurable outcomes and only necessary design constraints.
Acceptance example. The requirement asks for confirmed identity within a target time rather than a named technology Both parties can see what completion means.
Preserve the baseline and use the authorised change route when the need changes.
Define scope
Begin the requirement with the goods, services, sites, stages and deliverables included. Procurement language should reveal the need before it narrows the solution.
Competition becomes unclear when everything related is assumed to be part of the price.
Return to outcome and draw an explicit scope boundary.
Need example. Migration covers two named systems but excludes historical paper records Suppliers can now understand the real problem.
Record the requirement source and why it is proportionate.
List exclusions
Write the work, environments and responsibilities outside the contract as an atomic, controlled requirement.
Interpretations multiply when silence is treated as agreement by each side.
Use one identifier and state exclusions beside the related scope item.
Specification example. Network cabling is supplied by the organisation, not the software vendor The statement can receive a comparable response.
Did You Know? Singapore's Ministry of Finance states that public procurement requirements, procedures and evaluation criteria are published on GeBIZ to support transparency and understandable competition. This is why the work, environments and responsibilities outside the contract needs a precise, dated record.
Quantify demand
Ask for evidence about the expected volumes, concurrency, locations and growth assumptions in a form the evaluator can compare fairly.
The evaluation drifts when large-scale is used without numbers.
Align response field, criterion and provide current and forecast ranges with dates.
Evidence example. The platform supports 800 concurrent users now and a tested growth scenario The claim has a reviewable basis.
Stage expensive evidence where possible and do not request confidential material without a controlled need.
Separate mandatory and desirable
Connect the requirements that determine eligibility versus added value with delivery, acceptance and operation.
Contract ambiguity appears when every preference is labelled must.
Trace the requirement through test and justify each mandatory condition and mark optional benefits.
Acceptance example. Local support hours are mandatory while an additional analytics dashboard is desirable Both parties can see what completion means.
Preserve the baseline and use the authorised change route when the need changes.
Use requirement keywords consistently
Begin the requirement with the controlled meaning of must, should, may and optional. Procurement language should reveal the need before it narrows the solution.
Competition becomes unclear when obligation words change across sections.
Return to outcome and publish definitions and apply them uniformly.
Need example. A supplier can distinguish a non-negotiable security control from a scored enhancement Suppliers can now understand the real problem.
Record the requirement source and why it is proportionate.
Write one requirement at a time
Write the atomic statement that can receive one response and one test as an atomic, controlled requirement.
Interpretations multiply when several duties are bundled under one identifier.
Use one identifier and split compound sentences and assign IDs.
Specification example. Reporting frequency and file format become two traceable requirements The statement can receive a comparable response.
Keep mandatory, desirable and optional language consistent across every schedule.
Avoid vague adjectives
Ask for evidence about the measurable property hidden behind easy, strong, fast or intuitive in a form the evaluator can compare fairly.
The evaluation drifts when opinion words become acceptance criteria.
Align response field, criterion and replace adjectives with observable outcomes.
Evidence example. A task is completed by a first-time user within a stated time in a usability test The claim has a reviewable basis.
Did You Know? Singapore's Ministry of Finance states that public procurement requirements, procedures and evaluation criteria are published on GeBIZ to support transparency and understandable competition. This is why the measurable property hidden behind easy, strong, fast or intuitive needs a precise, dated record.
Use performance requirements
Connect the response, throughput, accuracy, availability or capacity needed with delivery, acceptance and operation.
Contract ambiguity appears when implementation details are prescribed where performance would suffice.
Trace the requirement through test and state conditions, measure and threshold.
Acceptance example. A search returns the agreed percentile response under the specified load Both parties can see what completion means.
Preserve the baseline and use the authorised change route when the need changes.
Define functional requirements
Begin the requirement with the actions, rules and outputs the solution must support. Procurement language should reveal the need before it narrows the solution.
Competition becomes unclear when a user story is too broad to test.
Return to outcome and name trigger, behaviour and result.
Need example. An authorised officer can reverse an erroneous status with an audit record Suppliers can now understand the real problem.
Record the requirement source and why it is proportionate.
Define interfaces
Write the systems, data, protocols and responsibilities at integration boundaries as an atomic, controlled requirement.
Interpretations multiply when connects to existing systems is treated as complete.
Use one identifier and name owner, version, direction and failure handling.
Specification example. The supplier consumes the documented API while the buyer provides test credentials The statement can receive a comparable response.
Keep mandatory, desirable and optional language consistent across every schedule.
Address data migration
Ask for evidence about the source, quality, mapping, reconciliation and rejected-record process in a form the evaluator can compare fairly.
The evaluation drifts when migration is priced as a single invisible task.
Align response field, criterion and define samples, volumes and acceptance evidence.
Evidence example. Totals and exception counts reconcile after a trial migration The claim has a reviewable basis.
Stage expensive evidence where possible and do not request confidential material without a controlled need.
Specify security outcomes
Connect the access, logging, protection, testing and response requirements with delivery, acceptance and operation.
Contract ambiguity appears when secure by industry standards appears without named evidence.
Trace the requirement through test and reference current approved standards and required proof.
Acceptance example. Privileged actions create tamper-evident logs retained for the agreed period Both parties can see what completion means.
Did You Know? Singapore's Ministry of Finance states that public procurement requirements, procedures and evaluation criteria are published on GeBIZ to support transparency and understandable competition. This is why the access, logging, protection, testing and response requirements needs a precise, dated record.
Specify privacy obligations
Begin the requirement with the collection, use, access, retention, transfer and deletion controls for personal data. Procurement language should reveal the need before it narrows the solution.
Competition becomes unclear when privacy is left to a contract boilerplate after design.
Return to outcome and connect data flows to minimisation and accountable roles.
Need example. Test accounts use synthetic data unless authorised otherwise Suppliers can now understand the real problem.
Record the requirement source and why it is proportionate.
Include accessibility
Write the ability of people with disabilities to use the service and information as an atomic, controlled requirement.
Interpretations multiply when accessibility is a goodwill aspiration.
Use one identifier and name the applicable standard, scope and evidence.
Specification example. Keyboard navigation and error messages are tested in the acceptance plan The statement can receive a comparable response.
Keep mandatory, desirable and optional language consistent across every schedule.
Include sustainability proportionately
Ask for evidence about the environmental requirements relevant to the goods or service in a form the evaluator can compare fairly.
The evaluation drifts when generic green language replaces a procurement decision.
Align response field, criterion and ask for measurable, contract-relevant evidence.
Evidence example. Equipment power consumption is compared under the same operating profile The claim has a reviewable basis.
Stage expensive evidence where possible and do not request confidential material without a controlled need.
Reference standards precisely
Connect the standard, version, clause and applicability of an external requirement with delivery, acceptance and operation.
Contract ambiguity appears when complies with all standards creates an unlimited promise.
Trace the requirement through test and cite only relevant current standards and explain precedence.
Acceptance example. The specification names the security standard edition and in-scope service Both parties can see what completion means.
Preserve the baseline and use the authorised change route when the need changes.
Handle equivalence fairly
Begin the requirement with the route for suppliers to demonstrate an equivalent standard or method. Procurement language should reveal the need before it narrows the solution.
Competition becomes unclear when a brand or certification excludes comparable evidence without reason.
Return to outcome and state the performance to be proven and review basis.
Need example. An alternative test report is accepted if it covers the same control objective Suppliers can now understand the real problem.
Did You Know? Singapore's Ministry of Finance states that public procurement requirements, procedures and evaluation criteria are published on GeBIZ to support transparency and understandable competition. This is why the route for suppliers to demonstrate an equivalent standard or method needs a precise, dated record.
Avoid unnecessary brand lock-in
Write the legitimate compatibility or support reason behind a named product as an atomic, controlled requirement.
Interpretations multiply when familiarity becomes a restrictive specification.
Use one identifier and describe interoperability and allow equivalents where appropriate.
Specification example. A consumable must fit installed equipment, with dimensions and safety criteria stated The statement can receive a comparable response.
Keep mandatory, desirable and optional language consistent across every schedule.
Write supplier response fields
Ask for evidence about the exact evidence, explanation, value or attachment expected for each requirement in a form the evaluator can compare fairly.
The evaluation drifts when suppliers answer in incomparable marketing prose.
Align response field, criterion and provide a response matrix and evidence labels.
Evidence example. Each mandatory requirement receives comply, partially comply or not comply plus a reference The claim has a reviewable basis.
Stage expensive evidence where possible and do not request confidential material without a controlled need.
Request evidence proportionately
Connect the certificates, reports, references, demonstrations or samples needed with delivery, acceptance and operation.
Contract ambiguity appears when every bidder carries an expensive proof burden before shortlist.
Trace the requirement through test and stage evidence and accept suitable forms.
Acceptance example. Detailed penetration evidence is requested from the preferred supplier under controlled access Both parties can see what completion means.
Preserve the baseline and use the authorised change route when the need changes.
Align evaluation criteria
Begin the requirement with the factors, weights and method used to compare offers. Procurement language should reveal the need before it narrows the solution.
Competition becomes unclear when the specification asks for qualities that evaluation ignores.
Return to outcome and trace requirements to published criteria.
Need example. Service continuity evidence contributes to the stated quality score Suppliers can now understand the real problem.
Record the requirement source and why it is proportionate.
Separate eligibility and scoring
Write the pass-fail conditions versus differentiating quality as an atomic, controlled requirement.
Interpretations multiply when the same issue is both an undisclosed gate and a score.
Use one identifier and mark treatment in the response schedule.
Specification example. A required licence is checked before scored implementation quality The statement can receive a comparable response.
Did You Know? Singapore's Ministry of Finance states that public procurement requirements, procedures and evaluation criteria are published on GeBIZ to support transparency and understandable competition. This is why the pass-fail conditions versus differentiating quality needs a precise, dated record.
Make price comparison possible
Ask for evidence about the pricing units, assumptions, options and total-cost period in a form the evaluator can compare fairly.
The evaluation drifts when headline prices hide different inclusions.
Align response field, criterion and issue a common pricing schedule.
Evidence example. Migration, subscription, training and exit support appear as separate comparable lines The claim has a reviewable basis.
Stage expensive evidence where possible and do not request confidential material without a controlled need.
State assumptions and dependencies
Connect the buyer and supplier conditions on which delivery relies with delivery, acceptance and operation.
Contract ambiguity appears when the supplier silently prices an ideal environment.
Trace the requirement through test and publish known dependencies and require declared deviations.
Acceptance example. Delivery dates assume buyer access to two named subject-matter experts Both parties can see what completion means.
Preserve the baseline and use the authorised change route when the need changes.
Define service levels
Begin the requirement with the measured service commitment, calculation window and remedy process. Procurement language should reveal the need before it narrows the solution.
Competition becomes unclear when uptime is quoted without exclusions or measurement source.
Return to outcome and state formula, reporting and exceptions.
Need example. Availability is calculated monthly from the agreed monitoring point Suppliers can now understand the real problem.
Record the requirement source and why it is proportionate.
Plan support and escalation
Write the routes, priorities, response targets and communication duties for incidents as an atomic, controlled requirement.
Interpretations multiply when twenty-four-seven support means only an email inbox.
Use one identifier and define severity, acknowledgement, update and resolution roles.
Specification example. A critical outage receives a named incident lead and scheduled updates The statement can receive a comparable response.
Keep mandatory, desirable and optional language consistent across every schedule.
Design acceptance tests
Ask for evidence about the objective checks that show each deliverable is ready in a form the evaluator can compare fairly.
The evaluation drifts when acceptance means the buyer is generally satisfied.
Align response field, criterion and trace tests to requirement IDs and data.
Evidence example. A migration test reconciles record counts and a sampled field mapping The claim has a reviewable basis.
Did You Know? Singapore's Ministry of Finance states that public procurement requirements, procedures and evaluation criteria are published on GeBIZ to support transparency and understandable competition. This is why the objective checks that show each deliverable is ready needs a precise, dated record.
Define test environments
Connect the data, configuration, tools and responsibilities needed for verification with delivery, acceptance and operation.
Contract ambiguity appears when production users become the first test.
Trace the requirement through test and agree representative environments and entry criteria.
Acceptance example. Performance testing uses the specified load profile before launch Both parties can see what completion means.
Preserve the baseline and use the authorised change route when the need changes.
Handle defects
Begin the requirement with the classification, correction, retest and acceptance effect of failures. Procurement language should reveal the need before it narrows the solution.
Competition becomes unclear when every issue blocks delivery or none does.
Return to outcome and publish severity definitions and closure evidence.
Need example. A critical privacy defect prevents acceptance while a cosmetic issue enters an agreed backlog Suppliers can now understand the real problem.
Record the requirement source and why it is proportionate.
Specify documentation
Write the user, administrator, technical and operational records required as an atomic, controlled requirement.
Interpretations multiply when documentation is one generic manual.
Use one identifier and name audience, format, update duty and acceptance.
Specification example. An operations runbook includes backup, restore, monitoring and escalation steps The statement can receive a comparable response.
Keep mandatory, desirable and optional language consistent across every schedule.
Plan training
Ask for evidence about the roles, learning outcomes, materials and evidence needed for adoption in a form the evaluator can compare fairly.
The evaluation drifts when training is measured only by attendance.
Align response field, criterion and define competence or task completion.
Evidence example. Administrators demonstrate configuration and recovery in a supervised exercise The claim has a reviewable basis.
Stage expensive evidence where possible and do not request confidential material without a controlled need.
Plan transition and handover
Connect the movement from project delivery into supported operation with delivery, acceptance and operation.
Contract ambiguity appears when go-live is treated as the end of responsibility.
Trace the requirement through test and state knowledge transfer, support overlap and ownership.
Acceptance example. The service desk accepts the runbook after shadow support and a readiness review Both parties can see what completion means.
Did You Know? Singapore's Ministry of Finance states that public procurement requirements, procedures and evaluation criteria are published on GeBIZ to support transparency and understandable competition. This is why the movement from project delivery into supported operation needs a precise, dated record.
Plan exit and portability
Begin the requirement with the data, formats, assistance and timelines needed when the arrangement ends. Procurement language should reveal the need before it narrows the solution.
Competition becomes unclear when exit is discussed only after relationship failure.
Return to outcome and specify export, deletion evidence and transition support.
Need example. Customer data are delivered in a documented format before certified deletion Suppliers can now understand the real problem.
Record the requirement source and why it is proportionate.
Control changes
Write the route for revising scope, requirement, price, time and acceptance as an atomic, controlled requirement.
Interpretations multiply when informal requests become unpriced obligations.
Use one identifier and record impact, authority and approved baseline.
Specification example. A new interface is assessed and signed before development begins The statement can receive a comparable response.
Keep mandatory, desirable and optional language consistent across every schedule.
Allocate risk deliberately
Ask for evidence about the party best able to control each uncertainty and its consequence in a form the evaluator can compare fairly.
The evaluation drifts when all risk is pushed to the supplier regardless of control.
Align response field, criterion and connect risk to authority, insurance and price.
Evidence example. The buyer owns delayed access to its legacy data while the supplier owns conversion quality The claim has a reviewable basis.
Stage expensive evidence where possible and do not request confidential material without a controlled need.
Use clarification fairly
Connect the controlled route for suppliers to ask and receive information with delivery, acceptance and operation.
Contract ambiguity appears when one bidder receives a material private answer.
Trace the requirement through test and publish relevant clarifications through the authorised channel.
Acceptance example. A scope correction is issued to all eligible participants Both parties can see what completion means.
Preserve the baseline and use the authorised change route when the need changes.
Run a consistency review
Begin the requirement with the agreement between specification, response schedule, evaluation, price and contract. Procurement language should reveal the need before it narrows the solution.
Competition becomes unclear when different documents define different deadlines and meanings.
Return to outcome and trace key terms end to end.
Need example. The same availability formula appears in requirements, evaluation and service schedule Suppliers can now understand the real problem.
Did You Know? Singapore's Ministry of Finance states that public procurement requirements, procedures and evaluation criteria are published on GeBIZ to support transparency and understandable competition. This is why the agreement between specification, response schedule, evaluation, price and contract needs a precise, dated record.
Keep a requirements ledger
Write the identifier, source, rationale, owner, evidence, test and status of each requirement as an atomic, controlled requirement.
Interpretations multiply when memory controls changes across a long procurement.
Use one identifier and maintain traceability through award and acceptance.
Specification example. A requirement's approved revision and affected test remain visible The statement can receive a comparable response.
Keep mandatory, desirable and optional language consistent across every schedule.
Pilot without hiding the decision
Ask for evidence about a limited trial used to reduce uncertainty before full commitment in a form the evaluator can compare fairly.
The evaluation drifts when a preferred supplier receives an informal advantage without a governed purpose.
Align response field, criterion and define pilot scope, evaluation and separation from award.
Evidence example. A sandbox trial tests integration assumptions under the same documented criteria for shortlisted suppliers The claim has a reviewable basis.
Stage expensive evidence where possible and do not request confidential material without a controlled need.
Check language across attachments
Connect the definitions and obligations repeated in diagrams, schedules and annexes with delivery, acceptance and operation.
Contract ambiguity appears when a diagram silently contradicts the written requirement.
Trace the requirement through test and review every attachment against the controlled glossary.
Acceptance example. The data-flow picture and interface schedule show the same direction, owner and retention boundary Both parties can see what completion means.
Preserve the baseline and use the authorised change route when the need changes.
Prepare the evaluation team
Begin the requirement with the shared interpretation and conflict controls used before scoring begins. Procurement language should reveal the need before it narrows the solution.
Competition becomes unclear when evaluators invent different meanings after reading bids.
Return to outcome and brief on criteria, evidence and recusal before access.
Need example. Reviewers score a sample response and resolve interpretation questions before opening live submissions Suppliers can now understand the real problem.
Record the requirement source and why it is proportionate.
Write for international suppliers
Write the plain definitions, dates, units and local context needed across markets as an atomic, controlled requirement.
Interpretations multiply when local shorthand and unexplained acronyms become hidden entry barriers.
Use one identifier and expand terms and use unambiguous formats.
Specification example. A response deadline states the time zone while measurements use named units and tolerances The statement can receive a comparable response.
Did You Know? Singapore's Ministry of Finance states that public procurement requirements, procedures and evaluation criteria are published on GeBIZ to support transparency and understandable competition. This is why the plain definitions, dates, units and local context needed across markets needs a precise, dated record.
A worked example
A team wants a new booking platform. Its first specification asks for a modern, intuitive, secure, scalable, world-class solution with good support. Suppliers interpret every adjective differently, price different scopes and submit offers that cannot be compared fairly.
The team restates the need, names user groups, volumes, integrations and accessibility contexts, separates mandatory from desirable requirements, defines response and availability measures, issues common evidence and pricing schedules, and traces requirement IDs into acceptance tests and transition duties.
English makes the procurement testable. Must sets obligation, under specified load bounds a performance claim, equivalent protects fair access, and acceptance defines proof. The specification creates a shared measuring instrument rather than a long wish list.
A practical checklist
- Business need and authority clear
- Users and contexts described
- Scope and exclusions explicit
- Mandatory and desirable separated
- Atomic requirements identified
- Performance measures bounded
- Security, privacy and accessibility included
- Supplier response evidence specified
- Evaluation and pricing aligned
- Acceptance tests traceable
- Transition and exit planned
- Change and risk ownership defined
Advice for students, parents and young adults
Students can practise specification writing by replacing one vague request—such as a good study app—with users, tasks, conditions, measures and evidence. The exercise strengthens technical writing and critical reading at the same time.
Parents and small organisations buying services can ask what is included, what is excluded, which claims are measurable, how personal data are handled and what happens at exit. Keep the request proportionate to the purchase.
A procurement specification does not replace the organisation's procurement rules, legal review, technical architecture, security assessment, data-protection work or authorised contract. Public-sector obligations and thresholds must be checked in their current official sources.
Frequently asked questions
What is the difference between a specification and a contract?
The specification describes required supply and evidence. The contract creates the binding agreement and usually incorporates or refers to the specification with other terms.
Should every requirement say must?
No. Reserve mandatory language for justified essentials. Mark desirable or optional elements so suppliers and evaluators can respond consistently.
Can a brand be named?
Sometimes compatibility or another legitimate need may justify it, but the reason and route for equivalent solutions should be considered under applicable procurement rules.
What makes a requirement testable?
It names an observable outcome, relevant conditions, a measure or expected behaviour, and the evidence or acceptance method.
Who writes the specification?
Usually a cross-functional team: service users, subject-matter experts, procurement, technical, security, privacy, accessibility, finance and legal roles as needed.
When does specification work end?
Not at publication. Requirements continue through clarification, evaluation, delivery, acceptance, change, operation and exit.
The deeper English lesson
Specification English is controlled-choice language. Definitions reduce ambiguity, modal verbs set obligations, numbers bound performance, response fields standardise evidence and traceability joins the original need to final acceptance. Precision supports innovation when it describes outcomes without unnecessary design lock-in.
Useful next reading
Continue with reading a tender notice, reading a purchase order, writing a business case, writing a vendor due-diligence questionnaire, and the How English Works.