Requirements

Tool Requirements

Requirements Rendering

UseCases.Render_All_TRLC_Records: 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: 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: 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: 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: 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: The safety_analysis rule shall render every FailureMode record of its failure_modes into the documentation output.

Root Cause Assessment

UseCases.Render_Root_Cause_Assessments: The safety_analysis rule shall render, for every root cause of its fault_trees, the ASIL, the rationale and the measures (name, kind and version) of the RootCauseAssessment that lists the root cause. It shall mark a root cause that no assessment lists as “Not assessed”, and a root cause whose assessment has no measure as “Not applicable”.

UseCases.Reject_Inconsistent_Assessment_Asil: The safety_analysis rule shall fail the build when the ASIL of a RootCauseAssessment is lower than the ASIL of a failure mode of one of its root causes, or higher than the ASIL of one of its measures, and the error message shall name the assessment and the failure mode or measure.

UseCases.Reject_Root_Cause_In_Multiple_Assessments: The safety_analysis rule shall fail the build when more than one RootCauseAssessment lists the same root cause, and the error message shall name the root cause and every assessment that lists it.

UseCases.Reject_Foreign_Assessment_References: The safety_analysis rule shall fail the build when a RootCauseAssessment lists a root cause that its fault_trees target does not generate, or a measure that is not an own record of a target in its safety_measures, and the error message shall name the assessment and the reference.

UseCases.Reject_Non_Assessment_Records: The safety_analysis rule shall fail the build when a file passed as assessments contains a record that is not a RootCauseAssessment, and the error message shall name the record.

UseCases.Cover_Root_Causes_And_AoUs_By_Assessment: The lobster traceability report of a dependable element shall require every root cause to be listed by a RootCauseAssessment, and every own assumption of use to be listed as a measure of one, so that the existing lobster-ci-report test fails otherwise.

UseCases.Pin_Assessed_Measure_Version: A RootCauseAssessment shall reference each of its measures with the version of the measure, and the lobster traceability report shall flag the reference as unresolved when the measure has another version.

Architecture Parsing

UseCases.Reject_Invalid_PlantUML: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: The tool shall extract requirement identifiers automatically from the TrlcProviderInfo provider of the requirements target attribute.

UseCases.Parse_GWT_Annotations: The tool shall read the requirement references, the given, when, and then parts, and the test-spec reference of every test case from the gtest.lobster file that lobster-gtest produces from the GTest XML result files. A test case without a given, when, or then part shall be included with an empty string for each missing part.

UseCases.Validate_Test_Specification: The test_specification rule shall fail the build for an RST file that does not consist of exactly one title section with a non-empty Test Goal section, an optional Test Focus section, and a Test Steps section with at least one step subsection. Each step shall consist of one field list with an optional Precondition and a non-empty Action and Expected field. Any other section, field, or text, and any RST warning or error, shall fail the build, independent of the maturity.

UseCases.Resolve_Test_Specification: For a test case with a test-spec reference, the tool shall look up the test_specification among the test_specs of the component’s units by the label as written in the unit’s test_specs, independent of canonical repository names. It shall use its test goal, test focus, and test steps instead of the given, when, and then parts, which shall be ignored with a warning. A reference that matches different test specifications shall not resolve.

UseCases.Enable_GWT_Derivation

The component rule shall pass the option

–derive-gwt-from-test-name to lobster-gtest when the resolved

lobster version provides that option, and shall omit it otherwise.

UseCases.Derive_GWT_From_Test_Name: With the option –derive-gwt-from-test-name, lobster-gtest shall derive the given, when, and then parts of a test case from its test name, if the name matches [<Prefix>_]Given<X>[_When<Y>]_(Expect|Then)<Z>. <Prefix> is alphanumeric, and <X>, <Y>, and <Z> are in CamelCase. Each derived part is its CamelCase text converted to lowercase words separated by spaces. A test case whose name has no When part shall have an empty when field. A test case that sets a non-blank given, when, or then RecordProperty shall take all three parts from its RecordProperty values only, and its name shall be ignored.

UseCases.Require_Given_And_Then: The tool shall report every linked test case without a test-spec reference whose given or then field is empty or blank as an error naming the requirement identifier, the test uid, and the missing fields. An empty when field shall not be reported. A test-spec reference that does not resolve to a test_specification shall be reported as an error naming the requirement identifier, the test uid, and the reference. The error shall fail the test action, and shall prevent the .update command from writing the lock file, unless check failures are allowed.

UseCases.Multi_Requirement_Linking: 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: 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 either the individual given, when, and then strings as separate fields, or, for a test case with a test specification, a spec field holding the label, test goal, test focus, and test steps (precondition, action, expected) of the test specification. An entry with both shall be rejected.

UseCases.Lock_File_Ordering: Test cases within a requirement entry shall be ordered lexicographically by uid to produce a deterministic, diff-friendly lock file.

UseCases.Update_Command: 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 or the referenced test specification, and overwrite the committed lock file.

UseCases.Test_Command_Verification: 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: 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.