4-day-mbse-with-core9_2018-reva

Model-Based System Engineering with CORE ® Model-Based Systems Engineering with CORE ™

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 registered trademark of Vitech Corporation and refers to CORE software,

training, and related services.

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

(Revision Date – March 2018)

Model-Based Systems Engineering with CORE ®

Rev: 2018‐RevA

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

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

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 Said another way: A System performs a function, transforming inputs to outputs and consists of a collection of interacting components with a common goal.

Segment

Subsystem

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 Software  Engineering Configuration  Management Training / HR

Manufacturing









End Users

Program Office

Test Engineering









Executive  Steering Acquisition

Design  Engineering Systems  Engineering Electrical  Engineering

Logistics  Engineering 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 Payload

90%

AllOthers Navigation

90%

Propulsion Perspective

Airframe Perspective

10%

10%

AllOthers Airframe

90%

AllOthers Propulsion

90%

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

Total Costs 

Method 3 — Top‐Down 

Breakdown

Method 1 —

Method 2 —

Project Phase

Bottom‐Up Cost

Requirements

1 x 8 x

1 x

1 x 4 x 7 x

Design

3 ‐ 4 x

Build

16 x 21 x

13 ‐ 16 x 61 ‐ 78 x

Test

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.

Image Courtesy of 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.pd f 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

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

Systems Engineering

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

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

The systems engineering process needs to support top‐down, middle‐out, and reverse engineering approaches to system  specification and design. System Design Model

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

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. A SYSTEM is a whole that cannot be divided into independent parts without losing  its essential characteristics as a whole.

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 3. Capture Component Hierarchy

3a. Refine 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 t1.Accept& Format Request

t.1.4

t.1.2

t1.Get Product From Inventory

System

User

t1.Accept Products

Control View  (FUNCTIONS & Control Constructs)

Project:

Organization:

Date:

IMS

October 13, 2010

n2 Thread 1 - Product In Inventory

t.1.1

Input – Output View (INTERFACE)

t1.Make Information Request

t1. Information Request

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

Physical View (COMPONENTS)

t.1.5

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

Systems Engineering Repository

3.1.1

3.1.2

3.1.3

Accept Requests

Retain Inventory

ControlMultiple Sensors

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

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

34

MBSE–Views–Specifications-Simulations

1.2

Center Support Personnel

Human

bdd Collectors

2

3

Sensors

Comm

External System

External System

CSP to ADP

Collectors

ADP to Support Personnel 1.1

Status

hierGeneral Requirements

ADP

Subsystem

R.1

EnR cont

Local-Comm General Requirements Requirement Comm-Local Unmanned Aerial Vehicle

1.3

TermR cont

SRD.1

ADP to SCF

Sector Command Facility Facility

SCF to ADP

IMS Source RequirementsD... Document

Satellite

effbd Thread 1 - Product In Inventory

1.4

LocalData

Local Comm refined by documents

refined by t.1.1 t1.Make Information Request

t.1.2

R.1.2 documents customers

documents

LocalData 2

R.1.1

Subsystem

SYS.1

R.1

R.2

t1.Accept Product

Image Management Sy... Component

Support Requirements Requirement

Specific Requirements Requirement

Support Requirements Requirement

C.1

Availability Requirement

Perform Customer Functions Customers

Project:

Organization:

Date: October 11, 2010 refined by

refined by

refined by

refined by

refined by

IMS CORE 7

t1.Collection Products

R.1.1 AND

R.2.1 Accept Requests Requirement t1.Information Request

R.2.2 Retain Inventory Requirement

R.2.3 ControlMultiple Collectors Requirement

causes R.2.4 Maximum Staff Requirement R.1 Staffing Per Shift Risk

Continuous Support Requirement

AND

Project:

Organization:

Date: September 26, ... generates t.1.3 t1.Accept& Format Request requests I.2

status

products

IMS

generates

t.1.4 t1.Get Product From Inventory

t.1.5 t1.Provide Product To User

I.1

system

Media of Requests Issue

Criteria for Determining Cert... Issue

0

t1.Inventory Product Operate Image Management System

t1.Formatted Request

AND

AND

ImageManagement...

