Bedarfsanalyse für Softwareanbieter: So gehen Sie vor

Warum Softwareanbieter Bedarf anders analysieren müssen

Softwareanbieter tun sich mit der Bedarfsanalyse schwer, weil Wunsch und Bedarf im Alltag kaum zu trennen sind. Ein Feature-Request nennt fast immer eine Lösung – etwa „Wir brauchen einen Export-Button“ – und nicht das dahinterliegende Problem. Wer nur Wünsche sammelt, erhält eine Funktionsliste statt eines Werkzeugs, das Arbeit abnimmt.

Eine saubere Bedarfsanalyse dreht die Reihenfolge um: zuerst Problem, Arbeitsablauf, Datenfluss und Entscheidungssituation verstehen. Erst danach geht es um Funktionen.

Typische Fehler sind bekannt: nur auf die lautesten Kund:innen hören, nur mit dem Einkauf sprechen, Konkurrenzlösungen als Maßstab nehmen oder annehmen, ein On-Prem-Kunde habe denselben Bedarf wie eine SaaS-Kundin. Der Bedarf hängt vom Betriebsmodell ab.

SaaS bringt zentrale Telemetrie und kurze Release-Zyklen. On-Prem bedeutet heterogene Umgebungen, Kunden-IT und lange Updatezyklen. Plattformen bringen Schnittstellen und ein Ökosystem aus Drittanbietern. Wer hier nicht trennt, erhebt den Bedarf der falschen Zielgruppe.

Der Nutzen zeigt sich sofort: weniger Fehlentwicklung, bessere Argumente gegenüber Einkauf und Geschäftsführung, belastbarere Preis- und Paketlogik. Dazu kommt ein rechtlich getriebener Bestandteil des Bedarfs.

Laut digital-recht.at ist der Data Act (Verordnung EU 2023/2854) am 12. September 2025 in Kraft getreten und betrifft nahezu alle Anbieter vernetzter Produkte und digitaler Dienste. Das Prinzip „Access by Design“ verlangt, dass Nutzer ihre Daten direkt abrufen können – etwa über ein Dashboard, eine API oder ein Exportwerkzeug. Datenzugriff ist damit kein Bonusfeature mehr, sondern Teil des zu erhebenden Bedarfs.

Unterschiede zwischen SaaS und On-Prem-Bedarfsanalyse in Österreich

Rechtlicher Rahmen in Österreich: Data Act, DSGVO und WKO-Praxis

Für Softwareanbieter sind zwei Regelwerke zentral, die einander begrenzen: der Data Act und die DSGVO. Der Data Act unterscheidet laut digital-recht.at drei Rollen.

Nutzer sind Personen oder Unternehmen, die ein vernetztes Produkt besitzen oder berechtigt nutzen. Dateninhaber sind Anbieter, die technisch oder rechtlich in der Lage sind, Daten bereitzustellen. Datenempfänger sind Dritte, denen Daten vom Dateninhaber zur Verfügung gestellt werden.

Softwareanbieter sind danach regelmäßig als Dateninhaber einzuordnen. Das gilt, wenn sie Plattformen oder Dienste betreiben, die Nutzerdaten generieren oder verarbeiten.

Laut derselben Quelle erfasst der Data Act insbesondere Produktdaten, Daten aus verbundenen Diensten – etwa Cloud-Nutzung oder API-Calls – und Metadaten. Nicht umfasst sind abgeleitete oder analysierte Daten, die durch zusätzliche Investitionen entstehen. Entscheidend ist, ob Daten „ohne Weiteres verfügbar“ sind, also ohne unverhältnismäßigen Aufwand bereitgestellt werden können.

