Requirements gap analysis: catch holes before engineering does

A gap analysis is a deliberate hunt for what your requirements don't say. It matters because of a well-documented economics of software: studies put 60–80% of development cost into rework, and effective requirements management can eliminate 50–80% of project defects. The cheapest place to find a missing requirement is in a document, where fixing it costs minutes. The most expensive is in production, where it costs an incident.

Where gaps hide

Run the requirements through a checklist of categories, because gaps cluster in predictable places:

• Happy path completeness — does the main flow actually work end to end, with no missing step?
• Edge cases — empty states, maximums, concurrent actions, the unusual-but-valid inputs.
• Error handling — what happens when something fails? Most requirements describe success and go silent on failure.
• Non-functional requirements — performance, security, accessibility, scale. These get assumed and then violated.
• Dependencies — what does this rely on, and what relies on it?
• Permissions and roles — who can do what? Often unstated until a security review.

Find conflicts, not just gaps

A gap is a missing requirement; a conflict is two requirements that can't both be true. "Users can edit their email freely" and "email changes require admin approval" can't coexist — one has to give. Conflicts are more dangerous than gaps because each one looks fine in isolation; you only catch them by reading requirements against each other. When you find one, resolve it explicitly and write down which requirement won and why, so it doesn't silently reappear.

Make it a loop

Gap analysis isn't one pass. When you patch a gap, the fix can introduce a new one — a resolved conflict changes a flow, which exposes a fresh edge case. Re-analyze the patched requirements rather than assuming the first pass cleaned everything. The goal is a set of requirements where the obvious holes are closed before a single line of code depends on them.