Lastenheft für Content-Software: Vorlage mit Muss-, Soll- und Kann-Kriterien

• Dennis Gumprich
• Veröffentlicht 7. November 2026

Was ist ein Lastenheft, und was unterscheidet es vom Pflichtenheft?

Das Lastenheft beschreibt die Anforderungen des Auftraggebers: was gebraucht wird und warum. Das Pflichtenheft beschreibt die Umsetzung durch den Anbieter: wie die Anforderungen erfüllt werden. Ein Anforderungskatalog ist meist der Kern des Lastenhefts, die priorisierte Liste aller Anforderungen.

Bei Standardsoftware, die als Dienst bereitgestellt wird, entfällt das Pflichtenheft häufig oder wird durch das Angebot und eine Konfigurationsbeschreibung ersetzt. Das Lastenheft bleibt trotzdem wichtig: Es zwingt das Team, sich vor der Auswahl zu einigen, und es macht Angebote vergleichbar. Wer öffentlich ausschreibt, braucht es ohnehin als Grundlage der Leistungsbeschreibung.

Wie ist ein Lastenheft für Content-Software aufgebaut?

In acht Kapiteln, vom Warum zum Wie-bewerten: Ausgangslage, Ziele, heutiger Ablauf, funktionale Anforderungen, nicht funktionale Anforderungen, Schnittstellen, Rahmenbedingungen und Bewertungskriterien. Ein Zeitplan für Auswahl und Einführung rundet es ab.

1. Kapitel 1AusgangslageWer seid ihr, wie viele Personen arbeiten mit Inhalten, in welchen Kanälen, mit welchen Werkzeugen? Zwei Seiten reichen. Anbieter verstehen daraus, in welcher Größenordnung ihr denkt.
2. Kapitel 2ZieleWas soll nach der Einführung besser sein? Messbar formuliert, etwa: Durchlaufzeit pro Inhalt halbieren, Themen über alle Kanäle transparent planen, Fachbereiche ohne E-Mail-Schleifen einbinden.
3. Kapitel 3Heutiger AblaufWie entsteht heute ein Inhalt, von der Idee bis zur Veröffentlichung? Wo hakt es? Diese Beschreibung ist für Anbieter wertvoller als jede Funktionsliste.
4. Kapitel 4Funktionale AnforderungenWas muss die Software können? Gegliedert nach Bereichen wie Planung, Erstellung, KI, Freigabe, Veröffentlichung und Auswertung, jeweils mit Muss, Soll oder Kann.
5. Kapitel 5Nicht funktionale AnforderungenDatenschutz, Informationssicherheit, Hosting, Verfügbarkeit, Barrierefreiheit, Sprachen, Support. Hier liegen häufig die echten Ausschlusskriterien.
6. Kapitel 6SchnittstellenWelche Systeme müssen angebunden werden: CMS, Intranet, PIM, Social-Media-Kanäle, Newsletter, Analyse? In welche Richtung fließen Daten?
7. Kapitel 7RahmenbedingungenAnzahl und Art der Nutzer, Rollen und Rechte, gewünschte Vertragslaufzeit, Einführung und Schulung, Zeitplan.
8. Kapitel 8BewertungskriterienWie werden Angebote verglichen? Gewichtung von Funktion, Bedienbarkeit, Sicherheit, Kosten und Zusammenarbeit, festgelegt bevor die Angebote eingehen.

Das dritte Kapitel wird am häufigsten übersprungen und ist oft das wertvollste. Wer den heutigen Ablauf beschreibt, zwingt Anbieter, ihre Lösung an euren Engpässen zu zeigen statt an ihren Lieblingsfunktionen. Wie ihr den Ablauf vorher erhebt, beschreibt der Beitrag Prozessreife messen.

Lastenheft-Vorlage: Anforderungen nach Muss, Soll und Kann

Die folgende Vorlage zeigt typische Anforderungen an Content-Software, eingeteilt in Muss, Soll und Kann. Sie ist ein Startpunkt, kein fertiges Lastenheft. Streicht, was ihr nicht braucht, und ergänzt, was euren Alltag ausmacht.

Achtet auf die Zahl der Muss-Kriterien. In dieser Vorlage sind es acht, und das ist eher die Obergrenze. Jedes zusätzliche Muss schließt Anbieter aus und erhöht das Risiko, dass am Ende niemand alles erfüllt und ihr die Kriterien doch wieder aufweicht. Einen vertieften Katalog speziell für Newsroom-Organisationen findet ihr im Beitrag Newsroom-Software: der Anforderungskatalog.

