Ways to contributeContribute to the RE Magazine Search Authors
1Write an articleMore Information
2Place an advertisementMore Information
3Sponsor the magazineMore Information

Sharing My Doubts on Goals and Requirements

Goals are intended, Requirements are imposed

Written by Karol Frühauf
Estimated Reading Time: 3 minutes, 59 seconds
Advertise with usAdvertisement
Best for System & Software Development

objectiF RPM – Requirements Engineering and Agile Development

Best for System & Software Development

objectiF RPM – Requirements Engineering and Agile Development


A popular discussion in requirements engineering courses is about the difference between goals and requirements. One view is that goals are requirements on the highest level of abstraction. My question: Why should you call a requirement differently depending on the level of abstraction? A requirement is a requirement. I say this because I am convinced that it is only worth introducing a new term if it carries a different meaning, if it denotes a different concept.

Let us first look at the definition of a requirement. I prefer the definition by Alan Davis from [1]: “A requirement is an externally observable characteristic of a desired entity.” It provides two important statements about a requirement:

  1. it shall be observable (on the entity as a black box) whether the requirement is fulfilled and
  2. it is a required characteristic of an entity that does not yet exist, of a future entity.

A desired entity can be a system/product, an organisation, a business process or something similar. For the current discussion, I restrict requirements to those concerning desired systems/products. Justification follows in the next commentary.

Goals are defined in [2] as follows: “Goals are a stakeholder’s (e.g. a person’s or an organisation’s) description of a characteristic property of the system to be developed or the development project.” I share the view that goals are what people or organisations intend to achieve. Things have no goals, only human beings have. But I doubt that it is useful to express goals as properties of the desired system or of the project developing it. This is just another phrasing of the view that goals are requirements on the highest level of abstraction and, consequentially, requirements are refinements of goals. Until which level of refinement should we talk about goals? On which level should we start to talk about requirements?

I offer another view. Goals are a stakeholder’s (i.e. a person’s or an organisation’s) description of the benefit intended in the context of the system; this change is carried out in a project that may also, but does not need to, deliver an IT system. Typical intended benefits are: a business process shall be executed faster, with less resources, with more consistent quality, etc. This can be achieved by organisational measures and/or with improvement of the IT systems used. These systems must possess characteristics that contribute to the achievement of the stakeholder’s goals. That is what we require from them.

This view has the advantage that it helps us to evaluate requirements. If the implementation of a requirement contributes to the achievement of at least one goal, then it is justified to state it. If the implementation of a requirement does not contribute to the achievement of any goal, then it is not justified. Perhaps not justified yet. It can be that some valuable goal is not stated yet.

I have no doubt that this view is helpful.

We express the change/improvement in system context that we want to achieve in measurable goals. In most of the cases we will modify or develop IT systems to achieve these goals. We express the desired characteristics of these IT systems as requirements. And we check for every requirement whether its implementation contributes to the achievement of goals. This is useful. Besides the system context diagram with actors and external interfaces, the check against goals is the only means to evaluate the justification of requirements. I don’t know any other criteria to objectively decide whether a requirement is justified or not. But I am happy to learn about them if I missed any. With the definition of goals according to [2], I can’t see any benefit in distinguishing between goals and requirements.

So far I only dealt with IT projects that realise business process changes. But this concept is beneficial also for product development projects. There, the goals are seldom business process related. They usually express intended market achievements with the modified or new product. The goals are characteristics of the market that should be attacked: geography, segment, population, etc. It is possible, again, to evaluate the justification of requirements against goals expressed in such terms.

Figure 1 illustrates both cases for goals and requirements.

Figure 1: Goals related to business process or market; requirements to the IT system or product
Figure 1: Goals related to business process or market; requirements to the IT system or product

In summary, using the two terms goals and requirements is only justified if they denote different concepts. I suggest that goals should be statements about the desired system context, while requirements are statements about the desired system. Systems have no goals, people and organisations have goals. This concept provides a valuable means to check whether a requirement is justified for the considered IT system (or product): if its implementation contributes to the intended change in the system context, then it is.

Karol Frühauf

P.S: Thanks to Oliver Hoeffleur/INFOGEM who shared first my doubts and helped me to sharpen them. I also thank the reviewer for the suggested generalisation of goals as statements about the system context.

References and Literature

  • [1] Alan M. Davis: Just Enough Requirements Management. Dorset House, 2005, 
ISBN 0-932633-64-1.
  • [2] Klaus Pohl, Chris Rupp: Requirements Engineering Fundamentals. Rooky Nook Inc., 2011, 1. Edition, ISBN 98-1-933952-81-9.

Give feedback


From Gerhard Schwab

Goals are the reason why projects are initiated - requirements are, what systems must fulfill

I totally agree with this view. I use the terms "goal" and "requirement" in a very similar way when setting up a project:

Goals describe, WHY we are doing this PROJECT, i.e. what do we want to achieve with it, whereas:

Requirements describe WHAT the SYSTEM must be capable of, i.e. which features and characteristics it must have in order to support these goals.

I think, this is quite consistent to your view.

Regards, Gerhard

From Karol Frühauf – Author

Yes, it is.

From David Gelperin

Requirements can be viewed as verifiable characteristics of a work product that are needed for success. There are 3 types of requirements from this perspective: functional, quality goals, and constraints. There are 2 types of quality goals: external e.g., usability, and internal e.g., understandability.

There are many differences between functional requirements and quality goals. One is that quality goals may conflict with one another e.g., usability and security. This means that all the (initial) goals of all the relevant qualities may not be feasible. Ian Alexander speaks about "optioneering" i.e., the need to find acceptable tradeoffs to create a feasible set of quality goals. After successful optioneering, the quality goals might be thought of as "quality requirements".

A freely downloadable quality model consistent with this perspective can be found at http://www.quality-aware.com