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 requirements manager I want the traceability report to mention the GitHub location of each item which comes from a file inside a git repository (hosted on my company's GitHub Enterprise server), so that I can - map the traceability report to a commit SHA, and - easily navigate to the corresponding location.
The location shall include: - the full URL including the git commit SHA, - and the line number (if applicable).
Note: - The assumption is that, the repository will be checked out locally by the user or CI system, and the URL to the remote repository will be given as input to the LOBSTER tool suite. That is, the tool suite does not have to detect the commit SHA on its own. - The line number is optional, because otherwise it is impossible to represent files as a whole by a LOBSTER item.
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.
When an item in the input report has a Git commit identifier whose metadata is available, the generated HTML report shall display that identifier as the build reference and display the commit's committer timestamp queried from Git, converted to UTC.
Note: The committer timestamp records when this commit object was created and may differ from the author timestamp, which records when the changes were originally authored.
For every item in the input report whose source location is a GitHub reference, the generated HTML report shall render the source location as a hyperlink that opens in a new tab.
The hyperlink destination shall be "{gh_root}/blob/{commit}/{filename}" when no source line is provided, and "{gh_root}/blob/{commit}/{filename}#L{line}" when a source line is provided. The hyperlink text shall be "{filename}" when no source line is provided, and "{filename}:{line}" when a source line is provided.
IF the tool is invoked with an explicit input ".lobster" file THEN the tool shall generate the HTML report from that file. OTHERWISE the tool shall use a default "report.lobster" input file name.
IF the input data contains items with justifications, THEN the tool shall process the justifications correctly, AND shall display the content according to the justifications in the HTML report.
IF an item in the LOBSTER report has one or more findings or tracing messages, THEN the generated HTML file shall display those findings for that item.
IF the input .lobster file does not exist or is missing, THEN the tool shall exit with a non-zero return code (2) AND shall print an error message to STDERR indicating that the specified file is not a valid file.
IF a valid .lobster file is provided as input AND the command line argument "--out" is provided, THEN the tool shall write a valid HTML report to the specified output file.
IF the conditions of [[Valid_Lobster_File]] are given AND the command line argument "--render-md" is provided, THEN the tool shall interpret the text property of every LOBSTER item as Markdown and render it accordingly as HTML in the generated report.
IF a valid .lobster file containing a "custom_data" field THEN the tool shall extract these values from the file AND shall render them in the top-right corner of the generated HTML report.
If the input LOBSTER report file contains codebeamer items THEN the generated HTML report SHALL represent these as hyperlinks to the item on the codebeamer server, where the codebeamer server URL is taken from the repo_root configuration parameter.
If the input LOBSTER report file contains codebeamer items THEN the generated HTML report SHALL represent these by their codebeamer item name, if it is given.
The "to_html" method of the Codebeamer_Reference class SHALL return a string representation of an HTML anchor element to the codebeamer item by constructing the URL as follows:
"<repo_roo>/issue/<item_id><version_addon>"
where <repo_root> is taken from the configuration file, and <item_id> is the codebeamer item ID taken from the LOBSTER input file, and <version_addon> is "?version=<version>" IF the version number of the codebeamer item is given, OTHERWISE <version_addon> is an empty string.