“Ongoing investigation in the case system-development” – Chris Rupp (alias Sherlock) im Interview mit den Veranstaltern der DREAM-Konferenz (NL) – Teil 2

Sie erinnern sich? Da war doch was mit Sherlock, Chris Rupp, RE und Holland! Vor ein paar Wochen haben wir den ersten Teil des Interviews von Chris mit den Veranstaltern der DREAM-Konferenz (Dutch Requirements Engineering and Management) veröffentlicht.

Nun sagen wir: Goedendag en hartelijk welkom zum zweiten Teil des Blogbeitrags!

Widmete sich Teil 1 in erster Linie dem Thema Stakeholderliste und Personas, wird in diesem zweiten und letzten Teil der Fokus auf der Ermittlung von Anforderungen liegen – oder im kriminalistischen Sinne: Zeugenbefragung und Dokumentenrecherche!

Unterbewusstes Wissen: Sie sagten, dass es schwierig ist, unterbewusstes Wissen zu ermitteln. Können Sie uns einige Tipps geben, wie wir unsere Fähigkeiten in diesem Gebiet verbessern können?

Unterbewusste Anforderungen sind dem Stakeholder so selbstverständlich, dass er sie nicht formuliert, sie eigentlich nicht mal selbst bewusst wahrnimmt. Das heißt aber nicht, dass diese Anforderungen deswegen unwichtig sind. Im Gegenteil. Sie sind so wichtig, dass die daraus resultierenden Funktionen so häufig genutzt werden, dass das Systemverhalten schon selbstverständlich ist.

Erheben können Sie derartige Anforderungen z.B. indem Sie Ihren Stakeholder bei der Arbeit beobachten. Dabei werden Sie auch die selbstverständlichen Arbeitsschritte erleben. Oder versuchen Sie doch mal selbst die Arbeit Ihres Stakeholders durchzuführen – am besten natürlich unter Anleitung ihres Stakeholders (der dann als Ihr Lehrmeister fungiert). Bei all den Tätigkeiten bei denen er die selbstverständlichen Informationen vergisst, werden Sie feststellen, dass diese Ihnen fehlen. Auch ein Blick auf das Altsystem lohnt sich. Dort sollten die unterbewussten Anforderungen umgesetzt sein. Sollten Sie dann die unbewussten Anforderungen entdeckt haben und beim Kunden hinterfragen, wird er Ihnen sagen: natürlich brauche ich das…

Ermittlung: Sie haben deutlich herausgestellt, dass der Schlüssel zu einer guten Anforderungsermittlung die Verwendung der richtigen Techniken ist. Diese kann man erlernen. Besonders wichtig ist Ihrer Meinung nach aber auch, an das unbewusste Wissen zu gelangen. Wir fragen uns, ob das auch lernbar ist, denn es scheint doch eher eine intuitive als eine rationale Fähigkeit zu sein.

Unbewusste Anforderungen sind Anforderungen, die dem Stakeholder nicht bekannt sind, die ihn aber sofort begeistern, wenn er sie im Produkt erlebt, da ein Bedürfnis danach in ihm existiert. Man erhebt sie nicht, man erfindet sie gemeinsam mit den Stakeholdern. Somit sind wir im Bereich der Innovation, der Kreativität, der Intuition. Um in diesem Bereich erfolgreich arbeiten zu können brauchen die Beteiligten fundiertes Grundwissen im betroffenen Fachbereich. Gute Ideen entstehen nicht auf der Basis von Unwissenheit. Neben einem gutem Fachwissen im Gegenstandsbereich benötigen Sie aber auch ein breites Wissen in vielen anderen Bereich (um daraus Ideen für einen Transfer schöpfen zu können) und die Fähigkeit, Konzepte und Ideen aus anderen Bereichen mit Problemstellungen aus dem Gegenstandsbereich zu kreuzen. Daraus entstehen dann evtl. Konzepte, die ein aktuelles Bedürfnis Ihres Stakeholders decken. Von Kreativitätstechniken halte ich nicht so viel. Sie sind ein möglicher Weg um zu Ideen zu kommen. Wichtiger ist mir allerdings der Fundus an Wissen, den Menschen im Kopf haben und mit dem Sie arbeiten können und das Potential all diese Wissensfragmente wild zu kombinieren. Begabte Menschen können das dann mit oder ohne die Hilfe einer bestimmten Kreativitätstechnik machen. Für die Durchführung eines Workshops mit mehreren Beteiligten ist allerdings die Verwendung bestimmter Kreativitätstechniken zu empfehlen, insbesondere wenn bestimmte Probleme vorherrschen, wie z.B. eine schwierige Gruppendynamik. Da kann z.B. eine Technik wie 6.3.5 dieses Problem lösen und damit für eine kreative Arbeitsatmosphäre sorgen.

Ermittlung: In der IT-Welt scheint die Mehrheit an Personen eher der Typ “beta” (mathematisch, methodisch, wissenschaftlich) zu sein. Aber sind die Anforderungsanalyse oder die Business Analyse nicht eher Gebiete, in denen eher „alpha“-orientierte (linguistisch, kreativ) Menschen effektiv sein können?

Puh, schwere Frage. An sich ist es wichtig, dass ein Requirements-Engineer sowohl analytisch sehr gut ist (denn er muss aus den 1000 Einzelinformationen ein Modell eines Systems formen und die Redundanzen und Widersprüche entfernen können). Der Requirements-Engineer sammelt die Informationen sehr vieler Stakeholder und verdichtet sie zu einer konsistenten Sicht.

Andererseits ist er die kommunikative Schnittstelle der Systementwicklung zum Rest der Welt. Somit braucht er eine hohe sprachliche Kompetenz und viel Kreativität, denn er muss gemeinsam mit den Stakeholdern die Systemrealität der Zukunft erfinden.
Im Vergleich zu den anderen IT-Disziplinen (wie Architekten, Porgrammierer, Tester) braucht er wesentlich mehr alpha-Eigenschaften.

Ermittlungsmatrix: Es ist ersichtlich, dass die Benutzung der Ermittlungsmatrix sehr nützlich sein kann. Wie wendet ihr SOPHISTen die Matrix in der Praxis an? Gibt es eine universelle Matrix für jedes Projekt oder ist das mehr Geschmackssache des Beraters?

Wir arbeiten mit der einen Matrix, die wir auch veröffentlicht haben. Aus dieser suchen wir die sinnvollste Ermittlungstechnik heraus, die in der entsprechenden Situation helfen würde. Jeder Analytiker nimmt sich allerdings heraus, auch mal der Tabelle zu widersprechen, wenn er persönlich die entsprechende Technik nicht mag, oder das Gefühl hat, dass der entsprechende Stakeholder auf eine andere Technik mehr anspringen würde. Die Matrix sollte eine Hilfestellung sein und keinesfalls als strikte Vorgabe oder Dogma verwendet werden.

Vielen Dank für die Antworten. Das wird uns und unseren Kollegen helfen, bessere Requirements-Engineers zu werden!

Danke für die Fragen. Sie waren auf einem wirklich hohen Niveau und zeigen, dass Sie schon ziemlich gute Requirements-Engineers sind.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert