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. In this article, we’ll go over the different sorts of software requirements and offer some suggestions for how to use them. 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, I am going to discuss the BABOK requirements classification schema with the help of examples.
Read More – IIBA BABOK Guide Version 3 – What’s Inside?
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.
Watch Now – Business Analyst Training | Types of Requirements
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 or on on-demand basis.
A comparative report will be needed to see the trend.
Learn More – 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 \sReusability
- Agility
One of the important parts of the requirements gathering activity for every business analyst is to write the requirements well.
Read Now – Top Characteristics of well-written 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
Conclusion
Techcanvass offers IT certification courses for professionals. We are an IIBA-endorsed education provider (EEP), iSQI ATP (for Certified Agile Business Analyst Training) as well as an Agile Testing alliance partner for CP-SAT certification training in Selenium.
Our ECBA Certification Training program is a well-structured course, which not only helps you in becoming a Business Analyst but also helps you in getting prepared for ECBA Certification.
