MBSE with Genesys 093022

Model-Based Systems Engineering with

Version 2022 RevA

1

Administrative Details

• Food

• Coffee, juice, snacks, etc. • Lunch (arrangements and timing) • Conveniences

• Restrooms • Telephones

• Schedule

• Preferred start and end time • Breaks

• Lab hours • Questions and answers

Introductions

2

MBSE with GENESYS

Overall Course Objectives

• Introduce a model-based systems engineering approach that consistently delivers success • Demonstrate how to implement this approach using a systems engineering environment • Solve a sample problem while at the same time, generating representative systems engineering artifacts and documentation • Provide systems engineering knowledge and skills to take back to your team members, project, and organization

3

A Roadmap for This Course

• Setting critical context • Introducing systems engineering • Decoding MBSE • Seeing GENESYS in action • Taking an integrated approach to (MB)SE • Understanding the problem • Capturing requirements • Visualizing requirements • Filtering, sorting, and documenting • Beginning analysis: concerns and risks

4

MBSE with GENESYS

A Roadmap for This Course, cont.

• Defining the system context (a black box view) • Defining the system boundary • Visualizing physical architecture • Adding tools to our toolkit • Working with use cases

• Considering states • Introducing behavior • Visualizing behavior

5

A Roadmap for This Course, cont.

• Transitioning from problem to solution • Leveraging threads • Defining integrated behavior • Tracing requirements • Allocating behavior • Defining physical architecture and interfaces • Considering verification and test • Addressing special topics • Wrapping up

Please raise questions and offer perspectives as they occur!

6

MBSE with GENESYS

An Introduction to Systems Engineering

7

8

MBSE with GENESYS

Image credit: Alisa Farr for Letter27. farrimages.com

Image credit: www.baaa ‐ acro.com

Image credit: 7Wonders

Image credit: MotorTrend

9

Seeing the Mismatch: Modern Conditions and Classic Approaches

We tend to assume that technological advances will enable us to do what we have always done, only better. However these same technologies imbue our operating environment with escalating non-linearity, complexity, and unpredictability.

Attempts to control complex systems by using the kind of mechanical reductionist thinking … breaking everything down into component parts, or optimizing individual elements … tend to be pointless at best or destructive at worst.

10

MBSE with GENESYS

Understanding Systems Challenges in Today’s World

Exceeding the capabilities of traditional siloed approaches • System scale

• Mission complexity • Technical complexity • Project team complexity • Dynamic complexity

SE Vision 2025. Copyright © 2014 by INCOSE. All rights reserved.

Image credit: Alisa Farr for Letter27. farrimages.com

11

Defining “System”

• A System “is a thing that contains interconnected smaller things, interacts with other things in a larger thing, and does something. ” • has structure, in a larger structure (‘physical’ context) • performs purposeful actions • time sequence of collective actions = behavior • behavior observed at interfaces (‘functional’ context) • “… a system is, and a system does …” An integrated composite of people, products, and processes that provide a capability to satisfy a stated need or objective. EIA ‐ 632 A system is an arrangement of parts or elements that together exhibit behavior or meaning that the individual constituents do not. INCOSE

System

Segment

Subsystem

Assembly

Part

12

MBSE with GENESYS

Systems Engineering

Systems Engineering is a transdisciplinary and integrative approach to enable the successful realization, use, and retirement of engineered systems, using systems principles and concepts, and scientific, technological, and management methods. INCOSE

13

Definitions of Systems Engineering

SIMILAR • S tate the problem, • I nvestigate alternatives, • M odel the system, • I ntegrate, • L aunch the system, • A ssess performance, and • R e-evaluate

“Systems engineering is a (thought) process employed in the evolution of a need into an ultimate deployment.” Source: Blanchard and Fabrycky, 2nd edition, 1990 “Systems engineering is the structured, multidisciplinary development of creating complex systems while minimizing risks and satisfying the customer.” Source: INCOSE 1992

The systems engineering team “owns” the architecture

14

MBSE with GENESYS

Differing Viewpoints: Subject Matter Experts and Systems Engineers

SMEs view their scope as the largest, most significant, most difficult

SMEs bring essential insights into the “art of the possible”

The systems engineer balances the perspectives yielding a capable, cost effective, and timely system

15

Connecting across the Project: Technical Detail within the Greater Context

“Functioning in an interdependent environment requires that every team possess a holistic understanding of the interaction between all the moving parts.”

“People can only be empowered if they have enough context to make good decisions.” Quotes from Team of Teams , 2015

Image credit: US Department of Transportation

16

MBSE with GENESYS

