Topics / Engineering practice
Specification conformance needs more than matching words.
To assess conformance, identify the authoritative requirement, the implementation behavior and the evidence that connects them for the reviewed revision.
Choose the specification with authority.
A ticket, generated description and approved requirement can disagree. Resolve which behavior governs the change before declaring an implementation conformant. Retain the decision and the superseded wording.
Illustrative example
The prose says “full-line comments.” The model says “comments.”
A parser accepts comments on their own line but loses entries when a comment follows data. The two descriptions imply different obligations. A passing full-line test cannot settle the inline case. Resolve the intended grammar, then test the agreed behavior.
Use several kinds of evidence honestly.
| Evidence | What it contributes |
|---|---|
| Requirement-to-code link | A recorded implementation relationship |
| Semantic review | A reasoned assessment of behavior against intent |
| Executed scenario | An observation under identified conditions |
| Formal result | A property under the stated model and assumptions |
A link or a review stamp is not execution evidence. A test result does not establish untested behavior. Combine the methods needed for the consequence of the claim.
Make conformance survive the next edit.
Proof retains the requirement, implementation links and verification context. When relevant wording or code changes, review which conclusions need renewed evidence. Do not update the specification solely to make an unexplained implementation pass.
For a first check, choose one disputed behavior. A narrow, reproducible comparison is more useful than a broad claim that the repository “matches the spec.”
Try it on your software
Bring a requirement whose implementation is disputed.
We can trace the competing interpretations and identify the observation that would resolve them.