Oder: „Warum Menschen verschieden sind und Potentiale nicht genutzt werden?“

Aufgabe des Requirements Engineering ist es, unterschiedliche Menschen zusammenzubringen und deren Vorstellungen, Ideen und Wünsche in die Form einer Anforderungsspezifikation zu gießen. Um dies zu erreichen, ist ein grosser Kommunikations- und Verständigungsbedarf zwischen diesen Personen notwendig. Die schwierige Aufgabe des Zusammenbringens dieser Menschen fällt Ihnen als Requirements Engineer zu. Dabei können Sie sich als Requirements Engineer folgende Fragen stellen: Mit was für einer Person habe ich es im Moment zu tun? Warum reagiert sie so wie sie reagiert? Wie kann ich in dieser Situation mit diesem Menschen umgehen, damit ich als Requirements Engineer meine Ziele erreiche? Und vor allem folgende Frage sollten Sie für sich beantworten: Wie darf ich mich auf keinen Fall verhalten, um meine Ziele nicht zu gefährden?

Wir werden in jedem Newsletter ein typisches Szenario aus unterschiedlichen Disziplinen des Requirements Engineering beschrieben. Um die Szenarien übersichtlich zu gestalten, wurde jeweils der am besten zu der beschriebenen Person passende Typ ausgewählt. Über den Persönlichkeitstyp können wir wiederum auf die Hintergründe und Ursachen der Verhaltensweisen schließen, wodurch wir Lösungsmöglichkeiten und „Don’t Do’s“ aufzeigen können. Die Persönlichkeit des Requirements Engineers selbst wird nicht betrachtet.

Betrachten wir folgendes Szenario: Im Rahmen der Anforderungserhebung möchten Sie die Anforderungen eines bestimmten Stakeholders, z.B. eines Repräsentanten der Endanwender, ermitteln. Dieser ist für sein sehr detailliertes und tiefgehendes Wissen bekannt und erfahrungsgemäß auch in der Lage, komplexe Probleme zu verstehen. Sie wenden hierbei zur Anforderungserhebung verschiedene Techniken an, versuchen über ein Brainstorming, über mündliche Interviews und Fragebögen oder über Prototypen diese Anforderungen herauszuarbeiten. Am Ende dieses Prozesses ist es Ihnen nicht gelungen, dem Stakeholder allgemein verständliche Anforderungen zu entlocken. Die genannten Anforderungen sind entweder zu abstrakt, oder sie gehen von nicht vorhandenen Vorkenntnissen aus. Oftmals enthalten die ermittelten Anforderungen sehr spezifische und schwer verständliche Fachbegriffe. Ganz offenbar hat der Stakeholder relativ genaue Vorstellungen davon, wie sich das zu entwickelnde Produkt verhalten soll, ist aber nicht in der Lage, Ihnen diese Anforderungen verständlich mitzuteilen.

Buchreferenz

Betrachtet man das Szenario aus Sicht der Typen nach Keirsey, so enthält die Mischung aus tiefgehendem Systemverständnis und der Schwierigkeit, dieses zu kommunizieren, Anzeichen dafür, dass es sich bei dem Stakeholder um einen  so genannten „Rational“ handelt [1,2]. Die Ursache seines Verhaltens lässt sich darauf zurückführen, dass es ihm schwer fällt, die Bedürfnisse anderer Menschen zu verstehen. Er erkennt also nicht ohne Weiteres, wie die Anforderungen beschrieben und erläutert werden müssten, damit Andersdenkende diese verstehen. Er sieht dabei seine Ideen als die einzig Richtigen an, und erwartet, dass die anderen diese entsprechend umsetzen. Er lebt gewissermaßen in seiner eigenen Welt und erwartet, dass seine Weltsicht von den Personen in seiner Umwelt übernommen wird. Ist dem nicht so, kommt es zu Missverständnissen und Problemen.

Nachdem wir den Stakeholder besser verstehen, bleibt aufzuzeigen, wie man mit ihm zu eindeutigen, richtigen und verständlichen Anforderungen kommen kann.

  • Als wichtigster Punkt erscheint uns die Verwendung eines Glossars, in welchem die unverständlichen Fachbegriffe erläutert werden. Dies zwingt den Stakeholder einerseits dazu, sich über seine Weltsicht Gedanken zu machen und diese seiner Umwelt mitzuteilen, und ermöglicht es andererseits den Benutzern der Anforderungen, die Begriffswelt des Stakeholders zu verstehen.
  • Stellen Sie dem Stakeholder eine zweite Person an die Seite, welche einerseits das Verständnis des Stakeholders zum Fachgebiet teilt und die Fachsprache versteht, aber gleichzeitig in der Lage ist, diese in eine allgemein verständliche Sprache zu übersetzen.
  • Verwenden Sie Anforderungsschablonen. Diese lassen dem Stakeholder weniger Freiräume zur Formulierung unverständlicher Sätze.
  • Fragen Sie Ihren Stakeholder, wie ein Test für die eben formulierte Anforderung seiner Meinung nach aussehen könnte. Diese Frage kann dazu beitragen, dass der Stakeholder messbare Kriterien für seine Anforderungen angibt.
  • Stellen sie möglichst geschlossene Fragen, also Fragen, die es dem Stakeholder lediglich erlauben, mit „Ja“ oder „Nein“ zu antworten. Diese Praxis verhindert, dass ein aufkeimendes Verständnis der Anforderung ihrerseits durch neue und unverständliche Beschreibungen zunichte gemacht wird.
  • Lassen Sie Ihren Stakeholder ein Anwendungsbeispiel im Detail erläutern. Dies dient der Konkretisierung der Anforderung.

Und vor allem, tun Sie folgendes nicht, wenn Sie die Anforderungen dieser Person erfolgreich erheben wollen

  • Beschäftigen Sie sich mit den Inhalten des Gesagten, niemals mit der Darstellung. Wenn der Stakeholder wüsste, wie er seine Ideen besser vermitteln kann, würde er es wahrscheinlich tun.
  • Zeigen Sie nie Ihre Verständnislosigkeit gegenüber den ermittelten Anforderungen, seien sie auch noch so schwer zu verstehen. Damit frustrieren Sie Ihren Stakeholder und verbauen sich möglicherweise die Chance auf gute und wichtige Anforderungen.
  • Formulieren Sie nicht einfach dieselben Fragen neu. Die Antworten, die Sie erhalten werden, werden selten mehr Klarheit schaffen, eher stiften die neuen Aussagen mehr Verwirrung.

Fazit: Standardantworten zum richtigen Umgang mit Menschen gibt es leider nicht – da müssen wir Sie enttäuschen. Dennoch ist es möglich, durch unsere Betrachtungsweise die in der Persönlichkeit des Einzelnen begründeten Motive für sein Verhalten zu erkennen und zu verstehen. Dieses Wissen erleichtert es einerseits, die richtige Handlungsoption zu erkennen und auszuwählen und andererseits verhindert es, durch eine falsche Herangehensweise das Problem im Umgang mit einem Menschen zu verschärfen. Im Requirements Engineering spielen diese Betrachtungen wegen des hohen Kommunikations- und Verständigungsbedarfs eine besondere Rolle.

[1] D.Keirsey: Please Understand me II, Prometheus Nemesis, 1998
[2] www.personalitypage.com

Dieser Gastbeitrag wurde von Paul Roux-Wentzel in Zusammenarbeit mit Christian Hertneck erstellt.