Types of Requirements in Business Analysis

In the world of Business Analysis everyone is talking about the requirements this and the requirements that but do they really understand the key definitions and differences between all the different types of requirements?
In this article we outline the different types of requirements by drawing an analogy to building a house.

What is a requirement?

A requirement in the context of Business Analysis is simply a statement provided by a stakeholder about what they believe they need in order to solve a particular business problem or respond to a specific business need.  Once this requirement has been raised by the stakeholder it is the business analyst’s role to further define, analyze, validate and prioritize the requirement statement as it is now included within the business analysis context of requirements management. In real life, the stakeholder will typically state their business problem or need and then provide a whole range of individual requirements throughout the requirements management process managed by the business analyst.

Why does the requirement type matter?

There are many different types of these requirements, which are raised by the stakeholders of a particular project. Although most of the requirements are raised typically at the start of the initiative or project, it is also likely that further requirements will be raised during later stages of the project. In the case of an Agile based project, it is likely that requirements will be raised on an ongoing basis although these will also be initiated with most of the significant and larger requirements to be stated early on in the project.

This means that all the different types of requirements that are provided need to be classified within its category in order to be able to manage the requirements process effectively. Once you understand the different types of requirements very clearly, this becomes a natural and easy task to firstly identify when a requirement is in fact a requirement and then to determine what type of requirement it is.

What types of requirements exist?

The easiest way for any Business Analyst to quickly understand these different types of requirements is to compare the typical business project to a project for building a house. We will now sketch the business need stated by the stakeholder in this context and illustrate examples of the different types of requirements, which exist:

Understand the Business Need / Business Problem Statement – Before we even get to the Requirements…

A family of four have lost their rural property house in a fire and are currently housed within a caravan on their property. After doing a lot of calculations around the family budget, considering the insurance payout they received and other specific family constraints they have decided that their best option is to rebuild the family home. After considering a variety of other housing possibilities they decided that living on the property where the house burnt down is in line with their long term plans to resell that property once the freeway is build close by which will be completed in a few years. This option to rebuild will therefore be by far the most profitable option for the family as a whole and in the mean time they can still enjoy their lush and rural location as a young family.

These are exactly the type of considerations, which business stakeholders will have to work through when they are faced with a business problem or need. The business analyst (operationally focused enterprise analyst) will be part of the options analysis performed when processes such as a feasibility studies, business concept briefs and other pre-project analysis steps are undertaken. The business analyst will also get involved in assessing whether the proposed initiative will be in line with the business strategy and be profitable by also assisting in cost/benefits analysis activities. As you can see there are a myriad of business analysis activities, which are performed even before requirements come into play.

An important point about Requirements Analysis

Before we start defining the different types of requirements it is important to point out that during the Requirements Analysis phase of the project the Business Analyst starts with a broad and general description of the what is required to be done (often a business need or problem description) and then start working with the key stakeholders within and surrounding the project to define the Scope (what is included and excluded in the project’s deliverables), Business Requirements (high-level requirement statements), Stakeholder Requirements (which becomes more specific describing ‘what’ is required) and finally delving into specifics of how to implement (with Solution Requirements and finally transition requirements). It is therefore a journey working from a concept level right down towards a detailed and specific requirements level.

Scope Statements

Although we are not discussing the scope statements of a project in great detail here it is important to take note that each project or initiative must have clear boundaries of what is included and excluded prior to embarking on requirements analysis. (This is approached in a slightly more iterative and evolutionary fashion on Agile based projects (driven by time, budget and change in business priorities) but is essentially still working within boundaries or scope definitions at a high level).

Scope Statement Example:

“Re-establish a family on their property in the country”

This example scope statement describes the scope of what the project ultimately will deliver. It is important to be clear on a project’s scope statement or statements to ensure that all the requirements, which are included in the requirements activities of the project, are in fact aligned with the overall project scope.

Types of Requirements 

As you can imagine there will be a lot of requirements raised and specified when it comes to building a house. We will only use a small set of requirement examples here to outline and describe the meaning of the different types of requirements that exist.

Business Requirements

Business Requirement Example:

Build a family home to replace the home that was burnt down including the addition of a garage.

The Business Requirement is a high level statement describing what is required from the business’s perspective. In some contexts or projects there may be overlap between the Business Requirements statements and that of individual scope statements. For larger initiatives these will be different levels of expressing what is required.

Stakeholder Requirements

