Anforderungsmanagement; Was Schubkarren und Anforderungen gemeinsam haben...

Integriertes Requirements Engineering – der Wert von Anforderungsmanagement in Kombination mit Verifikation/Validierung

Lesen Sie das Lifecycle InsightsE-Book „Das Produktentwicklungsdilemma: Fünf Strategien für Führungskräfte in der Produktentwicklung, um Produktanforderungen zu erfüllen und Liefertermine einzuhalten“.“

Ich habe ein Praktikum im Bereich Konstruktionstechnik bei GE absolviert, während ich an meinem Bachelor-Abschluss als Ingenieur gearbeitet habe. Wie in den meisten Unternehmen war der erste Arbeitstag mit einer Einführung für neue Mitarbeiter verbunden. Zu den Einführungsunterlagen gehörten GE-ismen, die viele der klassischen Geschichten über den Gründer von GE, Thomas Edison, die wir schon lange kennen, erneut erzählten – Tausende von gescheiterten Versuchen, um letztlich eine funktionierende Glühbirne zu erhalten. „Ich bin nicht gescheitert; ich habe 10.000 Methoden gefunden, die nicht funktionieren“, „Genie ist 1 % Inspiration und 99 % Transpiration“ und andere, die Sie schon gehört haben. Gegen Ende des Buchs fanden sich örtliche GE-ismen, darunter eine Geschichte aus der Zeit, als die Fabrik gebaut wurde...

Die Geschichte handelt von einem Arbeiter, der jeden Tag mit einer Schubkarre voller Dreck die Baustelle verließ. Sicherheitsleute am Ausgang hielten ihn an und suchten im Dreck nach dem, was er zu stehlen versuchte. Da sie nichts fanden, ließen sie ihn gehen... Und so ging es jeden Tag: Der Arbeiter verließ mit einer Schubkarre voller Dreck die Baustelle, bis sie es am letzten Bautag aufgaben und ihn fragten, was er stehle.  Seine Antwort... Schubkarren.

Wir verbringen viel Zeit mit textbasierten Anforderungen und Anforderungsdokumenten. Dabei passiert es leicht, dass wir den Unterschied zwischen dem Inhalt von Anforderungen und dem Rahmen, in dem sie präsentiert werden, aus den Augen verlieren. Ich versuche, diese Verwirrung bzw. den Reifegrad bei meinen Besuchen in verschiedenen Unternehmen zu messen, indem ich Konstrukteure frage, was sie produzieren... Wenn sie dann einen Papierstapel hervorholen oder mir ein dickes PDF-Dokument mit Anforderungen präsentieren, weiß ich, dass wir es mit einem Konstrukteure zu tun haben, der sich mehr auf die „Schubkarre“, also das Hilfsmittel, als auf den eigentlichen Inhalt konzentriert.

Während meiner Zeit in der Hightech-Branche erkannte das Management, dass wir mehr Aufgaben zu erledigen hatten als Mitarbeiter, die sie bewältigen konnten. Dies führte zu einer umfassenden Initiative, die Produktivität aller Beteiligten zu steigern. Dies war insbesondere an die Personen am Frontend des Lebenszyklus gerichtet, d. h. diejenigen, die die Anforderungen definierten, die von allen anderen nachgelagerten Benutzern verwendet wurden. (Man erkannte also, dass der entscheidende erste Schritt für den Projekterfolg darin bestand, sicherzustellen, dass die Anforderungen richtig waren.) Um den Status quo zu bestimmen, wurde eine Zeit-/Bewegungsstudie in Auftrag gegeben, um festzustellen, welche Arbeiten die Frontend-Mitarbeiter erledigten, und Verbesserungspotenziale zu ermitteln. Sie fanden Folgendes heraus:

• 50 % ihrer Zeit verbrachten die Mitarbeiter mit der Generierung/Pflege von Dokumenten

• 25 % ihrer Zeit verbrachten sie mit der wiederholten Eingabe derselben Informationen an verschiedenen Orten in verschiedenen Dokumenten, Präsentationen usw.

• 30 % für die Kommunikation dieser Ideen an andere (oft immer wieder dasselbe Meeting)

• 14 % ihrer Zeit für „Futzing“ (nicht ganz offizieller Fachbegriff für wiederholte Versuche, ein Dokument korrekt zu drucken)

... was in der Summe mehr als 100 % ergibt (weil diese Leute viel mehr als 40 Stunden pro Woche gearbeitet haben, um alle Aufgaben zu erledigen).

Diejenigen unter Ihnen, die sich noch an das Buch „Reengineering the Corporation“ von Michael Hammer und James Champy (ca. 1993) erinnern, werden sich an den Prozess des Value Mapping erinnern, bei dem Sie Ihre Geschäftsprozesse erfassen und den Zeit-/Aufwand messen mussten, der für diese Prozesse aufgewendet wurde, um ihn dann mit dem Wert für den Kunden zu vergleichen. Wenn Sie etwas fanden, für das Sie Zeit aufwenden, das der Kunde aber nicht schätzte, dann war das ein Kandidat für die Eliminierung aus Ihren Entwicklungsprozessen. Wendet man das Wertprinzip aus dem Reengineering auf die Anforderungen an, so müssten die Anforderungsspezifikationen/-dokumente angesichts des Aufwands, den wir in sie stecken, für den Kunden extrem wertvoll sein. Unsere Analyse hat jedoch ergeben, dass niemand sie liest, dass sie veraltet sind, sobald Sie sie ausdrucken, dass es angesichts der für sie aufgewendeten Zeit die Tendenz gibt, zu glauben, dass alles im Projekt in Ordnung sein muss, wenn die Dokumente abgezeichnet sind, und vieles mehr. Warum also verbringen wir so viel Zeit mit etwas von so zweifelhaftem Wert?

