38 Detailed Requirements Gathering Tools, Techniques & Template – What? How? Why?

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.

Or Tweet.

Or Share.

Either way - have fun with with your projects.