Was ist eine Software-Spezifikation und warum sollte man sie nicht unterschätzen?

Die Softwarespezifikation ist eines der wichtigsten Dokumente in der Softwareentwicklung. Dennoch ist es ein Begriff, der von Unternehmen oft unterschiedlich interpretiert wird - manchmal vereinfachend als "Anforderungsliste", manchmal als "Kundenauftrag". Die Realität ist jedoch viel umfassender und tiefer. Eine gut ausgearbeitete Softwarespezifikation kann beide Seiten einer Zusammenarbeit schützen und das Risiko, dass ein Projekt an der Zeit, am Budget oder an Missverständnissen scheitert, erheblich verringern.

In diesem Artikel erklären wir im Detail, was eine Softwarespezifikation ist und was nicht, was sie enthält, warum sie wichtig ist und wem sie hilft, und wie wir bei TRITON IT damit arbeiten.

Was ist eine Softwarespezifikation?

Eine Softwarespezifikation ist ein detailliertes Dokument, das beschreibt, was erstellt werden soll, wie es funktionieren soll, unter welchen Bedingungen das Ergebnis als fertig angesehen wird und welche Risiken zu berücksichtigen sind. Sie ist nicht nur eine "Wunschliste" oder ein auf Papier geschriebener Auftrag. Es handelt sich um eine förmliche Vereinbarung zwischen dem Kunden und dem Lieferanten, in der die spezifischen Anforderungen und Erwartungen festgelegt sind, die beide Seiten vereinbart haben.

Die Erstellung eines Pflichtenheftes ist in der Regel Gegenstand einer separaten Preisgestaltung, denn nur auf dieser Grundlage lässt sich der Preis für das Projekt zuverlässig bestimmen - vorausgesetzt, er ist im Voraus festzulegen und steht fest. Bei agilen Entwicklungsmethoden kann der Gesamtpreis in Abhängigkeit von den Entwicklungsstufen variieren. Daher enthält die Spezifikation oft eine detaillierte Beschreibung der Arbeit und ihrer Architektur in Form von Text oder z. B. UML-Diagrammen.

Was ist UML?

UML (Unified Modeling Language) ist eine standardisierte Sprache für die visuelle Modellierung von Softwaresystemen. Sie wird verwendet, um die Struktur, das Verhalten und die Architektur eines Systems mithilfe von Diagrammen zu erfassen, die den Entwurf, die Analyse und die Kommunikation zwischen Entwicklern erleichtern. UML hilft bei der Umsetzung von Ideen in verständliche Modelle.

Was ist PlantUML?

PlantUML ist eine Beschreibungssprache, mit der UML-Diagramme in einer textuellen und standardisierten Weise definiert werden können. Während UML selbst nur eine grafische Notation ist, bietet PlantUML eine Möglichkeit, diese Diagramme mit einfachem Code zu erstellen. Dies ermöglicht die einfache Integration in Versionierungssysteme, die Automatisierung der Dokumentation und auch die Erzeugung von Diagrammen mit Hilfe von KI, wie z. B. großen Sprachmodellen (LLMs). Dies ermöglicht Softwarearchitekten, KI-gestützte Systemarchitekturen effizienter zu entwerfen.

Die Spezifikation zielt darauf ab, Mehrdeutigkeiten zu beseitigen. In dem Moment, in dem die Entwicklung ohne eine präzise Spezifikation beginnt, entstehen Annahmen, Interpretationen und Fehlerquellen. Eine gute Spezifikation legt die Spielregeln fest - für Entwicklung, Tests und Übergabe.

Was beinhaltet eine Softwarespezifikation?

Eine Softwarespezifikation ist ein präziser und detaillierter Leitfaden dafür, wie das Ergebnis aussehen soll. Stellen Sie sich das wie einen detaillierten Bauplan für ein Haus vor - wenn Sie ein Haus wollen, reicht es nicht, zu sagen: "Ich möchte ein Haus mit drei Schlafzimmern und einem Badezimmer". Der Architekt muss Ihnen einen Plan vorlegen, aus dem genau hervorgeht, was wo hinkommt, welche Materialien verwendet werden, wo Licht und Strom sind, wo die Türen sind, wie dick die Wände sind usw. So ist es auch mit der Software.

