Einer der ersten Schritte bei der Anforderungsanalyse ist die Spezifikation des Systemkontextes und die Abgrenzung des Systems vom Systemkontext.
In der Literatur wird dazu oft das System als derjenige Teil der Realität definiert, der durch das Projekt verändert, beeinflusst oder neu gestaltet wird. Der Kontext hingegen ist der Teil, der das System zwar beeinflusst, der aber durch das Projekt selbst nicht verändert wird.
So weit – so gut. Leider wird in der Literatur im Weiteren beim „System“ nur von der Software, die neu entwickelt oder angepasst werden soll, geschrieben, vielleicht noch von der Hardware und der Infrastruktur, die diese Software benötigt. Und da beginnt ein wesentliches konzeptionelles Problem des Projektes.
Praktisch jedes Softwareprojekt greift auch in die Geschäftsprozesse ein, in denen die Software, die der eigentliche Gegenstand des Projektes ist, zum Einsatz kommt. Es ist gut, wenn diese Geschäftsprozesse deshalb mit zum System und nicht zum Kontext gezählt werden. Dann wird eine grundsätzliche Analyse der bestehenden Prozesse und eine Spezifikation der geänderten Prozesse in fachlichen Use Cases nicht mehr dem Zufall überlassen, sondern als notwendiger Teil des Spezifikationsprozesses betrachtet.
Das hat zur Folge, dass parallel zur Softwareentwicklung der Prozess des Change Managements in der betroffenen Organisation startet. So kann man dafür sorgen, dass das Change Management nicht mehr Stiefkind des Projektes ist, sondern so priorisiert wird, wie es seinem Anteil am Projekterfolg – oder Misserfolg – in der Praxis entspricht.