ANSWER
The requirements classification schema used by the BABOK (v2.0) places requirements in one of the following categories.
- Non-Functional Requirements
Business Requirements define the goals and objectives of the business at the enterprise level. These are requirements that apply to the organization as a whole rather than a specific group within the organization. Business requirements are developed and documented as part of ongoing enterprise analysis activities. Business Requirements, or Enterprise Requirements as I prefer to call them, offer everyone within the organization a common understanding of why certain projects are initiated. They are a compass for the organization providing a clear direction that can be followed. While all requirements ideally should define something in measurable terms, this is even more important with business requirements. Therefore, business requirements should outline a corresponding metric and target that needs to be achieved by the business.
Stakeholder Requirements describe the goals and objectives of a particular group within an organization. Like Business Requirements, they are intended to provide a higher level direction for the stakeholder group, but often they are developed while considering the contending goals and objectives of other areas of the organization that interact with each other. So, the stakeholder requirements of various groups need to reflect an overall balance across the organization to support and achieve the Business Requirements in the best possible way. This tighter coupling and dependency between requirements causes Stakeholder Requirements to change more frequently. Stakeholder requirements do not define what needs to be supported by a particular solution (whether the solution is a business process or system solution), rather they span the gap between Business Requirements and more specific Solution Requirements.
Solution Requirements describe the various characteristics of a solution that must be met. The solution may be a process solution or a system solution. Solution requirements should be written in a way that they also support and align with the Stakeholder and Business Requirements. Solution requirements are defined throughout the requirements analysis process. They can be further classified into two sub-categories:
Functional Requirements describe the behavior and information that the solution will manage. In the case of a non-system solution, the behavior typically refers to a workflow and the information refers to the inputs and outputs of the workflow. Additionally, the requirements describe how the data will be transformed and by whom. In the case of a system solution, the functional requirements describe the features and functionality of the system as well as the information that will be created, edited, updated, and deleted by the system.
Non-functional Requirements describe the qualities of the process or system. Instead of describing what the solution must do non-functional requirements describe how well the solution must do something. Non-functional requirements often describe qualities of a process or system such as its repeatability, usability, reliability, interoperability, scalability, extensibility, etc.
Transition Requirements describe any capabilities of the solution that aren’t permanent but instead exist only to facilitate the transition from the current state to the future state. Once the process or system has been developed and the transition of users and information from the current solution to the new solution has occurred, these capabilities will no longer be needed or supported. Transition requirements cannot be developed until both the current state and the future solution have been defined.
The requirements classification schema used by the BABOK (v2.0) places requirements in one of the following categories.
- Solution Requirements
- Functional Requirements
- Non-Functional Requirements
Business Requirements define the goals and objectives of the business at the enterprise level. These are requirements that apply to the organization as a whole rather than a specific group within the organization. Business requirements are developed and documented as part of ongoing enterprise analysis activities. Business Requirements, or Enterprise Requirements as I prefer to call them, offer everyone within the organization a common understanding of why certain projects are initiated. They are a compass for the organization providing a clear direction that can be followed. While all requirements ideally should define something in measurable terms, this is even more important with business requirements. Therefore, business requirements should outline a corresponding metric and target that needs to be achieved by the business.
Stakeholder Requirements describe the goals and objectives of a particular group within an organization. Like Business Requirements, they are intended to provide a higher level direction for the stakeholder group, but often they are developed while considering the contending goals and objectives of other areas of the organization that interact with each other. So, the stakeholder requirements of various groups need to reflect an overall balance across the organization to support and achieve the Business Requirements in the best possible way. This tighter coupling and dependency between requirements causes Stakeholder Requirements to change more frequently. Stakeholder requirements do not define what needs to be supported by a particular solution (whether the solution is a business process or system solution), rather they span the gap between Business Requirements and more specific Solution Requirements.
Solution Requirements describe the various characteristics of a solution that must be met. The solution may be a process solution or a system solution. Solution requirements should be written in a way that they also support and align with the Stakeholder and Business Requirements. Solution requirements are defined throughout the requirements analysis process. They can be further classified into two sub-categories:
Functional Requirements describe the behavior and information that the solution will manage. In the case of a non-system solution, the behavior typically refers to a workflow and the information refers to the inputs and outputs of the workflow. Additionally, the requirements describe how the data will be transformed and by whom. In the case of a system solution, the functional requirements describe the features and functionality of the system as well as the information that will be created, edited, updated, and deleted by the system.
Non-functional Requirements describe the qualities of the process or system. Instead of describing what the solution must do non-functional requirements describe how well the solution must do something. Non-functional requirements often describe qualities of a process or system such as its repeatability, usability, reliability, interoperability, scalability, extensibility, etc.
Transition Requirements describe any capabilities of the solution that aren’t permanent but instead exist only to facilitate the transition from the current state to the future state. Once the process or system has been developed and the transition of users and information from the current solution to the new solution has occurred, these capabilities will no longer be needed or supported. Transition requirements cannot be developed until both the current state and the future solution have been defined.