Pflichtenheft für Unternehmenssoftware in Schweizer KMU erstellen

Was ein Pflichtenheft für Unternehmenssoftware leistet

Ein Pflichtenheft – in der Praxis auch Lastenheft oder Anforderungsspezifikation genannt – hält fest, was eine Software können soll. Es ist die Grundlage für Angebote, für die Entwicklung und für die Abnahme. Fehlt das Dokument, gibt es keine gemeinsame Definition davon, wann ein Projekt als «fertig» gilt.

Die Begriffe sind nicht deckungsgleich: Das Lastenheft hält das «Was» des Auftraggebers fest, das Pflichtenheft das «Wie» des Auftragnehmers. In KMU-Projekten fliessen beide oft in ein einziges Dokument. Das ist praktikabel, solange erkennbar bleibt, was Anforderung des Auftraggebers und was vorgeschlagene Lösung des Anbieters ist.

Der Satz «Das habe ich mir anders vorgestellt.» am Ende eines Software-Projekts ist teuer. Er liegt meist nicht an schlechter Entwicklungsarbeit, sondern daran, dass die Anforderungen nie klar genug formuliert waren. Da KMU 95 Prozent der Wirtschaftslandschaft der Schweiz ausmachen (kmu.admin.ch), betrifft diese Gefahr die grosse Mehrheit der hiesigen IT-Vorhaben.

Relevante Zahlen für KMU in der Schweiz

Ausgangslage, Ziel und Vorher/Nachher festhalten

Beschreiben Sie den heutigen Zustand: Welche Abläufe laufen wie, mit welchen Hilfsmitteln (Excel-Listen, Papier, Insellösungen), wo entstehen Fehler, Doppelspurigkeiten oder Wartezeiten? Halten Sie fest, was die neue Software konkret verbessern soll. Ein klares Vorher/Nachher hilft dem Entwickler, die richtigen Prioritäten zu setzen, wenn Budget oder Termin unter Druck kommen.

Bearbeitet die Software Personendaten, gehört eine Bestandsaufnahme der Datenflüsse in die Ausgangslage. Die Swisscom-Checkliste zum Datenschutzgesetz empfiehlt einen pragmatischen Einstieg: Durchsuchen Sie die bestehenden Geschäftsanwendungen nach Personendaten und notieren Sie, woher die Daten stammen, wozu sie genutzt und wo sie gespeichert werden.

Gemäss dieser Checkliste lässt sich damit ein Überblick mit über 80 Prozent Vollständigkeit erreichen. Für die rein internen Arbeiten nennt die Quelle ein Zeitbudget von rund einem Arbeitstag, mit späterer Verfeinerung.

Schritte zur Erstellung eines Pflichtenhefts für KMU in der Schweiz

Nutzergruppen und Berechtigungen klären

Listen Sie auf, wer die Software nutzt: Mitarbeitende, Kunden, Partner, Administratoren. Zu jeder Rolle gehört, was sie sehen, lesen, ändern und löschen darf. Ein Lagerist sieht andere Dinge als ein Geschäftsführer. Wer die Rollen früh definiert, spart später Arbeit, weil Berechtigungskonzepte nachträglich nur mit Eingriffen in die bestehende Logik zu ändern sind.

Ebenfalls zu klären: Wer darf Daten exportieren, wer Stammdaten ändern, wer Zugriffsrechte vergeben? Erhalten Externe Zugang (Kundenportal, Partnerzugang), kommen Fragen der Authentifizierung und der Protokollierung von Zugriffen hinzu.

Funktionale Anforderungen als überprüfbare Benutzergeschichten formulieren

Formulieren Sie Funktionen als Benutzergeschichten: «Als Kundenberater möchte ich eine neue Offerte erstellen, sie dem Kunden per E-Mail senden und den Status verfolgen.» Nicht: «Das System soll ein Offertenmodul haben.» Der Unterschied liegt in der Prüfbarkeit. Am Projektende lässt sich für jede Benutzergeschichte mit Ja oder Nein beantworten, ob sie erfüllt ist – kann der Kundenberater das, oder kann er es nicht?

Ergänzen Sie zu jeder Geschichte, welche Daten eingegeben werden und welches Ergebnis sichtbar sein muss. Sammelbegriffe wie «benutzerfreundlich» oder «flexibel» lassen diese Antwort offen und gehören nicht in eine Anforderung, sondern höchstens in ein separates Qualitätsziel.

Nicht-funktionale Anforderungen und Datenschutz ergänzen

Leistungsanforderungen beschreiben nicht eine Funktion, sondern die Bedingungen: Wie schnell muss eine Seite laden, wie viele gleichzeitige Nutzer müssen unterstützt werden, welche Browser und Geräte sind Pflicht? Diese Angaben bestimmen Architektur und Testaufwand.

Bearbeitet die Software Personendaten, gelten die Vorgaben des revidierten Datenschutzgesetzes (DSG), das seit dem 1. September 2023 in Kraft ist. Der Eidgenössische Datenschutz- und Öffentlichkeitsbeauftragte (EDÖB) hält fest, dass das DSG technologieneutral formuliert und deshalb direkt auf KI-Anwendungen anwendbar ist.

Daraus sind drei Punkte als Anforderungen ins Pflichtenheft aufzunehmen: Transparenz über Zweck, Funktionsweise und Datenquellen; ein Widerspruchsrecht Betroffener gegen automatisierte Einzelentscheidungen; eine Datenschutz-Folgenabschätzung bei Anwendungen mit hohem Risiko. Wird die Software bei einem Hosting- oder Cloud-Anbieter betrieben oder greift sie auf Drittsysteme zu, gehört ein Auftragsdatenverarbeitungsvertrag zu den Anforderungen.

