MBSE for Electronic Voting System Security – Part 2 (Rhapsody and DOORS NG)

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 DOORS NG 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.

rhapsody-doors-ng-1

Figure 1 EVS Requirements in DOORS NG

A screenshot of the web interface to the DOORS NG 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 DOORS 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.

Figure 2 Syndeia Model Transform of system requirements from DOORS NG to Rhapsody SysML

We’re going to do this with Syndeia as shown in Figure 2. From the Syndeia dashboard, we will take our DOORS NG 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.

Figure 3 Requirements Table in Rhapsody SysML

This not only created the requirements inside of Rhapsody, shown in Figure 3 in tabular form, but it also keeps them linked individually with the corresponding requirement back in the DOORS NG 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 Rhapsody 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:

  • MBSE for Electronic Voting System Security (Rhapsody) – Part 1
  • MBSE for Electronic Voting System Security (Rhapsody) – Part 2 (this post)
  • MBSE for Electronic Voting System Security (Rhapsody) – Part 3 (coming soon)
  • MBSE for Electronic Voting System Security (Rhapsody) – Part 4 (coming soon)
  • MBSE for Electronic Voting System Security (Rhapsody) – Part 5 (coming soon)
Dirk Zwemer

Dirk Zwemer

Dr. Dirk Zwemer (dirk.zwemer@intercax.com) is President of Intercax LLC (Atlanta, GA), a supplier of MBE engineering software platforms like Syndeia and ParaMagic. He is an active teacher and consultant in the field and holds Level 4 Model Builder-Advanced certification as an OMG System Modeling Professional.