Requirements Engineering

Die Erfassung und Dokumentation von Anforderungen, im klassischen Entwicklungsumfeld als Lasten- und Pflichtenhefte, im agilen meist als Epics und User Stories bezeichnet, ist die Aufgabe des Requirements Engineers oder Business Analysten. Dieser ist traditionell meist ein Software-Entwickler, der die Rolle ausfüllt, weil er, im Unterschied zu den meisten seiner Kollegen, auch über einige kommunikative Fähigkeiten verfügt, die irgendwann mal ein Manager entdeckt und ihm den Job „übergeholfen“ hat.

Ich behaupte, dass diese Konstellation, gelinde gesagt, eher suboptimal ist. Interviewen, Zuhören, Coachen und Schreiben sind ganz andere Fähigkeiten als Codieren. Und das ist es, was ein Business Analyst als Primärtugenden haben sollte! Wenn er dann noch ein gewisses Grundverständnis dafür mitbringt, wie Software funktioniert – und das bekommt er quasi automatisch mit, wenn er sich ausführlich mit Tools wie UML oder BPMN beschäftigt – dann ist das völlig ausreichend. Denn beim Aufstellen eines Klassendiagramms muss er sich über Objektorientierung und Normalformen bei relationalen Datenbanken gezwungenermaßen Gedanken machen, genau wie über Verzweigungen und Schleifen, wenn er ein Ablaufdiagramm erstellt. Sich allerdings in die (unter Fachleuten oftmals sehr leidenschaftlich und existenziell geführte) Diskussion darüber einzumischen, ob eine Datenschnittstelle nun mit JSON, REST, XML oder was-weiss-ich-womit realisiert werden sollte, ist wohl eher nicht seine Aufgabe. Ich persönlich halte es sogar für schädlich, wenn der Business Analyst zu viel Fachwissen hat, weil er sich dann automatisch mehr um die Entwickler kümmert als um die Stakeholder. Und ich habe noch kein Software-Projekt erlebt, das daran gescheitert wäre, dass die Entwickler nicht gewusst haben, was sie zu tun hatten – allerdings schon einige, bei denen die Stakeholder sich unverstanden gefühlt und infolgedessen das Produkt nicht akzeptiert haben.

Ich arbeite bereits seit 2000 als Requirements Engineer, also schon seit vor Gründung meiner eigenen Firma. Seitdem habe ich Projekte in verschiedensten Branchen, insbesondere als ERP-Speziallösungen und als Datenbanken im Immobilien-/Facility- und Finanzbereich, realisiert. Ich bin in der Lage, sowohl in deutsch- als auch in englischsprachigen Arbeitsumgebungen zu agieren und habe Erfahrungen mit internationalen und multikulturellen Teams. Die sehr tiefgründige Beschäftigung mit der Materie hat auch einige Male dazu geführt, dass ich nach Umsetzung der Software-Lösung einen Interims-Manager-Vertrag oder auch eine Beteiligung an den entsprechenden Unternehmen angeboten bekommen habe.