Loading presentation...

Present Remotely

Send the link below via email or IM


Present to your audience

Start remote presentation

  • Invited audience members will follow you as you navigate and present
  • People invited to a presentation do not need a Prezi account
  • This link expires 10 minutes after you close the presentation
  • A maximum of 30 users can follow your presentation
  • Learn more about this feature in our knowledge base article

Do you really want to delete this prezi?

Neither you, nor the coeditors you shared it with will be able to recover it again.


The Case for "Business Use Cases"

No description

Lon Kimberlin

on 4 August 2016

Comments (0)

Please log in to add your comment.

Report abuse

Transcript of The Case for "Business Use Cases"

The Case for "Business Use Cases"
The Business Use Case
The Business Use Case is a technology free description of system behavior as it responds to requests or actions outside of the system. This is typically done by treating the system as a "black box" and detailing system actions based on detailed scenario-driven threads focused on achieving a goal or task.
Karl Wieger's
Use Case Template
Use Case ID
- Hierarchical / Relational Numbering
Introduction to Business Architecture on BUC
- Simple, self evident explanation, verb object.
Brief Description
- Basic information in two sentences.
TR Business Use Case
Thom Riemersma uses the following fields
PM2 Business Use Cases
Use Case Name
~ Verb-Noun, Goal Driven
Use Case Number
- Relational Numbering Convention

- Business Use Cases WILL evolve and should be noted
The objective is that the Business Use Case describes
the system must do (rather then
it will be done).
The PM2 prescribes the following fields to be included in a Business Use Cases.
- Brief Description of What the User Intends to Achieve
- A quick overview of the which connects goal, actor and system.

- Someone or something outside the system acting on being prompted.
- Names from business as use case references.
- The conditions that must be true for the trigger to work.
- The event that cause the Business Use Case to begin its cascade.
(the trigger can be external, temporal (time based) or internal)

Basic Course of Events
- The Normal / Basic / Happy Path Flow of the Use Case

Alternative Paths
- The "paths" less followed but possible in the Use Case
( the greater the number of decisions the more likely alternative paths)
- What happens when something goes wrong at the system level.

Post Conditions
- What is guaranteed to be true when the use case closes.
Business Rules

- Policies defining org. conduct itself in the Use Case.
(rules are typically partnered with Basic Course of Events)
Notes / Comments
- Points of Clarification to Others.
Author / Date
- Tracking and Connecting
- An explanation of the use case in plain language.
- The enterprise applicability of the Business Use Case.

- Summary of the hurdles / opportunities in the current state.
- Solution enablers believed to be true at a high level.
Business Actors
- Those people or applications outside the solution.
Business Entities
- Data / information provide to / used by the solution.
- The event or activity which will kick off the use case cascade.

- Specific circumstances that enable the business case.
- The end result of the Business Use Case also the Goal.
Main Flow
- The Happy Path Interaction of System and Actor.
Alternate Flow
- Other possible pathways outside of the expected path.


- Anything that can go wrong within the solution.
System Details
- Matrix input / outputs / data flows.
Data / Activity Flow
- Diagram of the business use case.
Business Rules
- Governance of what the actor can / can't do
Logical Rules
- Validation governing the main flow.
Screen Shots
- Visualization of User Interfaces

Special Requirements
- Added assumptions
Revision History / Approval / Appendix
Use Case Name
- Concise reflection of users task (verb - noun)
Create By

- The source of the documentation
Date Created
- Documentation Start Date
Last Updated By

- Name of last editor
Updated Date
- Date of last update
Use Case Identification
Use Case Definition
- Person or entity outside the solution "pulling the levers".
- Plain language explanation of the Business Use Case.
- Any circumstances which must be true for the use case to start.
- State of solution at Use Case completion.

- The relative importance of capability to overall Use Case.
Frequency of Use
- Relative number times used for a defined period of time.
Normal Course of Events

- Detailed normal course of events expected
Alternative Courses
- Other legitimate courses that can be anticipated.
- Errors that happen and the responses they elicit.
- Other Use Cases "called" by this Use Case
Special Requirements

- Non functional requirements
- Noted presumptions
Notes / Issues
Pre / Post Conditions
- Pre and Post BUS conditions relative to the trigger
- A detectable to the business event starting the BUC
Primary Flow
- Business / Solution Interaction towards achieving goal
Alternate Flows

- Any interaction in the same BUC that is not the primary
Local View Diagrams
- The BUC with all actors and other BUC interaction.
Activity Diagrams

- Primary and alternate BUC flows.
is the Goal?
Must Be in Place?
Steps are Most Likely / Expected?
Roles are Involved?
Ignites the Action?
Other Way Could This Be Done?
Problems Do You Foresee?
Are the Anticipated Outcomes?
Business Rules Define the Process?
The SRF Business Use Case
Actor : The person or system requesting action.
Preconditions : Circumstances and events required to be in place.
Description : 1 Paragraph, Less the 4 Sentences.
Trigger - A clear / distinct event which will initiate Use Case
Process / The sequence of events / steps between actor and
Course of Events : system describing the use case. The steps are simple
single actions and generally involve one for one
interaction of actor and system.
Post conditions : The condition and event that signals completion.
Exceptions : What could possibly go wrong with preconditions / steps.
Assumptions / Business Rules : What is believed or defined to be "true" for a step or the steps to take place or happen as described.
Notes and Comments :
Running thoughts as the Business Use Case Develops

Full transcript