Fort­bil­dun­gen in der SYSTHEMIS

SYST­HE­MIS-Exper­ten arbei­ten in ver­ant­wor­tungs­vol­len Posi­tio­nen in ver­schie­dens­ten Pro­jek­ten. Um den Ansprü­chen unse­rer Kun­den gerecht zu wer­den, ist ste­ti­ge Wei­ter­bil­dung und die Opti­mie­rung unse­rer Abläu­fe uner­läss­lich. In einer zwei­tä­gi­gen Schu­lung mit der Exper­tin Sabi­ne Zehn­der-Samu­els haben wir unse­re Kennt­nis­se in die­sem Bereich auf den neu­es­ten Stand gebracht und auch unse­re bewähr­ten Pro­zes­se auf den Prüf­stand gestellt.

Was ist Requirements-Engineering?

Der Grund­stein für den Erfolg jedes ambi­tio­nier­ten Pro­jekts wird bereits ganz zu Beginn mit dem Erar­bei­ten der rich­ti­gen Anfor­de­run­gen gelegt. Was will der Kun­de? Weiß er über­haupt genau, was er will? Und spre­chen alle Stake­hol­der die­sel­be Spra­che, wenn es um die For­mu­lie­rung der gemein­sa­men Zie­le geht? Der Schlüs­sel zu all die­sen Fra­gen ist das Requi­re­ments-Engi­nee­ring.  Zur grund­le­gen­den Begriffs­klä­rung wer­fen wir einen Blick in die Defi­ni­ti­on des Inter­na­tio­nal Requi­re­ments Engi­nee­ring Board (IREB):

Das Requi­re­ments-Engi­nee­ring ist ein sys­te­ma­ti­scher und dis­zi­pli­nier­ter Ansatz zur Spe­zi­fi­ka­ti­on und zum Manage­ment von Anfor­de­run­gen mit den fol­gen­den Zie­len: die Wün­sche und Bedürf­nis­se der Stake­hol­der zu ver­ste­hen und das Risi­ko zu mini­mie­ren, ein Pro­dukt, das nicht die­se Wün­sche und Bedürf­nis­se erfüllt, auszuliefern.“ *

Zu Beginn der Schu­lung gab ein dif­fe­ren­zier­ter Blick auf die Dimen­sio­nen des Requi­re­ments Engi­nee­ring als Dis­zi­plin bereits wich­ti­ge Erkennt­nis­se. Denn es ist dabei lan­ge nicht getan mit rei­nem Anfor­de­rungs­ma­nage­ment. Requi­re­ments-Engi­nee­ring ist die Sum­me aus ver­schie­de­nen Teil­dis­zi­pli­nen: wie erhe­be ich Anfor­de­run­gen, wie doku­men­tie­re ich sie, wie mana­ge ich sie und wie siche­re ich Qua­li­tät? Dabei wird bereits in den ers­ten Schrit­ten, der Erhe­bung und Doku­men­ta­ti­on von Anfor­de­run­gen, der Grund­stein für ein gelun­ge­nes Pro­jekt gelegt. Wenn in IT-Pro­jek­ten Bud­gets oder Dead­lines über­schrit­ten wer­den, liegt dies häu­fig dar­an, dass im Lau­fe des Ent­wick­lungs­pro­zes­ses noch Anfor­de­run­gen über­ar­bei­tet wer­den müs­sen, weil sich her­aus­stellt, dass bereits bei deren Erhe­bung und Doku­men­ta­ti­on Miss­ver­ständ­nis­se ent­stan­den sind, die dann durch die fol­gen­den Pro­jekt­pha­sen mit­ge­schleppt wurden.

Die Rolle des Requirements-Engineers

Das Ent­ste­hen sol­cher Miss­ver­ständ­nis­se im gesam­ten Pro­jekt zu ver­hin­dern, ist Auf­ga­be des Requi­re­ments-Engi­neers. Des­sen Rol­le ist am ehes­ten als die eines Ver­mitt­lers zu sehen, der die Inter­es­sen und Wün­sche aller Stake­hol­der jeder­zeit im Blick hat und der idea­ler­wei­se die Spra­che aller Betei­lig­ter glei­cher­ma­ßen zu spre­chen ver­mag. Im inners­ten Kreis des Pro­jek­tes arbei­tet er mit abso­lu­ten Fach­ex­per­ten zusam­men, wei­ter außen sitzt die Pro­jekt­lei­tung, dann fol­gen die Abtei­lungs­lei­tung und letzt­lich ganz außen die Ent­schei­der. Der Requi­re­ments-Engi­neer ist damit gewis­ser­ma­ßen die kom­mu­ni­ka­ti­ve Schalt­zen­tra­le des gesam­ten Pro­jekts, wo alle Fäden zusam­men­lau­fen. Er ist dafür ver­ant­wort­lich, dass auch der Geschäfts­füh­rer ver­steht, wovon der inners­te Kreis der Ent­wick­ler spricht. Die­se Rol­le lässt sich nicht her­un­ter­bre­chen auf das blo­ße Abschrei­ben von Anfor­de­run­gen: es geht um einen erheb­li­chen Mehr­auf­wand, der sich letzt­lich jedoch lohnt.

