Hallo,
eine Ist-Analyse und ein Soll-Konzept sind schon wichtig, um auch in der Dokumentation deutlich herauszustellen, warum der jetzige Zustand verbesserungswürdig ist (denn Dein Projekt muss ja in irgendeiner Form nützlich und sinnvoll sein) und in welcher Form Du Deine Verbesserungen umsetzen möchtest. Du könntest das zum Beispiel in diese Punkte einfliessen lassen:
Wenn ich Deine Gliederung richtig verstehe, möchtest Du VoIP einführen und ein bestehendes ISDN-Telefonnetz/Anlage ablösen (die Angabe des genauen Projektthemas wäre nicht schlecht gewesen).
Dadurch, dass Du schon Vor- und Nachteile abwägst und die Funktionsweise von VoIP erklärst, muss ja der vorher herrschende Zustand ablösungsreif sein. Also hast Du mehr oder weniger eine Ist-Analyse schon gemacht und Dir überlegt, wie man etwas besser machen kann (mit VoIP). Somit hast Du auch schon ein Soll-Konzept.
Du könntest die Punkte zum Beispiel so Aufziehen oder Umbiegen, dass Du Punkt 3 damit beginnst, indem Du die Vorher-Struktur beschreibst und aufzeigst, warum das so nicht mehr so gut ist (z.B. hohe Kosten, extra-Leitungen mit entsprechender Infrastruktur usw.). Dann machst Du weiter, indem Du darlegst, welche Gründe dafür sprechen, die Vorher-Struktur durch VoIP abzulösen (dabei nicht vergessen zu begründen, warum mögliche andere Alternativen nicht gewählt wurden, wenn vorhanden). Dabei kannst Du dann auch das, was Du in Punkt 4 erklären möchtest, einfliessen lassen und die Punkte quasi zusammenmischen.
Dann solltest Du das drinhaben, was wichtig ist: Du hast geguckt, was vorhanden ist, hast Nachteile darin entdeckt, hast überlegt, wie man es besser machen kann und begründest Deine Entscheidung.
PS: Zusatztipp: Ich würde in Punkt 6 oder 7 eine Kosten-Nutzen-Gegenüberstellung noch einbinden (falls Du das nicht vorgehabt haben solltest).