This article provides an example of how to connect software component / unit test cases to SystemWeaver requirements and generate requirement coverage test reports and store them in a git repository. We also demonstrate here how you can look at the test report in SystemWeaver using a Git Integration extension view. In the example below, we are implementing a simple software component performing basic mathematical operations in Python. The same principle can be used in any build environment and some of the scripts can be reused. This principle also works for code to requirements coverage.

Tip: All files referenced in this article are provided as attachments at the bottom of the page.

The figure below describes the overall process from creating traceability to requirements to checking in test results. 


In a Python file called, we have created four test cases to verify four Design requirements for basic math operations (Addition, Subtraction., Multiplication, and Division) in Version 1 of the top-level "Math operations" component. 

We then made a Version 2 of the Software component in SystemWeaver and added two new requirements, removed one requirement and took a new version of another requirement:


The connection between the Python test cases and the requirements in SystemWeaver is made by referring to the SystemWeaver ID of the requirement in the following format:


At this point, we check in the code again, which triggers the build process in the Azure build machine as shown below. The build script (configuration of Azure is attached in azure-pipelines.yml) executes all test cases and generates a json file called converted_unit_test.json. 

As you might notice in the Azure configuration, the test results are initially exported to a file called unit_test.json and then transformed to converted_unit_test.json using the Python script to the standard SystemWeaver format.


Build Script in Azure

In the Git repository, we also define a file called config.json which points to the current software component ID in SystemWeaver (math operation (Version 2)). The config file also specifies the address of the SystemWeaver REST API server and credentials to log into the server. Another script in the build process ( uses this data to read requirements from SystemWeaver and generates a file called reqs.json. A last script ( then utilizes reqs.json and converted_unit_test.json to generate a pdf report which lists all requirements under the component and shows the traceability to the test cases on each requirement. It also presents the test results in a PDF file (testReport.pdf): 

  • Green indicates that the requirement under the component has been tested. 
  • Yellow indicates that a version of the requirement that is not under the current component has been tested. The developer should then check the updated requirement and make the necessary changes in the test script to update the reference to the correct version of the requirement.
  • Red indicates that the requirement that has been tested that is not in the scope of the component. The link should be removed from the test case or changed to a correct requirement ID.
  • White signifies that the requirement has no coverage on test side. A test method should be specified and linked to the requirement to assure full requirements test coverage.

Watch a Demo

The video below shows how to connect software component/unit test cases to SystemWeaver requirements and generate requirement coverage test reports and store them in a git repository.

This next video demonstrates how you can look at the test results in SystemWeaver using a Git Integration extension view.