Eine Anfor­de­rungs­spe­zi­fi­ka­ti­on schafft die Basis für die Ent­wurfs­pha­se. Sie defi­niert klar Kun­den­wün­sche für das zukünf­ti­ge IT-Sys­tem und ist uner­läss­lich im wei­te­ren Ent­wick­lungs­pro­zess von IT-Pro­jek­ten. Im Las­ten­heft wer­den die Anfor­de­run­gen prä­zi­se aus­for­mu­liert. So soll­te es auch sein, denn wenn eine Anfor­de­rungs­spe­zi­fi­ka­ti­on unklar defi­niert wird, kann die­ser Umstand schwer­wie­gen­de Fol­gen haben, da die Qua­li­tät einer Anfor­de­rungs­spe­zi­fi­ka­ti­on star­ken Ein­fluss auf die Qua­li­tät des zu ent­wi­ckeln­den Pro­jekts hat.

1. Die rich­ti­ge Anfor­de­rungs­spe­zi­fi­ka­ti­on

Nach einer erfolg­rei­chen Ana­ly­se liegt als Ergeb­nis eine Anfor­de­rungs­spe­zi­fi­ka­ti­on inklu­si­ve Schlüs­sel­me­cha­nis­men vor. Funk­tio­na­le Anfor­de­run­gen sind geeig­net, Aus­sa­gen dar­über zu tref­fen, was das Sys­tem im Ein­zel­fall leis­ten kön­nen soll. Nicht funk­tio­na­le Anfor­de­run­gen bezie­hen sich auf Eigen­schaf­ten, wie die Benut­zer­ober­flä­che, Spei­cher­nut­zung oder Reak­ti­ons­zeit. Die Anfor­de­run­gen sol­len nur fest­le­gen, wel­che Eigen­schaf­ten das Pro­dukt haben soll und nicht, wie die­se Eigen­schaf­ten rea­li­siert wer­den. Dafür sind Black­box-Beschrei­bun­gen gut geeig­net. Bei kom­ple­xe­ren Zusam­men­hän­gen ist eine White­box sinn­vol­ler. Ein vor­läu­fi­ger Pro­jekt­plan kann dann erstellt wer­den.

2. Wor­auf ist zu ach­ten?

Jede Anfor­de­rung muss kor­rekt durch die Soft­ware erfüllt wer­den. Daher soll­te jede Anfor­de­rung nur eine ein­deu­ti­ge Inter­pre­ta­ti­on mit einer mög­li­chen Rück­ver­fol­gung auf die Quel­le haben. Ein­zel­ne Begriffs­de­fi­ni­tio­nen sind hier­bei von Bedeu­tung. Not­wen­dig ist die Voll­stän­dig­keit hin­sicht­lich des Ver­hal­tens in ver­schie­de­nen, denk­ba­ren Situa­tio­nen, wie bei­spiels­wei­se bei feh­ler­haf­ten Ein­ga­be­da­ten.
Es dür­fen aber nicht nur die funk­tio­na­len Anfor­de­run­gen erfüllt wer­den. Eine Struk­tur besitzt genorm­te Kon­sis­tenz. Für iden­ti­sche Objek­te und Sach­ver­hal­te dür­fen nicht ver­schie­de­ne Begrif­fe ver­wen­det wer­den. Die ein­zel­nen Anfor­de­run­gen müs­sen logisch auf­ge­baut wer­den und dür­fen sich nicht wider­spre­chen. Sie soll­ten mit einer Gewich­tung hin­sicht­lich der Sta­bi­li­tät, Soll- und Wunsch­an­for­de­run­gen ver­se­hen wer­den. Die Anfor­de­run­gen soll­ten über­prüf­bar sein. Der Aus­druck benut­zer­freund­lich oder feh­ler­frei ist nicht aus­rei­chend. Jede Anfor­de­rung soll­te ein­deu­tig defi­niert sein.

3. Spe­zi­fi­ka­ti­on bei neu­en IT-Pro­jek­ten und Pro­jek­ten der Wei­ter­ent­wick­lung

Es erscheint als sinn­voll ein neu­es IT-Pro­jekt als einen dyna­misch inter­ak­ti­ven Pro­zess zu ver­ste­hen. Am Ende ent­steht das von allen Betei­lig­ten gewünsch­te IT-Sys­tem.
Das Grund­prin­zip soll­te sein, Ver­trau­en zu schaf­fen. Die Fach­ab­tei­lung und der IT-Lie­fe­rant ler­nen gegen­sei­tig die Bedürf­nis­se und Denk­wei­se des ande­ren ken­nen. Das ist eine Grund­vor­aus­set­zung für eine Ver­trau­ens­ba­sis.
Zeit und Auf­wand wer­den ein­ge­spart, wenn bei der detail­lier­ten Spe­zi­fi­ka­ti­on im Vor­feld zusätz­lich eine inten­si­ve Kom­mu­ni­ka­ti­on im Ver­lauf der Wei­ter­ent­wick­lung statt­fin­det. Regel­mä­ßi­ge Tests geben ein früh­zei­ti­ges Feed­back zur Spe­zi­fi­ka­ti­on.