Skip to main content

Having established the system domain and high-level objectives of our Electronic Voting System (EVS) in Part 1, the typical next step in systems engineering is requirements process in which we generate the requirements that the system must meet. A common pattern here is that requirements are managed in a specialized requirements management tool like Jama Connect and brought into the SysML model, either en masse or selectively, as part of the development process, so that we can relate those requirements to other aspects of the system.

EVS Requirement in Jama Connect

Figure 1 EVS Requirements in Jama Connect

A screenshot of the web interface to the Jama Connect repository where we have created a whole series of requirements is shown in Figure 1. Flash chain of custody, for example, talks about maintaining chain of custody of the flash memory cards used to transmit ballots or votes.

We want to bring all or some of the requirements hierarchy into the SysML model in a way in which, if the requirement changes later, either on the Jama or on the SysML side, we will be able to recognize the changes and reconcile the two versions so that model unity and consistency is maintained.

Syndeia Model Transform of system requirements from Jama Connect to MagicDraw SysML

Figure 2 Syndeia Model Transform of system requirements from Jama Connect to MagicDraw SysML

We’re going to do this with Syndeia as shown in Figure 2. From the Syndeia dashboard, we will take our Jama requirements hierarchy, shown on the right side, and drag and drop it into our SysML model shown on the left side. This involves a model transform connection, which may be customized to select the attributes that are carried over to the SysML model.

Requirements Table in MagicDraw SysML

Figure 3 Requirements Table in MagicDraw SysML

This not only created the requirements inside of MagicDraw, shown in Figure 3 in tabular form, but it also keeps them linked individually with the corresponding requirement back in the Jama database. When things change, the Syndeia user can detect those changes and even update in either direction if the engineering change process permits.

Within the MagicDraw model, these requirements may be decomposed and connected to the SysML model elements that satisfy them as the system design proceeds. In the next two posts, we will look at that system design with respect to hardware, software and operations in both the system architectural model and related models in specialized engineering domains.

Related Posts:

Tags:
Blog

Related Posts

Pipelines Part 3 – Matching Requirements to Parts using Syndeia Digital Pipelines

We’re continuing our blog series on using Syndeia digital pipelines to execute real world use cases in systems engineering. In Part 2, we demonstrated a digital pipeline that ...
Dirk Zwemer and Gregory Seeds

Pipelines Part 2 – Gap Analysis between Requirements and Tests

Demonstrating measurable ROI from digital engineering is just as important in driving enterprise adoption as customer mandates, e.g. DoDI 5000.97. In particular, the concept of ...
Dirk Zwemer and Gregory Seeds

Pipelines Part 1: Quick Introduction and Demo

Syndeia Pipelines automate digital engineering workflows by orchestrating complex, multi-step tasks, such as ETL operations, cross-repository queries, model transformations/syncs, ...
Manas Bajaj

Christmas at the North Pole, Powered by Pipelines🎄

While the rest of the world is busy hanging lights, doing last minute gift shopping, and sipping cocoa, the North Pole is deep in digital engineering mode. Snow is falling, elves ...
Manas Bajaj

What’s New in Syndeia 3.7? - Part 1

We are excited to release Syndeia 3.7, the next generation of our digital thread platform for integrated digital engineering. Check out the latest features in less than 5 minutes ...
Dirk Zwemer

Model-Based Systems Engineering for Autonomous Vehicles, Part 16 – Custom Dashboards

In Parts 1-10 of this blog series, we built a digital thread for an autonomous vehicle system to demonstrate how a federation of models in different software tools can become a ...
Dirk Zwemer

Model-Based Systems Engineering for Autonomous Vehicles, Part 15 – Digital Pipelines

In Part 14 of this series, we developed a custom script to calculate project metrics for our Autonomous Vehicle digital thread project. The value of this information is greatest ...
Dirk Zwemer

Model-Based Systems Engineering for Autonomous Vehicles, Part 14 – Open REST API

Syndeia has been developed as an API-first enterprise application, i.e. the full capabilities of the software are exposed through an open REST API with the understanding that the ...
Dirk Zwemer

Model-Based Systems Engineering for Autonomous Vehicles, Part 13 – Digital Reports

A key function of Digital Threads is to be able to answer questions about project status in real-time without the overhead of data collection, status reports and meetings. In this ...
Dirk Zwemer