Complementing – not Replacing – Approaches A SYSTEM is a whole that cannot be divided into independent parts without losing its essential characteristics as a whole. ANALYTIC THINKING applies an analytic method to separate a system down into its constituent parts. Analytic thinking attempts to explain the behavior of these parts, and then attempts to aggregate this understanding into an understanding of the whole SYSTEM THINKING considers problems and solutions in terms of how the interactions of the parts, and the parts with the whole and its environment, create the properties of the whole. Systems Engineers need to rethink their problem ‐ solving approach in general and innovation in particular– this is system thinking. For further information on systems thinking see The Fifth Discipline by Peter Senge and various publications from Russell Ackoff

17

When to Do Systems Engineering?

The System Life Cycle Model (ISO 15288)

SE focus in later stages centers on Operation, Maintenance, Sustainment

Highest level of SE intensity is concentrated in these phases

Utilization & Support Stage

Concept Stage

Development Stage

Production Stage

Retirement Stage

Lifecycle performance effects the next version

Systems engineering applies across all phases of the lifecycle

18

MBSE with GENESYS

Four Primary SE Activities

P HYSICAL A RCHITECTURE

B EHAVIORAL A RCHITECTURE

V ERIFICATION & V ALIDATION

R EQUIREMENTS

19

Three Systems

20

MBSE with GENESYS

Failure to Think Systemically

21

Failure to Think Systemically

Blackwater Wildlife Preserve

22

MBSE with GENESYS

Why Do Systems Engineering: The Financial Case • Cope with complexity • Avoid omissions • Avoid invalid assumptions • Make informed, defensible decisions • Manage change • Design most efficient, economic, and robust solution • Achieve greater design control Project Phase Method 1 — Bottom ‐ Up Cost Method 2 — Total Costs Breakdown Method 3 — Top ‐ Down Hypothetical Project Requirements 1 x 1 x 1 x Design 8 x 3 ‐ 4 x 4 x Build 16 x 13 ‐ 16 x 7 x Test 21 x 61 ‐ 78 x 28 x Operations 29 x 157 ‐ 186 x 1615 x Source: Error cost escalation through the project life cycle ‐ NASA Johnson Space Center It is not hard to know when system engineering fails, because when something important goes wrong it usually makes the news fast. INCOSE

23

Enabling Project Success: The Motivation for SE

 Understanding the problem  Integrating the team  Defining the seams  Addressing the gaps  Guarding the why

Image Credit: Defense Acquisition University

24

MBSE with GENESYS

Enabling Project Success: The Motivation for SE

SE Criticality Increases as Projects become Complex

All Projects Benefit from SE

Projects that apply SE best practices perform better than projects that do not

25

Decoding MBSE What model-based systems engineering is and what it isn’t

26

MBSE with GENESYS

Classical Engineering in a Complicated World

R

F

L

R1

F1

L1

F2

R1.1

L1.1

F2.1

R1.2

L1.2

F2.2

R2

L2

F3

L3

R2.1

F3.1

L3.1

R2.2

F3.2

L3.2

R2.3

F3.3

L3.3

R3

F4

L4

R4

F4.2 F4.1

L4.2 L4.1

R4.2 R4.1

F5

L5

R5

F6

F6.2 F6.1

R EQUIRED

B EHAVIOR

P HYS A RCH

C ONCEPT

D EVELOPMENT

27

From Static Products to Intelligent Systems of Systems

Smart, Connected Product

Product System Systems of Systems

Product

Smart Product

Electro ‐ mechanical

Cyber

Connected

Coordinated

Collaborating

Adapted from Claas, November 2019.

Icons made by Freepik from www.flaticon.com

28

MBSE with GENESYS

Towards MBSE: A Practice in Transition

Future

Traditional

• Specifications • Interface requirements • System design • Analysis & Trade ‐ off • Test plans

Moving from document-centric to model-centric

Reprinted from INCOSE Model-Based Systems Engineering Workshop, February 2010

29

Models and MBSE

Model: a graphical, mathematical (symbolic), physical, or verbal representation or simplified version of a concept, phenomenon, relationship, structure, system, or an aspect of the real world. www.businessdictionary.com

Model: a physical, mathematical, or otherwise logical representation of a system, entity, phenomenon, or process. DoD5000.59 ‐ M 1998

Model ‐ based systems engineering (MBSE) is the formalized application of modeling to support system requirements, design, analysis, verification and validation activities beginning in the conceptual design phase and continuing throughout development and later life cycle phases. INCOSE SE Vision 2020, September, 2007

Much of the confusion in MBSE is the ambiguity in “model”. If everything is a model, everything qualifies as MBSE.

30

MBSE with GENESYS

“Demythify” the Transition: Recognizing What MBSE Is Not

31

Understanding the Transition: From Ambiguity to Clarity, “One Idea in One Place”

32

MBSE with GENESYS

Understanding the Transition: Clarify “Model” in MBSE

33

Focusing on the Foundational Concepts: Model-Based Systems Engineering

Requirements a system’s why

specifies

basis of

verified by

Verification a system’s proof

Physical Architecture a system is

