Types of Requirements
From Requirements Management School
There are various stakeholders involved in any given software engineering project. Each of these stakeholders brings a very different perspective to the table. This means that there are also many different types of requirements that need to be addressed in order to satisfy all stakeholders’ needs.
Requirements can be categorized in several different ways. In order to ensure that everyone is working from the same definitions, there are four distinct types of requirements that should be addressed by a requirements document:
- Business Requirements – These are the requirements that are set out by the organization that is paying for the software. Their requirements will be defined by the business case and the expected benefits. It may also include business constraints - such as legal, regulatory and accounting standards that the software must adhere to or even other software that it must interface.
- User Requirements – User requirements are made up of the functions that a user needs to carry out with the software in order to reach their goal. An example for a user requirement might be that they are able to set a reminder for an event.
- Functional Requirements – The functional requirements are a list of objectives that the software must meet. They identify the individual tasks that the software will carry out in order to meet the end user’s needs. A functional requirement might be “the software shall notify the user with a reminder”.
- Non-Functional Requirements – The non-functional requirements generally relate to the way in which the software behaves in its environment i.e. integrity, ease of use, reliability, scalability and so on.
When defining these 4 types of requirements, keep the following in mind:
- Requirements must be defined so that they are consistent, feasible and verifiable.
- They must also be written in a manner that does not address how the goal is going to be achieved but only the the goal.
- In addition, it is always important to remember to be explicit. Define every requirement, go through the processes with a fine tooth comb and remember that the obvious also needs capturing. It should never be assumed that certain functionality will be there. As each stakeholder views the process from one perspective the functionality that they assume as standard may not be apparent from somebody else’s perspective.
