Systems Engineering with Use Cases

1
Systems Engineering with Use Cases Threads

• Steve Nelson
• Albin Engineering
• Contact Information
• http//www.sanelson.com/Work/SAN_work.htm
• Steve_at_SANelson.com

2
Course Description

• This course provides an overview of the
  application of OO and UML techniques to the
  Systems Engineering, behavior problem space.
• Topics discussed include
• Use Case identification
• Behavior analysis through Threads
• Applicability across the project lifecycle
• Tools and Techniques as practiced on multiple
  realworld projects

3
Its all About Behavior

• A Use Case is WHAT the system must do,
• behavior is HOW the system will do it.

4
Threads Model Behavior

• Behavior Analysis with Threads
• The systematic application of requirements,
  constraints and system behavior goals (conops) to
  derive a desired behavior, captured in the
  Operations Concept and expressed in system design
  implementation
• Can be applied at every system level from system
  of systems to component
• Applicable across the project timeline from
  inception to post delivery troubleshooting.

5
Required Behavior is Captured in the Operations
Concept

• The CONOPS is an architecture driving document
• CONOPS defines drives SW and HW implementation
• HW design, SW implementation and Operations
  Procedures are equal elements of the system
  architecture

CONOPS Design Implementation
6
When (and why) is Behavior Modeling useful?

• Project Inception
• Understanding customers need
• System Definition (SFR, PDR)
• Deriving system and subsystem requirements
• System Design (CDR)
• Validating system design
• Validating adequacy of the systems operational
  requirements
• Validating critical system timelines
• Validating architectural design

Begin with the end in mind
7
More, when (and why) is Behavior Modeling useful?

• System Development (Integration Test)
• Defining logical integration steps stages
• Defining logical requirements groupings for
  verification
• Developing verification procedures
• Developing operations procedures
• System Delivery
• Developing system documentation
• Troubleshooting and anomaly investigation

Begin with the end in mind
8
Use Cases

• "Use case driven" means writing the user manual
  first, then writing the code. This practice
  reinforces the fundamental notion that a system
  must conform to the needs of the users, instead
  of your users conforming to the system.
• Top Ten Use Case MistakesFebruary 2001
• Doug Rosenberg and Kendall Scott

9
Where are the Use Cases?

• Every system, and every layer of every system,
  must address the Universal Use Cases,
• Install
• Initialize
• Operate
• Fault Detection Response
• Maintenance
• Disposal

The Universal Use Cases
10
Decomposition

• Functional Decomposition
• Derives functional requirements
• Behavior Decomposition
• Derives sub-use cases and operational
  requirements (conops)

Decomposition
11
Derived Use Case
OSR (System) Use Cases
DCC (Sub-System) Use Cases
12
A Behavior Hierarchy
OSR
Big fleas have little fleas upon their backs to
bite them, and little fleas have lesser fleas,
and so ad infinitum. Swift, 1733, On scaling
laws in Biology
13
Threads

• A Thread is the analysis of a
• Use Case

14
Behavior Modeling with Threads

• A thread defines a nominal execution of a Use
  Case
• A thread sequentially connects the sub Use Cases
  within a higher Use Case
• A thread connects the decomposed requirements
  across a system layer
• A successful thread will
• satisfy requirements
• meet conops intentions
• mitigate system design constraints.

Requirements, CONOPS Constraints
15

• A Thread
• Is executed by actors
• Details a path through the requirements, at a
  defined layer of the system, to achieve the
  required behavior.
• Is the conops (the design) for achieving the
  required behavior

Decomposition
Thread
The thread is the CONOPS
16
Requirements, CONOPS Constraints
Use Cases Threads
17
The Goal

• Identify the systems Use Cases
• Analyze the necessary behavior of each Use Case
• Capture the behavior as requirements (Ops Concept)

18
How do we get there?
19
Do we thread every Use Case?

• No, All Use Cases are not equally important
• Prioritize based on risk
• Mission Success Risk
• Essential Mission Functionality
• Effectiveness Measures are a good starting point
• Integration Risk
• Complex Interfaces Interactions
• Development Risk
• New technology or application
• FMEA will indicate potential risk areas

All Systems Engineering is Risk Reduction
20
Drilling Down and Exploring Alternate Paths

• Lower level Use Cases may warrant elaboration
• Analysis of thread path variants may indicate
  additional potential risk areas that should be
  explored
• gtgtWarningltlt
• Potential for infinite path variations is
  possible!
• Resist optimization
• The customer gets what they pay for Kathy
  Morgan

21
So, When are we done?

• Typical approach is to identify all significant
  risks with the major ones understood to the
  extent that contingency strategies are definable.
• Done, done, done when,
• Requirement compliance achieved
• Design constraints mitigated
• System Conops defined behavior achieved

Requirements, CONOPS Constraints
22
Tools and Techniques

• Applying Object Oriented (OO) and Unified
  Modeling Language (UML) Tools in Systems
  Engineering

23
A Process for System Behavior Analysis

