In Part 1 of this series, we connected individual requirements in DOORS NG to requirements and other elements in SysML. Greater challenges arise when we need to map requirement structure and organization between tools, because different tools organize requirements in significantly different ways.

SysML tends to organize requirements in simple tree hierarchies using containment relationships. Each requirement has only a single owner, which may be another requirement, and the tree may have as many levels as desired. Dependency relationships, e.g. <<deriveReqt>> may be used to cut across the tree, adding dimensionality to the structure.

DOORS NG offers two vehicles for organizing requirements, Collections and Modules, in addition to its folder structure. Syndeia handles each, in different ways, but with the same goal of making connections for structural comparison and synchronization.

In DOORS NG, a Collection contains a flat list of requirements, i.e. a Collection cannot contain other Collections. Such a Collection is shown in the DOORS NG web interface in Figure 1, containing seven requirements.

Figure 1: DOORS NG web interface opened to Requirement Collection cUAV_Specification

Using the Syndeia Dashboard, Connection Manager tab, as shown in Figure 2, we can drag and drop the collection, REQ-004956_cUAV Specification, on the right, into the SysML package on the left, using the Model Transform connection type. Model Transform connections bring over the structure as well as the content of the elements.

Note that each requirement appears twice in the DOORS NG browser shown in Figure 2, once by itself and once as part of a collection. The same requirement can belong to many collections in DOORS NG, which is not generally allowed in SysML.

Figure 2: Syndeia Dashboard showing an empty SysML package on left, DOORS NG repository on right

After the Model Transform operation is complete, we can show the new SysML requirement structure in a Requirement Diagram (Figure 3). The DOORS NG collection has been mapped to a SysML requirement, but with a different applied stereotype, <<DOORS-NG_Requirement_Collection>>.

As with individual requirements, as shown in Part 1, we could do the same thing, starting from SysML. The SysML and DOORS NG requirement pairs remain linked through Syndeia for comparison and synchronization in either direction.

Figure 3: SysML Requirement structure after Model Transform connection through Syndeia

Requirement Modules in DOORS NG can have multilevel structures of any depth, unlike Collections. However, DOORS NG treats them internally very differently, which affects what Syndeia is able to do.

Figure 4: DOORS NG web interface opened to Requirement Module UAV Requirement Module

Figure 4 shows the UAV Requirement Module in the DOORS NG web interface. The module, ID 1783, contains a top-level requirement, ID 1779, with two other requirements, IDs 1781 and 1780, below it, and a fourth requirement, ID 1782, below 1780. Using the Syndeia Model Transform connection, we can drag the module in one operation into SysML and show this structure in a diagram, as in Figure 5. All SysML elements are requirements, but the top level has the applied stereotype <<DOORS-NG_Module>>. As with collections, the connected DOORS NG and SysML requirements can be compared and updated. However, Syndeia cannot use a structure like Figure 5 to generate a Module in DOORS NG in reverse because of limitations in the current DOORS NG APIs.

Figure 5: SysML Requirement structure after Model Transform connection through Syndeia

Being able to work with Collections and Modules in connecting these tools has a sometimes-overlooked advantage. When a project has thousands of requirements, creating connections individually can be time-consuming and tedious. Creating a large set of connections in one operation is often the most efficient approach. Users can select which specific requirements and sub-structures they want to bring over to SysML. 

In Part 1, we demonstrated Syndeia's ability to connect to DOORS NG, browse requirements and other artifacts, and create connections between existing SysML elements and DOORS NG artifacts. In Part 2 (this post), we have demonstrated Syndeia's ability to generate requirements in SysML from DOORS NG (and vice versa). In Part 3, we will demonstrate Syndeia's ability to track versions of connected DOORS NG requirements, compare, and synchronize in both directions.

Related articles:

• Video introduction to Syndeia DOORS NG interface
• Syndeia with DOORS NG, Part 1
• Syndeia with DOORS NG, Part 2 (this post)

Contact us at info@intercax.com to get a Syndeia trial license and try out the DOORS NG interface.