Behavioral Architecture a system does

verified by

verified by

performed by

34

MBSE with GENESYS

Focusing on the Foundational Concepts: Specifying the Design Envelope

Color Code

Requirement Entity

Functional Entity

Physical Entity

Interface Entity

built from / kind of

Verification Entity

Other Entity

Component

exposes

Port

connected to

Link

includes

35

Focusing on the Foundational Concepts: Defining Functions and Exchanges

Color Code

Requirement Entity

Functional Entity

Resource

Exit

Physical Entity

Interface Entity

captures / consumes / produces

exits by

built from / kind of

Verification Entity

Other Entity

Function

Component

performs

decomposed by

exposes

inputs / outputs

Port

connected to

Item

Link

transfers

decomposed by

includes

36

MBSE with GENESYS

Focusing on the Foundational Concepts: Considering All States

Color Code

triggered by

Transition

Requirement Entity

Functional Entity

entered by / exited by

Resource

Exit

Physical Entity

Interface Entity

State

captures / consumes / produces

exits by

built from / kind of

incorporates

exhibits

decomposed by

Verification Entity

Other Entity

Function

Component

performs

decomposed by

exposes

Event

inputs / outputs

Port

connected to

responsible for

Item

Link

transfers

decomposed by

includes

37

Focusing on the Foundational Concepts: Capturing the Right Problem

Color Code

triggered by

Transition

Requirement Entity

Functional Entity

entered by / exited by

Resource

Exit

Physical Entity

Interface Entity

State

captures / consumes / produces

exits by

built from / kind of

incorporates

exhibits

decomposed by

Verification Entity

Other Entity

Function

Component

performs

involves / describes

Use Case

decomposed by

elaborated by

includes / extends / kind of

elicits

basis of / specifies

specifies

Requirement

exposes

refined by

Event

inputs / outputs

Port

connected to

responsible for

Item

Link

transfers

decomposed by

includes

38

MBSE with GENESYS

Focusing on the Foundational Concepts: Planning and Tracking Verification

Color Code

triggered by

Transition

Requirement Entity

Functional Entity

entered by / exited by

Resource

Exit

Physical Entity

Interface Entity

State

captures / consumes / produces

exits by

built from / kind of

incorporates

exhibits

decomposed by

Verification Entity

Other Entity

Function

Component

performs

involves / describes

Use Case

decomposed by

elaborated by

includes / extends / kind of

elicits

basis of / specifies

specifies

Requirement

exposes

refined by

verified by

verified by

Event

verified by

inputs / outputs

verified by

Port

Verification Requirement

executed by / executes

verified by

specifies

verified by

connected to

responsible for

Test Configuration

Verification Activity

employs

accomplished by

decomposed by

Verification Event

includes

Item

Link

transfers

decomposed by

includes

39

Focusing on the Foundational Concepts: Capturing the Journey

Color Code

triggered by

Transition

Requirement Entity

Functional Entity

entered by / exited by

Resource

Exit

Physical Entity

Interface Entity

State

captures / consumes / produces

exits by

built from / kind of

incorporates

exhibits

decomposed by

Verification Entity

Other Entity

Function

Component

performs

involves / describes

Use Case

decomposed by

elaborated by

includes / extends / kind of

elicits

basis of / specifies

specifies

Requirement

exposes

refined by

verified by

verified by

Event

verified by

inputs / outputs

verified by

Port

Verification Requirement

executed by / executes

verified by

specifies

verified by

connected to

responsible for

Test Configuration

Verification Activity

employs

accomplished by

decomposed by

Verification Event

includes

Item

Link

transfers

decomposed by

includes

generates

results in

causes

assigned to

Organization

Concern

Risk

40

MBSE with GENESYS

Focusing on the Foundational Concepts: Engineering with Rigor

Color Code

triggered by

Transition

Requirement Entity

Functional Entity

entered by / exited by

Resource

Exit

Physical Entity

Interface Entity

State

captures / consumes / produces

exits by

built from / kind of

incorporates

exhibits

decomposed by

Verification Entity

Other Entity

Function

Component

performs

involves / describes

Use Case

decomposed by

elaborated by

includes / extends / kind of

elicits

basis of / specifies

specifies

Requirement

exposes

refined by

verified by

verified by

Event

verified by

inputs / outputs

verified by

Port

Verification Requirement

executed by / executes

verified by

specifies

verified by

connected to

responsible for

Test Configuration

Verification Activity

employs

accomplished by

decomposed by

Verification Event

includes

Item

Link

transfers

constrains / uses parameter from

decomposed by

includes

generates

results in

causes

assigned to

Constraint Definition

Organization

Concern

Risk

41

The Systems Metamodel

triggered by

Transition

…more than diagrams …more than a data dictionary …more than capture …more than specification …more than the system of interest

entered by / exited by

Resource

Exit

State

captures / consumes / produces

