Business requirements are defined and documented in the analysis phase. On many projects, the requirements can be easily uncovered, written down, and agreed to. Then, off to design and construction we go. On larger projects, however, gathering requirements is not always so easy. Understanding business requirements can be difficult, especially if they involve the complexities associated with modeling enterprisewide processes. Process modeling is a technique for understanding, defining, and precisely representing underlying business processes.

Let’s assume that you have already used a variety of techniques to gather business requirements. You’ve found out that a lot of what the business stakeholders describe are not requirements at all. Instead, much of what you have been told represents business facts, opinions, misunderstandings of how things work, and general unrelated rambling. The purpose of process modeling is to take all of these statements from various individuals and put them together to precisely and accurately define the business process—either as it exists today or as it should exist in the future. The business process does exist, but it takes skilled hands and minds to precisely describe it on paper.

Start general
All processes have input, some actions that transform the input, and an output or result. When doing process modeling, first look for the high-level series of related activities that represent one logical process. Give this process a descriptive name, usually in the form of a noun. For instance, there may be a series of activities that describe a process called “Sales Order.” The process itself can be described in terms of a business definition, frequency of occurrence, relative importance, and so on.

Look for events
Events are occurrences that cause a process to be initiated. The event may be external to the company or to the department that is performing the process. The event may also be time-based. For instance, many financial processes are triggered by the closing of the financial period on a monthly and yearly basis. If it looks like a process is triggered by the completion of another process that is internal to the company or to the group, it is likely that the process you are looking at is part of a larger process and not one that stands on its own.

Fill in the details
After you have described the general process and identified the event that triggers it, you can fill in the underlying activities. Look for all of the detailed activities you uncovered that describe portions of the process. Some may be at a higher summary level than others.

Start laying out the underlying activities in order, based on what happens first, second, third, etc. Each of these activities should be action-oriented and are usually described in phrases beginning with a verb. This is not too much different than when you create the network diagram for the workplan. In some cases, activities can be done in parallel. In other cases, one activity must wait until another activity is completed. If you find that an activity is expressed at a summary level, it should be broken down into its more fundamental components.

Just as you collected some information at the process level, so you will also want to capture some basic information about each activity. This might include a short definition of the activity, who does it today, how long it takes, and any deliverables used or created.

Validate and rationalize the model
After you complete the initial process modeling pass, you should review the entire process to validate its accuracy. When you describe the underlying activities at the basic component level, it is likely that gaps will be identified and errors uncovered. For instance, you may have an activity that relies on an input, but your process does not show where the input comes from. Likewise, when the customers view the entire process, they may see activities that are missing. As new information is uncovered, you should modify the details, adding new activities where necessary.

The process model is a representation of a business process, so the customer and/or sponsor should formally approve it to ensure that it is correct.

Modeling tools
As you can probably see, the level of data collection and detail required for process modeling makes it a good candidate for an automated tool. There are many in the marketplace. Tools allow you to document the underlying processes, tie the activities together, keep track of inputs and outputs, and so forth. They also perform two other valuable functions.

First, they can tell you where you have disconnects and overlaps. If the tool captures enough information, it can tell you when pieces of the puzzle are missing or whether you have described multiple activities that are similar. Second, the tools can represent all the textual information you have gathered in pictorial or graphic form. Most people have seen large process diagrams that allow you to view how activity and information flow within a process. These visual representations are valuable when trying to streamline a process, but they are difficult and time-consuming to produce by hand.

Here are some key points to remember.

  • Process modeling is used to precisely represent complex business processes that would be difficult to understand based on the business requirements alone.
  • All business processes should have a unique name.
  • All business processes have an event that kicks them off.
  • The potentially difficult part of process modeling is in understanding and representing all the underlying basic work activities that make up the general process, including how they relate to each other to make up the process.
  • Process modeling tools are valuable because they capture all the detail and point out process errors and discrepancies. Most of them can also generate a diagrammatic representation of the process that is much easier to understand than looking at all of the details as straight text.

Project management veteran Tom Mochal is director of internal development at a software company in Atlanta. Most recently, he worked for the Coca-Cola Company, where he was responsible for deploying, training, and coaching project management and life-cycle skills for the IS division. He’s also worked for Eastman Kodak and Cap Gemini America and has developed a project management methodology called TenStep. He holds a B.S. in computer science from Iowa State University.

How do you capture business requirements?

What methods or techniques do you use to capture business requirements? What suggestions do you have for others having difficulty gathering this critical information? Send us an e-mail with your experiences and suggestions or post a comment below.