Specification Gap
Requirements cover what the system should do but omit how it behaves, connects, migrates, and hands over.
Requirements documentation covers what the system should do but omits how it should behave, how it connects, how data gets in, and how it hands over. The vendor fills these gaps with assumptions that favour the vendor's commercial position.
Recognition signals
- Requirements document is a feature list with no NFR section. Performance, availability, security, and scalability are implied but never specified.
- Integration described as "must integrate with system X" with no detail. No protocol, no frequency, no error handling, no interface specification.
- No data migration plan. Legacy data is mentioned in scope but nobody has defined what moves, what transforms, what validates, and what gets left behind.
- No transition requirements. The specification describes the future state but not the path from current state — cutover, parallel running, rollback, BAU handover.
- Change requests in the first six months trace back to spec gaps. The vendor isn't gold-plating — they're charging for work that should have been in scope from the start.
Structural cause
Why this happens
Functional requirements come from business users who know what they want the system to do. Non-functional, integration, migration, and transition requirements require technical and commercial expertise that isn't in the room during requirements workshops. Nobody asks the questions that weren't asked.
Requirements workshops are populated by people who use the current system and want a better one. They can describe the features they need. What they can't describe — because it's outside their domain — is performance under load, integration protocol design, data migration complexity, or transition logistics. These domains require specialists who typically sit in enterprise architecture, infrastructure, or operations. If those specialists aren't in the room, their domains don't appear in the specification.
The vendor sees the gaps and makes a commercial calculation. They can flag the missing domains and help the customer build a complete specification — which takes time, delays the contract, and might raise the price. Or they can bid on what's specified, knowing that the missing domains will surface as change requests during delivery. The second option wins more bids.
Risk mapping
| Risk | Description |
|---|---|
| P1 | Specification domain gaps — requirements missing entire domains (NFR, integration, migration, transition) |
| CO1 | Leverage gap — vendor fills specification gaps with assumptions that favour their position |
| G3 | Structure gap — requirements process doesn't cover all necessary domains |
| V3 | Visibility gap — missing domains invisible until delivery pressure reveals them |
Self-assessment
When to worry
- Requirements document has no non-functional requirements section
- Integration requirements say "must integrate" without protocol, frequency, or error handling detail
- No data migration acceptance criteria — just "data will be migrated"
- No transition or BAU handover requirements in the specification
When you're OK
- Requirements structured across six domains: functional, NFR, integration, migration, transition, records management
- Technical specialists participated in requirements workshops
- Each requirement has testable acceptance criteria
Related reading
- Integration Blind Spot — the specific case where integration falls between organisational boundaries
- Acceptance Drift — vague specifications make acceptance testing subjective and deferrable
- Why integration governance fails — integration as the first domain to expose specification gaps
Variations in the first six months almost always trace back to requirements that should have been in the original specification.
A specification review identifies missing domains before the RFP goes out — when fixing gaps costs time, not money. 10fifteen — programme governance assessments.