From CDP4-COMET to SysML v2: How to model requirements

The first thing to do when creating a system is to specify requirements, whether the system is physical or a representation of one (i.e. a model).

Requirements was the first thing to be digitalised after the age of document centric processes. IBM’s DOORS, for example, was created to move away from documents and manage requirements, and then became an industry standard. This kind of tool is very useful for requirements, but when the time comes to map the requirements onto physical elements of your system, it becomes a tedious job to verify each requirement and check their implementation in the system.

If you want to implement model-based system engineering (MBSE), the best approach is to integrate requirements first and the rest will follow. Here, we show you how to model the requirements with CDP4-COMET – specifically the web version, accessible at comet-web.cdp4.org/ – and in SysML v2.

Modelling requirements in CDP4-COMET

Starion’s CDP4-COMET has been specifically developed for concurrent design engineering. It’s therefore a good tool to use to communicate requirements to other stakeholders quickly and to verify the requirements faster in the early phases of a project.

As CDP4-COMET is based on ECSS-E-TM-10-25, its vocabulary is taken from ECSS (European Cooperation for Space Standardization) and therefore from the space domain.

Requirements are classified with the ‘Specification’ they belong to. A Specification is a document with a set of requirements that are relevant to a common subject. In the space domain, usually it is a mission requirements document (MRD), a system requirements document (SRD) or a user requirements document, but it can also be a reference document such as the International Telecommunication Union (ITU) regulations, or a launcher specification.

In CDP4-COMET Web, it can be represented as shown in the screenshot below:

Such documents are structured in chapters, and sub-chapters. In CDP4-COMET, we can represent them with Requirement Groups.

Category gives you a second, orthogonal axis. Where groups impose a single tree, categories can be applied freely and support super-categories, so the same requirement can be classified as functional and safety-related during the later implementation phase.

How do requirements connect to the design?

Requirements connect to the design either implicitly or explicitly.

Implicitly, through parameter types

A requirement’s Parametric Constraint and an Element Definition‘s Parameter refer to the same Parameter Type. Nothing further is needed for a value to be compared against a threshold.

For example, with respect to the requirement MRD10000 above, we have the following Parametric Constraint:

Afterwards, when you want to check if your parameter is verified, the rule verification engine (available in the CDP4-COMET desktop app) will check for identical Parameter Types in your model and check if the Parametric Constraint has been verified. In this way, we can demonstrate that our design is compliant with the requirements.

Explicitly, through relationships

ECSS-E-TM-10-25 provides a Binary Relationship (a source and a target `Thing`) and Multi Relationship (a set of related Things). These are generic: the data model does not define a “satisfies” relationship or a “derives from” relationship.

Instead:

1. You define a Category in the reference data library: “satisfies”, “derives from”, “refines”.
2. You apply that category to the relationship.
3. You define a Binary Relationship Rule in the library specifying which source categories may be related to which target categories under that relationship category, along with a forward and inverse relationship name.

This is more flexible than a fixed vocabulary but that also means more work. The semantics of your traceability are a project deliverable that someone has to author, review and place under configuration control. If two teams working in the same model invent “satisfies” and “is satisfied by” independently, the traceability matrix will have holes that no tool will report, because both relationships are valid.

Typically, you will then define:

• “satisfies” relationships, defining which components satisfies a requirement
• “is verified by” relationships, defining the verification scenarios that cover relationships
• “is derived from” relationships, linking requirements that are refining others.

Modelling requirements in SysML v2

SysML v2 is primarily a textual language, which is convenient for requirements management. Here, we show how to write a requirement, how to link it to the elements it constrains, how to organise requirements into a specification, and how to derive one requirement from another.

Defining the requirement

We will use SysML v2 textual language for defining requirements, and as we want to model a space system, let’s apply same structure as above for requirements, requirement specification, chapters, sub-chapters and requirements.

First, we define the requirement with requirement def keywords:

Note the two identifiers at work here: MRD10000, between angle brackets, is the short name, while MissionDuration is the readable name used inside the model. The doc comment carries the “must” statement verbatim, so the requirement text stays exactly as agreed with the stakeholders.

That defines only the human readable requirement. This is enough for documentation but not enough to have the model help you in your process: requirements are not linked yet with the elements of the model.

SysML v2 already gives you the syntax for linking the requirements, without having to redefine the relationships as in CDP4-COMET.

Let’s first add which part of the model is related to the requirement, and the associated mathematical constraint as well.

Three keywords are doing the work here.

• subject states what the requirement is about, so the constraint is no longer floating free
• attribute turns the “5 years” of the prose into a typed, quantity-bearing value a solver can read
• require constraint states the Boolean expression that must hold for the requirement to pass.

This is the direct equivalent of the Parametric Constraint in CDP4-COMET, except that the binding to the design is explicit in the text rather than implied from a shared Parameter Type.

Here, we defined the “requirement is satisfied by” relationship and the constraint to be verified, so that validators could pick up the constraint and check it automatically with parameters of the model.

Using the requirement definition

Sharpest eyes will notice this: we just defined the requirement but SysML v2 requires us to state the definition on one side and the part using the definition on the other side. Therefore, we need to use the definitions we created previously, scope the requirement, define the chapters and order the requirement with the requirement keyword:

The group is what gives the document its shape. Requirement group <MRD> MissionRequirements plays the role of the Specification, and each nested group plays the role of a chapter. Inside Chapter1_Programmatics, “duration : MissionDuration” is a usage of the definition, so the same definition can be reused in another chapter, another document or another project without being copied.

Derive requirements

Now, another main relationship in modelling is the requirement derivation. SysML v1 defined a deriveReqt, while CDP4-COMET let you define the relationship manually.

In SysML v2, we define derived requirements by defining a connection, which is defined in the RequirementDerivation package. Here we use the connection keyword:

The derivation is a model element, not an annotation on the side: use one #original end and as many #derive ends as the breakdown requires. Because #derivation comes from the standard library rather than from your own reference data, every conforming tool reads the link the same way (unless you redefined it). The same principle covers the rest of your traceability: verify for the link to test cases. We will cover them in a future post.

Conclusion

Both tools let you do the same requirement engineering work with (almost) the same capabilities:

• CDP4-COMET gives you a data model that is aligned with ECSS: Specifications, Requirement Groups and Categories map onto the documents your project has to deliver. This allows you to model faster and prepare mass budgets or power budgets faster. That also implies that all relationship definitions are contained in your model.
• SysML v2 also provides the possibility to model and verify requirements on your model. It provides the same capability as CDP4-COMET to define elements and then use them in your model, comes with a standard library to define requirement derivations and constraints, and gives the option to create relationships tailored to your project (which we did not cover in this post).

A CDP4-COMET data model is based on ECSS and intended for concurrent design (i.e. several engineers working on the same model). SysML v2 is the future language for supporting system engineering. That is why Starion is taking the best of both worlds and developing a SysML v2 modelling tool based on the CDP4-COMET platform: read more here.

Do you want to learn more?

If your team or organisation is interested in MBSE or would like to learn more about SysML v2 to implement it in your projects, sign up to our MBSE and SysML v2 newsletter. Now is the perfect time to start exploring SysML v2, test out new tools and define transition plans to adopt the new version in your modelling activities.

You can also reach out to our team for guidance and support on anything related to MBSE, SysML v2 and/or concurrent design.