1. Beschreibung der Arbeit

Hier beschreiben Sie einfach , was erstellt werden soll. Egal, ob es sich um eine Web-App, ein unternehmensinternes System, eine mobile App oder vielleicht ein Ablagetool handelt. Das Ziel ist es, sicherzustellen, dass beide Parteien die gleiche Vorstellung vom Ergebnis des Projekts haben.

Beispiel

2. Funktionale Anforderungen

Funktionale Anforderungen sind eine Liste spezifischer Funktionen, die die Software erfüllen soll. Was der Benutzer tun können soll - z. B. sich anmelden, nach einem Artikel suchen, ein Profil bearbeiten, eine Rechnung herunterladen. Und das Wichtigste: Ein Teil der Spezifikation umfasst Dinge, die die Anwendung nicht kann, auch wenn sie offensichtlich erscheinen.

Beispiel:

• Ein Benutzer kann sich mit einer E-Mail und einem Passwort anmelden.
  
• Die Anwendung erlaubt keine Anmeldung mit einem Facebook- oder Google-Konto.
  
• Der Administrator kann Benutzerkonten löschen.

3. Nicht-funktionale Anforderungen

Hierbei handelt es sich nicht um Funktionsanforderungen, sondern vielmehr um Bedingungen und Einschränkungen, unter denen das System funktionieren soll. Dazu gehört zum Beispiel, wie schnell das System reagieren soll, auf welchem Gerät es laufen soll, wie hoch die zu erwartende Belastung des Systems ist, welche Technologien verwendet werden sollen oder welche Daten es verarbeiten soll.

Beispiel:

• Das System soll für Mobiltelefone optimiert werden.
  
• Es wird auf einem Client-Server unter Linux laufen.
  
• Es muss mit den Browsern Chrome und Firefox kompatibel sein.
  
• Es muss in der Lage sein, 500 gleichzeitig verbundene Benutzer zu verarbeiten.
  

4. Verfahren zur Erreichung des Ziels

Hier wird beschrieben, wie die Entwicklung ablaufen wird. Welche Schritte werden nacheinander befolgt, welche Meilensteine werden gesetzt, wie oft werden Berichte gesendet, wann wird was getestet, wann wird was übergeben.

Beispiel:

• Phase eins: Entwurf der Benutzeroberfläche.
  
• Phase zwei: Entwicklung der Kernfunktionalität.
  
• Phase drei: Testen und Fehlersuche.
  
• Phase vier: Abnahme und Bereitstellung.
  

5. Systemstruktur

Der Abschnitt über die Systemstruktur zeigt, aus welchen Teilen (Modulen) das gesamte System besteht und wer daran beteiligt ist (Akteure). Module wie z. B. "Bestellformular", "Produktkatalog", "Verwaltungsoberfläche". Akteure sind verschiedene typische Benutzer - zum Beispiel ein regelmäßiger Besucher, ein registrierter Benutzer, ein Administrator..

Beispiel:

• Modul
  
• Modul
  
• Akteure:
  
  • Benutzer (nimmt eine Reservierung vor)
    
  • Administrator (verwaltet Kapazität, bestätigt Aufträge)
    

6. Skizzierte Architektur

Hierbei handelt es sich nicht um ein detailliertes technisches Design (das kommt später), sondern um eine Skizze, wie das System intern funktionieren wird - wie die verschiedenen Teile miteinander kommunizieren werden, wo die Datenbank gespeichert wird, ob das System in ein Frontend und ein Backend unterteilt wird und wie die Logik zwischen ihnen aussehen wird.

So erhält der Kunde eine Vorstellung von der Komplexität der Lösung und davon, ob sie seinen Bedürfnissen und Möglichkeiten entspricht.

7. Methode der Akzeptanz