Die Quelle nennt vier Pflichtenbereiche für Softwareanbieter: Access by Design, Vertragsklarheit, technische Dokumentation sowie Datenschutz und Sicherheit. Access by Design verlangt den Datenabruf per Dashboard, Schnittstelle oder Exportfunktion. Vertragsklarheit bedeutet: Weitergabe an Dritte nur auf Grundlage eines Vertrags mit dem Nutzer, insbesondere für Analyse- und Marketingzwecke. Die technische Dokumentation muss festhalten, welche Daten verarbeitet werden, wie sie gespeichert sind und wie der Zugriff erfolgt. Bei gemischten Datensätzen aus personenbezogenen und nicht personenbezogenen Daten gelten zusätzliche Anforderungen; die DSGVO bleibt voll anwendbar.

Eine „Bill of Materials“ für Daten kann diese Dokumentation strukturieren.

Das WKO-FAQ zum Data Act weist ausdrücklich auf rechtliche Grenzen hin – vor allem bei personenbezogenen Daten (DSGVO) und Geschäftsgeheimnissen (Wettbewerbs- und Strafrecht).

Auf der DSGVO-Seite gilt: Verantwortliche können von Herstellern verlangen, dass beim Einsatz der Software datenschutzrechtliche Vorgaben umgesetzt werden. Für die Bedarfsanalyse heißt das, Datenschutz und Datenzugriff von Anfang an mitzudenken und nicht erst kurz vor dem Release.

Anlaufstellen in Österreich sind das Data-Act-FAQ der WKO sowie Rechtsberatung – etwa über die Wiener IT-Kanzlei hinter digital-recht.at.

Vorteile und Risiken der frühzeitigen Einbindung von Datenschutz und Data Act

Relevante rechtliche Rahmenbedingungen für Softwareanbieter in Österreich

Stakeholder, Nutzer:innen und Datenrollen richtig erfassen

Ein Stakeholder-Mapping für Softwareprojekte sollte mindestens fünf Gruppen unterscheiden. Dazu zählen Anwender:innen im Tagesgeschäft, Entscheider:innen im Fachbereich und in der Geschäftsführung, IT und Administration auf Kundenseite, Datenschutzverantwortliche sowie Einkauf und Rechtsabteilung. Externe Partner über Schnittstellen kommen hinzu.

Jede Gruppe blickt anders auf dasselbe Produkt. Anwender:innen sprechen über Arbeitsabläufe und Zeitdruck, Entscheider:innen über Kosten, Risiko und Wirkung. Die IT spricht über Betrieb, Integration und Updates, Datenschutz über Zwecke, Rechtsgrundlagen und Löschkonzepte. Der Einkauf spricht über Verträge, Haftung und Laufzeiten.

Über das Stakeholder-Mapping hinaus sollten Softwareanbieter die Data-Act-Rollen im Projekt ausdrücklich vergeben. Nach der Einordnung von digital-recht.at sind das Nutzer, Dateninhaber und Datenempfänger.

Für jede Rolle ist zu klären: Welche Daten entstehen hier? Wer darf sie abrufen? Wer bekommt sie weitergegeben? Auf welcher vertraglichen Grundlage?

Diese Zuordnung ist kein Papierritual. Sie bestimmt, welche Anforderungen an Export, Schnittstelle, Oberfläche und Dokumentation entstehen.

Sinnvoll ist eine einfache Matrix mit Stakeholder, Rolle im Projekt, Data-Act-Rolle, wichtigstem Bedürfnis, wichtigstem Bedenken und Einfluss auf die Kaufentscheidung. Wer diese Matrix einmal ehrlich ausfüllt, erkennt schnell, wo Bedarf nur behauptet wird und wo er belegt werden muss.

Besonders wichtig ist die Trennung zwischen der Person, die unterschreibt, und der Person, die täglich mit der Software arbeitet. Wird nur mit der ersten Gruppe gesprochen, entsteht ein Produkt, das im Einkauf überzeugt und im Alltag scheitert.

Bedarfsignale aus Vertrieb, Support und Produkt nutzen

Belastbarer Bedarf entsteht selten aus einer einzigen Quelle. Hilfreich ist es, mehrere Signalarten zusammenzuführen. Support-Tickets zeigen Reibung im Betrieb, Sales-Calls und verlorene Deals zeigen Ausschlusskriterien, Churn-Gespräche zeigen unerfüllte Erwartungen.

