Lad os antage at vi skal udvikle programmel der skal koble alt DSB's (Banestyrelsen, DSB Passager og DSB Gods's) strategiske, taktiske og operationelle funktioner sammen: fra de der blot understøttes til de der automatiseres.
For at kune gøre dette er det rimeligt først at sikre sig at informatikingeniøren ved DSB (etc.) forstår alle de fagtermer som berører de ønskede programmel. Hertil kræves at udviklerne først konstruerer en del-semantik for alle disse termer (af visse kaldes dette en `ontologi'). Termerne dækker over individder (observerbare tilstande mv.) og fænomener (begivenheder, handlinger, forløb). Jeg kalder dette for domæne-arbejdet, andre for videnindsamling og bearbejdning, atter andre for `ontologi'.
For dernæst at sikre sig at kundens og brugernes krav indkredses på bedst mulig måde, konstrueres en såkaldt kravspecifikation. Denne bygger på domæne-modellen. Denne sidste valideres vis-a-vis kunden og brugerne.
Endelig fastlægges programmellets arkitektur: de ydre grænseflader der bestemmes af brugerens eller andet programmels' eller andre maskiners brug, og programmellets struktur: de indre grænseflader der bl.a. tilsikrer modularitet, programmets evne til at blive flyttet mellem datamatiske ``platforme'', til at videreudvikles (evolvere), dets robusthed, sikkerhed, fejl-tolerance, mmm. Til slut sker der yderliere en række trin af forfining af programmet, fra arkitekturens og strukturens abstraktioner til den eksekverbare kodes konkretiseringer.
I de næste tre afsnit vil vi nærmere beskrive forhold i forbindelse med denne tredelte udviklingsprocess.