Klare Anforderungen

Am Ende eines erfolg­rei­chen Pro­jek­tes ste­hen Ergeb­nis­se. Wel­che Ergeb­nis­se das sind, wird vor­ab in Form von Zie­len und Anfor­de­run­gen beschrie­ben. Theo­re­tisch jeden­falls. Obwohl also Anfor­de­run­gen von so zen­tra­ler Bedeu­tung im Pro­jekt­ma­nage­ment sind, wird in der Pra­xis genau in die­ser zen­tra­len Dis­zi­plin lei­der all­zu oft nicht prä­zi­se und ordent­lich gear­bei­tet. War­um das so ist und was Sie dage­gen tun kön­nen ist Inhalt die­ses etwas län­ge­ren Exkur­ses in die Kunst des Anforderungsmanagements.

Ziel einer Anfor­de­rungs­spe­zi­fi­ka­ti­on (…) ist es, die Anfor­de­run­gen so zu for­mu­lie­ren, dass zwi­schen dem Auf­trag­ge­ber und Auf­trag­neh­mer ein gemein­sa­mes Ver­ständ­nis über das zu ent­wi­ckeln­de Sys­tem geschaf­fen wird.
Wiki­pe­dia

Soweit die Theo­rie. In der Pra­xis stellt sich das sys­te­ma­ti­sche und voll­stän­di­ge Erfas­sen, Ord­nen und Ver­wal­ten von Anfor­de­run­gen lei­der etwas schwie­ri­ger dar.

If I had asked peo­p­le what they wan­ted, they would have said fas­ter horses.
Hen­ry Ford

Die Problematik

Eh-klar“-Anforderungen

Jeder Mensch hat ein Viel­zahl von Annah­men über sei­ne Umwelt. Meis­tens sind uns die­se gar nicht bewusst. Das Pro­blem impli­zi­ter Annah­men im Rah­men des Anfor­de­rungs­ma­nage­ments hat zwei Facet­ten: Einer­seits feh­len sol­che impli­zi­ten Anfor­de­run­gen schlicht im Anfor­de­rungs­ka­ta­log; ande­rer­seits beschrän­ken die­se Annah­men den Lösungs­raum schon in der Anfor­de­rungs­de­fi­ni­ti­on. Die impli­zi­te Annah­me zur Zeit Hen­ry Fords war, dass die Fort­be­we­gung mit­tels Pferd die schnellst­mög­li­che sei.

Lösungen statt Anforderungen

Die­se impli­zi­te Annah­me über die mög­li­chen Arten der Beför­de­rung führt auto­ma­tisch zu einer geis­ti­gen Beschrän­kung des Lösungs­raums. Die eigent­li­che Anfor­de­rung der Men­schen zur Zeit Hen­ry Fords war es schnel­ler als bis­her von einem Ort zum ande­ren zum ande­ren zu gelan­gen. Anstatt aber mit einer ech­ten Anfor­de­rung unvor­ein­ge­nom­men nach Lösun­gen zu suchen, den­ken wir sehr schnell in kon­kre­ten Lösun­gen und hal­ten die vor­ge­schla­ge­ne Lösung dann für unse­re Anforderung.

Unvollständige Anforderungen

Die Fach­ex­per­ten ken­nen zwar einer­seits die Anfor­de­run­gen, sind aber ande­rer­seits sel­ten in der Lage die­se sys­te­ma­tisch und voll­stän­dig zu erfas­sen. Ins­be­son­de­re die impli­zi­ten Anfor­de­run­gen wer­den ger­ne ver­ges­sen. Aber auch Anfor­de­run­gen, die nicht-funk­tio­na­ler Natur sind, bei­spiels­wei­se die Aus­fall­si­cher­heit eines Sys­tems, wer­den ver­ges­sen, weil sie nichts mit den eigent­li­chen Arbeit zu tun haben. Trotz­dem sind gera­de die­se nicht-funk­tio­na­len Anfor­de­run­gen äußerst wich­tig für das Fin­den der rich­ti­gen Lösung.

