As a traceability manager I want the traceability report to list items that fulfill the tracing policy, and how they do so, so that I can decide whether to release my product.
Example: If the tracing policy is: Tests --(trace to)--> Requirements, then the report shall list all tests that link to at least one requirement, and the report shall list all linked requirements per test.
The use case applies to the reverse direction as well.
Issues:
missing reference to System Requirements
Build Reference: main | Timestamp: 2026-10-19 07:48:19+00:00 UTC
As a traceability manager I want the traceability report to list items that are not covered by other items, where coverage rules are specified by the tracing policy, so that I can identify gaps in the coverage.
Example: If the tracing policy is: Tests --(trace to)--> Requirements, then the report shall list all tests that do not link to any requirement.
The use case applies to the reverse direction as well.
Issues:
missing reference to System Requirements
Build Reference: main | Timestamp: 2026-10-19 07:48:19+00:00 UTC
As a traceability manager I want the traceability report to show the fraction of the number of items in one level (of the tracing policy) which fulfill the tracing policy, divided by the total number of items in that level (of the tracing policy). The fraction shall be shown as percentage.
Example: If the tracing policy is: Tests --(trace to)--> Requirements, then the report shall show the fraction of requirements which are covered by at least one test, divided by the total number of requirements.
As a CI administrator I want that the tool exits with a non-zero return code whenever it encounters invalid input so that the CI pipeline can catch invalid input automatically.
As a user of LOBSTER I want to have a good usability and standard command-line ergonomics, like built-in help or automatic creation of output destinations, so that using the tools is intuitive and seamless in scripts and interactive use.
IF the file given through the command line option "--config" does not exist, THEN the tool SHALL print an error message stating that the file is not an existing file to STDERR AND SHALL exit with a non-zero return code.
IF the config file does not contain the mandatory key "codebeamer_url", OR the optional key "output_file" is present but is not a string, OR the optional key "kind" is present but is not a string, OR "kind" is a string but is not one of "req", "act", "imp", THEN the tool SHALL print an error message identifying the violation to STDERR AND SHALL exit with a non-zero return code.
IF the config option "output_file" is given, THEN the tool SHALL write the generated LOBSTER items, in the LOBSTER interchange format, to that file. OTHERWISE the tool SHALL write them to "report.lobster".
The tool SHALL generate exactly one LOBSTER item per recognized test case found in the consumed input files, and SHALL exclude any test case whose documentation contains a "NOTRACING" annotation.
IF a test case's documentation contains one or more "@requirement" tags, given either in the "CB-#nnn" format or as a codebeamer HTTP URL, THEN the tool SHALL add a tracing target for each referenced requirement to the corresponding LOBSTER item.
OTHERWISE (a test case's documentation contains no "@requirement" tag) the tool SHALL still generate a LOBSTER item for that test case, without any tracing target.
IF the config option "files" is not given, THEN the tool SHALL use the current working directory as the sole input, applying the same directory-search rule as for an explicitly configured directory.
IF a list element given through the config option "files" is a directory, THEN the tool SHALL recursively search that directory AND SHALL treat every file found with one of the extensions ".cpp", ".cc", ".c", ".h" as an additional input file, ignoring any other file found there.
IF a list element given through the config option "files" is a file, THEN the tool SHALL process it as an input file, regardless of its file extension.
IF a list element given through the config option "files" is neither a file nor a directory, THEN the tool SHALL print an error message identifying the offending element to STDERR AND SHALL exit with a non-zero return code.
IF the resolved set of input files (after applying [[Input_Directory_Traversal]] and [[Explicit_File_Ignores_Extension]]) is empty, THEN the tool SHALL print an error message identifying the configured "files" option to STDERR AND SHALL exit with a non-zero return code.
The function get_test_file_list SHALL raise FileNotFoundError, identifying the offending entry, IF a file/directory list entry is neither an existing file nor an existing directory.
The function parse_config_file SHALL return a Config object with the fields codebeamer_url, kind, files, and output_file, populated from the config file or their default values.
The function parse_config_file SHALL raise KeyError, IF the config file does not contain the mandatory key "codebeamer_url". OTHERWISE, IF the optional key "output_file" or "kind" has an invalid type, or "kind" is not one of "req", "act", "imp", THEN the function SHALL raise ValueError.
The function get_test_file_list SHALL add a list entry that is a file directly to the returned list, without checking it against the given extension list.
The function run_lobster_cpptest, IF config.files names a single existing file, SHALL write a LOBSTER item for every recognized test case found in that file, using absolute file paths in the generated item locations.
The function run_lobster_cpptest, IF config.files names a single directory, SHALL write a LOBSTER item for every recognized test case found in that directory.
The function run_lobster_cpptest SHALL raise FileNotFoundError and SHALL NOT create an output file, IF a config.files entry is neither an existing file nor an existing directory.
The function run_lobster_cpptest SHALL write, for every recognized test case, a LOBSTER item that carries a tracing reference for every resolved requirement tag, OR, IF none could be resolved, a LOBSTER item without any tracing reference.
The function collect_test_cases_from_test_files SHALL return one TestCase per recognized test case, with its "requirements" list populated from the "@requirement" tags found in that test case's documentation.
The class TestCase SHALL recognize a test case at any line matching one of the supported test macros (TEST, TEST_P, TEST_F, TYPED_TEST, TYPED_TEST_P, TYPED_TEST_SUITE, TEST_P_INSTANCE, TEST_F_INSTANCE), SHALL extract its suite and test name, and SHALL determine the line range of its documentation comment and of its definition (up to the matching closing brace).
The class TestCase SHALL parse every "@requirement" tag in a test case's documentation, in either the "CB-#nnn" format or as a codebeamer HTTP URL, and SHALL accept multiple tags separated by commas, spaces, or newlines.
The class TestCase SHALL parse every "@requiredby" tag in a test case's documentation, matching the "scope::name" syntax, and SHALL accept multiple tags separated by commas or newlines.
The class TestCase SHALL parse the "@testmethods" tag of a test case's documentation, and SHALL silently drop any value that is not one of the supported test methods (TM_EQUIVALENCE, TM_PAIRWISE, TM_GUESSING, TM_BOUNDARY, TM_CONDITION, TM_REQUIREMENT, TM_TABLE).
The class TestCase SHALL parse the "@version" tag of a test case's documentation, and, IF fewer version values than requirement tags are given, SHALL pad the version list by repeating its last value, so that every requirement tag has a corresponding version value.