Model-Based Systems Engineering with GENESYS

Model-Based System Engineering with CORE ® Model-Based Systems Engineering with GENESYS TM

Course Material t ri l r

Vitech Corporation 2070 Chain Bridge Road Suite 100 Vienna, Virginia 22182-2536 703.883.2270 www.vitechcorp.com Vitech Corporation 2270 Kraft Drive Suite 1600 Blacksburg, VA 24060 540.951.3322 www.vitechcorp.com

Copyright © 1995-2019 Vitech Corporation. All rights reserved.

No part of this document may be reproduced in any form, including, but not limited to, photocopying, translating into another language, or storage in a data retrieval system, without prior written consent of Vitech Corporation.

Restricted Rights Legend

Use, duplication, or disclosures by the Government are subject to restrictions as set forth in subparagraph (c)(1)(ii) of the Rights in Technical Data and Computer Software clause at DFARS 252.277-7013.

Vitech Corporation 2270 Kraft Drive, Suite 1600 Blacksburg, VA 24060 540.951.3322 www.vitechcorp.com

is a trademark of Vitech Corporation and refers to all products in the GENESYS software product family.

Other product names mentioned herein are used for identification purposes only, and may be trademarks of their respective companies.

(Revision Date – February 2019)

Model-Based Systems Engineering with GENESYS™

Version: 2018 RevB

1

Administrative Details

• Food

• Coffee, juice, snacks, etc. • Lunch

• Conveniences • Restrooms • Telephones

• Schedule • Lab hours • Questions and answers

Introductions

2

Overall Course Objectives

• Introduce a model based systems engineering process / methodology that is consistently successful • Demonstrate how to implement this methodology using an automated toolset • Solve a sample problem while at the same time, generate representative SE documentation • Provide SE knowledge and skills to take back to your team and organization

3

System Engineering and MBSE Concepts

4

Introductory Section Objectives

• Systems Engineering (SE) • What is Systems Engineering • Why do Systems Engineering • Model Based Systems Engineering • What is Model Based Systems Engineering (MBSE) • How does MBSE help? • Systems Thinking • Layered Approach (STRATA TM )

5

Systems Engineering

6

Systems Engineering (SE)

• What is Systems Engineering? • Fundamental Concepts • Who does System Engineering • When to do System Engineering • Why do System Engineering • Essential Elements of a system design

Systems Engineering

7

Definitions of Systems Engineering - INCOSE, http://www.incose.org/AboutSE/WhatIsSE

Systems Engineering is an engineering discipline whose responsibility is creating and executing an interdisciplinary process to ensure that the customer and stakeholder's needs are satisfied in a high quality, trustworthy, cost efficient and schedule compliant manner throughout a system's entire life cycle.

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 Engineers “Own” the Design

8

Other Definitions

“Systems Engineering is a (thought) process employed in the evolution of a need into an ultimate deployment.” Source: Blanchard and Fabrycky, 2nd edition, 1990; pg. 21 “Systems Engineering is the structured, multidisciplinary development of creating complex systems while minimizing risks and satisfying the customer.” Source: INCOSE 1992 “Systems Engineering is an interdisciplinary approach encompassing the entire technical effort to evolve and verify an integrated and life-cycle balanced set of system, people, product, and process solutions that satisfy customer needs.” Source: EIA 632

9

Fundamental Concepts

System

Definition of a System: A system is a construct or collection of different

elements that together produce results not obtainable by the elements alone. A Consensus of the INCOSE Fellows

Segment

Subsystem

Said another way: A System performs a function, transforming inputs to outputs and consists of a collection of interacting components with a common goal.

Assembly

Part

10

System Breakdown

System

• Segment - A grouping of elements that are closely related and which often physically interface. It may consist of elements produced by several organizations and integrated by one. • Subsystem - A functional grouping of components that combine to perform a major function within an element. • Assembly - A functional subdivision of a subsystem and generally a self-contained combination of items performing a function necessary for subsystem operation. A functional unit viewed as an entity for purpose of analysis, manufacturing, testing, or record keeping. • Part - An element that is not normally subject to further subdivision or disassembly without destruction of designated use.

Segment

Subsystem

Assembly

Part

11

Stakeholders in Systems Engineering -

End User Management (Sponsor / Customer)

Security

Mechanical Engineering

Manufacturing

✓

✓

✓

✓

End Users

Program Office

Software Engineering Configuration Management

Test Engineering

✓

✓

✓

✓

Executive Steering

Design Engineering Systems Engineering Electrical Engineering

Logistics Engineering

✓

✓

✓

✓

Acquisition

Training / HR

Purchasing

✓

✓

✓

✓

Contacts

Operations

Facilities

✓

✓

✓

✓