exits by

built from / kind of

incorporates

exhibits

decomposed by

Function

Component

performs

involves / describes

Use Case

decomposed by

elaborated by

includes / extends / kind of

elicits

basis of / specifies

specifies

Requirement

exposes

refined by

verified by

verified by

Event

verified by

inputs / outputs

verified by

Port

Verification Requirement

executed by / executes

verified by

specifies

verified by

connected to

responsible for

Test Configuration

Verification Activity

employs

accomplished by

decomposed by

Verification Event

includes

Item

Link

transfers

constrains / uses parameter from

decomposed by

includes

generates

results in

causes

assigned to

Constraint Definition

Organization

Concern

Risk

42

MBSE with GENESYS

Essential Characteristics of the Systems Model

A system is a whole that cannot be divided into independent parts without losing its essential characteristics as a whole. It follows from this definition that, a system’s essential defining properties are the product of the interactions of its parts, not the actions of the parts considered separately. Therefore, when a system is taken apart, or its parts are considered independently of each other, the system loses its essential properties. Furthermore, when performance of each part taken separately is improved, the performance of the system as a whole may not be, and usually isn’t. --Russell Ackoff

43

What MBSE is All About

• Making system descriptive and analytical models explicit , coherent , consistent , and actionable • Evolution from low-fidelity representations in documents to higher-fidelity, richer representations • Improved granularity of knowledge capture for management, analysis, and learning • One architectural model connecting multiple analytical models • Leveraging models for communication and analysis • Developing an “authoritative source of truth” for system design and specification • Ensuring consistent design and specification (when done well) • Providing an explicit system model to engineering teams An evolution – not revolution – in thinking and approach… An evolution that offers transformative results

44

MBSE with GENESYS

Moving the Focus from Engineering Artifacts to Engineering Systems

45

Aligning across the Engineering Enterprise Right Data, Right Place, Right Time, Right Presentation

Customer

Program Mgt.

Configuration Management

Chief Engineer

Publications

Hardware

Training & Personnel

Software

Environmental

Systems Engineering Team

Safety

Operations

Reliability, Availability, Maintainability

Maintenance

Logistics

Manufacturability

Test

Security

46

MBSE with GENESYS

Seeing the Impact in One Area: Dynamic Technical Data Packages with Context

• Interface definitions • Incoming and outgoing signals • Required functionality • Design constraints • Associated requirements • Test requirements • Physical and behavioral context • Rationale and design history • Analytical dependencies • Multidimensional traceability

47

Transforming Engineering: A New Manifesto

48

MBSE with GENESYS

SE, MBSE, and Digital Engineering Digital Engineering

critical enabler for the modern engineering enterprise MBSE connective tissue of the Digital Engineering environment Systems Engineering technical connective tissue of the project team

49

GENESYS Environment

50

MBSE with GENESYS

A Black Box View of GENESYS

Capture the what and why of design Visualize your information your way Integrate architecture with analysis

51

The GENESYS Technology • Systems metamodel • Provides a structure to capture and communicate all aspects of the system through a proven information model • Reflects the language of the systems engineer • System design repository • Contains and preserves the integrity of the system model • Exposes the current state of engineering to the entire engineering team • View “generators” • Guarantees consistency and integrity of all design artifacts • Updates to any view result in automatic updates to all other affected views managing the bookkeeping so that the team can focus on engineering The GENESYS technology empowers engineering teams to build a complete and integrated system definition

52

MBSE with GENESYS

Leveraging the GENESYS Architecture: A Glass Box View

Model Consumer

User Interface, Reports, Scripts, Simulation, API Applications

Object ‐ oriented .NET object model Data binding support

Client API

WCF (Windows Communication Foundation) stack Provides communication flexibility Process, Machine, LAN, WAN, TCP, HTTP, etc.

Services

Applies fundamental business logic Responsible for model consistency

Database

Persists and retrieves raw data

53

Enabling Real-Time Collaboration through the GENESYS Architecture

Single Compute r

Collaborative

Model Consumer

Genesys.exe

Model Consumer

Client API

Client API

Services

GENESYS Collaborative Edition Services Host [windows service]

Database

Services

Services GENESYS Server

SQL SERVER (GENESYSCOLLAB) [windows service]

Database

Database

54

MBSE with GENESYS

GENESYS Systems Metamodel Concepts

Systems metamodel (also known as the System Definition Language) is an extended natural language in ERA format

GENESYS Concept

English Equivalent

GENESYS Example

• Requirement Accept Requests • Function Accept And Format Request • Component Command Center Subsystem • Requirement basis of Functions • Functions are allocated to Components

Class / Entity

Common Noun / Particular Noun

Relationship

Verb

Attribute

Adjective

• Description • Number

Resource consumed by Function • Amount • Acquire Available (hold partial)

Relationship Attribute

Adverb

Parameter Structure

N/A N/A

Design-dependent variables (mass, size, reliability, etc.)

Viewed as activity diagram or enhanced FFBD

55

Seeing a Partial Systems Engineering Example

DOCUMENT

documents (documented by)

documents (documented by)

• Number • Description • Type

REQUIREMENT • Number • Description • Type • Origin

COMPONENT • Number • Description • Type

specifies (specified by)

FUNCTION

specified by (specifies)

performs (allocated to)

•Number •Description •Duration •Exit Logic

56

MBSE with GENESYS

GENESYS Walkthrough A quick introduction to the interface

57

Exploring GENESYS

• Launching GENESYS and logging in • Importing a project • Navigating the project explorer • Project properties • Facilities, folders, and entities • Entity property sheet • Diagrams and the diagram toolbox • Exiting GENESYS

58

MBSE with GENESYS

Launching GENESYS 1. Open the Windows Start menu 2. Select GENESYS #### folder 3. Select GENESYS #### Collaborative Edition

59

Logging into GENESYS 1. Enter your password (“admin” is the default password for the Administrator account) 2. Click OK You can select your repository (local, peer, or GENESYS server) We will use the Administrator account in class, but you should not use this account on a day ‐ to ‐ day basis

60

MBSE with GENESYS

Reviewing the GENESYS Home Screen

61

Accessing Commands via the Application Menu 1. Click “File” to access the main application menu Commands on the application menu are global

Import and Export load and save project information files to and from the GENESYS repository Information added to a project is saved in real ‐ time to the repository without need for an explicit save or export command

62

MBSE with GENESYS

Importing a Project File into GENESYS 1. Select the application menu 2. Select Import

3. Navigate to the specified folder 4. Select “Fast Food Sample.gnsx” 5. Click Open

C:\Program Files\Vitech\GENESYS #### Collaborative Edition\Samples\Project Samples

63

Stepping through the Import Wizard

64

MBSE with GENESYS

Import Wizard Results • Click CLOSE

65

Opening SAMPLE: Fast Food Project 1. Select the Project 2. Click Open

GENESYS can have multiple projects open simultaneously. Each open project has at least one project explorer open. Closing the last project explorer will prompt to close the project

66

MBSE with GENESYS

Ribbon Controls and Commands

Application Menu

Navigation Commands

Undo/Redo

Ribbon Tabs

Context ‐ Sensitive Commands (highlighted or shaded based on current selection)

67

Specifying Project Properties 1. In the project explorer panel, select “SAMPLE: Fast Food”

The project property sheet provides top ‐ level information on the project and its configuration • Organization information • Customer information • External file paths • Completeness and integrity checkers • Project configuration settings

68

MBSE with GENESYS

Navigating within a Project The project explorer panel enables navigation of the project by packages or by classes

Packages allow you to group any blend of entities together for model management and navigation purposes Classes group all entities of a given type together into folders and subfolders 1. Click “Essentials” in the facility drop ‐ down 2. Select “All Classes” The facility drop ‐ down allows you to view a subset of the classes in the project 3. Click “All Classes” in the facility drop ‐ down and select “Essentials”

69

Understanding “Schema” and “Facilities”

• Schema • Collection of all entity classes, attribute definitions, relationship definitions, and parameter definitions that are available to the systems team • Instantiation of the systems metamodel in a database • Facility • Collection of related entity classes grouped together for visibility • Subset of the total schema • All Classes – all classes

• Essentials – primary classes used for basic systems engineering • Program Management – classes used for program management • Systems Engineering – classes used for systems engineering • Verification – classes used for verification definition and tracking

70

MBSE with GENESYS

Accessing Entities 1. Select Component in the project explorer panel Browser panel shows entities in the selected class / folder An entity is an object that is an instance of a given class definition in the model New entities can be created multiple ways • the New Entity command in the ribbon • the “Create” control at the top of the entity list • double ‐ clicking the class name

71

Accessing Information about an Entity 1. Select “Fast Food System” in the browser panel

Selecting an entity populates the property sheet with all information about the entity

• Attributes • Properties • Parameters • Diagnostics • Relationships • Views

72

MBSE with GENESYS

Opening a Property Sheet 1. Double ‐ click “Fast Food System” in the browser panel to open the property sheet as a separate window Double ‐ clicking an entity anywhere in GENESYS is a shortcut to open the property sheet The property sheet allows us to • characterize the entity (the upper region) • see the valid relationships types (the lower ‐ left region) • see the current relationships and their attributes (the lower ‐ right region) 2. Close the property sheet

73

Changing an Attribute and Accessing Versions 1. In the project explorer, make a change to the Description attribute 2. Click in the Abbreviation attribute When you change fields or close a window, GENESYS saves the changed value 3. Click the versioning icon at the right of the Description panel The version dialog allows you to access and restore previous versions. Project administrators determine which attributes should be versioned. 4. Click OK to close the version dialog

