Intercax - Blog

MBSE for Urban Systems – Part 2.1 | Managing Requirements

Written by Dirk Zwemer | Jan 31, 2019

Effective systems development begins with a
clear set of objectives, captured as requirements. In terms of building a
model, we must consider several different types of requirements:

  • Model Architecture requirements – which urban systems should be part of the model
  • Model Simulation requirements – which performance factors should be calculated
  • Urban System requirements – what levels of performance should be achieved


Figure 1 Architectural Modeling Requirements for Utilities Subsystem (DOORS NG)

We show examples of architectural requirements in Figure 1 and simulation requirements in Figure 2. The third category is outside the scope of this TechNote and may be dependent on the specific urban community being investigated.


Figure 2 Simulation Modeling Requirements for Water Services (Jama Connect)

Because our modeling effort is assumed to be collaborative, we must be ready to accommodate a range of modeling tools and repositories. For purposes of illustration, we assume that the architectural requirements have been captured in IBM Rational DOORS NG and the simulation requirements in Jama Connect, two different requirements management tools widely used for requirements generation and version-management. However, we also need to link these requirements both to each other and to other system model elements, in order to provide traceability and data access across tool and domain boundaries. For this purpose, we use Syndeia, the MBSE interoperability platform from Intercax. Syndeia enables the modeler to build, maintain and analyze a network of connections across multiple engineering software models, creating a practical Total System Model (TSM) by federation of individual domain models.

MBSE allows for multiple approaches to making these connections. With Syndeia, we classify these connections as Model Transform or Reference:

  • Model Transform – We can take
    elements or sets of elements in one model and transform them into equivalent
    elements in another, bringing across attributes and internal structure as
    needed. Because the elements remain connected, the elements may be compared and
    updated as one or both ends of the connection change over time.


Figure 3 SysML dependencies between architectural and simulation modeling requirements (Cameo)

In Figure 3, we show how this might work in our system. The simulation requirements on the left, transformed from Jama Connect into Cameo System Modeler are linked to the architectural requirements on the right, transformed from DOORS NG into Cameo through the standard SysML <<deriveReqt>> dependency.

  • Reference – alternatively, we
    could have used Syndeia to create reference connections directly from requirements
    in DOORS NG to requirements in Jama. This would also have provided
    traceability, enabling users of one tool to access related elements in another
    or to recognize when a new version of the connected element has been committed.

MBSE and Syndeia accommodate both approaches. The Reference connection obviates the need for a third tool and updating of shared data. Model Transform makes explicit the overall architecture of the TSM and uses a standard library of artifact and relationship types, which can enhance cross-discipline communication.  As we will see, both approaches can be used in a complementary fashion in the same project. Model transforms will be used to connect Cameo, DOORS NG, Jama Connect and Simulink, while Reference connections will tie elements in these tools to JIRA issues for collaborative project management.

In the next post, we will decompose our urban systems structure in SysML and relate it to our model requirements. In this and the following posts in the series, we will provide alternative versions for SysML modeling in Rhapsody. Both SysML models will be made available for download with the final installment of the series.

Related Posts:
View full post