What
Is A Process Flow Diagram?
As
the name implies, Process Flow Diagrams are pictures that describe how
a thing is done; they illustrate a process. In the software/systems
development world, a process flow is something you would create after
you've written your Requirements Document,
but before you begin working on your Software Design
Document. A process flow breaks a big task down into individual
steps, and then describes the dependencies and relationships between
those steps. You can't really design your software or system until you
have a solid understanding of the process that software or system must
support. Processes that look very simple and straightforward aren't
always what they seem, but until you begin detailing a process you won't
know what's missing.
Consider
the task of answering the phone. A basic process flow for answering
the phone might look like this:
Notice
how many separate steps are involved in having a phone conversation.
Each step is represented in the diagram as a separate box. Also notice
the two paths through the process, represented by arrows in the diagram:
1)
You could answer the phone, find no one on the other end and hang up
2)
You could answer the phone, find that there is a caller on the line,
talk for a while, come to the end of the conversation and then hang
up
There
are no other paths available to the phone user; for instance, you can't
hear the phone ring and then decide if the conversation is over, so
there is no arrow leading from the box where you hear the phone ring
to the box where you decide if the conversation is over.
A
process flow diagram is intended to show all the possible actions and
all the possible outcomes involved in a task, procedure or process.
The example above could be expanded considerably if you take answering
machines, caller ID, call waiting and other possibilities into account.
A
complete process flow diagram helps you to anticipate how your program
or procedure and your user(s) will interact. It serves as a roadmap,
ensuring that your program or process will be able to respond to every
possible action the user might take.
The
goal in any process flow is to give a complete, graphical representation
of how a program or process works, and what happens as a result of various
actions on the part of the user.
Back
to Top
How
to Create A Process Flow Diagram
The
basic concept of a process flow is pretty simple. You need to break
a program or process down into separate steps, then figure out how the
user gets from one step to the next.
For
example, consider the process of getting yourself a drink from your
refrigerator. Begin by making a list of the steps involved in getting
a drink.
| Open
the fridge |
| Look
at the available drinks |
| Take
a drink out of the fridge |
| Close
the fridge |
This
is a good start, but you can break it down even further if you think
about it. For instance, this list of steps assumes that there are drinks
in the fridge, and that each drink is self-contained. What if you decide
you want milk? The steps listed above would indicate that you should
be drinking your milk out of the carton. Here's a more detailed list
of steps:
| A.
Open the fridge |
| B.
Look at drinks in the fridge |
| C.
Choose a drink |
| D.
Remove the drink receptacle from the fridge |
| E.
Close the fridge |
| F.
Determine if the drink receptacle contains more than one serving |
| G.
If the drink receptacle contains more than one serving, put the
receptacle on the countertop and go to step G.1; if the receptacle
contains only one serving, go to step H |
| G.1
Go to the cupboard containing cups and glasses |
| G.2
Choose a cup or glass |
| G.3
Remove your cup or glass from the cupboard |
| G.4
Close the cupboard |
| G.5
Retrieve the drink receptacle |
| G.6
Pour one serving of your drink from the receptacle into your glass
or cup |
| G.7
Open the fridge |
|
G.8
Put the drink receptacle back into the fridge
|
| H.
Close the fridge |
Now
imagine the extra steps introduced if you want to account for the case
where you look for a drink, but don't find any drinks in the fridge.
Think about how you would include steps for having ice with your drink.
As you can see, even the simplest task can seem like a major production
when you break it down into its smallest components.
You
may be wondering if all this detail is really necessary; to get a drink
from the fridge, probably not. But to write a computer program, absolutely!
You don't want to discover that you've forgotten to include a step or
possible user action AFTER you've begun to write your code, because
it can be very hard to backtrack through the program and squeeze that
new step or action into a program you've already begun to write. As
you wrote the program, whether you realized it or not you were going
with an assumption that no other steps or actions would have to be accomodated.
Whole modules may have to be rewritten when your assumptions change,
so it's a far better thing to spend an extra few hours nailing your
process flow than to spend extra days and weeks dealing with a new step
or action later.
Once
you have all of your steps listed and have reviewed them to ensure you've
included every possible condition in your program or process, get someone
else to look over your list. Ideally, this should be someone who has
some familiarity with the process your system or program will support.
Virtually without exception, that other person will bring up steps you
haven't considered.
When
you're sure you've got your list of steps finalized, it's time to start
creating your diagram. Take each step, and make it into a box. Then
connect the boxes with arrows to illustrate the possible paths through
the process. Whether
you use a sketchpad, a white board, a chalk board or a computer program,
be prepared to manipulate your working copy quite a bit before getting
a finished product. Some people prefer to begin with diagram sketches
instead of step lists; use whatever makes the most sense to you. If
you're a visual person, diagram sketches may get you off to a better
start than written step lists. In our 'getting a drink' example, the
process flow might look like this:
The
process flow diagram has a start and an end, and the flow moves in a
circular path from the start box to the finish box. Notice that there
are three possible paths to get from the start to the end:
1.
You could open the fridge, find no drinks and close the fridge.
2.
You could open the fridge, choose a single-serving drink and close the
fridge.
3.
You could open the fridge, choose a drink receptacle, pour yourself
a single serving of the drink and then close the fridge.
Notice
that there are two decision points in this process flow - places in
the process where the user of the process must answer a yes/no question.
Most process flows for software have many decision points, and therefore
many different paths the process, or user of the process, can possibly
follow.
Once
you have a good working copy of your flow, follow each path through
your flow from the START box to the END box. This will help you to discover
possibilities you hadn't thought of, and to see if there are any dead
ends in your flow - places where the user will get stuck instead of
being allowed to get to the END box.
In
the example above, following all the paths would point out that I haven't
included any steps to cover the situation in which the user opens the
cup/glass cupboard and doesn't find any cups or glasses. Unless I add
some more steps to cover this possibility, the user will get stuck in
the "Choose Cup/Glass" box whenever no glasses or cups are
found. I'd also see that I haven't included any steps to accomodate
the situation in which the drink is in a receptacle, but the receptacle
only has one serving left in it. Given the flow I've written, the user
would end up putting an empty receptacle back into the fridge. Again,
I would add the steps for that path to my process flow.
Your
first draft of the process flow will get quite a workout in terms of
edits and changes, so don't worry about formatting, fonts and other
details of how pretty it looks until your flow is finalized. If your
finished diagram is very complex, you may want to use different colors
of arrows and boxes to distinguish the different paths. Notice how I've
used green in the START box, a reddish tone in the END box and yellow
in the decision points; the meanings of these colors (go, slow down
and stop, respectively) are fairly universal, so people viewing the
diagram will get an immediate idea of what happens at those places in
the diagram before they even read the contents of the boxes.
This
simple drink example should give you enough information to get started
on your own process flows. To review:
1.
Gather your requirements in a Requirements Document
2.
Break the process defined by the requirements down into individual steps
3.
Have someone else review your steps, and edit them accordingly
4.
Sketch out a process flow
5.
Follow all of the possible paths through your flow from START to END
6.
Edit your flow diagram to accomodate new or different steps discovered
while following the available paths
7.
Clean up the process flow diagram so it will be presentable to your
users
Back
to Top
Tools
to Try
You
don't really need anything more than boxes and arrows to make a process
flow diagram, though as the complexity of your diagrams increases you
may choose to use different shapes to represent different kinds of paths,
decisions and actions. There are many different formalized systems for
creating process flows, and while each dictates its own set of formatting
rules, all that really matters in the end is that anyone looking at
your process flow can follow its paths and understand the process it
illustrates.
Most
MS Office programs contain drawing tools. I created the flows shown
in this page in MS Power Point, because in my opinion its large, empty
workspace and its flexibility are easier to work with than the workspace
provided by Word or Excel. Word "expects" you to write documents
and Excel "expects" you to create spreadsheets, so they're
not always optimal for creating or manipulating graphics.
If
you don't have MS Office but you do have Windows, you can use the Paintbrush
program that comes with windows. More information about Paintbrush and
the things you can do with it can be found in the Stupid
Graphics Tricks page.
There
are plenty of other flowcharting programs available if you want or need
to get really fancy with your diagrams. Visio Technical has templates
and tools specially designed to help you create all kinds of different
diagrams, including network layouts, database diagrams, and yes, process
flows. ABC Flowcharter is another tool you may see on software shelves
for this purpose. Both are excellent programs, but I would discourage
you from investing the money in either of them unless you're sure that
your needs far exceed what can be accomplished with software you already
have.
Back
to Top