• Involving all stakeholders, • Soliciting stakeholder requirements • Provide balance • Find out what you don’t know • Communicate in terms they need and/or understand

12

Subject Matter Experts

• SMEs view their scope as the largest, most significant, most difficult • The Systems Engineer balances the perspective yielding a capable, cost effective, and timely system • The Systems Engineer optimizes all of the perspectives

Payload Perspective

Navigation Perspective

10%

10%

AllOthers

90%

AllOthers

Payload

90%

Navigation

Propulsion Perspective

Airframe Perspective

10%

10%

AllOthers

90%

AllOthers

Airframe

90%

Propulsion

Stakeholder view of Missile

13

When to Do Systems Engineering? The System Life Cycle Model (ISO 15288)

Highest level of SE intensity is concentrated in these phases

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

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 Life Cycle

14

Why Do Systems Engineering

• Cope with Complexity • Avoid Omissions • Avoid Invalid Assumptions • Manage Change • Design most efficient, economic, and robust solution • Greater design control

Hypothetical Project

Method 2 — Total Costs

Method 3 — Top-Down

Breakdown

Method 1 —

Project Phase

Bottom-Up Cost

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

15

Why Do Systems Engineering

• Cope with complexity • Avoid omissions • Avoid invalid assumptions • Manage change • Design most efficient, economic, and robust solution • Greater design control

Life-cycle cost commitment. SOURCE: INCOSE Systems Engineering Handbook Version 3, June 2006.

It is not hard to know when System Engineering fails, because when something important goes wrong it usually makes the news fast. - INCOSE

16

Not Doing Systems Engineering -Results in Failure

• Over one-third of all projects fail. • Over two-thirds will not achieve all their goals. • Failure is usually obvious only when the project is overdue and over budget.

ImageCourtesyof Pixabay https://pixabay.com/en/plane-crash-crash-crash-landing-62883/

17

Additional References …

You may want to pursue additional reading on the benefit of Systems Engineering, here are three excellent references: 1.) The Business Case for Systems Engineering: Comparison of Defense- Domain and Non-Defense Projects, Special Report CMU/SEI-2014-SR-013, by Joe Elm and Dennis Goldenson). Website: https://resources.sei.cmu.edu/asset_files/SpecialReport/2014_003_001_91760.pdf 2.) The Guide to Lean Enablers for Managing Engineering Programs, Pub. by Joint MIT- PMI-INCOSE Community of Practice on Lean in Program Management, Edited by Josef Oehmen, May 2012. Website: https://dspace.mit.edu/bitstream/handle/1721.1/70495/oehmenetal2012- theguidetoleanenablersformanagingengineeringprograms.pdf?sequence=4 3.) Systems engineering return on investment, January 2013, Doctoral Thesis by Eric C. Honour, Defense and Systems Institute, School of Electrical and Information Engineering, University of South Australia. Website: http://www.hcode.com/seroi/documents/SE-ROI%20Thesis-distrib.pdf

18

Model Based System Engineering

19

Learning Objectives

• Define Model Based Systems Engineering • Relate MBSE and systems engineering • How is MBSE different than SE • Why do MBSE

• MBSE Process and Approaches • How, when and why to use MBSE

20

Systems Engineer’s Desktop

Engineering Handbooks

Trade Studies

Function Lists

Open Actions

Extracted Requirement s

Traceability Documents

Source Requirement s

Graphical Data

We can determine complicated outcomes. We can only enable complex outcomes. We can specify complicated systems. We can only intervene in complex systems. Irene Ng, Complicated vs Complex Outcomes “

21

Definitions of Model Based Systems Engineering?

“ Model Based Engineering (MBE): An approach to engineering that uses models as an integral part of the technical baseline that includes the requirements, analysis, design, implementation, and verification of a capability, system, and/or product throughout the acquisition life cycle.” Final Report, Model -Based Engineering Subcommittee, NDIA, Feb. 2011 “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 (INCOSE - TP - 2004 - 004 - 02, Sep 2007)

22

Model-Based Systems Engineering

• Methodology is a paradigm shift • System model provides essential and required data • System model includes the system design, engineering views and specification documents • System specifications are complete, current and consistent • Model captures design decisions

Systems Engineering

23

How is MBSE different from SE?

MBSE is an extension/expansion of SE MBSE is a methodology implemented into a tool/design environment An MBSE Model consists of a language, structure, argumentation and presentation elements • System Definition Language is clear and unambiguous thereby promoting understanding across a broad spectrum of the population • Structure allows the full integration of the system’s control aspects with the system’s external observables • Argumentation is provided through the integration of the language and structure • Presentation of the reasoning (argumentation) occurs through model-generated views (both graphical and textual)

24

Why Do MBSE

