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 FMEA rule shall render every FailureMode record from the
input TRLC sources 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.
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.
- 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 that does not exist in the set of received AoUs, preventing silent misconfiguration.
- 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.