en
de

Mehr als alter Wein in neuen Schläuchen

6 Februar 2014
| |
Lesezeit: 4 Minutes

Als Requirements Engineer treffe ich oft auf folgendes Szenario:

Während Monaten ermitteln, dokumentieren und stimmen Unternehmen Anforderungen ab. Die IT entwickelt, testet und übergibt die Lösung dem Betrieb. So, und nun? Die Anforderungsdokumente werden weggelegt. Neue Projekte ziehen ein und die Geschichte mit den Anforderungen beginnt von vorne.

Warum lassen Unternehmen die getätigte Investition nach Projektende ungenutzt? Die meisten Unternehmen beantworten mir diese Frage mit: „Wir haben kein geeignetes Tool dafür!“ Ist das der wahre Grund?

Wiederverwendungskonzept

Gemäss meiner Erfahrung fehlt jeweils ein Wiederverwendungskonzept. Was regelt denn so ein Wiederverwendungskonzept? Der hier vorgestellte Inhalt entspricht einem generischen Vorschlag. Das Konzept passt sich der Grösse des Unternehmens und der Anzahl der wiederverwendeten Anforderungen an. Es ist wichtig, dass die oberste Führungsebene das Konzept stark mitprägt und unterstützt. Sie sollte schon aus wirtschaftlichen Gründen daran interessiert sein, die Anforderungen wieder zu verwenden.

Reuse-Manager (Wiederverwendungs-Manager) ernennen

Die Führungsebene stellt genügend Ressourcen für das Wiederverwendungsmanagment bereit. Je nach Grösse des Unternehmens ist diese Rolle sinnvollerweise in der Fachführung oder im Produktmanagement anzusiedeln. Bei hoher Maturität eines Prozessmanagements ist ein Prozessverantwortlicher eine ideale Person dafür. Die Aufgaben und Verantwortlichkeiten eines Reuse-Managers:

Bestimmen von potenziell wiederverwendbaren Anforderungen

Eine Anforderung ist umso besser wiederverwendbar

  • je generischer der Spezifikationslevel ist
  • je eingeschränkter die Produktepalette ist
  • je unabhängiger die Anforderung in einen Ablauf eingebunden ist
  • je abstrakter und technologieunabhängiger die Beschreibung ist
  • je zeitlich konstanter die Ausprägung ist

Die Top 3 der Wiederverwendung sind:

  • Nicht-funktionale Anforderungen
  • Begriffsdefinitionen
  • Funktionale Anforderungen

Analyse von Informationen

Der Reuse-Manager durchsucht vorhandene Informationen aus laufenden und bereits abgeschlossenen Projekten nach Wiederverwendung. Er ist in den jeweiligen Projekten eingebunden, um sein Know-how einzubringen und frühzeitig neue wiederverwendbare Anforderungen zu identifizieren.

Organisation der Anforderungsarchitektur

  •   Der Reuse-Manager erstellt die Architektur der Anforderungen. Dazu wählt er ein für das Unternehmen sinnvolles Vorgehen
  •   Nach Art kategorisieren (z.B. Nicht funktionale Anforderung) und Hinterlegen mit geeigneter Struktur
  •   Struktur der Referenzdatenbank (z.B. Nicht-funktionale Anforderungen angelehnt an ISO/IEC 9126)

Verknüpfung

Der Reuse-Manager erfasst die gesammelten Informationen in einer Datenbank. Die für ein neues Projekt relevanten wiederverwendbaren Anforderungen werden von ihm aus der Datenbank extrahiert und eingebracht.

Verantwortlichkeit

Der Reuse-Manager ist für die Einhaltung der im Wiederverwendungskonzept enthaltenen Prozesse und Richtlinien verantwortlich.

Vorgehensweisen

Um eine Konsistenz in der Anforderungs-Suppe zu erhalten, ist es grundsätzlich erforderlich, ein einheitliches Vorgehen in der Anforderungsstrukturierung zu wählen. Damit wird auch die Wiederverwendbarkeit ermöglicht. Im Fachbuch‘ Requirements- Engineering und –Management von Chris RUPP & die SOPHISTen‘ sind einige mögliche Vorgehen erläutert.

  • Ansatz nach IVENA (Integriertes Vorgehen zur Ermittlung nicht-funktionaler Anforderungen)
  • Produktlinien-Ansatz (Anforderungen als Basis für ganze Produktlinien)
  • Main-Stream-Ansatz (Ableiten der Anforderungen von einem zentralen Produkt)
  • Copy & Paste Ansatz

Erstellung von Richtlinien