Produktanalytics zeigen tatsächliches Verhalten statt behaupteter Präferenzen. Feature-Request-Boards zeigen Häufigkeit und Dringlichkeit, Usability-Tests zeigen Verständnisprobleme. Schulungsanfragen und wiederkehrende Fragen im Onboarding sind starke Signale. Sie weisen auf fehlende Klarheit im Produkt oder in der Dokumentation hin.

Diese Signale sollten nicht einzeln bewertet, sondern trianguliert werden. Ein Wunsch, der nur in einem Sales-Call auftaucht, ist ein Hinweis. Ein Wunsch, der gleichzeitig in Support-Tickets, Churn-Gesprächen und Nutzungsdaten auftaucht, ist ein Muster.

Wichtig ist, Signale zu quantifizieren, wo das möglich ist: wie oft, bei welchen Kundensegmenten, mit welchem Umsatzanteil, in welchem Ausmaß. Qualitativ ist zu erklären, warum das Problem entsteht. Reine Stimmenzählung führt zur Tyrannei der lautesten Kundschaft.

Im österreichischen KMU-Kontext können je nach gewachsener Systemlandschaft, verfügbaren IT-Ressourcen, Anforderungen an Sicherheit und Datenschutz sowie saisonalen Schwankungen unterschiedliche Anforderungen entstehen.

Solche Faktoren können andere Anforderungen begründen – etwa einfache Administration, klare Exportmöglichkeiten und nachvollziehbare Dokumentation. Wer hier nur Funktionswünsche sammelt, übersieht den eigentlichen Bedarf nach Betriebssicherheit und Nachvollziehbarkeit.

Methoden, die zu Softwareteams passen: Interviews, Shadowing, JTBD

Für Softwareteams haben sich mehrere Methoden bewährt, die sich nach Einsatzszenario unterscheiden lassen. Leitfadengestützte Interviews eignen sich für Entscheider:innen und für die breite Erhebung von Problemen. Kontextinterviews und Shadowing begleiten Personen bei ihrer echten Arbeit. Sie eignen sich, wo Abläufe komplex sind und Menschen ihren Arbeitsfluss nur unvollständig beschreiben können.

Jobs-to-be-done hilft, Wünsche in Aufgaben und Fortschrittsziele zu übersetzen. Workshops unterstützen beim Abgleich widersprüchlicher Anforderungen, Umfragen beim Quantifizieren von Mustern aus Interviews. Keine dieser Methoden ersetzt eine andere; sie ergänzen sich.

Ein Fragenkatalog für B2B-SaaS sollte entlang des Arbeitsablaufs aufgebaut sein, nicht entlang der Funktionsliste. Bewährte Fragen sind: Wie erledigen Sie diese Aufgabe heute, Schritt für Schritt? Welche Informationen brauchen Sie an welcher Stelle, und woher kommen sie? Was passiert, wenn etwas schiefläuft?

Weitere Fragen: Wer muss zustimmen, bevor etwas weitergeht? Welche Daten geben Sie an wen weiter, und auf welcher Grundlage? Was kostet Sie diese Aufgabe an Zeit oder Geld?

Wie würden Sie merken, dass es besser läuft? Welche Lösung haben Sie schon versucht, und warum hat sie nicht funktioniert? Womit dürfen wir auf keinen Fall Ihre Zeit verschwenden?

Auch die Vertriebsliteratur arbeitet mit einem strukturierten Vorgehen. Bei HubSpot beginnt die Bedarfsanalyse damit, die Kundschaft kennenzulernen und ihre Ziele zu ergründen, bevor Lösungen ins Spiel kommen. Für Produktteams ist das eine gute Erinnerung, dass Analyse und Verkauf dieselbe Grundlage haben – nur mit unterschiedlicher Konsequenz. Der Vertrieb braucht ein Argument, das Produktteam braucht eine belastbare Anforderung.

