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)