Sind KI-Funktionen eingeplant, gehören Regeln zur Ausgabe dazu: KI-Ausgaben sind Vorschläge, keine geprüften Fakten. Vor Kundenkontakt, Veröffentlichung, Vertragswirkung oder Buchung muss eine sachkundige Person Richtigkeit, Vollständigkeit, Tonalität und Quellen kontrollieren. Autonome Entscheide mit rechtlicher oder finanzieller Wirkung sind als Anwendungsfall auszuschliessen, und sensible Angaben wie Passwörter, Schlüssel oder vollständige Kundendossiers dürfen nicht in externe Werkzeuge eingegeben werden.

Vorteile und Risiken bei der Verwendung von KI in Unternehmenssoftware (Schweiz)

Schnittstellen zu bestehenden Systemen beschreiben

Halten Sie fest, mit welchen bestehenden Systemen die neue Software kommunizieren muss – etwa Bexio, Abacus, ein ERP, ein Newsletter-Tool, ein Webshop oder eine Branchenlösung. Für jede Schnittstelle ist zu klären, ob eine dokumentierte API existiert oder ob ein Dateiaustausch nötig ist.

Pro Schnittstelle gehören vier Angaben ins Pflichtenheft: Datenrichtung (lesen, schreiben oder beides), betroffene Datenobjekte und Felder, Rhythmus (Echtzeit, stündlich, nächtliche Verarbeitung) und Fehlerbehandlung. Bei der Fehlerbehandlung ist zu beantworten, was passiert, wenn das Zielsystem nicht erreichbar ist, ein Datensatz abgelehnt wird oder zwei Systeme denselben Datensatz gleichzeitig ändern. Ohne diese vier Angaben entsteht der Aufwand ungeplant mitten im Projekt.

Abgrenzung gegen Scope-Creep

Notieren Sie ebenso klar, was nicht Teil des Projekts ist: Funktionen, die erst in einer späteren Ausbaustufe kommen, Systeme, die nicht angebunden werden, Datenmigrationen, die der Auftraggeber selbst erledigt, sowie der Umfang von Schulung und Dokumentation.

Diese Abgrenzung ist die wirksamste Bremse gegen schleichende Erweiterungen. Sie macht sichtbar, wenn ein neuer Wunsch auftaucht, und erlaubt, ihn als Nachtrag mit eigenem Aufwand und eigenem Termin zu behandeln, statt ihn stillschweigend aus dem laufenden Budget zu bezahlen.

Technische Rahmenbedingungen und Eigentumsfragen regeln

Vorgaben zum Betrieb: Muss die Software auf einem bestimmten Server oder in einer bestehenden Infrastruktur laufen? Gibt es Vorgaben zu Datenbank, Programmiersprache oder Schnittstellenstandards? Soll der Quellcode dem Unternehmen gehören? Klären Sie vor Vertragsabschluss zudem, was bei einem Anbieterwechsel passiert – Datenexport, Dokumentation und Übergabe des Know-hows.

Hat das Unternehmen oder das Produkt einen EU-Bezug, kommen regulatorische Termine hinzu. Für Hochrisiko-KI-Systeme gemäss Anhang III des EU AI Acts gelten ab dem 2. Dezember 2027 strenge Vorgaben. Ab dem 11. Dezember 2027 gilt der Cyber Resilience Act vollständig.

Schweizer Anbieter können davon betroffen sein, auch ohne Niederlassung in der EU. Massgebend ist, ob Produkte oder Dienstleistungen gezielt auf den EU-Markt ausgerichtet sind – etwa über eine auf EU-Kunden zugeschnittene Website, Liefermöglichkeiten in EU-Staaten oder Preisangaben in Euro.

Regulatorische Termine für KI- und Cybersicherheit in der Schweiz (EU-Bezug)

Detaillierungsgrad und Abnahmekriterien festlegen

Die Faustregel lautet: So detailliert schreiben, dass zwei verschiedene Entwickler dasselbe verstehen würden. Lässt ein Satz Interpretationsspielraum, wird er falsch interpretiert. Prüfen Sie deshalb jede Anforderung mit der Gegenfrage, ob zwei Personen unabhängig voneinander dieselbe Funktion beschreiben würden.

Daraus folgen die Abnahmekriterien: Pro Anforderung wird festgehalten, woran die Erfüllung gemessen wird. Bei Benutzergeschichten ist das die Frage, ob die beschriebene Person die beschriebene Handlung ausführen kann. Ergänzen Sie, wer abnimmt (Fachbereich, Projektleitung, Geschäftsleitung) und in welcher Umgebung getestet wird – mit Testdaten, auf einem Testsystem und mit den echten Schnittstellen.

Der Aufwand für Details muss zum Risiko passen: Wo Kunden-, Personal-, Vertrags- oder Finanzdaten verarbeitet werden oder automatisierte Entscheide vorbereitet werden, braucht es mehr Kontrolle, Protokollierung und Dokumentation als bei einer Funktion, die nur öffentliche Informationen strukturiert. Das Pflichtenheft ist dabei kein Enddokument: Datenschutz- und Sicherheitsthemen werden erfahrungsgemäss nach einem ersten Durchgang weiter verfeinert.