Project: SAMPLE: ImageManagement (Base Sys...

Organization:

Date:

September 26, 2010

tasking

data

C.2

Perform Collector Functions

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

CORE Environment

CORE 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 CORE Technology

• CORE 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 • CORE System Design Repository • Contains and preserves the integrity of the System Model • Latest and greatest engineering is available to the entire engineering team • CORE Graphical View Generators • Guarantees consistent views • Updates to any view result in automatic updates to all other affected views to maintain consistency

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

40

Product Configuration

9 CORE 9.0

CORE Essentials Extensible repository (SE and architecture schemas) with structured analysis diagrams and COREsim CORE Spectrum Essentials plus SysML views and DoDAF reports

CORE Server

C A L

CORE2ne t

* CAL – Concurrent Access  License

41

CORE Provides a System Definition Language

SDL is an Extended Natural Language in ERA Format

CORE Language

English Equivalent

CORE Example

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

Class / Element Common Noun / Particular Noun

Relationship Verb

Attribute

Adjective

• Description • Number

Resource consumed by Function • Amount • Acquire Available (hold partial) • Viewed as Enhanced FFBD or FFBD

Attribute of Relationship

Adverb

Structure

N/A

42

A Partial SE Example

DOCUMENT • Description • Type

documents (documented by)

documents (documented by)

COMPONENT • Number • Description

REQUIREMENT • Number • Description • Type • Origin

specifies (specified by)

• Type • Cost

FUNCTION

• Number • Description • Duration • Exit Logic

performs (allocated to)

specified by (specifies)

43

CORE WALKTHROUGH

CORE Walk-Through • Examine Project Explorer

• Packages, Facilities, Folders, Filters, Sort Blocks • Element Browser Views • Property Sheet • Hierarchy • Function Flow Block Diagram (FFBD) • Enhanced FFBD (EFFBD) • IDEF0 • N2 Diagrams • Interface Block • Physical Block Diagram • Element Table • CORE Scripts • Element Extractor • COREsim • Schema Editors

45

CORE Walk-Through: Starting CORE From the Start menu: 1. Select All Programs 2. Select CORE 9 3. Select Empty Repository

46

CORE Walk-Through: CORE Login

1. Type Password (“admin”) 2. Verify Repository 3. Click Login 

Default: Local Repository (In practice, you may have several repositories  for different development projects)

47

CORE Walk-Through: Registered User

First Time Use – OPTIONAL: Fill in  information to register for  access to website user  information and notification  of Webinars. Option Buttons:  ‐ Register ‐ Remind Me Later  ‐ No Thanks

48

CORE Walk-Through Initial Screens (Project Explorer)

49

CORE Walk-Through Importing CORE Projects (pt. 1)

2.

1.

3. Navigate to Samples Folder 

4.

1. File – Import 2. CORE Data File … 3. Select Samples Folder 4. Select “FastFoodSampleSolution.xml” 5. “OPEN”

5.

50

CORE Walk-Through Importing CORE Projects (pt. 2)

51

CORE Walk-Through Opening an Imported Project

1. Click “Open Project: 2. Select the Project you want to open 3. Click the “OPEN” button

1.

2.

3.

52

SOME BASIC CONCEPTS

Project Explorer

Menu Toolbar

Packages

Facilities/Classes

54

Project Navigation

Packages & Facilities both assist in model management. Facilities group a set of classes  around a broad theme; i.e.,  Document Management, Systems  Engineering.  Packages are a user‐defined  collection of elements from multiple  classes. Packages are useful when  teams have responsibility for sub‐ portions of the model; i.e. a single  component.

Elements can be in multiple packages and folders

55

Facilities and Elements

Facilities contain sets of related classes.

Each class contains elements that represents a “thing” that can be uniquely identified.

New elements are  created by double‐ clicking on the Class  name.

56

Element Browser

Menu Bar

Icon Bar

Element List

Element  Property  Sheet

Parameter tab

Attribute tabs

Diagnostics  tab

View tabs

57

Attributes & Relations

Double‐click  on an Element  will open the  Element’s   Property Sheet  in a separate   window.

Attributes

Relationship  target elements

List of  possible  relationships

Relationship  attribute

58

Secondary Attributes

NOTE: Unique ID is a  locked attribute set  by the model when  the element is  created. This attribute is  used to index all  elements in the  database and  cannot be changed  by a user. 

59

Attribute Versions

Versioning Icon

Current

Base

60

Perspectives

Full Details: This viewpoint includes all attributes and relationships. System Context: This viewpoint includes the number, description, and a few  other attributes along with the minimal relationships.

61

Definitions: Schema and Facilities

• Schema • Collection of all element 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 element classes grouped together for visibility • Subset of the total schema • Essentials – limited set of classes, basic list of key elements • Program Management – element classes used for program management • Systems Engineering – element classes used for systems engineering • Document Management – element classes used for formal document generation • Verification - element classes used for verification definition and tracking • All Classes – all element classes

62

View Window Select the Component Fast Food System. Then, from the top view tabs list select the Structure Block Definition Diagram icon

View Tabs  to select 

Diagram Toolbar

other  views

Constructs

Entities

Table View of  display elements

63

Exit CORE

If you have made changes

If you have not made  changes

64

Integrating the Repository and View Generators Provides Consistency

Functional Views

Requirements Views

SRD.1

IMS Source RequirementsD... Document

documents

documents

documents

SYS.1

R.1

R.2

Image Management Sy... Component

Support Requirements Requirement

Specific Requirements Requirement

refined by

refined by

refined by

refined by

refined by

R.1.1

R.2.1 Accept Requests Requirement

R.2.2 Retain Inventory Requirement

R.2.3 ControlMultiple Collectors Requirement

causes R.2.4 Maximum Staff Requirement R.1 Staffing Per Shift Risk

Continuous Support Requirement

generates

generates

System  Design Repository

I.1

I.2

Media of Requests Issue

Criteria for Determining Cert... Issue

Physical Views

1.2

Center Support Personnel

Functional Timelines

Human

2

3

Sensors

Comm

External System

External System

CSP toADP

ADP to Support Personnel 1.1

Status

ADP

Subsystem

ResourceMIPS

0 5

FunctionAssessKill FunctionPerform Intercept FunctionRequest Intercept Function (WithExits)Discrimina FunctionThreatTrack FunctionDetect& InitiateTrack

EnR cont

1.3

TermR cont

ADP to SCF

Comm-Local

Sector Command Facility

Local-Comm

SCF to ADP

Facility

1.4

LocalData

0

10

20

30

40

50

57.0

Local Comm

LocalData 2

Subsystem

65

Setting Up Your Project

Getting Started with CORE Characterizing Users and Projects

• Creating a new project • Examine Project level properties • Set Project Level preferences • Set Personal preferences

67

Creating a New Project

1. Select New Project

2. Name the Project:  “Geospatial Library”

3. Review the default settings: ‐ Permission Level ‐ Select Schema

‐ Enable Versioning ‐ Enable Audit Logs

4. Click OK to Create and Open

68

Project Explorer: Properties

1. Select Properties (this opens the project  Properties Page)

2. Set Base Path and  External Graphics Path (this sets the path for  saving external files  supporting the project)

* NOTE:         Icon opens a  new dialog box (next page).

69

Setting Base or Graphics Path 1. “Browse for Folder” Dialog Box Opens

2. Navigate through Drive and Select desired folder

3. Click “OK” Button 

70

Setting Project Attributes on Secondary Tab

Staying on the Properties… 1. Select the Secondary Tab 2. Fill in information on  Organization 3. Fill in information on  Customer  NOTE : These Attributes are  used to complete information  found on a Cover Page for  Formal Documentation. 

2.

3.

1.

71

Project Preferences

Allows the project team to set a common graphical style. You must have Administrator permissions for the project to edit project preferences. Project preferences are exported as part of the project backup. 

1.

1. Open Project Preferences: Click “Project” in Menu Bar 2. Select Project Preferences ‐ Opens a new window (next  slide)

2.

72

Project Preferences (CORESim)

Default Values for CORE  Simulator feature (these are covered in  detail in a later section  of the class)

73

Project Preferences (General)

Diagram ‐> General: Sets preferences for all  diagrams. Each Diagram Type has  unique preferences for  the diagram.

74

User Preferences

Allows Individual Users to  customize their settings

1.

Note:

1. Open user Preferences dialog: Tools > User Preferences 2. Click OK to close

2.

Project Explorer Diagram Tab Section can be used to select the types of  diagrams that will be accessible for the project

75

Setting Report File Locations

User Preferences ‐> File Location: shows where CORE script files are located. (**Do not change this unless you are creating or running customized scripts**)

76

Diagram Preferences

Each user may change diagrams default settings based on individual preferences.

77

Simplified MBSE Process

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

79

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

The project plan and responsibility for individuals should be taken into consideration when you set up the CORE project.

80

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

81

REQ

CAPTURE ORIGINATING REQUIREMENTS

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

83

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.

84

GL Source Document

See H‐1

C:Program  Files(x86)/Vitech/CORE9/Data/Samples/GeospatialLibrarySourceDocument

85

Analysis of GL Source Document • What did we learn from reading the source document? A.) Geospatial Library – System of Interest  B.) Two External Systems – Customer and Image Collectors

