Requirements Classification Schema

REQUIREMENTS CLASSIFICATION SCHEMA

A requirement is something that is needed in order to complete a project and to understand what the client needs are. The more one knows about the requirement, the better would be the outcome of the project which in turn will satisfy the clients and the stakeholders. The requirements classification schema is subdivided into the below categories:

• Business Requirements-

Business Requirements defines the goals and objectives of the business at the enterprise level. These are the requirements that applies to the entire organization as a whole and it’s not just limited to a specific group.

Business requirements are developed and documented as a part of ongoing enterprise analysis activities. Business requirements clearly displays the purpose of the projects which have been initiated and is understandable by everyone within the organization. It shows a clear path for the organization to follow to achieve the output. 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. It’s a crucial parameter that drives a business to great heights if followed correctly and accurately.

• Stakeholder Requirements-

Stakeholder Requirements describe the goals and objectives of a specific group within an organization. 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.

The stakeholder requirements of various groups needs to show a perfect 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, rather they span the gap between Business Requirements and more specific Solution Requirements.

• 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. Every requirement is interlinked with each other and every requirement has its own process which needs to be executed. Solution requirement is a way to figure out different solutions which can be incorporated with other requirements to get the best outcome.

• Functional Requirements-

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-

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-

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.