Oft­mals blei­ben die Anfor­de­run­gen auch nur des­halb unvoll­stän­dig, weil nicht alle Nut­zer­grup­pen aus­rei­chend betrach­tet wur­den. Ger­ne ver­ges­sen wird der IT-Betrieb, der die Soft­ware nach Fer­tig­stel­lung betrei­ben soll. Zur Feh­ler­su­che und ‑behe­bung braucht der Betrei­ber in der Regel Hilfs­mit­tel wie Log­ging, also das Auf­zeich­nen von Ereig­nis­sen im Sys­tem in einem Log­file o.ä., oder Moni­to­ring, also die Mög­lich­keit das Sys­tem live zu über­wa­chen und die Funk­ti­ons­fä­hig­keit zu prü­fen. Ähn­li­ches gilt für Sicherheitsanforderungen.

Arten von Anforderungen

Anfor­de­run­gen las­sen sich grob in zwei Kate­go­rien ein­tei­len. Funk­tio­na­le Anfor­de­run­gen beschrei­ben das Ver­hal­ten des Sys­tems aus fach­li­cher Sicht, also was das Sys­tem tun soll. Nicht-funk­tio­na­le Anfor­de­run­gen hin­ge­gen beschrei­ben wie das Sys­tem sein soll, also wel­che Eigen­schaf­ten es auf­wei­sen soll.

Funktionale Anforderungen

Beschrei­bung des Ver­hal­tens des Sys­tems aus Sicht eines Nut­zers, bei­spiels­wei­se: „Das Pro­dukt soll den Sal­do eines Kon­tos zu einem Stich­tag berech­nen.“ Die Spe­zi­fi­ka­ti­on erfolgt in der Regel in natür­li­cher Spra­che. For­ma­le Spe­zi­fi­ka­tio­nen fin­den nur bei sehr kri­ti­schen Tei­len Anwen­dung deren Kor­rekt­heit mathe­ma­tisch bewie­sen wer­den soll, bei­spiels­wei­se die Steue­rungs­soft­ware einer Rakete.

Da natür­li­che Spra­che immer auch zu Miss­ver­ständ­nis­sen führt, ist ein ein­heit­li­ches For­mat für die Anfor­de­run­gen unbe­dingt anzu­ra­ten. Bewährt in der Pra­xis haben sich bei­spiels­wei­se User-Sto­ries in der Form: „Als <Rol­le> möch­te ich <Ziel/Wunsch>, um <Nut­zen>.“ Das ein­gangs ange­führ­te Bei­spiel wür­de als User Sto­ry etwa so lau­ten: „Als Kon­to­in­ha­ber möch­te ich den Sal­do mei­nes Kon­tos zu einem Stich­tag sehen, um eine schnel­le Über­sicht mei­ner finan­zi­el­len Lage zu erhalten.“

Ein wei­te­rer wich­ti­ger Bestand­teil von Anfor­de­run­gen sind Akzep­tanz­kri­te­ri­en. Sie legen fest, wie bewer­tet wird, inwie­weit eine Anfor­de­rung erfolg­reich umge­setzt wur­de. Im agi­len Vor­ge­hen hei­ßen die­se Kri­te­ri­en daher auch die „Defi­ni­ti­on of Done“. Teil­wei­se wer­den auch Test­fäl­le zusam­men mit den Anfor­de­run­gen spe­zi­fi­ziert. Wer­den die­se dann als Unit-Tests ein­ge­setzt und die Anfor­de­rung wäh­rend der Pro­gram­mie­rung stän­dig gegen die­se Tests geprüft spricht man auch von Test-Dri­ven-Deve­lo­p­ment.

Nichtfunktionale Anforderungen

Nicht-funk­tio­na­le Anfor­de­run­gen beschrei­ben die Eigen­schaf­ten eines Sys­tems. Die­se las­sen sich grob in zwei Kate­go­rien ein­tei­len: in Eigen­schaf­ten der Aus­füh­rung, bei­spiels­wei­se Benutz­bar­keit oder Ant­wort­zei­ten, und Eigen­schaf­ten der Evo­lu­ti­on, bei­spiels­wei­se die Wart­bar­keit oder die Por­tier­bar­keit. Wei­te­re Bei­spie­le fin­den sich in Wiki­pe­dia:

Methodik

Erarbeiten in Workshops

