Business Requirements Analysis

Clearly Agreeing What You're Going to Deliver

Every new activity, every new product, every new project in the workplace is created in response to a business need. Yet we often find ourselves in situations where, despite spending tremendous time and resources, there's a mismatch between what has been designed and what is actually needed.

Has a client ever complained that what you delivered isn't what she ordered? Has someone changed his mind altogether about the deliverable, when you were halfway through a project? Have you had conflicting requirements from multiple clients? And have you ever received new requirements just after you thought you'd finished creating a product?

A focused and detailed business requirements analysis can help you avoid problems like these. This is the process of discovering, analyzing, defining, and documenting the requirements that are related to a specific business objective. And it's the process by which you clearly and precisely define the scope of the project, so that you can assess the timescales and resources needed to complete it.

Remember: to get what you want, you need to accurately define it – and a good business requirements analysis helps you achieve this objective. It leads you to better understand the business needs, and helps you break them down into detailed, specific requirements that everyone agrees on. What's more, it's usually much quicker and cheaper to fix a problem or misunderstanding at the analysis stage than it is when the "finished product" is delivered.

Tip:

Many organizations already have established procedures and methodologies for conducting business requirements analyses, which may have been optimized specifically for that organization or industry. If these exist, use them! However, do make sure you also consider the points below.

How to Use the Tool

Below is a five-step guide to conducting your own business requirements analysis.

Step 1: Identify Key Stakeholders

Identify the key people who will be affected by the project. Start by clarifying exactly who the project's sponsor is. This may be an internal or external client. Either way, it is essential that you know who has the final say on what will be included in the project's scope, and what won't.

Then, identify who will use the solution, product, or service. These are your end-users. Your project is intended to meet their needs, so you must consider their inputs.

Tip:

Make sure that your list is complete: remember, end-users for a product or service might all be in one division or department, or they might be spread across various departments or levels of your organization. Our article on Stakeholder Analysis will help you identify stakeholders.

Step 2: Capture Stakeholder Requirements

Ask each of these key stakeholders, or groups of stakeholders, for their requirements from the new product or service. What do they want and expect from this project?

Tip 1:

Remember, each person considers the project from his or her individual perspective. You must understand these different perspectives and gather the different requirements to build a complete picture of what the project should achieve.

Tip 2:

When interviewing stakeholders, be clear about what the basic scope of the project is, and keep your discussions within this. Otherwise, end-users may be tempted to describe all sorts of functionality that your project was never designed to provide. If users have articulated these desires in detail, they may be disappointed when they are not included in the final specification.

You can use several methods to understand and capture these requirements. Here, we give you four techniques:

Technique 1: Using stakeholder interviews

Talk with each stakeholder or end-user individually. This allows you to understand each person's specific views and needs.

Technique 2: Using joint interviews or focus groups

Conduct group workshops. This helps you understand how information flows between different divisions or departments, and ensure that hand-overs will be managed smoothly.

Tip:

When using these two methods, it's a good idea to keep asking "Why?" for each requirement. This may help you eliminate unwanted or unnecessary requirements, so you can develop a list of the most critical issues.

Technique 3: Using "use cases"

This scenario-based technique lets you walk through the whole system or process, step by step, as a user. It helps you understand how the system or service would work. This is a very good technique for gathering functional requirements, but you may need multiple "use cases" to understand the functionality of the whole system.

Tip:

You might want to find existing use cases for similar types of systems or services. You can use these as a starting point for developing your own use case.

Technique 4: Building Prototypes

Build a mock-up or model of the system or product to give users an idea of what the final product will look like. Using this, users can address feasibility issues, and they can help identify any inconsistencies and problems.

You can use one or more of the above techniques to gather all of the requirements. For example, when you have a complete list of requirements after your interviews, you can then build a prototype of the system or product.

Step 3: Categorize Requirements

To make analysis easier, consider grouping the requirements into these four categories:

Functional Requirements – These define how a product/service/solution should function from the end-user's perspective. They describe the features and functions with which the end-user will interact directly.

Operational Requirements – These define operations that must be carried out in the background to keep the product or process functioning over a period of time.

Technical Requirements – These define the technical issues that must be considered to successfully implement the process or create the product.

Transitional Requirements – These are the steps needed to implement the new product or process smoothly.

Step 4: Interpret and Record Requirements

Once you have gathered and categorized all of the requirements, determine which requirements are achievable, and how the system or product can deliver them.

To interpret the requirements, do the following:

Define requirements precisely – Ensure that the requirements are:

Not ambiguous or vague.

Clearly worded.

Sufficiently detailed so that everything is known. (Project over-runs and problems usually come from unknowns that were not identified, or sufficiently well-analyzed.)

Related to the business needs.

Listed in sufficient detail to create a working system or product design.

Prioritize requirements – Although many requirements are important, some are more important than others, and budgets are usually limited. Therefore, identify which requirements are the most critical, and which are "nice-to-haves".

Analyze the impact of change – carry out an Impact Analysis to make sure that you understand fully the consequences your project will have for existing processes, products and people.

Resolve conflicting issues – Sit down with the key stakeholders and resolve any conflicting requirements issues. You may find Scenario Analysis helpful in doing this, as it will allow all those involved to explore how the proposed project would work in different possible "futures".