Wie formuliert ihr Anforderungen so, dass sie prüfbar sind?

Eine gute Anforderung beschreibt ein Ergebnis, nicht eine Funktion, und ist in einer Demo oder einem Test überprüfbar. Sie enthält wer, was und unter welcher Bedingung. Vage Wörter wie „intuitiv“ oder „flexibel“ lassen sich nicht bewerten.

Die zweite Formulierung ist länger, aber jeder Anbieter kann sie in einer Demo zeigen oder nicht. Hilfreich ist es, Anforderungen als kleine Szenarien zu schreiben, die aus eurem Alltag stammen. Ein Szenario wie „Aus einem Themenbriefing entstehen ein Fachartikel, drei LinkedIn-Beiträge und ein Newsletter-Teaser“ sagt mehr als zehn Einzelfunktionen.

Drei Fragen kommen in Gesprächen mit Kommunikationsteams immer wieder auf und gehören deshalb ausdrücklich ins Lastenheft:

• Welche Systeme lassen sich ohne zusätzlichen Entwicklungsaufwand anbinden? Und was kostet eine individuelle Anbindung? Den Unterschied zwischen offener Schnittstelle und Standardanbindung erklärt der Beitrag MCP oder API.
• Wer braucht eine Lizenz? Fachbereiche liefern Inhalte und geben frei, arbeiten aber selten täglich im System. Klärt, ob es Rollen für Kommentieren und Freigeben ohne volle Lizenz gibt.
• Wie werden KI-Funktionen abgerechnet? Pauschal, nach Nutzern oder nach Verbrauch? Bei verbrauchsabhängigen Modellen braucht ihr eine Schätzung für euer Volumen.

Wie bewertet ihr die Angebote?

Mit einer Nutzwertanalyse, deren Gewichtung ihr festlegt, bevor die Angebote eingehen. Muss-Kriterien entscheiden über die Zulassung, Soll- und Kann-Kriterien über die Rangfolge. Kosten fließen als eigener Block ein, nicht als Tiebreaker.

Der wichtigste Block ist die Bedienbarkeit im Alltag, und er lässt sich nur mit eigenen Inhalten testen. Demos mit Musterdaten sehen bei jedem Anbieter gut aus. Bittet deshalb um einen kurzen Test, in dem eure Redaktion einen echten Inhalt vom Briefing bis zur Freigabe durchspielt. Wie ein solcher Test aufgebaut ist, beschreibt der Beitrag Pilot und Rollout. Wie ihr die Kosten der Laufzeit in einen Business Case übersetzt, steht in Business Case für Content-Software.

In sechs Wochen zum Lastenheft

Ein belastbares Lastenheft entsteht in sechs Wochen, wenn Fachbereich, IT und Datenschutz von Anfang an beteiligt sind und die Arbeit in klare Etappen geteilt wird.

1. Woche 1Ziele und Beteiligte klärenLegt drei bis fünf messbare Ziele fest und benennt die Beteiligten: Fachbereich, künftige Nutzer, IT, Datenschutz, Einkauf. Meldet das Vorhaben früh bei IT und Datenschutz an, wie im Beitrag IT und Datenschutz früh einbinden beschrieben.
2. Woche 2Heutigen Ablauf beschreibenSpielt zwei typische Inhalte von der Idee bis zur Veröffentlichung durch und haltet fest, wo es hakt. Erhebt dabei Ausgangswerte wie Durchlaufzeit und Freigabedauer.
3. Woche 3Anforderungen sammelnSammelt Anforderungen aus allen Gruppen, formuliert sie als prüfbare Szenarien und ordnet sie den Bereichen zu.
4. Woche 4PriorisierenStuft jede Anforderung als Muss, Soll oder Kann ein. Begrenzt die Muss-Kriterien auf fünf bis acht. Diskutiert jedes Muss mit der Frage: Würden wir einen Anbieter wirklich ausschließen, der das nicht erfüllt?
5. Woche 5Rahmen und Bewertung festlegenErgänzt Nutzerzahlen, Rollen, Schnittstellen und Zeitplan. Legt die Gewichtung der Bewertung fest, bevor ein Angebot vorliegt.
6. Woche 6Abstimmen und freigebenLasst das Lastenheft von allen Beteiligten gegenlesen und gebt es frei. Danach beginnt die Marktansprache.