• MBSE enables the systems engineer to: • Cope with complexity • Avoid omissions • Avoid invalid assumptions • Integrated consistency and completeness checks • Traceability to identify potential impact of change

• Automatic, integrated document and view generation (specifications and design documents, diagrams [including SysML], ad-hoc reports) • Information exists exactly once and referenced many times • Expose entire design model to all stakeholders Allow SE’s to deal with large volumes of data, quickly and efficiently.

It is not hard to know when System Engineering fails, because when something important goes wrong it usually makes the news fast. - INCOSE

25

Not Doing MBSE Systems Engineering

• Cost Growth • Schedule Delays • Quality Deficiencies • Inconsistency • Failure to Achieve • Architectures,

• Seamless Upgradeability, • Modularity • Non Retrievable Design History

There is never enough time to do a job right the first time, but there always seems to be enough time to do the job again

26

The MBSE Process: Inputs and Outputs

Systems Engineering Process

System Specs & Custom Reports

Expertise

Source Documents

System Design Model

The systems engineering process needs to support top-down, middle-out, and reverse engineering approaches to system specification and design.

27

Model Essential Characteristics

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

28

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

SYNTHETIC THINKING is a way of thinking about and designing a system that derives the properties and behavior of its parts from the functions required of the whole. Synthetic thinking provides better understanding of complex systems than analytical thinking does because the whole has properties that none of its parts have. 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.

29

Dgn V&V

BEH

REQ

ARCH

Layer Of Detail

Source Documents

Docs

LAYER 1

Dgn V&V

BEH

REQ

ARCH

Docs

Docs

LAYER 2

Dgn V&V

BEH

REQ

ARCH

Docs

Docs

LAYER n Model-Based Systems Engineering Process

30

SE Activities Timeline - Top Down 0. Define Need & System Concept

Activity bars represent movement of “center of gravity” of systems engineering team. Concurrent engineering is assumed.

1. Capture and Analyze Originating Requirements

2. Define System Boundary

3. Capture Originating Architecture Constraints

4. Derive System Threads

5. Derive Integrated System Behavior

6. Derive Component Hierarchy

7. Allocate Behavior to Components

SCHEDULE

8. Define Internal Interfaces

9. Confirm Selected Design

10. Perform Effectiveness & Feasibility Analyses

11. Define Resources, Error Detection, & Recovery Behavior

12. Develop Validation Requirements/Validation Plans

13. Generate Documentation and Specifications

31

SE Activities Timeline Reverse Engineering

8. Update System Boundary

Then modify top-down

Find the top

7. Derive As-Built System Requirements

7a. Modify Reqts & Arch. Constraints

6. Derive As-Built System Threads

6a. Modify System Threads

5a. Modify & Decompose System Behavior

5. Aggregate to As-Built System Behavior

4a. Allocate Behavior to Components

4. Derive As-Built Behavior of Components

3a. Refine Component Hierarchy

3. Capture Component Hierarchy

2. Capture Interfaces

2a. Define Interfaces

SCHEDULE

1. Define System Boundary

9. Select Revised Design

10. Perform Effectiveness & Feasibility Analyses

11. Capture Error Detection, Resource, & Recovery Behavior

12. Develop Test Plans

13. Generate Documentation and Specifications

32

The Necessary and Sufficient Perspectives Required to Completely Specify a System

ffbd Product in Inventory

t.1.1

t.1.5

t1.Make Information Request

t1.Provide Product To Customer

User

System

AND

AND AND

AND

t.1.3

t.1.4

t.1.2

t1.Accept& Format Request

t1.Get Product From Inventory

System

User

t1.AcceptProducts

Control View (FUNCTIONS & Control Constructs)

Project:

Organization:

Date:

IMS

October 13,2010

n2 Thread 1 - Product In Inventory

t.1.1

t1.Make Information Request

t1. Information Request

Input – Output View (INTERFACE)

t.1.3

t1.Accept & Format Request

t1.Formatted Request

t.1.2

t1.Accept Products

t.1.4

t1.Get Product From Inventory

t1.Inventory Product

t.1.5

Physical View (COMPONENTS)

t1.Provide Product To Customer

t1.Collection Products

Project:

Organization:

Date:

IMS

October 13, 2010

REQUIREMENTS – related across all of these elements to define or specify the performance, functionality, and constraints of the individual element.

These perspectives provide the basis for knowing when you are done. NOTE: Selection of views is important; some provide more insight than others.

33

Applying MBSE

Process Inputs:

• Source Rqmts. • Change Requests

Behavioral Analysis • System Behavior Models • Inputs/Outputs • Control/Sequencing • Performance Rqmts.

Architecture/ Synthesis • System Architecture • Components • Interfaces • Allocated Requirements

Source Requirements Analysis • Originating Rqmts. • Concerns and Decisions • Risks

Automated Document Generation

