Send the link below via email or IMCopy
Present to your audienceStart 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.
Make your likes visible on Facebook?
You can change this under Settings & Account at any time.
The Case for "Business Use Cases"
Transcript of 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.
Use Case Template
Use Case ID
- Hierarchical / Relational Numbering
Introduction to Business Architecture on BUC
- Simple, self evident explanation, verb object.
- 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
- 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.
- What is guaranteed to be true when the use case closes.
- 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.
- Those people or applications outside the solution.
- 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.
- The Happy Path Interaction of System and Actor.
- Other possible pathways outside of the expected path.
- Anything that can go wrong within the solution.
- Matrix input / outputs / data flows.
Data / Activity Flow
- Diagram of the business use case.
- Governance of what the actor can / can't do
- Validation governing the main flow.
- Visualization of User Interfaces
- Added assumptions
Revision History / Approval / Appendix
Use Case Name
- Concise reflection of users task (verb - noun)
- The source of the documentation
- Documentation Start Date
Last Updated By
- Name of last editor
- 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
- Other legitimate courses that can be anticipated.
- Errors that happen and the responses they elicit.
- Other Use Cases "called" by this Use Case
- 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
- Business / Solution Interaction towards achieving goal
- Any interaction in the same BUC that is not the primary
Local View Diagrams
- The BUC with all actors and other BUC interaction.
- 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