Des­halb ist größ­te Skep­sis ange­bracht, wenn es von Kun­den­sei­te heißt: „Das macht der Pro­jekt­lei­ter oder Pro­dukt­ma­na­ger mit.“ Genau die­se Her­an­ge­hens­wei­se führt näm­lich häu­fig dazu, dass die Rol­le stief­müt­ter­lich behan­delt wird. Es ist wich­tig, sich bewusst zu machen, dass ein Pro­jekt nicht mit dem Kick­off-Work­shop beginnt. Die wich­tigs­te Arbeit des Requi­re­ments-Engi­neers fin­det weit vor­her statt.

Methoden

Um den Stake­hol­dern die für ihn rele­van­ten Infor­ma­tio­nen zu ent­lo­cken, bedient sich der Requi­re­ments-Engi­neer ver­schie­dens­ter Metho­den, vor allem aus dem Bereich der Psy­cho­lo­gie. Ob Fra­ge­bö­gen – wie bei­spiels­wei­se die Del­phi-Metho­de – Inter­views oder Beob­ach­tungs­tech­ni­ken: rich­tig ange­wen­det lie­fern sie ihm ziel­ge­nau das gesuch­te Wis­sen und hel­fen ihm, den Stake­hol­der, des­sen Wis­sens­stand und des­sen Wün­sche bes­ser zu verstehen.

Das kann von Pro­jekt zu Pro­jekt kom­plett unter­schied­lich aus­se­hen. Mög­li­cher­wei­se bekom­men wir bereits einen Use Case, den es zu erfül­len gilt, oder es besteht bereits ein Stan­dard­pro­dukt, auf dem wir auf­bau­en sol­len. Es gibt aber auch Pro­jek­te, in denen die Stake­hol­der zu Beginn noch kei­ne kon­kre­te Vor­stel­lung vom gewünsch­ten End­pro­dukt haben. Bei einem sol­chen Start auf der grü­nen Wie­se bie­ten sich Krea­tiv­tech­ni­ken wie Brain­stor­ming oder Mind-Map­ping an, um gemein­sam eine Visi­on zu ent­wi­ckeln. Akku­ra­te und ziel­ge­rich­te­te Kom­mu­ni­ka­ti­on, kom­bi­niert mit der Aus­wahl der rich­ti­gen kom­mu­ni­ka­ti­ven Werk­zeu­ge, sind das A und O des Requirements-Engineers.

Requirements-Engineering in unserem Arbeitsalltag

Wir haben fest­ge­stellt, auch durch die Erkennt­nis­se der Schu­lung, dass wir als Pro­duct-Owner, Pro­jekt­lei­ter oder Orga­ni­sa­ti­ons­be­ra­ter in der Ver­gan­gen­heit häu­fig Auf­ga­ben eines Requi­re­ments-Engi­neers mit­über­nom­men haben, obwohl die Rol­le im Pro­jekt so nur teil­wei­se oder gar nicht vor­ge­se­hen war. Das zeigt, wie die Rele­vanz und Trag­wei­te die­ser Funk­ti­on immer noch mas­siv unter­schätzt wer­den. Das umfas­sen­de Manage­ment von Anfor­de­run­gen ist nichts, was man neben­bei machen kann. Eine kla­re Abgren­zung ist hier wich­tig, schon allein auf­grund des gro­ßen Auf­wands, den die­se Rol­le mit sich bringt. Es ist unrea­lis­tisch, zu erwar­ten, dass mit einem Work­shop beim Kun­den mal neben­bei Anfor­de­run­gen erho­ben wer­den kön­nen, die dann auch noch ein­deu­tig sind und als Basis für das gan­ze Pro­jekt ausreichen.

Des­halb haben wir beschlos­sen, die­se Erkennt­nis­se in unse­re lau­fen­den und zukünf­ti­gen Pro­jek­te zu tra­gen und einen dem­entspre­chen­den Werk­zeug­kas­ten in der SYST­HE­MIS ein­zu­füh­ren, aus dem wir uns alle bedie­nen kön­nen. Wir haben bereits Tem­pla­tes erar­bei­tet, die jetzt stan­dar­di­siert wer­den. Das soll zu einem Best Prac­ti­ce füh­ren, zu einem all­ge­mei­nen Leit­fa­den auf Basis eines Tool­sets wie Con­fluence und Jira. Im Ergeb­nis wird es ein ein­heit­li­ches und abge­stimm­tes Vor­ge­hen geben, wie wir in bestehen­den Pro­jek­ten dahin­ge­hend nach­steu­ern kön­nen und wie wir neue Pro­jek­te aufsetzen.

* Rupp, Chris und die SOPHIS­Ten: Requi­re­ments-Engi­nee­ring und ‑Manage­ment. Das Hand­buch für Anfor­de­run­gen in jeder Situa­ti­on, 7. Auf­la­ge, Nürn­berg, Deutsch­land, Han­ser, 2020, S.18.