Größtenteils läuft es darauf hinaus, dass wir auf diese Weise bezahlt werden, die Richtlinienkonformität nachweisen, mit Kunden interagieren, usw.

Bleiben wir bei unserer Schubkarren-Analogie: Wie wäre es, wenn wir uns auf den Inhalt statt auf Behälter konzentrieren und damit beginnen könnten, Anforderungen einzeln zu verwalten nach Bedarf zu konfigurieren und anzuwenden? Wir könnten die Produktivität am Frontend deutlich steigern (d. h. im Sinne des Lean-Konzepts die Verschwendung vermeiden, die durch Warten auf die Füllung einer Charge entsteht – in diesem Fall: wenn ein ganzes Dokument, das auf Prüfung/Genehmigung wartet, bis alle Anforderungen erfasst sind) und den wesentlichen Nutzen der Anforderungen jetzt dadurch erschließen, dass wir sie in den Entwicklungsprozess integrieren, sodass die Produkte durchgängig von den Anforderungen beeinflusst werden. Wir nennen dies integrierte Anforderungen …

Ein Beispiel für integrierte Anforderungen wäre die Verknüpfung von Anforderungen mit ihren nachgelagerten Verifikations- und Validierungsprozessen (schließlich ist eine der Definitionen für eine gute Anforderung, dass sie „überprüfbar“ ist).

Stellen Sie sich also den Produktivitätsschub vor, den Prozesse dieser Art mit sich bringen: Eine Anforderung wird im Zusammenhang mit den Testfällen definiert, die ihrerseits wiederverwendet werden, um die Konformität zu validieren (wobei auch die Testfälle einzeln anstatt in einem Testdokument verwaltet werden); die Anforderungen und ihre Parameter sind an Programmpläne gebunden, die uns darüber informieren, welche Anforderungen für welchen Zwischentermin validiert werden müssen. Die Durchführung der Tests/Validierung wird überwacht, wobei Nachweise gesammelt und mit den Anforderungen verknüpft werden (sodass die Verbindung von den Anforderungen zur Validierung und den Nachweisen klar ersichtlich wird), und die Erfahrungen/Probleme/Abweichungen werden zum Frontend des Prozesses zurückgemeldet, wo wir das bestehende Programm als Ausgangspunkt (mit allen erfassten Erfahrungen) für den nächsten Zyklus verwenden.

Sie denken vielleicht, dass dies viel zu viel ist, um es auf einmal zu bewältigen, aber es gibt Gewinne auf dem Weg dorthin.

Es ist zum Beispiel sinnvoll, nur Testfälle zu verwenden, die mit Anforderungen verknüpft sind. Aus unserer Erfahrung wissen wir, dass das nicht ungewöhnlich ist:

• 30 % der Testfälle haben keine Quellen – es gibt keine zu validierenden Anforderungen; das bedeutet „Test Creep“: 30 % unnötige Tests

• 25 % der Anforderungen sind nicht verifiziert – keine mit den Anforderungen verknüpften Testfälle; es wird nicht das Richtige getestet

Es ist leicht gesagt: Lassen Sie die „Schubkarre“ stehen... kulturell ist dies jedoch schwierig umzusetzen; vor allem, wenn Ihre Kunden erwarten, dass Sie Arbeitsergebnisse in Form von Dokumenten bereitstellen. OK, wir erstellen Dokumente, um sie ihnen bereitzustellen. Aber wir konzentrieren uns darauf, einzelne Anforderungen zu konfigurieren/zu verwalten, sie immer wieder in vielen verschiedenen Programmen zu verwenden; wir denken über Anforderungen im Sinne eines „Lean“-Konzepts nach (Genehmigung einzelner Anforderungen im Gegensatz zum „Anti-Lean“-Verfahren, wobei wir warten, dass ein ganzes Bündel von Anforderungen im selben Dokument genehmigt wird) und wir haben jetzt einen klaren Überblick, der es uns erlaubt, einzelne Anforderungen, wohin sie weitergeleitet werden, wie/wann sie überprüft wurden, ihre Historie, ihre Begründung, Probleme usw. zu verfolgen und für die nächste Runde zu nutzen, was es uns erlaubt, sie in jedem Zyklus erneut zu verwenden/weiter zu verbessern.

Lesen Sie das Lifecycle InsightsE-Book „Das Produktentwicklungsdilemma: Fünf Strategien für Führungskräfte in der Produktentwicklung, um Produktanforderungen zu erfüllen und Liefertermine einzuhalten“.“

Erfahren Sie mehr über die Anforderungen, indem Sie unsere Blogbeiträge lesen. Erfahren Sie, wie Sie mit Teamcenter X in der Cloud schnell und kostengünstig die Kontrolle über Produktinformationen und -prozesse einschließlich der Anforderungen übernehmen können.