Business Processes
• A business process describes a set of activities
that are necessary to complete a response to a
stimulus applied to an organization.
What is a business process?
Customer (request)
Supplier (order)
Supplier (shipment)
Inventory System
(update inventory)
Business
Management (directive)
News (Info. about competitor)
Committee
(response)
Marketing
(plan)
Examples of Business Processes
• Routine business processes:
–
–
–
–
fulfill customer order
receive shipment for inventory
review loan applications
create a two week payroll
• More complex business processes:
– Developing a new product
– Deciding on a location for new store
– Designing a new marketing campaign
Triggering Business Processes
• The stimulus for an organization to respond to
could be external:
– customer request
– supplier shipment
– new knowledge about competitor
• or from an internal source:
– management wants new product developed
– organization opening a new branch office
Business Process - A Response
• The response is the action(s) that the
organizations takes as a result of the stimulus.
– For example:
• ship product to customer
• update inventory based on shipment
• All of the activities required to recognize the
stimulus and develop and implement the final
response are the business process.
Business Process Modeling
• What is a process model?
– A formal way of representing how a business system
operates.
– Illustrates the activities that are performed and how data
moves through the process.
– A process model can be used to document current system
or to illustrate new system
• Use Cases and Data Flow Diagrams (DFD) are
among many techniques to support Business Process
Modeling
Why Draw Process Models?
To
clearly communicate the processes (flow of
data) through a system.
To help us structure our view of the business
process.
To articulate our understanding of how a system
under study actually works
To formalize the description of processes
(documentation)
Diagrams are sometimes easier to understand than
text.
Why Draw Process Models?
• Why use a diagram and not just text?
– “Since we previously had no way of showing a tangible
model, we have had to build the next best thing, which
is to use English narrative to describe the proposed
system. Can you imagine spending five years’ salary
on a custom built house on the basis of an exhaustive
narrative description of how the house will be built? ...
If you use English to describe a complex system... the
result takes up so much space that it’s hard for the
reader to grasp how the parts fit together”
(Gane and Sarson, Structured System Analysis, 1974)
Use Cases
• A Foray into the world of objects
– Look at business processes in an object oriented
view
• more ‘natural’ in its makeup
– Not all that new
• Jacobson 1986 formally introduced them
• Late 1990’s they took hold as a ‘norm’
– Part of UML
Use Cases
• This newer methodology allows analysts to
consider what the user and the system need
to do to interact and handle a business
process
• They have recently moved from objectoriented analysis into more mainstream
development
• Now, pretty much a standard
Use Case Modeling Process
• First, try to understand the general processes to
be studied.
– Document Analysis
– Questionnaires about problems
– Observation
• Ask questions, test assumptions.
Use Case Modeling Process
• Try to understand the objectives of the new
project
– Interviews
– JAD
Use Case Modeling
• Starts to document the process
• Triggers:
– Inputs to each use case with source
• What causes the system to ‘wake up’ and do something?
– Outputs with sync (destination)
– Major Steps
• with links to all inputs and outputs
• What do the users do?
• What does the system need to respond with?
Automation
• Use Cases are critical here
– The ‘2B’ system is, in fact, the ‘as is’ system
– More interested in physical processes than logical
Improvement
• Two objectives
– Need to understand ‘as is,’ since it will remain
the core system
• Use Cases are the foundation for discussions about
shortcomings of the current system
• More time is spent gaining an understanding of the
logic of the current system
Reengineering
• The ‘as is’ system is studied in depth later in the
project
– deemed ‘essential systems analysis’
– start with the logic of the process
• design process, procedure, and physical system
• study current system
• develop a transition plan
– significant user involvement in systems specifications
• interviewing
• JAD
Use Cases
• A use case illustrates the activities that are performed by
users of a system
• Use cases are logical models – they describe the activities
of a system without specifying how the activities are
implemented
• Triggers:
– Initiated by an external “actor” (which may be a person, a role,
or even another system)
– Can be initiated by the passage of time, which is a specific type
of trigger, a “temporal event”
Benefits of using use cases
• Facilitates user involvement. Understandable.
• A view of the desired system’s functionality from a
business process viewpoint.
• An effective tool for validating requirements.
• An effective communication tool.
• In general: provide a representation of the behavior of a
business organization for the purpose of understanding
the business itself
Processes
• Processes are named with verb/noun combinations
• High level processes (also known as “events”) are
logical units of action that must be completed as a
whole
• They start with general verbs such as “process”,
“respond to”, “generate” or “maintain”
• Lower level processes are discrete, detailed activities,
with specific action verbs such as “calculate” or
“validate”
What processes do
•
•
•
•
•
•
Perform computations
Make decisions
Sort, filter, or otherwise summarize data
Organize data into useful information (generate reports)
Trigger other processes
Use stored data (create, read, update, or delete a record)
Triggering a business process
• Stimulus for a process could be from outside the
organization
– Customer makes a request
– Supplier sends a shipment
– Marketing department gets new info re competitors
• or from an internal source
– Manager wants to analyze sales force productivity
– Inventory for a specific item falls below its reorder point
Output from a business process
• The purpose of a business process is to generate a
response to a trigger
– A product is shipped to a customer
– Inventory is updated to reflect new inventory
• All of the activities required to recognize the stimulus and
develop and implement the final response are the business
process
Use Cases
• One way to identify use cases is to start with actors think about all the actions they take
• Another way is to look directly at outcomes – what are
the different services we need to provide.
• For each use case, want to be clear on:
–
–
–
–
the actor that initiates the event
the event or business process (this will be the title)
the first input or trigger
all inputs, outputs and responses
Elements of a Use Case
• Note: like many of these tools and techniques,
there are ‘norms’ rather than ‘standards’. Use
Cases can be relatively simple and
straightforward, or they might need to model
a highly complex process, where they would
be correspondingly detailed.
Elements of a Use Case
• Basic Information
– Name – as simple and descriptive as possible
– Number – just to keep track
– Priority – how essential is this to the overall
system
– Actor – the key person, system, or device that
interacts with the process
– Trigger – what starts the use case to happen?
• can be external (customer visits our web site)
• or temporal (its payday)
Elements of a Use Case
• Preconditions
– the state the system must be in before the use
case can commence
• for example, a ‘sign in’ use case would require that a
customer has an account. If not, it would direct them to
a ‘create account’ use case
Elements of a Use Case
• Major steps performed
– ‘Normal Course’
• probably the one you want
• no exceptions exist
– ‘Alternative Courses’
• what happens if some alternative event takes place
– ‘sign up’ would be an alternative course in our eBy log in
example
Elements of a Use Case
• Postconditions
– an inventory of the results of progressing
successfully through the use case
• Exceptions
– what errors could happen in the steps
• Summary Inputs and Outputs
– major elements and their source or destination
Steps for generating use cases
• Identify the use cases – think about the triggers
coming in to initiate action, and the major inputs and
outputs
• Identify the major steps for each
• Identify elements within each step – its triggers, inputs
and outputs
• Confirm the use case with users
Some comments re Use Cases
• If you end up with a lot of use cases, think about
combining some of them into higher level processes
• Write from the perspective of an independent observer
• The information flows should deal with “information”
rather than physical objects
• There should be a match between the major
inputs/outputs and the information flows
Not all elements of the
use cases
are always required.
They should
be as simple, or as
complex, as
you need them to be.