Wenn die Toolentscheidung zum Studienprojekt wird und warum das selten gut ausgeht

Warum überhaupt ein RM-Tool?

Bevor wir über die Auswahl sprechen, sollten wir den Nutzen eines solchen Tools verstehen. Requirements Management (RM) bildet die Basis einer strukturierten, nachvollziehbaren und effizienten Produktentwicklung – unabhängig davon, ob es um Software, Maschinenbau oder regulierte Branchen wie Medizintechnik oder Automotive geht.

Ein modernes RM-Tool ist dabei weit mehr als eine digitale Ablage für Dokumente. Es unterstützt zum Beispiel dabei:

• Anforderungen zentral zu erfassen, zu strukturieren und zu versionieren statt sie in verstreuten Dateien, Tabellen oder E-Mails zu verlieren.
• Beziehungen und Abhängigkeiten transparent zu machen damit klar wird, welche Änderungen welche Bereiche betreffen.
• Qualitätsprüfungen und Nachverfolgbarkeit zu gewährleisten zum Beispiel, ob alle Anforderungen getestet und genehmigt sind.
• Kommunikation und Zusammenarbeit zu fördern indem alle Beteiligten im selben System arbeiten und dieselben Informationen sehen.

Kurz: Ein RM-Tool ist die zentrale Schaltstelle im Entwicklungsprozess. Es sorgt dafür, dass alle Beteiligten vom Requirements Engineer über die Entwickler bis zur Qualitätssicherung strukturiert, nachvollziehbar und effizient zusammenarbeiten.

‍

Der klassische Fall: „Such doch mal ein Tool raus“

Viele Unternehmen erkennen den Nutzen und wollen ein RM-Tool einführen. Doch anstatt die Auswahl als strategisches Projekt zu behandeln, wird sie häufig an eine einzelne Person, oft einen Studenten oder eine Studentin, delegiert.

Typische Aufgabenstellungen klingen dann so:

• „Recherchiere mal 10 bis 15 Tools.“
• „Vergleiche die Funktionen in einer Excel-Tabelle.“
• „Erstelle daraus eine Shortlist.“
• „Empfiehl uns das beste Tool.“

Diese Vorgehensweise wirkt auf den ersten Blick strukturiert und objektiv. In Wahrheit basiert sie aber oft auf falschen Annahmen und führt deshalb in der Praxis nur selten zu einer wirklich brauchbaren Entscheidung.

‍

Typische Fallstricke bei dieser Herangehensweise

Fokus auf Funktionen statt auf reale Probleme

In vielen studentischen Marktanalysen werden Tools anhand von Feature-Listen miteinander verglichen. Es entsteht eine große Excel-Tabelle, in der Funktionen wie „Workflow-Management“, „Nachverfolgbarkeit“ oder „Testfallableitung“ abgehakt werden, je nach dem, ob sie im Tool vorhanden sind oder nicht.

Das Problem dabei: Diese Liste bildet bestenfalls den Funktionsumfang, aber nicht den tatsächlichen Nutzen eines Tools ab. Denn dieselbe Funktion kann in zwei Tools völlig unterschiedlich umgesetzt sein von „kaum benutzbar“ bis „intuitiv und durchdacht“.

Studierenden fehlt in der Regel das Erfahrungswissen, um diese Unterschiede realistisch einzuschätzen. Sie sehen oft nur, ob eine Funktion existiert, nicht wie sie sich im Alltag bewährt. Und am wesentlichsten: sie kennen die internen Probleme der Organisation wenn überhaupt meist nur aus Gesprächen, nicht aber aus jahrelanger, praktischer Erfahrung. Deshalb geraten Tools mit umfangreichem Marketing oft in die engere Auswahl, obwohl sie für die konkreten Herausforderungen des Unternehmens womöglich ungeeignet sind.

Unklare Zielsetzung durch vagen Auftrag

