Business Requirements Analysis
Tuesday, November 26, 2013
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.
Tags:
Project Management, Skills
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.
