This blog was supposed to be on requirements elicitation techniques, but it ended up being an example of what peer review does. I finished my blog and handed it over to my colleague for feedback. He pointed out that I assumed people knew how to gather requirements for them to start using the techniques mentioned in the blog. In other words, the blog on techniques was a step ahead, and I should first explain the approach. Ouch! The bump on my head still hurts. So, here we go.
I interview many candidates. Whenever I ask “How do you approach requirements session?” the answers invariably include something akin to “I use JAD session” or “I shadow users”. JAD (Joint Application Design), shadowing, interviewing, and brainstorming are techniques used AFTER you have an approach. Think of it this way. You decide to go on a vacation. How do you approach it? You don’t start with “I will drive” or “I will fly”. These are ways (techniques) by which you reach the destination. The first thing you need to do is decide where to go, when to go, and how to go (approach). The series of steps you take (approach) has to precede the decision to drive or fly (technique). There is a very fine difference.
So, how do we plan an approach to a requirements gathering session? Do we call for a meeting and ask the business user “ok, so what do you want?” or “I am ready, go ahead and list your requirements?” Don’t be surprised if you get a very lengthy grocery list! To avoid such mishaps here is a process-based approach to requirements gathering.
The first point in my last blog was “Do your homework”. The first step as part of homework is to understand the organization and the unit. This understanding provides the big picture so that the goals of the requirements that are to be gathered align with the goals of the organization and unit. Next is to understand the business under consideration, and the scope of the system being worked upon. There are many avenues to it. One of them is to get hold of an AS-IS process diagram.
Start from a high-level process. Some call it “Level 0” or “L0.” Drill down from here to the lowest level possible – L1, L2, L3 and so on (do not confuse this with support levels). Normally you would achieve this by L3 or L4. If AS-IS diagrams don’t exist, your task is to create them.
A mature organization typically has all the “as is” processes documented. Go over it. Go over any other document related to the system that may be available – business bequirements focuments (BRD), functional specifications documents (FSD), user manuals, data flow diagrams (DFD), entity relationship diagrams (ERD), and DDD (sorry, I just created that one!). Get access to the test system and play around in the sandbox – see what it does, see what it doesn’t do. Talk to the technical people. Sometimes they know more about the business than the business users themselves. Ask for a walk-through by technical and/or business folks. If you have a knowledgeable lead, talk to them. By now you should have a good understanding of the way business is conducted. As you assimilate information, note things that don’t seem right. Always remember your title – Business Analyst – so make sure that you are always trying to analyze as you proceed.
Armed with enough knowledge, proceed to capture the “to be” process. Remember, you are documenting only the “to be” process and not the requirements. A common pitfall is to embed requirements in process documents. Be sure to avoid it.
Make a copy of the “as is” process and mark bottlenecks, pain points, workaround’s, manual processes, and non-value add processes. See if you can measure lead and lag times between points in the process. All the current weaknesses should be resolved in the “to be” process in addition to any new functionality or change in the process itself. Beware not to resolve a process inefficiency by automating it. You will be automating inefficiency.
Again start from Level 0 or L0. Make necessary changes. Each of the tasks define your high-level requirements. Here is an example of a L0 procurement process in a bureaucratic organization
Use the gathered requirements to prepare your high-level BRD.
Each of the boxes can further be broken down into next level processes. For example, the first task can be decomposed into
Again, each of the tasks can further be elaborated (here is a buzzword for the interviews – Functional Decomposition). Here is what it may look like, assuming that we go all the way to the lowest level possible (do not magnify the picture. It is there for illustrative purpose only):
At each level look for opportunities to eliminate both the deficiencies (what is missing) and the inefficiencies (what isn’t needed) in the current process. Keep this maxim in mind while redesigning processes – the shortest distance between two points is a straight line. A straight line is not always practical or feasible, but use it as a guideline to streamline the processes. Even if you manage to eliminate or refine one or two steps, it can result in significant time and cost savings.
The hazy little light blue rectangles in the diagram above specify the system that performs that particular task. The diagram also includes manual tasks, reports, and emails. Check if you can automate manual tasks, and whether consecutive manual tasks can be replaced by a workflow. Again, do not automate inefficient processes. Deal with reports separately. Once the “to be” process is documented, have it validated by the business users. Validation is mandatory. It is so mandatory that I will say it again – it is mandatory to have these “to be” processes validated and approved by the business users. What you are left with is a bunch of tasks at the lowest functional level. It is for these that you need to gather functional requirements.
There is one more step you need to do before diving into the requirements gathering process – organize a requirements elicitation kick-off session. Invite business users and the technical team members. Highlight the importance of requirements, characteristics of a good requirement, what has been achieved so far, next steps, and the need for continued user participation and cooperation. The most important component is listing and explaining a good requirement. What are the characteristics? Here is a website that explains it really well. (The next blog will address this and requirements gathering techniques). There are some good examples on the website of how not to write a requirement, which is equal in importance to how it shall be written (a touch of BA humor there!).
The following diagram summarizes the approach
We are ready to launch into the requirements gathering process. That bump on my head is now better.
Don’t forget to leave your comments below.