Operational Concepts and the Case for Use Cases Unifying UML with Systems Engineering Raymond W...

Operational Concepts and the Case for Use Cases Unifying UML with Systems Engineering

Raymond W JorgensenRockwell Collins, Inc

18 April 2002Ver 1.0

©Copyright 2001 Rockwell Collins, Inc

2

Legal Notice

• Copyright © 2001 Rockwell Collins, Inc. All Rights Reserved.• Permission is hereby granted to anyone to use this copyrighted material for any lawful purpose, including

commercial applications, and to alter it and redistribute it freely, subject to the following restrictions:– The origin of this copyrighted material must not be misrepresented; you must not claim that you wrote the original text. – If you use this copyrighted material (in whole or in part) in a product, the Rockwell Collins copyright notice must appear in the product

and acknowledgement of Rockwell Collins’ contribution must appear in any accompanying documentation.– Alterations to the Rockwell Collins copyrighted material must be plainly marked as such, and not misrepresented as work attributable

to Rockwell Collins.

• Product support for the copyrighted material is not provided.• NO WARRANTIES. THE COPYRIGHED MATERIAL IS PROVIDED “AS IS” WITHOUT WARRANTY OF

ANY KIND. TO THE MAXIMUM EXTENT PERMITTED BY APPLICABLE LAW, ROCKWELL COLLINS DISCLAIMS ALL WARRANTIES, EITHER EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE, WITH REGARD TO THE COPYRIGHTED MATERIAL.

• NO LIABILITY FOR CONSEQUENTIAL DAMAGES. TO THE MAXIMUM EXTENT PERMITTED BY APPLICABLE LAW, IN NO EVENT SHALL ROCKWELL COLLINS, ITS EMPLOYEES, OFFICERS, DIRECTORS OR SHAREHOLDERS BE LIABLE FOR ANY DAMAGES WHATSOEVER (INCLUDING WITHOUT LIMITATION, DIRECT OR INDIRECT DAMAGES FOR PERSONAL INJURY, LOSS OF BUSINESS PROFITS, BUSINESS INTERRUPTION, LOSS OF BUSINESS INFORMATION, OR ANY OTHER PECUNIARY LOSS) ARISING OUT OF THE USE OF OR INABILITY TO USE THE COPYRIGHTED MATERIAL, EVEN IF ROCKWELL COLLINS HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.

• This license shall be subject to the laws of the State of Iowa. • Exclusive jurisdiction of any and all legal proceedings pertaining to this matter shall be in State or Federal

Court in Linn County, Iowa.



3

Presentation Overview

• Classes or Requirements • Define the Operational Concept• Uses Cases & Scenarios• Diagramming with UML



4

Requirement Overview Classes of Requirements

ProgramRequirements

ProjectRequirements

TechnicalRequirements

OperationalPolicies

OriginatingRequirements

SystemRequirements

StakeholderNeeds

SourceRequirements

FunctionalRequirements

PhysicalRequirements

InterfaceRequirements

ConstrainingRequirements

Ÿ PerformanceRequirements



OperationalConcepts

Class Diagram of

Requirements



5


– Program Requirements: Defines what a contractor must do to fulfill contractual obligations (i.e. SOW)

– Technical Requirements: Defines what a system or component will do to support an unfulfilled need

– Operational Policies: Defines what the operators must do to perform their duties as part of the overall system operation



6


• Classes of Technical Requirements– Originating Requirements

– Operational Concepts

– System Requirements

Establish the boundary conditions• Source Requirements• Stakeholder needs• Constraints

Define interaction between system and actors

• Scenarios• Human vs. Machine Tasks

Describe the problem statement• Function• Physical Characteristics• Interfaces



7

Define the Operational Concept

Use Cases

Capture OriginatingRequirements

Define OperationalConcepts

Audit Project

Validate System

Verify SystemDefine SystemRequirements

Design System Integrate System

Implement System

Design and DevelopSystem



8

Effective Requirements Capture Define the Operational Concept

• Define Operational Concepts– Defines:

• intended purpose of system usage• user interaction with the system

– considers all actors who interact with the system

• user expectations of operability• description of a “day in the life of your product.”

– Find Answer: “What is the user intended to do with the system?”



9


• Define Operational Concepts– Establish the Need

• Statement of Need, Mission Need Statement - why are we here?

– Capture Principle Requirements• Identify constraining requirements that impact the operational concept

– Identify life-cycle phases• Operational concept should address each life-cycle phase

• Set of use cases for each life-cycle phase

– Assess system operation• Discovered through assessment of user community expected usage

– Open dialog, interviews

• Derived from source requirements and stakeholder needs



10


• Roles

• Skills

• Authority

• Knowledge

• Language

• Culture

• Experience

• Education

• Reading level

• Technical prerequisites

• Occupational specialties