Schritte zur Bedarfsanalyse für Softwareanbieter in Österreich

Vom Bedarf zu User Stories, API-Design und Vertragsklauseln

Die Übersetzung beginnt mit der Trennung von funktionalen und nicht-funktionalen Anforderungen. Funktionale Anforderungen beschreiben, was das System tun soll; nicht-funktionale beschreiben, wie es das tun soll: Performance, Verfügbarkeit, Bedienbarkeit, Barrierefreiheit, Sicherheit, Auditierbarkeit, Mandantenfähigkeit.

User Stories halten Nutzen und Kontext fest, Akzeptanzkriterien machen überprüfbar, wann eine Anforderung erfüllt ist. Gute Akzeptanzkriterien sind beobachtbar und nicht als technische Lösung formuliert. Zu jeder Story gehört ein Hinweis darauf, welches erhobene Problem sie löst – sonst lässt sich später nicht beurteilen, ob sie noch gebraucht wird.

Data-Act-konforme Designs gehören ausdrücklich in die Anforderungsliste. Nach der Darstellung von digital-recht.at umfasst Access by Design den Datenabruf über Dashboard, API oder Export-Tool. Vertragsklarheit bedeutet, dass Daten nur auf Grundlage eines Vertrags mit dem Nutzer an Dritte weitergegeben werden, insbesondere für Analyse- und Marketingzwecke. Die technische Dokumentation muss festhalten, welche Daten verarbeitet werden, wie sie gespeichert sind und wie der Zugriff erfolgt.

Daraus entstehen konkrete Anforderungen an Exportformate, Schnittstellendokumentation, Berechtigungskonzepte und Protokollierung.

Auf der Vertragsseite empfiehlt es sich, Klauseln zu Datenzugriff, Weitergabe, Aufbewahrung und Löschung früh mit Recht abzustimmen – nicht erst beim ersten Enterprise-Deal. Wer den Datenzugriff im Produkt sauber umsetzt, kann ihn im Vertrag einfacher beschreiben. Wer ihn nur im Vertrag beschreibt, muss ihn später nachbauen – meist teurer und unter Zeitdruck.

Priorisieren und validieren, bevor teuer entwickelt wird

Ein einfaches Bewertungsraster mit den Achsen Nutzen, Aufwand, Risiko und Compliance reicht für den Anfang. Nutzen lässt sich über betroffene Personengruppen, Häufigkeit, Zeitersparnis oder Umsatzbezug abschätzen, Aufwand über Entwicklung, Betrieb und Dokumentation.

Risiko und Compliance sollten nicht als Anhängsel behandelt werden. Ein Feature, das Datenzugriff oder personenbezogene Daten berührt, wird teurer und langsamer, wenn es erst spät geprüft wird. Für jede Position gehört eine kurze Begründung mit Quelle des Bedarfsnachweises in die Liste.

Bekannte Verfahren ergänzen das Raster. Kano unterscheidet Basis-, Leistungs- und Begeisterungsmerkmale und verhindert, dass Selbstverständliches als Innovation gefeiert wird. MoSCoW sortiert nach Muss, Soll, Kann und Nicht jetzt und macht Streichungen diskutierbar. Pretotyping testet die Nachfrage mit dem geringstmöglichen Aufwand, bevor gebaut wird.

Entscheidend sind klare Abbruchkriterien: Welches Ergebnis in welchem Zeitraum führt dazu, dass wir das Vorhaben nicht weiterverfolgen? Wer keine Abbruchkriterien definiert, entscheidet am Ende über Budget statt über Bedarf.

Validierung heißt nicht, alles zu bauen und zu hoffen. Sie kann über weitere Interviews, einen klickbaren Prototyp, einen Pilotkunden mit klarem Prüfauftrag oder eine bewusst kleine erste Ausbaustufe erfolgen. Wichtig ist, dass das Ergebnis der Validierung dokumentiert wird. So bleiben spätere Entscheidungen nachvollziehbar und werden nicht bei jedem Personalwechsel neu aufgerollt.

