Presentation is loading. Please wait.

Presentation is loading. Please wait.

Raymond W Jorgensen Rockwell Collins, Inc

Similar presentations


Presentation on theme: "Raymond W Jorgensen Rockwell Collins, Inc"— Presentation transcript:

1 Raymond W Jorgensen Rockwell Collins, Inc
Operational Concepts and the Case for Use Cases Unifying UML with Systems Engineering Raymond W Jorgensen Rockwell Collins, Inc

2 ©Copyright 2001 Rockwell Collins, Inc
Legal Notice Copyright © 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 2002 Ver 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 2002 Ver 1.0 ©Copyright 2001 Rockwell Collins, Inc

4 Requirement Overview Classes of Requirements
Class Diagram of Requirements 18 April 2002 Ver 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 2002 Ver 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 2002 Ver 1.0 ©Copyright 2001 Rockwell Collins, Inc

7 Define the Operational Concept Use Cases
18 April 2002 Ver 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 2002 Ver 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 2002 Ver 1.0 ©Copyright 2001 Rockwell Collins, Inc

10 Effective Requirements Capture Define the Operational Concept
Identify the actors - know your audience! Roles Skills Authority Knowledge Language Culture Experience Education Reading level Technical prerequisites Occupational specialties 18 April 2002 Ver 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. 18 April 2002 Ver 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 2002 Ver 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 2002 Ver 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 2002 Ver 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 2002 Ver 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 2002 Ver 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. Define the Operational Concept Use Cases & Scenarios 18 April 2002 Ver 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 2002 Ver 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 2002 Ver 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 2002 Ver 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 2002 Ver 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 2002 Ver 1.0 ©Copyright 2001 Rockwell Collins, Inc

23 System Architecture and Design
Requirement Artifact Needs: Originating Requirements Source Requirements Stakeholder Needs Constraints Boundary Conditions Context Operational Concept Use System Requirements Functional Physical Interface Architectural Analysis & Modeling Originating Requirements Constraints illustrates allocation System Requirements Operational Concepts Functional Requirements Physical Requirements Requirements Allocation Interface Requirements Use Cases Logical Representation Physical Representation Structural Representation Interface Design Requirements Structural Analysis Implementation Requirements Structural Analysis Implementation Requirements Structural Analysis Implementation Requirements Structural Analysis Implementation Requirements Structural Analysis Implementation Use Cases & Scenarios Functional Flow Block Diagram Entity Relationship Diagram State Transition Diagram Functional Interface Diagram N Squared Diagram Structure Charts Class Diagrams Object Diagrams Structure Charts Class Diagrams Deployment Diagrams Object Diagrams Interface Descriptions 18 April 2002 Ver 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 2002 Ver 1.0 ©Copyright 2001 Rockwell Collins, Inc

25 Use Cases & Actors Diagramming Notation
18 April 2002 Ver 1.0 ©Copyright 2001 Rockwell Collins, Inc

26 Use Cases & Actors Use Case Diagram
is really a Class Diagram where the Use Case “Class” is main component 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 18 April 2002 Ver 1.0 ©Copyright 2001 Rockwell Collins, Inc

27 Use Cases & Actors Use Case Diagram
18 April 2002 Ver 1.0 ©Copyright 2001 Rockwell Collins, Inc

28 Use Cases & Actors Use Case Diagram
18 April 2002 Ver 1.0 ©Copyright 2001 Rockwell Collins, Inc

29 Sequence Diagram Diagramming Notation
Messages: Several subtypes - not covered in this course Also shows “activation”, showing when object is “alive” 18 April 2002 Ver 1.0 ©Copyright 2001 Rockwell Collins, Inc

30 ©Copyright 2001 Rockwell Collins, Inc
Sequence Diagram 18 April 2002 Ver 1.0 ©Copyright 2001 Rockwell Collins, Inc

31 Sequence Diagram Use Case: Suspect Flees the Scene 18 April 2002
Ver 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 2002 Ver 1.0 ©Copyright 2001 Rockwell Collins, Inc

33 Collaboration Diagram
18 April 2002 Ver 1.0 ©Copyright 2001 Rockwell Collins, Inc

34 Collaboration Diagram
18 April 2002 Ver 1.0 ©Copyright 2001 Rockwell Collins, Inc

35 ©Copyright 2001 Rockwell Collins, Inc
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 2002 Ver 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 2002 Ver 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 2002 Ver 1.0 ©Copyright 2001 Rockwell Collins, Inc

38 Overview of Basic UML Beyond UML
Note Types Requirement Types Comment Stakeholder Need Rationale Source Requirement Trade Study Constraining Requirement Design Description User Interface Definition Functional Requirement Use Case Description Physical Requirement Ops Concept Definition Interface Requirement Verification Procedure User Interface Requirement Validation Procedure Scenario Steps Validation Results Verification Case Verification Results Validation Case 18 April 2002 Ver 1.0 ©Copyright 2001 Rockwell Collins, Inc

39 Overview of Basic UML Beyond UML
Abstraction Block/ Object Types System Hardware Component Document Types Software Component Operational Concept Document Actor/ Human Requirements Document Use Case Scenario Project Plan Function Statement of Work State Design Document Use Case Hierarchy Interface Definition Functional Hierarchy User Interface Definition Physical Hierarchy Product Specification Structural Hierarchy 18 April 2002 Ver 1.0 ©Copyright 2001 Rockwell Collins, Inc

40 Overview of Basic UML Beyond UML
Interface Path More Document Types Functional Interface Verification Description Physical Interface Validation Description User Interface Verification Summary Port Validation Summary Diagram/ Illustration/ Graphic 18 April 2002 Ver 1.0 ©Copyright 2001 Rockwell Collins, Inc


Download ppt "Raymond W Jorgensen Rockwell Collins, Inc"

Similar presentations


Ads by Google