Author requirements

Requirements in STIG are typed model entities, not free-floating paragraphs. Each requirement has a stable Kotlin identity, a subject element, safety classification, and direct trace links. The same declaration drives IDEA navigation, model rules, traceability, and the generated report.

The requirement contract

Field	Meaning
Kotlin `val` name	Canonical model identity used by links; choose a stable engineering name.
`name`	Short human-readable title.
`description`	Precise normative statement using `shall`, `shall not`, `should`, `should not`, or `may`.
`verificationCriteria`	Acceptance decision: relevant stimulus, observable result, and required bounds or precise references.
`asil`	Explicit safety classification.
`element`	The element whose black-box behavior the requirement specifies.
`allocatedTo`	Direct child elements that realize the requirement.
`derivedFrom`	Parent requirements refined by this requirement.

Declare requirements as properties of a Requirements. A top-level container can also carry authors and DocumentMetadata; nested containers inherit that document context. Set the container's element explicitly, including on empty specifications. Each requirement's element must match its specification's subject.

Hierarchy boundaries belong to Element: isTopLevel=true removes the requirement for derivedFrom, and isBottomLevel=true removes the requirement for further allocatedTo entries. Both flags default to false. The former assumed fields are removed. Missing required attributes and references are HIGH findings.

The generated Highway model API lists the exact constructor types and required/defaulted parameters for this STIG version.

Example

class FusionRequirements : Requirements(
    element = fusionActivity,
    name = "Fusion requirements",
    description = "Black-box requirements for perception behavior.",
) {
    val reportStaleObservations = Requirement(
        name = "Report stale observations",
        description = "${fusionActivity.name} shall publish a degraded health state within 50 ms " +
            "after detecting an observation older than 100 ms.",
        asil = ASIL.B,
        element = fusionActivity,
        derivedFrom = listOf(aebRequirements.reportPerceptionDegradation),
        verificationCriteria = """
            Provide an observation older than 100 ms. Measure from detection of that observation.
            A degraded health state appears within 50 ms; an absent or later state change fails.
        """.trimIndent(),
    )
}

val fusionRequirements = FusionRequirements()

Use Kotlin references in descriptions when a display name must stay aligned with another model entity, and use typed fields such as element, derivedFrom, and allocatedTo for semantics. Do not encode traceability only in prose.

Verification criteria and migration

Supply non-blank verificationCriteria on every requirement, including QM requirements. The executable requirementVerificationCriteriaDefined rule reports a HIGH failure for a missing, empty, or whitespace-only value. The separate semantic adequacy rule reviews whether the criteria establish the correct acceptance decision. A present string does not prove adequacy.

Criteria can use test, analysis, inspection, or demonstration and can reference an identified definition or limit. They do not require a test case to exist yet. Text in a description, note, or linked test does not fill the Kotlin field; TestCase.verifies links evidence and does not prove that verification succeeded.

The nullable constructor default supports draft authoring and preserves existing source calls. Existing requirements without criteria now acquire the HIGH presence finding and may fail stigCheckModel at the configured threshold. Supply the actual engineering criteria when migrating; do not insert placeholder acceptance text. The parameter is appended to preserve source parameter order, but the constructor's binary signature changes: recompile model consumers.

Write a useful requirement

State one observable obligation at the subject element's boundary.
Use one accepted normative modal.
Make the trigger, output, limits, and timing measurable rather than using placeholders or subjective terms.
Set ASIL from the engineering classification and keep it compatible with the subject and parent requirements.
Link every derived requirement to its real parents; declare an upper model boundary with element.isTopLevel.
Allocate a parent-level requirement only to direct children that realize it.
Define an acceptance decision in the requirement's verification criteria.

The maximum ASIL across an element's requirements must not exceed its asil. If the element also declares allocatedAsil, that value must equal the maximum when at least one requirement is present, all requirement ASILs are known, and the complete requirement set is available. This comparison includes all specification containers for the subject element. Empty or unclassified requirement sets do not establish a QM classification.

Every element in a requirement's allocatedTo list must contain a requirement referencing it through derivedFrom. This coverage check follows every explicit allocation, including one that independently violates a hierarchy rule. Coverage is collective across the allocated element's requirements specifications and their nested sections. If no derivation exists, each top-level Requirements specification receives the finding. Sections do not receive it. When no specification exists, the allocated element receives the finding. Requirements allocated to no elements create no coverage obligations; the missing-allocation rule checks that condition separately.

The complete-project check also discovers missing coverage when the allocated element has no own Gradle module. This checks trace coverage; implementation and verification are checked separately. A different element deriving from the allocated requirement does not satisfy the intended element's obligation.

Module checks and IDEA inspections discover these obligations by loading the complete parent model through the module dependency graph, including parent requirements that the child has not referenced. See Model-check context.

STIG checks mechanically decidable obligations and prepares semantic review work for engineering judgment. The generated model-rule catalog lists the current rule IDs, decision methods, scopes, contracts, and remediation. It distinguishes the limited executable predicates from semantic obligations such as feasibility or external consistency.

Check and review

# One element
./gradlew :path:to:element:stigCheckModel

# Complete project
./gradlew stigCheckModel

# Opt-in review checklist for this viewpoint
./gradlew :path:to:element:stigCheckModel --viewpoints requirements --checks manual

# Review rendered traceability
./gradlew :path:to:element:stigGenerateHtml

IDEA creates live inspections for executable rules, including criteria presence, and offers their existing fixes. Semantic rule help identifies work for a human or AI; ordinary inspections do not invoke an AI service. Gradle loads the compiled model and runs the same inventory rules.

Automatic checks run by default. Manual/all modes distinguish confirmed violations (FAIL) from pending semantic judgment (REVIEW). Null, empty, and whitespace-only descriptions or criteria produce automatic presence findings; the corresponding semantic request waits until the required text exists. Other unavailable engineering evidence stays unresolved in the review. Failure to load required context is an execution error. Model thresholds require a FAIL at or above failAt; pending work does not fail an INFO threshold. Summaries retain unselected and uninvoked rules rather than counting them as passed. A successful build establishes the executed checks' predicates, while the semantic work still needs assessment.

The module overview's Model Checking Summary links to the full results for each viewpoint on that page. Scope results remain available even when a viewpoint has no Kotlin package or model entities to document.

Requirement obsolescence and element operating-mode modeling remain deferred. Current review can interpret explicit textual conditions but cannot establish complete lifecycle or mode coverage.

Ask `$stig:specification`

For a read-only review:

Use $stig:specification to review the requirements in <module path>. Use the current rule
catalog and model-check evidence, assess verification criteria, and follow
derivedFrom and allocatedTo links. Cite declarations and distinguish established
findings from missing evidence and pending judgment. Do not edit the model.

The same skill reviews Markdown specifications using explicit requirement IDs or document anchors. Criteria can be associated prose or table cells; Kotlin syntax is unnecessary. The review records logical ownership, comparison scope, and missing evidence, including when one specification spans files or one file contains requirements and tests. It applies the same engineering contracts without claiming that Kotlin reflection or package checks ran on Markdown.

For an edit, state the intended engineering change explicitly:

Use $stig:specification to rework <requirement or container> so it expresses <intended
behavior>. Preserve valid trace links, explain every semantic change, then run
the affected model checks. Do not invent missing engineering decisions.

23 October 2026