Ein weiterer häufiger Fehler: Die Auswahl erfolgt oft ohne klar definierte Zielsetzung. Was genau soll das Tool leisten? Soll es lediglich Anforderungen dokumentieren? Oder auch deren Versionierung, Prüfung, Verlinkung mit Testfällen, Wiederverwendung oder Genehmigung unterstützen?

Wer später mit dem Tool arbeitet, ist ebenfalls oft unklar. Geht es nur um eine Arbeitsunterstützung für Requirements Engineers oder um eine Plattform für alle Beteiligten im Entwicklungsprozess, von der Fachabteilung über die Entwicklung bis hin zum Test?

Studierende sind in solchen Fällen meist auf sich allein gestellt. Sie erhalten vage Aufgabenstellungen wie „Sichte doch mal den Markt“ aber keine klaren Vorgaben, welche Ziele eigentlich erreicht werden sollen.

Diese Zielklärung wäre jedoch essenziell, um sinnvolle Auswahlkriterien überhaupt definieren zu können. Ohne diese Klarheit wird dann oft einfach gesammelt, was gesammelt werden kann mit wenig Bezug zur tatsächlichen Notwendigkeit.

Vergleich von Äpfeln mit Birnen

Ohne ein tiefes Verständnis von Requirements Engineering und seiner Abgrenzung zu angrenzenden Disziplinen (wie Projektmanagement oder Issue-Tracking) werden oft völlig unterschiedliche Toolarten in einen Topf geworfen.

So erscheinen in den Vergleichslisten neben echten RM-Tools plötzlich auch Werkzeuge wie Jira, Confluence, Excel, Trello oder DMS-Systeme, weil sie irgendwie auch mit Anforderungen arbeiten können.

Der Vergleich wird dadurch beliebig und die Aussagekraft der Bewertung sinkt gegen null. Studierenden fehlt hier meist das methodische Hintergrundwissen, um zu erkennen, welche Tools tatsächlich dafür gedacht sind, Anforderungen strukturiert zu managen, und welche Tools eher Notlösungen oder Teilkomponenten darstellen.

Ohne diese fachliche Abgrenzung besteht die Gefahr, dass das „gefundene“ Tool gut aussieht, aber den eigentlichen Anforderungen an ein RM-Tool überhaupt nicht gerecht wird.

Keine realistische Bewertung

Selbst wenn Zielsetzung und Toolkandidaten klar wären: Studierende haben in der Regel keine echte Projekterfahrung in der Organisation. Sie wissen nicht, wie Anforderungen heute erfasst und gepflegt werden, welche Friktionen es im Alltag gibt, wer wie mit Anforderungen arbeitet und wo typischerweise Probleme auftreten.

Das führt dazu, dass Tools häufig anhand ihrer Benutzeroberfläche, Webpräsenz oder vorhandener Demos bewertet werden, aber nicht danach, wie sie im konkreten Projektkontext funktionieren würden.

Gerade im RM-Bereich ist jedoch entscheidend, wie gut sich ein Tool in die tatsächlichen Prozesse und Rollenmodelle des Unternehmens integriert. Diese Bewertung kann nur vornehmen, wer diese Prozesse kennt und die Auswirkungen eines Tools auf tägliche Arbeitsabläufe einschätzen kann.

Keine Verankerung in der Organisation

Und selbst wenn eine Empfehlung ausgesprochen wird: wie geht es dann weiter? Oft scheitert die Umsetzung daran, dass die Entscheidung nicht mit den internen Stakeholdern abgestimmt ist. Die Geschäftsführung, die IT oder die Fachabteilungen kennen die Auswahlkriterien nicht, haben die Tools nie gesehen und verstehen nicht, warum gerade dieses Tool empfohlen wurde.

Die Empfehlung läuft ins Leere. Sie wird „zur Kenntnis genommen“, aber nicht weiterverfolgt, weil sie intern weder Rückhalt noch Anschlussfähigkeit besitzt.

Hier zeigt sich ein grundlegendes Problem: Die Toolauswahl wurde ausgelagert, an eine Einzelperson, ohne echte Einbindung, ohne Entscheidungsbefugnis und ohne strategisches Mandat. Ein solches Vorgehen kann keine nachhaltige Veränderung bewirken.

