How to set goals and requirements


"A goal is the object or aim of an action ... usually within a specified time limit." (Locke, E.A. & Latham, G.P. (2002). Building a Practically Useful Theory of Goal Setting and Task Motivation: A 35-Year Odyssey, American Psychologist, 57, page 705)


Definition:  A goal is a desired future result toward which effort is directed. (For the sake of simplicity, I do not distinguish between goal, objective, aim and target.)


A desired future result toward which no effort is directed is a whish, not a goal. A goal (the desired future result) can be broadly determined or specific. If someone has the goal to become rich, he can make a great effort to reach that goal although it is not precisely defined. When several people work together to achieve a goal, it is advisable to define that goal precisely.


A goal is not an isolated goal value, but it is a situation. A situation is a system at a point in time. Just as there are simple and complex systems, there are simple and complex goals. "I want to go to the kitchen and drink a glas of water." This is a simple goal and the answer to the question "Have you achieved your goal?" can normally be yes or no. For a complex goal, the question cannot be answered with a simple yes or no, because in a complex goal situation there are always several elements that are related to the goal. Here is an example:


A student sets himself the goal to get a very good grade in an exam. He prepares day and night for the exam for 7 weeks. He reaches his goal and gets a very good grade in the exam. Unfortunately, his girlfriend is annoyed with him because he hasn't spent any time with her and she separates from him. In addition, he learned too hard and he is sick for 4 weeks after the exam. He should have considered his goal as a goal situation. A complex goal should be set in a comprehensive way: a very good grade without annoying the girlfriend and damaging the health.


The prerequisite to anticipate the goal situation is that we understand the current unsatisfactory situation. The main question is: Why is this situation unsatisfactory? A superficial answer to this question would not be sufficient to set a goal for the solution of a complex problem. An unsatisfactory situation has deficiencies. Deficiencies represent opportunities for improvement. For example, if the growth of a business is 3% and 5% would be possible, then 3% growth is a deficiency.


To understand an unsatisfactory situation, we first need to identify the main elements responsible for the deficiencies. In a second step we must examine the rules and characteristics causing these deficiencies. Then we understand what is positive and negative about the current situation. It is important to understand both because when we improve the negative, we must not damage the positive.


"In the field of user experience understanding negative experiences and the conditions in which they arise may prove very important in order to further develop products iteratively based on the user experience evaluations."

(Timo Partala, Aleksi Kallinen, Understanding the most satisfying and unsatisfying user experiences: Emotions, psychological needs, and context, Interacting with Computers, Volume 24, Issue 1, January 2012, page 26)


"It is good engineering practice to state the problem in terms of the top-level function that the system must perform. However, it is better to state the problem in terms of the deficiency that must be ameliorated. This stimulates consideration of more alternative designs." (, 22.08.20, page 3)


The whole process of goal setting looks like this:

How to set goals and requirements - the goal setting process - goal-oriented requirements

"Typically, the current system under consideration is analyzed in its organizational, operational and technical setting; problems [deficiencies] are pointed out and opportunities are identified; highlevel goals are then identified and refined to address such problems and meet the opportunities; requirements are then elaborated to meet those goals. ... Goals may be formulated at different levels of abstraction, ranging from high-level, strategic concerns ... to low-level [specific concerns]" (A. van Lamsweerde, Goal-Oriented Requirements Engineering: A Guided Tour, Proceedings of the 5th IEEE International Symposium on Requirements Engineering, IEEE Computer Society, 2001, page 249, 250)


Specific goals can be called requirements (in software and systems engineering) or SMART goals (specific, measurable, achievable, relevant and time-bound). A goal is a desired future result toward which effort is directed. A requirement is a capability, a function or a property of a desired result.


"I think in terms of three levels of requirements ... At the top are the business requirements, representing the high-level objectives ... The second level addresses the user requirements, which describe the tasks that users must be able to perform using the new product. [The third level are specific functional requirements.]" (K. E.Wiegers. Karl Wiegers describes 10 requirements traps to avoid. Software Testing and Quality Engineering, 2(1), 2000, page 1-2)


There is another aspect that plays a role in setting a goal. We normally want to achieve our goals at a certain point in time with as little effort as possible. So what would be the perfect goal? A goal would be perfect if it satisfies all aspects of the goal situation as well as possible and if it can be achieved at a certain point in time with as little effort as possible. The following figure shows the dependence of the quality of the result on the effort. It shows that it is impossible to achieve a perfect result. So setting a perfect goal is pointless. Goals and requirements must match the available budget and schedule.

How to set a goal? How to set an optimal goal? -

The optimal goal for a complex problem always lies within an optimal range.


"... there is no single optimal solution to complex systems problems. Most system designs have several performance and cost criteria. Systems Engineering creates a set of alternative designs that satisfies these performance and cost criteria to varying degrees. Moving from one alternative to another will usually improve at least one criterion and worsen at least one criterion (i.e., there will be trade-offs). None of the feasible alternatives is likely to optimize all the criteria (Szidarovszky, Gershon, and Duckstein, 1986)." (, 22.08.20, page 3)

Alternativ methods - different goal situations - different goal systems -

So far we do not know the solution of the problem. We do not know which method to apply to reach the goal. Different methods result in different goal situations (goal systems). Therefore all goals and requirements are still uncertain.


"... if a project applies a rigid development approach and fails to recognise uncertainty and the need for evolution, it can actually drive additional costs into a project. A common reason for project problems is insufficient management of changing requirements during all stages of the project life." (Nolan, A., Abrahao, S., Clements, P. and Pickard, A. 2011. Managing Requirements Uncertainty in Engine Control Systems Development. Proceedings of the 19th International Requirements Engineering Conference. IEEE, page 259)


Nevertheless, at this stage we are making a list of possible goals and requirements and we prioritize them. This list will help us to decide what is the right method to solve the problem.


"One characteristic of excellent requirements is that they are explicitly prioritized. When customer expectations are high, timelines are short, and resources are limited, you want to make sure the product contains the most essential functions. ... A common approach to prioritization is to group requirements into three priority categories. Essential [must have] ... Conditional [should have] ... Optional [nice to have] ... Keep the prioritization as simple as possible to help you make the necessary development choices." (K. Wiegers, “First things first: prioritizing requirements,” Software Development, vol. 7, no. 9, pp. 48–53, 1999.)

How to compare different systems -

Even if the goals and requirements are still uncertain, we need them to be able to assess the result quality later. The figure above can be interpreted in two ways:

  1. We compare two possible goal systems and find that System 2 gives us a better result quality.
  2. We compare the current system 1 with the goal system 2 and see that the desired result quality is significantly higher than the current one.

Example: A pizzeria buys a new oven. With this new oven (system 2) more and better pizzas can be baked than with the old oven (system 1).


The second obstacle we may encounter on our way to solving a problem is the uncertainty of our goals and requirements.


Continue with the next step of the problem-solving process:

How to be creative and find or have new ideas for the solution