Collectors

Customers

Geospatial Library

86

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, 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

87

Multiple Ways to Capture Requirements

• Copy & Paste/Paste Unformatted commands • Document Parser • Element Extractor • Import of requirements in comma-separated value (CSV) format

88

Elements Used for Requirements Capture

built from / (built in)

refined by / (refines)

documents /  (documented by)

Component (System)

Document

documents / (documented by)

refined by / (refines)

augmented by / (augments)

Requirement

ExternalFile

NOTE: ExternalFile CLASS is used to  capture pictures, graphs, tables,  etc. that are part of a requirement  statement.

89

The Requirements Capture Approach • Get the leaf nodes – the requirements in single, verifiable statements.

documented by

Source  Document

System

• Record source requirement statement in the Description attribute of a Requirement . • Obtain traceability between source and first level Requirements with documents/documented by relationship pair. • Obtain traceability between parent/child Requirements with the refines/refined by relationship pair.

documents

Originating  Requirements

X

Parent  Requirements

refined by

refined by

Child  Requirements

refined by

Leaf node Requirements traceable to Originating  Requirements using “ refined by ” relation

90

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

91

Open the Document Parser

1.

1.) Select Parser Button (this opens Document Parser) 2.) Change Class to Requirements 3.) NOTE Keywords for parsing

