Requirement in general sense is the need. In this particular context, a requirement can be defined as the need of a stakeholder/client. This requirement is communicated at the beginning of the project and in the process of SDLC, this is converted to a solution which the client requested.
Requirements are considered as the foundation of any project, as the project depends and works on that particular requirement. It is something that is demanded by the stakeholder/client and is expected that it is submitted as requested without a deviation.
Once this requirement has been given by the stakeholder, a business analyst comes in to the picture where he/she needs to further define, analyse, validate and prioritize the requirement.
Before we go further into the types of requirements, let us first understand what requirement is with an example:
An entrepreneur is wanting to develop an application which is used to connect with people all around the world. But there are applications in the market which are already doing the same functions and much more. However, the person has a few ideas which hare unique and will show a difference that existing applications in the market.
This is an example of problem statement or business problem that is given to a business analyst. So now, business analyst role starts with options analysis, feasibility study of the ideas and business concept briefs through which he/she can understand the exact requirement and then can define business requirements and stakeholder requirements.
Namely there are 4 types of requirements:
Business requirements: These are generally described as a high-level statement that is required from business perspective. These requirements describe why the project has been started and the objectives that are needed for the project to be a success. In short, business requirements can be described as the needs of an organization as a whole.
In the above given example, we can consider developing an application as the business requirements, as it gives the whole picture of what is needed by the client.
The document that is prepared for business requirements is called as Business Requirements Document (BRD)
Stakeholder requirements: These are the requirements of a particular stakeholder or class of stakeholders. Stakeholder can be one or two or multiple. And all the requirements given by them are considered as stakeholder requirements. In short, we can define stakeholder requirements as the ‘what’ of a requirement.
In the above example we can see that developing an application is a business requirement. But what is the application used for is stakeholder requirement because it explains in detail what the application is supposed to do.
The document that is prepared for stakeholder requirement is called as User Requirements Document (URD)
Solution Requirements: They describe the characteristics of the solution that meet both business requirements and stakeholder requirement. A BA has to do requirement analysis to develop and define solution requirements. The document that is prepared for solution requirements is Solution Requirements Specifications (SRS). This is again classified in to Functional and Non-functional requirements.
- Functional Requirements: These can be described as the technical requirements of the project that define the capabilities in terms of behaviour or operations. The documents that are prepared for functional requirements are known as Functional Specifications (FS) or Functional Requirement Specifications (FRS) or Functional Requirement Documents (FRD). Functional requirements describe the ‘How’ of a solution. In the above example, how application should look is the functional requirement.
- Non-Functional Requirements: This describes the attributes a system or process should possess and not a function that system must perform. The documents that are prepared for non-functional requirements are known as Supplementary Support Document (SSD). In the above example, characteristics of the application can be considered as non-functional requirements.
Transition Requirements: Transition requirements are described as the temporary requirements one-time requirements that are needed for the solution to perform but are not needed once the project is finished. Once the desired state of the solution is reached, these capabilities are not required. The documents that are prepared for transition requirements are known as Application Design Documents (ADD).
Once the business analyst has a clear picture about different types of requirements it becomes easy to categorize the requirements. Requirement analysis is all about understanding different types of requirements and managing them effectively through Requirements Management Process of a project.