Requirements represent the stakeholders’ requirements for a system, consider the problem to be solved, and are written in a natural or semi-formal language. These requirements form the basis and may not be subject to permanent, short-term changes. Due to the different perspectives on the basis of various stakeholder groups, ambiguity and contradictions may initially prevail in the recording of the requirement. The requirements are the basis for project planning, risk management, acceptance tests, acceptance and change management
According to IEEE-STD-1220-1998, a requirement is defined from the following:
- Product or process
- Eligible criteria (eg performance, security, maintainability, …)
- Clarity of the statement
- Testability or measurability
- Explanation of the critical factors of the product and how to test them and under what circumstances are accepted
- Clarity of origin (customer, guidelines, etc.)
Within the scope of requirements engineering, the three core activities documentation, extraction and agreement can be derived from the vision and the context of the system within an iterative process. These are supported by validation and management activities to address challenges and risks.
System Engineering not only describes the requirements of a product alone, but also considers its internal and external environment in which it is to be embedded.
In line with system engineering, requirements engineering also deals with the description, linking and analysis, the qualification of requirements and their communication, as well as the degree of abstraction. The goal of requirements engineering is not only to evaluate the correct requirements for a product, but rather a method to create a holistic view and deliver the right product at the right time.