Requirements

Tool Requirements

Requirements Rendering

UseCases.Render_All_TRLC_Records

Description:: The trlc_rst renderer shall produce an RST output that contains

every requirement record present in the input TRLC source files.

UseCases.Resolve_Derived_From_References

Description:: The rendered RST output shall contain working cross-references

for all derived_from fields, linking child requirements to their parent requirements.

Requirement Validation

UseCases.Validate_Traceability_Completeness

Description:: The build shall fail when a component requirement does not have

a derived_from reference to at least one feature requirement, unless the requirement is explicitly marked as component-internal.

UseCases.Emit_Correct_Provider_Info

Description:: The score_requirements_rule shall emit a TrlcProviderInfo

provider containing all own TRLC source files, the specification RSL files, and all transitive dependency TRLC files.

UseCases.Emit_Sphinx_Sources

Description:: The score_requirements_rule shall emit a SphinxSourcesInfo

provider containing the rendered RST file and all transitive Sphinx source dependencies.

Safety Analysis Rendering

UseCases.Render_All_Failure_Modes

Description:: The safety_analysis rule shall render every FailureMode record of

its failure_modes into the documentation output.

Architecture Parsing

UseCases.Reject_Invalid_PlantUML

Description:: The PlantUML parser shall exit with a non-zero return code when

the input diagram contains syntactical errors, preventing silent production of incorrect output.

Lobster Traceability

UseCases.Extract_Lobster_From_Requirements

Description:: The requirements rule shall extract a lobster traceability file

from all TRLC requirement records using the configured lobster extraction schema.

RST Requirements

UseCases.Reject_Incomplete_RST_AoU

Description:: The RST requirements converter shall exit with a non-zero

return code, name the offending assumption of use, and write no output when an assumption of use directive has no root_causes field or a root cause that is not of the form <fta_package>.<RootCause>.

AoU Forwarding

UseCases.Forward_Own_AoUs_To_Dependees

Description:: The dependable_element rule shall automatically include lobster

traceability entries for all assumptions of use defined by its direct dependencies in the dependee’s traceability report as a “Received AoUs” tier.

UseCases.Chain_Forward_Received_AoUs

Description:: The dependable_element rule shall support an aou_forwarding

attribute pointing to a YAML file that selects which received AoUs are forwarded further to elements that depend on this element. Each entry in the YAML shall require a mandatory justification field and the version of the AoU it forwards, so that a justification is reviewed again when the AoU changes.

UseCases.Reject_Unknown_AoU_In_Forwarding_YAML

Description:: The AoU forwarding tool shall exit with a non-zero return code

when the forwarding YAML references an AoU identifier, or an AoU version, that does not exist in the set of received AoUs, or lists an AoU identifier more than once, preventing silent misconfiguration.

UseCases.Derive_Own_AoUs_From_Safety_Analysis

Description:: The dependable_element rule shall derive the assumptions of

use it exposes to its dependees from the assumptions_of_use targets that the safety_analysis targets of its dependability_analysis consume as safety_measures, and shall provide no other source of own assumptions of use. An assumption of use shall be exposed once, however many safety analyses consume it.

UseCases.Receive_Duplicate_AoU_Once

Description:: The dependable_element rule shall list an assumption of use in

its “Received AoUs” tier once, when it reaches the element along several paths with identical content, such as through a direct dependency and through a dependency that forwards it.

UseCases.Reject_Conflicting_AoU_Definitions

Description:: The dependable_element rule shall fail the build when an

assumption of use reaches the element along several paths with different content, such as in different versions, and the error message shall name the assumption of use and the differing fields.

UseCases.Cover_Received_AoU_Via_Component_Requirement

Description:: The CompReq requirement type’s derived_from field

(CompReqSourceId) shall accept versioned, typed cross-module TRLC references to AoU records alongside its usual FeatReq/ AssumedSystemReq references. Resolving an AoU reference shall require the defining assumptions_of_use target to be listed directly in the CompReq target’s deps. The dependable_element rule shall convert such references to lobster trace references resolved against the “Received AoUs” tier, so a component requirement can cover a received AoU it handles locally without requiring that AoU to be chain-forwarded.

UseCases.Include_Forwarded_AoUs_In_Traceability

Description:: The lobster traceability report of a dependable element shall

require every item in its “Received AoUs” tier to be covered by at least one of: a component requirement (via derived_from) or a chain-forwarding entry (via aou_forwarding), so that the existing lobster-ci-report test fails when a received AoU is neither handled nor forwarded.

Test Case Coverage

UseCases.Lock_File_As_Spec_And_Approval

Description:: The tool shall use one YAML lock file as both the declaration of

which requirements are claimed to be completely covered and as the committed approval artifact.

UseCases.Requirement_IDs_From_TRLC

Description:: The tool shall extract requirement identifiers automatically from

the TrlcProviderInfo provider of the requirements target attribute.

UseCases.Parse_GWT_Annotations

Description:: The tool shall parse GTest XML result files, extracting

RecordProperty values for the keys lobster-tracing, given, when, and then on a per-TEST, per-TEST_F, and per-TEST_P basis. A test case without a given, when, or then property shall be included with an empty string for each missing field.

UseCases.Multi_Requirement_Linking

Description:: A test case that carries lobster-tracing values matching more than

one requirement identifier shall appear in the lock file entry of every matched requirement.

UseCases.Lock_File_Content

Description:: The lock file shall contain, per requirement: the requirement

identifier and an ordered list of linked test cases. Each test case entry shall contain: a uid in the format “//bazel_package/SuiteName:TestName” (package-scoped gtest tag) and the individual given, when, and then strings as separate fields.

UseCases.Lock_File_Ordering

Description:: Test cases within a requirement entry shall be ordered

lexicographically by uid to produce a deterministic, diff-friendly lock file.

UseCases.Update_Command

Description:: The .update Bazel run target shall extract requirement identifiers

from the TrlcProviderInfo target, parse GTest XML result files for lobster-tracing-linked test cases, build the spec from given/when/then, and overwrite the committed lock file.

UseCases.Test_Command_Verification

Description:: The Bazel test target shall parse GTest XML result files, rebuild

the spec for each linked test, and compare uid and spec against the committed lock file, failing if they differ. On failure it shall print a human-readable diff showing which test cases changed and the exact bazel run command needed to refresh the lock file.

UseCases.LOBSTER_Covered_Attribute

Description:: The test target shall emit a lobster-act-trace JSON artifact that

marks each linked test case as “ok” when its uid exists in the committed lock file and its spec matches, and “fail” otherwise.