Software-Entwicklung | Methodik

Ziele vs. Anforderungen: Wo liegt der Unterschied?

Ziele und Anforderungen – zwei vermeintlich ganz verschiedene Begriffe. Aber der Schein trügt. Es gibt klare Zusammenhänge. Nur leider wird die Brücke zwischen den Zielen und den Anforderungen in vielen Projekten zuwenig oft geschlagen. Mit einer systematischen Herangehensweise in der Projektinitialisierung und in der Konzeptphase lassen sich viele in späteren Phase möglicherweise auftretende Missverständnisse vermeiden. Bewusste Design-Entscheide in den frühen Projektphasen helfen dabei.

Die Wirkungsziele eines Projekts geben uns einen Soll-Zustand vor. Wo wollen wir am Ende stehen? Was soll mit dem Projekt erreicht werden? Die Abwicklungsziele geben die Rahmenbedingungen vor. Was für Ressourcen stehen uns im Projekt zur Verfügung? Welchen Weg gehen wir zum Ziel? Die Projektziele, also Wirkungs- und -Abwicklungsziele, werden bei Projektstart festgelegt – normalerweise. Aber wofür stehen denn die Anforderungen? Und wann kommen die ins Spiel?

Anforderungen sind konkretisierte Ziele...

In einem Projekt gibt es nur wenige Ziele, zumindest im Vergleich zu den Anforderungen. Anforderungen gibt es meistens listenweise. Oft wird der Bezug zwischen Anforderungen und Zielen aber nicht wirklich hergestellt. Denn was sind denn eigentlich Anforderungen anderes als heruntergebrochene Ziele? Detailziele des Projekts. Konkretisierungen der Projektziele. In den frühen Projektphasen, z.B. in der Design- oder Konzeptphase, werden die Anforderungen erarbeitet. Dies ist Teil der Projektdisziplin "Requirements Engineering". Und die Ausgangslage dafür bilden eben die Projektziele. Dies zumindest die Theorie.

...und Ziele sind abstrahierte Anforderungen

Schauen wir uns dies noch etwas genauer an. Drehen wir die Zeitachse um und gehen zurück von der Anforderungsliste zu den Zielen. Die Ziele sind im Prinzip die Zusammenfassung der Anforderungen und bilden eine höhere Abstrahierungsebene. Eigentlich sind Ziele und Anforderungen dasselbe. Einfach auf unterschiedlichen Flughöhen oder Betrachtungsebenen. Ein Beispiel verdeutlicht dies. Nehmen wir an, wir möchten ein Softwaresystem bauen, welches uns ermöglicht, unsere Personalressourcen besser zu planen (ein Projektwirkungsziel). Und es soll zudem nicht mehr als CHF 200'000 kosten und bis in einem Jahr eingeführt sein (zwei Projektabwicklungsziele). Dies sind wohl eher Projektziele aus Sicht des Managements (hohe Flughöhe).

Der Projektleiter und sein Projektteam werden wohl mit diesen Managementzielen noch nicht ganz glücklich sein: Was heisst denn konkret "Personalressourcen besser planen können"? Und was heisst "bis in einem Jahr eingeführt"? Das Projektteam muss das genauer wissen und diese Ziele auf die eigene Flughöhe herunterbrechen. Dieses Konkretisieren geschieht in den ersten Projektphasen. Besser könnte z.B. heissen, dass man schneller einen Überblick über bestehende Ressourcenauslastungen erhält. Oder dass man den Ressourcenbedarf im System anmelden kann. Noch konkreter: Das System soll einem Abteilungsleiter per Knopfdruck die Auslastungskurven seiner Mitarbeiter über die nächsten 3 Monate grafisch darstellen. Das entspricht in der Welt der Software-Entwicklung in etwa einer User Story oder einem Use Case. (Für diese grobe Betrachtungsweise soll diese Analogie hier genügen.)

Ziele sind das WAS, Anforderungen das WIE

Beim Herunterbrechen der Projektziele auf Anforderungen im Rahmen des Requirements Engineering wird einem schnell klar, dass es für viele Ziele mehrere Konkretisierungen geben kann. Das Ziel "besser" kann als "schneller", "übersichtlicher" oder auch "kostengünstiger" verstanden werden. Das sind unterschiedliche Lösungsansätze (Designs) für die Erreichung eines Ziels. Somit muss in dieser Projektphase ganz viel entschieden werden: Jedes Ziel (WAS) kann mit verschiedenen Lösungen (WIE) erreicht werden. Und jemand muss in dieser Phase konkret festlegen, welchen dieser Lösungsansätze man weiterverfolgt. Dies sind Design-Entscheide, die übrigens oftmals auch schleichend und nicht wirklich bewusst im Projekt gefällt werden.

Vom Ziel über den Design-Entscheid zur Anforderung, ad infinitum

Wenn die Projektziele (WAS) einmal mittels Design-Entscheiden in die Form von Anforderungen (WIE) umgewandelt sind, dann kann man das Ganze natürlich wiederholen. Diese Anforderungen können nun ihrerseits wiederum als Detailziele angeschaut werden. Denn was sind Anforderungen anderes als konkretisierte Ziele? Also lassen sich diese noch weiter konkretisieren. Zurück in unserem Beispiel heisst das: Die obige User Story kann weiter konkretisiert werden. In der Software-Entwicklung würde man hier wohl ein Screen Design zeichnen, das darstellt, wo der User welchen Button drücken kann, um dann ein Balkendiagramm etc. zu erhalten.

So genau wollen wir dieses Beispiel hier aber nicht weiterführen. Es geht vielmehr darum, dass wir feststellen, dass das Herunterbrechen von Zielen auf Anforderungen im Prinzip mehrmals wiederholt werden kann. Jede Anforderung (WIE) kann auf einer tieferliegenden Ebene wieder als als Ziel (WAS) betrachtet werden, welches somit seinerseits noch weiter in Einzelheiten aufgeschlüsselt werden kann. Das könnte man beliebig wiederholen. Bei der Software-Entwicklung könnte man die Ziele mit Design-Entscheiden soweit herunterbrechen, dass am Ende Pseudo-Code oder gar lauffähiger Code herausschaut und die Anforderungen somit so konkret sind, dass man die fertige Lösung fast schon vor sich hat. Auf dieser Detailebene spricht man dann häufig von technischer Spezifikation. Aber im Grunde genommen sind das einfach sehr, sehr detaillierte Ziele.

Über den Autor


Managing Director INTRASOFT AG

Dr. Daniel Hösli ist Managing Director und Lead Consultant bei der INTRASOFT AG, deren SaaS-Lösung PQFORCE die führende Plattform für agile, projekt-orientierte Unternehmensführung ist. Er ist seit 15 Jahren täglich mit dem Aufbau von Projektmanagementsystemen in beratender und projektleitender Funktion tätig - organisatorisch wie technisch - und hat so die Erfahrung aus unzähligen Kontakten und Aufgabenstellungen aus den unterschiedlichsten Unternehmungen und verschiedenen Managementebenen.

Nicht verpassen

Mit PQFORCE Insights bekommen Sie unsere neuesten Nachrichten, Best Practices, Tipps und Angebote direkt in Ihre Mailbox geliefert.
Wir werden Ihnen nur relevante, spamfreie E-Mails senden.
Sie können sich jederzeit mit einem Klick wieder abmelden.
Jetzt ausprobieren