Theo­re­tisch wür­de es rei­chen, wenn die Fach- und IT-Exper­ten gemein­sam die funk­tio­na­len und nicht-funk­tio­na­len Anfor­de­run­gen auf­schrie­ben. Auf­grund von impli­zi­ten Annah­men, Lösungs­den­ken und feh­len­der Sys­te­ma­tik blei­ben die Ergeb­nis­se dann aber in der Regel sub­op­ti­mal. Es hat sich bewährt, wenn ein erfah­re­ner Mode­ra­tor die­sen Pro­zess sau­ber führt. Hier­bei ist es wich­ti­ger, dass der Mode­ra­tor die Mode­ra­ti­on der Grup­pe und die Metho­dik beherrscht, weni­ger den Fach­pro­zess selbst. Meist ist es vom Vor­teil eher fach­fremd zu sein, weil es dann leich­ter fällt, schein­bar dum­me Fra­gen zu stel­len und inten­si­ver nach­zu­ha­ken, um damit impli­zi­te Annah­men her­aus­zu­ar­bei­ten. In der Regel sind meh­re­re Work­shops not­wen­dig, um die Anfor­de­run­gen nach und nach zu ver­fei­nern und zu vervollständigen.

Vom Groben zum Feinen

Meis­tens bie­tet sich ein Vor­ge­hen vom Gro­ben zum Fei­nen an. Zunächst iden­ti­fi­ziert man dazu in sich abge­schlos­se­ne Berei­che der Anwen­dung. Eine Online-Ban­king Anwen­dung hat zum Bei­spiel ein Modul Report­ing in dem der Nut­zer sich über sei­nen Kon­to­stand infor­mie­ren kann; davon los­ge­löst gibt es ein Modul Ban­king in dem der Nut­zer Über­wei­sun­gen und Dau­er­auf­trä­ge ein­rich­ten kann. Gegen­stand des ers­ten Work­shops soll­te genau die­ser gro­be Über­blick über die ver­schie­de­nen Modu­le sein, qua­si eine Land­kar­te als Über­sicht. In den fol­gen­den Work­shops wer­den dann die Funk­tio­nen die­ser Modu­le nach und nach ver­fei­nert. Auch dabei geht man am bes­ten vom Gro­ben zum Feinen.

Format

Ein ein­heit­li­ches For­mat, bei­spiels­wei­se in Form von User-Sto­ries, ist sehr hilf­reich. Hier­für braucht es unbe­dingt einen erfah­re­nen Mode­ra­tor, der auf die Ein­hal­tung ach­tet. Nun stellt sich die ganz prak­ti­sche Fra­ge, wie und wo die­se Anfor­de­run­gen am bes­ten doku­men­tiert wer­den. Die ein­fachs­te und am häu­figs­ten gewähl­te Lösung ist die sprach­li­che Beschrei­bung der ver­ein­bar­ten Anfor­de­run­gen in einem Text­do­ku­ment. Vor­teil dabei ist es, dass der zum Zeit­punkt der Abnah­me die­ses Doku­ments gül­ti­ge und (hof­fent­lich) kon­sis­ten­te Stand der Anfor­de­run­gen zusam­men­hän­gend in einem Doku­ment beschrie­ben ist.

Theo­re­tisch geht man nun davon aus, dass die­ser Stand mehr oder weni­ger 1:1 umge­setzt wird, was prak­tisch so nie pas­siert. Die Anfor­de­run­gen leben wei­ter, ändern sich, eini­ge fal­len weg und ande­re kom­men hin­zu. Ein sol­ches mono­li­thi­sches Doku­ment an die­se Ände­run­gen anzu­pas­sen ist sehr auf­wän­dig und wird in der Pra­xis kaum gemacht. Statt­des­sen wer­den die Ände­run­gen in Ergän­zungs­do­ku­men­ten beschrie­ben. Um sich nach einer Wei­le den gül­ti­gen Stand der Anfor­de­run­gen zu erschlie­ßen, ist es dann aber not­wen­dig beim ursprüng­li­chen Doku­ment zu star­ten und anschlie­ßend alle Ände­rungs­do­ku­men­te zu sichten.

Ein wei­te­rer Nach­teil eines sol­chen Anfor­de­rungs­do­ku­ments ist die Tren­nung von Ergeb­nis und Dis­kus­si­on. Ein Doku­ment hält immer nur das Ergeb­nis fest, aber nicht die Ent­ste­hungs­ge­schich­te einer Anfor­de­rung. Gera­de wenn Anfor­de­run­gen sich ent­wi­ckeln und wei­ter­ent­wi­ckeln, ist die Dis­kus­si­on zur Anfor­de­rung eine hilf­rei­che Informationsquelle.

Werkzeuge