Einer der wichtigsten Teile! Hier beschreiben Sie genau, wie die Übergabe der Arbeit stattfinden wird. Was alles getestet werden muss, wie die Checkliste aussehen wird, um zu überprüfen, ob die Arbeit vollständig ist. Wenn die Checkliste abgehakt ist, gibt es keinen Raum für Vermutungen, ob alles für die Übergabe bereit ist, und die Arbeit wird ohne Vorbehalt abgenommen.

Beispiel:

• Benutzeranmeldung und -abmeldung funktioniert
  
• Der Benutzer kann eine neue Buchung erstellen
  
• E-Mail-Bestätigung kommt innerhalb von 5 Minuten an

8. Aufgeführte Risiken

In diesem Abschnitt wird bewertet, was zu Komplikationen führen könnte - z. B. Abhängigkeit von Dritten, langsame Entscheidungsfindung durch den Kunden, Integration in externe Systeme usw. Dieser Abschnitt ist für alle wichtig, denn auch ein gut geplantes Projekt kann auf Hindernisse stoßen, die man besser im Voraus benennt.

Beispiel:

• Die Integration mit einem E-Mail-Dienst eines Drittanbieters kann fehlschlagen, wenn dieser seine API ändert.
  
• Die verspätete Lieferung von Dokumenten durch einen Kunden kann zu einer Verzögerung des Liefertermins führen.

Was ist keine Software-Spezifikation?

Eine Softwarespezifikation ist nicht nur eine Spezifikation des Kunden. Wenn ein Kunde eine E-Mail schickt, in der er sagt, er wolle ein "Kapazitätsmanagement-Reservierungssystem", ist das keine Spezifikation. Ebenso wenig wie eine in Excel geschriebene Liste von Funktionen oder eine Mind Map oder ein Wireframe, obwohl diese Dinge Teil der Spezifikation sein können.

Eine echte Spezifikation ist ein vollständiges Dokument, das nicht nur die Funktionen, sondern auch deren Grenzen, Umgebungen, Testszenarien und Abnahmebedingungen beschreibt. Am wichtigsten ist, dass sie von beiden Parteien unterzeichnet oder zumindest vereinbart werden muss. Andernfalls hat sie kein Gewicht.

Wozu ist sie gut?

Für den Kunden bringt die Spezifikation große Vorteile mit sich:

• Er weiß genau, was er kauft.
  Es gibt keine Verwirrung darüber, was geliefert wird und was nicht.
  
• Gleiche Ausgangsbedingungen im Ausschreibungsverfahren.
  Wenn der Kunde beschließt, sich an mehrere Unternehmen zu wenden, kann er die Spezifikation nehmen und sie zur Preisgestaltung ausschreiben. Sie konkurrieren dann alle um dieselbe Sache - nicht um ihre Interpretation.
  
• So wird verhindert, dass der Preis während der Entwicklung in die Höhe getrieben wird.
  Wenn etwas nicht in der Spezifikation steht, kann es vernünftigerweise als Mehrfachkosten beziffert werden. Sobald jedoch das, was in der Spezifikation steht, niedergeschrieben ist, muss der Lieferant es entwickeln und liefern.
  
• So wird eine reibungslose Übergabe gewährleistet.
  Bei den Abnahmebedingungen wird klar festgelegt, was zu prüfen ist und unter welchen Bedingungen die Arbeit ohne Vorbehalt abgenommen wird.

So machen wir es bei TRITON IT

Bei größeren Aufträgen oder Ausschreibungen erstellen wir eine Softwarespezifikation als kostenpflichtige Dienstleistung. Der Kunde kann die Spezifikation dann an andere Unternehmen weitergeben, damit diese den Preis für die Lösung festlegen. Wenn wir die Ausschreibung gewinnen, ziehen wir den Preis für die Spezifikation vom Gesamtpreis ab. In der Praxis bedeutet dies, dass die Spezifikation für den Kunden kostenlos ist.

Gleichzeitig bestehen wir nicht darauf, dass wir die Spezifikation erstellen müssen. Wenn der Kunde sie selbst oder mit einem anderen Anbieter erstellt, ist das völlig in Ordnung - aber wir wollen sie immer sehen. Ohne sie gehen wir nicht in die Entwicklung.