NextGenSysML Part 9 – Requirements Requirements
This blog post presents the requirements for the modeling of requirements with SysMLv2. It is part of a blog post series about the upcoming new SysML v2 and SysML API & Services standard. The blog posts present the requirements for the standard stated in the request for proposals (RFP) published by the OMG. See the end of this post for a list of all posts of this series including a link to the first post of the series that provides an overall introduction.
Requirements are a crucial part of systems engineering, and SysML v1 adopted it for the systems modeling world. So, let’s see what is planned for the next generation of SysML for requirements.
Naturally, SysML v2 shall provide a model element to define a requirement. The requirement has an identifier with a user-defined number scheme, a textual requirement statement, and additional optional attributes status, priority, risk, author, and owner.
Many sources propose different sets of important requirement attributes. The attributes for the SysML v2 requirement are derived from the INCOSE handbook and ReqIF. Of course, it is possible to add your own specific attributes.
Although the requirements are part of the model, they are in most cases still defined by text. SysML v2 provides additional more formal capabilities to specify requirements. You can use a restricted requirement statement with predefined keywords and sentence structures. Better than just text, but still text-based.
Another option is a formal requirement statement that can include constraints or expressions to specify conditions that an acceptable solution must satisfy. This enables real model-based requirements.
With SysML v2 it is possible to annotate supporting information to requirements and requirement groups.
Requirements never come alone and you need capabilities to organize them. Besides a general container for model elements (see NextGenSysML Part 4), SysML v2 provides a requirement group element. There is a relationship between the group and its members that specifies the meaning of the membership. The requirements in the group can be ordered. Besides requirements, a group can also have other groups as members.
SysML v2 separates the definition and the usage of requirements as you know, for example, from blocks and parts (block definition and internal block diagram). A requirement can have different local usages, for example, to model different configurations of the system with localized values as part of the requirement.
Another capability to vary requirements is the requirement specialization, i.e., a generalization relationship from one requirement to another.
Talking about relationships: SysML v2 provides a some special requirement relationships:
- Satisty relationship between a requirement and a model element that satisfy it.
- Verify relationship between a verification case and the appropriate requirement.
- Derive relationship between a derived requirement and a source requirement.
An optional requirement for SysML v2 asks for logical operations between requirement relationships of same kind. For example, to specifiy that satisfy relationships from two architecture elements to a requirements means that both elements satisfy the requirement or only one. Partial satisfaction can also be specified. That is not possible with SysML v1, but SYSMOD closes the gap with some special stereotypes (weightedSatisfy).
SysML v2 provides the new concepts criteria, goal, and objective that are not part of SysML v1. A criteria provides the basis for an evaluation of a requirement, for example, that the mass of a component may be below a certain value. Requirements based on that criteria set the concrete mass value. Goals are similar and specifiy a direction like “minimizing mass”. Objectives describe a desired end state like the lightest system of its kind.
The next blog post covers the requirements about the capability of SysML v2 to model verification aspects. Stay tuned!
Previous blog posts of this series:
- NextGenSysML Part 0 – Next Generation Modeling: SysML v2 and SysML API & Services – Introduction
- NextGenSysML Part 1 – Overview SysML v2 and SysML API & Services RFP’s
- NextGenSysML Part 2 – The General OMG Requirements
- NextGenSysML Part 3 – Language Architecture and Formalism Requirements
- NextGenSysML Part 4 – Cross-cutting Requirements
- NextGenSysML Part 5 – Properties, Values & Expressions Requirements
- NextGenSysML Part 6 – Structure Requirements
- NextGenSysML Part 7 – Interface Requirements
- NextGenSysML Part 8 – Behavior Requirements
Planned future blogs posts:
- NextGenSysML Part 10 – Verification Requirements
- NextGenSysML Part 11 – Analysis Requirements
- NextGenSysML Part 12 – Example model and Conformance Requirements
- NextGenSysML Part 13 – SysML API & Services Overview
- NextGenSysML Part 14 – SysML API & Services: Architecture and Conformance Requirements
- NextGenSysML Part 15 – SysML API & Services: Service Requirements