Welche nicht funktionalen Anforderungen gehören ins Lastenheft?

Alles, was nicht die Funktion, sondern den Betrieb betrifft: Datenschutz, Informationssicherheit, Hosting, Verfügbarkeit, Barrierefreiheit, Sprachen und Support. Hier liegen in vielen Organisationen die echten Ausschlusskriterien, und hier stellen IT und Datenschutz ihre Fragen.

Gerade bei KI-Funktionen lohnt Genauigkeit. Fragt nicht nur, ob Daten zum Training genutzt werden, sondern auch, welche Modelle zum Einsatz kommen, wo die Verarbeitung stattfindet und wie sich KI-Funktionen für einzelne Nutzergruppen einschränken lassen. Worauf es bei der Prüfung im Detail ankommt, beschreibt der Beitrag DSGVO-konforme Content-Marketing-Software.

Wie beschreibt ihr Schnittstellen im Lastenheft?

Als Liste der Systeme mit Richtung und Zweck des Datenflusses: welches System, welche Daten, in welche Richtung, wie oft. Technische Details liefern die Anbieter, ihr beschreibt, was fließen muss.

Eine einfache Tabelle reicht: CMS, Intranet, Mitarbeiter-App, soziale Kanäle, Newsletter-Werkzeug, Produktdatenbank, Bilddatenbank, Analysewerkzeuge. Für jedes System notiert ihr, ob Inhalte hineingeschickt, Daten abgeholt oder beides passieren soll, und ob das manuell, per Klick oder automatisch geschehen muss. Wichtig ist die Frage, welche Anbindungen im Angebot enthalten sind und welche gesondert entwickelt oder bezahlt werden müssen. Diese Unterscheidung entscheidet oft mehr über die Gesamtkosten als der Lizenzpreis. Wie Inhalte nach der Freigabe ohne Kopieren in das Zielsystem kommen, beschreibt der Beitrag Die letzte Meile.

Welche Fehler machen Teams beim Lastenheft?

Die meisten Fehler machen Lastenhefte entweder zu eng, zu vage oder zu spät abgestimmt.

1. Funktionslisten statt AbläufeHundert Häkchen sagen wenig darüber, ob eure Redaktion schneller wird. Beschreibt Szenarien aus dem Alltag.
2. Zu viele Muss-KriterienAb etwa acht Ausschlusskriterien bleibt kaum ein Anbieter übrig. Am Ende werden Kriterien aufgeweicht und das Verfahren verliert an Glaubwürdigkeit.
3. Eine bestimmte Lösung beschreibenWer das Lastenheft nach den Funktionen eines Anbieters schreibt, verhindert echten Wettbewerb und übersieht bessere Wege.
4. IT und Datenschutz zu spätWenn Sicherheitsanforderungen erst nach der Auswahl auftauchen, beginnt das Verfahren von vorn.
5. Gewichtung nach den Angeboten festlegenWer die Gewichtung erst kennt, wenn die Angebote vorliegen, bewertet unbewusst zugunsten eines Favoriten.

Fazit: Ein gutes Lastenheft beschreibt euren Alltag, nicht einen Anbieter

Ein Lastenheft für Content-Software ist weniger eine Funktionsliste als eine Beschreibung dessen, was nach der Einführung besser sein soll. Wer Ziele messbar formuliert, den heutigen Ablauf realistisch beschreibt, Anforderungen als prüfbare Szenarien schreibt, Muss-Kriterien begrenzt und die Bewertung vorher festlegt, bekommt vergleichbare Angebote und eine Entscheidung, die auch später trägt.

Nutzt die Vorlage als Startpunkt. Streicht konsequent, was ihr nicht braucht, und ergänzt die zwei, drei Anforderungen, die euren Alltag wirklich ausmachen. Diese entscheiden am Ende über den Erfolg der Einführung.

Häufige Fragen

Dennis Gumprich

Senior Consultant Content Solutions · contentbird GmbH

Dennis begleitet Marketing- und Kommunikationsteams bei der Frage, wie generative KI in bestehende Content-Prozesse passt, ohne Qualität, Markensprache und Freigaben zu untergraben. Schwerpunkte: Content Operations, KI-Governance und Toolauswahl in Mittelstand und Konzern.

Transparenzhinweis: Dennis arbeitet für contentbird, einen Anbieter von KI-gestützter Content-Software. Produkterwähnungen sind im Beitrag gekennzeichnet. Mehr über Dennis · LinkedIn