What is a Requirement?

Requirement as a description of the desired scope of functions

There are many different definitions for the term requirement. The Association for Work Design, Company Organisation and Enterprise Development (REFA) defines it as “the totality of physical and mental prerequisites for performing work”. In psychology, they refer to the demands of people to perform specific tasks. And in recruitment, they are summarised for potential employees and declared as qualification profiles.

What is a requirement in software development or product development?

The International Requirements Engineering Board (IREB) defines it 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), it is a useful representation of a need, usually described by documents. The Business Analysis Body of Knowledge Guide (BABOK) defines four categories:

• 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.
• Transition 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 into functional and non-functional or quality requirements, as well as legal, moral/ethical, organisational and technological parameters. 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

Principles for working with requirements

The International Requirements Engineering Board (IREB) defines nine principles for working with requirements that apply to all tasks, activities or practices¹:

1. Value-orientation: Requirements are a means to an end, not an end in itself.
2. Stakeholders: Requriements engineering is about satisfying the stakeholders’ desires and needs.
3. Shared understanding: Successful systems development is impossible without a common basis.
4. Context: Systems cannot be understood in isolation.
5. Problem – Requirement – Solution: An inevitably intertwined triple.
6. Validation: Non-validated requirements are useless.
7. Evolution: Changing requirements are no accident, but the normal case.
8. Innovation: More of the same is not enough.
9. Systematic and disciplined work: We can’t do without in requirements engineering.

There are a number of techniques that help to observe these principles. And there are a number of activities that result from them. “Systematic and disciplined work” is only mentioned as principle 9, but it forms the basis of the requirements engineer profession. Part of systematic work is configuring the process for the current project, selecting the most appropriate techniques and practices, and continuously engaging with the content.²

Questions in the context of requirements

There are a number of questions when dealing with desired scopes of functions. You can find answers to some of the questions in our blog:

• What are the best practices in preparing, conducting and following up on requirements workshops? Which questions help and how do you deal with conflicts?
• Products and systems are often misused. What are the reasons for this and why are such misuse cases suitable for requirements elicitation?
• How can you reduce the scope of functions if the set of desired features is too large? Which criteria are suitable for this?
• Requirements analysis knows numerous methods and techniques. Which of these methods work remotely or online? And what additional tips are there?
• When exchanging requirements, there are technical and procedural challenges. How can we achieve a loss-free exchange?

We are sure you can think of more questions. Please contact us and we will try to answer your questions or publish corresponding articles.

Tools for working with requirements

There are various tools that offer useful services in practice. Here you will find a small list of tools without any claim to completeness and without evaluation:

• Polarion Requirements by Siemens
• DOORS Next by IBM
• Helix ALM by Perforce
• Visure Requirements
• TraceCloud
• SpiraTest by Inflecta
• Jira by Atlassian

Of course, the list can easily be extended, especially since there are numerous products that are used in organisations for working with stakeholder needs or defining system properties (e.g. MS Excel or MS Word), but originally have a different marketing focus.

[1] See IREB Syllabus CPRE Foundation Level
[2] See the nine principles in requirements engineering

Here you can find out which attributes are often used to record functional scopes.

If you like the article or would like to discuss it, please feel free to share it in your network. And if you have any comments, please do not hesitate to send us a message.

And here you will find additional information from our Smartpedia section:

What is a Walkthough?

t2informatik develops and modernises software as a service provider. Click here to learn more.