architecting the problem space – model-based user needs ......architecting the problem...
TRANSCRIPT
Architecting the Problem Space - Model-Based User Needs Analysis Tuesday, 01 July 2014
David Harvey and Tommie Liddy INCOSE IS 2014
AEROSPACE
CONCEPTS
Architecting the Problem Space –Model-Based User Needs Analysis
David Harvey and Tommie LiddyAerospace Concepts
Tutorial Outline• Format – Lecture and tutorial exercise mix• Classic Model-Based Systems
Engineering introduction– What is a system, which system and what is
Systems Engineering– Systems Engineering and Model-Based
Systems Engineering• Applying MBSE to user needs analysis
and beyond– Capability and capability system requirements
(key to the problem space)– Classic MBSE to support capability focus– Stakeholders, views and architectures– Case study Part 1 – Operational scenario
analysis– Case study Part 2 – High-level solution and
system requirements• Conclusion
Aerospace Concepts Pty Ltd © 2014 2Architecting the Problem Space – INCOSE IS 2014
Architecting the Problem Space - Model-Based User Needs Analysis Tuesday, 01 July 2014
David Harvey and Tommie Liddy INCOSE IS 2014
Administrative Details
• Facilities and safety• Schedule: 10:00 – 17:00
– Lunch: 12:10 – 13:30– Afternoon break: 14:55 – 15:30– Additional breaks if needed
• Questions as they occur– may be deferred (but not forgotten!)
• Introductions
Aerospace Concepts Pty Ltd © 2014 3Architecting the Problem Space – INCOSE IS 2014
Who Are We?Aerospace Concepts Pty Ltd
• Systems engineering in aerospace, defence &related domains, specialising in:– Model Based Systems Engineering (MBSE) and capability
development– Flight Safety Analysis (aerospace modelling and simulation)– Engineering Management System development
• Main team of 20 plus ‘ecosystem’ ofspecialists on contract– Guidance – Space vehicle design– Human factors – Communications eng.– Failure analysis – Military operations
• Aerospace Research– Driving force in the Antarctic Broadband program– Quantum computing
4Architecting the Problem Space – INCOSE IS 2014Aerospace Concepts Pty Ltd © 2014
Architecting the Problem Space - Model-Based User Needs Analysis Tuesday, 01 July 2014
David Harvey and Tommie Liddy INCOSE IS 2014
Now for you!
• Name• Organization / Role• What you hope to get from the tutorial
5Architecting the Problem Space – INCOSE IS 2014Aerospace Concepts Pty Ltd © 2014
AEROSPACE
CONCEPTS
Classic Model-BasedSystems Engineering
Module 1
Architecting the Problem Space – INCOSE IS 2014Aerospace Concepts Pty Ltd © 2014
Architecting the Problem Space - Model-Based User Needs Analysis Tuesday, 01 July 2014
David Harvey and Tommie Liddy INCOSE IS 2014
SYSTEMS ENGINEERINGINTRODUCTION
Aerospace Concepts Pty Ltd © 2014 7Architecting the Problem Space – INCOSE IS 2014
• A System ‘is a thing, which contains smaller interconnected things, andexists in a larger thing, where it interacts with other things, to do something.’– is: a collection of components connected by links to form a
purposeful entity within a larger context (aka system environment)• components and links = structure
– does: performs functions to process items, transforming inputs tooutputs while responding to controls, consuming or producingresources & (usually) creating by-products and/or waste
• time sequence of functions and items = behaviour– behaviour is observed at external interfaces seen in the system
context– interfaces are comprised of links that transfer external items
• driven by external stimulus and response functions• performed by external components joined by the interfaces
• “… a system is, and a system does …
• “and a system evolves” 8
… will be, … will do… was , … did
Current: “as is”Future: “to be”Past: “as was”
form
function
fit
What is a System?
Architecting the Problem Space - Model-Based User Needs Analysis Tuesday, 01 July 2014
David Harvey and Tommie Liddy INCOSE IS 2014
Which System..?
Martin, James N., The Seven Samurai of Systems Engineering: Dealing with the Complexity of 7 Interrelated Systems,Fourteenth Annual International Symposium of the International Council On Systems Engineering (INCOSE), June 2004
Aerospace Concepts Pty Ltd © 2014 9Architecting the Problem Space – INCOSE IS 2014
Context Systemdefines theproblem
Deployed Systemmodifies theContext System
What is Systems Engineering? (1)Systems Engineering is an engineering discipline whose responsibility iscreating and executing an interdisciplinary process to ensure thatcustomer and stakeholder needs are satisfied in a high quality,trustworthy, cost efficient and schedule compliant manner throughout asystem's entire life cycle.
INCOSE
Aerospace Concepts Pty Ltd © 2014 10Architecting the Problem Space – INCOSE IS 2014
INCOSE SE Handbook 2012
Architecting the Problem Space - Model-Based User Needs Analysis Tuesday, 01 July 2014
David Harvey and Tommie Liddy INCOSE IS 2014
What is Systems Engineering? (2)
• Based on systems thinking• Discussing, examining and modelling the real
world
• Cross-discipline• Bridging the gap between fields of knowledge
• Interconnectivity• Knowing how separate systems fit together in a
larger context
Aerospace Concepts Pty Ltd © 2014 11Architecting the Problem Space – INCOSE IS 2014
History of Systems Engineering
• Formal origin in the1930s with Britishmulti-disciplinaryteam to analyse airdefence system
• Developed sincethen initially inaerospace anddefence – now morewidespread
• Driving factors– Complexity– Precision– Rapid development
Aerospace Concepts Pty Ltd © 2014 12Architecting the Problem Space – INCOSE IS 2014
INCOSE SE Handbook 2012
Architecting the Problem Space - Model-Based User Needs Analysis Tuesday, 01 July 2014
David Harvey and Tommie Liddy INCOSE IS 2014
Systems Engineering Activity AreasRequirements Domain
Architecture Domain
Behavior Domain
Test & Evaluation Domain
Aerospace Concepts Pty Ltd © 2014 13Architecting the Problem Space – INCOSE IS 2014
Systems Engineering Process
Requirements Analysis:Defined Problem
Functional Analysis:Logical Solution
Architecture Synthesis:Design Solution
RequirementsLoop
Design Loop
Systems Analysis&Process Control
Stated Need
Solution Specification
‘Logical’ model– what thesystem does
VerificationFeedback
‘Physical’ model- how the systemis structured
Constraint Analysis:Design Limitations
derived from MIL-STD-499B (Draft)
Aerospace Concepts Pty Ltd © 2014 14Architecting the Problem Space – INCOSE IS 2014
Architecting the Problem Space - Model-Based User Needs Analysis Tuesday, 01 July 2014
David Harvey and Tommie Liddy INCOSE IS 2014
Managing Complexity withHierarchies
• Decompositionand Aggregationto managecomplexity
• From universedown toindividualcomponent
Aerospace Concepts Pty Ltd © 2014 15Architecting the Problem Space – INCOSE IS 2014
Decomposition, Iteration& Recursion
SYSTEM
SUBSYSTEM
ELEMENT feedback
derivation and allocation
Iterativerepeat process at a level
Recursivesame process atsuccessive levels
Aerospace Concepts Pty Ltd © 2014 16Architecting the Problem Space – INCOSE IS 2014
Architecting the Problem Space - Model-Based User Needs Analysis Tuesday, 01 July 2014
David Harvey and Tommie Liddy INCOSE IS 2014
MODEL-BASED SYSTEMSENGINEERING
Aerospace Concepts Pty Ltd © 2014 17Architecting the Problem Space – INCOSE IS 2014
Constraints
VerificationStandards
Trade Studies
MOEsCOIs
Interfaces
Risks
TraceabilityValidation
Architecture
DecisionsPerformance
ReviewsChange
Management
Capabilities andRequirements
Documents and Specifications
Product or ProcessArchitecture
Complexity in relationships often hiddenInconsistencies result in problems
Courtesy Vitech Corp.
Aerospace Concepts Pty Ltd © 2014 18Architecting the Problem Space – INCOSE IS 2014
Architecting the Problem Space - Model-Based User Needs Analysis Tuesday, 01 July 2014
David Harvey and Tommie Liddy INCOSE IS 2014
Model-Based Approach
Aerospace Concepts Pty Ltd © 2014 19Architecting the Problem Space – INCOSE IS 2014
Systems Engineering in Transition
Specifications
Interface requirements
System design
Analysis & Trade-off
Test plans
AirplaneATC Pilot
Request to proceed
Authorize
Power-up
Initiate power-up
Direct taxiway
Report Status
Executed cmds
Initiate Taxi
Future
Reprinted from INCOSE Model-Based Systems Engineering Workshop, February 2010
Traditional
Moving from document-centric …… to model-centric
Aerospace Concepts Pty Ltd © 2014 20Architecting the Problem Space – INCOSE IS 2014
Architecting the Problem Space - Model-Based User Needs Analysis Tuesday, 01 July 2014
David Harvey and Tommie Liddy INCOSE IS 2014
Essential Components of MBSE
• A declared metamodel– Structure and semantics– Textual and graphical– Explicit, context-free language for communication– Problem, solution, and management dimensions
• Defined mappings / projections– ‘Fit for purpose’ views– Documentation and design artefacts– Other work products
• A process or methodology
Aerospace Concepts Pty Ltd © 2014 21Architecting the Problem Space – INCOSE IS 2014
What Makes an MBSE Model?
• Metamodel– Language – clear and unambiguous– Structure – behavior expressed in
relationships• Presentation
– Ways to express content, direct from themodel
• Content– Information built within the structure using
the language22Architecting the Problem Space – INCOSE IS 2014Aerospace Concepts Pty Ltd © 2014
Architecting the Problem Space - Model-Based User Needs Analysis Tuesday, 01 July 2014
David Harvey and Tommie Liddy INCOSE IS 2014
MBSE Concepts
• The model is essential, it is:‘the single source of truth’
• The model encompasses the systemdesign and specification
• The model is provided to subsequentteams throughout the product lifecycle
• Required system specifications aregenerated from the model, complete andconsistent
Aerospace Concepts Pty Ltd © 2014 23Architecting the Problem Space – INCOSE IS 2014
Evolution of MBSE
• Good Systems Engineering is inherentlymodel based (holistic approach)
• Two major factors led to need for toolsupport1. Increasing complexity of projects vs
understanding capacity• Metcalfe’s Law (Metcalfe 1973) vs Miller’s
‘Magical Number’ (Miller 1955)• Outsourcing (Sparrow & Wegner 2011)
2. Teams of Systems Engineers
Aerospace Concepts Pty Ltd © 2014 24Architecting the Problem Space – INCOSE IS 2014
Architecting the Problem Space - Model-Based User Needs Analysis Tuesday, 01 July 2014
David Harvey and Tommie Liddy INCOSE IS 2014
Tool Support Evolution
MBSE tools can be used to support SE that is either focusedon the documents required or the system model
Aerospace Concepts Pty Ltd © 2014 25Architecting the Problem Space – INCOSE IS 2014
SE Centricity and Basis
Aerospace Concepts Pty Ltd © 2014 26Architecting the Problem Space – INCOSE IS 2014
Architecting the Problem Space - Model-Based User Needs Analysis Tuesday, 01 July 2014
David Harvey and Tommie Liddy INCOSE IS 2014
Document-Centric SE
• The engineer’s focus is onproduction of documents –not the definition of theproblem and appropriatesystem solution
• No reference to a centralmodel
• Lack of enforcedconsistency and informationreuse
• Documents still useful forcommunication(see Logan & Harvey 2011)
Suggested by Estafan 2008
Aerospace Concepts Pty Ltd © 2014 27Architecting the Problem Space – INCOSE IS 2014
Model-Centric SE
• Model development is thesystems engineer’s majorfocus
• Model ‘of’ and ‘about’ asystem contained within amodel of the context
• Key artefact becomes themodel, but documents canbe used to:– Capture information– As fit-for-purpose outputs
from the model for reviewand approval
Derived from Estafan 2008
Aerospace Concepts Pty Ltd © 2014 28Architecting the Problem Space – INCOSE IS 2014
Architecting the Problem Space - Model-Based User Needs Analysis Tuesday, 01 July 2014
David Harvey and Tommie Liddy INCOSE IS 2014
One Integrated Model
DataDataDataData
verified by
Source Requirements Domain
Architecture Domain
Behavior Domain
V&V Domain
verified by
Originating requirementstrace to behavior
Originating requirements trace to physical components
Behavior is allocated tophysical components
verified by
DataData
Aerospace Concepts Pty Ltd © 2014 29Architecting the Problem Space – INCOSE IS 2014
System Schema Segment
transfers
comprised of
responsible for
SystemArchitecture
Domain
Interface
Link
decomposed by
decomposed by
inputs /outputs /
triggered by
performs
connectedto
built fromComponent
specifiesRequirement
refined by
SelectedClasses
documents
SelectedClasses
refined byDocument(Standard)
joins
basis of
InterfaceElement
RequirementElement
PhysicalElement
FunctionalElement
Color Code
specifies
Exit
Resource
Selected Classes
captures /consumes /produces
exitsby
includesOrganization
• “Top-down” system analysis &design process (example)
– Identify governing Standards, drivingRequirements and responsibleOrganizations if given
– Identify top level Component (theSystem) which performs top levelFunction within the System Context
– Decompose Functions, capturingbehavior through use of Resources,control flows, triggering and Exit logicand identifying input and output Itemsand performance Requirements (MOP)
– Develop system breakdown structure,with Components connected by Linksthat comprise Interfaces and transferItems
– Allocate atomic Functions to atomicComponents
• Produce component Specificationsand other report Documents
Perf Char
exhibitsFunction
Item
Aerospace Concepts Pty Ltd © 2014 30Architecting the Problem Space – INCOSE IS 2014
Architecting the Problem Space - Model-Based User Needs Analysis Tuesday, 01 July 2014
David Harvey and Tommie Liddy INCOSE IS 2014
MBSE Concurrent Activities
Process Inputs
Process Outputs
CORE Repository
SourceRequirements
Analysis• Originating Rqmts.
• Issues and Decisions• Risks
DesignValidation and
Verification• Analysis
• Verification Methods• Test Plans
Architecture/Synthesis
• System Architecture• Components • Interfaces
• Constraints• Allocated Rqmts
Functional/Behavior Analysis
• System Behavior Models• Data Inputs/Outputs• Control/Sequencing• Performance Rqmts.
Topdown
Bottomup
Middle out
Aerospace Concepts Pty Ltd © 2014 31Architecting the Problem Space – INCOSE IS 2014
A Model-Based ApproachSupporting ‘Fit for Purpose’ Views
Aerospace Concepts Pty Ltd © 2014 32Architecting the Problem Space – INCOSE IS 2014
Architecting the Problem Space - Model-Based User Needs Analysis Tuesday, 01 July 2014
David Harvey and Tommie Liddy INCOSE IS 2014
The Automatic Generation ofRepresentations and Work Products
RequestLink
CommandLinkReturn Link
CollectorProduct Link
Customers Collectors
Geospatial Library System
RequestLink
CommandLinkReturn Link
CollectorProduct Link
Customers Collectors
Geospatial Library System
Views are projections of the model. Choose the views that servethe purpose and drive them from a single, integrated model.
Aerospace Concepts Pty Ltd © 2014 33Architecting the Problem Space – INCOSE IS 2014
Model-Based, Model-Centric
• Focus on the information of and about the system– Traceability
• Links established and maintained as part of the approach– Consistency
• ‘Single source of truth’• Internal consistency
– Adaptability• Any number of views or documents can be produced as
snapshots of slices of the model– Robustness & information sharing
• System information made explicitly clear• Domain specialist views are possible – without neglecting the
interconnected nature of domains
Aerospace Concepts Pty Ltd © 2014 34Architecting the Problem Space – INCOSE IS 2014
Architecting the Problem Space - Model-Based User Needs Analysis Tuesday, 01 July 2014
David Harvey and Tommie Liddy INCOSE IS 2014
MBSE is Not a Silver Bullet…• Rubbish in, rubbish out• Complete automation is not possible, nor
desirable, input and review needed• It is not easy
– MBSE doesn’t make your life easier.– MBSE done badly = bad SE = poor outcomes
• However, it makes projects more successful inthe long-run– less chance of schedule and cost overruns– greater chance of delivering the right capability– greater management of interfaces
Aerospace Concepts Pty Ltd © 2014 35Architecting the Problem Space – INCOSE IS 2014
AEROSPACE
CONCEPTS
Applying MBSEto user needs analysis and beyond
Module 2
Architecting the Problem Space – INCOSE IS 2014Aerospace Concepts Pty Ltd © 2014
Architecting the Problem Space - Model-Based User Needs Analysis Tuesday, 01 July 2014
David Harvey and Tommie Liddy INCOSE IS 2014
CAPABILITYDirected Action
Aerospace Concepts Pty Ltd © 2014 37Architecting the Problem Space – INCOSE IS 2014
Stakeholder Needs andOperational Concepts
• Shared vision ofstakeholders
• Mission requirement(s)• Collection of scenarios
involving externalsystems
0. Define Need & System Concept
ISO/IEC 15288* Stakeholder Requirements Definition
*ISO/IEC (2008) 15288:2008, Systems and Software Engineering—System Life Cycle Processes.
Aerospace Concepts Pty Ltd © 2014 38Architecting the Problem Space – INCOSE IS 2014
Architecting the Problem Space - Model-Based User Needs Analysis Tuesday, 01 July 2014
David Harvey and Tommie Liddy INCOSE IS 2014
Capability System
• Capability [Requirement] – the Need– the capacity or ability to achieve a particular effect …– may be described in terms of the nature of the effect and how,
when, where and duration it is produced.• Capability System – the Solution
– a useful combination of elements required to deliver capability,• Doctrine, Organization, Training,• Materiel System,• Leadership, Personnel, Facilities and Policy…
DOTmLPF-P
cf: UK DLOD – ‘TEPID OIL + I’, andAUS Fundamental Inputs to Capability (FICs)
Aerospace Concepts Pty Ltd © 2014 39Architecting the Problem Space – INCOSE IS 2014
DOTmLPF-P• DOTmLPF-P is defined in the Joint
Capabilities Integration DevelopmentSystem (JCIDS) process
• The DOTmLPF-P model representscategories of “solutions” required tocreate an operational capability
• DOTmLPF-P is a key authoritativeintellectual tool in DoD’s efforts toimprove efficiency and effectiveness
Aerospace Concepts Pty Ltd © 2014 40Architecting the Problem Space – INCOSE IS 2014
Architecting the Problem Space - Model-Based User Needs Analysis Tuesday, 01 July 2014
David Harvey and Tommie Liddy INCOSE IS 2014
Capability
The ability to achieve a desired effect underspecified standards and conditions throughcombinations of means and ways to perform aset of tasks. It is defined by an operational user andexpressed in broad operational terms in the formatof a joint or initial capabilities document or a jointdoctrine, organization, training, materiel, leadershipand education, personnel, and facilities (DOTMLPF)change recommendation.
DoDAF v1.5
Aerospace Concepts Pty Ltd © 2014 41Architecting the Problem Space – INCOSE IS 2014
Where Does Capability Fit?
Aerospace Concepts Pty Ltd © 2014 42
DoDAF v2.0
Architecting the Problem Space – INCOSE IS 2014
Architecting the Problem Space - Model-Based User Needs Analysis Tuesday, 01 July 2014
David Harvey and Tommie Liddy INCOSE IS 2014
Capability System Requirements
• Capture end-user and other stakeholders views of thecapability – what they achieve and what they do
• Derive their needs of the enabling capability system –in which some of them are a constituent element!
• Develop a solution-class concept for the CapabilitySystem that addresses those needs
• Derive the capability requirements for the capabilitysystem elements; and for which solutions are todeveloped and tested – for all of the DOTmLPF-Pelements, not just the major (materiel) systems!
Aerospace Concepts Pty Ltd © 2014 43Architecting the Problem Space – INCOSE IS 2014
‘Traditional’ System Acquisitionand Systems Engineering
Stakeholderrequirements
definitionInstallation
& validationOperational
systemProgram
engineering
definition
Systemrequirements
definition
Systemrequirements
definition
Componentdevelopments
Architecturaldesign
Architecturaldesign
Integratedconfiguration
items
Componentrequirements
Componentdesign
Componentbuild & test
Components
Integratedconfiguration
items
Reporting, metrics &management control
Productengineering
Productengineering
Reporting, metrics &management control
Reporting, metrics &management control
Deliveredsub-systems
Deliveredcomponents
Multiple projects
“Local” user &organizationalrequirements
“Local” user &organizationalrequirements
Proposedcharacteristics
Integration&
verification
Integration&
verification
Multiple projectsAllocatedrequirements
Proposedcharacteristics
Allocatedrequirements
ProposedcharacteristicsAllocated
requirements
Deliveredsub-systems
CUSTOMER
SystemRequirementsdefinition
Architecturaldesign
Integratedsystem
Integration&
Single project atthe systems level
Productengineering
Reporting, metrics &management control
Proposedcharacteristics
verificationSUPPLIERS
Aerospace Concepts Pty Ltd © 2014 44Architecting the Problem Space – INCOSE IS 2014
Architecting the Problem Space - Model-Based User Needs Analysis Tuesday, 01 July 2014
David Harvey and Tommie Liddy INCOSE IS 2014
A System
Maritime missile defencecapability enabled by anintegrated detection, controland engagement system
Classical systems engineering focuseson designing a best solution (system)for a bounded, controlled problem:i.e. system-centric analysis, design andintegration
Single Performer (aka Operational Node),many activities;single system, many functions.
Aerospace Concepts Pty Ltd © 2014 45Architecting the Problem Space – INCOSE IS 2014
System of Systems
DETECT
ENGAGECONTROL
Networked detection,control and engagementcapability:collaborating systems
Network Centric Warfare; Network Enabled Capability
The Network
Increasing complexity of the system requires a new approachto capability development and employment.
Aerospace Concepts Pty Ltd © 2014 46Architecting the Problem Space – INCOSE IS 2014
Architecting the Problem Space - Model-Based User Needs Analysis Tuesday, 01 July 2014
David Harvey and Tommie Liddy INCOSE IS 2014
System of Systems Acquisition
Statement ofNeed
Installation &validation
OperationalCapability
ProgramEngineering
CUSTOMER Statement ofNeed
OperationalSystem
Architecturaldesign
IntegratedSoS
Multiple projects atthe SoS level
CapabilityEngineering
Reporting, metrics &management control
Proposedcharacteristics
OperationalConcept
Architecturaldesign
Operationalconcept
Installation &validation
Systemrequirements
definition
Systemrequirements
definition
Componentdevelopments
Architecturaldesign
Architecturaldesign
Integratedsystems
Componentrequirements
Componentdesign
Componentbuild & test
Components
Integratedconfiguration
items
Reporting, metrics &management control
Productengineering
Productengineering
Reporting, metrics &management control
Reporting, metrics &management control
Deliveredsystems
Deliveredcomponents
Multiple projects
“Local” user &organizationalrequirements
“Local” user &organizationalrequirements
Proposedcharacteristics
Integration&
verification
Integration&
verification
Multiple projectsAllocatedrequirements
Proposedcharacteristics
Allocatedrequirements
ProposedcharacteristicsAllocated
requirements
Deliveredsub-systems
OperationalCapability
Aerospace Concepts Pty Ltd © 2014 47Architecting the Problem Space – INCOSE IS 2014
Requirements Analysis:Defined Problem
Functional Analysis:Logical Solution
Solution Synthesis:Physical Solution
RequirementsLoop
Design Loop
Systems Analysis&
Process Control
Stated Needs and Constraints
System Requirements
‘Logical’ model:system behavior
Verification
‘Physical’model: system
structure
Constraint Analysis:Design Limitations
Systems Engineering Process
Aerospace Concepts Pty Ltd © 2014 48Architecting the Problem Space – INCOSE IS 2014
Architecting the Problem Space - Model-Based User Needs Analysis Tuesday, 01 July 2014
David Harvey and Tommie Liddy INCOSE IS 2014
Capability Definition Process
Aerospace Concepts Pty Ltd © 2014 49
‘Physical’model:
operationalstructure
Mission Analysis:Objectives and Tasks
Activity Analysis:Capability Concept
Capability Design:Capability [System] Solution
Needs Loop
Architecture Loop
Operational Analysis&
Process Control
Strategic Goals and Limitations
Capability [System] Requirements
‘Logical’ model:operationalbehavior
Validation
Constraint Analysis:Capability Limitations
Architecting the Problem Space – INCOSE IS 2014
Model-Based System DefinitionConcurrent Activities
Aerospace Concepts Pty Ltd © 2014 50
Process Inputs:• Source Rqmts.• Change Requests
1
s1.Make
Collection
Request
AND
2
s1.Accept &
Format Request
3
s1.Check
Product
Inventory
AND
4
s1.Get Product
From Inventory
5
s1.Provide
Product to User
C.1
Universe
External System
C.2
Customers
External System
C.3
Collectors
External System
SYS.1
Collection
Management ...
System
S.1.1
Analysts
Human
S.1.2
Command
Center
Subsystem
S.1.3
Work Stations
Subsystem
3.1
General
Requirements
3.1.1
Accept
Requests
3.1.2
Retain Inventory
3.1.3
Control Multiple
Sensors
AutomatedDocumentGeneration
Process Outputs:• System RequirementsDocuments
• System Design Model• Exports to Other Tools
CORE System DesignRepository
SourceRequirements
Analysis• Originating Rqmts.
• Issues and Decisions• Risks
DesignValidation and
Verification• Analysis
• Verification Methods• Test Plans
Architecture/Synthesis
• System Architecture• Components • Interfaces
• Constraints• Allocated Requirements
Functional/Behavior Analysis
• System Behavior Models• Data Inputs/Outputs• Control/Sequencing• Performance Rqmts.
Architecting the Problem Space – INCOSE IS 2014
Architecting the Problem Space - Model-Based User Needs Analysis Tuesday, 01 July 2014
David Harvey and Tommie Liddy INCOSE IS 2014
Model-Based Capability DefinitionConcurrent Activities
Aerospace Concepts Pty Ltd © 2014 51
Process Inputs:• Guidance• CONOPS
1
s1.Make
Collection
Request
AND
2
s1.Accept &
Format Request
3
s1.Check
Product
Inventory
AND
4
s1.Get Product
From Inventory
5
s1.Provide
Product to User
C.1
Universe
External System
C.2
Customers
External System
C.3
Collectors
External System
SYS.1
Collection
Management ...
System
S.1.1
Analysts
Human
S.1.2
Command
Center
Subsystem
S.1.3
Work Stations
Subsystem
3.1
General
Requirements
3.1.1
Accept
Requests
3.1.2
Retain Inventory
3.1.3
Control Multiple
Sensors
Process Outputs:• Operational
RequirementsDocuments
• Operational ArchitectureViews
• Exports to Other Tools
CORE CapabilityDesign Repository
Source DataAnalysis• User Needs
• Policies and Regulations• Issues and Decisions
• Risks
OperationalValidation
• Analysis• Validation Methods
• Test Concepts
CapabilityDesign
• Operational Architecture• Orgs, Roles, Nodes•Interaction Needlines
• Allocated Needs
Activity Analysis• Operational Behavior Models• Information Inputs/Outputs
• Control/Sequencing• Effectiveness Measures
AutomatedDocumentGeneration
Architecting the Problem Space – INCOSE IS 2014
Operational & System Definition Recursion
52
Requirements Analysis:Defined Problem
Functional Analysis:Logical Solution
Solution Synthesis:Physical Solution
Systems Analysis&
Process Control
Constraint Analysis:Design Limitations
Mission Analysis:Defined Goals
Activity Analysis:Capability Concept
Operational DesignCapability Solution
Systems Analysis&
Process Control
Constraint Analysis:Capability Limitations
CapabilitySystem
Requirements
SystemRequirements
verification
validation
validation
measures ofperformance
measures ofeffectiveness
operational architecture
system architecture
Mission
SystemSolution
Architecting the Problem Space - Model-Based User Needs Analysis Tuesday, 01 July 2014
David Harvey and Tommie Liddy INCOSE IS 2014
Capability System Engineering
Aerospace Concepts Pty Ltd © 2014 53
Mission Analysis:Defined Goals
Activity Analysis:Capability Concept
Operational DesignCapability Solution
Systems Analysis&
Process Control
Constraint Analysis:Capability Limitations
Doctrine Solution
Requirements Analysis:Defined Problem
Functional Analysis:Logical Solution
Solution Synthesis:Physical Solution
Systems Analysis&
Process Control
Constraint Analysis:Design Limitations
Organization Solution
Requirements Analysis:Defined Problem
Functional Analysis:Logical Solution
Solution Synthesis:Physical Solution
Systems Analysis&
Process Control
Constraint Analysis:Design Limitations
Training Solution
Requirements Analysis:Defined Problem
Functional Analysis:Logical Solution
Solution Synthesis:Physical Solution
Systems Analysis&
Process Control
Constraint Analysis:Design Limitations
Leadership Solution
Requirements Analysis:Defined Problem
Functional Analysis:Logical Solution
Solution Synthesis:Physical Solution
Systems Analysis&
Process Control
Constraint Analysis:Design Limitations
Personnel Solution
Requirements Analysis:Defined Problem
Functional Analysis:Logical Solution
Solution Synthesis:Physical Solution
Systems Analysis&
Process Control
Constraint Analysis:Design Limitations
Facilities Solution
Requirements Analysis:Defined Problem
Functional Analysis:Logical Solution
Solution Synthesis:Physical Solution
Systems Analysis&
Process Control
Constraint Analysis:Design Limitations
Policy Solution
Requirements Analysis:Defined Problem
Functional Analysis:Logical Solution
Solution Synthesis:Physical Solution
Systems Analysis&
Process Control
Constraint Analysis:Design Limitations
Materiel System
Requirements Analysis:Defined Problem
Functional Analysis:Logical Solution
Solution Synthesis:Physical Solution
Systems Analysis&
Process Control
Constraint Analysis:Design Limitations
Capability System: The combination ofthe DOTMLPF elements – Doctrine,Organization, Training, Materielsystem, Leadership and education,Personnel, Facilities and Policy.
Architecting the Problem Space – INCOSE IS 2014
ARCHITECTUREDefinition and Description
Aerospace Concepts Pty Ltd © 2014 54Architecting the Problem Space – INCOSE IS 2014
Architecting the Problem Space - Model-Based User Needs Analysis Tuesday, 01 July 2014
David Harvey and Tommie Liddy INCOSE IS 2014
What is an ‘Architecture’?
• Architecture: the fundamental organizationof a system embodied in its components,their relationships to each other and to theenvironment and the principles guiding itsdesign and evolution, where:– fundamental organization means essential,
unifying concepts and principles– system includes application, system, platform,
system of-systems, enterprise, product line, ...– environment is developmental, operational,
programmatic, … context of the system
Aerospace Concepts Pty Ltd © 2014 55
ISO/IEC/IEEE 42010:2011, Systems and softwareengineering — Architecture description
Architecting the Problem Space – INCOSE IS 2014
conforms to
What is an Architecture Description?
Aerospace Concepts Pty Ltd © 2014
Mission
System
fulfills
Environment Architectureinfluences
inhabits
ArchitecturalDescription RationaleStakeholder
Concern Viewpoint View
LibraryViewpoint
Model
has an
has
hasidentifies
selectsorganizedby aggregates
provides
described by
consists ofmethodsfor
has source
covers
addresses
ISO/IEC/IEEE 42010:2011
Architecting the Problem Space – INCOSE IS 2014 56
Architecting the Problem Space - Model-Based User Needs Analysis Tuesday, 01 July 2014
David Harvey and Tommie Liddy INCOSE IS 2014
Views and Viewpoints
Aerospace Concepts Pty Ltd © 2014
http://en.wikipedia.org/wiki/Multiview_orthographic_projection
Multiple views;How many viewpoints?
Architecting the Problem Space – INCOSE IS 2014 57
What is an Architecture Framework?
• An architecture framework establishes a common practice forcreating, interpreting, analyzing and using architecturedescriptions within a particular domain of application orstakeholder community.
ISO/IEC/IEEE 42010:2011
• Architecture is often equated with structure. This might even betrue, given a sufficiently general notion of structure. This issuegoes to the heart of the Standard, which rests on two principles:– (I) The fundamental concepts of systems are increasingly non-
physical and increasingly removed from what has been traditionallycalled "structure". In this tradition, "structure" usually refers to thecomponents and organization of physically identifiable things, suchas hardware entities or software objects such as modules.
– (II) All architecture views of the system are of equal importance.The Standard does not assume that a physical-structural view isprimary or that it can be used to derive other views or properties ofthe system.
http://www.iso-architecture.org/42010/faq.html#whstruct
Aerospace Concepts Pty Ltd © 2014 58Architecting the Problem Space – INCOSE IS 2014
Architecting the Problem Space - Model-Based User Needs Analysis Tuesday, 01 July 2014
David Harvey and Tommie Liddy INCOSE IS 2014
US DOD Architecture Framework
Aerospace Concepts Pty Ltd © 2014
C4ISR1996-97
28 May 2009
Architecting the Problem Space – INCOSE IS 2014 59
DoDAF 2 Viewpoints
Aerospace Concepts Pty Ltd © 2014 60
From DoDAF 2.0 Volume 1: Introduction, Overview, and Concepts Manager Guide, May 28, 2009
Architecting the Problem Space – INCOSE IS 2014
Architecting the Problem Space - Model-Based User Needs Analysis Tuesday, 01 July 2014
David Harvey and Tommie Liddy INCOSE IS 2014
DoDAF Meta-model
Aerospace Concepts Pty Ltd © 2014 61Architecting the Problem Space – INCOSE IS 2014
DoDAF Viewpoint Definitions (1)• All Viewpoint -overarching aspects of architecture context
• Capability Viewpoint - capability requirements, delivery timing, anddeployed capability
what, when and who has it/will get it• Operational Viewpoint - operational scenarios, activities, and
requirements that support capabilitiesmission, tasks, who, op roles and activities, when, where, how
• Project Viewpoint - relationships between operational and capabilityrequirements and the various projects being implemented
capability development plan• Services Viewpoint - design for solutions articulating the Performers,
Activities, Services, and their Exchanges, providing for or supportingoperational and capability functions
logical support for operationsAerospace Concepts Pty Ltd © 2014 62Architecting the Problem Space – INCOSE IS 2014
Architecting the Problem Space - Model-Based User Needs Analysis Tuesday, 01 July 2014
David Harvey and Tommie Liddy INCOSE IS 2014
DoDAF Viewpoint Definitions (2)• Systems Viewpoint - design for solutions articulating the systems,
their composition, interconnectivity, and context providing for orsupporting operational and capability functions
physical support for operations• Data and Information Viewpoint - data relationships and alignment
structures satisfying capability and operational requirements, systemengineering processes, and systems and services
• Standards Viewpoint - applicable operational, business, technical,and industry policies, standards, guidance, constraints, and forecasts
Aerospace Concepts Pty Ltd © 2014 63Architecting the Problem Space – INCOSE IS 2014
One Model – Many Views
Aerospace Concepts Pty Ltd © 2014 64Architecting the Problem Space – INCOSE IS 2014
Architecting the Problem Space - Model-Based User Needs Analysis Tuesday, 01 July 2014
David Harvey and Tommie Liddy INCOSE IS 2014
CASE STUDY – PART 1Operational scenario analysis
Aerospace Concepts Pty Ltd © 2014 65Architecting the Problem Space – INCOSE IS 2014
Case Study
• Generate a set of views that describe thearchitecture of the Emergency Medical ServicesCoordination Capability
• Use a mix of view ‘models’ i.e. templates– Text, table, and / or graphic– Traditional views and SysML diagrams– Handouts progressively provide an example of
model-based capability analysis and systemdefinition
Aerospace Concepts Pty Ltd © 2014 66Architecting the Problem Space – INCOSE IS 2014
• Document-Based, Model-Centric SystemsEngineering– Could move to Model-Based by using Systems
Engineering tool support
Architecting the Problem Space - Model-Based User Needs Analysis Tuesday, 01 July 2014
David Harvey and Tommie Liddy INCOSE IS 2014
Emergency MedicalServices Coordination
Aerospace Concepts Pty Ltd © 2014 67
EmergencyMedical Services
Coordination??
SystemCenter
Capability
?????
Architecting the Problem Space – INCOSE IS 2014
Capability Definition Questions
• Why does it do it?– goal and objectives => mission
• Who uses it? Who is impacted by it?– organization elements and relationships
• Where is it used?– locations, logical and / or physical
• When is it used?– time, sequence, major events, cycles
• How is it used?– processes and procedures, behavior
• What is in it & what does it do?• How is this achieved?
Aerospace Concepts Pty Ltd © 2014 68
OperationalAnalysis
“Black Box”context analysis
Solution ConceptSolution Design
Architecting the Problem Space – INCOSE IS 2014
Architecting the Problem Space - Model-Based User Needs Analysis Tuesday, 01 July 2014
David Harvey and Tommie Liddy INCOSE IS 2014
Operational Schema Segment
Operational Viewpoint:• model captures
operational elements,the tasks andactivities, and resourceflow exchanges usersneed to achieve theirgoals and tasks - themission
• views visualize thecaptured data
Aerospace Concepts Pty Ltd © 2014 69
achieves
Architecturecomposed of
OperationalArchitecture
Domain
NeedLine(Op I’face)
transfers
decomposed by
OperationalItem
decomposed by
exits by
inputs / outputs /triggered by
captures /consumes/
produces
performsconnected to /thru
guides
SelectedClasses
achieves
built from Performer(Op Node)
Exit
Resource
responsible for
Selected Classes
includesGuidance
achieves
OperationalTask
includes
Missionincludes
refined by
Capability
basis ofOperational
Activity
Organizationassignedto
Architecting the Problem Space – INCOSE IS 2014
Operational AnalysisMethodology and Outputs
Aerospace Concepts Pty Ltd © 2014 70
OV1
High-Level OperationalConcept Graphic
OrganizationRelationshipsChart
Operational ResourceFlow (Needlines)
Needline Information Exchange Information Exchange Performance
OV2 Ref Source Activity Destination Category Content Services SizeSim User
QtyFreq Latency
ExchangeType
Security Criticality InteropNotes
1 needline AAR - GenericADF Aircraft
Air to AirRefueller(V1)
Refuel ADFaircraft inflight
Generic ADFAircraftCommand(V1)
Conduct ofOperations
Coord Info ElectronicData
Very small 1-3 On demand(3-6 per day)
Near RT Duplex - S S Essential Joint,Coalition
1 needline AAR - GenericADF Aircraft
Air to AirRefueller(V1)
Refuel ADFaircraft inflight
Generic ADFAircraftCommand(V1)
Conduct ofOperations
Coord Info Low QualityVoice
30 min radiocircuit
1-3 On demand(3-6 per day)
voice Half duplex S Essential Joint,Coalition
2 needline AEW&C - MROC MobileRemoteOperationsCentre (V1)
Conductmobileregionaloperations
AEW&C (V1) Conduct ofOperations
Fightercontrol rebro
Low QualityVoice
30 min radiocircuit
1-10 On demand voice Half duplex S Essential Joint,Coalition
Key radios (relay function to CAP)
2 needline AEW&C - MROC tbd tbd ROC MROC ISR/BM AEW&CRadar PlotData
ElectronicData
large 1-3 Continuous Near RT Simplex S Essential Joint
2 needline AEW&C - MROC AEW&C (V1) DistributeAEW&Ctrack data
ROC MROC ISR/BM AEW&CTrack Data
Electronicdata
medium 1-3 On demand(3-6 per day)
Near RT Simplex S Essential Joint
3 needline AOC - WOC AirOperationsCommand(V1)
Plan andmanage airoperations
Generic WingOperationsCentre (V1)Generic WingOperationsCentre (V1)
Commandand Control
refer togeneric TG-TU C2
refer togeneric TG-TU C2
refer togeneric TG-TU C2
refer togeneric TG-TU C2
refer togeneric TG-TU C2
refer togeneric TG-TU C2
Duplex - S refer togeneric TG-TU C2
Essential refer togeneric TG-TU C2
It is assumed that CAOC information distribution to a WOCis equivalent in magnitude to the exchange of informationbetween the Genericly described Task Group to Task Unitlink.This IER references the 'Generic C2' analysis at the startof this document.
4 needline Generic MissileController - FOSOW
GenericFOSOWController(V1)
Control andupdateFOSOWflight pathpost launch
FOSOW (V1)FOSOW (V1)
SystemTelemetry
missilecontrol data,targetupdates
ElectronicData
small 1-3 On missiondemand, 1-10 per day
RT Duplex - S S Essential Joint Data transmission requried is 9.2kbits for 30 mins.
An operationalconcept provides amission overviewthat involves theusers of a system ofinterest …
… users who haveformal (command)relationships andoperational roles …
… that constitute theperformers which, toachieve mission-necessaryoperational tasks,exchangeoperationalinformation …
… and the informationexchange has variousattributes and meetscertain performancecriteria.
… which is produced orconsumed by theoperational activities thatachieve the operationaltasks performed byperformers …
OV4 OV2 OV5b OV3
OperationalActivity Model
OperationalResource Flow
Operational activity (hierarchy): OV5aOperational rules, transitions and timelines: OV6
Operational Architecturerepresented byOperational Views
Architecting the Problem Space – INCOSE IS 2014
Architecting the Problem Space - Model-Based User Needs Analysis Tuesday, 01 July 2014
David Harvey and Tommie Liddy INCOSE IS 2014
Operational Scenario Analysis
“Matthew collapses at work. His colleague,John contacts the Emergency MedicalServices (EMS). Alan, an EMS specialistcall-center operator, takes the call …”
Aerospace Concepts Pty Ltd © 2014 71
FormalOrganization Performer
acts as OperationalActivities
performs
Needline OperationalItems
connected by exchange
transferredby
OperationalNeed
results in
Architecting the Problem Space – INCOSE IS 2014
Organizational Relationships
Aerospace Concepts Pty Ltd © 2014 72
OrganizationType: <……>Role: <…….>
Organization Organization
‘controls’ ‘coordinates’
‘Theatre Company’ includes a ‘Person’ with ‘Role:Actor’ who becomes a ‘Character’ in a ‘StagePlay’.
The Person (organization) as Actor (role)“performs” as the Character (performer) in theStage Play (operational scenario).
Architecting the Problem Space – INCOSE IS 2014
Architecting the Problem Space - Model-Based User Needs Analysis Tuesday, 01 July 2014
David Harvey and Tommie Liddy INCOSE IS 2014
Operational Interaction
Aerospace Concepts Pty Ltd © 2014 73
connectedto
Performer
Needline akaOperational Interface
OrganizationType: <……>Role: <…….>
responsible for
Static View“formal” organization
Dynamic View“working” organization,
scenario dependent
Needed Interactions
Operational Item
transfers
‘Resource’ FlowsArchitecting the Problem Space – INCOSE IS 2014
EMSCC Scenario Analysis:Who?
Aerospace Concepts Pty Ltd © 2014 74
Turn over and draw an EMSCC Organization DiagramArchitecting the Problem Space – INCOSE IS 2014
Scenario Major medical emergency – all services requiredOrganization Elements and Performers
Person Organization / Description [has] Role(s)[acts as]
Performers(s)
Alan Emergency medical servicescall-center operator
Emergency medicalservice coordinator
Call Taker /Operator
Architecting the Problem Space - Model-Based User Needs Analysis Tuesday, 01 July 2014
David Harvey and Tommie Liddy INCOSE IS 2014
Organization as Hierarchy
75
includes/included in)
coordinates with/coordinated by)
Aerospace Concepts Pty Ltd © 2014 Architecting the Problem Space – INCOSE IS 2014
Organization as ‘Spider’ Diagram
Aerospace Concepts Pty Ltd © 2014 76Architecting the Problem Space – INCOSE IS 2014
Architecting the Problem Space - Model-Based User Needs Analysis Tuesday, 01 July 2014
David Harvey and Tommie Liddy INCOSE IS 2014
Organization traced to Performer
77Aerospace Concepts Pty Ltd © 2014 Architecting the Problem Space – INCOSE IS 2014
The Organization
is responsible for
The Performer(s)
Operational Connectivity –Resource Flows
Aerospace Concepts Pty Ltd © 2014 78
performs
inputs,outputs
transfers
connected to
Performer Operational Activity
Needline Operational Item
Operational Tasks
achieve
Mission achieve
Architecting the Problem Space – INCOSE IS 2014
Architecting the Problem Space - Model-Based User Needs Analysis Tuesday, 01 July 2014
David Harvey and Tommie Liddy INCOSE IS 2014
Interaction, Activities and Flows:Where, When and How?
Aerospace Concepts Pty Ltd © 2014 79Architecting the Problem Space – INCOSE IS 2014
Scenario Major medical emergency – all services requiredOperational Connectivity
Needline Description PerformersInfo Transferred
between Performers
Caller -Operator
Telephone link between thecaller and the EmergencyMedical Services
Caller /OperatorPatient Symptoms,Request for furtherdetails, etc…
Performer Hierarchy
Aerospace Concepts Pty Ltd © 2014 80Architecting the Problem Space – INCOSE IS 2014
Architecting the Problem Space - Model-Based User Needs Analysis Tuesday, 01 July 2014
David Harvey and Tommie Liddy INCOSE IS 2014
Operational Connectivity
81Aerospace Concepts Pty Ltd © 2014 Architecting the Problem Space – INCOSE IS 2014
Interaction, Activities and Flows:Where, When and How?
Aerospace Concepts Pty Ltd © 2014 82Architecting the Problem Space – INCOSE IS 2014
Scenario Major medical emergency – all services requiredOperational Activities and Information Flow
Activity Description PerformerInput Item(Resource)
Output Item(Resource)
Report medicalemergency
Contact EmergencyMedical Services (EMS) Caller Patient
Symptoms
Receive Call Takes the EMS call Operator PatientSymptoms
Request forfurther details,
Architecting the Problem Space - Model-Based User Needs Analysis Tuesday, 01 July 2014
David Harvey and Tommie Liddy INCOSE IS 2014
Behavior Diagrams – EFFBD*
Aerospace Concepts Pty Ltd © 2014 83
*Enhanced FunctionalFlow Block Diagram
Time-sequencedActivity = Behavior
Architecting the Problem Space – INCOSE IS 2014
SysML Activity Diagram
Aerospace Concepts Pty Ltd © 2014 84Architecting the Problem Space – INCOSE IS 2014
Architecting the Problem Space - Model-Based User Needs Analysis Tuesday, 01 July 2014
David Harvey and Tommie Liddy INCOSE IS 2014
Timeline
Aerospace Concepts Pty Ltd © 2014 85Architecting the Problem Space – INCOSE IS 2014
DoDAF OV-3 – Operational ResourceFlow
Aerospace Concepts Pty Ltd © 2014 86
Blank attributes – missing information?
Data can be readily reviewed in this view and formatArchitecting the Problem Space – INCOSE IS 2014
Architecting the Problem Space - Model-Based User Needs Analysis Tuesday, 01 July 2014
David Harvey and Tommie Liddy INCOSE IS 2014
Operational Data Metamodel
OV-3
OV1 OV6a
OV-5a,bOV-6b,cOV-2
OV4
OperationalInterfaces
performs
connectedto
inputs/outputs
transfers
Mission
achieved byresponsible for
results in
Critical OperationalIssuesgenerates
achieved byassigned to
Guidance(Policy & Doctrine)
guides
Business Limitations& Constraints
External Fileaugmented by
Organizations<role(s)>
OperationalNodes
OperationalActivities
OperationalTasks
OperationalItems
Operational Needs& Constraints
OV-3: Operational Resource Flow MatrixOV-4: Organizational Relationships ChartOV-5a: Operational Activity DecompositionTree
Views generated from data model:OV-1: High-Level Operational ConceptOV-2: Operational Resource FlowDescription
OV-5b: Operational Activity ModelOV-6a: Operational Rules ModelOV-6b: State Transition DescriptionOV-6c: Event-Trace Description87
Operational (User) Needs Derivation
Aerospace Concepts Pty Ltd © 2014 88
Performer[Op Node]
Needline OperationalItem
OperationalActivity
performs
connected to inputs/outputs/triggered by
transfers
Organization<role(s)>
responsiblefor
(User) Requirement<Origin: operational>
<Type: functional/performance/constraint>
results in
”An organization element acting in it’s operational role [i.e. as a performer]performs operational activity(s) and interacts with other performers to achieve amission and / or operational tasks. Effective performance of that activity needs
particular capability characteristics.”
Mission/Op Task
achieves
Capability
refines
assigned to requires
‘Measure ofEffectiveness’
exhibitsIT
Architecting the Problem Space – INCOSE IS 2014
Architecting the Problem Space - Model-Based User Needs Analysis Tuesday, 01 July 2014
David Harvey and Tommie Liddy INCOSE IS 2014
Operational / User Needs Derivation:What?
89
Scenario Major medical emergency – all services required
Operational Needs (User Requirements)
Performer Activity Need(s) EffectivenessOperator Receives Call Operator needs notification of
incoming emergency call.
Operator needs to accept CallWithin time specified.
Percentage of calls answeredwhen an operator is available.
Call wait time less than 30secs for 99% of calls
Aerospace Concepts Pty Ltd © 2014 Architecting the Problem Space – INCOSE IS 2014
User Needs – SysML Reqts Diagram
Aerospace Concepts Pty Ltd © 2014 90Architecting the Problem Space – INCOSE IS 2014
Architecting the Problem Space - Model-Based User Needs Analysis Tuesday, 01 July 2014
David Harvey and Tommie Liddy INCOSE IS 2014
CASE STUDY – PART 2Functions, requirements and system synthesis
Aerospace Concepts Pty Ltd © 2014 91Architecting the Problem Space – INCOSE IS 2014
IEEE1220 Systems EngineeringPlan
Aerospace Concepts Pty Ltd © 2014 92Architecting the Problem Space – INCOSE IS 2014
Architecting the Problem Space - Model-Based User Needs Analysis Tuesday, 01 July 2014
David Harvey and Tommie Liddy INCOSE IS 2014
IEEE1220 Requirements Analysis
93
User needs and other stakeholder requirements analysis
System Requirements AnalysisAerospace Concepts Pty Ltd © 2014
IEEE1220 Functional Context Analysis
Aerospace Concepts Pty Ltd © 2014 94
To:Requirements analysis
Functional Design
Functional Requirements Analysis
Architecting the Problem Space – INCOSE IS 2014
Architecting the Problem Space - Model-Based User Needs Analysis Tuesday, 01 July 2014
David Harvey and Tommie Liddy INCOSE IS 2014
SV-7
SV-6
SV-1/SV-2SV-4/SV-10
System Requirements Model
Aerospace Concepts Pty Ltd © 2014 95
SystemConstraints
SystemRequirements
Functions System
specifies
performedby
Items
refined by
Links
[External]Interfaces
comprise
PerformanceCharacteristic
(MOP)
transferredby
connected to
exhibits
VerificationRequirements
inputs/outputs
OperationalNeeds &
Constraints
BusinessLimitations
& Constraints
basis of
specified by
verified by
joinedto
ExternalSystem(s)connects
joins
Views generated from data model:SV-1 Systems Interface DescriptionSV-2 Systems Resource Flow DescriptionSV-4 Systems Functionality DescriptionSV-6 Systems Resource Flow MatrixSV-7 Systems Measures MatrixSV-10a Systems Rules ModelSV-10b Systems State Transition DescriptionSV-10c Systems Event-Trace Description
Architecting the Problem Space – INCOSE IS 2014
System Schema Segment
MBCD– 8
-96
transfers
comprised of
responsible for
SystemArchitecture
Domain
Interface
Link
decomposed by
decomposed by
inputs /outputs /
triggered by
performs
connected to
built fromComponent
specifiesRequirement
refined by
SelectedClasses
documents
SelectedClasses
refined by
Document(Standard)
joins
basis of
InterfaceElement
RequirementElement
PhysicalElement
FunctionalElement
Color Code
specifies
Exit
Resource
Selected Classes
captures /consumes /produces
exitsby
includesOrganization
• “Top-down” system analysis &design process (example)
– Identify governing Standards, drivingRequirements and responsibleOrganizations if given
– Identify top level Component (theSystem) which performs top levelFunction within the System Context
– Decompose Functions, capturingbehavior through use of Resources,control flows, triggering and Exit logicand identifying input and output Itemsand performance Requirements (MOP)
– Develop system breakdown structure,with Components connected by Linksthat comprise Interfaces and transferItems
– Allocate atomic Functions to atomicComponents
• Produce component Specificationsand other report Documents
Perf Char
exhibitsFunction
Item
96Aerospace Concepts Pty Ltd © 2014 Architecting the Problem Space – INCOSE IS 2014
Architecting the Problem Space - Model-Based User Needs Analysis Tuesday, 01 July 2014
David Harvey and Tommie Liddy INCOSE IS 2014
Functions and Requirements:How this is achieved
Aerospace Concepts Pty Ltd © 2014 97Architecting the Problem Space – INCOSE IS 2014
Scenario: Major medical emergency – all services requiredFunction and Performance Requirements (System Requirements)
User Need Function(s) Performance RequirementOperator needsnotification ofincomingemergencycall.
Provide aural alarm Audio level abovexxdBA
The EMS operator station shallprovide an aural alarm at aninitial level for xx dBAescalating to yy dBa over 10sec period.
From Operational to System Space
Aerospace Concepts Pty Ltd © 2014 98Architecting the Problem Space – INCOSE IS 2014
Architecting the Problem Space - Model-Based User Needs Analysis Tuesday, 01 July 2014
David Harvey and Tommie Liddy INCOSE IS 2014
End-to-end Analysis Thread
Aerospace Concepts Pty Ltd © 2014 99Architecting the Problem Space – INCOSE IS 2014
The OperationalActivities result inUser Needs which formthe basis of systemFunctions specified byRequirements
IEEE1220 System Functional Design
Aerospace Concepts Pty Ltd © 2014 100Architecting the Problem Space – INCOSE IS 2014
Architecting the Problem Space - Model-Based User Needs Analysis Tuesday, 01 July 2014
David Harvey and Tommie Liddy INCOSE IS 2014
IEEE1220 System Synthesis
Aerospace Concepts Pty Ltd © 2014 101
Much ‘analysis’ in ‘design’
Analysis of Alternatives
*Architecting the Problem Space – INCOSE IS 2014
IEEE1220 System Design
Aerospace Concepts Pty Ltd © 2014 102Architecting the Problem Space – INCOSE IS 2014
Much ‘analysis’ before‘Final Design’
Architecting the Problem Space - Model-Based User Needs Analysis Tuesday, 01 July 2014
David Harvey and Tommie Liddy INCOSE IS 2014
Requirements Analysisand System Design
Aerospace Concepts Pty Ltd © 2014 103
Enterprise
User Org
Other S’holders
Op Nodes Op Activities
Op ItemsOp Interfaces
Op Needs
Constraints
*System
External Systems
Interfaces
LinksItems
Mission
*Functions/Perf
Requirements
Document
Op Tasks
Limitations
*System*Functions/Perf
ComponentsSub-functions
User needs and otherstakeholder requirements
System requirementsanalysis
Functional Analysisand System Synthesis
Architecting the Problem Space – INCOSE IS 2014
The Model Framework
104
Exit
Resource
Selected Classes
captures /consumes /produces
exits by
includesOrganization
transfers
comprised of
responsible for
implemented by
implemented by
implemented by
implemented by
Architecture composed of
achievescomposed of
NeedLine
transfers
inputs / outputs/ triggered by
achieves
OperationalArchitecture
Domain
decomposed by
decomposed by
exits bycaptures / consumes
/ produces
performs
connected to
documents
SelectedClasses
achieves
built fromPerformer
refined by
Document(Guidance)
OperationalTask
includes
Mission
includes
Op Activity
Op Item
SystemArchitecture
Domain
Interface
Link
Function
decomposed by
Itemdecomposed by
inputs / outputs/ triggered by
performs
connectedto
built fromComponent
Requirement
refined by
SelectedClasses
documents
SelectedClasses
refined byDocument(Standard)
joins
basis of
InterfaceElement
RequirementElement
PhysicalElement
FunctionalElement
Color Code
specifies
System ofInterest
OperationalCapability
‘enables’
refined byCapability
basis of
implemented by
State
Mode
Event
Transition
OperationalNeeds
Aerospace Concepts Pty Ltd © 2014
Architecting the Problem Space - Model-Based User Needs Analysis Tuesday, 01 July 2014
David Harvey and Tommie Liddy INCOSE IS 2014
AEROSPACE
CONCEPTS
Summary
Conclusions and beyond
Aerospace Concepts Pty Ltd © 2014 105Architecting the Problem Space – INCOSE IS 2014
CONCLUSION
Aerospace Concepts Pty Ltd © 2014 106Architecting the Problem Space – INCOSE IS 2014
Architecting the Problem Space - Model-Based User Needs Analysis Tuesday, 01 July 2014
David Harvey and Tommie Liddy INCOSE IS 2014
Tutorial Summary• Introduced classic systems engineering process and a model-
based systems engineering method• Discussed architecture definition frameworks and their
application to the problem space analysis• Applied MBSE methods to the problem space (exploratory
research and conceptual design)– from goal identification through to needs definition to solution
concept• Gained practical experience in developing an information model
and derivation of user needs and other stakeholderrequirements– Emergency Medical Services Capability
Appreciation of the opportunities and challenges in adopting anMBSE method as a structured and explicitly defined approach for
user and other stakeholder requirements analysis.Aerospace Concepts Pty Ltd © 2014 107Architecting the Problem Space – INCOSE IS 2014
Closing thoughts• All good systems engineering is and always was
model-based– Documents are still an important part of MBSE– With the rise in complexity of projects and teams, MBSE tool
support is required
• Always ask Why, Who, Where, When, How & What• Symmetry between the system and operations
schema segments, the process and techniques are(almost) the same!
• Using the best available tool helps do the bestpossible job
Aerospace Concepts Pty Ltd © 2014 108Architecting the Problem Space – INCOSE IS 2014
Architecting the Problem Space - Model-Based User Needs Analysis Tuesday, 01 July 2014
David Harvey and Tommie Liddy INCOSE IS 2014
Model Based Systems Engineering
If you doubt thepower of modelbased systemdescriptions,without using yourhands, or simileor metaphor,describe a spiralstaircase (tosomeone who hasnever seen one)
Aerospace Concepts Pty Ltd © 2014 109Architecting the Problem Space – INCOSE IS 2014
Upcoming 2-Day MBCD Course
Model-Based Conceptual Design –A Practical Approach
Date: Wednesday 9 to Thursday10 July 2014
Location: Washington DCFees: $995 USD per person
For more details go to:www.eventbrite.com
and search ’conceptual design’
Enter the promotional code‘matesrates’ for 25% off
110
Architecting the Problem Space - Model-Based User Needs Analysis Tuesday, 01 July 2014
David Harvey and Tommie Liddy INCOSE IS 2014
MODEL-BASED MODEL-CENTRICAPPROACH
111Architecting the Problem Space – INCOSE IS 2014Aerospace Concepts Pty Ltd © 2014
Tool Support for Model-BasedApproach
• Today we have focused on document-based model-centric approach– Here is an example of a model-based
model-centric approach to the sameproblem…
Aerospace Concepts Pty Ltd © 2014 112Architecting the Problem Space – INCOSE IS 2014
Architecting the Problem Space - Model-Based User Needs Analysis Tuesday, 01 July 2014
David Harvey and Tommie Liddy INCOSE IS 2014
QUESTIONS?
Aerospace Concepts Pty Ltd © 2014 Architecting the Problem Space – INCOSE IS 2014 113
Thank You!For additional information contact:
David HarveyAerospace Concepts
PO Box 3005Port Adelaide SA 5015AUSTRALIA
+61 403 757 [email protected]
Aerospace Concepts Pty Ltd © 2014 114Architecting the Problem Space – INCOSE IS 2014
Architecting the Problem Space - Model-Based User Needs Analysis Tuesday, 01 July 2014
David Harvey and Tommie Liddy INCOSE IS 2014
References (1)
• DoDAF 1.5,http://dodcio.defense.gov/Portals/0/Documents/DODAF/DoDAF_Volume_II.pdf
• DoDAF 2.0http://dodcio.defense.gov/TodayinCIO/DoDArchitectureFramework.aspx
• Estafan, J., “Survey of Model-Based Systems Engineering MBSE Methodologies”INCOSE MBSE Initiative, 2008,(http://www.omgsysml.org/MBSE_Methodology_Survey_RevB.pdf) Accessed 16Aug 2011.
• Friedenthal, Moore and Steiner 2009, A Practical Guide to SysML: The SystemsModeling Language
• Haskins, C., Systems Engineering Handbook: A Guide for Systems CycleProcesses and Activities, SE Handbook Working Group INCOSE, Version 3.2.2,October 2011.
• IEEE, IEEE Standard for Application and Management of the SystemsEngineering Process, IEEE 1220-2005, Reaffirmed 2011
• ISO, Systems and Software Engineering—System Life Cycle Processes, ISO/IEC(2008) 15288:2008, March 2008.
• ISO, Systems and software engineering — Architecture description,ISO/IEC/IEEE 42010:2011, November 2011.
Aerospace Concepts Pty Ltd © 2014 115Architecting the Problem Space – INCOSE IS 2014
References (2)
• Logan, P. & Harvey, D., “Architecting the Problem Space: an ArchitectureFramework-based Method for Definition of User Requirements”, 4th Asia-PacificConference on Systems Engineering (APCOSE 2010), Keelung, Taiwan, October2010.
• Logan, P. & Harvey, D., “Documents as Information Artefacts in a Model BasedSystems Engineering Methodology”, 5th Asia-Pacific Conference on SystemsEngineering (APCOSE 2011), Seoul, Korea, October 2011.
• Martin, James N., The Seven Samurai of Systems Engineering: Dealing with theComplexity of 7 Interrelated Systems, Fourteenth Annual InternationalSymposium of the International Council On Systems Engineering (INCOSE), June2004
• Metcalfe, R., “Packet Communication”, Massachusetts Institute of Technology(MIT) Project MAC Technical Report MAC TR-114, December 1973.
• Miller, G., “The Magical Number Seven, Plus or Minus Two Some Limits on OurCapacity for Processing Information”, Psychological Review Vol. 101, No. 2,pp.343-352, May 1955.
• Sparrow, B, Liu, J. & Wegner, D., “Google Effects on Memory: CognitiveConsequences of Having Information at Our Fingertips”, Science: 333 (6043),pp.776-778, August 2011.
• SysML specification v1.3, 2012, OMG (www.omgsysml.org)
Aerospace Concepts Pty Ltd © 2014 116Architecting the Problem Space – INCOSE IS 2014
Architecting the Problem Space - Model-Based User Needs Analysis Tuesday, 01 July 2014
David Harvey and Tommie Liddy INCOSE IS 2014
AEROSPACE
CONCEPTS
End
117Aerospace Concepts Pty Ltd © 2014 Architecting the Problem Space – INCOSE IS 2014