Types of Requirement
The number of qualifiers for the word requirements can be confusing; we speak of requirements as being functional or non-functional, system or software, project or business or user. Restricting ourselves with the single word requirement does not help; separate categories of requirements do exist, and it is a very useful to formally differentiate them. Such differentiation facilitates requirements elicitation itself, system design and development, and testing.
Even within a single organisation (or project) multiple terms are often used without first having taken the precaution of agreeing a definition for each of them. Organisations should define a consistent set of terms, agree them among units of the organisation and apply them consistently
There are many systems were classifying requirements. It would have been possible for to have classified the following in different ways. We are always interested in hearing other people's views; please feel free to e-mail us.
Examples.
Business Requirements
Define the business need, e.g. in terms of increased profitability, market share, etc. There is a close relationship to the business case for the project. Sometimes the term is used interchangeably with User Requirements. It may be useful to limit the term business requirements to those reasons why business may choose to invest in a project. It is unlikely that satisfaction of business requirements can be included in acceptance testing. It is also unlikely that developers could work purely from a specification of business requirements.
User Requirements
Define what the user needs by way of services to meet the business requirements.Sometimes used interchangeably with the term business requirements. A hotel receptionist for example, needs to be able to find a booking on the system by quoting a booking reference. Popular ways of discovering user requirements is through scenarios and use cases.
Software Requirements
Define the software necessary to support the user requirements.
Functional requirements: specify what the system does. They are the services to be offered by the finished product. When testing, functional requirements are either present or not present.
Non-functional requirements refer to levels of quality to be applied to the functional requirements. They define how well something is done. This term is unfortunate; Collins Concise English Dictionary defines functional as "capable of working". By implication, non-functional may be considered as the opposite. These days, a preferred term is quality requirement or quality attribute.
Quality requirements: specify how well the functions are performed. Quality requirements are sometimes referred to as non-functional requirements. Getting the quality requirements right can mean the difference between merely satisfying the stakeholders and exciting them. In fact, it is possible to fully satisfy all functional requirements, and yet fail to deliver the system that the stakeholders needed.
Click here for more detail on quality requirements
System Requirements
Sometimes used synonymously with the term software requirements. In other cases they may refer to requirements at the overall system level, including requirements for business processes, software systems and hardware. They may also refer to interfaces to other systems.
Project requirements
Project requirements are the constraints, typically of cost and time, that apply to a project. Although what we are able to achieve is obviously affected by the time and money available, project constraints clearly do not define the product. With less time we may have to settle for less functionality than we would otherwise have been able to create. Similarly, with less money, our quality requirements will have to be less ambitious. But the product is still the product; we cannot describe it in terms of the money and time available to create it.
Interface requirements
Define the need for specific interfaces.
Constraints
The term constraints gets used in a variety of ways. It can refer to limits on project cost and duration. Sometimes it used as an alternative to non-functional or quality requirements. We may usefully reserve the term to cover such things as legal requirements, technical (design) requirements, implementation requirements, cultural requirements, and so on. Yet again, the term is sometimes defined as global requirements. Take your pick.
Business rules
Business rules are sometimes thought of as a form of non functional requirement. However, business rules exist independently of our product and it is convenient to establish them independently. They can be maintained by the user community. They can be implemently in a free standing manner by using a rules engine.