Operational Concepts and the Case for Use Cases Unifying UML with Systems Engineering Raymond W...
-
Upload
melissa-powell -
Category
Documents
-
view
216 -
download
3
Transcript of 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.
18 April 2002Ver 1.0
©Copyright 2001 Rockwell Collins, Inc
3
Presentation Overview
• Classes or Requirements • Define the Operational Concept• Uses Cases & Scenarios• Diagramming with UML
18 April 2002Ver 1.0
©Copyright 2001 Rockwell Collins, Inc
4
Requirement Overview Classes of Requirements
ProgramRequirements
ProjectRequirements
TechnicalRequirements
OperationalPolicies
OriginatingRequirements
SystemRequirements
StakeholderNeeds
SourceRequirements
FunctionalRequirements
PhysicalRequirements
InterfaceRequirements
ConstrainingRequirements
Ÿ PerformanceRequirements
Ÿ PerformanceRequirements
Ÿ PerformanceRequirements
OperationalConcepts
Class Diagram of
Requirements
18 April 2002Ver 1.0
©Copyright 2001 Rockwell Collins, Inc
5
Requirement Overview Classes of Requirements
– 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
18 April 2002Ver 1.0
©Copyright 2001 Rockwell Collins, Inc
6
Requirement Overview Classes of Requirements
• 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
18 April 2002Ver 1.0
©Copyright 2001 Rockwell Collins, Inc
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
18 April 2002Ver 1.0
©Copyright 2001 Rockwell Collins, Inc
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?”
18 April 2002Ver 1.0
©Copyright 2001 Rockwell Collins, Inc
9
Effective Requirements Capture Define the Operational Concept
• 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
18 April 2002Ver 1.0
©Copyright 2001 Rockwell Collins, Inc
10
Effective Requirements Capture Define the Operational Concept
• Roles
• Skills
• Authority
• Knowledge
• Language
• Culture
• Experience
• Education
• Reading level
• Technical prerequisites
• Occupational specialties
– Identify the actors - know your audience!
18 April 2002Ver 1.0
©Copyright 2001 Rockwell Collins, Inc
11
Effective Requirements Capture Define the Operational Concept
– 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
*
18 April 2002Ver 1.0
©Copyright 2001 Rockwell Collins, Inc
12
Effective Requirements Capture Define the Operational Concept
• 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
18 April 2002Ver 1.0
©Copyright 2001 Rockwell Collins, Inc
13
Define the Operational Concept
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
18 April 2002Ver 1.0
©Copyright 2001 Rockwell Collins, Inc
14
Define the Operational Concept
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
18 April 2002Ver 1.0
©Copyright 2001 Rockwell Collins, Inc
15
Define the Operational Concept
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.
18 April 2002Ver 1.0
©Copyright 2001 Rockwell Collins, Inc
16
Define the Operational Concept
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
18 April 2002Ver 1.0
©Copyright 2001 Rockwell Collins, Inc
17
Define the Operational Concept
Use Cases & Scenarios
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 April 2002Ver 1.0
©Copyright 2001 Rockwell Collins, Inc
18
Define the Operational Concept
Use Cases & Scenarios
• 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
18 April 2002Ver 1.0
©Copyright 2001 Rockwell Collins, Inc
19
Define the Operational Concept
Use Cases & Scenarios
• 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.
18 April 2002Ver 1.0
©Copyright 2001 Rockwell Collins, Inc
20
Define the Operational Concept
Use Cases & Scenarios
• 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.
18 April 2002Ver 1.0
©Copyright 2001 Rockwell Collins, Inc
21
Define the Operational Concept
Use Cases & Scenarios
• 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
18 April 2002Ver 1.0
©Copyright 2001 Rockwell Collins, Inc
22
Define the Operational Concept
Use Cases & Scenarios
Scenarios are used to discover: Functions & Functional Requirements User Interfaces Functional Interfaces.
18 April 2002Ver 1.0
©Copyright 2001 Rockwell Collins, Inc
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
18 April 2002Ver 1.0
©Copyright 2001 Rockwell Collins, Inc
24
Define System Requirements Functional Requirements
Scenarios are used to discover: Functions & Functional Requirements User Interfaces Functional Interfaces.
18 April 2002Ver 1.0
©Copyright 2001 Rockwell Collins, Inc
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
18 April 2002Ver 1.0
©Copyright 2001 Rockwell Collins, Inc
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
18 April 2002Ver 1.0
©Copyright 2001 Rockwell Collins, Inc
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>>
18 April 2002Ver 1.0
©Copyright 2001 Rockwell Collins, Inc
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
18 April 2002Ver 1.0
©Copyright 2001 Rockwell Collins, Inc
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”
18 April 2002Ver 1.0
©Copyright 2001 Rockwell Collins, Inc
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
Primary System<<actor>>
Context System<<actor>>
18 April 2002Ver 1.0
©Copyright 2001 Rockwell Collins, Inc
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
18 April 2002Ver 1.0
©Copyright 2001 Rockwell Collins, Inc
32
Collaboration Diagram
• Notation is same as sequence diagram
• Sequence Diagram– Temporal relationships
• Collaboration Diagram– Spatial relationships
18 April 2002Ver 1.0
©Copyright 2001 Rockwell Collins, Inc
33
Collaboration Diagram
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
Primary System<<actor>>
Context System<<actor>>
18 April 2002Ver 1.0
©Copyright 2001 Rockwell Collins, Inc
34
Collaboration Diagram
<<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
18 April 2002Ver 1.0
©Copyright 2001 Rockwell Collins, Inc
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
18 April 2002Ver 1.0
©Copyright 2001 Rockwell Collins, Inc
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
18 April 2002Ver 1.0
©Copyright 2001 Rockwell Collins, Inc
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)
18 April 2002Ver 1.0
©Copyright 2001 Rockwell Collins, Inc
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
18 April 2002Ver 1.0
©Copyright 2001 Rockwell Collins, Inc
39
Overview of Basic UML
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
18 April 2002Ver 1.0
©Copyright 2001 Rockwell Collins, Inc
40
Overview of Basic UML
Beyond UMLInterface Path
Functional InterfacePhysical Interface
User Interface
Port
Diagram/ Illustration/ Graphic
Verification Description
Verification Summary
Validation Summary
Validation Description
More Document Types