What is a requirement, what interpretations are there and how should requirements be expressed?
The description of the desired range of functions
There are many different uses and interpretations of the term requirement. The Association for Work Design, Organisation and Development of Enterprises (REFA) defines a requirement as “the totality of the physical and mental conditions required to carry out the work”. In psychology, requirements are the demands of people to perform specific tasks. And in personnel recruitment, requirements for potential employees are summarised and declared as a requirement profile.
What is a requirement in software development or product development? The International Requirements Engineering Board (IREB) defines a requirement as
- a need that is perceived by a stakeholder.
- an ability or characteristic that a system should have.
- a documented representation of a need, skill or property.
For the International Institute of Business Analysis (IIBA), a requirement is a useful representation of a need that is usually described by documents. The Business Analysis Body of Knowledge Guide (BABOK) has four categories of requirements:
- Business requirements are goals and results that describe the reason for initiating changes.
- Stakeholder requirements describe the needs of the stakeholders that must be fulfilled in order to meet the business requirements.
- Solution Requirements define the performance and quality of a solution that meets stakeholder requirements. They can be subdivided into functional and non-functional requirements.
- Transistion Requirements describe the performance of a solution to facilitate the transition from the actual to the target state.
In many organisations there is also a division of the requirements into functional and non-functional or quality requirements, as well as legal, moral/ethical, organisational and technological framework conditions. Due to the variance of the term and the different interpretations, organisations should urgently pay attention to a common understanding of all participants.
Objectives when collecting requirements
The use of defined processes to work with requirements is also recommended. The aim should be, among other things, to identify
- assessed according to importance and/or stability,
- verifiable and traceable
The attributes that are often used to record requirements can be found here »
“The expertise in software architectures, the expertise in software development and the very flexible way of working were ideal for us.“
“I have been reading your blog for a long time with great pleasure. Systematically, to the point and appealing.”