– Identify the actors - know your audience!



11


– Define Life-Cycle Contexts

– Define Use Cases & Scenarios• Use Case: A set of scenarios and

conditions that express a complete thread of interaction between actors and systems. A use case may consist of one or more scenarios.

• Scenarios: A sequence of events or transactions between actors and systems.

ScenarioScenario

Use CaseUse Case

contains

contains

Operational ConceptsContent Information Class Diagram

Use Case

Scenario

OperationalConcept

1

*

1

*



12


• Define Operational Concepts– Contains no “shall” statements– Must not refer to specific design components

• Components have NOT been introduced into the problem domain, yet

– Ask questions regarding how the operator/maintainer intends to use capability



13


Use Cases

• Uses Cases Functional Requirements• Use Case captures interaction

– External visible exchange– subject of Validation

• Functional Requirement captures behavior– Internal processing – subject of Verification



14


Use Cases

• Validation– Demonstrate that the ‘right’ system has been

created, i.e. is fit for purpose; is the right thing.

• Verification– Demonstrate that the system, as made, is ‘right’,

i.e. fulfils the specified requirements; the thing is right



15


Use Cases

A Use Case hierarchy is used to capture the relationships (extensions) between different system uses, and the relationship of the different system actors and the use case in which they may play a role.The use case captures the operational interaction of the components/ actors in the use case.

Each use case has a use case description capturing an overview and purpose of the use case.



16


Use Cases & Scenarios

– Capture a list of potential Use Cases

• At least one main Use Case should be developed for each life-cycle phase of the system

– Use Cases are typically separated into individual scenarios that represent a cohesive main flow of events

• Main Scenario

• Alternate Courses - options open to the user

• Exception Cases - when something goes wrong



17



A use case may consist of one or more scenarios to capture the operational interaction. Each scenario has a sequence of steps defining the scenario.Each scenario may have a Sequence Diagram illustrating the interaction.

The Use Cases and Scenarios are published in an operational concept document.



18



• Capture the following information to fully define a use case scenario:

• Use Case Name

• Feature Set: Relationship between this use case and the principle requirements or originating requirements.

• Purpose

• Brief Description

• Actors



19



• Trigger Stimulus: Identify the initiating event that would cause this scenario to occur.

• Preconditions: Scenarios that lead into this use case or assumptions/ conditions that exist prior to this use case

• Use Case Diagram

• Postconditions: Identify the state that exists after completing the scenario.



20



• Main Course Steps

Step Description: Include a step by step sequence of events.

Data: Identify the information and control data transactions that occur in the associated step

Branches: Identify any extension use cases that may branch from the associated scenario step

Requirements: Establish a link relationship between the step and the appropriate system requirement (when available)

User Interface: Identify the user interface definition that is associated with the scenario step.



21



• Alternate Course: Describe alternate scenarios that result from operational decisions.

• Exception: Describe additional scenarios that address exception conditions or failures (abnormal events or off-nominal conditions). Address such issues as:

Safety

Security

Misuse

Abnormal Operation

Weather Conditions

Sequence Diagram: each scenario



22



Scenarios are used to discover: Functions & Functional Requirements User Interfaces Functional Interfaces.



23

System Architecture and Design

Originating Requirements

System Requirements

Logical Representation

Physical Representation

Interface Design

Constraints

Functional Requirements

Physical Requirements

Interface Requirements

Operational Concepts

Use Cases

Requirements

Structural Analysis

Implementation

Requirements

Structural Analysis

Implementation

Requirements

Structural Analysis

Implementation

Requirements

Structural Analysis

Implementation

Structure ChartsClass DiagramsObject Diagrams

• • •

Functional Flow Block DiagramEntity Relationship DiagramState Transition DiagramFunctional Interface DiagramN Squared Diagram

• • •

Use Cases & Scenarios• • •

Interface Descriptions• • •

Operational ConceptUse

System RequirementsFunctionalPhysicalInterface

Architectural Analysis & Modeling

Structural Representation

RequirementsAllocation

Requirements

Structural Analysis

Implementation

Structure ChartsClass DiagramsDeployment DiagramsObject Diagrams

• • •

Requirement Artifact Needs:Originating Requirements

Source RequirementsStakeholder Needs

ConstraintsBoundary ConditionsContext

illustrates allocation



24

Define System Requirements Functional Requirements

Scenarios are used to discover: Functions & Functional Requirements User Interfaces Functional Interfaces.



25

Use Cases & Actors

Diagramming Notation

Use Case #N

Use Case Diagram Notation

PrimarySystem

<<actor>>

Use Case

Actor - human/ biological

Actor - non-human

Association

Extension/ Include



26

Use Cases & Actors

Use Case Diagram

• Relationships– Association (Participatory)

• Actors participate in Use Cases

– Extension• Use Cases extend another Use Case