Dieses Kapitel sorgt für eine ausreichende Werkzeugunterstützung, die eine gute Verwaltung der Anforderungen und ein leichtes Auffinden ermöglicht. Der Ort, an dem die zur Wiederverwendung gesammelten Daten abgelegt werden, heisst Referenzdatenbank oder Wiederverwendungs-Pool. Dazu sind Ausbildungsunterlagen und Richtlinien zu erstellen. Auch wird hier die Sicherstellung der Wiederverwendungs-Anforderungen unternehmensweit und nicht abteilungsweise geregelt.

Berechtigung und Rollen

Erstellen eines geeigneten Rechtekonzepts hilft, die festgelegten Strukturen zu bewahren. Dabei müssen die nachfolgenden Hauptaspekte beantwortet werden. Anhand welcher Arbeitsabläufe und durch welche beteiligten Stellen werden Anforderungen generiert und verwaltet? Welche Anforderungslevels und Attribute pflegen die jeweiligen Gruppen und Benutzer? Wie sind die Strukturen und Attribute organisiert? Welche unterschiedlichen Rechte gibt es (lesen, schreiben, löschen, freigeben). Welche Ebenen von Rechte gibt es (Strukturen, Attribute, textliche und grafische Inhalte von Anforderungen)? Wer ist für welchen Bearbeitungsschritt verantwortlich?

Einführungsstrategie

Eine Einführungsstrategie vom Wiederverwendungskonzept fördert dessen Akzeptanz und hilft, wertvolle Arbeit zu sichern, und eine grosse Investition zu schützen. Dabei lohnt es sich, Zeit für Planung, Auswahl des Teams und Definition der Arbeitspakete zu investieren. Auch Themen wie, Mitarbeiter in den neuen Methoden auszubilden und benötigte Unterstützung bereitzustellen, sind Teile der Einführungsstrategie. Der Hauptfokus liegt jedoch in der Aufnahme und im Teilen von Informationen. Sie ist ein Wegbereiter um alle Know-how Träger zu motivieren, ihre Informationen zu teilen um Konkurrenzdenken entgegenzuwirken.

Wann haben Sie das letzte Mal eine Anforderung wiederverwendet? Oder doch alles neu gemacht?

Kommentare (3)

Avatar

Peter Gfader

10 Februar 2014 um 15:25

Bei einem Wiederverwendungskonzept von Anforderungen werfen sich in mir ein paar Fragen auf.
– Wenn wir Funktionale Anforderungen wiederverwenden, bauen wir dann nicht nochmal das Gleiche?
– Wieso gibt es dann überhaupt die Investition in das Produkt, Projekt?
– Wenn der Spezifikationslevel generisch ist, wie wollen wir dann überhaupt etwas Sinnvolles bauen?

Den Reuse von sehr hohem Spezifikationslevel: Visionen, Epics, Goals, Impacts, Anforderungen sehe ich als gefährlich.
– Wie motiviere ich ein Team was Ähnliches/Selbes zu Bauen?
– Wie bekomme ich dafür finanzielle Mittel vom Management?

– Was ist eine „Architektur der Anforderungen“?

