3. Types of requirements

There are different types of requirements in a project, depending on how they have been categorized, whether it is based on the kind of deliverable, the kind of process the requirement will require, or its source.

The types of requirements are usually classified into four types: business requirements, stakeholder requirements, solution requirements, and transition requirements.

3.1 Business requirements:

Business requirements are what the business needs to do in order to meet the organization’s objectives while meeting stakeholder requirements. Business requirements are an interpretation of the stakeholder requirements in terms of what is goals the project should accomplish while fulfilling these stakeholder requirements. In simple terms, they give the extent of a business need or problem that should be addressed by a particular project or task.

3.2 Stakeholder requirements:

Stakeholder requirements are the goals and the objectives that the stakeholders want to be fulfilled, or a solution to a particular existing problem through the successful completion of the project. Simply put, stakeholder requirements are the needs of the various parties involved in the project, such as the business units, operations, customers, users, and subject matter experts. While business requirements are high level, stakeholder requirements are detailed needs from the stakeholders’ perspective.

3.3 Solution requirements:

Solution requirements detail the conditions, capabilities, and characteristics a solution has to have in order to solve the problem in the existing system and fulfill the stakeholders’ needs, business needs and objectives, and support the project. Solution requirements are from the perspective of a solution, explaining what course of action to take in order to construct a solution that satisfies business as well as stakeholder requirements. There are two types of solution requirements: functional and non-functional requirements.

a) Functional requirements: Functional requirements define the specific behaviors, responses, information, rules, or operations of a solution. They outline:

• What features or functionality the solution will support
• What specific stakeholders will do or experience while being a part of or using the solution
• What information or data will be managed
• Under what circumstances will the behaviors and responses happen (or not) in order to ensure the required results and outcome

b) Nonfunctional requirements: Nonfunctional requirements specify the manner in which a solution is intended to operate. They describe the qualities a solution must have and any supplemental expectations or conditions it must meet or support. Nonfunctional requirements define standards for:

• Usability: How easy the solution must be to understand or figure out
• Reliability: To what extent users can rely on the solution to be accessible and work when needed
• Performance: How quickly and efficiently the solution works and how it responds to commands and requests for action
• Security: The level of protection the system and its data are expected to have in place
• Design: The visual elements expected from the solution
• Accessibility: The support that must be provided for users with disabilities, including hearing or vision loss, typically in compliance with relevant regulations such as the Americans with Disabilities Act of 1990
• Documentation: The type and extent of written documentation expected or needed
• Information capacity: Requirements for the amount of data or media to be stored, including the expected growth of the information over time
• Information architecture: Any needs for the arrangement or organization of the information in the solution
• Anything else: Whatever else the stakeholders decide is required of the solution.

No matter what kind of solution requirements are identified and defined, those you elect to implement should be validated as capabilities that stakeholders really need and (as a result) decide must be included in the solution — either because including them is strategically, functionally, or technologically smart.

3.4 Transition Requirements

Transition requirements are the conditions or activities that are necessary for the organization to move solutions out of development and into real-world business use. They are not what the application needs to do but what the organization needs to do in order to put it into use. Transition requirements can do the following:

• Describe what has to be done with people, process, and technology before you can get the solution into implementation
• Educate and train the way new way employees must work and outline the differences from before and now.

• Define any shifting, movement, enhancement, or change to data and information out of their original structures or locations into their new data centers.