2.

3.

92

Create a Source Document Element

1.) Click “Select” Button 2.) Select New and Enter name for Source Document 3.) Select “OK” to make the element

2.

1.

3.

93

Parsing the Document

1.) Open the Document  to be parsed (this pulls  document into left hand  pane) 2.) Parse the document  using the Parse Button  (this will break up the  document into  individual statements  and populate the right  hand pane)

C:Program  Files(x86)/Vitech/CORE9/Data/Samples/GeospatialLibrarySourceDocument

94

Create All Elements

Parser ‐> Create All Elements

95

View the Parsed Requirements

Open the Element  Browser and select  the Requirement  Class

96

Edit the Parsed Requirements

Delete Elements 1.0, 2.0 and  Debris 0001 Why?  No requirement content.

Delete Command: a.) Delete Key b.) Menu Button c.) Select Element, Right  Click, Delete Element

CAUTION!  DELETE – Removes the element from the project and removes  all of the element’s relations.  A DELETED element cannot be recovered.

97

Transforming Debris 0010

Debris 0010 – EIA 632.  This is discussed in the GL Source Document as a  reference by which to design the system.  We want to capture this in our  design model…

Select Debris 0010 Right click  Select “Transform Element Class…” Select “Document” from drop‐down menu Select OK

Provide new name: “EIA 632” Select OK

98

Edit EIA 632 (1 of 2) 1. Select Document Class 2. Select EIA 632 3. In the Property Sheet –

2.

Fill in the Attributes … Document Number:  ANSI/EIA‐632‐1998

1.

3.

Document Date: 07 January 1999 Type: Standard

Title: Processes for  Engineering a System Non‐Gov’t Category:  STANDARDS 4. In Relationships: Select “referenced by”,  Double Click to get dialog  box (next slide…)

4.

99

Edit EIA 632 (2 of 2)

EIA 632 is a reference document for the GL Source document, therefore EIA  632 is “referenced by” the GL Source document.

Double Click “referenced by”  gets the top dialog box. 1. Select GL Source Document 2. Click Add 3. Click OK (this step creates  the relation in the model)

2.

3.

1.

The Relation – completed on  the EIA 632 Property Page

100

Edit Debris 0002

Copy the description from Debris 0002 and paste it in the  DOCUMENT > GL Source Document’s description Once copied, then go back to REQUIREMENTS and DELETE  Debris 0002 CAUTION: Get in the habit of using Paste Unformatted.  Using this  command, you can control font type and size globally in a document  ensuring consistency in the text.

101

Edit Document: Geospatial Library Source Document

In the DOCUMENT Class, Select  the GL Source Document element. Open a separate Property Sheet  window by double‐clicking on the  element.

Paste in the Description Edit Attributes as shown

Specify the External File Path to  hyper‐link to the actual document.

Building an element’s attributes and relations can be done in either the Project Browser – Property view or in an individual Property Sheet.

102

Create Component: Geospatial Library

Select the COMPONENT class and  create “Geospatial Library” by  double‐clicking on the class  name. Double‐click on the element  “Geospatial Library” to open a  Property sheet. Set Type Attribute From REQUIREMENT Class: Place Debris 003 – in Description Place Debris 0007 ‐ in Mission (then DELETE Debris 0003 and  0007) Double‐click on the  relationship documented by and add “target” GL Source  Document.

Debris 0003’s description

Debris 0007’s description

CORE will automatically create exhibits State and performs Function.

103

Clean up remaining Requirement Elements…

