And Let the Diagramming Begin!

Like any diagramming process, there are various flavors of this document, but any work flow must cover six essential aspects per process:

  1. When does the process begin? (If preceded by a specified process, indicate the name of that process.)
  2. What happens during the process?
  3. What determines that the process has ended?
  4. What determines that the process has not ended successfully?
  5. What is the next step in the process when completed successfully?
  6. What is the next step when the process has not completed successfully?

The Work Flow Diagram should not contain a lot of detail, after all this is a diagram, and those boxes are just so large. - Ok, you can make them bigger, but why should it take the developer or stakeholder a half-hour or so, using a magnifying glass, to read the content of your boxes. Save the detail for your Use Cases. Keep your content brief.

Finally, here's a quick word on the difference between a Workflow Diagram and an Activity Diagram. Workflow Diagrams are fairly flexible and easy to read. They don't have a UML specification. Most companies seem to prefer such diagrams over Activity Diagrams. Non-technical persons have no problem reading these diagrams. However, even if a particular diagram is not defined by a UML standard, it adds a lot to the consistency of your work if you format non-standard diagrams according to UML specifications as much as it makes sense.

If, however, you are contracting with a client, such as the US Government who generally embraces UML standards, then I would still use the Workflow Diagram to get sign-off on the business process and then create the Activity Diagram as a way to begin the solution architecture. Activity Diagrams are more geared toward the developer and tend to be a bit harder for non-technical business persons to comprehend. They are defined by a UML specification.

Articles & Additional Resources

These links should give you a solid overview of what a Workflow Document is and offer some helpful patterns.
Wikipedia article on the Workflow Diagram
Brief Wikipedia article on Business Process Modeling
Repository for Workflow Modeling Patterns
Windows Workflow Foundation

Examples

Business Process Workflow
Technical Process Workflow

Syndicate content
They Say

His (Larry's) assistance in administrating the team effort and analytical work was
of the highest caliber. In addition, his contributions to the development effort
were an integral part of the project's success...

Dwight - Director of eCommerce

Larry proved to be "solutions" oriented. On several occasions, Larry identified
obstacles in the path of our goal to deploy an eCommerce solution and diligently
and independently worked with software vendors and consultants to find solutions.

Mike - Director of eCommerce Strategy

Larry is an innovative self-starter, who rarely needs supervision. He typically
exceeds expectations and enjoys the challenges associated with installing new
technology... Larry is an invaluable asset to any Information Technology team and I
highly recommend him.

Bob - Partner, Retired KPMG LLC

I've found his e-commerce analysis documents (flowcharts, diagrams, etc.) and use
cases thorough and clear. Larry was very conscientious and also has the invaluable
ability to communicate and work well with both users and developers.

Ward - Software Engineer

His documents were all very concise, even though the work he was documenting was
often difficult to describe, even to the developers... We often wished we "had
Larry" on other projects that were getting hard to control.

Dave - Software & Database Developer

His documentation is beyond compare in it's detail, accuracy and ease of reference.
His thorough documentation and notes brought calm to the chaos on many an
occasion... He is a self-starter and worked many a late night to ensure the project
stayed on course. I would love to work with Larry again.

Tom - Sr. Software Developer