On Using UML in the Systems Engineering Process for System
Requirements Development
Pete Ross, Shawn Simmons, Michael Crow
The Boeing Company
Integrated Defense Systems
1.0 Introduction
1.1 Need for Improved Methods of Implementing SE Process1.2 Where OOA, UML, and Related Tools Help
2.0 Comprehensive Requirements Analysis and Management Through Models & Databases
2.1 UML Use for Enhanced Definition & Communication of Requirements
2.2 Executable Modeling for Requirements & Design Analyses
3.0 Summary
1.1 Need for Improved Methods of Implementing SE Process
Large Scale Platforms ContainingHighly Integrated Systems
Many Platforms, Highly Integrated
Common Operating Picture And Information Available At All Echelons
Integrated Air Platforms
Integrated Ground Platforms
Highly Integrated Systems Engineering Processes are Needed to MeetThe Challenges Of Large Scale Integration Of System of Systems
Integrated Air And Ground Systems
Integrated Air And Ground Systems
Past• Performance Driven• Military Specs• Federated Systems• Focus on Delivered Quality
Present• Integrated Systems• Rapid Prototyping• COTS• Affordability Focus
Future• System-of-Systems Solutions For Network Centric Operations• Flexibility/Agility• “Time to Market” Focus• Commercial Practices and Products• MDA/ Effects Based Development• Quality at Each Step of Process
FA-18 C/D
The System Engineering Environment Has Changed
Future Concepts
DeltaLaunchVehicle
Systems Engineering Processes Must
Support FlexibilityThroughout
Development Process
Systems Engineering Processes Must
Support FlexibilityThroughout
Development Process
Operational Needs Are Continuously Changing
Systems Technologies are Constantly Evolving
Therefore RequirementsEvolve Continuously during A
Development Program
Operational Needs Are Continuously Changing
Systems Technologies are Constantly Evolving
Therefore RequirementsEvolve Continuously during A
Development Program
F-22
The Communication Challenge
• Capture and Integrate Analyses of Many Domain Experts to Properly Turn User Needs into System Requirements
۰ Increased emphasis on well organized and maintainable capture and analysis of user and inter-/ intra- system processes in a variety of situations
۰ For efficiency and clarity, need integrated processes, modeling languages, and tools
• Address Legacy Structured Analysis and Design Technique Shortfalls
۰ Tends to drive federated solutions۰ Low support for showing linkage of functional decomposition back to intended use
• Capture and Integrate Operator Intended Usage to Properly Turn User Needs into
System Requirements
۰ Need to keep customer in the loop well into the development process
۰ For efficiency and clarity, need to be able to effectively communicate with the intended users in a language that both they and the contractor team understand
Customer
Engineer
?Communicate
s in the language of a use domain
Communicates in the language
of a technology
domain
Command & Control Segment
The Systems Integration Challenge For SoS Architectures
Subsystem Level 4 Allocates to CSCI/HWCI
HWCI & CSCI Level 5 Allocates to HWC and CSC
Increased Focus of Integration at the Highest Level and ThereforeComplexity From Both the Operators and Developers Point of View
JTF/AOC Air Space
Air Vehicle Segment Radar Segment
eg. Cockpit, airframe, engine eg. Console, Comm gear Integrated Processor
Theater Command & Control Processes/Interactions
ICD
AV ICD:
Internal ICDs Internal ICDs
ICD.
Fu
nctio
nal &
Ph
ysical Arch
itectures
Weapon SystemLevel 2 (Concept)
Allocates to Segment
Land SeaForce StructureLevel 1(Context)
Requirements DetailAllocates to System
Major SubsystemLevel 3 (Logical)
Allocates to SubSys
Users Operational ViewSystem Developers View
DOD AF Intent is to Bridge these
Levels
DOD AF Intent is to Bridge these
Levels
Integration Has Been Focused At This Level Over Last Decade
Traditional SE Processes Have Not Been Proven To Be Efficient
Integration Has Been Focused At This Level Over Last Decade
Traditional SE Processes Have Not Been Proven To Be Efficient
Definition ofSystem Requirements
L1 OperationalFunction &
Performance
L1 OperationalFunction &
Performance
L2 System Function &
Performance
L2 System Function &
Performance
L3 SegmentFunction &
Performance
L3 SegmentFunction &
Performance
L4 Subsystem Function &
Performance
L4 Subsystem Function &
Performance
L5 CSCFunction &
Performance
L5 CSCFunction &
Performance
System
Segment
Subsystem
CSC
SDS9/10/02
BuildBuild
CSCI & HWCI
Allo
cate
req
uire
men
ts t
o:
Linear Time RepresentationOf Requirements Development
Processt
Test
Customer
SystemsEngineering
ProductEngineering
Test and Evaluation
IntegratedProcesses,Common Semantics
Visual Models,and Common
FormatPortable Data
Function & PerformanceAllocations
1.2 Where OOA, UML, and Related Tools Help
OOA/ UML Benefits
UML is a standardized language Which has Continued software and systems
engineering support
Captures Life Cycle Uses of System ByFormal Analysis of Multiple Use Cases
Commercial and defense industry
software development standard modeling
language
Activity
ClassAttributesOperations
State
represents operations in use
represents changes in attributes or operation activations
Elements used to model a real world object and its behavior
Integrates Abstract Physical & Behavioral ViewsUsing Object Oriented Analysis
What Are Object Oriented Analysis and Unified Modeling Language?
• OOA: Abstract modeling and analysis of real world objects behavioral interactions and architectural relationships
• Apply Content Decomposition Hierarchically to Aid in System Requirements Analysis
• OO is Used to Bound the Levels and Support Information Technology Based Descriptions of the System
• UML: UML captures the results of OOA• UML is an industry standard for conceptual/ visual modeling• Specified and maintained by non-profit Object Management Group (OMG)• UML is a language not a methodology
• Concepts, Semantics, Notation, Rules
Class Diagrams Use Case Diagrams Activity & State Diagrams Sequence Diagrams
Piloted Strike System & SoS Aggregations with System of System Classes in green
Air Operations Commander Mission Area Commander
Operation Commander
Combat Air Operations Group
11 0..n0..n
Operation Group
11
1..n1..n
Mission Commander
Small Diameter BombPSS Air Vehicle JDAM
Flight Package
1..n1..n
11
PSS Pilot
Piloted Strike System
0..n0..n11 0..n0..n
1..n1..n
11
Perform Final Pre-Flight Tests
Taxi Solo to Point
Enter Solo Flight Holding Pattern
Take Off Solo Air Vehicle
Enter Solo Landing Approach
Taxi Solo to Taxi Hold-Point
Taxi Solo to Take Off Hold-Point
<<extend>>
<<extend>>PSS Pilot
Air Traffic Controller
Land/ Taxi Solo Air Vehicle
<<include>>
<<include>>
Operation CommanderReceive Solo Mission Start
Clearance
Taxi/ Take Off Solo Air Vehicle
<<include>>
<<include>>
<<include>>
<<include>>
<<include>>
Mission plan completed in planning system, encrypted, and ready for transfer
Display menu for selecting method of transfer of mission plan to Air Vehicle
Radio mission plan to Air Vehicle
Transfer mission plan to data transfer cartridge
Choose appropriate mission plan transfer method
Carry data transfer cartridge to Air Vehicle
Put data transfer cartridge in Air Vehicle
Air Vehicle powered up, checked out and ready for mission plan
Radio receive mission plan
Receive data transfer cartridge
Request decryption key
Display confirmation of mission plan & pilot acceptance
Air Vehicle ready for taxi and operational use
See Mission Plan & Pilot Authentication Use Case
: PSS Air Vehicle : PSS Pilot : Planning System
: PSS Pilot : PSS Air Vehicle
: Airborne Tanker
: Refueling Specialist
Initiate Fuel Flow Through Fuel Boom
Display Fuel Level,Report Fuel Level
Visually Monitor Tanking Operation,Monitor Fuel Level
5: Radio Relay Fueling Anomaly Report(Verbal Anomaly Report : Data)
4: Report Fueling Anomaly Status(Anomaly Scene : View, Anomaly Fuel Level
Data : Data)
1: Flow Fuel to Air Vehicle(Initiate Fuel Flow :
Command)
3: Monitor Fueling Situation Display(Fuel Level : Data,
Fueling Operation Scene : View)
6: Audio Message Fueling Anomaly Report(Verbal Anomaly Report : Data) 7: Monitor for Fueling
Anomaly Reports(Verbal Anomaly Report : Data)
Display Fueling Progress,Display Interlock Locked Status
Seq's 3, 7, and 8 are concurrent2: Update Fueling Progress
Display(Fuel Level : Data)
8: Automatically Monitor for Fuel Level and Emergencies( )
Example Diagram Types
8 Diagram/View Types: Activity, Class, Collaboration, Component, Deployment, Sequence, State, Use Case
OOA/ UML Supports Decomposition of Use, Behavior, Objects, Data, and Interface Types
Form-Up for Coordinated Taxi
Taxi Coordinated to Point
Perform Final Pre-Flight Tests
Taxi to Point
Take Off Air Vehicle
Taxi/ Take Off for Specific Scenarios 1 & 2
Receive Coordinated Mission Start
Clearance
<<include>>
<<include>>
<<include>>
<<include>>
<<include>>
<<include>>
Taxi Coordinated to Take Off Hold-Point
<<extend>>
Taxi Coordinated to Taxi Hold-Point
<<extend>>
Mission Commander
Small Diameter BombAir Vehicle JDAM
11
Pilot
Piloted Strike System
0..n1 0..n0..n
1..n1..n
11
Flight PackageUse Decomposition
Content Decomposition
Captures Scenario Dependent Behavior
OOA/ UML Used to Capture Interface Behavior One Level at a Time
Completed Prepare System Pre-Mission Scenario Phase
Request Mission Start Clearance
Ready to Request Taxi Clearance
Receive Clearance
Completed Prepare System Pre-Mission Scenario Phase
Communicate Clearance
Communicate Request
Approve Mission Start Clearance
: Operation Commander : Air Vehicle : Pilot
Stimulus-Response Activity Modeling Between System and Externals,
Repeated at Next Level for Segment-Segment, Segment-Externals, and Similarly Through Remaining
Decomposition Levels
Provides Deterministic Means of How Far to Decompose Functionality at Each Level
Stimulus-Response Activity Modeling Between System and Externals,
Repeated at Next Level for Segment-Segment, Segment-Externals, and Similarly Through Remaining
Decomposition Levels
Provides Deterministic Means of How Far to Decompose Functionality at Each Level
UML Supporting Technologies
Process
ModelingStandard
EmergingTechnologies
OMGVision
ModelingMethodology
Model Driven Development Process
UMLtm (Unified Modeling Language)
MDAtm (Model Driven Architecture)
xUMLAction
SemanticsXMI
Profiles &Patterns
Design Tags
Code Templates
Object Modeling Methodology
OMG is working to provide a vision, framework, and definition at all levels ofsoftware and systems development on a non-proprietary basis
What is needed beyond OOA/ UML?
• Integration With Performance Requirements Analysis Tools & Processes• An adequate means to capture and manage performance requirements• Need visual models to capture timing and motion requirements• Need visual models for performance parameter decomposition/ allocation• Adequate functional architecture views for use as a framework for trade-
offs of physical architectures and performance allocation analyses• Adequate semantics for combined behavioral and performance
simulations• xUML provides some capability in this area
• Integration With Physical Modeling Tools & Processes• Adequate physical views for capturing and managing physical interfaces,
physical allocation analyses, and non-functional requirements
• Integration With Classical System Engineering Processes• Integrated cost, performance, schedule, risk models for use in trade-off
analyses
2.0 Comprehensive Requirements Analysis and Management Through Models & Databases
2.1 UML Use for Enhanced Definition & Communication of Requirements
2.2 Executable Modeling for Requirements and Design Analyses
2.1 UML Used for Enhanced Definition & Communication of Requirements
The Coordination Challenge
SystemsEngineering
ProductEngineering
Test and Evaluation
CustomerStakeholders
0 kft
Down Range
Cross RangeAirborne TankerPSS Air Vehicle
0 km
+/- 30 deg Max Angle to Start Approach
Use Case Connect for In-Flight Refueling, Thread CFIFR-1
Notes and Justifications: +/- 30 deg approach angle driven by viewing angle available to Fueling Specialist through cameras, and he needs to visually confirm approach and approach rate
These graphics are for illustration purposes only and do not represent any real vehicle requirements.
< Max Start Distance
0 kft
Down Range
Cross RangeAirborne TankerAirborne TankerPSS Air VehiclePSS Air Vehicle
0 km
+/- 30 deg Max Angle to Start Approach
Use Case Connect for In-Flight Refueling, Thread CFIFR-1
Notes and Justifications: +/- 30 deg approach angle driven by viewing angle available to Fueling Specialist through cameras, and he needs to visually confirm approach and approach rate
These graphics are for illustration purposes only and do not represent any real vehicle requirements.
< Max Start Distance
Use C
ase
Threa
d Num
ber in
Us
e Cas
e
Threa
d Typ
e
Threa
d Crite
ria
Type
Threa
d Crite
ria
Desc
riptio
n
Threa
d Pe
rform
ance
Type
s
Refer
ence
Grap
h, Ta
ble, o
r Doc
umen
t
Perfo
rman
ce V
alue
Type
Perfo
rman
ce V
alue
1 Perfo
rman
ce V
alue
2 Perfo
rman
ce V
alue
Units
Perfo
rman
ce
Reqm
t Typ
e
Justi
ficati
on
Posit
ion of
Acti
vity
in Th
read
Activ
ity N
ame
Clas
s Nam
e
Connect for In-Flight Refueling 1 C2 Start
PSS Pilot has visually acquired Airborne Tanker and received radio clearance from Refueling Specialist to come in for tanking.
Time to Complete Maximum 5 min Goal
Human concentration fatigue start threshold
Beginning
Control PSS Air Vehicle to Connect to Fuel Boom PSS Pilot
End
Fueling boom is interlocked to PSS Air Vehicle. Confirmation from PSS Air Vehicle that interlock is complete. Fuel levels in PSS Air Vehicle are displayed to both PSS Pilot and Refueling Specialist.
Intermediate Time
Constraints
Connect for In-Flight Refueling -1
Concurrent Timing Diagram See diagram notes
Beginning
Control Fuel Boom to Support Connection to Air Vehicle
Refueling Specialist
Air Vehicle - Tanker Start Separation Maximum 10 km Notional
Existing standard stand-off distance
prior to start of tanking operations End
Display Interlock & Fuel Status
PSS Air Vehicle
Tanker SpeedMin and
Max 250 350 nmph Firm
Existing tanker dispensing safety
limits EndDisplay Interlock Locked Status
Airborne Tanker
Tanker Altitude
Min and Max 2 20 kft Firm
Existing tanker dispensing safety
limits EndDisplay Fueling Progress
Airborne Tanker
Intermediate Movement Constraints
Connect for In-Flight Refueling -1 Movement
Constraint Diagram See diagram notes
Start In-Flight Refueling 1 C2 Start
Fueling boom is interlocked to PSS Air Vehicle. Confirmation from PSS Air Vehicle that interlock is complete. Fuel levels in PSS Air Vehicle are displayed to Refueling Specialist.
Beginning
Initiate Fuel Flow Through Fuel Boom
Refueling Specialist
EndFuel is flowing to PSS Air Vehicle. Updated fuel level dispalyed to Refueling Specialist. End Update Fueling Progress
Airborne Tanker
Develop System
Manufacture System
Test System
Distribute System
Operationally Use System
Support System
Train with System
Dispose of System
Program Start or Modification Start
Ready for Operational
Test
Storage Assigned
Disposal Assigned
Modification Assigned
Manufacturing Acceptance Tests Passed
Significant Redesign Required
Operational Tests Passed
Support Required
Operational Mission or New Base Assigned
Training Mission Assigned
New Base, Modification, or Disposal
Assigned
Disposal Assigned
Support Required
Disposal Assigned
Function X
Time
Map Best Models & Data Constructs to an Integrated SE ProcessUse UML Model as Focal Point to Tie Together Engineering ProductsMap Best Models & Data Constructs to an Integrated SE Process
Use UML Model as Focal Point to Tie Together Engineering Products
Integrated Processes, Common Semantics Visual Models, and Common Format Portable Data
Matrices/Databases Graphs DrawingsSimulations Block
Diagrams
UML ModelContext Diagrams, Process Flows, Use Descriptions, Item
Exchanges, Candidate Technology &Solution Objects Classes
Multi-Discipline Participation in Use Case DrivenArchitecture Development & Design
System Con Ops,Safety, Security
Measures ofEffectivenessMeasures ofEffectiveness
System Effectiveness,Reliability
ArchitecturallySignificant
MissionScenarios
Interoperability
Architecturally SignificantMission Scenarios
Identify Functional Interaction of System with
External Participants And Use of IERs
Architecturally SignificantMission Scenarios
Identify Functional Interaction of System with
External Participants And Use of IERs
AbstractUse Case
“Operate System”
PerformanceRequirements
Database
Nominal Use ThreadsContingency Threads
Views Need to Convey All Aspects of Each LevelOf The Architecture To All Stakeholders
User/Customer
ProductTeam
Cubes Represent Engineering Data & Architecture Products
The Products Developed are Organized Based on the Zachman FrameworkThe goal of Using a Framework is to Ensure an Architecturally Complete Description
L3 L4 L5
L2
L1
L1 L2
PeopleTime
FunctionData
Network
Functional Analysis
Synthesis
Requirements Analysis
Motivation
Integration & Test TeamSpecializedViews Like
SecurityAre Created
For Each Level From Data
Across the Rows
Engineering Products Provide Forum and Canvas for Product Definition and Refinement
ArchitecturallySignificant
MissionScenarios
Functional Architecture
Modes
Activities
Use Cases(for all life cycle phases)
Capabilities
States
Performance
Threads
External Systems
Physical Architecture
Measures of Effectiveness
Database
Views
Product RelationshipsProvide LinkageTo Intended UseScenarios
Construction of The Functional ArchitectureAnd Allocated To The Physical Architecture
Class 4Attributes
Operations
Operation p ()Operation q ()Operation r ()
Attribute xAttribute y
State Diagram
Class Association (roles) Relationships
Object BObject A Object C
Activity 1
Activity 2
Activity 3
Activity 4
Activity 5
State I State II
State III
State IV
Superstate A
StateDiagram
Component 1
Component 2
Node A
Component 3
Component 4
Node B
Deployment Diagram
ClassDiagram
Class 1Attribute xAttribute yProcess I ( )Process j ( )
Class 2Attribute xAttribute zProcess k ( )Process n ( )
* 1
Class 4Attribute wAttribute z
Class 5* 0..3
Class 3Attribute qAttribute rProcess o ( )Process p ( )
Class Diagram
Integrated Process & Environment for Deriving Behavioral Requirements
Use Driven and Methodical Requirements Derivation
Functional Architecture
Life Cycle Phases
Modes
Activities
Use Cases
Capabilities
States
Performance
Threads
ExternalSystems
Safety, Health, Quality,
Security, Survivability,
Concepts
Use Scenario Script Driven Verification Using Logic and Timing Simulations
StateModel
PerformanceModel
Interactive Simulation
UMLUML
MatrixMatrixIDEFIDEF
Linking performance with functional architecture to validateArchitecture meets Measures of Effectiveness is key
Performance Analysis
Integrate Commercially Available Tools
TradeStudies
PerformanceAnalysisModeling
RiskToolChange
Management
UML Tool
Requirements Management
Database
Best Of BreedToolsets ShouldBe Combined to
Achieve MaximumIntegration Across
System EngineeringTasks
System EngineeringToolsets
Should Be ChosenTo Be Synergistic
With SoftwareEngineeringEnvironment
2.2 Executable Modeling for Requirements and Design Analyses
Where Executable Modeling Fits In
• To Meet System Analyses Needs:• Capacity (bandwidth)• Security• Fault Tolerance• Interoperability• Interference• Operator Awareness• Control Logic, Timing, Accuracy• Safety (Maintain Physical Separation)• Timelines and accuracies required to
Carry out Mission Objectives
• Supports SE Information Needs:– Critical Function Partitioning– Data for Systems Engineering Trade Studies and “what if” analysis.– Data to Verify requirements and architecture completeness.– Data to Verify interface definition.
In the Development Process
Functional Analysis / Allocation
Verification Loop
Design Loop
Requirements Loop
Requirements AnalysisSystem Analysis
Analysis &Control Loop
Iteration Loop Synthesis
Relationship of Executable Modeling toVerification and Validation
L1 Function & Performance L1 Function & Performance
L2 System Function &
Performance
L2 System Function &
Performance
L3 Segment Function &
Performance
L3 Segment Function &
Performance
L4 Subsystem Function &
Performance
L4 Subsystem Function &
Performance
Op Eval System
Exercise
Op Eval System
Exercise
Segment TestSegment Test
Subsystem Test
Subsystem Test
CSCI & HWCI Test
CSCI & HWCI Test
L5 CSCI Function &
Performance
L5 CSCI Function &
Performance CSC TestCSC Test
System
Segment
Subsystem
CSC
SDS9/10/02
BuildBuild
CSCI & HWCI
Allo
cate
req
uire
men
ts t
o:
Executable Modeling
The Role of Executable Modeling is to Verify the Requirements for Consistency And Validate that the requirements meet the requirements from the level aboveThe Role of Executable Modeling is to Verify the Requirements for Consistency And Validate that the requirements meet the requirements from the level above
Function & PerformanceAllocations
Validation
Verification
V&V TestingIs performed
On the As-built,As coded system
With Hardware In the Loop
Executable Modeling is performedUsing the analysis model
of the “To be built” System
AV ClassOperation 1Operation 2Operation 3
Transitioning From FunctionalModeling to Executable Modeling
Operation n……
Object BObject A Object C
Activity 1
Activity 2
Activity 3
Activity 4
Activity 5
Bring together Physical, Functional, Data to EvaluateLogical Consistency & Performance
Bring together Physical, Functional, Data to EvaluateLogical Consistency & Performance
State I State II
State III
State IV
Superstate A
StateDiagram
Object BObject A Object C
Activity 1
Activity 2
Activity 3
Activity 4
Activity 5
Object BObject A Object C
Activity 1
Activity 2
Activity 3
Activity 4
Activity 5
Object BObject A Object C
Activity 1
Activity 2
Activity 3
Activity 4
Activity 5
A State ModelIs Developed for
Each Class
Tools Should Be Chosen to Best Fit The Needs of the Purpose of the Analysis
System Analysis & Tool Suitability
Logical: SegmentLogical: Segment
Context Level Architecture Analysis• Concept Modeled As A “Black Box”• Model of Domain Elements as Sources And Sinks
Concept Level Architecture Analysis• Segment Elements Modeled As “Black Boxes”• Domain Elements Modeled as Sources And Sinks
Logical Level Architecture Analysis• Physical Elements Modeled As “Black Boxes”• Concept Elements Modeled as Sources And Sinks
Concept: Weapon SystemConcept: Weapon System
Context: Force StructureContext: Force Structure
Capacity (bandwidth)Latency (delays)
SecurityFault ToleranceInteroperability
InterferenceOperator Awareness
Communications Analysis
Using UML In TheSystem Engineering Process
• Best Solution for Behavioral Requirements Development• Strongly and clearly driven by concepts of use and documented knowledge of required interfaces with
other systems. • Use case based approach fosters multi-discipline participation
• Provides Appropriate (Use Oriented) Focal Point to Organize and View Other Model Artifacts
• Provides Clear Traceability of Derived Behavioral Requirements• Saves $$$ for changes and supports spiral development
• Provides Strong Foundation for Engineering & Design Processes Automation• Large industry investment and support from Software Engineering
Design Of Highly Integrated Systems Require Integrated SE ProcessesAdoption of a UML based Object Oriented Architecture Centric SE Process
That Uses Modeling and Simulation As Its Core, Meets That Need
A Disciplined Architecture Centric Systems Engineering ApproachWill be Required to Provide Interoperable C4ISR Systems to Meet
The Challenges of Information Dominance
A Disciplined Architecture Centric Systems Engineering ApproachWill be Required to Provide Interoperable C4ISR Systems to Meet
The Challenges of Information Dominance