Requirements Breakdown Structure
Requirements Breakdown Structure
In the process of starting a project, you might need to spend some time defining what the project really is about and what stakeholder’s needs it is going to address, that is, gather the project requirements. To collate these requirements, a requirements breakdown structure (RBS in project management) is of major help.
RBS Definition
While this work is typically carried out by a Business Analysis team, not all projects have the luxury of those dedicated competencies, and the project manager is brought in to solve the day and be a jack of all trades. Thus, it is therefore useful for project managers to know what a requirement is and how these can be structured logically. Mainly when it is known that most projects fail due to low requirements identification!
A requirements breakdown structure (RBS – not to be confused with risk or resource breakdown structure!) is of major help to collate these requirements. A RBS is a hierarchical description of all project requirements, typically represented as a tree structure, that must be present in the solution to deliver the business value expected. Contrary to the famous Work Breakdown Structure (WBS), which focuses on the how of the project, an RBS focuses on the what of the project.
Building an RBS
Business Requirements:
These represent the high-level business needs that ought to be covered by the project. Using the same example of a website development project, the same of our business requirements would include “BR1. Grow online sales” and “BR2. Grow brand awareness”.
Check out Business Requirements Document Template.
Stakeholder Requirements:
Their requirements refer to the needs of those impacted or with an impact on the project, which are usually a refinement from the business requirements, that is, an exercise of decomposition but this time attending to the origin of the requirement (e.g., by department or team). In our example, the Sales team might require “SR1.1 The website must enable users to buy in the shop online”, while the Finance team might require “SR1.2 The website should allow for real-time statistics on sales” and the Business Intelligence team might ask for “SR2.1 The website should collect data on visits’ location”.
Solution Requirements - Functional:
We then decompose a level further by identifying the functional and non-functional requirements of the solution. Starting with functional requirements, these refer to the requirement set at the user and system level, such as “FR1.1.1 The website requires users to register for their first purchase online” or “FR1.1.2 A user profile will be created for the user”.
Solution Requirements:
Non-functional: on the other hand, we also have non-functional requirements to consider: requirements related to quality, constraints, and assumptions for the solution. These could include aspects regarding performance, scalability, accessibility, and others. Following our example, a non-functional requirement for this project could be “NFR1.1.1 The website should have 98% uptime” or “NFR1.1.2 The website should have an Average Page Response Time of 3 seconds”.
Transition Requirements:
If you are moving from a solution to another or doing an upgrade to an existing solution, it is a good practice to also consider transition requirements, that is requirements that could facilitate the transition from the current state of the enterprise to a desired future state, but that will not be needed once that transition is complete. In our example, this could relate to rollout activities, data conversions needed, or training needs to move into the new solution.
Requirement Breakdown Techniques - Hints and Tips
-
Go to the lowest possible level:
It is not uncommon for requirements to be missed or assumptions to be made, which can later translate into an incomplete and failed project. Therefore, don’t be afraid to be specific and have an exhaustive detail level – you actually need it!
-
Run a requirements workshop:
By making it a group or focused exercise rather than individual interviews, you can engage stakeholders, clarify assumptions, identify redundancies and avoid misunderstandings.
-
Be objective:
Don’t be fooled by adjectives such as “simple,” “easy,” or “good,” as these can later bring satisfaction to the project stakeholders if not promptly clarified. What “easy” means to me can be very different from what it means to you; hence, requirements should be written in an objective language, as straightforward as possible.
-
Don’t focus on the implementation:
Then, the implementation of the requirements is to be considered later when building the Work Breakdown Structure. Don’t skip a step: your work is to focus on the what for now.
-
Combine it with a Requirements Traceability Matrix:
The Requirements Traceability Matrix extends information about the requirement, not just by tracing it back to the source (the stakeholder who requested it) but also by identifying their priority, typically expressed by the MoSCoW technique (must, should, could, won’t). Download requirements traceability matrix templates to help you keep documents and requirements in line with your project.
If you get the RBS right, it is simpler to progress into a Work Breakdown Structure, meaning that you will halfway towards successful project planning! Once RBS is done, don't forget to download our WBS Template.