Ein Anforderungsdokument für die Website schreiben
Ein Anforderungsdokument existiert, damit Sie und die Entwicklerin dieselbe Website beschreiben. Es muss nicht lang sein. Ein vierseitiges Briefing, das beide Seiten tatsächlich gelesen haben, verhindert mehr Streit als eine fünfzigseitige Spezifikation, die keiner zu Ende gebracht hat.
Dieser Leitfaden behandelt, was hineingehört, was Sie weglassen können und wie Sie den wichtigsten Abschnitt schreiben: was das Projekt nicht ist.
Wozu ein Anforderungsdokument dient#
Es hat drei Aufgaben: mehreren Entwicklern erlauben, dasselbe zu bepreisen, damit die Angebote vergleichbar sind; Ihnen eine Referenz geben, wenn es Uneinigkeit über den Umfang gibt; und Sie zwingen, Entscheidungen zu treffen, solange sie noch billig sind.
Es ist kein Design-Briefing und keine technische Spezifikation. „Die Website muss schnell laden“ ist eine Anforderung; „Redis für Object Caching verwenden“ ist eine Lösung, und sie zu wählen, bevor Sie jemanden beauftragt haben, entzieht Ihnen genau die Expertise, für die Sie zahlen.
- Nennen Sie Ergebnisse und Randbedingungen, keine Umsetzungen.
- Schreiben Sie es so, dass jemand außerhalb Ihrer Organisation es ohne Rückruf versteht.
- Halten Sie es kurz genug, um es in einem Zug zu lesen — vier bis acht Seiten genügen für die meisten Websites.
- Datieren und versionieren Sie es, denn es wird sich ändern.
Die Abschnitte, die sich lohnen#
Diese Struktur deckt die meisten Website-Projekte ab. Lassen Sie weg, was nicht zutrifft, statt es aufzufüllen.
| Abschnitt | Was hineingehört |
|---|---|
| Hintergrund | Was die Organisation tut und warum die Website gebaut oder ersetzt wird |
| Ziele | Primäres Ziel, sekundäre Ziele und wie Erfolg gemessen wird |
| Zielgruppe | Zwei oder drei Besuchergruppen und die Frage, mit der jede ankommt |
| Seitenstruktur | Jede Seite, in Bereiche gruppiert, als startkritisch oder später markiert |
| Funktionale Anforderungen | Formulare, Suche, Konten, Filter, Buchung, Checkout — was jedes leisten muss |
| Integrationen | Jedes externe System, mit Ansprechpartner und Link zur API-Dokumentation |
| Inhalt | Wer welche Seite schreibt, wer freigibt, wann sie fällig ist |
| Nicht-funktional | Performance, Barrierefreiheit, Browser- und Geräteunterstützung, Sprachen, Sicherheit |
| Nicht im Umfang | Ausdrücklich ausgeschlossene Arbeit — der wertvollste Abschnitt |
| Randbedingungen | Budgetrahmen, Termin und feste Vorgaben (bestehender Host, vorgeschriebenes CMS) |
Schreiben Sie prüfbare Anforderungen#
Eine Anforderung ist nützlich, wenn beide Seiten hinterher übereinstimmen können, ob sie erfüllt wurde. „Die Website sollte schnell sein“ ist nicht prüfbar; „die Produktlistenseite erreicht Largest Contentful Paint unter 2,5 Sekunden auf einem Android-Mittelklassegerät über 4G“ schon.
Dasselbe gilt für Funktionen. „Ein Kontaktformular“ lässt jede Frage offen, auf die es ankommt.
| Vage | Prüfbar |
|---|---|
| Ein Kontaktformular | Sechs Felder, Spamschutz, Speicherung in der Datenbank, Mail an zwei Adressen, DSGVO-Einwilligung |
| Mobilfreundlich | Nutzbar ab 320 px, alle Touch-Ziele mindestens 44 px, kein horizontales Scrollen |
| Schnell | LCP unter 2,5 s und CLS unter 0,1 auf den vier Haupt-Templates, gemessen über 4G |
| Barrierefrei | WCAG 2.2 AA auf Templates, geprüft per Tastatur- und Screenreader-Durchgang |
| SEO-freundlich | Editierbare Titel und Beschreibungen, saubere URLs, Sitemap, strukturierte Daten bei Artikeln |
| Mehrsprachig | Drei Sprachen, übersetzte URLs, hreflang-Tags, Sprachumschalter auf jeder Seite |
Die Ausschlussliste#
Das ist der Abschnitt, den alle überspringen, und derjenige, der das Projekt rettet. Schreiben Sie die Dinge auf, die eine vernünftige Person als enthalten annehmen könnte, und sagen Sie klar, dass sie es nicht sind — oder nehmen Sie sie auf, falls sie es sein sollten.
Das vor Eintreffen der Angebote zu tun bedeutet, dass die Angebote vergleichbar sind. Es danach zu tun bedeutet Streit.
- Texterstellung und Korrektorat — gehen Sie davon aus, dass es Ihre Sache ist, sofern das Angebot nichts anderes sagt.
- Fotografie, Illustration und Stock-Lizenzen.
- Inhaltspflege: Wer tippt 200 Produkte ins CMS?
- E-Mail-Einrichtung, DNS-Umzug und Übertragung des Hosting-Kontos.
- Laufende SEO-Arbeit, abgegrenzt von der technischen SEO-Einrichtung zum Start.
- Schulung, Dokumentation und Übergabe.
- Support nach dem Start: was abgedeckt ist, wie lange, und was abgerechnet wird.
Eine gute Entwicklerin ergänzt diese Liste unaufgefordert. Wer ohne Rückfragen allem zustimmt, hat sie meist nicht gelesen, und die Uneinigkeit ist lediglich vertagt.
Häufige Fragen
Wie lang sollte ein Anforderungsdokument sein?
Vier bis acht Seiten decken die meisten Unternehmenswebsites ab. Shops und Anwendungen werden länger, weil der funktionale Teil wächst, aber jenseits von zwanzig Seiten fragen Sie sich, was da beschrieben wird, das ein Gespräch nicht klären könnte. Der Maßstab ist, ob beide Seiten es gelesen haben, nicht ob es vollständig ist.
Sollte ich die Technologie vorgeben?
Nur wo Sie eine echte Randbedingung haben: ein vorhandenes CMS, das Ihr Team kennt, ein Host, bei dem Sie bleiben müssen, ein System, das angebunden werden muss. Ansonsten nennen Sie das Ergebnis und lassen die Beauftragten die Umsetzung wählen. Einen Stack vorzugeben, den Sie nicht verstehen, verengt Ihre Optionen und liefert eine schlechtere Antwort.
Brauche ich zusätzlich Wireframes?
Grobe Wireframes für die drei oder vier wichtigsten Templates nehmen mit sehr wenig Aufwand viel Mehrdeutigkeit heraus und sind weit billiger zu ändern als ein Design. Sie ersetzen die schriftlichen Anforderungen nicht — sie zeigen Anordnung, nicht Verhalten —, aber beides zusammen lässt sich deutlich genauer bepreisen als jedes für sich.
Was, wenn ich manche Antworten nicht kenne?
Schreiben Sie „wird noch entschieden“ und benennen Sie, wer entscheidet und bis wann. Eine ehrliche Lücke mit Verantwortlichem ist in Ordnung; eine erfundene Antwort nicht, denn das Angebot wird darauf aufbauen. Entwickler bepreisen Unsicherheit ohnehin, also bringt es meist eine bessere Zahl, die Unsicherheit sichtbar zu machen, statt sie zu verstecken.
website anforderungsdokumentwebsite briefingwebsite lastenheftwebsite ausschreibungwebsite leistungsumfangwebentwicklung anforderungen