An die­ser Stel­le bie­ten sich pro­fes­sio­nel­le Tools zum Anfor­de­rungs­ma­nage­ment an, die im Wesent­li­chen alle die Mög­lich­keit bie­ten Anfor­de­run­gen fein gra­nu­lar zu defi­nie­ren, zu grup­pie­ren, mit einem Sta­tus zu ver­se­hen und zu jeder Anfor­de­rung eine Dis­kus­si­on zu füh­ren. Zum Zeit­punkt der ganz­heit­li­chen Erhe­bung der Anfor­de­run­gen erscheint ein sol­ches Tool meist ein wenig über­di­men­sio­niert, lohnt sich aber spä­tes­tens wenn die Anfor­de­run­gen über Mona­te und Jah­re hin­weg sich verändern.

Pro­fes­sio­nel­le Werk­zeu­ge zur Ver­wal­tung von Anfor­de­run­gen gibt es sehr vie­le. Ihr gro­ßer Vor­teil ist gleich­zei­tig für vie­le ihr größ­ter Nach­teil: Die­se Sys­te­me behan­deln Anfor­de­run­gen als ato­ma­re Objek­te, die über ver­schie­de­ne Attri­bu­te (Beschrei­bung, Auf­wand, Sta­tus, etc.) ver­fü­gen und mit­ein­an­der in Bezie­hung ste­hen kön­nen (Abhän­gig­kei­ten). Men­schen die mono­li­thi­sche Doku­men­te in Pro­sa gewohnt sind und schät­zen, haben damit in der Regel Mühe. Die Vor­tei­le eines guten Werk­zeugs über­wie­gen aber die­sen Nach­teil der Umge­wöh­nung bei weitem:

  • Eine zen­tra­le Abla­ge aller Anforderungen.
  • Durch meh­re­re Benut­zer gleich­zei­tig zu bearbeiten.
  • His­to­ri­sie­rung und Rück­ver­folg­bar­keit: Ände­run­gen an Anfor­de­run­gen wer­den pro­to­kol­liert; his­to­ri­sche Ver­sio­nen sind jeder­zeit abrufbar.
  • Zuge­hö­ri­ge Meta­in­for­ma­tio­nen an glei­cher Stel­le: Attri­bu­te und Dis­kus­sio­nen / Kom­men­ta­re zur jewei­li­gen Anforderung.
  • Anfor­de­run­gen kön­nen mit­ein­an­der in Bezie­hung gesetzt wer­den (A ist Vor­aus­set­zung für B)
  • Ver­bin­dung von Anfor­de­rung mit Testfällen.

Fahren auf Sicht

Es ist ver­füh­re­risch, die Anfor­de­run­gen voll­stän­dig spe­zi­fi­zie­ren zu wol­len bevor man zur Umset­zung schrei­tet. Dahin­ter steckt immer noch der Irr­glau­be, dass eine voll­stän­di­ge und kor­rek­te Spe­zi­fi­ka­ti­on mög­lich und sinn­voll sei. Tat­säch­lich stellt man wäh­rend der Umset­zung fest, dass vie­le Anfor­de­run­gen unnütz, unklar oder nicht kor­rekt sind. Meist ist es bes­ser und bil­li­ger auf Sicht zu fah­ren und nur im Detail zu spe­zi­fi­zie­ren was tat­säch­lich als nächs­tes umge­setzt wer­den soll.

Ein Kri­te­ri­um ob es bes­ser ist auf Sicht zu fah­ren oder man getrost voll­stän­dig spe­zi­fi­zie­ren kann lie­fert das Cyne­fin-Frame­work zur Klas­si­fi­ka­ti­on des Vor­ha­bens in die fol­gen­den Kategorien:

Simp­le
Bezie­hung zwi­schen Ursa­che und Wir­kung ist für alle offensichtlich.
Com­pli­ca­ted
Bezie­hung zwi­schen Ursa­che und Wir­kung erfor­dert Ana­ly­se und/oder die Anwen­dung von Fachwissen.
Com­plex
Bezie­hung zwi­schen Ursa­che und Wir­kung kann nur im Nach­hin­ein wahr­ge­nom­men werden.
Chao­tic
Es gibt kei­ne Bezie­hung zwi­schen Ursa­che und Wir­kung auf Systemebene.