3.1

General

Requirements

3.1.1

3.1.2

3.1.3

Systems Engineering Repository

Accept

Retain Inventory

ControlMultiple

Requests

Sensors

Design Validation and Verification • Analysis • Verification Methods • Test Plans

Process Outputs: •System Req Documents •System Design Model •Exports to Other Tools

34

Diagrams- Models

Diagrams flow from the Model

35

Relating SysML to MBSE

“SysML provides a means to capture the system modeling information as part of an MBSE approach without imposing a specific method on how this is performed. The selected method determines which activities are performed, the ordering of the activities, and which artifacts are created to represent the system.” (emphasis added)

From: Friedenthal, S., Moore, A., & Steiner, R. A Practical Guide to SysML, Morgan Kaufmann OMG Press, 2009, et al.

Generate SysML Consistent Views from the MBSE Model

36

Systems Engineering Review

• Understanding what to do in systems engineering is easy. • Doing systems engineering well is difficult. • Managing complexity is a major challenge. • Good systems engineering needs: • Robust systems engineering process • Tools that support the process • Effective communication • Documented procedures and standards • Supportive technical management • Proactive engineers MBSE Tools Aren’t a Silver Bullet; Engineers Innovate; Tools Support Consistency, Coherence, and Integration

37

GENESYS Environment

38

GENESYS Concept of Operations

Data Interchange Files

Keyboard Entry, Data Extractors, & Parsers

SE Expertise

Inputs

Model

Formal Specifications

Custom Reports, Queries, & WEB Publishing

Views

39

The GENESYS Technology • GENESYS System Definition Language

• An Information Model that provides a structure to capture and communicate all aspects of the system

• Based upon the language of the systems engineer: • A language of key words, relationships, and symbology • A language that encodes the contextual significance of each element in the system definition • GENESYS System Design Repository • Contains and preserves the integrity of the System Model • Latest and greatest engineering is available to the entire engineering team • GENESYS Graphical View Generators • Guarantees consistent views • Updates to any view result in automatic updates to all other affected views to maintain consistency

The GENESYS Technology empowers engineering teams to build a complete and integrated System Definition.

40

GENESYS Architecture

User Interface, Reports, Scripts, Simulation, API Applications

Model Consumer

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

41

GENESYS Product Suite

• GENESYS Collaborative Edition • Limited, local repository supports up to 5 concurrent connections • GENESYS Server • Unlimited repository and connections leveraging full editions of SQL Server • GENESYS Web Server • Currently, provides read-only web access to data model via ASP.net, IIS

42

Collaborative Edition

• Supports up to 5 concurrent connections • local, network, or API applications

• Can connect to remote services • SQL Server 2008 R2 Express • 10 GB database limitation • Uses only 1 processor • Uses only 1 GB RAM • Provided with GENESYS Install

43

Collaborative Edition Architecture

Single Computer Genesys.exe

Collaborative

Model Consumer

Model Consumer

Client API

Client API

Services

GENESYS 4 Collaborative Edition Services Host [windows service]

Database

Services

GENESYS Server

SQL SERVER (GENESYSCOLLAB) [windows service]

Services

Database

Database

44

GENESYS System Definition Language

SDL is an Extended Natural Language in ERA Format

GENESYS Language

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)

Attribute of Relationship

Adverb

Structure

N/A

• Viewed as Enhanced FFBD or FFBD

45

A Partial SE Example

DOCUMENT

documents (documented by)

documents (documented by)

• Number • Description • Type

COMPONENT

REQUIREMENT • Number • Description • Type • Origin

specifies (specified by)

• Number • Description

• Type • Cost

FUNCTION

• Number • Description • Duration • Exit Logic

performs (allocated to)

specified by (specifies)

46

GENESYS WALK-THROUGH

47

GENESYS Walk-Through

• Examine Project Explorer

• Facilities, Folders, Filters, Sort Blocks • Entity Browser Views • Property Sheet • Hierarchy • Function Flow Block Diagram (FFBD) • Enhanced FFBD (EFFBD) • N2 Diagrams • Interface Block • Physical Block Diagram

• GENESYS Reports • Simulator • Schema Editors

48

Starting GENESYS

From the Start menu: Select All Programs Select GENESYS 6.0 Folder Select GENESYS 6.0 Collaborative Edition

49

GENESYS Login

Type Password (“admin”) Click OK

NOTE: this is an Administrator account,

which we will use in class. You will not use this account on a day-to-day basis.

You can choose your repository

50

GENESYS Registration Screen

Registration as a First Time user on your computer will add you to the Vitech User’s Group.

51

GENESYS Starting Screen

52

GENESYS Importing a Project

1.

1. Click “G”, then “Import” 2. Navigate to folder 3. Select .gnsx file to import 4. Click OPEN button