Select  Specific Requirements Add to Description all the  requirement descriptions for  Specific Requirements 1‐7 (Principal: No Requirement’s  description attribute shall be  empty.) Delete remaining “Debris”  elements Delete 3.0 General Requirements

Double‐click on documented by Select Geospatial Library  Source Document

104

Edit GENERAL REQUIREMENTS 1

PRINCIPLE: Because we removed the  element “3.0 Specific  Requirements”, we need  to re‐establish traceability  to the source document  with the remaining root  Requirements.

Double‐click on documented by

Select Geospatial Library Source Document

105

Renumber GENERAL REQUIREMENT 1 PRINCIPLE: Assign Number and Name to REQUIREMENTS to provide some structure for users  looking at Requirements in the project. We will start by re‐number GENERAL REQUIREMENT 1 and 3.1 Specific Requirements. Then we will give all Requirement Elements Unique Names

Select “GENERAL REQUIREMENTS 1” ; Then Right click and select Renumber  Element

In the Dialog Box: Type “R.1” and Click on “OK”

106

Renumber Specific Requirements Follow the same steps for Specific Requirements  Make the New Number R.2

NOTE: Renumbering an element will  give the element selected the  New Hierarchical Number and  will renumber down thru the  hierarchy using the parent‐child  relation.  Renumber – two ways: (a.) Right Click and select from  drop down menu (b.) Use the Renumber Button 

Resulting List:

107

Rename Requirements

Select each Requirement and Rename the elements has shown below

Renaming can be  accomplished by two  methods:

(a.) selecting the element and  right click to get to the drop  down menu and then  selecting the Rename  Element option or, (b.) selecting the element and  editing the Name attribute

108

Composite Requirements

Requirements that either state or imply multiple requirements within the statement are considered “Composite”. Composite requirements need to be decomposed into single statements. Many times requirements from stakeholders and customers are written as composite requirements. We now need to review the Originating Requirements we have and determine which of these are “Composite” Read through the list of requirements Which of these are “Composite”?

109

Composite Requirements

Requirements R.1 and  R.2, R.2.1, R.2.2, R.2.3, R.2.7 contain multiple  requirement statements. Select the Requirement and then set the Type  attribute to Composite.

Once we know which requirements are “Composite” – we need to  decompose them (in the next slides…)

110

Using the Element Extractor

The Element Extractor is a feature that allows for extracting information from a  document.  We can use this feature to create child requirements for each of the  Composite requirements identified. Select Tools ‐> Element Extractor to Open the Element Extractor

111

Features of the Element Extractor Pull‐down  Menus

Extractor  Toolbar

Source Pane

Text Transfer Buttons

112

Element Extractor: Open Document

Step 1. Select “Load a New  Document” Button

Step 2. Navigate to and  select the document

Step 3. Click “Open”  Button

113

Prepare to Extract Child Requirements OBJECTIVE: Create “refined by” REQUIREMENTs for each Composite REQUIREMENT we have identified.

1.) Set the Class to  Requirement 2.) Scroll in the  document window to  get to the desired  requirement section  We are now set up  to begin extracting  information from  the document and  creating child level  requirements.

114

Select Attribute Values for Child Requirements Objective: Create new REQUIREMENTs to decompose R.2.1 Accept Requests from Certified Customers

1.) Fill in Name Attribute  2.) Highlight text (in the document  frame) to be used in Description  3.) Click on “Description:” button  to fill‐in the description attribute 4.) Set Origin: attribute 5.) Set Paragraph Number: and  Paragraph Title: attributes 6.) Set “refines” Relation (dbl. Click  relation and set using dialog box) Once all attributes and relations are  set, you can make the element by: a.) Extractor ‐> Create Element b.) shortcut – ctrl +E c.) clicking on the button

115

Adjust Attribute and Relationship Values for Remaining Child Requirements

To create another (new)  Requirement: 1.) Change the Name. 2.) Select new text and / or  edit the Description 3.) Check the Origin,  Paragraph Number,  Paragraph Title and change  if needed.  4.) Check the Relation and  the Targets – change if  needed. Finally, once everything is  completed, Create the new  element.

116

Renumber to include the new Requirements

After Renumbering

Before Renumbering

Select R.2.1 and  Renumber

New Requirements are not numbered. Use the Renumber Element command on the parent requirement  to get the new requirements into the numerical hierarchy.

117

Composite Requirement Decomposition To Review: What we did was to break up the Composite requirement, without  changing the intent of the Original requirement, in to two new singular  requirements. The  “refined by”  relation shows decomposition in the REQUIREMENT Class. Diagrammatically, we now have the following requirement relation…

We need to repeat this process for the remaining Composite requirements …

118