When should I use requirement composition vs specialization vs #derivation?

Syside
1

Hi all,
I’m learning SysML v2 requirements and I’m confused about the difference between:

  • composition (subrequirements) (i.e., requirements nested/owned inside another requirement)

  • specialization (i.e., specializes)

  • derivation using the library #derivation connection

Coming from Codebeamer / DOORS, I used to think “downstream/upstream” links were basically interchangeable, but now I realize SysML v2 may attach stronger semantics depending on the relationship.

What I’m trying to model

I have a typical multi-level requirement structure:

  1. 1 System-level requirement (vehicle/system)

  2. 4–5 Subsystem requirements that explain what the sub-system-level requirements should be..

  3. ~20 Software requirements that capture detailed “nitty-gritty” behavior, interfaces, timing, edge cases, diagnostics, etc.

Questions

  1. In SysML v2, which of these should be used?

  2. When is #derivation connection recommended vs discouraged?
    Is it mainly a traceability relationship (like SysML v1 deriveReqt)?

Any guidance / best practices appreciated — especially how you’d map this to what DOORS/Codebeamer users call upstream/downstream links.

2

Hello Abhishek,

This is indeed a very good question. Requirements in SysML v2 are more complex than in v1 (and DOORS), and they are essentially structured constraints integrated with the design models. Of course, it is up to the modeler how many of the capabilities they use.

Generally speaking, downstream links are best realized by specialization and decomposition. Let’s assume that you follow a refinement-based approach like OOSEM, where lower-level design models specialize higher-level ones (typically redefining features and/or decomposing them into subcomponents). In this case, the requirement hierarchy can reflect the same or a similar specialization/decomposition tree. Note that this doesn’t necessarily mean your requirements are bound to the design - quite the opposite, they guide the design.

For example, when you have a high-level requirement that you want to split/decompose into smaller parts, you can specialize it and decompose it into subrequirements. The specialization captures the design decision to split the requirement in a certain way, and the decomposition captures the way it is split. Or, when you have a set of high-level requirements (possibly in a hierarchy) describing the problem domain, and you commit to a solution, you can model the downstream connections again with specialization: the solution-specific requirements will specialize the high-level requirements, usually redefining or introducing typed subjects, and concretizing some parameters by binding them to features of the solution model. From there, you can continue by specializing and decomposing the solution-level requirements as before.

Of course, these are only examples, but the point is to master specialization, decomposition, and redefinition (see Lessons 22 and 23) and use them in creative ways to capture your own design and the process leading to it.

So far, I haven’t really seen a convincing case where the only option was derivation, but it is there as a backup and to support previously existing features. The difficulty with derivation connections (usages) is that they must connect usages, whereas I usually recommend using requirements definitions for traditional requirement modeling. Technically, it would be possible to use derivation connection definitions to model relationships between requirement definitions, but it is less comfortable. If you want to have requirement usages, you have to either use package-level requirement usages (which I generally don’t recommend) or group derived and source requirements in another requirement, but that can get complicated and unintuitive quickly.

In the end, I recommend using specialization and decomposition whenever possible, and reserving #derivation for corner cases when there is no other obvious solution.

Best regards,
Vince

1 Like
3

Hi Vince,

Thank you for the detailed and thoughtful response — it really helped clarify how one should think about specialization and decomposition as the primary “downstream” mechanisms in SysML v2.

I had a couple of follow‑up thoughts/questions that I’d love your perspective on.

1. Modularity and packages for multi‑level requirements

You mentioned that using package‑level requirement usages (and, more generally, managing requirements across packages) is usually not recommended. I understand the concern about complexity and unintuitive structures, especially when derivation is involved.

That said, coming from a large‑scale systems background, I’ve always seen modularity as one of the strongest advantages. In practice, we often want to:

  • Separate stakeholder / system / subsystem / software requirements into different packages,

  • Allow teams to own and evolve their part of the requirement model independently,

  • Enable reuse or substitution of whole requirement sets.

From that angle, having requirements organized in different packages feels quite natural and even desirable. I’m curious whether your recommendation is mainly about:

  • Avoiding requirement usages at the package level, or

  • A more general caution against distributing requirement hierarchies across packages?

In other words, is the concern more about how the relationships are modeled, rather than about modular packaging itself?

2. RequirementDef vs RequirementUsage (especially at the top level)

Another topic I wanted to ask about is RequirementDef vs RequirementUsage.

In the Advent of SysML v2 videos, there is a strong emphasis on using requirement definitions for requirements. This made me wonder whether a pattern like the following would actually be preferable, especially at the highest level:

  • Define a RequirementDef for a type of requirement (e.g., StakeholderRequirement), which:

    • Captures what a stakeholder requirement “should look like”

    • Defines common structure, parameters, attributes, and constraints

  • Then create the actual first stakeholder requirements as usages of that definition

Conceptually, this feels similar to defining a well‑typed requirement schema first, and only then instantiating concrete requirements from it — which seems very aligned with SysML v2’s emphasis on strong typing and semantics.

Do you see this as a recommended pattern in practice, or do you generally prefer treating even top‑level requirements directly as definitions? Are there trade‑offs (tooling, readability, scalability) that make one approach more pragmatic than the other?

Thanks again for the guidance — this discussion has been extremely helpful in reshaping how I think about requirements beyond the traditional DOORS mindset.

Best regards,
Abhishek

4

  • Define a RequirementDef for a type of requirement (e.g., StakeholderRequirement), which:

    • Captures what a stakeholder requirement “should look like”

    • Defines common structure, parameters, attributes, and constraints

  • Then create the actual first stakeholder requirements as usages of that definition

I think this is another instance of a common confusion regarding Definitions vs. Usages. Usages are always relational, describing instances in the context of some other instances. A good question here (@VinceMolnar) is what are some/the natural Types to feature the actual instance Usages.

A good rule of thumb (also from @VinceMolnar) is that package level Usages are rarely correct, and when they are they should almost always be abstract (in your example a corresponding package level usage might be something like abstract requirement allStakeholderRequirements : StakeholderRequirement).