What are the types of requirements as per BABOK?

One of the best parts of BABOK is its requirements classification schema. BABOK describes four types of requirements and that’s very useful in understanding the evolution of requirements in business analysis practice.

Elicitation, analysis, definition, validation, and management are just a few of the procedures that go into creating requirements. It’s important to remember that, like all other software engineering activities, requirements should be tailored to the demands of the process, the project, the product, and the people involved.

In addition, the requirements should be defined at several degrees of granularity. This is because requirements are written for users, business managers, system engineers, and other professionals.

In this article, we are going to discuss the BABOK requirements classification schema with the help of examples.

What are the types of requirements as per BABOK?

There are numerous types of requirements, ranging from high-level business needs to granular technical requirements that specify a specific aspect of a computer program or hardware device. There are various types based on the source of the demand, such as stakeholder requirements, and the process location, such as transition requirements. Because there is often misunderstanding and disagreement regarding what exactly constitutes a need, some teams will refer to business rules and policies as requirements, while others will refer to them as business specifications. BABOK has described 4 types of requirements as shown below:

• Business Requirements– Business requirements represent business objectives, stated by the customer.
• Stakeholders Requirements– Stakeholders’ requirements represent the requirements of individual stakeholders.
• Solution Requirements- Features and characteristics expected of developed software applications represent solution requirements.
• Transition Requirements- The transition requirements are the requirements needed to implement the software application successfully.

These requirements are crucial factors for any business to operate with better growth. But to understand them, we need to move ahead and learn how this requirement plays a major role to provide desired outcomes.

Business Requirements

Business requirements are high-level requirements that express an organization’s goals and desired outcomes. Engineers typically dismiss them as “fluffy” because they can’t see how they’ll be implemented, but if they’re adequately expressed, they can be broken down into measurable statements.

They are usually defined by the product owner or sponsor, the marketing department, or the client in a business case or other statements. They make an attempt to explain why the company is investing money and resources in the project. Enterprise Architect provides a Business Requirement element on the ‘Requirements’ toolbox page.

As per the BABOK guide, the business requirement is defined as:

Statements of goals, objectives, and outcomes that describe why a change has been initiated. They can apply to the whole of an enterprise, a business area, or a specific initiative.

Every software application, conceptualized and initiated by an organization, is meant to achieve a business goal like improving customer service, increasing revenue by 10% every month, etc.

Business requirements are typically high-level business goals and objectives.

An example of a business requirement

A typical business requirement example is shown for a large private sector bank could be as shown below:

We would like to automate our customer relationship management system so that we can offer better customer services so that the customer response time improves by 70% in the next 6 months.

It’s important that business requirements objectively state the objectives of what does the business need?

The business requirement takes needs as input to describe the business requirements. Business requirements do not include details about screens or business rules.

Stakeholder Requirements

Stakeholder requirements are declarations of the wants and expectations of the stakeholders, as well as the features that must be met in order for the business requirements to be met. Analysts prefer to focus on the functional aspects of demands, but stakeholders may have expectations for performance and dependability, as well as a number of other non-functional requirements.

Stakeholder requirements as per the BABOK guide:

Describe the needs of stakeholders that must be met in order to achieve the business requirements.

Stakeholder’s requirements are more individualistic. They serve as a bridge between business and solution requirements.

Stakeholders may specify their requirements specific to the project as per their needs (the division or business unit they represent).

Example of stakeholder requirements

In our Bank’s customer service management project, one of the stakeholders may state the following requirement:

We would like to have a mechanism to monitor the response time for each and every customer support request on a daily basis in order to improve the response time. The report should be generated daily, monthly on an on-demand basis.

A comparative report will be needed to see the trend.

One of the most significant challenges that a business analyst may face is when stakeholders can’t express the requirements well.

Solution Requirements

These requirements refer to the expected features and behavior of the system. Solution requirements as per the BABOK guide:

Describe the capabilities and qualities of a solution that meets the stakeholder requirements. They provide the appropriate level of detail to allow for the development and implementation of the solution.

Solution requirements represent the requirements of a solution. These requirements will be used by the development team to develop the system

Solution requirements are of two types:

Functional Requirements:

