How to set goals and requirements

Key message: Perfect is impossible. Optimal goals and requirements have a high quality and can be achieved efficiently.

 "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, 2002, 57, p. 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 can be broadly or precisely defined. 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. A system is a set of interrelated elements.

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. 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, p. 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." (http://prod.sandia.gov/techlib/access-control.cgi/1996/961620.pdf, 22.08.20, p. 3)

The whole process of goal setting looks like this:

"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]" (van Lamsweerde, A. (2001). Goal-Oriented Requirements Engineering: A Guided Tour, Proceedings of the 5th IEEE International Symposium on Requirements Engineering. IEEE Computer Society, 2001, p. 249-250)

Specific goals can be called requirements (in software and systems engineering) or SMART goals (specific, measurable, achievable, relevant and time-bound).

Definition:  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.]" (Wiegers, K. E. (2000). Karl Wiegers describes 10 requirements traps to avoid. Software Testing and Quality Engineering, 2000, 2(1), p. 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. A nearly perfect target would only be possible with a great deal of effort. Goals and requirements must match the available budget and schedule. Too demanding goals create stress and the resulting pressure easily causes mistakes.

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)." (http://prod.sandia.gov/techlib/access-control.cgi/1996/961620.pdf, 22.08.20, p. 3)

It is important to look for alternative designs (= goal systems). For this search, the question of the perfect (ideal) goal is a good starting point. What would the ideal goal look like without thinking about the effort required to achieve it? If we then leave out the one or the other of this ideal goal, we arrive at alternative goals. In the same way we should ask ourselves, "If we change the current situation/system, what could happen in the worst case?"

If we change an existing system just a little, it will result in a small improvement. The goal will only slightly shift up on the curve. However, a fundamental change can result in a completely new system with a greatly improved result quality.

The figure above can be interpreted in two ways:

1. We compare two possible designs 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 compared to the old oven (system 1).

For each alternative design, we need a different method to achieve the desired goal system (the desired goal situation).

At the moment we cannot decide which of the alternative goals is the optimal one for us, because we do not know if there is an applicable method for each of them. Each of the alternative goals is 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, p. 259)

Nevertheless, at this stage we are making a list of possible goals and requirements and we prioritize them.

"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." (Wiegers, K. (1999). "First things first: prioritizing requirements". Software Development, 1999, vol. 7, no. 9, p. 48–53)

Even if the goals and requirements are still uncertain, we need the list to evaluate our ideas for solving the problem and to be flexible if the requirements change.

"The majority of software projects experience significant requirements churn: changes in the requirements in the late stages of the project. ... This leads to two very different reactions. One route is to put more effort into the requirements process itself. ... Another school contends that requirements churn is unavoidable, that it's too difficult for many projects to stabilize requirements sufficiently to use a predictive plan. ... This school of thought advocates adaptive planning, ... a planning approach that treats change as a constant in a software project. This change is controlled so that the project delivers the best software it can; but although the project is controllable, it is not predictable." (Fowler, M. (2004) UML destilled. Addison-Wesley, Boston, p. 23)

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

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