In the DOORS database, we can see a project and some modules. We will use the Verification Requirements module and Verification Tests module in DOORS for this demonstration. Objects under the verification requirements will sync to vManager as sections or subsections, and test cases and metric ports attached in vManager linked with the sections or subsections will synchronize back as objects inside the verification test module.

In the Verification Requirements module, we have predefined requirements. We can see a hierarchy of the requirements here, along with their respective attributes like priority, status, heading, short text, etc. The verification test module is currently empty in vManager. Currently, V Plan is also empty, as requirements from DOORS haven’t synchronized yet as sections or subsections.

Now, we will start with synchronizing the verification requirements. OpsHub will preserve the history of DOORS requirements while syncing them to vManager as sections. The OpsHub admin is activating the requirement synchronization. All the objects from the Verification Requirements module in DOORS will synchronize to vManager as sections and subsections, preserving all the attributes and hierarchy. In vManager, the verification engineer refreshes the page and views the four sections and subsections that have been created.

All attributes for each section and subsection, like the title, description, status, priority (mapped as severity), remote ID of the DOORS object in the custom field, and the remote link to navigate to the DOORS object, have successfully synchronized from DOORS to vManager, maintaining the hierarchy. In DOORS, a field is called an attribute. We can see the linked ID of the section from vManager. In all the objects, the value is set, helping users achieve better traceability when navigating to vManager.

Navigating to vManager, the verification engineer now starts adding test cases. Under the first test case, they add a name, description, test execution status, and severity. Similarly, another test case is added. Here, we can see the section and subsection levels with a red flag, whereas the test cases added do not reflect the red flag. This is because the test cases were last updated on vManager. To clear the flag, follow the steps as shown in the video. The flags are no longer visible, indicating that the value has been read and accepted by the verification team.

The verification engineer now goes ahead and adds metrics to the test cases. In DOORS, the project manager opens the verification test module to view the synchronized test cases from vManager with an out link to the requirement. We can see the test cases have been linked to the Verification Requirements module. Under each verification item, we can see the heading, description as short text, and all synchronized attributes like priority and status.

After reviewing the vManager test cases as verification items in DOORS, the project manager makes changes to the short text and then the status for the first test case, adjusting the specs for the tests to be performed. They then change the short text for the second test case. In both test cases, we can see the object text consisting of links attached to V Plan. Here, we can see the link to the Verification Test module in the Verification Requirements module in vManager. The verification engineer refreshes the page to view the changes made to the test cases in DOORS.

At this point, the verification engineer, as per protocol, goes to the regression center, runs the regression. Once the regression is complete and the coverage output is available in the regression center, it is synced and integrated into the planning center. In this demo, we are using pre-calculated coverage output for the metric port attached. Therefore, we will directly fetch the coverage outputs like grade average, past runs, and fail runs. To do so, the verification engineer clicks on Grade Analysis. This button enables OpsHub to show the pre-calculated coverage output.

Once the values are available at the planning center, the verification engineer fetches them from V Plan or its database to the attribute level. By clicking on Sync, we can see the values have been updated. OpsHub, via a CUDA script, allows the roll-up of results from the test case to a section or subsection level. Therefore, the results are identical at the Gluco Monitoring Machine level, which is the parent requirement. We can see the average result of both the test cases. This result is rolled up to the Health Monitoring Device section.

Navigating to DOORS to see similar outputs, the project manager enters the Verification Test module and clicks on the Low Blood Sugar Verification Test. Here, we can see four failed runs, two past runs, and the average grade is 33%. Based on this, the project manager changes the status of the test case to “Failed”. For the second test case, since the average grade is 100%, with zero failed runs and six past runs, the project manager changes the status to “Completed”.

Let’s take a look at the rolled-up results at the Requirements object level. Under High Blood Sugar Range Verification, we can see a 100% grade average, six past runs, and zero failed runs. Under Low Blood Sugar Range Verification, we can see a 33% grade average, four failed runs, and two past runs. The average rolled-up result at the parent requirement level is 66.66%, with four failed runs and eight pass runs. The same result is rolled up at the Health Monitoring Device 2.0 level. The project manager has now changed the status of the requirement to “Closed”.

Navigating to vManager, while the requirement update is syncing, the verification engineer refreshes the page to view the updates made to the test cases in DOORS. The test for High Blood Sugar Notification Verification is marked as “Passed”, whereas the test for Low Blood Sugar Notification is marked as “Failed”. The verification engineer refreshes the vManager page one last time to view the updated status of the requirement. The status change made to the requirement in DOORS has successfully synchronized and is reflected as “Resolved”.

That completes the demo. Thank you for watching.