Die aller­meis­ten Vor­ha­ben wer­den ent­we­der kom­pli­ziert oder kom­plex sein. Sind sie kom­pli­ziert, bei­spiels­wei­se die Kon­struk­ti­on eines Flug­zeugs oder eines Hoch­hau­ses, ist eine voll­stän­di­ge Spe­zi­fi­ka­ti­on mög­lich und sinn­voll. Bei einem kom­ple­xen Vor­ha­ben, bei­spiels­wei­se ein neu­er Ser­vice für eine unbe­kann­te Kun­den­grup­pe, ist unbe­dingt ein Fah­ren auf Sicht angeraten.

tl;dr

Weil es so ein­fach und grund­le­gend erscheint, fin­det das sys­te­ma­ti­sche Erfas­sen und Ord­nen der Anfor­de­run­gen an die Pro­jekt­er­geb­nis­se lei­der viel zu sel­ten die not­wen­di­ge Auf­merk­sam­keit. Eben Mal schnell die Anfor­de­run­gen von den Fach­ex­per­ten in irgend­ei­nem For­mat zusam­men­zu­tra­gen und abzu­stim­men, führt zu unvoll­stän­di­gen, unver­ständ­li­chen und schlecht hand­hab­ba­ren Anfor­de­run­gen. Ein fach­frem­der oder wenigs­tens fach­fer­ner pro­fes­sio­nel­ler Mode­ra­tor kann die­sen Pro­zess der Anfor­de­rungs­er­he­bung und des Anfor­de­rungs­ma­nage­ments deut­lich beschleu­ni­gen und pro­fes­sio­na­li­sie­ren. Im wei­te­ren Pro­jekt­ver­lauf lohnt sich die anfäng­lich Inves­ti­ti­on in ein pro­fes­sio­nel­les Anfor­de­rungs­ma­nage­ment inner­halb kür­zes­ter Zeit.

Arti­kel­bild: Sean MacEn­tee bei flickr.com (CC BY 2.0)



Share This Post

Von Marcus Raitner

Hi, ich bin Marcus. Ich bin der festen Überzeugung, dass Elefanten tanzen können. Daher begleite ich Organisationen auf ihrem Weg zu mehr Agilität. Über die Themen Führung, Digitalisierung, Neue Arbeit, Agilität und vieles mehr schreibe ich seit 2010 in diesem Blog. Mehr über mich.

3 Kommentare

Eine sehr gute Zusam­men­fas­sung der wesent­li­chen Pro­ble­me und des Sinn und Zwecks guten Requi­re­ments Engi­nee­ring. Nach­dem ich dies in einem Soft­ware Ent­wick­lungs-Pro­jekt nach Scrum von der Pike auf gelernt hat­te, muss­te ich mit Erstau­nen oder Erschre­cken fest­stel­len, wie wenig das in ande­ren Pro­jek­ten berück­sich­tigt wird. Auch wird sehr häu­fig der Bereich der Anfor­de­rungs­do­ku­men­ta­ti­on ver­nach­läs­sigt oder igno­riert, so das man die Anfor­de­run­gen höchs­tens aus der Soft­ware oder dem Quell­code able­sen kann.

Lie­ber Mar­cus, klas­se Arti­kel. Dan­ke, danke.
Lei­der wird heu­te soviel wert auf tech­ni­sche Umset­zung gelegt, dass die sau­be­re Erfas­sung der Anfor­de­run­gen schnell in den Hin­ter­grund gerät. Umso wich­ti­ger, dass ein unter­stüt­zen­des Werk­zeug eben jenes ist: eine Hil­fe und nicht eine zusätz­li­che Admi­nis­tra­ti­ons­bür­de. Für Werk­zeug­tipps aus der Pra­xis wäre ich sehr dankbar.

Rei­ner

Vie­len Dank für dei­nen Kom­men­tar, Rei­ner. Da ich im Moment fast aus­schließ­lich agil arbei­te (und das auch nicht mehr in Pro­jek­ten, aber das ist eine ande­re Geschich­te), bin ich ein gro­ßer Freund von JIRA (evtl. mit dem Port­fo­lio-Plug­in wenn es mal grö­ßer wird). Wenn es weni­ger digi­tal und mehr phy­sisch sein soll, dann geht nichts über eine gro­ße Wand und vie­le Post-Its ;-) Als metho­di­sche Hil­fe beim Struk­tu­rie­ren der Anfor­de­run­gen kann ich Sto­ry Map­ping oder Impact Map­ping sehr empfehlen.

Schreibe einen Kommentar