>> „Wann haben Sie das letzte Mal eine Anforderung wiederverwendet? Oder doch alles neu gemacht?“
Das ist eine SUPER FRAGE!!
Ich sehe viel zu viele Initiativen wo genau das passiert („doch alles neu gemacht“). Das Problem ist dabei aber nicht dass man die Anforderungen nicht gekannt hat.
Ich denke da gibt es ein paar andere Gründe dafür und diese zu ergründen sollte ein potentielles Ziel sein.

    Gabriela Moll

    Gabriela Moll

    11 Februar 2014 um 11:04

    Hallo Peter

    Herzlichen Dank für Dein Interesse an diesem Thema und Deine Fragen. Ich freue mich sehr über jede Auseinandersetzung mit der Wiederverwendung von Requirements. Zu Deinen Fragen:

    • Wenn wir Funktionale Anforderungen wiederverwenden, bauen wir dann nicht nochmal das Gleiche?
    Wieso gibt es dann überhaupt die Investition in das Produkt, Projekt?

    -> Ich erfahre oft, dass ich im Requirements Engineering den IST-Zustand mit verschiedenen Techniken (Feldbeobachtung/Artefaktebasierte Techniken/Systemarchäologie) ermitteln muss. Diese Aufgabe ist zeitlich sehr aufwändig und ich bin viel effizienter, wenn ich die ‚alten‘ Anforderungen wiederverwenden kann. Klar muss ich als Business Analyst die einzelnen Anforderungen den neuen Wünschen und Gegebenheiten, welche ich mit verschiedenen Kreativitätstechniken ermittelt habe, anpassen. Dies ist jedoch viel weniger aufwändig als das Rad neu erfinden.

    • Wenn der Spezifikationslevel generisch ist, wie wollen wir dann überhaupt etwas Sinnvolles bauen?

    -> Zur Verdeutlichung habe ich Dir zwei Beispiele.

    Anforderung auf Spezifikationslevel 1:
    Das System muss dem User die Möglichkeit bieten, die Bankverbindung eine Kunden einzugeben

    Dieselbe Anforderung, nur auf Level 2:
    Das System muss dem User die Möglichkeit bieten, die Clearingnummer der Bank und die Kontonummer eines Kunden einzugeben.

    D.h. die Anforderung auf Level 1 könnte ich für den Bau eines Dokumentenmanagements verwenden. Aber auch für den Bau eines Erfassungssystems für Zahlungsaufträge.

    • Den Reuse von sehr hohem Spezifikationslevel: Visionen, Epics, Goals, Impacts, Anforderungen sehe ich als gefährlich.
    o Wie motiviere ich ein Team was Ähnliches/Selbes zu Bauen?
    o Wie bekomme ich dafür finanzielle Mittel vom Management?

    -> Das sehe ich wie Du. Visionen, Epics, Goals, Impacts erachte ich nicht als sinnvoll wieder zu verwenden. Etwas ‚ähnliches‘ Bauen gibt es zum Beispiel beim Ablösen von alten Systemen. Da kannst Du als Basis schon mal die bestehenden Anforderungen übernehmen. Aber diese müssen, wie schon beim ersten Punkt erwähnt, überarbeitet werden.
    Der Zusatzaufwand kann in vielen Fällen nicht auf die Projektkosten umgerechnet werden und ist damit nur schwer durchzusetzen. Deshalb erachte ich es als Linienaufgabe Anforderungen zu pflegen. Hier hilft aus meiner Sicht eine finanzielle Gegenüberstellung. Wie hoch ist der Aufwand damit Mitarbeiter erhobenes Wissen so dokumentieren, dass es wiederverwendet werden kann, und damit überprüft wird, ob das Wissen bereits vorhanden ist oder tatsächlich neu erhoben werden muss. Im Vergleich, wie hoch ist der Aufwand für zukünftige Projekte die Requirements komplett neu zu ermittelt und zu dokumentieren.

    • Was ist eine „Architektur der Anforderungen“?

    -> Die Architektur beinhaltet aus meiner Sicht die Attributierung, Sichten, Priorisieren, Versionierung, Verfolgbarkeit und die Verwaltung von Anforderungsänderungen. Sie beschreibt die Strukturen und die Prozesse um diese Inhalte sicherzustellen.

    Natürlich bin ich gespannt, welche weitere Gründe vorherrschen, dass selten eine Wiederverwendung stattfindet.

    Beste Grüsse
    Gabriela

      Avatar

      Peter Gfader

      18 Februar 2014 um 17:41

      >> ich bin viel effizienter, wenn ich die ‚alten‘ Anforderungen wiederverwenden kann
      Wie wissen wir ob die noch aktuell sind?
      Wie wissen wir ob diesen Anforderungen dem aktuellem System noch übereinstimmen?

      Ich glaube wir kommen hier an einen interessanten Punkt: Ist Zustand von (Requirements, Doku,…). Zum Verstehen des Systems als „Neuling“ sind ‚alte‘ Anforderungen wichtig. War das das Argument deines Blog posts?

      Ich denke wir sollten vielleicht die 2 Aspekte unterscheiden:
      1. ‚Alte‘ Anforderungen zum Verständnisaufbau für neue Mitarbeiter
      2. ‚Alte‘ Anforderungen zum Wiederverwenden für ’neue‘ Produktentwicklung

      Punkt 1 sehe ich als wertvoll, Punkt 2 weniger.


      >> RE: Spezifikationslevel 1 & 2
      Was ist denn der Vorteil des Wiederverwendens eines Requirements auf Level 1?
      Ist vielleicht das Tooling um Requirements zu komplex dass wir diese kopieren und einfügen müssen? Was könnten wir machen um das zu vereinfachen?

×

Updates

Schreiben Sie sich jetzt ein für unsere zwei-wöchentlichen Updates per E-Mail.

This field is required
This field is required
This field is required

Mich interessiert

Select at least one category
You were signed up successfully.

Erhalten Sie regelmäßige Updates zu neuen Blogartikeln

Jetzt anmelden

Oder möchten Sie eine Projektanfrage mit uns besprechen? Kontakt aufnehmen »