Requirements Classification: What OK, OKB, NOK, OKM and R Really Mean

Introduction

In August 2024, the VBB awarded the Berlin S-Bahn contract worth more than EUR 1.5 billion. The specifications contained thousands of individual requirements, from crash standards and climate zones to accessibility. For every single item, each bidder had to make a statement: Can we meet it? Under what conditions? With what evidence?

That statement is classification. It sounds like a simple column in Excel, but it is the foundation of every bid response. Classify too optimistically? That leads to renegotiations. Too broadly? In the worst case, exclusion from the procurement procedure. The ESA procurement guidelines put it plainly: discrepancies between compliance statements and the actual bid lead to downgrades. The same principle applies in public procurement law for the rail industry.

Yet classification is treated as an afterthought in many companies: a column filled in under time pressure. This article explains the 5-level model in detail, places it in the context of international standards, and shows the most common mistakes along with specific countermeasures.

Where classification sits in the bid process

Classification does not happen in a vacuum. It sits precisely between requirements analysis and the bid response. The VDB requirements management guide describes a structured process in which classification connects the specification and the design specification. The result is a compliance matrix: a tabular comparison of each requirement with the bidder's response.

The 5-level model at a glance

The international standard for tender compliance recognizes three levels: Compliant, Partially Compliant, and Non-Compliant, as defined by the ESA in its procurement guidelines. In industrial practice, particularly in rail and vehicle engineering, a more differentiated 5-level model has become established. It provides more information and enables more precise communication with the client.

The model adds three intermediate levels to the binary Compliant/Non-Compliant distinction, covering by far the largest share of requirements in practice. Reality is rarely black and white: a vehicle that "almost" meets a requirement needs a different response from one that cannot meet it at all.

OK: Fully achievable

The requirement can be met without restriction. It sounds simple, but it requires the strongest evidence: a specific source document must exist that proves compliance. The INCOSE Guide to Writing Requirements identifies verifiability as a core characteristic of every requirement. The same applies to the response. An OK without evidence is worthless.

The evidence follows the four verification methods defined by both ISO/IEC/IEEE 29148 and CENELEC EN 50126 : test (physical examination), analysis (calculation or simulation), inspection (visual examination), and demonstration (functional evidence). The method that applies to each requirement must be set out in the verification plan from the outset.

OKB: Achievable subject to a condition

The requirement is fundamentally achievable, but under certain conditions that the client must accept or enable. OKB is often the most interesting category because it shows that the provider has genuinely engaged with the requirement and gives an honest assessment instead of assigning a blanket OK.

The condition must be formulated concretely and measurably. "Under certain circumstances" is not an acceptable OKB condition. The EuroSpec Requirements Management Specification requires traceability and testability for every requirements response. For OKB, that means the condition itself must be a verifiable statement.

NOK: Not achievable

The requirement cannot be met. That is not failure, but honest communication. The real mistake lies elsewhere: leaving an NOK as a dead end. Experienced bid teams add a deviation analysis to every NOK. What exactly is the difference? Is there a technical alternative? What would the trade-off be?

In the context of TSI requirements an NOK is particularly sensitive: failure to meet TSI requirements must be documented as a formal deviation and can jeopardize vehicle approval by the Notified Body (NoBo). "It cannot be done" is not enough here. The deviation analysis must identify the regulatory consequences.

OKM: Achievable with modification

The requirement can be met, but changes to the design, configuration, or process are needed. The difference from OKB is that the modification lies with the provider, not the client. That costs time and money, and both must be communicated transparently.

For OKM, ISO/TS 22163 (IRIS) plays a role: the IRIS standard requires structured change processes. Every modification must be documented and traceable in configuration management. An OKM response without an effort estimate leaves the client in the dark about the overall cost.

R: Clarification required

The requirement cannot be assessed conclusively because information is missing. R is not an avoidance category. It signals to the client: the requirement is unclear or incompletely formulated. The INCOSE requirements quality criteria list unambiguity and completeness as fundamental prerequisites of good requirements. If both are missing, R is the only responsible answer.

The clarification request must be specific: Which information is missing? What would enable the assessment? Experienced teams often formulate R responses as a conditional classification: "For climate zone T1, the response would be OK; for T2, it would be OKB subject to the following condition…" This shows the client that the technical work has already been done.

Classification and verification: the IADT methods

Every classification needs a verification method. Both CENELEC EN 50126 (RAMS for railway applications) and ISO/IEC/IEEE 29148 define four methods, known as the IADT methods. The chosen method determines both the effort required and the evidential strength of an OK classification.

The methods are arranged hierarchically. Test has the greatest evidential strength, inspection the least. In practice, this means:

• Test: Physical examination under defined conditions. For safety-critical requirements (crashworthiness EN 15227, fire protection EN 45545), it is often the only accepted method. An OK backed by a test is incontestable.
• Analysis: Calculation, FEM simulation, or statistical evaluation. Used when physical testing would be disproportionately costly, for example for service-life evidence through RAMS analyses under EN 50126.
• Demonstration: Functional evidence under real or realistic conditions. Typical for software requirements and passenger information systems.
• Inspection: Visual or documentary examination. Suitable for dimensions, material markings, and configuration features. It is insufficient for performance characteristics.

Typical classification distribution

What does a realistic distribution look like in a rail bid? It naturally varies by product maturity and fit with the tender. But experienced bid managers recognize typical patterns. A bid with 95% OK is either a perfect fit or it was not classified carefully. Usually, it is the latter.

This is a typical pattern for a bid based on an existing vehicle concept that is being adapted for a new market. For new developments, the distribution shifts towards OKM. For tenders tailored to an existing product, OK dominates.

The number of NOKs is less decisive than the quality of the deviation analyses. Five percent NOK with convincing alternatives beats zero percent NOK with sloppy classification that exposes inconsistencies in the technical evaluation.

Common classification mistakes

Most classification mistakes are not technical mistakes. They are systematic biases: time pressure, poor alignment, wishful thinking. And they are expensive. In bid evaluation technical compliance checks take place before commercial evaluation. Non-compliant bids are eliminated, no matter how good the price is.

Mistake 1: An overly optimistic OK

Mistake 2: OKB without a clear condition

Mistake 3: NOK without an alternative

Mistake 4: Missing source reference

Mistake 5: Cross-subsystem inconsistency

Why source references are not optional

A source reference is the proof that a classification is robust. No more, no less. The ISO/IEC/IEEE 29148 defines a traceability link for every requirement: from the source requirement (specification), through the solution description (design specification), to the verification evidence (test report, analysis, inspection). This chain must be unbroken.

In the context of CENELEC EN 50129 this chain becomes the safety case: a structured document that demonstrates a system's safety to an independent assessor (ISA). Classification is at the start of this chain. If the source reference is missing there, the entire evidence trail collapses.

This is what a professional classification process looks like in practice, illustrated here with the example of Tendric, from the requirement and source comparison through to the generated response:

The compliance matrix in practice

The compliance matrix is the document in which all classifications come together. The Association of Proposal Management Professionals (APMP) defines it as a tabular comparison of every RFP requirement with the corresponding response, including a reference to the relevant bid section. In the rail industry, this structure is supplemented by the specific features of the VDB guide : standard references, verification methods, and supplier assignment.

A professional compliance matrix in the rail industry contains at least the following fields for every requirement:

