Trends & Benchmarks 2014: Welche Traceability ist denn wirklich die grösste Herausforderung im Requirements Engineering?


SwissQ

Zusammenfassung

SwissQ publizierte am 3. April 2014 an einem exklusiven Anlass für die Szene die neuste Version von Software Development Trends & Benchmarks 2014. Mit dabei ist auch der Bereich „Requirements“. Was mich schon das letzte Jahr verblüffte, ist, dass die meisten Traceability im Kontext des Requirements Engineerings als grosse Herausforderung identifizieren. Ich möchte in meinem Blogbeitrag gerne untersuchen, was Traceability ist und wieso eigentlich Unternehmen von Traceability herausgefordert werden.

Herausforderungen im RE

Trends-2014-RE-Herausforderungen

Wenn ich mir spontan Traceability vorstelle, sehe ich ein-zwei Requirements. Darauf referenzieren mehrere Test Cases; der eine gleich auf zwei unterschiedliche Requirements. Und zuletzt referenziert ein Solution Design auf ein-zwei Requirements. So, ganz naiv betrachtet, kann man Traceability sich vergegenwärtigen. Und die meisten tun das wohl ebenso, und sehen darin die grosse Herausforderung.

Traceability-Down
Trends-2014-RE-Herausforderungen
Womit werden wir in diesem Kontext jedoch herausgefordert? Gleichsam spontan lehrt meine Erfahrung mich:

  • Requirements sind bloss textuell und nicht in einem Requirements Management oder Application Lifecycle Management System erfasst
  • Requirements sind zwar erfasst, aber Tester und Entwickler haben wiederum andere Systeme
  • Requirements sind zwar erfasst und in einem zentralen Repository für alle zugänglich und somit verlinkbar, aber sie sind nicht wirklich verständlich oder aussagekräftig

Das sind Herausforderungen, die sicherlich die meisten Befragten spontan im Sinn hatten, als sie den Fragebogen ausfüllten. Und sicherlich gäbe es noch mehr, vor allem technische. Die ersten beiden konkreten Herausforderungen könnten rasch mit zweckmässigen Werkzeuge gelöst werden. In gewissen Branchen fordert selbst der Regulator, dass alle diese Artefakte miteinander eindeutig verbunden sind. Und zwar unabhängig, ob man eine komplette Application Lifecycle Management Lösung einsetzt oder nicht – zur Not nämlich tun es auch manuelle Links in klassischen Office-Produkten. Verkomplizierend ist jedoch, wenn man sich in Baselines bewegt. Wenn zum Beispiel Test Case 1 v1-00 auf Requirement v1-00 referenziert, jedoch Test Case 1 v2-00 auf Requirement v1-00. Solche Konstrukte überfordern Office-Produkte; sie erzeugen einen nicht unerheblichen Wartungsaufwand.

Aus Sicht Requirements Engineering interessiert allerdings viel mehr, wieso überhaupt unverständliche und wenig aussagekräftige Requirements irgendwo-irgendwie dokumentiert werden. Wieso sind diese Requirements so? Wieso haben wir – ich nenne sie frech -„Schein“-Requirements, die nichts aussagen?

Wenn Requirements professionell ermittelt, beschrieben, geprüft und abgestimmt werden, dann will ich meinen, es ist eine Schuld des Requirements Engineerings, wenn die Tester und Entwickler nicht wissen, was ein Requirements aussagen will.

Ist es wirklich „nur“ Traceability?

Traceability als technische Anwendung von Links zwischen unterschiedlichen Objekten ist kaum eine grosse Herausforderung, wenn man zeitgemässe Werkzeuge einsetzt. Haben also Tester und Entwickler oder Requirements Engineers selber tatsächlich Schwierigkeiten mit ungenügenden Requirements? Requirements, die bloss aus einem ebenso ungenügenden einen Satz bestehen? Requirements, deren Zweck man nicht recht nachvollziehen kann? Requirements, die schlicht und einfach unverständlich sind? – Hat die schweizerische Szene vermutlich unter dem Stichwort „Traceability“ Missverständnisse in der Kommunikation und ungenügende Requirements zusammengefasst?

Der aktuelle Trends & Benchmarks 2014 zeigt folgende Gründe, wenn man danach fragt:

Trends-2014-RE-Gründe-ungenügende-Anforderungen

Weit und breit kein Stichwort, keine Andeutung von Traceability. Also doch nicht? Allerdings jede Menge über Kommunikation, Missverständnisse und sogar noch eines bezüglich mangelhafter Priorisierung – aber das ist dann die andere Seite der Traceability, die ich gerne auch noch erklären möchte.

Die andere Seite der Traceability

Traceability bedeutet auch, dass ein Requirement immer auf ein Ziel, auf ein Feature verweist.

