Skip to content
KSTL-1 · Uncrewed aircraft

Kestrel-1 Survey UAV

A fixed-wing survey UAV, seeded as a worked example: eight requirements, six components, four suppliers and four verifications, wired into a traceability graph, with a real ELANG system_model and an inline Technical Data Package.

A requirements traceability table in DjiniousEngineering: requirements derived from needs, allocated to components, sourced from suppliers and closed by verification activities, each row showing its evidence class and validation state.A requirements traceability table in DjiniousEngineering: requirements derived from needs, allocated to components, sourced from suppliers and closed by verification activities, each row showing its evidence class and validation state.
The whole chain closed as graph edges, not a slide: derive, allocate, source, verify — with an evidence class on every row.Worked example · Fixed-wing survey platform
—
ledger items
11
lifecycle stages
5
steps on the path
2
standards applied
STANDARDS

What this class is held to

The recipe for this system class encodes its standards as tracked obligations, so the design is proven against them rather than tested against them at the end.

  • NASA SE Handbook Rev.2
  • EASA UAS 2019/947
THE MISSION NEED

The smallest complete thread — every edge closed

Kestrel-1 exists to show the whole chain closed on a small system: eight requirements derived from the need, allocated onto six components, sourced from four suppliers, and each closed by one of four verification activities. It is the example to read when you want to see needs → requirements → components → suppliers → verification as actual graph edges rather than a diagram of one.

THE PATH

UAV recipe over the baseline lifecycle

Take a survey UAV from need to a released baseline and Technical Data Package, with a verification activity standing behind every requirement.

  1. 01Derive eight singular requirements from the mission need
  2. 02Allocate each requirement onto a component in the architecture
  3. 03Source the six components from four qualified suppliers
  4. 04Close every requirement with a verification activity of sufficient evidence class
  5. 05Author the ELANG system_model and freeze the Technical Data Package

Worked example

THE GATE

SRR — System Requirements Review

The first gate: the requirement baseline has to hold before any design proceeds.

  • Every requirement is singular and verifiable
  • A verification method is assigned to each requirement
  • The initial hazard list exists
  • Every requirement derives from a stated need

Nothing closes a requirement on JUDGMENT when its verification method demands MEASURED — the evidence class is enforced, not advisory.

IN THE PLATFORM

On the canvas

An ELANG system_model open in the DjiniousEngineering editor, with its conformance level and gap list beside it.An ELANG system_model open in the DjiniousEngineering editor, with its conformance level and gap list beside it.
A real ELANG model backs the example — four pillars, checked against twenty-six well-formedness rules.
The documents view in DjiniousEngineering, listing the generated deliverables and the Technical Data Package folder.The documents view in DjiniousEngineering, listing the generated deliverables and the Technical Data Package folder.
The release artifact: a Technical Data Package generated from the validated thread, not typed up beside it.
MORE CASES

Bring a uncrewed aircraft system you actually build.

We will frame the need, derive the requirements, stand up the ELANG model and walk a review gate with you on the call.

Book a demo