Minimum Requirements for a Valid SysML v2 Use Case Model?

SysML v2 Questions / Help
1

Hello,

I hope you are doing well.

I am relatively new to SysML v2 and currently trying to learn it more deeply by building simple system model examples based on functional requirements, and representing them using use case models (textual notation).

I have completed the “Advent of SysML v2” course and also reviewed the SysML v2 specification (Part 1: Language Specification), including the sections related to use cases. However, I am still facing some practical challenges when trying to apply this knowledge.

In particular, I find it difficult to determine whether the use case models I create are actually correct and complete, or if they are missing important elements.

At this stage, I am mainly focusing on creating simple examples rather than complex systems, so I am especially interested in understanding what is the minimum level of detail required for a use case model to still be considered valid and to reasonably represent functional requirements.

I would appreciate your advice on the following:

  1. Are there any recommended resources or examples that show how to properly construct SysML v2 use case models?

  2. What is the minimum set of elements that a use case should include to be considered valid?

  3. How much detail is usually expected for a use case model to reasonably represent functional requirements?

Any guidance would be very helpful.

Thank you.

2

Hi,

SysML v2 language is flexible and supports modelling at different fidelity levels. Therefore there is no one criteria that defines what is a complete use case model, it all depends on your project context, company or team modeling and style guidelines, and how you plan to use the model.

You could consider the model is good enough if the model does not have syntax errors (Syside here is extremely useful), model makes sense from semantics point of view and it captures the design details sufficiently accurately so that you are able to perform all the tasks you need to perform. You can initially capture a minimum set of information in your use case and then add additional detail gradually as you develop the model in future.

Useful resources from SysMLv2 release GitHub:

Also, I strongly recommend getting a hold of The SysML v2 Book and studying the Chapter 33 which discusses all SysMLv2 Cases, including Use Cases. It provides good guidance to make fidelity related decisions for your SysML models.

Finally, feel free to refer to other resources as listed in this forum post: Useful SysML v2 Resources

Kind regards,
Kestutis

3

@KestutisJankevicius
Thank you very much for the helpful response and guidance — I truly appreciate your time.

I have one follow-up question regarding use case structuring and behavioral detail:

To ensure I am modeling use cases appropriately, I would like to confirm whether the following general approach is considered valid for representing use case actions/behavior in SysML v2.

For example, would a structure similar to the following be an appropriate way to define use cases and then express their behavioral flow through use case usages and ordered actions?

use case def 'UseCase1' {
    subject system : System;
    actor actor1 : Actor;
    objective {
        doc /* description */
    }
}

use case def 'UseCase2' {
    subject system : System;
    actor actor2 : Actor;
    objective {
        doc /* description */
    }
}

use case 'UseCaseUsage1' : UseCase1 {
    subject system : System;
    actor actor1 : Actor;

    include includedUC : UseCase2 {
        subject system : System;
        actor actor2 : Actor;
    }

    first action action1;
    then action action2;
    then action action3;
}

More specifically, is using ordered actions in this way an appropriate method for expressing the internal behavioral flow of a use case?

Or is there a more recommended way to model such behavioral details in SysML v2 use cases?

Thank you again for your help.

4

Hi again,

I assume the code snippet you shared would be written as is at package level, hence the feedback below is written with this in mind.

You should not have package-level usages because it creates an issue for semantics, as usage exists in all contexts all the time which is probably not what you want. Therefore a good practice is to always wrap the usages in some kind of definition, for example “part def SystemContext". Inside you can define all the relevant structural elements as part usages - system itself and for actor(s), and use cases themselves can be added as usages, too. For each use case, you can redefine the inherited subject and actors by binding them to the part usages owned by “SystemContext".

And regarding the actions succession:

  • Action succession should begin with first start; followed by the then action action1; and so on.
  • The use case definition is kind of a case definition, which is a kind of calculation definition, which is kind of action definition. Thus, when using action successions, include use case usages should be a part of that succession (i.e. include use cases feature after first start; line)
  • The pattern for including the use case without keywords use case (i.e. then include nameA :<use case def> {} instead of then include use case nameB : <use case def> {} ) is actually feature referencing, therefore reference nameA must resolve to another use case usage with name nameA. In my code snippet see example useCase2B.

See updated code snippet below

package Forum_UseCases {
    part def System;
    part def ExampleActor;

    use case def UseCase1 {
        subject system : System;
        actor actor1 : ExampleActor;
        objective {
            doc
            /* description */
        }
    }

    use case def UseCase2 {
        subject system : System;
        actor actor2 : ExampleActor;
        objective {
            doc
            /* description */
        }
    }

    part def SystemContext {
        part mySystem : System;
        part myActor : ExampleActor;
        part anotherActor : ExampleActor;

        use case useCase2B : UseCase2 {
            subject redefines system = mySystem;
            actor redefines actor2 = myActor;
        }

        use case useCase1 : UseCase1 {
            subject :>> system = mySystem;
            actor :>> actor1 = myActor;
            first start;
            then action action1;
            then include use case useCase2A : UseCase2 {
                subject :>> system = mySystem;
                actor :>> actor2 = anotherActor;
            }
            then include useCase2B;
            then action action2;
            then action action3;
        }
    }
}

Hope it is clear now how to begin adding use cases to your SysML v2 models!

Kind regards,
Kestutis

5

Thank you very much for the detailed explanation and the updated example.

Your response was extremely helpful and gave me a much clearer understanding of how use cases should be structured and interpreted. It clarified several points I was uncertain about and will help me significantly moving forward.

I truly appreciate your time and guidance.

Thank you again.