2.

3.

4.

C:/Program Files (x86)/Vitech/GENESYS 6 Collaborative Edition/Samples/Project Samples

53

Application Menu

Provides access to global commands

Click the “G” Ball to get to the Application Menu

Import & Export used to bring or save an individual project to the GENESYS data repository Note: In GENESYS information added to a project is saved in the project database without the need to “save repository” or “export project”

54

Opening a Project

1. Click “Import” 2. Navigate to folder (Project Samples) 3. Select “Fast Food Sample” file

1.

2.

3.

55

GENESYS Import Wizard Steps

56

BASIC CONCEPTS

57

Opening - SAMPLE: Fast Food project

1. Select the Project 2. Click the OPEN button

1.

2.

58

Project Property Page

This page provides top level information on how the project is set up. Organization and Customer Information is provided on this page. Additional project set up information at the bottom of the page.

59

Project Explorer

Menu Bar Ribbon Bar

Project Repository Facilities/ Classes

- Click on Class (Component) and then select an Entity (Fast Food System) - Properties of the Entity in Property Sheet on Right Hand Side of frame

60

Ribbon Bar Controls

Application Menu

Undo Redo Commands

Navigation Commands

Command Tabs

Context Sensitive Commands (highlight or shaded based on selected entity in the model)

61

Facilities and Entities

New entities can be created by typing a name in the “Create” window.

Project Explorer Window is used to navigate around the project.

Browser Window: Shows the entities in the selected Class. An entity is an element in the model which can be uniquely identified in a particular class.

Facilities contain sets of related classes based upon your role in the project.

62

Project Explorer

Ribbon Bar Select Tabs

Browser Panel: List of Entities in the selected Class

Property Sheet (content changes based the Tab

and Class Selected)

Selection Tab

63

Property Page

Double-click an Entity to open its Property Sheet in a

separate window

Attributes

Relationship target entities

List of possible relationships

Relationship attributes

64

Properties Tab

65

Parameters Tab

Click on Parameters Tab.

Click “Add/Remove” to edit Parameters for an entity. Add values to the appropriate category.

66

Diagnostics Tab

Click on Diagnostics Tab – provides information on completeness and integrity of entity to overall design. Checkers are customizable and results can be provided in a report by project or class.

67

Attribute Versions

Versioning Icon

Current

Prior

68

Definitions: Schema and Facilities

• Schema • Collection of all entity classes, attribute types, and relationships that are available to the system designer; i.e. the embodiment of the system definition language excluding the structural aspects • Facility • Collection of related entity classes grouped together for visibility • Subset of the total schema • All Classes – all entity classes • Essentials – entity classes used for basic systems design management •

Program Management Facility – entity classes used for program management • Systems Engineering Facility – entity classes used for systems engineering • Verification Facility - entity classes used for verification definition and tracking

69

View Window Select the Component Fast Food System, Select the View Tab, Then select the BDD icon

View Ribbon Bar

Entities Tabs

Constructs

70

Exit GENESYS

EXPORT – allows you to save a GENESYS Project File

EXIT – Exits GENESYS. Project Data is written to underlying SQL database as work is done and is available when you start next session.

71

Integrating the Repository and View Generators Provides Consistency

Functional Views

Requirements Views

System Design Repository

Physical Views

Functional Timelines

72

SETTING UP YOUR PROJECT

73

Getting Started with GENESYS Characterizing Users and Projects

• Creating a new user account • Creating a new project • Setting project permissions • Setting user preferences

74

Creating a New User Account

Select either

Admin Tools icon from the ribbon

Or

Administrative Tools from the splash screen

75

Create a New User Account

Select User Tab. Select New User Icon

Selecting “New User” will open a dialog window for create a User Account (next page)

76

Create a New User Account

In the Create New User window

• User Name: – enter “Systems Engineer”

Note: User names must be at least two (2) characters in length

• Password: – enter “Welcome”

Note: Passwords must be at least five (5) characters in length

• Confirm Password: – Re-enter your password exactly as you typed it above

When you are finished, click OK

77

Edit User Account Details

Add New User Account Details and User Privileges

User Properties:

Double-click the New User account

Or

Select Edit User

78

Group Properties

Groups Tab allows you to: (a.) set up a New Group (b.) Edit Group (c.) Delete a Group

BEST PRACTICE: - Set up User Accounts - Set up Groups (for a project) - Assign Users to Groups

79

Creating a New Project

From “Home”: (a.) Select “New Project” (b.) Set Project Name (c.) Select Schema type (d.) Review/change selections

For the class, create a new project using the name: Geospatial Library Class Project

80

Project Explorer: Properties

Basic Project properties are set on the Project Property Page.

- Enter Org Name and Address

- Enter Customer Name and Address