Analyze feasibility – Determine how reliable and easy-to-use the new product or system will be. A detailed analysis can help identify any major problems.

Once everything is analyzed, present your key results and a detailed report of the business needs. This should be a written document.

Circulate this document among the key stakeholders, end-users, and development teams, with a realistic deadline for feedback. This can help resolve any remaining stakeholder conflicts, and can form part of a "contract" or agreement between you and the stakeholders.

Step 5: Sign Off

Finally, make sure you get the signed agreement of key stakeholders, or representatives of key stakeholder groups, saying that the requirements as presented precisely reflect their needs. This formal commitment will play an important part in ensuring that the project does not suffer from scope creep later one.

Key Points

The key to a successful business requirements analysis is identifying what the new system or product will do for all appropriate end-users/stakeholders – and to understand what they WANT the new system or product to do.

You can use various techniques to gather requirements, but make sure those requirements are clear, concise, and related to the business. This process also helps you identify and resolve any conflicting requirements issues early on.

Once you complete your analysis, record it in a written document. This becomes the "contract" for creating the product or system that addresses all the needs of your business or your client.

This site teaches you the skills you need for a happy and successful career; and this is just one of many tools and resources that you'll find here at Mind Tools. Subscribe to our free newsletter, or join the Mind Tools Club and really supercharge your career!

Join the Mind Tools Club

Comments (12)

Midgie wroteOver a month ago

Thanks for sharing the link to a very comprehensive Business Requirements Document. Although I would suggest that users review all the sections and check whether they are needed. Yet, it is often easier to start with a bigger more comprehensive template and remove sections, than a smaller template and having to add extra things into it.

What experiences have you had with templates such as this BRD and how did it go?

Midgie

wroteOver a month ago

The BABOK (Business Analysis Body of Knowledge) is a guide for Business Analysts that describes industry best practices for this area. There is a similar document PMBOK for the Project Management area. Templates for the BRD can be found on several university websites,as well as commercial organisations, however some these require a subscription to access them. www.nobleinc.ca/word/BRD_Template_UML-NobleInc.doc is a comprehensive example.

leemol wroteOver a month ago

Great tool - it would be useful to have a Mindtools template

paul_murray wroteOver a month ago

Hi Dianna,

I feel much more on board with getting in front of end users and stakeholders now. Even though I have gathered feedback indirectly through various other non-related meetings, I think, taking the time to focus on discussing requirements specifically for this project, could very well unlock some great ideas.

Thanks for your insights, going to have a coffee now and have a read of your article.

Paul

Dianna wroteOver a month ago

Hi Paul,
I think situations like this come down to a cost vs. benefit analysis. What benefits will you reap by conducting the survey? As Midgie says, will the additional feedback help you structure your project and ensure stakeholder buy in?

On the surface of it I think you will probably derive a lot of benefit from talking with the stakeholders. Any type of change initiative will meet with some degree of resistance - it's human nature. When you involve people in the change from the very early stages you are able to breakdown many of these resistances before they even rear their ugly heads. And you never know where the next great idea might come from. It's possible that one of the people you survey has an innovative idea, or something you can build on, that you wouldn't have thought of on your own.

And remember too that there are many ways to get feedback from people. You can develop a simple online survey or conduct small group sessions. decide which method is the most efficient and which will make sure you are on the benefit side of the cost/benefit equation.

One of my favorite articles on change is the one one why change can fail. It comes at the issue from the back end and has lots of great tips. Here is the link if you are interested in reading it: http://www.mindtools.com/community/pages/article/newPPM_81.php

Dianna

Midgie wroteOver a month ago

Hi Paul,
What a great question to ask ... should any of us still spend time doing the research / interviews to come up with the answers that we already know?

My personal view is definitely yes! By doing the interviews and finding out what the stakeholders want and need, and what they identify as missing, you will then have the 'evidence' to back up what you are doing.

Otherwise, you might proceed only to find out later that big chunks were missing. The benefit of doing the interviews is that you might reveal aspects that you didn't expect. These could ultimately add more benefit to the overall project.

Let's see what others' views are. Hope that helps.
Midgie

paul_murray wroteOver a month ago

Hi All,

The article on business requirements analysis is great. I do have a question, and maybe it is not meant for this discussion thread, so correct me if I am wrong (I just joined).

I am currently initiating a project to improve and re-design our company Intranet. At the moment, there is a lot of functionality missing, so I know what a lot of the work is and what needs to be done, however, should I spend the time to still survey/interview my stakeholders, even if I feel confident the answers I get back will fit with what I know?

Kind regards,
Paul

Midgie wroteOver a month ago

Hi Ben and Lunitaire,
I agree that a template would add value to this article.

I've passed the request to our editorial team to look at and hopefully they will be able to do something soon.

Midgie

lunitarie wroteOver a month ago

I completely agree with Ben- this is a very well written and informative topic.

A template would definately add value to an already great article!

ChaiLatte wroteOver a month ago

Can you create a PDF file for this Business Requirements Analysis topic? I find this write-up extremely useful and it should compliment the What is Project Management workbook, as an appendix.