‍

Warum der Denkfehler dahinter gefährlich ist

Die Entscheidung, eine Toolauswahl „mal eben auszulagern“ – sei es an Studierende, an die IT oder an eine einzelne Fachperson entspringt oft einem nachvollziehbaren Wunsch:

Man möchte sich selbst entlasten.

„Wir haben intern keine Zeit dafür“, „Wir kennen uns mit Tools nicht gut genug aus“, „Lass uns das erstmal sondieren und dann später entscheiden“. Solche Sätze hören wir oft. Dahinter steckt meist das Bedürfnis, das Thema strukturiert angehen zu wollen, aber ohne es gleich zur Chefsache zu machen.

Doch genau das ist der Denkfehler: Die Auswahl eines RM-Tools ist keine rein operative, sondern eine strategische Entscheidung. Sie betrifft nicht nur die Frage, welche Software genutzt wird, sondern wie ein Unternehmen künftig mit Anforderungen arbeitet. Und damit verändert sie Prozesse, Rollen, Verantwortlichkeiten und oft auch die Unternehmenskultur.

Im Gegensatz zu typischen Office-Tools ist ein RM-Tool nicht einfach ein Werkzeug, das man installiert, schult und dann benutzt. Es greift tief in die Abläufe der Produktentwicklung ein:

• Es verändert, wie Anforderungen erfasst, diskutiert und freigegeben werden.
• Es legt offen, wer Entscheidungen trifft und wer wofür verantwortlich ist.
• Es macht sichtbar, wo Unklarheiten, Redundanzen oder Zielkonflikte bestehen.

Damit wirkt ein RM-Tool wie ein Brennglas und zwar auf gute wie auf schlechte Prozesse. Und genau deshalb braucht es für die Auswahl ein hohes Maß an interner Auseinandersetzung:

Welche Arbeitsweisen wollen wir beibehalten? Wo wollen wir effizienter werden? Wer muss künftig zusammenarbeiten? Was sind unsere Prioritäten?

Wird diese Auseinandersetzung vermieden und die Verantwortung stattdessen an eine Einzelperson oder gar eine externe Kraft übergeben, fehlt die wichtigste Zutat für eine erfolgreiche Tool-Einführung: das gemeinsame Verständnis.

Denn ohne diese interne Klarheit…

• wird kein Tool die bestehenden Probleme lösen – weil sie gar nicht klar benannt wurden,
• wird kein Tool wirklich akzeptiert – weil es nicht zu den tatsächlichen Bedürfnissen passt,
• wird keine Entscheidung getragen – weil sie niemand wirklich verantwortet.

Was dann bleibt, ist ein hübscher Vergleichsbericht, eine theoretisch fundierte Empfehlung und die Realität, dass sich am Arbeitsalltag nichts ändert.

‍

Wie man es besser macht

Die gute Nachricht: Eine fundierte Auswahl eines Requirements Management-Tools ist absolut machbar – auch ohne riesige Budgets oder monatelange Marktanalysen. Entscheidend ist jedoch, dass die Verantwortung dafür dort liegt, wo auch die Auswirkungen ankommen: bei denjenigen, die mit dem Tool arbeiten werden und bei denjenigen, die die Prozesse verantworten.

Studierende können diesen Prozess sinnvoll unterstützen z. B. durch Recherchen, Prototypen oder Begleitdokumentation. Aber die Auswahl selbst sollte nie ohne Einbindung der Organisation und ihrer konkreten Herausforderungen erfolgen. Ein zielführender Auswahlprozess umfasst im Kern fünf Schritte:

1. Zuerst das Problem verstehen, nicht den Markt

Bevor überhaupt ein Tool betrachtet wird, muss klar sein: Was läuft heute nicht gut? Wo entstehen Reibungsverluste, Mehraufwände oder Missverständnisse?

Diese Fragen lassen sich nicht durch Internetrecherche beantworten, sondern nur durch Gespräche mit Beteiligten: mit Fachabteilungen, Entwicklern, Testern, Projektverantwortlichen.