- Set Base Path and Graphics

(NOTE: these attributes are used for document generation and for External File locations.)

Base Path -> C:\Program Files x86\Vitech\GENESYS 6 Collaborative Edition Graphics -> C:\Program Files x86\Vitech\GENESYS 6 Collaborative Edition\Bitmaps

81

Setting Project Permissions

In Administrative Tools, Project Tab: - Click “Set Project Permissions”

- Selection User or Group - Select and set permissions

Administer a Project’s Access Control List by selecting Project > Set Project Permissions User/Group Permissions are set by checking the appropriate boxes for: – Read – Update – Create – Delete – Full Control

82

Entity Permissions

In the Browser

• Select an Entity • Right-click > Set Entity Permissions

• Set Read, Update, Delete, and/or Full

Control to set the entity permissions for each User/Group.

NOTE: If you do not need to delineate privileges for your project, check administration to automatically activate all privileges. GENESYS will run faster this way.

83

Attribute Permissions

In the Browser

– Select an Entity – Right mouse click > Set Attribute Permissions • Select Attribute first • Then set Read, Update,

Delete, and/or Full Control to set the entity permissions for each User/Group.

84

Preferences – Project & User

Project Preferences – for the Project User Preferences – User customization

User Permissions

85

Simplified MBSE Process

86

Overview

• Define the system • Capture originating requirements • Evaluate a source document • Extract requirements • Define the system boundary

• Define the system behavior and physical architecture • Allocate the behavior to the physical components

87

Essential Tasks Before You Start Development Activities Plan the activity • Prepare a Systems Engineering Management Plan (e.g., SEMP) • Tailor the plan to your project Make sure you assign responsibility • Define the people who retain authority over the system requirements, behavior, architecture, interfaces, and test and integration plan

88

Dgn V&V

BEH

REQ

Layer of Detail

ARCH

Source Documents

Docs

LAYER 1

Dgn V&V

BEH

REQ

ARCH

Docs

Docs

LAYER 2

Dgn V&V

BEH

REQ

ARCH

Docs

Docs

LAYER n

Model-Based Systems Engineering Process

89

Requirements

CAPTURE ORIGINATING REQUIREMENTS

90

Candidate Source Documents

• 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

• Business Plan • Market Analysis

91

Capture the Originating Requirements “Making Sure That We Solve the Right Problem”

• Start by extracting the first-level requirements from the source document(s) in order to gain an understanding of the top-level context of the system. • Next capture the “children” of the first-level requirements, creating Concerns as necessary. • The objective is to continue the hierarchy of extracting “children” until each leaf- level requirement is a single, verifiable statement.

92

Geospatial Library (GL) Overview

93

GL Source Document

See H-1

94

Requirements Activities • Capture top-level or parent source requirements • Provide traceability from the source document to the parent originating requirements • Capture various source requirement attributes: – Source document paragraph title, paragraph number, and origin – Capture requirement type such as composite, constraint, functional, performance, test, or verification • Decompose composite source requirements, be careful not to change the requirements’ meaning • Provide traceability from each parent requirement to its children • Prefer hierarchy organization but flat file organization of requirements is acceptable

95

Multiple Ways to Capture Requirements

• Copy & Paste/Paste Unformatted commands • Parse requirements into GENESYS • Import requirements into GENESYS using the Excel Connector features

96

Entities Used for Requirements Capture

Component (System)

documents (documented by)

Document

built from (built in)

refined by (refines)

documents (documented by)

augmented by (augments)

Requirement

ExternalFile

refined by (refines)

97

The Requirements Capture Approach

• GOAL: Source requirements in single, verifiable statements. (Need to break-up composite requirement statements.) • Record source requirement statement in the Description attribute of a REQUIREMENT. • Obtain traceability between source document and first level REQUIREMENT with documents/documented by relationship pair. • Obtain traceability between parent REQUIREMENT and child REQUIREMENT with the refines/refined by relationship pair.

documentedby

Source Document

System

documents

X

Parent Requirements

refinedby

refinedby

Child Requirements

refinedby

Leaf node Requirements trace to other entities

98

Planning for Document Parsing

Each source document is different in its content and structure. Consequently, one needs to plan the strategy for extracting requirements. • Identify requirement document passages where requirement statements cluster – why did the customer group certain requirements together? • Identify other classes involved in the extraction process • Plan to remove parsed requirement statements with empty descriptions and plan to “fill in” some empty descriptions with combined requirement statements; to create a “composite” requirement • Know how to distinguish a functional requirement from a performance requirement • Know how to distinguish a constraint requirement from a functional requirement

99

Open the Document Parser

Use “HOME” Ribbon Bar. Select “Document Parser”

- which opens the Document Parser dialog box.

Clicking “Select” button allows for creation of new DOCUMENT entity to capture the source document. (see next slide)

