Visual Modeling 101 Speakers Background Industrial Engineer from
Visual Modeling 101
Speaker’s Background • Industrial Engineer from Southern Poly-Tech • 30+ years experience in process engineering, operations, and project management • 15+ years on the road as a PM/BA • Worked in many companies, industries and countries – which gives me a unique perspective on best practices in actual use • Belonged to many IIBA chapters over the years, and helped start some
Abstract • This presentation is a high level introduction to the various visual models that Business Analyst typically create in the inception and solution definition phases of a project. • Visual models help to convey “blueprint” style information to project stakeholders to assure everyone sees the same project objectives. • Models discussed here are: – Context Model – Use Case Model – Business Object State Model – Workflows (process flows) – Storyboarding (screen mock-ups) 3
Intent • Teach you the importance of visual modeling • Teach you how to build 6 of the 8 common project front-end models • We will not cover the two that are more design/architectural: – Sequence diagrams – Deployment diagrams
Introduction • Visual modeling has been around a very long time • It is the most effective way to convey information across a wide variety of people • It bridges the gap between the technical minded and the non-technical minded • Models help to form the “blueprints” for a system Note: Examples in this presentation were created using MS Visio & MS Power. Point – A BA needs to be very skilled with using tools of these types 5
What will we learn? • This slide deck discusses six common front end visual models: – Context Model – Use Case Model – Business Object State Model – Workflows (process flows) – Storyboarding (screen mock-ups) 6
Context Models
What is Context Modeling? • The modeling of a system to show its business interfaces and boundaries • A Context Model should have: – – Systems identified Significant interfaces identified Information flow identified Significant actors might be identified Creating a Context Model during elicitation can quickly help with clarification of requirements and project scope boundaries 8
Example of Context Model 9
Benefits of Context Modeling • Puts focus on the business problem being solved • Gets development team on the right page • Supports scope discussions • Supports estimation of work 10
Defining the Context • Best Practice for the Context Model is to depict the system of interest in the center and all of the connected systems around it – Arrows are used to show information flow directions • The easiest way to find the connected systems is by identifying where information comes from and goes to – The process workflows should have this • Best time to create the context model is while eliciting the process workflow in preparation of the business case 11
What is needed? • Choose a modeling tool: – MS Visio – MS Power. Point – Paper, Pencil & Eraser 12
Finding the Templates Find your “Software” Templates
Finding the Templates Select the template you want
Rules of Context Modeling • Single Page • Executive Level • Minimal Labeling • Tell the goal of the Project 15
Basic Modeling Elements <System Name> Enter System Name Choose an Icon to represent your system 16
Developing the Model • Study the information flow on the system boundaries • Identify: – Where information comes from – Where information goes to • Focus on the business problem being solved 17
Example - Film Review System Note that I cheat and use the person icon from the use case model template Start with the big picture 18
Example - Film Review System Choose Icons/Images that tell a story – ex: If data comes from a POS terminal, show a POS Terminal Then fill in deeper details 19
Magic of Power. Point Select all of the Images
Magic of Power. Point 2) Select “Color” 1) Go to Picture Tools: FORMAT 3) Choose a color scheme for your Images
Example - Film Review System The new Film Review System will allow our Film Critics to publish their reviews for our customers to access at any time Adjust aesthetics I like to add an elevator speech about the business problem being solved 22
A more Complex Model OK but too technical
A simple graphical model 24
A simple graphical model 25
A simple deeper level model Know your audience 26
Even more complex model
IIBA BABOK Style Example
What Next? • Peer review with team • Validate with real users • Put to use Tip: Put the context model in the business case and share it with all team members 29
Use Case Models
What is Use Case Modeling? • The modeling of use cases associated to a system • A Use Case Model should have: – – Systems identified Significant “generic” actors identified Operations the actors perform identified Operations grouped by goals (epics) Creating a Use Case Model during elicitation can quickly help with clarification of requirements and project scope boundaries 31
Example of Use Case Model 32
Benefits of Use Case Modeling • Helps identify missing scope • Clarifies scope • Shows dependencies • Supports estimation • Supports system segmentation • Supports project planning (and sprint 0) 33
What is needed? • Choose a UML modeling tool: – MS Visio – MS Power. Point – can be done – Paper, Pencil & Eraser UML = Unified Modeling Language. Standardized symbol notation maintained by the International Organization for Standardization (ISO) 34
Rules of Use Case Modeling • Reduce Actors to their lowest common denominator – System Admin, Worker, Manager, etc. • Do not try to show roles/permissions in the use case model • Ignore “Cancel” – assume it exists at all times • Ignore exceptions (user error pop-ups) – save that for the use case itself • Ignore navigation – show dependency only • Neatness & accuracy do count • Keep each model simple - 7 to 9 Use Cases per Page • Most important is that all use cases get identified – Use Cases = Scope 35
Basic Modeling Elements Enter System Name System Boundary – from UML Use Case stencil set 36
Basic Modeling Elements Actor – from Use Case Stencil Movie Reviewer Actor’s Name 37
Basic Modeling Elements Use Case – from Use Case Stencil <Actor Name> 38
Basic Modeling Elements on i t ia c o ss A Movie Reviewer n de D en p e n cy e en o ati r z ali G es ds d n u l te x Inc E Associations – from Use Case Stencil 39
Basic Modeling Elements Movie Reviewer This is all you need Tip: Unless it helps with the story, you can use the generalization arrow for all places 40
Finding Use Cases • Use Cases are operations (actions) performed by an actor using the system – Yes, you can model use cases that are not part of the system if needed to show that they are out of scope • The easiest way to find use cases is by studying the actor’s process workflows – Look for action verbs (operations) that are performed on nouns (business objects) – Ex: Search for Movies (<action verb>…<noun>) • Best time to create the use case model is while eliciting the process workflows 41
Use Cases Modeling • Start by putting all of your actors and use cases on a single page – then segment by workflow 42
Example - Manage Film Profiles 43
Example - Manage Films Library 44
Example - Manage List of Film Actors 45
Examples of UC Model Hierarchy 46
What Next? • Peer review with team • Validate with real users Tip: Use the list of grouped use cases to plan the development work (Project Backlog) 47
Business Object Models
What is Business Object Modeling? • The modeling of business objects associated to a system • A Business Object Model should have: – – All associated business objects modeled Attributes displayed Operations displayed Relationships between objects displayed • The Business Object Model is also known as (aka) an “Entity Relationship Model” Creating an Object Model during elicitation can quickly help with clarification of requirements and project scope boundaries 49
Example of Business Object Model 50
Like a Class Model? • Business Object model differs from a Class Model – No system objects – No attribute details (type, character count, etc. ) – No system attributes (ex: IDs, Keys, etc. ) – Does share stencils and structure 51
Benefits of Business Object Modeling • Shows dependencies • Supports the database modeling • Supports the UI modeling • Shows where the use case operations exist • Shows the important attributes of each object • Supports system segmentation 52
What is needed? • Choose a UML modeling tool: – MS Visio – MS Power. Point – can be done – Paper, Pencil & Eraser 53
Rules of Business Object Modeling • Only model what is important to the picture you want to portray • There is no perfect model – its like a blueprint • Neatness & accuracy do count • Keep each model simple – use hierarchy structure like you would for flowcharts • Most important is that viewers all perceive the same conclusions 54
Basic Modeling Elements Enter System Name System Boundary – from UML Use Case stencil set 55
Basic Modeling Elements Object (aka Class) – from UML Class Stencil Object‘s Name Object’s Attributes Object’s Operations 56
Basic Modeling Elements n n io t a i o p m Co io sit on i t a reg n g Ag oc s s D c ire A d e t A d te oc s s In s A al er n e i r he on i t cia o s io t a i G Relationships– from UML Class Stencil 57
Basic Modeling Elements This is all you need 58
Finding Business Objects • The easiest way to find business objects is by studying the actor’s process workflows – Look for the nouns (business objects) that are being interacted with by the actor • Best time to create the business object model is while eliciting the process workflows 59
Modeling Example – System Boundary Start by adding and naming your system boundary 60
Modeling Example – Objects Add your first business object 61
Modeling Example – Objects Give object a name 62
Modeling Example – Attributes Add attributes Scrub these with the team later to resolve down to the minimum attributes needed to support the business activity – each attribute takes space and adds product weight 63
Modeling Example – Operations Add Operations (Use Case Titles) Can you see the story coming together? 64
Modeling Example – Lists Add other business objects and associations Directed Association Note that the list’s attributes correlate to column headings for the list 65
Modeling Example – Lists Add other business objects and associations Aggregation Association with Cardinality noted 66
Modeling Example – Objects 67
Modeling Example – Actors (optional) Tip: Including some actors helps take the “scare” out of the model 68
What Next? • Peer review with team • Validate with real users Tip: Use the object model to plan the development work 69
Business Object State Models
What is State Modeling? • The modeling of the different states a business object can be in over its lifecycle • A Business Object State Model should have: – Business Object identified – States are identified – Significant actors might be identified Creating a State Model during elicitation can quickly help with clarification of requirements 71
Example of a State Model 72
Benefits of State Modeling • State changes are not easily depicted in process workflows • State changes can be important to the system • Having the state model can clear up behavioral misconceptions 73
Defining the States • Best Practice for the State Model is to depict each business object separately – Unless relationships are affected by the state changes • The easiest way to find the state changes is by studying the process workflows • Best time to create the state model is while eliciting the process workflow • The model is only needed if it adds value to the team 74
What is needed? • Choose a UML modeling tool: – MS Visio – MS Power. Point – can be done – Paper, Pencil & Eraser 75
Rules of State Modeling • Single Page • Typically single business object – but can be multiple • Minimal Labeling – but adding business rules can help 76
Basic Modeling Elements Enter System Name System Boundary – from UML Use Case stencil set 77
Basic Modeling Elements Start Node End Node 78
Basic Modeling Elements State Decision 79
Basic Modeling Elements Connector 80
Basic Modeling Elements This is all you need 81
Developing the Model • Study the status changes for a business object along its workflows through its entire lifecycle • Identify: – What are the different statuses (states) – What action triggers the status change – What rules control the status change – Which actors can execute the status change 82
Developing the Model Start by adding and naming your system boundary 83
Developing the Model Add Terminators (Start & End) 84
Developing the Model Add States 85
Developing the Model Add Decision Points 86
Developing the Model Add Connectors & Trigger Actions 87
Developing the Model Tip: Add Actors (optional) 88
What Next? • Peer review with team • Validate with real users • Put to use 89
Business Workflow Models
What is Workflow Modeling? • The modeling of the process activities that get performed in the journey to reach a goal • A Workflow Model should have: – Consistent level of abstraction – Clear division of steps – Key decision points identified • Workflow Modeling is also known as “Process Mapping” Creating a Workflow Model during elicitation can quickly help with clarification of requirements 91
Example of a Workflow Model 1. 0 2. 0 3. 0 4. 0 6. 0 5. 0 7. 0 92
Benefits of Workflow Modeling • Activities are exposed to: – Identify what is part of or not part of the system (scope) – Depict the one best way to perform the work – Help determine what can be automated – Contrast current and future processes – Support discussion about the process 93
Defining the Workflow • Best Practice for the Workflow Model is to depict each process at the same level of abstraction – Use separate models to detail out lower level workflows • Swim lanes help when there is a need to depict ownership of activities (ex: by department, machine vs manual, etc. ) • Breaks in time (delays, waits) can be very important • The model is needed to properly analyze the process being discussed • Decide if both current and future state flows are needed 94
What is needed? • Choose a UML modeling tool: – MS Visio – MS Power. Point – can be done – Paper, Pencil & Eraser There is a symbol set called BPMN that uses 30+ symbols – Recommend not using this in requirements elicitation – save it for the analysis & design phase 95
Rules of Workflow Modeling • Single Pages • Separate pages for separate levels of abstraction – This segregation can wait until clean-up – Label levels (level 0 = top) • Simple symbols - KISS • Minimal Labeling – but adding business rules can help 96
Basic Modeling Elements Swim lane 1 Swim lane 2 • Use swim lanes to delineate different domains – Departments, Actors, System/Actor, Locations, System/System, etc. • If not needed, a border only works nicely 97
Basic Modeling Elements St ar Pr t/E oc De nd Co ion es s. A cti vit y nn cis Ga te w ec to r ay • Use these basic “high school” level symbols – KISS principle so executives can understand your model 98
Developing the Model • Study the business process • Identify: – What are the explicit / implicit activities being performed – What triggers the next step – Where are the key decision points – Who performs the activity – Who is the audience for this model – What level of abstraction is needed for the story 99
Start your Model Workflow Title Actor Titles 100
Add Start & End Points Start labeled with trigger action End labeled with process goal 101
Add Activities, Decisions, Connectors Take care about Business Object names Activities star with Action Verb Numbering Activities can help - optional 102
Identify System of Interest - Optional New Film Review Application 103
Create Lower Level Flows as needed Note Level change Note numbering scheme 104
More lower Level Flows 105
And. . lower level flows Stay on same level of Abstraction 106
Lowest Level? • There is a workflow methodology that models at the level of human movements (& thoughts) • This is rarely used – but needed if minimal time on task for user is critical • 18 notation symbols are called “Therbligs” Therbligs were developed in the early 19 th century by Frank & Lillian Gilbreath 107
What Next? • Peer review with team • Validate with real users • Put to use 108
Storyboarding Modeling
What is Storyboard Modeling (aka Screen Mock-up Modeling)? • Storyboarding is the visual modeling of the different “scenes” along a workflow (or storyline) • In this case we are talking about the user interface screens used to along a workflow • A Screen Mock-Up Model should have: – Workflow activity goal identified – Attributes & Operations labeled – Only enough detail to bring clarity Creating a Screen Mock-Up Model during elicitation can quickly help with clarification of requirements 110
Example of a Screen Mock-Up 111
Benefits of Screen Mock-Up Modeling • A visual story of the workflow emerges • Business attributes and operations become clear • Scope of work for user interface becomes clear 112
Defining the Screens • Best Practice for the Screen Mock-ups is to depict each screen separately • Avoid putting in any “look & feel” style - that is typically a different task at a different time with a different audience • Label attributes and operations • Consider using “Lorem ipsum dolor” for data – to avoid distracting the audience Helpful hint: Try entering =lorem() on a new line in Word or Power. Point. 113
What is needed? • Choose a modeling tool: – MS Visio – MS Power. Point – can be done – Paper, Pencil & Eraser 114
Rules of Screen Mock-Up Modeling • Single page per screen • Typically single business object – but can be multiple • Only include what is needed – just enough detail to define the requirements • If marking up an existing screen, blur or shade over any details that are not relevant 115
Basic Modeling Elements Screen Name Screen Frame – from Wireframe stencil set 116
Basic Modeling Elements u r ne in en M Sp n w do x Bo p xt ro D Te l be La e bl Ta bs Ta io n x Bo tto Bu ck he ad R C n tto Bu 117
Developing the Model • Study the value added objects, attributes, and operations along the workflow • Identify: – What are the different business objects – Which business object attributes are needed – Which business object attributes are required – What operations need to be performed 118
Developing the Model Start with a “clean canvas” 119
Developing the Model Pile in attributes that will belong with this business object Start to define how data will be presented Start to define space needed for each attribute 120
Developing the Model Pare down clutter by pushing attributes into logical groups If time permits, consider capturing details about each data field: type, length, max/min values, etc – you will need these for use cases later 121
Developing the Model Clean up and order attributes Add operations 122
Developing the Model Detail out other screens 123
Developing the Model Pretty it up and build the Story Helpful hint: Paste into Power. Point and add hot spots to allow clicking through model. 124
What Next? • Peer review with team • Validate with real users • Put to use 125
A picture tells a 1000 words? 126
Recap • We have looked at 6 common visual models • All are created during early stages of a project • All add value to the project • Each is fairly simple to create • Getting the correct information is the hardest part 127
Experience Notes • No two modelers will create in the same way – what is important is that viewers perceive the correct conclusions. • Having visual models adds clarity to your project • As a PM, you might need to ask your BA to create some visual models 128
Questions? 129
Bonus Section System Sequence Diagrams
What is a Sequence Diagram? • The modeling of the messages passed between system components • A Sequence Diagram should have: – Name of the use case being modeled – The Actor Title – Each system component touched Sequence Diagrams are traditionally in the Systems Analyst domain but BAs can generally create them 131
Example of a Sequence Diagram 132
Benefits of Sequence Modeling • Messages between system components can be traced • Deeper understanding of the system is revealed 133
What is needed? • Choose a UML modeling tool: – MS Visio – MS Power. Point – can be done – Paper, Pencil & Eraser 134
Rules of Sequence Modeling • Depict only one use case • Single Page • Landscape unless forced to be Portrait • Messages use <verb> <business object> format • Show message direction • Message to self (recursive) might be needed for clarity 135
Basic Modeling Elements Activation Fragment (frame) Message Return Message Self Message Actor Lifeline 136
Defining the Model • Determine what each system component actually does • Validate that you have the correct system components • Use intuitiveness & critical thinking to determine the message names and sequence order • Validate with others 137
Start your Model Use Case Title 138
Add Actor & Components Label Actor and System Components 139
Add Messages & Activations 140
Identify System of Interest - Optional New SSO IDM 141
What Next? • Peer review with team • Validate with real users • Put to use 142
Bonus Section Deployment Diagrams
What is a Deployment Diagram? • The modeling of “hardware” where system components reside and their intercommunication protocols • A Deployment Diagram should have: – Name of the system being modeled – Name of each Hardware Node – Names of System Components at each Hardware Node – Name of Communication Protocol between each Hardware None Deployment Diagrams are traditionally in the Systems Analyst domain but BAs can generally create them 144
Example of a Deployment Diagram Missing Comm Protocols and system components 145
Benefits of Deployment Modeling • Physical & Geographical aspects of the system can be visualized • Minimum components to operate at each hardware node are known • Can be used for configuration management & field installation guidance 146
What is needed? • Choose a UML modeling tool: – MS Visio – MS Power. Point – can be done – Paper, Pencil & Eraser 147
Rules of Deployment Modeling • Depict only one system • Single Page • Landscape unless forced to be Portrait • List all system components and versions • List communications lines with their protocols 148
Basic Modeling Elements User hardware Boundary Application hardware System Components Communications 149
Defining the Model • Determine list of hardware used (can be virtual) – Note CPU speed, RAM, etc • Determine list of system components at each hardware – Include operating system – If customer hardware, include browser types and versions • Determine communication protocol between hardware • Validate with others 150
Start your Model 151
Add Hardware & Communications 152
Add Components & Versions 153
Identify System of Interest - Optional New SSO IDM 154
What Next? • Peer review with team • Validate with real users • Put to use 155
- Slides: 155