Ergebnisse dokumentieren und in die Roadmap überführen

Am Ende der Bedarfsanalyse steht kein Ordner, sondern ein Entscheidungsstand. Ein kompakter Bericht hält fest, welche Personengruppen befragt wurden, welche Probleme belegt sind, welche Anforderungen daraus abgeleitet wurden und welche Punkte bewusst nicht weiterverfolgt werden.

Ein Entscheidungslog dokumentiert, wer wann auf welcher Grundlage entschieden hat. Traceability – die Rückverfolgbarkeit von der Anforderung über die User Story bis zum Bedarfsnachweis – verhindert, dass Anforderungen ohne Grund in der Roadmap landen und dort bleiben.

Zur Dokumentation gehört eine Datenlandkarte: Welche Daten entstehen, wo werden sie gespeichert, wer greift darauf zu, an wen werden sie weitergegeben? Die von digital-recht.at erwähnte „Bill of Materials“ für Daten kann als Struktur dienen. Sie greift dieselben Fragen auf, die der Data Act an die technische Dokumentation stellt.

Personengruppen, die personenbezogene Daten betreffen, sollten gesondert gekennzeichnet werden. Hier setzt die DSGVO zusätzliche Grenzen, wie das WKO-FAQ betont.

Die Überführung in die Roadmap braucht einen Review-Zyklus: In welchem Rhythmus wird der erhobene Bedarf überprüft? An welchen Signalen wird gemessen, ob sich die Annahmen bestätigt haben? Wer darf Anforderungen streichen?

Ohne diesen Zyklus wird die Bedarfsanalyse zum einmaligen Projekt und die Roadmap zum Archiv alter Annahmen. Mit Zyklus wird sie zu einem Steuerungsinstrument, das Produktentscheidungen begründbar macht.

Fallstricke vermeiden: Checkliste für den Start

Die häufigsten Fallstricke wiederholen sich: nur die laute Kundschaft hören, Wünsche mit Bedarf verwechseln, nur mit einer Stakeholder-Gruppe sprechen.

Weitere Fehler sind: Datenschutz und Recht zu spät einbinden, Compliance als Nachgedanke behandeln, Anforderungen ohne Bedarfsnachweis in die Roadmap aufnehmen und keine Abbruchkriterien definieren.

Ein weiterer Fehler ist, den Datenzugriff bis zum ersten Enterprise-Deal aufzuschieben. Genau diese Anforderung muss laut digital-recht.at mit Access by Design, Vertragsklarheit, technischer Dokumentation sowie Datenschutz und Sicherheit früh im Produkt verankert werden.

Eine kompakte Checkliste für den Start: Zielgruppe und Stakeholder-Matrix festlegen; Data-Act-Rollen (Nutzer, Dateninhaber, Datenempfänger) im Projekt benennen. Interviews, Beobachtung und Analytics kombinieren; Probleme statt Lösungen dokumentieren; funktionale und nicht-funktionale Anforderungen getrennt festhalten.

Außerdem: User Stories mit Akzeptanzkriterien versehen; Datenlandkarte und Dokumentation der verarbeiteten Daten anlegen; Vertragsklauseln zu Weitergabe und Nutzung früh abstimmen. Danach: Priorisierung mit Nutzen, Aufwand, Risiko und Compliance durchführen; Abbruchkriterien definieren; Ergebnisse schriftlich festhalten und einen Review-Zyklus für die Roadmap vereinbaren.

Für österreichische Unternehmen ist das Data-Act-FAQ der Wirtschaftskammer Österreich der Einstieg in die unternehmerischen Pflichten und Grenzen. Rechtsberatung – etwa über die Wiener IT-Kanzlei hinter digital-recht.at – hilft, wenn Vertragsklauseln oder Rollen im Einzelfall zu klären sind.

Wer diese Stellen früh einbezieht, spart sich späte Umbauten und kann Bedarf und Rechtsrahmen in einer einzigen Planung zusammenführen.