(https://www.linkedin.com/showcase/ba-times/about/)
(https://twitter.com/batimes)
(https://www.facebook.com/BATimescom/)
(http://feeds.feedburner.com/BusinessAnalystTimes-BusinessAnalysisHome)
Contributing (/contributing-to-ba-times.html) | Join BA Times (/register.html) |
LOGIN (HTTPS://WWW.BATIMES.COM/LOGIN.HTML)
(htps/w
: wwb.am
ti esc.om)
(htp/w
: wwb.am
ti esc.om)
Lean Planning Board
Visual and easy
Make 5S, Autonomous Maintenance, Leader
standard work, and Continuous Improvement
work
wcm-apps.com
OPEN
Process Approach To Requirements Gathering
Written by Mani Ramasarma (/blog/mani-ramasarma.html)
 Read 158509 times
 May 4, 2015
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 (http://www.batimes.com/articles/requirements-elicitation-prerequisites.html) 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.
 Read 158509 times
Published in Articles (/articles.html)
Tagged under #Requirements (/tag/requirements.html) #Business Analysis (/tag/businessanalysis.html) #BPM (/tag/bpm.html) #Lean (/tag/lean.html)
Mani Ramasarma (/Blog/Mani-Ramasarma.Html)
Mani Ramasarma, is a Senior Business Architect at a leading Multilateral bank based in Washington DC. He has over 28 years experience
in varied sectors like Finance, Cement, Pharmaceuticals, Plastics and
IT. Mani adopts and evangelizes a practical, process based approach to
business analysis. He has trained and mentored many BAs.
@maniramasarma. https://www.linkedin.com/in/maniramasarma
(https://www.linkedin.com/in/maniramasarma)
Latest From Mani Ramasarma
The Requirements Process (/articles/the-requirements-process.html)
The B in BA (/articles/the-b-in-ba.html)
The A in BA (/articles/the-a-in-ba.html)
Business Analyst Skills - Overview (/articles/business-analyst-skills-overview.html)
Requirements Elicitation - Pre-requisites (/articles/requirements-elicitation-prerequisites.html)
Related Items
AI and the Digital BA—What’ It All About? Part 1 (/articles/ai-and-the-digital-ba-what-itall-about-part-1.html)
20 Lessons learnt over 20 years of doing Business Analysis (/articles/20-lessons-learntover-20-years-of-doing-business-analysis.html)
To-Do List/Ta-Da List (/articles/to-do-list-ta-da-list.html)
“The secret: One day builds always take longer than a day.” (/articles/the-secret-one-daybuilds-always-take-longer-than-a-day.html)
Five Trends in Business Analysis, Project Management, and Agile (/articles/five-trends-inbusiness-analysis-project-management-and-agile.html)
More in this category: « Data Flow Diagrams - Are They Worth It? (/articles/data-flowdiagrams-are-they-worth-it.html)
sport.html)
Agile is a Team Sport » (/articles/agile-is-a-team-
back to top (/articles/process-approach-to-requirements-gathering.html#startOfPageId2670)
Over 91,000 BAs
Over 1,500 Insightful Articles
Free PDUs - 200 Webinars
Free Templates and White papers
Weekly Round-up Newsletter
JOIN BA TIMES (/REGISTER.HTML)
AGILE (/AGILE/ARTICLES.HTML?CAT=AGILE)
CAREER (/CAREER/ARTICLES.HTML?CAT=CAREER)
BPM (/BPM/ARTICLES.HTML?CAT=BPM)
COMMUNICATE (/COMMUNICATION/ARTICLES.HTML?
CAT=COMMUNICATION)
LEADERS (/LEADERSHIP/ARTICLES.HTML?
REQUIREMENTS (/REQUIREMENTS/ARTICLES.HTML?
CAT=LEADERSHIP)
CAT=REQUIREMENT)
TECHNIQUE (/TECHNIQUES/ARTICLES.HTML?
CAT=TECHNIQUES)
BA JOBS (HTTP://JOBS.BATIMES.COM/)
(http://dbcc.advertserve.com/advertpro/servlet/click/zone?
zid=121&cid=433&mid=680&pid=0&sid=31&uuid=5f86f179b203f780a613f13016f2029c&ip=185.80
approach-to-requirementsgathering.html&redirect=https%3A%2F%2Faspetraining.com%2Fresources%2Ftoolsresources%2Fkanban-quick-startguide%3Futm_source%3DBATimes%26utm_medium%3Dhalf-page%26utm_content%3Dkanbanquick-start%26utm_campaign%3Ddigital)
(http://dbcc.advertserve.com/advertpro/servlet/click/zone?
zid=109&cid=346&mid=483&pid=0&sid=8&uuid=5f86f179b203f780a613f13016f2029c&ip=185.80.
approach-to-requirementsgathering.html&redirect=https%3A%2F%2Fwww.businessprocessincubator.com%2F)
Our Company
Macgregor Communications
About Us (/about-business-analyst-
(https://www.macgregorcommunications.com/) times.html)
Follow us on
Contact Us (/contact-us.html)
Advertise (/advertise-with-us.html)
 (https://twitter.com/batimes)

(https://www.facebook.com/BATimescom/) Project Times (http://www.projecttimes.com/)

Privacy Policy (/privacy-policy.html)
(https://www.linkedin.com/showcase/batimes/about/)
Terms of Use (/terms-of-use.html)

(http://feeds.feedburner.com/BusinessAnalystTimesBusinessAnalysisHome)
Connect
Content
Create an Account (/register.html)
Articles (/articles-business-analyst.html)
Login to My Webinars (/login.html )
Webinars (/business-analyst-
Contribute (/contributing-to-ba-times.html)
Authors (/authors.html)
Advertise (/advertise-with-us.html)
LinkedIn
(https://www.linkedin.com/groups/BusinessAnalyst-Times-2824059)
training/training-home.html)
Whitepapers (/business-analyst-whitepapers/)
Templates (/templates/business-analysttemplates.html)
Books (/books/book-directory.html)
Conferences (/business-analyst-events.html)
Sitemap (/resources/sitemap.html)
© BA Times.com 2019
(/articles-business-analyst.html)
(https://www.macgregorcommunications.com/)