October 09, 2018

Requirements Breakdown Structure (RBS) in Project Management

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) is of major help.

RBS project management, Requirement Breakdown Structure
Requirements Breakdown Structure


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. This being said, it is thus useful for project managers to know what a requirement is and how these can be structured in a logical way. Particularly, when it is known that most projects fail due to poor requirements identification!

Requirements are conditions or tasks that need to be addressed and completed to the project to be accepted as complete. They are originated from the project’s stakeholders and can be expressed as physical deliverables or business benefits, as aspirations or solutions, and as functional or technical needs. As an example, if you are building a website, a requirement could be that it should be integrated with an e-commerce solution.

To collate these requirements, a requirements breakdown structure (RBS – not to be confused with risk or resource breakdown structure!) is of major help. A RBS is a hierarchical description of all project requirements, typically represented as a tree structure, that must be present in the solution in order to deliver the business value expected. Contrary to the famous Work Breakdown Structure (WBS) which focuses the how of the project, a RBS focuses on the what of the project.

Building a RBS

Requirements Breakdown Structure Template
Requirements Breakdown Structure Template

To build a RBS group and decompose the requirements gathered in at least 4 levels:

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, same of our business requirements would include “BR1. Grow online sales” and “BR2. Grow brand awareness”.

Stakeholder Requirements: 

There 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 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, that is, 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 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

  1. 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 level of detail – you actually need it!
  2. 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.
  3. Be objective:
    Don’t be fooled by adjectives such as “simple”, “easy”, of “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 clear as possible.
  4. Don’t focus on the implementation:
    The implementation of the requirements, the how, 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.
  5. 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).
If you get the RBS right it is then much simpler to progress into a Work Breakdown Structure, meaning that you will halfway towards a successful project planning!

No comments:

Post a Comment