1. Requirement ID (unique reference from the specification)
2. Requirement text (the client's original wording)
3. Binding level (mandatory / desired / option)
4. Classification (OK / OKB / NOK / OKM / R)
5. Comment (condition, modification, deviation, or clarification request)
6. Source document (test report, data sheet, approval)
7. Verification method (test / analysis / demonstration / inspection)
8. Responsible department (EN 15380 subsystem)
9. Design specification reference (section in the bid document)

ReqIF and tool-supported data exchange

Classification in Excel works. Until it no longer does. Once there are a few hundred requirements, a tool-supported workflow is worthwhile. The Requirements Interchange Format (ReqIF) is an open XML-based standard for exchanging requirements between different requirements-management tools. Whether the client and bidder use IBM DOORS, Siemens Polarion or another tool does not matter.

The VDB guide "Data exchange in requirements management" expressly recommends ReqIF for the bid and clarification phase. Specifically, it delivers:

• Changes are automatically flagged when new specification revisions arrive. No more manual reconciliation between document versions.
• Links between requirements, classifications, and evidence documents are retained during data exchange.
• All changes remain traceable in an audit-proof manner, which is directly relevant to review by NoBo and DeBo.
• Classification, verification method, and source reference are transferred as separate fields, not as free text in an Excel cell.

How AI supports classification

Manual classification has a problem: consistency. When dozens of experts assess requirements independently, different standards emerge. Expert A classifies a requirement as OK, Expert B classifies the same one as OKB. Not because either is wrong, but because they have different knowledge of the internal document base.

AI can help at several points:

• Automatically searching for test reports, approval documents, and manufacturer data sheets that fit a requirement
• Identifying TSI, DIN EN, ISO, and CENELEC references in requirement text, including checking whether the referenced standard version is still current
• Comparing classifications across subsystems to find contradictions (for example, when one team assesses an axle load as OK while another rates a dependent requirement as NOK)
• Suggesting classifications based on previous bids, including suitable source documents and verification methods
• Similarity search across previous projects whose classifications serve as references

According to the Loopio 2025 RFP Response Trends Report 68% of proposal teams across industries use generative AI, twice as many as in 2023. Seventy percent of them use AI at least weekly. The average RFP win rate is 45%. Teams with structured processes perform better.

The rail industry remains more cautious here than other industries. But pressure is increasing: according to the UNIFE World Rail Market Study 2024 the global rail market reached EUR 201.8 billion, with around 3% annual growth through 2029. As volume and complexity rise, the question will not be whether AI is used in classification, but when.

Best practices for bid managers

Whether you work with Excel, IBM DOORS, Siemens Polarion or a specialized platform such as Tendric : the following principles always apply. They are based on the recommendations of the VDB guide, the EuroSpec specification and the INCOSE quality criteria for requirements.

1. No OK without a source document. If no evidence exists, it is not OK. The verification method (IADT) is part of it.
2. Every OKB needs a measurable condition. Specific, testable, documented. The condition itself must be verifiable.
3. Every NOK needs an alternative. Quantify the deviation and offer technical alternatives.
4. Every OKM needs an effort estimate. The cost and timeline of the modification belong in the response. The change-management process under ISO/TS 22163 provides the structure.
5. Every R needs a specific clarification request. Not "unclear," but: exactly which information is missing? Where possible, include a conditional classification.
6. Check consistency across subsystems. The EN 15380-5 System Breakdown Structure provides the framework. Dependencies between departments must be checked explicitly.
7. Create a classification guide before the project begins. What do OK, OKB, and OKM mean in this specific project? Include examples.
8. Plan review loops. Apply the four-eyes principle at minimum for critical classifications. For safety-critical requirements: independent review under EN 50129.
9. Do not postpone verification planning. The verification method is set during classification, not only in the project phase.
10. ReqIF instead of Excel versions. The VDB guide expressly recommends tool-supported exchange for the bid and clarification phase.

Conclusion

No one becomes a bid manager because they are passionate about classifying requirements. But classification determines which commitments a company makes and which risks it takes. A structured, source-based process with clear definitions for each category separates professional bid responses from ones cobbled together under time pressure.

The 5-level model provides more precision than the binary distinction between Compliant and Non-Compliant. Platforms such as Tendric model this approach natively. Combined with source references under ISO/IEC/IEEE 29148, verification methods under EN 50126 and specific conditions for every deviation, a mandatory exercise becomes a tool that wins tenders.