# How do we write requirements we can test, and accept delivery on evidence? Tamir Khason · Updated 2026-10-07 Write each requirement with the test that would pass or fail it, and score bids on demonstrations with your own data. Accept delivery on tests you can reproduce, and tie payment to them. If you can't say how you would check a requirement, expect to argue about it later. ## Write requirements a test can fail Replace each feature requirement with the task it serves and how you will know it worked. "User-friendly" can't fail a test. "A clerk opens a case and attaches a document" can, with stated test data and pass criteria. Requirements copied from one product sheet get challenged and draw one serious bid. Describe the outcome, the data, the acceptance tests and the exit terms, and let bidders propose how. If bidders read the scope differently, resolve it through the permitted clarification process before award. ## Score on evidence, then accept on evidence Score a demonstration on your own sample data, with frozen inputs, published criteria and any supplier help recorded. Measurable quality criteria survive a challenge better. A minimum quality threshold keeps a weak bid from winning on price alone. At delivery, treat the supplier's test results as evidence that still needs a challenge. Run the tests in a clean environment, with real data and local conditions such as heat, and record every result. Accept with a signed defect list attached, rather than a bare signature. ## Depending on your seat If you're on the board and management asks to release further investment, ask who chose and witnessed the acceptance tests. Map the results to the investment's essential operating assumptions, and ask for an independent challenge where the evidence comes only from the supplier. If you run the business or IT and a late supplier wants to skip a test, keep the test for the core and let only low-risk parts move. Put the cost of any delay it causes on the supplier, in writing. If the contract names no acceptance tests, write them now from the requirements and add them to every remaining milestone. ## What to check before you decide - Next to each requirement, write the acceptance test, the test data and the pass criteria. - Ask procurement counsel to read the draft for terms that only one product can meet. - Define a demonstration on your own sample data, with frozen inputs and criteria published in the tender. - Give every bidder the same workload and conditions, and record any supplier help during the test. - Tie payments to acceptance tests a third party could run and reproduce. - Require documented interfaces and full data export, so you can switch suppliers later. - Accept each phase with a classified defect list the supplier signs, and read the warranty terms with counsel first. ## Questions people ask ### Can the board rely on charger acceptance evidence supplied only by the integrator? Treat supplier tests as evidence that still needs an appropriate challenge. Reliance depends on test coverage, reproducibility, unresolved exceptions, and who independently confirms the operating claims. ### Our control system vendor is late and wants to skip the factory test to meet the turnaround, should I allow it? Skipping the factory test moves the discovery of problems to the most expensive place there is. Allow it only for parts that can be tested on site without risk to the schedule, and keep the test for the core logic, with the vendor carrying the cost of delay it causes. It depends on which parts are late and on whether a reduced scope could go in this turnaround. ### Should we delay our tender when bidders interpret the scope differently? Resolve material interpretation differences through the permitted procurement process. The decision depends on whether bidders are pricing the same service and whether clarification would alter the competition. ### How do I write AI tender requirements for a government system that don't describe a single vendor's product? Write the outcome, the data, the acceptance tests and the exit terms, and let bidders propose how. Score on a demonstration against your own sample data rather than on feature lists. It depends on what your procurement rules allow for demonstrations and on how well you can describe the decision the system supports. ### Last tender went to the lowest bidder who is failing, how do I write the next tender so quality counts? Shift scoring toward evidence the bidder cannot write freely, such as demonstrations on your data, named staff with verifiable history and milestone-based payment. Keep price important and make quality measurable so the scoring survives a challenge. It depends on what weighting your procurement rules allow and on how well you can define acceptance. ### Vendor delivered a phase and our contract has no acceptance tests, how do we accept without losing our rights? Write the acceptance tests now from the requirements, run them with the vendor present and record results, because a documented test gives you a position the signature alone does not. Agree the criteria for later phases before the next milestone. It depends on how clear the requirements are and on how the contract treats defects found after signature. ### Chargers accepted on paper underperform in the field, how do we handle the supplier and fix acceptance for the next lot? Measure the shortfall on site with a defined test, because a claim needs numbers and the next acceptance needs the same test. Make field acceptance under local conditions, including heat, a condition for the second lot. It depends on what the tender specified as the acceptance basis and on what the warranty covers. ### What evidence should we require before accepting battery optimisation software? Acceptance must cover feasible operation as well as simulated value. Required tests depend on the battery limits, available measurements, and who can override a dispatch decision. ### How should we compare cloud bids with different workload assumptions? Compare bids against one documented workload and service boundary. A valid ranking depends on included services, usage assumptions, exclusions, and the consequences of exceeding them. ### How can we make tender proof-of-concept scoring reproducible across bidders? Define common inputs, permitted assistance, and observable scoring before testing. Procurement owners should confirm how consistent conditions and clarifications fit the tender process. ### Should we accept outsourced software when its test results cannot be reproduced? Treat the test claim as incomplete until an authorised team can reproduce it. The next step depends on missing dependencies, environment assumptions, and whether the tests cover acceptance requirements. ## How I can help with this decision - **Ask or talk (Free):** I give my view on which requirements in your draft can't be tested or point at one vendor, and what acceptance must contain. - **Review (Pay if it was worth it):** I write an independent review of the requirements, scoring and acceptance terms, or of a delivery against them. I recommend what to change before publication, or whether to accept, accept with conditions or hold further payment. - **Retain (When it makes sense):** I stay close through evaluation and delivery to review demonstrations and acceptance results against the criteria you published. ## Ask me about your case I'll reply personally within two working days with an initial view. [Ask me about your case](https://1pf.co.il/en/#q=We're%20writing%20a%20tender%20for%20a%20new%20system.%20How%20do%20we%20set%20requirements%20we%20can%20test%2C%20and%20accept%20delivery%20on%20evidence%3F&field=government&src=guide) · [Book 45 minutes](https://1pf.co.il/book/) --- [Decision guides](https://1pf.co.il/en/guides/) · [Home](https://1pf.co.il/en/index.md)