This is the most comprehensive list of requirements gathering techniques in Google today.
Having these techniques in your Business Analyst weaponry will give you unlimited ammo for succeeding in ANY project.
The great thing is.
They’re practical.
Meaning each and every one can be implemented immediately.
And once you’ve read this.
I guarantee – you will be dying to get back to your requirements.
My EXACT Requirements Tools & Techniques List
I’ve been growing this list for a while.
Even though some of them I'd never thought of before reading about them or just doing them without thinking.
And I’ll be honest:
I have more experience of some than I do others.
But today I’m giving you my EXACT list of requirements gathering techniques.
Some are proven.
Some are controversial.
Others are a bit geeky.
But together they will give you a different angle of attack for any requirements gathering process on any project.
But that's not all.
I’m also telling you WHEN they work.
As well as WHY they work.
PLUS I’ll give a top tip for implementing each one.
So give yourself some time.
And read through the whole list.
Some of these techniques assume that the system is already in place and you’re making changes to it.
Other’s are great if there’s no system currently in place.
Others are just great.
I’ll ask now:
"Please leave a comment at the end of the post if it gives you some ideas about your projects."
Gathering Requirements: More than just your standard
So I’m sure you’ve heard about the standard requirements gathering techniques -
Interviews.
Workshops.
Reading Documents.
And the few others that the Requirements Engineering certificate teaches you.
Well I’m taking this post 10 steps further than that.
You get ALL the detailed individual techniques to pick your favourite whenever you need it.
But first…
Is It Requirements Engineering? Requirements Gathering? Requirements What?
If you’ve been in the requirements game a while.
You WILL know this.
But if not.
Let me explain…
There’s a lot of talk in the Business Analysis Domain about whether we say…
Gathering Requirements.
Engineering Requirements.
Eliciting Requirements.
Why do we ask this?
Because the view is that requirements aren’t just THERE to gather.
They don’t exist.
Users don’t really know what they want.
So we as Business Analysts MUST identify them from effectively nothing.
And that’s Why.
Mike Cohn provides a brilliant explanation in his book:
User Stories Applied – For Agile Software Development
http://www.amazon.co.uk/User-Stories-Applied-Development-Addison-Wesley
Anyway that’s enough of the controversy.
Lets dive in.
I’ve broken the list into various sections:
1. Techniques working with others (1-13) - Go straight there
2. Observation techniques (14-18) - Go straight there
3. At your desk techniques (19-27) - Go straight there
4. Bonus techniques (28-38) - Go straight there
Gathering Requirements with Others
The most essential thing when meeting with others is this.
Always prepare.
Always have an abjective.
Always book early.
Tool 1. Q&A Requirements Interviews
When? Right throughout the Project – when ONE person has the knowledge.
Also known as Interviews This has got to be the most popular technique used by Business Analysts.
And yes – they are very important.
Face to face Question and Answer sessions will enable you to get into the minds of the users.
But if there’s a lot of people who need to input then they can be too time consuming.
So don’t let it be your only way of engineering those underlying requirements.
Tip: Book early and don’t limit your sessions to just users.
Tool 2. User Story Requirements Workshops
When? When you need input from lots of people in a short space of time.
User Stories is an Agile methodology concept and aims to get EVERYONE involved in a workshop, from developers to testers to users.
Stories should be in the form of…
As a [USER]
I Want [A FEATURE]
Because [REASON]
It immediately gives you an owner and a reason for the requirements.
Tip: Having given attendees time to write their stories. Leave enough time to discuss everyone’s thoughts.
Tool 3. Brainstorming Requirements
When? When decisions need to be made and everyone has different views.
Brainstorming with stakeholders is a great way of capturing unstructured discussions.
It’s also a great way of structuring discussions about certain subjects.
You can use post-it notes or a white board but there are a number of ways brainstorming can be done.
For example:
One person can speak at one time (i.e. when they hold the pen).
Or Round Robins between everyone in the room until people run out of things to say.
Tip: Have a few different subjects you need to discuss and try to stick to them throughout the workshop.
Tool 4. Requirements Focus Groups
When? When your project is being delivered to Customers who have specific views.
This isn’t just for branding Marketers.
Focus Groups are a great way of getting the views of similar people.
Especially when you don’t know much about your target users or customers.
Tip: Great for when you are delivering BRAND NEW functionality to a system.
Tool 5. Visiting Customers
When? When your system is being developed for external customers.
Getting into the mind of your external customers is the most important thing for ANY business.
If you can engineer your requirements in-line with the end customers views.
It will always be a winner.
What’s more:
The modern BA shouldn’t just stay in the office anymore.
So get out there and see the customers
Tip: make sure you push for this with the decision makers i.e. Technical Director / CEO.
Tool 6. Voice of the Employee (VOE) Workshop
When? When you need to know about current systems or processes and you know employees have that knowledge.
Voice of the Employee or VOE is derived from Six Sigma.
So is used for process improvement.
But it is also great for gathering ideas about change.
So what’s the best way to do this?
Invite to a wrokshop, everyone who has some knowledge about the areas your project will impact.
Cut out 100 cards of four different colours - as below – Red, Green, Blue, Yellow.
Ask attendees this..
What’s bad about the process? – Red (have lots of these)
What’s good about the process? – Green
What ideas do you have about change? - Blue
What should never change? - Yellow
Tell them to write one comment on each card.
Then discuss everyone’s comments.
Tip: Don’t run out of paper/cards.
Tool 7. Voice of the Customer Workshop
When? When there are several handover for a system’s surrounding processes.
These are similar to focus groups.
But can be structured in the same way as a Voice of the Employee.
But the questions are different.
For example:
Good things about the service.
Bad things about service.
Ideas how to improve the service.
Things that shouldn’t change.
But first.
Make sure you identify the service being received by the customers.
So you can ask the right questions.
Tip: Don’t over promise – remember the Ideas are ‘Blue Sky Thinking’ and may never get implemented.
Tool 8. Requirements Gathering Phone Calls
When? When you need to talk to someone who is based far away.
This may seem very simple.
But I had a 30-minute phone call the other day and was able to engineer numerous requirements.
Bear in mind.
This was someone who I’d not met but they did work for my company.
Tip: These people are out there – we (Business Analysts) just need to find them.
Tool 9. Risk Review with Developers
When? When you need to prioritise your (upcoming) backlog.
Embarking on a new project can be unforeseeable.
But it’s better to attack the more risky requirements early on.
So if you have engineered a high level knowledge - sometimes called Epics - of what the requirements are.
And you know who will be developing the system.
Hold a risk review meeting with the developers.
And you could engineer even more requirements.
Rank the epics in terms of risk.
Then prioritise the epics based on the risk level.
Some low risk requirements will be dependent on high risk requirements so your order may not be in exact High-to-Low.
Tip: Keep an eye out for further requirements during the session.
Tool 10. As-Is Process Mapping Workshops
When? Early on in a project when you don’t know the surrounding process of a system.
Understanding the surrounding process WILL help you determine what the system needs to do.
Or even what it is already doing well.
So get a couple of subject matter experts (SME’s) and go through the step-by-step process.
From start to finish.
Tip: Decide on the process you want to cover and give yourself enough time based on your current knowledge.
Tool 11. To-Be Process Engineering Workshops
When? When you know the as-is process that surrounds the system and you have recommendation for change OR know there needs to be a change.
So we know it’s important to conduct As-Is process mapping workshops.
But doesn’t mean the status quo needs to stay like that.
So.
To-Be process mapping workshops CAN help you determine what the system requires in order to fulfil the needs of the process.
Tip: Think outside the box and take into account the TIMWOOD 7 Wastes framework.
Tool 12. PEST Requirements Gathering
When? When you start working in a new domain/organisation or once a year if you’re with the same company a while.
Isn’t this another marketing activity?
No – it’s a business strategy technique.
And it can help you determine what’s happening on the outside world.
In requirements terms – it can help you determine the future.
So you avoid having out of date requirements for a system that will take over 12 months to develop and deploy.
Tip: The outside world changes hard and fast - DO make sure you conduct a PEST frequently.
Tool 13. Daily Requirements Meetings
When? Every Day!
If you know about SCRUM.
You know this is something that happens anyway between us the developers, testers and SCRUM Master.
BUT – have you looked for any other daily meetings you can attend or even create yourself.
Daily meetings are becoming more and more popular among teams right across organisations.
There’s nothing wrong with suggesting to join them for a few weeks so you can hear of the teams day-to-day tasks.
Of course – this is much more effective if your system is being developed for internal users.
Tip: Don’t be afraid of making the suggestion.
Observation Techniques
Tool 14. Observing Users
When? When you know the current user will be adopting the system of interest.
By observing users.
You get knowledge you’d never get from just asking questions.
And you get first-hand knowledge of the working system doing it’s processes.
You could give the user a bit of advice while they’re there.
Or you might spot some quick wins.
Tip: Conduct the observation when the user is carrying out the task you are interested in.
Tool 15. Listening to Support Calls
When? When you have a support or service centre dealing with customer queries.
This is a new found exploration for me in my requirements gathering.
But it works great.
So I booked in once a week to spend 1.5 hours shadowing support calls.
It helps understand your customers (users) in times of need.
Bear in mind – you will mostly hear negative things about the system.
After all, that is the general reason for support.
James Lawther discusses on Business Analyst Learning blog what we BA’s can learn from call centres not just in regards to requirements.
http://businessanalystlearnings.com/what-business-analysts-can-learn-from-call-centers
Tip: Listen in during the busy times - usually morning - when the system is being loaded. Also - tell the service desk analyst you're not testing their work.
Tool 16. Observing Developers
When? For techie projects that require you to work closely with the development team – maybe better for technical projects.
This may be controversial.
Why?
Because there’s an argument that the BA should be Business Minded and not very technical.
But don’t forget they are bridging the gap between technical and organisation.
AND the developers will need to use our requirements.
So effectively dev team are a customer of the requirements.
And therefore – we need to know what their constraints are.
So learn a bit of technical stuff and get yourself a day-in-the-life-of a developer (or even just an hour).
Tip: Choose a developer who is happy to explain things clearly – if you know what I mean.
Tool 17. Observing Testers
When? Usually while working in iterations and some of the early features have been delivered.
Definitely better for Agile ways of working.
But could be used in Waterfall if you’re clever about it.
By observing the testers, you can see the new features in action before the next set of requirements have even been delivered.
So although testing can only be completed after development.
It CAN be used to engineer further requirements.
Not only that…
It will be a brilliant learning curve for you as a (Requirements) Business Analyst.
Tip: Take this opportunity to look out for development that doesn’t meet requirements.
Tool 18. Observe Problem Reports
When? When you have a service team dealing with regular problems.
This could also be in the form of change suggestions.
Does you organisation have a structured way of recording problems?
If so, find out who owns that list.
Ask them for it.
And review it to see if you can build any of the problems into your requirements engieering process.
Tip: Ask them if they have a summary before trying to delve into the complete raw data.
Gathering Requirements at your Desk
Tool 19. Reading Documents
When? All the Time!
Boring, boring, boring.
That’s what you might think about analysing documents.
But you’ve probably read enough documents to last you a lifetime.
There’s LOADS to learn from this technique and documents are ALWAYS available.
Has it not been written by a direct project stakeholder?
Doesn’t matter!
If it’s relevant, it’s readable.
So how do you know if the doc is relevant?
Look at the SCOPE section - ussually in the first few pages.
I like to show the navigation pane on the side (see below) so I can get a good overview of the document before delving in too much.
And remember.
Some of the docs may be old so always take that into account.
Tip: Don’t wait for the docs to come to you – If you have access to the document storage – SEARCH IT!
Tool 20. System Interface Analysis
When? When you have access to the system that your users are already using.
Getting down and dirty with the system is a fantastic way to see all the functionality in good working order.
How do I know?
Because I do it – every day.
And I have access to every version release from the past few years so I can see how the system has been developed over time.
From before I even knew the company existed.
Giving me unlimited ideas about what requirements could be introduced next.
Tip: This is great for when you start working with new systems.
Tool 21. Reading API Documents
When? When the architects have an idea that they want to turn into reality and they’ve documented it.
What's API? Read on to find out.
Quite often – architects have already decided how their amazing new systems will integrate.
Quite often – They’ve done it without too much input from the users.
Quite often – They’ve documented an Application Programming Interface document.
This document will describe how the interfaces will work together to deliver the much needed functionality to the users.
Just because the architect has written it, doesn’t mean it can’t be challenged.
So take some time to read it.
Understand it.
AND even more importantly QUESTION it!
Tip: Don’t forget your key task - use it to elicit business requirements – you’re not an architect.
Tool 22. Requirements from Reading User Manuals
When? When guides are available for the system that’s already built.
This is difficult if you don’t have the system to use alongside the manual.
But if you’ve seen the system at work.
Then there is probably a user guide somewhere to go with it.
It’s probably never been read by the user.
This will help you understand if a requirement is ACTUALLY needed or if it already exists in the system.
And the user just doesn’t know about it.
Tip: Think about what great features you could add to the user manual itself.
Tool 23. Review Product Management’s Vision/Strategy
When? When you need to brush up your knowledge on the comapny road map.
Our requirements MUST be in line with the Product Manager's Vision.
So they are just one of the many customers of BA’s.
My product managers use a system called AHA.io.
I requested access so I could see how the 'ideas' were being updated.
It’s got me into the minds of the product managers to help fulfil their vision.
So just ask.
Tip: Setup weekly meetings with the product manager who is responsible for the system you’re working with.
Tool 24. Data Analysis
When? Whenever data is available and an important decision needs to be made based on volumes or values.
I’m a firm believer that you can only make truly remarkable decisions when you use data.
If a decision is NOT based on data then it is made by speculation or assumption.
Opening up HUGE risk for incorrect requirements or even rework at a later date.
Tip: Build a strong relationship with the person who is most likely get you the data you need – usually the database administrator.
Tool 25. Read Government Compliance Documentation
When? When working in a highly regulated industry.
Working in pharmaceuticals is a great example.
Nearly every system change needs to be approved by the government body.
And they write requirements based on the approval process.
So every requirement MUST be in line with the government documents.
So read it, read it again and make sure nothing is missed.
Tip: Don’t get pulled in by the legal requirements being the only ones – come up with your own too.
Tool 26. Use the System / Do the process
When? When you have the system available or can work alongside the user.
Easily one of the best ways to get into the ‘minds’ of the user.
Simple!
If ever you get a chance to use a system that you’re writing requirements for.
Take it.
Or even better - get out there and ask if you can use it.
Take it even further.
If you’re attempting to automate a manual process then – do the process.
Tip: Always put yourself in the mindset of the user when you’re using the system or doing the process.
Tool 27. Document Scenarios
When? When there’s a technical project which needs business scenarios.
You could argue this is in the wrong section.
Why?
Because you don’t really want to just stay at your desk when documenting business scenarios.
But to be honest BA's NEVER just should just stay at their desk.
This technique will hugely benefit your business knowledge.
And enable you to write user stories.
Here’s an example:
A customer is created in Store A.
And service #1 is delivered.
The same patient is created in store B.
Store B searches for the patient on the System.
Store B finds that patient and delivers Service #2.
Only one demographic record exists for the customer.
Service #1 and service #2 exist for that customer.
Tip: Think outside the box when documenting scenarios BUT start simple.
Bonus Requirements Gathering Tools
Tool 28. Questionnaires
When? When there are lots of people scattered about from whom you want input.
Questionnaires are great for collecting very basic responses from lots of people.
The answers will help you focus your efforts on a particular piece of functionality that may be causing everyone pain.
OR it can help you determine the most popular idea for improving the process or system.
So choose your candidates carefully.
By that I mean think about a variation of users.
For example:
Some experienced users.
Some inexperience (new) users.
Some low frequent users.
Some high frequent users.
You get the picture?
Then come up with your own questions - and send it out - do it today.
Tip: Many people tend to go for most experienced people – don’t do it. Mix up your user base.
Tool 29. Surveys
When? When you are able to study the process with a clipboard.
Aren’t surveys just the same as questionnaires?
To which, I’d say this:
A questionnaire is something your recipients complete.
A survey is where you s’vey what is going on and write it down.
Perhaps you want to look out for a particular pattern in the process.
Or a particular event during the process.
Tally charts are a great way for capturing this info.
You could say.
A survey is kind of a cross between a questionnaire and an observation.
Tip: Choose your timing wisely - you don’t want to survey a process where nothing is happening.
Tool 30. Review Competitors Systems
When? When you know you can get access (psst. do they have a free version?)
This may sound a little unethical.
But trust me.
Everyone does it.
Do you work for a company delivering commercial software?
If so, ask yourself this:
Are your competitors doing something you’re not?
If the answer is ‘Not Sure’ – then find out.
If the answer is ‘Yes’ – then check it out
Tip: This may take some thought… but keep trying and the opportunity WILL arise.
Tool 31. Prototyping
When? When there’s a high risk of the project failing or the success criteria is too vague.
Prototyping can cost A LOT of money.
And it can be time consuming.
But the rewards of prototyping means that when the project is rolled out you can
re-engineer the requirements that didn’t meet the needs of the user.
A decision to prototype would usually be made by the directors.
But that doesn’t mean we Business Analysts can’t make suggestions based on our knowledge.
Tip: if you think there’s an opportunity for prototyping – then go for it.
Tool 32. Change Desk Location
When? Throughout the course of the project, while the project is in full flight.
I can’t give you the exact figures.
But I can tell you that you are A LOT more likely to ask someone a question if you are sat next to them
Because you don’t need to put any extra effort in if you can just talk to someone whenever you need to
So moving desks to sit with the people you want to extract info from WILL be beneficial to your requirements project.
Tip: Try and sit with someone who has a lot of experience with the system you’re working with.
Tool 33. Spend time in the target environment (day-in-the-life-of)
When? When you want to learn the work of another team.
This technique will give you more than doing a quick observation.
However. It is time consuming to do lots of them.
But it’s another technique, which WILL get that tacit knowledge from your user’s minds.
Make it last at least one day
Tip: Target an environment where the project will have the most impact. For example, a particular team.
Tool 34. Watch the News
When? Every Day.
I know. This is a bit random,
But you never know what you might hear about your industry.
Even if you merely get an inclination to do further research.
Big changes in industry are often reported in the news.
So it makes sense to follow it.
Tip: Make this a habit.
Tool 35. Search Google
When? Whenever you’ve got internet connection.
We all know anything can be found in Google.
So why can’t we engineer our requirements from Google?
We probably can.
Or if we can’t – we can certainly get some ideas.
So type anything relevant into Google and see what comes up.
Tip: To make your search more targeted type this into the search “intitle:” and then your search criteria – like below.
Tool 36. Read Books
When? Try to read for at least 30 minutes a day.
Whether it’s a book about Business Analysis.
Or a book about your company’s industry
Continuous improvement is what BA’s are all about.
So what better way to improve yourself than continuous learning with a book.
So pick up a book and build on your knowledge. Today.
It WILL get your mind ticking around requirements for your projects
Tip: Look out for recommended reading lists on websites.
Tool 37. Use (or Transpose) your Requirements Experience
When? When you’ve got experience of other projects in other industries
When you’re looking at job specs.
You might read something like this:
“Experience in the __________ industry is mandatory.”
I actually believe it is better to have experience of a number of different industries.
Because you can use experience from one industry to improve another.
And that's what I mean by transpose
So don’t be afraid to transpose your knowledge from one industry to another.
Tip: Look back at your requirements from other projects and see if you can add any in to your current project – particularly non-functional requirements.
Tool 38. Proof of Concept
When? When you need to test the requirements to prove they are valid
Similar to a prototype, a proof of concept (POC) can be time consuming.
And costly
But they do have the benefits in that you can make sure the requirements you’ve discovered are valid and deliverable
So if there’s an opportunity to develop a simple version of the full system requirements
Then you may want to develop a POC first.
Tip: Make sure the POC is a simplified version of the overall requirement
So that's my list
If you enjoyed getting some ideas about your requirements elicitation techniques.
Or even have any techniques you think I've missed.
Leave a comment.Or Tweet.
Or Share.
Either way - have fun with with your projects.
Make sure you download the Business Requirements Template (below) that I put together especially for this post.
Matt, once again, you have produced (and more importantly, made available) a wonderful and invaluable resource! Clearly, a goldmine for BA’s but also a great resource for many provider roles, including Business Relationship Management.
Well done, and thank you!
Thanks Vaughan, great to hear you think this post is also useful.
Thanks Matt for sharing! As Vaughan says valuable piece for BAs as well as for many provider roles including BRMs.
No problem Seema. Glad you like it. Thanks, Matt
Great resource!
– new IT Business Analyst