– Includes• Use Case includes another Use Case

Use Case Diagramis really a Class Diagram

where the Use Case “Class” is main

component



27

Use Cases & Actors

Use Case Diagram

PrimaryActor

OtherActor

Use Case #N

Use Case DiagramRelates Use Case to Interacting Actors Use Case #P

Primary System<<actor>>

Context System<<actor>>



28

Use Cases & Actors

Use Case Diagram

<<Actor>>

Police DogContainment System

<<Actor>>

PoliceCruiser

Police Dog

HandlingOfficer

Suspect

UC1.1: Police DetainsSuspect

UC1.2: Arrest Suspect



29

Sequence Diagram

Diagramming Notation

Sequence Diagram Notation

<<actor>>

Actor - human

Class or Actor - non-human

Message - event, information, or control (data flow)

Lifeline - existence of an object at top of line

X Termination or destruction of object along lifeline

Activity or FunctionFunction

Messages:Several subtypes - not covered in this course

Also shows “activation”, showing when object is “alive”



30

Sequence Diagram

PrimaryActor

SecondaryActor

Use Case NSequence of Events

Event 1

Event 2

Event 3

Event 4

Event 5

Event 6

Event 7

Event 8

Event 9

Event 10





31

Sequence Diagram

<<Actor>>

Police DogContainment System

<<Actor>>

PoliceCruiserPolice Dog

PoliceHandler Suspect

release

apprehend

arrest

pursue

release door

open door

pursue

Use Case: Suspect Flees the Scene



32

Collaboration Diagram

• Notation is same as sequence diagram

• Sequence Diagram– Temporal relationships

• Collaboration Diagram– Spatial relationships



33


PrimaryActor

Event 1Event 3Event 9

Event 2Event 8Event 10

Event 4

Event 7

System Context DiagramCollaboration Diagram with Subject FocusRelates Primary System with External Actors





34


<<Actor>>Police Dog

Containment System

<<Actor>>

PoliceCruiser

environmental control

recall, contain

release door

Police Dog

HandlingOfficer

PublicSuspect

Intruder

forced entryimitated commands

environmental warning

release, recall

resist

approach

apprehendadvise, question, arrest

advise, question

recall

<<Actor>>

Environment

airflow

environment

temperature

open door



35

Summary

• Operational Concepts provide an effective means of understanding the system from the Users perspective– Excellent communication between Users and

Engineers

• Use Cases provide an effective foundation for the Operational Concept– Focus on human interaction– Basis for system Validation activities



36

References/ Acknowledgements

• Customer Centered Products: Creating Successful Products Through Smart Requirements Management, Ivy Hooks, 2001

• The Engineering Design of Systems, Dennis Buede, 2001

• Modern Structured Analysis, Edward Yourdon, 1989• OMG Unified Modeling Language Specification v1.3,

2000• Use Case Based Requirements Development, Thomas

Vayda, 2000



37

Rockwell Collins References

• Engineering Technical Consistent Process (ETCP)• Capture Originating Requirements Guideline, RC-ENG-G-104

• Define Operational Concept Guideline, RC-ENG-G-101

• Define Requirements, RC-ENG-G-601

• Manage Requirements Guideline (in progress)• Define System Architecture Guideline, RC-ENG-G-102

• System Diagramming Guideline, RC-ENG-G-103

• Define System Architecture Checklist, RC-ENG-C-101

• Define Interface Definition Guideline (in progress) RC-ENG-G-105

• Define User Interface Guideline (in progress)• Product Family Engineering Guideline (in progress)



38

Overview of Basic UML

Beyond UML

Stakeholder Need

Constraining Requirement

Requirement Types

Source Requirement

Functional Requirement

Physical Requirement

Interface Requirement

User Interface Requirement

Scenario Steps

Verification Case

Validation Case

Note Types

Comment

Rationale

Trade Study

User Interface Definition

Use Case Description

Ops Concept Definition

Verification Procedure

Validation Procedure

Validation Results

Verification Results

Design Description



39


Beyond UMLAbstraction Block/ Object Types

System

Hardware Component

Software Component

Actor/ Human

Use Case

Function

Scenario

State

Use Case Hierarchy

Functional Hierarchy

Physical Hierarchy

Structural Hierarchy

Document Types

Operational Concept Document

Requirements Document

Project Plan

Statement of Work

Design Document

Interface Definition

Product Specification

User Interface Definition



40


Beyond UMLInterface Path

Functional InterfacePhysical Interface

User Interface

Port

Diagram/ Illustration/ Graphic

Verification Description

Verification Summary

Validation Summary

Validation Description

More Document Types

Date post:	27-Mar-2015
Category:	Documents
Upload:	melissa-powell
View:	216 times
Download:	3 times

Operational Concepts and the Case for Use Cases Unifying UML with Systems Engineering Raymond W...

Documents