MBSE Requirements Modeling Literature ReviewCal Poly Group Report Out

2 June 2016

Model-Based Systems Engineering

Outline

• Task Objective• Literature Review

– Use Cases & Conops as part of the requirements process– Requirements Modeling Language (RML)/Telos– Unified Requirements Modeling Language (URML)– User Requirements Notation (URN)

• Interesting Findings• Contributors

2

Model-Based Systems Engineering

Task Objective

• Question: Is there a better way to manage requirements?– Input from Bill Bertch:

• Intent is not to replace the natural language practice at JPL• A formal requirements language is desirable

– rigorous syntax and semantic structure– parse textual requirements into requirements language

• A link to Concept of Operations and behavioral models is desirable– Assertion: Analysis of correctness and completeness is difficult

using natural language requirements and spreadsheets only(JPL existing practice on most projects)

• Our Process– Gather a group of (enthusiastic) Cal Poly undergrads– Conduct weekly meetings– Perform literature search– Assimilate/synthesize what we discover– Report Out

3

Model-Based Systems Engineering

Literature Review: Requirements

Conops Use Cases Behavioral Models

Natural Language

Requirements

4

Use Cases

ConopsNatural

Language Requirements

Highly desired to be linked

Behavioral Models

Model-Based Systems Engineering

Functional & Non-Functional Requirements

Functional requirement• Specifies a behavior that must be performed by the

systemNon-functional requirement (i.e., performance requirements)• Specifies a criteria that can be used to judge the operation

of a system (i.e., how well it performs)– How fast, big, accurate, safe, reliable, robust, scalable and long-

lasting.– “The system shall deliver data within 1 hour of observation”– Usability, testability, maintainability, etc.

5

Model-Based Systems Engineering

Literature Review: RML

Requirements Modeling Language (RML) (1980s & 90s)• Objective: Organize and model requirements as objects

– An Object-Oriented (OO) framework– Uses OO concepts to create requirements models for both

functional and non-functional requirements

RML mainly designed for software development

• Advantages• A formal requirements language

• Disadvantages• Intended for software • Not much recent work in this area• No commercial/open source tool• Difficult for us to fully understand

Model-Based Systems Engineering

Literature Review: Telos

Telos (a follow-on to RML)• Objective: Extend RML’s range of

applications– Builds on lessons learned in RML– Creates “extensible ontologies”

• Advantages:– Allows formal reasoning (queries of

model)– Has been successfully applied to the

wide scope of requirements modeling applications (according to paper)

• Disadvantages:– Still a research topic in software

engineering (no systems engineering application)

Admit class in Telos

Model-Based Systems Engineering

Literature Review: URML

User Requirements Modeling Language• A profile of UML

– Implements danger, feature and goal modeling related to requirements

Advantages:• Similar in concept to UML/SysML• Partially implemented in commercial tool

– Sparx System Enterprise Architect add-in

Disadvantages:• Not a lot published• No recent activity (nothing since 2013)

8

Model-Based Systems Engineering

Literature Review

User Requirements Notation (URN)*• URN is a semi-formal, lightweight graphical language

for modeling and analyzing requirements in the form of goals and scenarios and the links between them

• URN combines:– Goal-oriented Requirements Language (GRL)

for non-functional requirements– Use Case Maps (UCMs) for functional requirements

9

* URN is International Telecommunication Union (ITU) Standards Z.150 & Z.151GRL Model UCM Model

Model-Based Systems Engineering

URN: Goal-oriented Requirements Language (GRL)

10

Legend:

Example:

(a) GRL elements(b) GRL satisfaction levels(c) Links composition(d) GRL links(e) GRL contribution types

GRL is a visual modeling notation for intentions,business goals, and non-functional requirements (NFR)

Model-Based Systems Engineering

URN: Use Case Maps (UCM)

11

Use Case Maps illustrate a flow of behavior among different components in a system.

• UCMs combine formal and informal language to create an organized, detailed map

• A map contains paths, which are sets of sequences• Responsibilities highlight required actions before the

scenario is completed• Forks and joints can exist in the path• Waiting places and timers are places where there is a pause

until an action is satisfied• Plug-in maps can highlight an area of the path in more

detail• Scenarios are defined paths in which a single alternative is

taken

Model-Based Systems Engineering

12

Garrett & Ivan todemo/describe jUCMNav

Video 1: https://www.youtube.com/watch?v=D097v1Sm98Q&feature=youtu.beVideo 2: https://www.youtube.com/watch?v=3hrpW7sXOI8&feature=youtu.be

Model-Based Systems Engineering

Interesting Findings

• RML/Telos appears to be an object-oriented framework for developing requirements models. – Doesn’t appear to be applied outside of software engineering– Could not locate industry-specific examples or commercial tools.

• URML is a profile of UML, but not much concrete has been published• URN models goals and use cases

(which can enable complete and consistent natural language requirements)– URN is a standard and has ongoing activity (Amyot, U of Ottawa)– URN and SysML seem compatible

(some work in this area has been published)– Open source tool (jUCMNav – “Juicy-M-Nav”) is an add-on module

for Eclipse (an open source integrated development environment)• Conclusion

– URN appears to be a rigorous model-driven requirementsmodeling method

13

Model-Based Systems Engineering

Contributors

• Cal Poly Students– Valeria Salazar– Maria Olea– Hector Molina Rivera– Kent Rush– Ivan Cheng– Garrett Miele– Katie Breitenstein– Luis Curiel

• Bill Bertch (JPL)• Kurt Colvin (Cal Poly/JPL Visitor)• (Indirectly) Daniel Amyot and Gunter Mussbacher -

University of Ottawa

14