How to gather business requirements

How to gather business requirements

Do you understand how to gather business requirements or the need to?

A Business Requirements Specification (BRS) or Business Requirements Document (BRD) is a key document that should form part of any project document suite.  It is actually one of the first documents that should be produced.  Possibly after the Business Case to get the project started, but certainly before any work actually starts on the project.

Why are BRS or BRDs so important?  Because if they are properly created they will be the basis on which all of the work in the project is undertaken.

Without it you can be assured that you will have

  • a project that delivers you a system that doesn’t do what the business/users want; or
  •  a project that only delivers part of what the users want; or
  • a project that doesn’t deliver any of what the business wants, and ends up being a complete was of time and money.

Now you understand why I say they are so important.

Understand current processes

Gathering business requirements is not a simple task.  One of the best ways to start is by understanding what the current processes look like (and yes you have heard me say this before), but if you start from the business process then you gain a clear understanding of the current situation in order to identify what needs to change and why, which in essence is forming your project.

If you gather the current state picture of your process, then you should easily be able to identify who your key stakeholders are, which systems are impacted by changes, what else is impacted, for example reporting.

You do this by talking to the people that currently undertake the work.  Those who are impacted day to day by a piece of the end to end process.  Ask ‘Who does this today?’, ‘Who is involved in the total process from end to end?’  This will help you find all of the right people that you need to speak to.

Don’t go into solution mode

Business requirements should be written from the perspective of what you want a process to do/perform.  They should not be written from a system solution perspective.  The system requirements are what is developed in a System Requirements Specification (SRS).

If you develop business requirements that talk about the system you are actually in solution mode.  This isn’t a good place to be because a lot of the time there are other ways to solve your process change problems, and so by defining them in your BRS/BRD you could be missing out on a much better way to perform your change.

Let the technical team determine what the system solution looks like.  In gathering your business requirements stick to the business process facts.

Be sure to look at the end to end process

If you work in a large organisation, it is very important when gathering your business requirements that you talk to each area of the business that uses a process to determine if they might currently be doing something differently, or have a special requirement that you don’t currently know about.

I can’t stress enough the importance of talking to more than one process user, or Subject Matter Expert (SME).  You limit the amount of knowledge of the current process if you only talk to one person and you are doing this at your own peril because it will inevitably lead to users not getting what they need from the system change.

Also be sure to validate your BRS/BRD with key people in the business.  They are the ones using the process.  They are the ones that will be able to tell you if you’ve missed something.

The time that you take to undertake these additional steps in your requirements gathering will come back to you ten fold in the project and ensure that the business actually gets what they wants and needs.


Written by Karen Munro

*Image courtesy of Stuart Miles at