74

MBSE with GENESYS

Exploring Entity Properties 1. Click the “Properties” tab

Properties are tool ‐ dependent fields that GENESYS uses to manage and represent entities

75

Specifying Parameters Parameters are design ‐ dependent variables to manage the numerical values of the design and can be referenced in text attributes 1. Click the “Parameters” tab 2. Click Add/Remove to edit the parameters for the entity New defines a new parameter for this class Copy allows you to copy an existing parameter definition from another class Add allows you to add a predefined parameter for the given class Remove allows you remove a previously assigned parameter

76

MBSE with GENESYS

Specifying Parameters Parameters allow you to specify • Objective (design targets) • Maximum, Minimum (bounds) • Design (current design value) • Observed (current as ‐ built value) • Precision (as ‐ built tolerancing) The same parameter can be bound to multiple entities using parameter bindings.

77

Leveraging Parameters: Descriptive Text, Computable Numerics Parameters can be inserted into any text field 1. Click the “Attributes” tab 2. Click in the Description panel 3. Right ‐ click to access the context menu a) Select Insert Parameter b) Select the parameter previously added or create a New Parameter The selected parameter field is inserted into the text using markup language. The

parameter value can only be edited via the parameters tab, but the value in the text field will be automatically updated. When output in a report or on a diagram, the markup language is hidden

78

MBSE with GENESYS

Reviewing Entity Diagnostic Errors

1. Click the “Diagnostics” tab Completeness errors reflect where attributes are incomplete or relationships don’t exist (e.g., a leaf ‐ level Requirement that does not trace into the solution architecture) Design integrity errors reflect inconsistencies in the descriptive architecture (e.g., an Item between Functions that is not properly mapped to a connecting Link ) The desired completeness and design integrity checkers are specified as part of the project properties. These can be customized based upon a team’s methodology or schema extensions.

79

Visualizing Completeness and Integrity Checks

Completeness

Design Integrity

80

MBSE with GENESYS

Seeing Stored Views: Auto-generated Diagrams with Style 1. Click the “Views” tab

Views are the style information for a specific diagram (diagram settings, node size and position, coloring, node template, etc.). GENEYSYS supports multiple views per diagram type allowing you to represent the same diagram multiple ways to address communication and analysis needs. GENESYS automatically stores this information when a diagram is closed. GENESYS applies this information when the diagram is re ‐ opened and automatically updated to reflect the current state of the project. Views can be renamed, opened, and deleted from the views tab

81

Opening Diagram Views Diagrams can be accessed using the diagram tabs at the bottom of the project explorer or the Views ribbon • clicking the tab accesses the view within the project explorer • selecting a diagram via the Views ribbon opens the diagram in a separate window The commands and behavior are the same whether you use a diagram tab or a separate window 1. Ensure “Fast Food System” is selected in the browser panel 2. Select the Views menu 3. Click BDD to open the block definition diagram

82

MBSE with GENESYS

Navigating the Diagram Controls

View port (adjust grey region to reposition and scale)

Scale and navigation controls

Insert lists • Constructs • Shapes • Key Entities • All Entities

83

Setting Diagram and Diagram Object Properties 1. Select “Properties” in the toolbox

The properties tab controls the style settings for the diagram and diagram objects (nodes, lines, and shapes)

When nothing is selected, the properties tab controls diagram ‐ level settings • diagram options • default content, coloring, and sizing When one or more diagram objects are selected, the properties control the presentation of those objects (coloring, sizing, use of images)

84

MBSE with GENESYS

Reviewing the Ribbon Bar for Diagrams

View tab opens new views on the selected entity

Diagram tab manipulates the formatting and content as well as exports graphic files

85

Exiting GENESYS When you want to end your session 1. Select the application menu 2. Select the Exit command

Remember that changes made to projects are committed to the repository in real ‐ time so there is no need to save when exiting

86

MBSE with GENESYS

Setting Up Your Project

87

Getting Started with GENESYS: Configuring Users and Projects

• Creating a new user account

• Creating a new project

• Setting project permissions

• Setting user preferences

88

MBSE with GENESYS

Accessing the Administrative Tools 1. In the project explorer, select the Utilities ribbon 2. Select Admin Tools (also available from the Home screen) Administrative Tools allow us to manage • Projects • Users • Groups

• Current sessions • Security options • OSLC settings

89

Creating a New User Account 1. In the administrative tools, select the Users tab 2. Select New User The New User dialog specifies the username and password for the account 3. Enter “JDoe“ as the username 4. Enter “Welcome” as the password 5. Click OK Usernames must be at least two characters

long. Passwords must be at least five characters long (password rules may be changed via the Security tab).

90

MBSE with GENESYS

Editing User Account Properties 1. Select Edit User