NOTE: Class and Folder into which items will be placed.

Keywords used in the parser algorithm.

100

Create a Source Document Element

Once the “Select” button is activated, the “Select Document for Root Entities” dialog box is opened:

Steps: 1. Click: “New” 2. Enter Name 3. Click: “OK”

This creates a new Document Element which will “ document ” all of the elements once parsed into the model.

101

Load the Source Document

Load the Document to be parsed. 1. Click “Load Document”

2. Navigate to: C:\Program Files x86\Vitech\GENESYS 5 Collaborative Edition\Samples\Project Samples 3. Select the file named: “GeospatialLibrarySourceDocument”

4. Select: OPEN

This will pull the document text into the white space in the Parser (see next slide…)

Note: Documents of type .docx, .doc, .htm, .html, .rtf, .txt can be loaded into the Document Parser

102

Parsing the Document

Click on : “Parse Document”

- this action will create elements in the selected class/folder in the project model - statements in the text that include the Keywords will be given a Name that includes “Requirement…”

Parsing creates ALL elements. The elements are edited in the model.

103

View the Parsed Requirements

In the Project Explorer: - Select Database

- Select Essentials (from the drop-down Facilities menu) - Select Requirement Class

104

Edit the Parsed Requirements

Delete Entities 1.0, 2.0 and Debris 0001

Why? - No requirement content.

Three ways to Delete an entity: a. Right Click -> Select Delete b. Delete (in Home Ribbon Bar) c. Use Delete Key

105

Edit Debris 0010 - (Transform an Element)

Select Debris 0010 Right click and select Transform Class…

Select Document Class and Click OK

Provide Transformed Entity Name of: “EIA 632”

These actions will move the entity out of the REQUIREMENT Class and into the DOCUMENT Class.

106

Edit EIA 632

Select DOCUMENT Class and EIA 632 entity.

Edit the attributes as shown.

Scroll down to Non-Gov’t Category and select “STANDARDS”

Then relate this element to the GL Source Document. (Select “referenced by” in Relationships Window; then double click to get new dialog window; make selection and click OK).

NOTE : All Entity Attributes are on the Attribute Tab. Scroll down to see the complete list.

107

Edit Debris 0002

1. In the REQUIREMENT Class; Select the Debris 002 entity and copy the Description attribute text. 2. Navigate to the DOCUMENT Class; Select the GL Source Document entity and paste the Debris 002 text in the Description attribute.

3. Then, Navigate back to the REQUIREMENT Class and Delete Debris 0002

108

Edit Document: Geospatial Library Source Document Open a Property Sheet by double-clicking on the entity in the Browser list.

Description (from Debris 002) Edit External File Path attribute.

NOTE : Building an entity’s attributes and relations can be done in either the Project Browser – Property view or in a Property Sheet.

109

Reminder: External File Path

- Click on Ellipses Button - Navigate to desired folder

- External File path is a Hyper-link to an external file. - The Base file path is set in the Project Property Page.

110

Edit Additional Attributes…

Scroll down… - Set Type - Set Non-Govt. Category

111

Create Component: Geospatial Library Select the COMPONENT class and create “Geospatial Library” by double-clicking on the class name.

Double-click on the entity “Geospatial Library” to open a Property sheet. Double-click on the relationship documented by and add “target” GL Source Document. Get Description from Debris 003 and Mission from Debris 007. Then Delete Requirements: Debris 0003 – Debris 0009 Why? No requirement content

Debris 003’s description

Set Type = System

Debris 007’s description

112

Editing General Requirements Re-specify top-level requirements by:

1. Delete 3.0 General Requirement

2. Select 3.1 General Requirement 2 Rename to Specific Requirements

3. Edit the description of Specific Requirements to include the definition from General Requirements 2.1 through 2.7 ( PRINCIPAL : No Requirement’s description shall be empty.) 4. Double-click on documented by Select GL Source Document 5. Set Type = Composite and Set Origin = Originating

113

Edit GENERAL REQUIREMENTS 1

Rename: GENERAL REQUIREMENTS 1 to “Continuous Support and Availability”

Set Number R.1

Set Type = Composite Set Origin = Originating

Double-click on documented by Select GL Source Document

114

Renumber Requirements

Select Requirement R.1 Then, Right click and select Renumber from the menu window.

Receive Renumber Warning

New number should be “R.1”, select OK.

This will renumber the elements in Hierarchy below the R.1 branch

Renumber will assign Hierarchical numbering down the hierarchy tree of the element selected

115

Renumber Requirements

Select 3.1 Specific Requirements Then, Right click and select Renumber from menu window

Type in new number “R.2”

Select OK

This will renumber the Specific Requirements.

