Requirements Library · Known gaps

What this corpus does not cover

A requirements practice that cannot find its own gaps is not working. Everything below was surfaced by the practice’s own instruments — structural checks, composition tests, and reviews by an instance that did not author the work.

None of this was found by an outside reader, because there has not been one. That is precisely why it is published here, at the same weight as everything else in the library rather than in a footnote.

These are stated at a level that avoids operational detail. The full analysis of each is available on request. Where a gap is disclosed in the corpus itself, the status line says so; where this review is the first record of it, the status line says that instead. The difference between the two is the more interesting fact, and a uniform status column would have flattened it.

1. Adversarial security is effectively absent

This is the largest gap in the corpus and the least defensible. The requirements set is rigorous about accidental failure and close to silent about deliberate failure. There is no threat model anywhere in the corpus.

  • No spoofing analysis. One rule treats a position arriving over an untrusted carrier as unknown, which handles an untrusted channel. It does not handle a forged position arriving over a trusted one — precisely the case that would make a real crew invisible or an empty area appear occupied. The rule’s own logic, in which visibility unblocks an action, is the attack surface.
  • No denial or interference analysis. The corpus specifies graceful behaviour under loss of connectivity in considerable depth. Nothing addresses induced loss, and the availability requirement as written would report a deliberate attack as bad weather.
  • No satellite-positioning denial or spoofing analysis. Every coordinate, every geographic exclusion check and the entire lost-link procedure depend on position, and the corpus does not address the case where position is wrong on purpose.
  • No false-signal analysis. A safety rule requires the system to yield reflexively on any indication of a particular hazard, treating ambiguity as confirmation. This is correct as safety engineering and is also a cheap, permanent denial of service against the whole fleet.
Status

Open. This requires a threat model as a first-class artifact, and several existing rules will need amendment once it exists rather than adjustment afterwards.

2. The suppression half of the system is specified but not designed

Requirements exist for what suppression must do — what must be true before a release, who authorises it, what the system must refuse. No design artifact specifies how. No interface contract terminates at the suppression airframe. Release mechanics, the refill handshake, the footprint model and the interlock are all out of scope of every design artifact in the corpus, each of which says so explicitly in its own out-of-scope section.

  • This is disclosed in the corpus rather than hidden, and it is deferred to a design session that has not run.
  • It remains the gap that matters most: it sits underneath what the programme is actually for, and it rests on two assumptions the corpus itself names as programme-ending if wrong.
Status

Deferred, dated, owned. Honest, and still absent.

3. Fleet readiness and maintenance has a role and no requirements

The role catalogue names a maintenance and readiness role. The data model carries airworthiness state and a grounding relationship. An interface contract for grounding exists. There is no need record, no non-functional requirement, no journey, no screen and no acceptance criterion for any of it.

  • The contract’s behaviour had to be derived from a system invariant, because there was no requirement to derive it from — which is how the gap was found.
  • Battery lifecycle, spares and consumable logistics are named repeatedly across the corpus as cost drivers and are specified nowhere.
Status

Open, logged by the corpus’s own composition test.

4. There is no verification or test artifact

Every rule and every non-functional requirement carries a section describing how it is verified. Collectively those sections reference a flight test campaign, a release qualification campaign, drop testing, human-in-the-loop simulation, exercise periods and adversarial testing. None of those is specified anywhere. The qualification programme for the release interlock is named as the longest-lead item in the programme and has no artifact at all.

  • This is the gap that most directly undercuts the corpus’s own claims. Under the library’s own standard, a check that has not been observed refusing a disqualified input does not count as present — and no check in this corpus has been observed at all, because nothing has been built.
  • The worked example states this about itself at §8 and §10 rather than letting the specification’s confidence stand in for evidence.
Status

Open. A whole missing artifact class, not a thin one.

5. The registries the programme depends on are unspecified

Several capabilities are gated on reference data the programme does not own and in at least one case must help create. The corpus specifies the lookup against those registries in contract-level detail and explicitly states that the registry itself is a separate build with its own requirements. Those requirements do not exist. The same is true of two other pre-survey and authorisation programmes, each of which gates a whole capability.

  • A related and narrower finding: the corpus solved the problem of stale reference data once — a geographic exclusion layer that disables its capability when its validity lapses — and did not generalise the solution to the layer that determines who is responsible for the ground. That layer has no expiry model and no accountable owner.
Status

Open. Named as high-value work in the plan; unspecified in the corpus.

6. Training, qualification and currency are entirely silent

The design creates four new operational roles, two of them derived from a regulatory framework that has not been finalised. Nothing in the corpus specifies how any of them is trained, qualified, kept current or evaluated. One need record names a training role among its stakeholders; no artifact serves that role.

  • For a programme whose central business case is expressed as a human supervision ratio, the absence of any training or qualification artifact is conspicuous.
  • It is the clearest instance in the corpus of a transition requirement going unspecified — the class BABOK 2.3 separates out precisely because it is the one people forget.
Status

Open, and undisclosed until this review.

7. Gaps in the practice’s own measurement

Distinct from the six above, and stated because a goals page carrying six measures and no data would otherwise read as though the measurement existed.

That last one is an invitation. The only real test of whether this practice finds its own gaps is what an outside reader finds that this page does not name. If you find one, that is the most useful thing you could send back — the contact page reaches the author directly, and no request form stands in front of it.