• Use Case Analysis
• Compile scenarios of interest (Use Cases)
• Assign to individual engineers for elaboration
• Document in Thread Artifact
• Validate through team scenario reviews
• Validate through executable models
• Capture information from the validation process
• Compiled a Thread Artifact compendium
• Flow knowledge captured during Thread process
  into System Engineering/Project Management
  documents
• Operations concepts, specifications, and design
  documents

Begin with the end in mind
24
The Thread Artifact

• The Thread Artifact Communicates System Design
• The Thread Artifact illustrates
• context within which system requirements are
  applied
• hardware, software, and operational requirements
• system constraints
• system components
• systems interfaces
• system behaviors
• system sequences timelines

Its an Artifact. 90 of Systems Engineering is
throw away
25
Elements of the Behavior Analysis Process and
the Thread Artifact

• Use Case Model
• Use Case Hierarchy
• Context Diagram
• Dependency Diagram
• n X n Chart
• MSC
• Event Flow Table

26
The Use Case Model Diagram

• Illustrating System Behaviors

27
Derived Use Case
OSR (System) Use Cases
The Use Case model diagram may identify lower
level Use cases to be elaborated later
DCC (Sub-System) Use Cases
28
Managing the Behavior Hierarchy Using Spreadsheet

• The system level operate Use Case contains 3
  level 2 Use Cases
• Insert Bread
• Start
• Remove toast
• The Start use case contains 2 level 3 use
  cases
• Enter Kitchen
• Operate start lever

A spreadsheet facilitates organization
29
Starting the Behavior Analysis

• Once the System Use Cases are listed the analysis
  of individual Use Cases can begin
• Prioritize the Use Cases
• Attack the high risk Use Cases first
• Develop the thread artifact

30
Thread Artifact Outline Development

• List of driving (source) requirements
• List of actors involved
• Context diagram for the Use Case
• Use Case dependencies
• The MSC
• Details of the MSC in the Event Flow Table
• Capture of information learned

31
Actors The Context Diagram

• Actors are the elements that execute behavior

32
MSC Structure

• Actors are listed across the top
• lifelines extend down from each actor
• Processes are shown as bubbles on the lifeline
• Messages between actors are shown as arrows
• Time flows down the page
• Many styles and tools exist

33
Sequence Diagram Summary

• The MSC is the single most valuable tool for
  communicating with users, team members and
  sponsors
• Visually represents the sequence of events
• Combines, graphically, elements of
• Use Case model
• Context diagram
• Dependency diagrams

The Message Sequence Chart captures the flow of
activities necessary to accomplish the Use Case
34
The Event Flow Table

• Details the sequential transactions of the MSC,
  allocates the appropriate requirement(s) to each
  transaction and captures relevant information
  uncovered during the analysis

35
Event Flow Table

• Primary analysis activity of the thread process
• Sequential listing of activities
• Triggering Actor (source)
• Message
• Receiving Actor (destination)
• Receivers Use Case (process)
• Transactions requirement

36
How the MSC and the Event Flow Table Work
Together
37
Sequence Diagram Elements
38
Transactions

• For Each Transaction
• Triggering Actor (source)
• Message
• Receiving Actor (destination)
• Receivers Use Case (process)
• Requirement(s)
• Comments

39
Requirements Comments
Begin with the end in mind
40
MSC and Message Details
Details of messages are captured in the system
design documents
41
A Simplistic Application of the Techniques

• The 3-Way Lamp Example

42
Need Statement

• Develop a home lighting device which has three
  user selectable brightness levels, runs on normal
  household AC power, and requires minimal user
  maintenance (bulb replacement is acceptable user
  maintenance).

43
Context Diagram

• Visually illustrates the key elements of the
  system
• Identifies the key interfaces of the system.

44
Expanded Context Diagram

• The lamp is expanded into 3 sub components
• control element
• power cord
• light bulb

45
Use Case Model Diagram

• The operate use case is expanded into 3 sub use
  cases
• Turn on
• Select Brightness
• Turn off

46
Actors and Class Diagram

• User
• Lamp
• Bulb
• Switch
• Plug
• Power Source

47
Select Brightness MSC

48
Sequence Diagram Elements
49
Sequence Diagram Information

A precondition
An unknown process
An operations expectation
50
Select Brightness Event Flow Table
51
Select Brightness Event Flow
52
Summary
53
Behavior Analysis Results

• Customers need understood
• System design derived or validated
• System requirements derived or validated
• Critical timelines derived or validated
• Architectural design derived or validated
• Integration steps stages derived
• requirement verification groups derived
• Development of verification procedures
  facilitated
• Development of operations procedures facilitated
• Development of System Documentation facilitated
• Troubleshooting or anomaly investigation
  facilitated

54
Contribution of Techniques
Who, What, When, Where, Why
55
Thread Artifact Process Review

• Step-by-step
• Compile scenarios of interest (Use Cases)
• Assign to individual engineers for elaboration
  (behavior Analysis)
• Document in Thread Artifact
• Validate through team scenario reviews
• Validate through executable models
• Capture information from the validation process
• Compiled a Thread Artifact compendium
• Flow knowledge captured during Thread process
  into System Engineering/Project Management
  documents
• Operations concepts, specifications, and design
  documents