Requirements wachsen nicht einfach so; sie werden konkret und gezielt angeregt.

Idealerweise basieren Requirements immer auf übergreifenden Geschäftszielen. Um mein Geschäftsziel zu erreichen, muss ich diese und jene Requirements umsetzen. Das ist die Theorie; in der Praxis aber sind Requirements wirklich oftmals „einfach da“ und niemand weiss wieso.

Traceability-Up

Requirements sind also einfach da, niemand weiss wieso, und irgendwann ärgert man sich, dass etwas Falsches umgesetzt, also nicht richtig priorisiert wurde. Ein Requirement ohne Sinn, ohne – wie wir in der SwissQ zu sagen pflegen – Business Value ist kein richtiges Requirements; es hat einfach keine Daseinsberechtigung. Sorry.

Wenn also Leute sich über mangelnde Traceability beklagen, dann heisst das nicht, dass Tester und Entwickler nicht wissen, auf welche Requirements sie ihre Artefakte verweisen sollen, sondern, dass Requirements einfach keinen Sinn haben.

Weil sie nicht in einem grösseren Zusammenhang eingebettet sind. Das ist erschreckend. Und das ist für mich keineswegs eine Frage des Werkzeugs. Denn dieses Problem haben selbst Unternehmen, die ausgeklügelte Application Lifecycle Management Lösungen unternehmensweit ausrollten.

Was ist also eigentlich die Herausforderung?

Für mich ist es immer wieder frappierend, dass Traceability als die grösste Herausforderung betitelt wird. Vor allem, weil dieses Stichwort bei anderen, verwandten Fragestellungen nie auftaucht. Was ist los? Ist es Bullshit-Bingo („Oh, Traceability, ja, grosse Herausforderung“) oder ist es wirklich ein Platzhalter für eine Menge anderer Probleme („Requirements ohne Sinn und Zweck“)?

Um diese Frage zu diskutieren, würde sich ein oder mehrere Bierchen nach Feierabend empfehlen.

Ich selber habe mir eine Meinung gebildet. Wenn die Leute Traceability sagen, meinen sie, dass sie Requirements haben, die nicht zu etwas Gross-Ganzem gehören. In der Produktentwicklung sind das Kundenbedürfnis, Marktbedürfnis oder Bedürfnisse, die wir wecken wollen. In der Unternehmensarchitektur sind das Geschäftsfähigkeit, Geschäftsziele. Ein Requirements ohne Bezug verursacht auch in nachgelagerten Projektphasen Rätsel und Unverständlichkeit. Traceability bedeutet schliesslich auch Lebenszyklus. Ein Requirement, das in anderen Projektzyklen (z.B. Testing) als harte Referenz weiterlebt, hat somit Gültigkeit und Relevanz. Und somit kann sichergestellt werden, dass alle nachgelagerten Aktivitäten das Richtige tun. Ob sie es richtig tun, da helfen wir gerne.

Was ich mitgeben kann

Wenn also jemand sagt, Traceability fordert ihn heraus, dann seien sie skeptisch. Was meint er konkret? Ich will drei Ursachen zusammenfassen:

  1. Links zwischen Requirements, Test- oder Entwicklungsartefakte zu setzen ist herausfordernd
  2. Unklar-unverständliche Requirements richtig zu interpretieren ist herausfordernd
  3. Requirements ohne Bezug zu etwas Gross-Ganzem (Geschäftsziel, Business Value) sind herausfordernd

Ich werde versuchen, im nächsten Trend & Benchmarks in der Fragestellung zu differenzieren, welches nun tatsächlich die grössere Herausforderung ist. Ich nämlich spekuliere, es ist dritteres.

Und wie kann SwissQ helfen?

SwissQ versteht alle drei Ursachen. Ob Links, unklare Requirements oder Requirements ohne Bezug – wir unterstützen sie gerne. Was ich persönlich empfehlen kann, ist der Business Value Gedanke. Business Value ist nämlich zentral – das beginnt eben und gerade bei den Requirements, weil später wird’s nie mehr reflektiert. Wir priorisieren kontinuierlich und in allen Bereichen. Unsere Requirements Engineers stellen sicher, dass sie bloss Requirements haben, die auch ihre strategischen Geschäftsziele erfüllen und nicht blosser Selbstzweck sind. Unsere Erfahrungen diesbezüglich vermitteln wir auch gerne in unserer Academy. Wir glauben nämlich, dass richtige Requirements Schlüssel zu ihrem Projekterfolg sind.

Newsletter abonnieren

0 thoughts on “Trends & Benchmarks 2014: Welche Traceability ist denn wirklich die grösste Herausforderung im Requirements Engineering?”


    Schreibe einen Kommentar