Diese Problemorientierung ist entscheidend, um die Anforderungen an ein Tool nicht aus einer allgemeinen Feature-Liste abzuleiten, sondern aus konkretem Bedarf. Erst dann kann entschieden werden, welche Funktionen wirklich relevant sind und welche nicht.

2. Anwendungsfälle definieren statt Funktionen zählen

Statt eine lange Liste von Features zu vergleichen, sollten konkrete Szenarien formuliert werden, z. B.:

• Wie erfassen wir Anforderungen im Team?
• Wie verwalten wir Änderungen und Versionen?
• Wie prüfen wir die Qualität von Anforderungen?
• Wie erkennen wir Widersprüche oder doppelte Inhalte?
• Wie leiten wir Tests oder Spezifikationen daraus ab?

Diese sogenannten Use Cases helfen dabei, Tools im Hinblick auf Alltagstauglichkeit zu bewerten – nicht nur auf Papier, sondern anhand dessen, was im Unternehmen tatsächlich gebraucht wird.

3. Stakeholder frühzeitig und aktiv einbinden

Ein RM-Tool betrifft nicht nur eine einzelne Rolle. Es wird zum Dreh- und Angelpunkt für viele Beteiligte von der Produktidee über die Entwicklung bis hin zur Qualitätssicherung. Deshalb ist es unerlässlich, dass alle betroffenen Gruppen von Anfang an einbezogen werden:

• Was brauchen sie konkret?
• Wo hakt es heute?
• Was wäre aus ihrer Sicht ein Fortschritt?

Diese Perspektiven sind entscheidend und sie sorgen ganz nebenbei auch dafür, dass das Tool später akzeptiert wird, weil sich niemand übergangen fühlt.

4. Nicht vergleichen, sondern ausprobieren

Je nach Vorkenntnissen lassen sich meist schnell zwei bis drei passende Tools identifizieren. Diese sollten dann nicht nur in Broschüren studiert, sondern im Rahmen eines echten Projekts ausprobiert werden.

Dabei geht es nicht darum, möglichst viel zu testen, sondern möglichst realistisch. Ein gut vorbereiteter Pilot mit echten Anforderungen, echten Prozessen und echten Anwendergruppen liefert mehr Erkenntnis als jede 100-zeilige Vergleichsmatrix.

5. Die Entscheidung dort treffen, wo die Verantwortung liegt

Am Ende muss klar sein: Die Einführung eines RM-Tools ist eine strategische Entscheidung. Sie verändert Arbeitsweisen, Prozesse und Verantwortlichkeiten. Deshalb darf sie nicht an einzelne Personen oder gar Externe delegiert werden, egal wie engagiert oder kompetent diese sind.

Die Verantwortung muss bei den Fachbereichen, der IT und der Projektverantwortung liegen und im Idealfall durch das Management aktiv unterstützt werden.

Studierende können auf diesem Weg eine wertvolle Rolle spielen, beispielsweise als Impulsgeber, als methodische Unterstützung oder als Dokumentierende. Aber sie sollten nicht allein gelassen werden mit der Erwartung, ein Unternehmenstool zu empfehlen, das sie selbst nie produktiv nutzen werden.

‍

Fazit: Die Toolentscheidung ist zu wichtig zum Delegieren

Ein RM-Tool ist keine Software wie jede andere. Es beeinflusst, wie ein Unternehmen Anforderungen erhebt, Entscheidungen trifft und Produkte entwickelt. Die Entscheidung für ein solches Tool sollte deshalb nicht an Einzelpersonen und schon gar nicht an Studierende oder Externe delegiert werden.

Stattdessen braucht es Klarheit über die Ziele, über den Nutzerkreis, über den gewünschten Nutzen, sowie den Mut, Tools nicht nur nach Funktionen, sondern nach Alltagstauglichkeit zu bewerten.

Denn am Ende zählt nicht, wie vollständig die Excel-Tabelle war, sondern wie gut das Tool die Arbeit im Projekt unterstützt.