What is Requirements Engineering?

We can say a system is badly designed if it is not well suited to the purpose for which it was intended. If the system is supposed to make some job more efficient, and it does not, then it is a poor system. If it is supposed to make a risky activity (like flying) safer, but does not, then it is a poor system. Turning this around, we define quality in terms of fitness-for-purpose. This means that
we cannot assess quality as a measure of software by itself; we can only assess quality when we consider the software in the context of a set of human activities.

In other words, software on its own cannot be said to be of ‘high quality’ or of ‘low quality’, because quality is an attribute of the relationship between software and the purposes for which it is used. This means that requirements
engineering plays a critical role in our understanding and assessment of software quality. The purpose for a particular system, and hence the key quality measures, may appear to be self-evident. For example, it is hard to imagine a purpose for an aircraft flight control system that does not include flying from one place to another as safely as possible. But human activities are complex, and so it is rare to find a system that has a single, unchanging purpose. Most systems have multiple purposes, and those purposes change over time. The different purposes of a system may be associated with different stakeholders, or with the different roles that the stakeholders play.

A systematic investigation of the purpose for any proposed software-intensive system is therefore essential. If we do not fully understand the purpose of a computer system, we cannot assess its quality. Further, if we do not understand the intended purpose of a system that we are trying to design, then we can only ever achieve good quality by accident.