NOTE: The REQUIREMENT class uses “refined by” as the Parent – Child relation. Parent – Child relation determines the hierarchy. The parent – child relation is unique within a Class

116

Renamed Requirements

Rename Requirements as indicated.

NOTE : Rename Requirements one of three ways: Ribbon Bar Button, Right- click and select from Pop-up Menu, Select Name on Property Page.

117

Composite Requirements Requirements R.1 and R.2, R.2.1, R.2.2, R.2.3, R.2.7 contain multiple requirement statements; meaning they are “composite” requirements. Therefore -> Set Type = Composite.

118

Attributes of a “Good” Requirement

We want requirements that at least meet some basic criteria to be acceptable.

There are many paradigms for requirement statements. Perhaps the easiest of these is having a “SMART” Requirement:

S – Specific – specify a singular, unique aspect of the intended system M – Measurable – quantify one “thing” in the requirement statement A – Assignable – we can assign an organization to meet the requirement R – Realistic – state requirements that can be realistically be met or achieved T – Time-Related – we can achieve the requirement within the time frame of the project

There are many lists of characteristics for good requirements. One good source for further study is the INCOSE Systems Engineering Handbook, 4 th

Edition, Section 4.3.2.2 which elaborates an extensive list of “Characteristics and Attributes of Good Requirements.”

119

Break-up Composite Requirements Composite Requirements need to be broken down into “single” requirement statements Goal is to: ▪ Break up Originating Requirements without changing the meaning ▪ Maintain Traceability to Originating Requirement and Originating Document Steps to create new child requirements from composite parent requirements: 1. Create New Requirement 2. Copy Parent Requirement Description attribute

3. Paste and then Edit Description in New Child Requirement 4. Relate Parent to Child using “ refined by / refines” relation 5. Provide traceability by setting Origin type

120

Decomposing R.2.1

Create new requirements such that: R.2.1 Accept Requests from Certified Customers is refined by : R.2.1.1 Accept Requests and R.2.1.2 Certify Customers

Last Step: Renumber R.2.1

121

Decomposing R.2.2

Create new requirements such that: R.2.2 Retain Inventory and Provide Products is refined by : R.2.2.1 Provide Products and R.2.2.2 Retain Inventory

Last Step: Renumber R.2.2

122

Decomposing R.2.3

Create new requirements such that: R.2.3 Control Multiple Collectors and Collector Types is refined by : R.2.3.1 Control Multiple Collector Types and R.2.3.2 Control Multiple Collectors

Last Step: Renumber R.2.3

123

Decomposing R.2.7

Create new requirements such that: R.2.7 Monitor and Assess Performance is refined by : R.2.7.1 Assess Self Performance and R.2.7.2 Monitor Self Performance

Last Step: Renumber R.2.7

124

Filters and Sort Blocks

125

Filters & Sort Blocks

To Edit Sort Blocks Expand or Filters: Navigate to the Data Ribbon Bar And select appropriate button.

NOTE: Filter and Sort Blocks are also accessible via the Utilities Folder in a Project.

Filters and Sort Block selection menu

126

Creating a New Filter

1. Click on New Filter Button 2. Enter Name, Click OK 3. Create New Filter using drop- downs on right hand side

- Select Attribute - Select Attribute Field - Select Operator - Type in Value

* Create a filter to display the Composite Requirements (ONLY), as shown above.

127

Filtered View

Filtered View: changes the background color in the Browser pane so that you can tell visually that a filter view is being shown.

128

Creating/Editing Sort Blocks

Easy way to create a new Sort Block is to duplicate an existing Sort Block and modify the new one to achieve the desired sort and representation.

129

Saving Your Work

130

GENESYS File Types

• GENESYS “auto saves” current project information directly in the SQL database as you construct the model. • You can close GENESYS and all the information currently residing in the project will be available when you re-open GENESYS • Individual project files can be saved as a .gnsx files • Select “G” or Home button (upper left-hand location) • Select Export • Save project file with a unique name

131

The Export Command

During a session, we recommend exporting the database periodically

132

The Exit GENESYS Command

• Exits GENESYS

• Option to: Stop Services

There is no need to exit now, this is shown as an example.

133

Documenting Your Work

134

Artifact Generation – Anytime during development

0. Define Need & System Concept

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

4. Derive System Threads

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 Validation Requirements/Validation Plans

13. Generate Documentation and Specifications

135

Create a Requirement Table (using Excel Connector) 1.) Install the Excel Connector (Run Excel.exe file provided with GENESYS installation, work through the installation menus) 2.) Open Excel, review the GENESYS Excel Ribbon Bar …

Section 1: Allows you to login to GENESYS Project

Section 2: Allows you to Create, Manage, and Publish the excel spreadsheet (or table).

Section 3: Allows for publication of defined Dashboards

136