• Stakeholder Requirement Example 1: “We need a family house with four bedrooms so that each child has their own bedroom”
• Stakeholder Requirement Example 2: “We need the house to have two separate bathrooms to ensure the parents have their own bathroom separate from the children”
• Stakeholder Requirement Example 3: “We need the house to be protected against future bush fires so that we don’t have to fear loosing our house again”

These examples are requirements, which are describing “what” the family need the new house to have. It is important to understand here that this type of requirement, the stakeholder requirement is not stating how they want these requirements to be implemented, they are simply stating what is required.  As a Business Analyst you must guard against requirement statements at this early stage of the project, which describes “how” to deliver the requirement. In the context of this example an example of a requirement, which describes “how” rather than “what” is needed would be this: “The family’s little girl states that she wants her bedroom to be painted pink with butterflies on the wall.” There are many stakeholders that will do exactly what the little girl has done and tell you as the business analyst how they want the solution to work before they have stated what exactly they are in need of.  The little girl is assuming that you know that she needs a bedroom and all she is concerned with is how the bedroom will look. Keep this in mind when you speak to your stakeholders in future about stakeholder requirements.

Solution Requirements

• Solution Requirement Example 1: “I want my bedroom to be painted pink so that everyone will know it is my room” – Stakeholder who raised this requirement is the little girl.
• Solution Requirement Example 2: “I want my bedroom floor space to be at least 30 square meters so that I can practice my skateboard tricks in the bedroom” – Stakeholder who raised this requirement is the teenage boy in the family.
• Solution Requirement Example 3: “Every bedroom must have an air-conditioning unit implemented so that the family can stay cool during the summer” – Stakeholder who raised this requirement is the father in consultation with the architect.
• Solution Requirement Example 4: “ The house must have fire resistant insulation in all the walls of the house to prevent significant fire damage.” – Stakeholder who raised this requirement is the builder who is adhering to a regulatory requirement.

The solution requirements describe how the stakeholder wants to implement their stakeholder requirements. In this example, the stakeholder requirement relating to having four bedrooms has been expanded upon with more specific solution requirements describing how that stakeholder requirement must be implemented (Solution requirements 1, 2 and 3 are expanding on that stakeholder requirement). Take note here that as you progress with your Requirements Analysis you are delving into more specific and detailed requirements.

Also keep in mind that although Solution Requirement example 2 has been stated and documented, it may be deemed invalid during a requirement validation session with all stakeholders in the room. It is important to capture all requirements but it is also important to validate and ensure that all stakeholders are in agreement about which requirements are in fact valid. In this example, the validation criteria may include budget constraints, which may be the reason why the teenage boy cannot have such a large room after all.

There are two sub-types of Solution Requirements:

• Functional Requirements: This type of solution requirement describes how the solution must behave. In the example of the house, it describes how the house must look (colors, size of bedroom) and perform (have an air-conditioning unit in each bedroom). In a system related scenario example, the different functions that you want a system to perform is typically described as functional requirements (in an Agile Project context, it is referred to as a ‘user story’). An easy way to remember this type of solution requirement is to think about what do you want to the system to be able to do. Another example in the context of the house would be that a functional requirement exists to have internal doors, which can be opened and closed but not locked. This is something that you want the house to be able to do, a function you want the house to be able to perform.
• Non-functional Requirements: The non-functional requirement type of solution requirement describes the characteristics that you want the system to have. In the context of the house example, solution requirement 4 is describing a characteristic that is required of the house walls. It is not a function of the house but rather a characteristic of the walls. In the scenario of a system an example that compares to this house analogy would be a non-functional requirement describing the need to have a backup-system installed to be used in the event of a disaster to prevent unnecessary data loss. The non-functional type of solution requirement therefore describes the attributes a system or process should possess and not a function that the system must perform.

Transition Requirements

Transition Requirement Example:

The floors in the house must be covered with sheets to protect the carpets when the moving company moves the furniture into the house.

A transition requirement describes a requirement that must be in place for a certain phase or period of time. In this example, the requirement to have the floor protect during the moving of furniture into the house is an example of a transition requirement. In the context of a system, a transition requirement could be that additional support staff must be available during the first month after the system have been implemented to assist with additional support queries that may be received.

In Conclusion

Once the Business Analyst has a clear picture about the different types of requirements and consequently the levels of detail of requirements it becomes second nature when identifying and categorizing requirements for a project. Requirements Analysis is all about understanding these types of requirements and managing them effectively through the Requirements Management Processes of a project.

Do you use the same requirement types in your organization? Please share your thoughts and opinions on this topic!