Functional requirements are the expected features of the system. Features like registering a user, making an online purchase, etc. Functional Requirements serve as a link between the business and technical teams, defining what the system must perform for its users in order to satisfy the company’s objectives. Some methodologists believe that Functional Requirements can be described solely through Use Cases or User Stories, but this appears to be a purist viewpoint, and in practice, detailed textual Requirements that describe what the architect must design and the developer must implement appear to be necessary. The ‘Requirements’ toolbox page in Enterprise Architect has a Functional Requirement element.

Non-Functional Requirements:

Non-functional requirements are the requirements that are related to the behavior of the system. Every page should load in 5 seconds is an example of a non-functional requirement. These are the quality requirements that the system must meet in order to fulfill the project contract. The importance of these aspects, as well as the amount to which they are implemented, varies from project to project. Non-behavioral Requirements are another name for them. They mostly deal with concerns such as:

• Accessibility
• Safety
• Consistency
• Durability
• Scalability
• Performance \Reusability
• Agility

One of the important parts of the requirements gathering activity for every business analyst is to write the requirements well.

Read Now – Functional Vs Non Functional Requirements

Transition Requirements

Transition requirements refer to the requirements to enable the successful implementation of a project. As per BABOK,

Describe the capabilities that the solution must have and the conditions the solution must meet to facilitate transition from the current state to the future state, but which are not needed once the change is complete. They are differentiated from other requirements types because they are of a temporary nature.

Transition requirements are short-period requirements. Once these requirements are completed, they no longer exist.

Example of transition requirements

Examples of transition requirements are as follows:

• The users must be trained to be able to use the system effectively
• The previous year’s data must be migrated to the new system to generate a comparative report

Learn More – What Is Requirements Analysis and Modelling?

Attributes of a good software requirements

It’s challenging to come up with a complete set of needs. Instead, it’s preferable to list the necessary components that a good SRS should have, and a good SRS should list all of the functions that the software must support:

• Functionality: These are the functional requirements that define the relationship between the system’s input and output. They will look for invalid inputs and outputs in the system’s behavior. The numerous outputs that are created from the given input will be suggested by functional requirements.
• Performance: There will be two sorts of performance criteria: static and dynamic performance requirements. Examples of static requirements are the number of terminals or users to be accommodated without imposing limits on the system’s execution behavior. Response time and system throughput restrictions are two examples of dynamic requirements.
• Correct and Complete: All requirements should be detailed in the document. If it’s a BRD, it should include a list of all business objectives and advantages. If it’s an SRS, it should detail all of the system’s features and capabilities. Use a readable format and go back to finish any entries that are still to be determined. It’s rare that a single person is responsible for delivering a full and accurate software requirements document.
• Design Agnostic: The end result should be depicted in software requirements documents. The many sorts of requirements, similar to an architectural diagram, specify what the development team should build and why, but rarely explain how. Allow developers to choose from a variety of design solutions during the software project’s implementation phase; don’t specify precise implementation specifics until they’re required to meet business objectives.

Future Aspects – Requirements Gathering in 2030

Requirements Development Pyramid

Just to further enhance the understanding of where business analysis skills come into picture ,where business analysts are involved during your requirements process we have a pyramid called Requirements Development Pyramid. Where business requirements are at the top of the pyramid, which is where it all begins.

Then it gets further expanded and detailed as stakeholder requirements.

The next step is to identify the solution and the transition requirements, which further widened more details coming to each other.

After that, the analysis and modelling begin, so you'll have process models and data model, and finally, you'll end up the requirements development phase with acceptance test cases.

Acceptance test cases are related to software acceptance and must be defined alongside the requirements as to why and how the customer is going to accept the software,what are the different test cases which the customer will be using to accept this offer.

Conclusion

In this article, we have seen types of requirements as per BABOK. Through this, we learnt how the requirements differ from each other. And how clients' offers can be evaluated using each one of these requirements types.

Acquiring a deeper understanding of the types of requirements as per BABOK is essential for any business analyst, and Techcanvass's CBAP Certification training course offers the perfect opportunity to do so. This course is tailored to equip you with the knowledge and skills necessary to excel in your business analysis career, making use of valuable resources such as the BABOK short revision tables, BABOK Revision Guide, and 25+ case studies.

Our CBAP training course covers every chapter of the BABOK, including perspectives, and is completely in line with the BABOK V3.