OUR BUSINESS ANALYSIS PROCESS
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. A focused and detailed business requirements analysis can help you avoid this problem.
Business Analysis 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.
Our Business Analysis process is based on the Business Analysis Body of Knowledge (BABoK) guide. It is published by the International Institute of Business Analysis (IIBA). A Guide to the Business Analysis Body of Knowledge® (BABOK® Guide) is a globally recognized standard for the practice of business analysis. The BABOK® Guide describes business analysis areas of knowledge, their associated activities and tasks, and the skills necessary to be effective in their execution.
5 Steps to Business Requirements Analysis
The following describes the basic steps CSDi's business analysts use to conduct a 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.
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?
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.
- 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.
- 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 on.
