Karol Frühauf

Sharing My Doubts on Goals and Requirements

Goals are intended, Requirements are imposed

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.

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.