Coverage
| Category | Ratio | Coverage | OK Items | Total Items |
| Use Cases | 80.0% | 8 | 10 | |
| System Requirements | 55.6% | 5 | 9 | |
| Software Requirements | 100.0% | 7 | 7 | |
| System Tests | 100.0% | 15 | 15 | |
| Software Tests | 100.0% | 3 | 3 |
| Category | Ratio | Coverage | OK Items | Total Items |
| Use Cases | 80.0% | 8 | 10 | |
| System Requirements | 55.6% | 5 | 9 | |
| Software Requirements | 100.0% | 7 | 7 | |
| System Tests | 100.0% | 15 | 15 | |
| Software Tests | 100.0% | 3 | 3 |
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.
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.
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 show the list of
requirements which are covered by tests.
As a requirements manager I want the traceability report to show the list of
requirements which are not covered by tests.
As a requirements manager I want the traceability report to show the list of
tests covering requirements.
As a requirements manager I want the traceability report to show the list of
tests which are not covering any requirement.
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.
As a requirements manager I want lobster-pkg to print a warning
for lobster-traces in <DESCRIPTION> and <VALUE> nodes
which are not extracted (due to wrong XML node or path properties).
IF an input file cannot be parsed as XML,
THEN the tool SHALL print an error message identifying the file and the parse
error to STDOUT
AND SHALL exit with a non-zero return code.
IF no input files or directories are given on the command line,
THEN the tool SHALL print an error message stating that no input files were
found to process
AND SHALL exit with a non-zero return code.
IF a command line argument is neither an existing file nor an existing
directory,
THEN the tool SHALL print an error message identifying the offending argument
to STDERR
AND SHALL exit with a non-zero return code.
IF the directory of the given output file path does not exist,
THEN the tool SHALL create it, including any missing parent directories,
before writing the output file.
The tool SHALL create a LOBSTER output item of type "Activity" for each input file
IF the file represents a test case, identified by having an <INFORMATION> node
containing a <TAGS> node with a <TAG> child node whose text is "TESTCASE"
(case-insensitive)
OR IF a lobster-trace is given in an ANALYSIS block
(details see [[Trace_in_Analysis_Node]]).
The following requirements describe how to fill the "refs" attribute of these
items.
Note: If no requirements is fulfilled, which describes how to fill the "refs" attribute,
then the item SHALL be created with an empty "refs" attribute.
Note: Pay attention to the difference between TESTSTEP and TESTSTEPS!
The tool SHALL extract all tags (marked by "lobster-trace") from <VALUE> nodes
from the specified input files
WHERE all of the following conditions apply:
- The file SHALL be a test case, identified by having an <INFORMATION> node
containing a <TAGS> node with a <TAG> child node whose text is "TESTCASE"
(case-insensitive).
- The <TESTSTEPS> node is of type "testCase".
- The <TESTSTEP> node is the first child node of a <TESTSTEPS> node.
- The <TESTSTEP> node is named "TsBlock".
- The <VALUE> node is nested inside a <TESTSTEP> node.
- The <VALUE> node contains one or more substrings in the format
"lobster-trace:<REQUIREMENT_ID>"
The tool SHALL extract all tags (marked by "lobster-trace") from <DESCRIPTION> nodes
from the specified input files
WHERE all of the following conditions apply:
- The <ANALYSISITEM> node is a **direct** child node of a <TRACE-ANALYSIS> node.
- The <ANALYSISITEM> node is of type "episode".
- The <DESCRIPTION> node is a **direct** child node of an <ANALYSISITEM> node.
- The <DESCRIPTION> node contains the substring in the format
"lobster-trace:<REQUIREMENT_ID>"
IF a "lobster-trace" tag is found in a <VALUE> node which does not satisfy the
nesting conditions of [[Trace_in_Test_Step_Node]],
THEN the tool SHALL print an error message identifying the file and the line
number(s) of the misplaced tag(s)
AND SHALL exit with a non-zero return code.
IF a "lobster-trace" tag is found in a <DESCRIPTION> node which does not satisfy
the nesting conditions of [[Trace_in_Analysis_Node]],
THEN the tool SHALL print a warning message to STDOUT identifying the file and
the misplaced tag
AND SHALL continue processing the remaining input.
Note: This requirement does not influence the tool return code.
The function "xml_parser" SHALL return one activity entry per
"lobster-trace:" substring found in a <VALUE> node located in an allowed
<TsBlock> (the first <TsBlock> under <TESTSTEPS>, or a <TsBlock> that is a
direct child of it), for a file identified as a test case.
The function "xml_parser" SHALL return an empty list,
IF the file is not identified as a test case,
OR IF no "lobster-trace:" substring is found in any allowed <VALUE> node.
The function "xml_parser" SHALL raise a LOBSTER_Exception whose message
names the file and the line number(s),
IF a "lobster-trace:" substring is found in a <VALUE> node that is not
located in an allowed <TsBlock>.
The function "extract_lobster_traces_from_trace_analysis" SHALL return one
trace entry for each <DESCRIPTION> node that is a direct child of an
<ANALYSISITEM> node of type "episode", which is itself a direct child of a
<TRACE-ANALYSIS> node, and that contains a "lobster-trace:" substring.
The function "extract_lobster_traces_from_trace_analysis" SHALL return one
misplaced-trace warning message for each <DESCRIPTION> node under a
<TRACE-ANALYSIS> node that contains a "lobster-trace:" substring but does
not satisfy the direct-child conditions of [[Trace_in_Analysis_Node]].
The function "create_raw_entry" SHALL update the "data" dictionary
with one Activity for the given file with framework "lobster-pkg" and kind "test",
AND SHALL add a tracing target for each requirement id parsed out of every
trace_list entry marked with activity "first".
The function "create_default_activity" SHALL create an Activity with
framework "lobster-pkg" and kind "test" for the given file,
IF the file is identified as a test case,
AND SHALL NOT create any entry otherwise.