Requirements Classification Schema

Requirements Classification Schema:

The requirements classification schema is further classified into the following:

Business Requirements: Defined as goals and objectives of the business at the enterprise level. They apply to the organization as a whole rather than a specific group within the organisation. Developed and documented as part of ongoing enterprise analysis activities.

Business Requirements are also known Enterprise Requirements. They offer everyone within the organization a common understanding of why certain projects have been initiated in the organisation. They provide organization clear direction that can be followed by everyone in the organisation. Requirements should ideally define something in measurable terms. This is most important with business requirements.  Therefore, business requirements should outline a corresponding metric and target that must be achieved by the business.

The critical activities of an enterprise that must be performed to meet the organizational objective while remaining solution independent.

The Business requirements document (BRD) is the detailed business solution for a project including the documentation of customer needs and expectations.

The BRD process can be incorporated with Six Sigma DMAIC (Define, Measure, Analyse, Improve, and Control) culture.

The common objectives of the BRD are as follows:

• To pursue agreement with stakeholders.
• Provide a foundation to communicate with the technology service provider what are the solution needs to satisfy the customer’s and business’ needs.
• Provide inputs into the next phase for this present project.
• To describe how the customer and business needs will be met by the solution.

Examples of business requirements:

• The process must completed.
• The data they need to be used for that process.
• Business rule usually governs the process and that data.

The following are teams and partners who create the BRD project: the following People Involved in the Creation of the BRD process;

• Project core team.
• Business partner.
• Process owner or representatives.
• Subject matter experts

 Stakeholder Requirements: Defines the goals and objectives of a particular group within an organization. Unlike Business Requirements, they are intended to provide a higher level direction to group of stakeholders.

They are often developed while considering the contending goals and objectives of other areas of the organization that interact with each other within the organisation. Stakeholder requirements of various groups are reflected in overall balance across the organization to support and achieve the Business Requirements in the best possible way.

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.

The cause for the frequently change in requirements is due to tighter coupling and dependency between requirements

Major roles in systems engineering played by Stakeholder requirements, they are:

• The basis of system requirements
• The basis of system validationand stakeholder acceptance.
• They Act as a reference for integrationand verification
• Serve as means of communication between the technical staff, management, finance department, and the stakeholder community.

 Solution requirements: The solution may be a process solution or system solution. Solution requirements is written in a way that they support and also align with the Stakeholder and Business Requirements. They are defined throughout the requirements analysis process.

Solution requirements sub-categories are as follows:

1. Functional Requirements: Defined as the behaviour and information that the solution will have to manage. The functional requirements describe the features and functionality of the system and the information that will be created, edited, updated, and deleted by the system. In the case of a non-system solution, the behaviour typically refers to a workflow and the information refers to the inputs and outputs of the workflow.

The Functional requirements describe how the data will be transformed and by whom.

The list of examples of functional requirements are: a) Business Rules, b) Transaction corrections, c) adjustments, and d) cancellations, e)Administrative functions, f)  Authentication, g) Authorization levels, h) Audit Tracking, I)External Interfaces, and j) Certification Requirements.

1. Non-functional Requirements: It describes the qualities of the process or system.  Instead of describing what the solution must do, the non-functional requirements describes how well the solution must do to achieve something. Non-functional requirements are described qualities of a process or system such as its repeatability, usability, reliability, interoperability, scalability, extensibility.

Mostly used Non-functional Testing Tools are: J Meter, Loadster, Loadrunner, Loadstorm, Neoload, Forecast, Load Complete, and Webserver Stress Tool.

 Transition Requirements: Describes 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. Transition requirements cannot be developed until both the current state and the future solution have been defined 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.

Common categories of transition requirements include:

• Rollout activities.
• Data conversions.
• Training needs.
• Realignment of responsibilities in the user groups.