The user properties allow you to specify • full name (for descriptive purposes) • email (for change notifications) • description • account disablement (for temporary lockout) • group membership 2. Click OK

91

Specifying Groups Groups tab allows you to • Create a new group • Edit properties and membership for a group • Delete a group Best practice for managing permissions is • Set up user accounts • Set up groups • Assign users to groups • Assign permissions to groups, not users

1. Close the Administrative Tools

92

MBSE with GENESYS

Creating a New Project 1. In the project explorer, select “Home” in the left panel 2. Select “New Project” 3. Set project name (“Geospatial Library Class Project”) 4. Select schema type (“Base Schema ####”) 5. Click OK Base schema, base view set, and unique entity names must be set during project creation Versioning and audit logging can be changed at any time via the project property sheet

93

Setting Our Project Properties Project properties are settings and descriptive values for a given project 1. (Optional) Enter Organization Name and Organization Address 2. (Optional) Enter Customer Name and Customer Address 3. Set Base Path and External Graphics Path

4. Select Design Integrity Checker These properties will be used when generating documents and for managing external files

Base Path ‐ > C:\Program Files\Vitech\GENESYS #### Collaborative Edition Graphics ‐ > C:\Program Files\Vitech\GENESYS #### Collaborative Edition\Bitmaps

94

MBSE with GENESYS

Editing Project Permissions Project permissions are managed from the Project ribbon or the Projects tab of the Administrative Tools

1. Click Set Permissions 2. Select User or Group 3. Select and set permissions

User/group permissions are set by checking the appropriate boxes for • Read

• Update • Create • Delete • Full Control

95

Editing Permissions at the Folder or Entity Level

If you wish to set permissions for a class, folder, or entity 1. Select the folder or entities of interest 2. Right ‐ click to access the context menu 3. Select the Set Permissions command 4. Set Read, Update, Delete, and/or Full Control to set the permissions for each user/group

96

MBSE with GENESYS

Editing Permissions at the Attribute Level

If you wish to set permissions for an attribute of an entity 1. Select the folder or entities of interest 2. Right ‐ click to access the context menu 3. Select the Set Attribute Permissions command 4. Select the desired attribute 5. Set Read, Update, Delete, and/or Full Control to set the permissions for each user/group

97

Editing Project and User Preferences

User Preferences – customize the way of working for the user Project Preferences – provide consistency across the project

98

MBSE with GENESYS

An Integrated Approach and Timeline for (MB)SE

99

An Integrated, Layered Approach to (MB)SE

Dgn V&V

BEH

REQ

ARCH

Level Of Detail

Source Documents

LEVEL 1

Dgn V&V

BEH

REQ

ARCH

LEVEL 2

Dgn V&V

BEH

REQ

ARCH

LEVEL n

100

MBSE with GENESYS

Behavioral Architecture (glass box perspective)

Operational Architecture

Physical Architecture

System Definition (black box perspective)

Enterprise Perspective

BASIS OF

ALLOCATED TO

REQ

ARCH

BEH

C ON

R ISK

UC

UC

P ROBLEM S PACE

S OLUTION S PACE

101

SE Activities Timeline for Top-Down Design

0. Define Need & System Concept

Activity bars represent movement of “center of gravity” of systems engineering team (concurrent engineering is assumed)

1. Capture & Analyze Orig. Requirements 2. Define System Boundary 4. Derive System Threads 3. Capture Originating Architecture Constraints

5. Derive Integrated System Behavior 6. Derive Component Hierarchy

7. Allocate Behavior to Components

SCHEDULE

8. Define Internal Interfaces

9. Select Design

10. Perform Effectiveness & Feasibility Analyses

11. Define Resources, Error Detection, & Recovery Behavior

12. Develop Verification & Validation Requirements/Plans

13. Generate Documentation and Specifications

102

MBSE with GENESYS

SE Activities Timeline for Reverse Engineering

8. Update System Boundary

then modify top ‐ down

Find the top,

7a. Modify Requirements & Architecture Constraints

7. Derive As ‐ Built System Requirements

6. Derive As ‐ Built System Threads

6a. Modify System Threads

5. Aggregate to As ‐ Built System Behavior

5a. Modify & Decompose System Behavior

4. Derive As ‐ Built Behavior of Components 3. Capture Component Hierarchy

4a. Allocate Behavior to Components

3a. Refine Component Hierarchy

2a. Define Interfaces

2. Capture Interfaces

SCHEDULE

1. Define System Boundary

9. Select Revised Design

10. Perform Effectiveness & Feasibility Analyses

11. Capture Error Detection, Resource, & Recovery Behavior

12. Develop Verification & Validation Requirements/Plans

13. Generate Documentation and Specifications

103

High-Level Overview of Steps We Will Follow • Capture requirements • Analyze requirements • Define the system boundary • Analyze use cases and threads • Define integrated behavior • Trace requirements • Define physical architecture

• Allocate behavior • Analyze interfaces • Defining verification and validation

104

MBSE with GENESYS

Essential Tasks Before You Start

Plan the activity • Prepare a Systems Engineering Plan (e.g., SEP) • Capture process, method, and tool guidance, including conventions • Tailor the plan to your project Make sure you assign responsibility • Define the people who retain authority over the system requirements, behavioral architecture, physical architecture, interfaces, and test and integration plan

105

Step 0: Defining Need and System Context Outside our scope, inside our responsibility

106

MBSE with GENESYS

Seeking the Enterprise Perspective: Defining Purpose, Context, Effectiveness • Answer what the system is trying to achieve, why, and how well • Learn about the situation • Align the stakeholders and the team • Get commitment to action • Enables • Eliminating costly, complex unnecessary features

• Adding simple features that bring great value • Identifies and addresses entangled social and technical issues

107

Appreciating the Enterprise Perspective: Insights from Andrew McNaughton / HS2 • “Why” is not an engineering decision

• The why behind your system is business, social, or political • Consultation (listening) • The only way you get permission • The only way to get engagement • Requires engaging the other party on their terms • From their perspective • In their notation • "95% of evidence is why we didn't do something" • Decisions, process, and evidence will be challenged

108

MBSE with GENESYS

Understanding the Operational Architecture: What the System Will Do and Why • Defines the missions and in what scenarios • Interactions with other systems & environment • Measures of operational performance for interactions • Operational concept (how the system will perform its mission & how it will fulfill its purpose) • Considers sunny and rainy day scenarios • Reflects who will use the system and how it will

evolve over time • Operator context • Perception of value • …

109

Requirement

refined by

Capturing and Structuring the Problem

110

MBSE with GENESYS

Requirements Capture in Context

0. Define Need & System Concept

Activity bars represent movement of “center of gravity” of systems engineering team (concurrent engineering is assumed)

1. Capture & Analyze Orig. Requirements 2. Define System Boundary 4. Derive System Threads 3. Capture Originating Architecture Constraints

5. Derive Integrated System Behavior 6. Derive Component Hierarchy

7. Allocate Behavior to Components

SCHEDULE

8. Define Internal Interfaces

9. Select Design

10. Perform Effectiveness & Feasibility Analyses

11. Define Resources, Error Detection, & Recovery Behavior

12. Develop Verification & Validation Requirements/Plans

13. Generate Documentation and Specifications

111

Where Do You Find Requirements? Reflections of Enterprise Perspective and Operational Architecture • System Concept Paper • Executive Order • Concept of Operations • Statement of Work

• Vendor Package/Contract • Preliminary Specification

• Change Request Trade Study Report • Standards (MIL-STD or Commercial) • Meeting Minutes (approved)

• Business Plan • Market Analysis

112

MBSE with GENESYS

Desired Characteristics of Requirement Statements

• Necessary – remove it if the statement is not needed • Implementation independent – state what is required, not how the requirement is met • Unambiguous – generates a common understanding • Complete – can be understood in isolation

• Singular – addresses one thought • Feasible – is inherently possible • Verifiable – can confirm the requirement is satisfied • Correct – properly expresses the stakeholder expectation • Conforming – conforms in look and feel to organizational standards

Additional information available in INCOSE Guide for Writing Requirements

113

Desired Characteristics of Requirement Sets • Complete – represents the full definition of the stakeholder expectations • Consistent – reconciled and individual statements do not conflict with one another • Feasible – can be satisfied by a solution that is obtainable within life cycle constraints • Bounded – establish the system scope and do not address subjects outside that scope • Structured – organized such that sub-sets of requirement statements can be identified Additional information available in INCOSE Guide for Writing Requirements

114

MBSE with GENESYS

Overview Picture of the Geospatial Library (GL)

Customers

Image Collectors

Geospatial Library

115

Reviewing the Geospatial Library Source Document

See Handout

116

MBSE with GENESYS

Capturing and Decomposing Originating Requirements • Capture the source document • Extract top-level or parent source requirements capturing source attributes (paragraph title, paragraph number, origin, etc.) • Provide traceability from the source document to the parent originating requirements • Decompose composite source requirements being careful not to change the meaning • Provide traceability from each parent requirement to its children • Continue the decomposition of requirements into “children” until each leaf-level requirement is a single, verifiable statement

117

Capturing Requirements: A Visual Perspective

• Objective is source requirements in single, verifiable statements (decompose composite requirement statements) • Record source requirement statement in the description attribute of a Requirement • Reflect traceability between source document and first level Requirement with documents/documented by relationship • Maintain traceability between parent Requirement and child Requirement with the refined by/refines relationship

documented by

Source Document

System

documents

X

Parent Requirements

refined by

refined by

Child Requirements

refined by

Leaf node Requirements trace to other entities

118

MBSE with GENESYS