As I've said in previous articles on this subject, requirements gathering is more of
an art than a science. Business process requirements however, is a good mixture
of both. I say that because business processes are a fairly finite and definable.
Sure, business processes may change over time, but gathering them is strictly
a snapshot of the organization's processes at that point in time.

The art-form you must conjure is the ability to extract those processes from
key people in the organization. Everyone has their own perspective of how the
business runs, which is a curse and a blessing at the same time. Sometimes
ego and personality conflicts enter the fray as well which presents unique
challenges in running a successful requirement gathering session.

The best thing to do is to procure a private conference room with a large table,
a projector, and a big white-board. The bigger, the better. You can keep all your
thoughts "in-cache" so to speak on the white-board.

Below are the steps I use to run these types of sessions:

1. Gather a team of subject matter experts who really know the business. You
    will want to get together 3-4 key players who are directly involved in the business
    process. These players will hopefully complement each other's understanding of
    the business since no one person will have a 100% understanding of all the details.   

2. Briefly interview each person involved in the process. You will want to get their
    job title and their role within the organization. This will prevent you from asking
    a question to the wrong person during the requirements session. You wouldn't
    ask a business analyst what the database server infrastructure looks like for
    example. At this point, you will gather information from a high-level what the 
    business model is and how all the team members fit into that puzzle.

3. Ask for a mission or goal statement. This may be a statement like: "We wish to 
   model the communication of data between our distribution centers and suppliers".

4. Get a list of entities involved in the process. These may include vendors, clients,
    profit centers, business units, or internal departments for example. By getting
    this information up front, it will save lots of time throughout the process by keeping
    only the relevant entities in the conversation.

5. Start with one end of the business process such as the initiation of a purchase
    order for example. The key here is to get the action that triggers the start of the
    business process you choose to model.

6. Ask lots of questions regarding each step. If we use the purchase order example,
   you may want to ask questions like: "is this process done online, on premisses,
   or over the phone?" and "what are the payment options?". These are very simple
   scenarios, but you get the idea.

7. Model the processes on a white-board first. This will give all the team members
    the opportunity to see each step through a progression. It will also spawn more
    questions and conversation about the relevant details of the process.

8. Train the model. Once you have a particular business process fleshed out on the
    white-board, run the model through a series of scenarios to test its durability.
    This is the part where all the team members should get involved in "what-if"
    scenarios. Don't run the model through obvious situations, hit it from all angles.
    The goal here is to break the model, find it's weaknesses, and repair them.

9. Iterate through each business process as you gradually build them and piece
    them together. The whole process is about piecing together many different
    smaller business processes to build the complete model. These things will
    build upon each other, so having a process incorrectly modeled may affect
    other connected down-stream processes.       

10. Document milestones. Once you have a particular process modeled and
     trained to exhaustion, formally document it then move on to the next 
     process. You will want to designate 1 person on the team as the "scribe".
     This will keep the process moving along without the fear of losing information. 

 I will get in more detail about this type of requirements gathering in future articles.

Was this article useful?

I also do on-site training and consulting for Data modeling/warehousing,
system and business requirements gathering, SSIS, SSAS, and SSRS

Come check us out at:
www.PragmaticWorks.com