Goals vs. requirements: What is the difference?
Goals and requirements - two supposedly quite different concepts. But appearances are deceptive. There are clear connections. Unfortunately, the bridge between goals and requirements is not built often enough in many projects. With a systematic approach in project initialization and in the concept phase, many misunderstandings that may arise in later phases can be avoided. Conscious design decisions in the early project phases help.
The impact goals of a project give us a target state. Where do we want to be at the end? What should be achieved with the project? The implementation goals provide the framework conditions. What resources are available to us in the project? Which way do we go to reach the goal? The project goals, i.e. impact and execution goals, are defined at the start of the project - usually. But what do the requirements stand for? And when do they come into play?
Requirements are concrete goals...
In a project there are only a few goals, at least compared to the requirements. Requirements usually exist in lists. Often, however, the relationship between requirements and goals is not really established. After all, what are requirements other than broken down goals? Detailed goals of the project. Concretization of the project goals. In the early project phases, e.g. in the design or concept phase, the requirements are worked out. This is part of the project discipline "Requirements Engineering". And the project goals form the starting point for this. At least this is the theory.
...and goals are abstracted requirements
Let's look at this a little more closely. Let's turn the timeline around and go back from the requirements list to the goals. The goals are basically the summary of the requirements and form a higher level of abstraction. Actually, goals and requirements are the same thing. Just at different altitudes or levels of consideration. An example illustrates this. Let's say we want to build a software system that allows us to better plan our human resources (a project impact goal). And it should also cost no more than CHF 200,000 and be implemented by one year (two project execution objectives). These are probably more project goals from a management perspective (high altitude).
The project manager and his project team will probably not yet be entirely happy with these management goals: What specifically does "be able to plan human resources better" mean? And what does "introduced within a year" mean? The project team needs to know this more precisely and break these goals down to their own flight level. This concretization happens in the first project phases. Better could mean, for example, that an overview of existing resource utilization is obtained more quickly. Or that one can register resource requirements in the system. Even more concrete: The system should graphically show a department manager the workload curves of his employees over the next 3 months at the push of a button. In the world of software development, this corresponds somewhat to a user story or a use case. (This analogy should suffice for this rough approach).
Goals are the WHAT, requirements the HOW
When breaking down the project goals to requirements in the context of requirements engineering, it quickly becomes clear that there can be several concretizations for many goals. The goal "better" can be understood as "faster", "clearer" or also "more cost-effective". These are different approaches (designs) for achieving a goal. Thus, a lot of decisions have to be made in this phase of the project: Each goal (WHAT) can be achieved with different solutions (HOW). And someone has to decide in this phase which of these solutions will be pursued. These are design decisions that are often made insidiously and not really consciously in the project.
From the goal to the design decision to the requirement, ad infinitum
Once the project goals (WHAT) have been transformed into the form of requirements (HOW) by means of design decisions, the whole process can of course be repeated. These requirements can now in turn be viewed as detailed goals. After all, what are requirements but concretized goals? So they can be concretized even further. Back to our example, this means: The above user story can be further concretized. In software development, one would probably draw a screen design here that shows where the user can press which button, in order to then obtain a bar chart, etc. This is how the user story can be further concretized.
However, we do not want to continue this example in such detail here. Rather, the point is that we see here that the breakdown of goals into requirements can, in principle, be repeated several times. Each requirement (HOW) can be seen as a goal (WHAT) on a deeper level, which in turn can be further broken down into details. This could be repeated at will. In software development, the goals could be broken down with design decisions to such an extent that pseudo-code or even executable code emerges at the end and the requirements are thus so concrete that the finished solution is almost already in front of you. At this level of detail, one often speaks of technical specifications. But basically, these are simply very, very detailed goals.
About the author
Dr. Daniel Hösli is Managing Director and Lead Consultant at INTRASOFT AG, whose SaaS solution PQFORCE is the leading platform for agile, project-oriented business management. He has been involved in the development of project management systems on a daily basis for 15 years in a consulting and project management capacity - both organizationally and technically - and thus has the experience from countless contacts and tasks from a wide variety of companies and different management levels.