Funktionale Spezifikationen: Beschreiben Sie einen Bedarf, nicht eine Lösung (2026)

Wenn Sie eine Dienstleistung von einem externen Anbieter in Anspruch nehmen, ohne Ihre Erwartungen zuvor schriftlich klar definiert zu haben, geben Sie diesem das Recht, Entscheidungen für Sie zu treffen. Das Dokument mit den funktionalen Spezifikationen formalisiert dieses Recht.

Was ein funktionales Spezifikationsdokument ist und was es nicht ist

Eine Funktionsspezifikation ist ein schriftliches Dokument, das beschreibt, was die Nutzer nach Abschluss eines Projekts tun können sollen. Sie legt nicht fest, wie das Ergebnis erzielt wird, welche Technologien oder Materialien zum Einsatz kommen. Sie beschreibt lediglich, was die Nutzer nach der Bereitstellung des Dienstes unter welchen genauen Bedingungen erreichen können sollen.

Dieses Dokument geht jeder technischen Entscheidung voraus. Es wird verfasst, bevor eine Lösung ausgewählt wurde. Es setzt jedoch voraus, dass … Rahmennotiz Projektrahmen, Ziele, Budget und Umfang sind bereits festgelegt: Das Leistungsverzeichnis beschreibt einen Bedarf mit definierten Parametern. Seine Aufgabe ist es, festzulegen, was nach Projektabschluss erfüllt sein muss, unabhängig vom gewählten Weg. Genau diese Positionierung verleiht ihm seinen Wert: Es dient als gemeinsame Referenz für Auftraggeber und Dienstleister, ohne eine der beiden Parteien zu bevorzugen.

Ein Punkt bedarf sofortiger Klärung. Das Dokument mit den funktionalen Spezifikationen listet keine Bildschirme, Schaltflächen, Menüs oder Formularfelder auf. Diese Elemente fallen unter eine andere Detailebene und werden in den technischen Spezifikationen behandelt, die nach Auswahl des Dienstleisters und der Lösung erstellt werden. Falls Ihr Dokument diese Elemente erwähnt, handelt es sich noch nicht um ein Dokument mit funktionalen Spezifikationen, sondern bereits um eine verkappte technische Spezifikation, die überarbeitet werden muss.

Dieses Dokument ist keine Firmenpräsentation, keine visuelle Inspirationsquelle und keine Zusammenfassung eines informellen Meetings. Es ist auch keine Wunschliste, die per E-Mail verschickt wird. Es ist ein strukturiertes Dokument für Personen, die Sie nicht kennen und Ihre Erwartungen ohne weitere mündliche Erläuterungen verstehen sollen.

Das Dokument mit den funktionalen Spezifikationen beschreibt nicht, was das System sein wird, sondern was die Benutzer damit tun können. Diese Unterscheidung zwischen „Sein“ und „Tun“ ist zentral für das Dokument. Ein System kann Dutzende von Funktionen umfassen und dennoch unbrauchbar bleiben, wenn die Benutzer die Aktionen, die ihren tatsächlichen Bedürfnissen entsprechen, nicht ausführen können. Das Dokument mit den funktionalen Spezifikationen beginnt daher immer mit der erwarteten Aktion, niemals mit der Liste der Komponenten, die diese ermöglichen.

Sie unterscheiden es von den Einkaufsspezifikationen und den technischen Spezifikationen.

Drei Dokumente werden oft allgemein als Spezifikationen bezeichnet, dienen aber nicht demselben Zweck und sind nicht für dieselben Personen bestimmt. Eine Verwechslung kann zu kostspieligen Fehlern führen. Einen Überblick über die verschiedenen Typen und das vollständige Framework finden Sie in unserem allgemeinen Leitfaden. Spezifikationen platziert sie alle in der gleichen Landschaft.

Die Einkaufsspezifikationen, auch Lieferantenberatungsspezifikationen genannt, dienen dem Vergleich von Angeboten für ein vordefiniertes Produkt oder eine Dienstleistung. Sie beantworten die Frage: Welches Angebot auf dem Markt entspricht am besten unseren Anforderungen? Sie setzen voraus, dass der Bedarf bekannt ist und die Vergleichskriterien festgelegt wurden. Sie richten sich an Lieferanten, die im selben Leistungsspektrum konkurrieren. Daher folgen sie den Funktionsspezifikationen, ersetzen diese aber niemals.

Das Dokument mit den technischen Spezifikationen beschreibt den Systemaufbau. Es erläutert die verwendeten Technologien, die gewählten Architekturen, die Integrationsbeschränkungen mit bestehenden Systemen und die einzuhaltenden Standards. Es beantwortet die Frage: Wie setzen wir die getroffenen Entscheidungen um? Es richtet sich an die Implementierungsteams – Entwickler, Ingenieure oder Architekten –, die genau wissen müssen, wie das Ergebnis erzielt wird.

Das Dokument mit den funktionalen Spezifikationen geht den beiden anderen voraus. Es beantwortet die Frage: Was muss das Ergebnis leisten? Es richtet sich an alle, die einen Lösungsvorschlag unterbreiten sollen, ohne eine bestimmte Lösung vorzugeben. Es wird vom Auftraggeber erstellt, bevor feststeht, wer das Projekt wie durchführen wird.

Die logische Reihenfolge ist unveränderlich: Zuerst der funktionale Aspekt, der den Bedarf ausdrückt; dann der technische Aspekt, der die gewählte Lösung beschreibt; und schließlich, falls erforderlich, der Kaufvertrag, der die Angebote für diese Lösung vergleicht. Diese Reihenfolge umzukehren, bedeutet, eine Antwort zu wählen, bevor man die Frage überhaupt gestellt hat.

Ein häufiger Fehler ist es, dem Dienstleister ein Dokument zu senden, das alle drei Ebenen vermischt: Es beschreibt die Ziele der Nutzer, die geplante Umsetzung und die Vergleichskriterien für die Angebote. Diese Vermischung raubt beiden Parteien die nötige Klarheit. Der Dienstleister weiß nicht, was verhandelbar ist und was nicht. Der Kunde kann die Angebote nicht auf einer gemeinsamen Basis vergleichen.

Warum die Beschreibung eines Bedürfnisses anstatt einer Lösung alles verändert

Der häufigste Fehler beim Verfassen einer funktionalen Spezifikation ist nicht das Vergessen einer Anforderung, sondern das Formulieren einer Lösung anstelle einer Anforderung. Diese weit verbreitete Verwechslung verändert den Charakter des Dokuments und seine praktischen Konsequenzen für das Projekt grundlegend.

Nehmen wir ein konkretes Beispiel. Ein Manager möchte, dass seine Kunden ihre Rechnungen einsehen können, ohne die Verwaltung kontaktieren zu müssen. Schreibt er: „Wir benötigen einen Button, der Rechnungen als PDFs aus einem Kundenportal exportiert“, beschreibt er eine Lösung: einen Button, eine Exportfunktion und das PDF-Format. Schreibt er hingegen: „Der Kunde muss jede auf seinen Namen ausgestellte Rechnung ohne Unterstützung unseres Teams finden und herunterladen können“, beschreibt er ein Bedürfnis.

Der Unterschied ist nicht kosmetischer Natur. Die erste Vorgehensweise schließt jegliche Alternative aus: keine automatischen E-Mail-Benachrichtigungen, kein Zugriff per mobiler App, keine monatlichen Gruppenmailings. Der Anbieter ist verpflichtet, genau das zu liefern, was beschrieben wurde, selbst wenn eine andere Vorgehensweise kostengünstiger, einfacher zu warten oder besser auf die tatsächliche Nutzung Ihrer Kunden zugeschnitten gewesen wäre. Und wenn das Ergebnis zwar der Beschreibung entspricht, aber das zugrundeliegende Problem nicht löst, haben Sie keine Handhabe: Sie haben bekommen, was Sie verlangt haben.

Der zweite Ansatz lässt alle Möglichkeiten offen, um dasselbe Ergebnis zu erzielen. Zwei Anbieter können unterschiedlich reagieren, und Sie können ihre Angebote anhand desselben Bedarfs vergleichen. Der eine bietet vielleicht ein Kundenportal mit direkten Downloads an, der andere versendet Dokumente automatisch per E-Mail mit jeder Rechnung. Beide Lösungen sind gültig, sofern sie den genannten Bedarf decken. Sie wählen die beste Lösung, nicht unbedingt die, die Ihrer ursprünglichen Vorstellung am ehesten entspricht.

Solange das Dokument Schaltflächen, Registerkarten, Formularfelder oder Technologiebezeichnungen enthält, handelt es sich noch nicht um eine funktionale Spezifikation, sondern bereits um eine verkappte technische Spezifikation. Die praktische Regel ist einfach: Beschreibt der soeben formulierte Satz einen Mechanismus anstatt einer von einem identifizierbaren Benutzer erwarteten Aktion, sollte er umformuliert werden.

Um einen tatsächlichen Bedarf zu ermitteln, genügen zwei Fragen. Erste Frage: Wer muss diese Handlung ausführen können? Zweite Frage: Was muss diese Person können, was sie heute noch nicht kann? Die Antworten liefern eine korrekte funktionale Anforderung. Der Mechanismus zu deren Erfüllung wird in diesem Dokument nicht behandelt.

Dieser disziplinierte Ansatz bei der Formulierung mag während des Entwurfsprozesses einschränkend wirken. Er erweist sich jedoch beim Vergleich von Angeboten als entscheidender Vorteil. Ohne eine gut formulierte Funktionsspezifikation lassen sich zwei Anbieter, die sehr unterschiedliche Lösungsansätze für dasselbe Problem verfolgen, nicht bewerten. Mit ihr können Sie jedes Angebot anhand einer einzigen Frage beurteilen: Erfüllt es die von mir spezifizierte Anforderung?

Jede Anforderung muss bei Lieferung überprüfbar sein.

Eine Anforderung, die bei Lieferung nicht überprüft werden kann, ist wertlos. Können Sie die Frage „Ist diese Anforderung erfüllt?“ nicht mit Ja oder Nein beantworten, bietet das Dokument zum Zeitpunkt der Annahme keinerlei Schutz.

Die Formulierung „Das System muss schnell sein“ ist für niemanden bindend. Sollten Sie das Ergebnis nach der Auslieferung als langsam empfinden, der Dienstleister aber als schnell, fehlt Ihnen im Dokument ein gemeinsamer Bezugspunkt für eine Entscheidung. Der Satz war eine Absichtserklärung, keine Anforderung.

Die Aussage, dass „das System es einem Benutzer ermöglichen muss, eine Kundendatei mit weniger als drei Schritten von der Startseite aus abzurufen“, ist eine überprüfbare Anforderung. Am Tag des Erhalts öffnen Sie die Ergebnisse, suchen nach einer Kundendatei und zählen die Schritte. Das Ergebnis ist entweder konform oder nicht. Es gibt keinen Interpretationsspielraum.

Dieses Prinzip gilt für jede Zeile des Dokuments. Stellen Sie sich bei jeder Anforderung folgende Frage: Welcher konkrete Test bestätigt ihre Erfüllung? Falls Sie keine konkrete Antwort finden, formulieren Sie die Anforderung so lange um, bis ein Test möglich ist.

Die gefährlichsten Formulierungen verwenden qualitative Adjektive: intuitiv, ergonomisch, einfach, schnell, robust, modern, professionell. Diese Wörter sind in einem Vertragsdokument wertlos. Sie haben für Sie eine andere Bedeutung als für den Dienstleister. Ersetzen Sie sie stets durch messbare Kriterien: eine Dauer, eine Anzahl von Aktionen, eine Verfügbarkeitsrate, einen quantifizierbaren Schwellenwert.

Jede Anforderung in den Funktionsspezifikationen sollte am Tag der Inspektion ohne Diskussion überprüfbar oder widerlegbar sein. Dieses Kriterium zeichnet ein zuverlässiges Dokument aus, das sowohl den Auftraggeber als auch den Dienstleister vor subjektiven Meinungsverschiedenheiten bei der Abnahme schützt.

Was das Dokument Abschnitt für Abschnitt enthalten sollte

Ein Dokument mit funktionalen Spezifikationen hat kein vorgeschriebenes Format. Es folgt jedoch einer logischen Struktur, die jeder Leser ohne weitere Hilfe nachvollziehen kann. Die hier dargestellten Abschnitte beantworten jeweils eine spezifische Frage. Fehlt ein Abschnitt, entsteht eine Lücke, die der Dienstleister bei der Erstellung seines Angebots auf Basis seiner eigenen Annahmen füllt.

Der Abschnitt „Kontext und Herausforderungen“ wird oft zu schnell verfasst. Ein Dienstleister, der das zugrundeliegende Problem versteht, wird eine passendere Lösung vorschlagen als jemand, der lediglich eine Liste von Anforderungen ohne jegliche Erläuterung abarbeitet. Nehmen Sie sich die Zeit zu erklären, warum dieses Projekt gerade jetzt gestartet wird und welches konkrete Problem es lösen soll.

Der Abschnitt zum Projektumfang ist genauso wichtig wie die Anforderungsliste selbst. Alles, was nicht explizit ausgeschlossen ist, ist potenziell enthalten, was im Projektverlauf zu zusätzlichen Anforderungen führen kann. Die Auflistung von Ausschlusskriterien schützt beide Parteien und vermeidet Unstimmigkeiten über den tatsächlichen Arbeitsumfang.

Der Abschnitt zu den Abnahmekriterien fehlt häufig in den an Dienstleister versandten Dokumenten. Sein Fehlen ist der Hauptgrund dafür, dass Lieferstreitigkeiten auf der Grundlage individueller Auslegungen und nicht anhand eines vorab festgelegten gemeinsamen Standards beigelegt werden. Ohne ihn bleibt die „akzeptable Leistung“ eine subjektive Vorstellung. Mit ihm wird sie zu einem rechtsverbindlichen Kriterium.

Wer hat es geschrieben und mit wem?

Die funktionalen Spezifikationen werden vom Auftraggeber erstellt: Er formuliert den Bedarf und übernimmt die Kosten für dessen Erfüllung. Nicht der Dienstleister verfasst sie, selbst wenn er über anerkannte Fachkenntnisse verfügt. Würde der Dienstleister dieses Dokument selbst erstellen, definiert er damit seinen Leistungsumfang, was den Zweck der Spezifikationserstellung untergräbt.

Der Texter fungiert als Projektverantwortlicher. Er vertritt die Bedürfnisse des Kunden, nicht die Lösungen des Entwicklers. Diese Rolle kann in Kleinstunternehmen oder kleinen bis mittelständischen Betrieben vom Geschäftsführer selbst übernommen werden, in strukturierteren Organisationen hingegen von einem kundenseitigen Projektmanager. In jedem Fall ist es erforderlich, die zukünftigen Nutzer des Endprodukts einzubeziehen, anstatt lediglich die Vorstellungen des Geschäftsführers aus dem Büro zu übertragen.

Zukünftige Nutzer drücken ihre Bedürfnisse naturgemäß in Form von Lösungen aus: Sie wünschen sich einen Button, einen Tab, eine zu exportierende Datei. Die Aufgabe des Autors besteht darin, diese Wünsche in funktionale Anforderungen umzuformulieren und dabei eine Ebene zurückzugehen, um die eigentliche, hinter jedem Wunsch erwartete Aktion zu ermitteln. Diese Übersetzungsarbeit verleiht dem Dokument seinen Wert.

Um die Rollen aller Beteiligten in diesem Prozess zu strukturieren, RACI-Matrix Es legt fest, wer für die Erstellung des Dokuments verantwortlich ist, wer zur Mitarbeit hinzugezogen werden soll, wer den Inhalt vor der Einreichung freigibt und wer lediglich über den Fortschritt informiert werden muss. Dieses Tool vermeidet Unklarheiten bezüglich der Verantwortlichkeiten und beugt Überraschungen während des Erstellungsprozesses vor.

Anforderungen priorisieren, ohne dabei den Überblick zu verlieren

Nicht alle Anforderungen sind gleichwertig. Einige sind unerlässlich: Werden sie nicht erfüllt, ist das Ergebnis unbrauchbar. Andere sind wichtig, verhindern aber keine weitere Bearbeitung, falls sie in der ersten Version fehlen. Wieder andere sind wünschenswert und können bis zu einer späteren Projektversion warten, ohne die ursprüngliche Abnahme zu beeinträchtigen.

Diese Hierarchie muss im Dokument klar definiert sein. Andernfalls weiß der Dienstleister nicht, worauf er sich konzentrieren soll, wenn Budget- oder Zeitbeschränkungen ihn zu Entscheidungen zwingen. Er trifft die Entscheidung für Sie, und das wollen Sie sicher nicht.

In einem typischen Projekt reichen drei Prioritätsstufen aus: essentiell, wichtig und wünschenswert. Fünf oder sechs sind nicht nötig. Zu detaillierte Aufschlüsselungen sind kontraproduktiv: Diskussionen über die Priorität einer Anforderung können dann länger dauern als deren eigentliche Umsetzung.

Die Priorisierung muss vor der Einreichung des Dokuments erfolgen, nicht erst während der Verhandlungen mit dem Dienstleister. Darauf zu warten, dass der Dienstleister fragt, was gestrichen werden kann, ist gleichbedeutend mit überhastetem Verhandlungsdruck und einem Partner, der selbst ein Interesse an einer Reduzierung seines Arbeitsumfangs hat. Die Priorisierung ist ein Akt der Klarheit, den der Auftraggeber selbst schafft, bevor er Dritte beauftragt.

Ein sinnvoller Kontrollpunkt nach Abschluss der Priorisierung: Prüfen Sie, ob das geplante Budget nur die „wesentlichen“ Anforderungen abdeckt. Sollten diese das verfügbare Budget bereits übersteigen, weist das Dokument ein Problem auf, das vor der Einreichung beim Dienstleister behoben werden muss.

Budget und Fristen, wie weit soll man bei den funktionalen Spezifikationen gehen?

Budget und Fristen sind in den Funktionsspezifikationen präzise aufgeführt: Gesamtbudget und Zieldatum. Eine detaillierte Aufschlüsselung nach Anforderungen oder ein detaillierter Wochenplan liegen zu diesem Zeitpunkt noch nicht vor.

Die Festlegung eines Maximalbudgets ermöglicht es Dienstleistern, ihre Angebote individuell anzupassen. Sie wissen, dass ein Angebot, das dieses Limit deutlich überschreitet, nicht angenommen wird und können daher Prioritäten zwischen notwendigen und wünschenswerten Anforderungen setzen. Ein häufiger Fehler ist das Fehlen eines Budgets: Es erzwingt einen Vergleich von Angeboten mit sehr unterschiedlichem Umfang und führt zu einer Informationsasymmetrie, die den Kunden benachteiligt.

Für die Festlegung von Fristen genügt es in der Phase der Funktionsspezifikationen, einen angestrebten Inbetriebnahmetermin und unvermeidbare Terminbeschränkungen anzugeben. Die genaue Definition von Projektmeilensteine Dies wird dann mit dem ausgewählten Dienstleister besprochen, sobald die Lösung ausgewählt und die Arbeitsweise zwischen den Parteien vereinbart wurde.

Wenn Sie bereits vor der Auswahl des Dienstleisters einen umfassenden Zeitplan erstellen müssen, ist der Aufbau eines umgekehrte Planung Die Verwendung des Zieldatums als Ausgangspunkt hilft Ihnen, die unabdingbaren terminlichen Einschränkungen zu identifizieren, die im Dokument erwähnt werden müssen, ohne auf die Details eines Ausführungsplans einzugehen, der noch nicht zu dieser Phase des Projekts gehört.

Lassen Sie es vor dem Absenden Korrektur lesen und genehmigen.

Ein Dokument mit funktionalen Spezifikationen sollte nicht eingereicht werden, ohne vorher von mindestens zwei Personen geprüft worden zu sein, die nicht an seiner Erstellung beteiligt waren. Diese externe Prüfung deckt auf, was dem Autor selbst entgeht: Unklarheiten, implizite Annahmen und Passagen, die nur verständlich sind, weil sie mit dem Kontext bereits vertraut sind.

Die erste Überprüfung sollte von einem zukünftigen Nutzer des Dokuments durchgeführt werden. Dieser sollte bestätigen, dass die Anforderungen mit seinen tatsächlichen Arbeitserfahrungen übereinstimmen und auf etwaige Lücken oder unklare Formulierungen hinweisen. Diese praxisnahe Überprüfung deckt oft die größten Schwächen des ersten Entwurfs auf.

Die zweite Überprüfung sollte von einer Person durchgeführt werden, die nicht am Projekt beteiligt ist und keine Vorkenntnisse zum Thema hat. Diese Person sollte sicherstellen, dass das Dokument ohne mündliche Erläuterung verständlich ist. Falls Rückfragen nötig sind, um die Anforderungen zu verstehen, ist das Dokument noch nicht zur Einreichung bereit.

Sobald die Korrekturen eingearbeitet sind, muss das Dokument vor der Übermittlung formell validiert werden. Diese Validierung kann in Form einer Unterschrift, einer Bestätigungs-E-Mail oder eines in einer Besprechung protokollierten Beschlusses erfolgen. Protokoll der Sitzung Dies stellt die offizielle und rechtsverbindliche Fassung dar. Ohne diese Bestätigung bleibt das Dokument ein Entwurf, selbst wenn Sie es bereits eingereicht haben.

Bei Projekten mit mehreren Entscheidungsträgern sollte die Validierung während eines Projekts organisiert werden. Lenkungsausschuss Dieses Gremium ist diesem Zweck gewidmet. Es bringt die Personen zusammen, die befugt sind, sich zu dem Projekt zu verpflichten, und stellt sicher, dass jede einzelne Person das Dokument vor dessen externer Weitergabe an die Dienstleister tatsächlich gelesen und genehmigt hat.

Was passiert, wenn ein Dienstleister etwas anderes anbietet als das, was angefordert wurde?

Ein Dienstleister kann auf Ihre funktionalen Spezifikationen mit einem anderen Ansatz reagieren, als Sie ursprünglich geplant hatten. Das ist nicht nur möglich, sondern manchmal sogar wünschenswert. Genau deshalb beschreiben funktionale Spezifikationen Bedürfnisse, nicht Lösungen: um Raum für eine bessere Antwort zu lassen, als Sie sie selbst hätten entwickeln können.

Die entscheidende Frage bei einem Alternativvorschlag lautet nicht: „Entspricht das meinen Anforderungen?“, sondern: „Erfüllt es meine Vorgaben?“ Lautet die Antwort „Ja“, ist der Vorschlag gültig, auch wenn er von Ihrer ursprünglichen Vision abweicht. Lautet die Antwort „Nein“, muss der Anbieter darlegen, wie er die verbleibenden, noch nicht erfüllten Anforderungen in seinem Vorschlag umsetzen will.

Es sind jedoch zwei Situationen zu unterscheiden. Erstens: Der Dienstleister schlägt einen alternativen Ansatz vor, der alle Ihre Anforderungen erfüllt. Genau dieses Szenario sollen die funktionalen Spezifikationen ermöglichen. Bewerten Sie das Angebot anhand der Anforderungen, nicht anhand des gewählten Mechanismus. Zweitens: Der Dienstleister schlägt einen alternativen Ansatz vor, der bestimmte wesentliche Anforderungen nicht abdeckt, und argumentiert, dass dieser für Sie besser sei. Fordern Sie ihn auf, nachzuweisen, dass Ihre Bedürfnisse erfüllt werden, oder seinen Vorschlag entsprechend anzupassen.

Diese Argumentation ist besonders wichtig, wenn Sie ein/e Lieferantenausschreibung Die Antworten stammen von verschiedenen Dienstleistern. Ohne eine klare Funktionsspezifikation basieren sie nicht auf demselben Rahmenwerk und lassen sich nicht objektiv vergleichen. Mit dieser Spezifikation können Sie jede Anforderung einzeln bewerten, unabhängig vom gewählten technischen Ansatz der einzelnen Anbieter.

Das Dokument im Laufe des Projekts weiterentwickeln, ohne seine grundlegende Natur zu verändern

Eine funktionale Spezifikation kann sich weiterentwickeln. Projekte dauern Wochen oder Monate, und der Kontext ändert sich. Es können Bedürfnisse auftauchen, die zu Beginn nicht erkannt wurden. Eine Anforderung kann sich als unnötig oder unrealistisch erweisen, sobald die ersten Zwischenergebnisse vorliegen. Die Weiterentwicklung des Dokuments ist an sich kein Problem.

Das Problem ist eine undokumentierte und nicht validierte Weiterentwicklung. Ändert sich eine Anforderung mündlich, ohne dass das Dokument aktualisiert und beide Parteien der Änderung zugestimmt haben, existieren zwei Projektversionen parallel: die des Dienstleisters und Ihre. Dies ist die häufigste Ursache für Missverständnisse bei der Projektabwicklung und eine der kostspieligsten, die behoben werden müssen.

Jede Änderung des Dokuments muss diesem Protokoll entsprechen:

• Machen Sie deutlich, was sich ändert: welche Anforderung, in welche Richtung und aus welchem ​​Grund.
• Beurteilen Sie die Auswirkungen dieser Änderung auf das vereinbarte Budget und den Zeitrahmen.
• Bevor die Änderung als offiziell gilt, muss eine formelle Bestätigung beider Parteien eingeholt werden.
• Datum der Änderung und Nummer der neuen Version des Dokuments

Eine Versionsübersicht auf der ersten Seite des Dokuments, in der jede Version mit Datum und Zweck aufgeführt ist, ermöglicht es, die Entscheidungshistorie nachzuvollziehen. Dies ist keine überflüssige Formalität: Im Streitfall lässt sich so nachweisen, was wann genau vereinbart wurde.

Anzeichen für eine schlecht formulierte Spezifikation

Bestimmte Anzeichen können schnell darauf hinweisen, dass ein Funktionsspezifikationsdokument in seiner jetzigen Form unbrauchbar ist. Die Identifizierung dieser Anzeichen vor dem Versenden des Dokuments verhindert, dass ein Dienstleister von einer falschen Grundlage ausgeht.

Erstes Anzeichen: Dieses Dokument beschreibt Schnittstellenkomponenten. Wenn Sie auf Schaltflächen, Registerkarten, Dropdown-Menüs oder Formularfelder stoßen, handelt es sich nicht um eine Funktionsspezifikation. Diese Elemente gehören in die technischen Spezifikationen, nicht in dieses Dokument.

Zweites Signal: Keine der Anforderungen nennt ein messbares Kriterium. Enthält der gesamte Text Wörter wie „einfach“, „schnell“, „intuitiv“ oder „einfach“, lässt das Dokument bei der Zustellung keine Überprüfung zu.

Drittes Signal: Das Dokument unterscheidet nicht zwischen dem Wesentlichen und dem Wünschenswerten. Wenn alle Anforderungen gleichwertig erscheinen, kann der Dienstleister bei Budget- oder Terminbeschränkungen keine Prioritäten setzen.

Viertes Signal: Ohne weitere mündliche Erläuterung ist der Zweck des Projekts nicht verständlich. Ein gutes Dokument ist selbsterklärend. Ein Leser, der Sie nicht kennt, sollte den Zweck allein durch das Lesen des Dokuments erfassen können.

Fünftes Signal: Das Dokument wurde von einer einzelnen Person verfasst, ohne die zukünftigen Nutzer des Ergebnisses zu konsultieren. Die blinden Flecken sind in diesem Fall zahlreich und systematisch und treten stets im ungünstigsten Moment zutage: bei der Auslieferung.

Wenn Sie einen dieser Fehler entdecken, überprüfen Sie den entsprechenden Abschnitt, bevor Sie das Dokument absenden. Ein Dokument, das aus Zeitgründen zu schnell verfasst wurde, verursacht oft deutlich höhere Korrekturkosten, sobald das Projekt von Anfang an schlecht gelaufen ist.

Ein vollständiges, von Anfang bis Ende entwickeltes Funktionsspezifikationsdokument für ein konkretes Projekt

Hier ist ein vollständiges Beispiel, um all das oben Genannte zu veranschaulichen. Ein kleines Unternehmen für Haushaltsdienstleistungen mit fünfzehn Mitarbeitern und zweihundert aktiven Kunden möchte seinen Kunden ermöglichen, Dienstleistungen zu buchen, ihre Servicehistorie einzusehen und online zu bezahlen, ohne telefonisch oder per E-Mail Kontakt aufnehmen zu müssen.

Abschnitt „Kontext und Probleme“: Das Unternehmen wickelt alle Buchungen nun per Telefon und E-Mail ab. Für die Koordination der eingehenden Anrufe wird eine Teilzeitkraft benötigt. Ziel ist es, Kunden die eigenständige Verwaltung ihrer Buchungen zu ermöglichen, die Anzahl der eingehenden Anrufe zu reduzieren und die Zahlungsabwicklung zu beschleunigen.

Umfangsschnitt: Dieses Projekt umfasst die Online-Buchung für Kunden, den Zugriff auf die Servicehistorie und die Online-Zahlung. Ausdrücklich ausgeschlossen sind die Terminplanung von Dienstleistern, die interne Rechnungsstellung, das Personalmanagement und die Buchhaltung.

Abschnitt „Interessengruppen“: Die Ergebnisse werden von drei Profilen genutzt. Der Endkunde bucht, sieht sich die Buchung an und bezahlt. Der Unternehmensadministrator genehmigt Buchungen außerhalb der automatischen Zeitfenster und sieht die Zahlungen ein. Der Manager hat Zugriff auf die Gesamtdaten, kann diese aber nicht direkt bearbeiten.

Abschnitt „Einschränkungen“: Das Ergebnis muss auf allen gängigen Browsern und Mobilgeräten funktionieren. Es muss den geltenden Datenschutzbestimmungen entsprechen. Es muss auch von Personen ohne technische Vorkenntnisse bedient werden können.

Abschnitt Budget und Fristen: Das Gesamtbudget für die erste Phase beträgt zwölftausend Euro. Die geplante Inbetriebnahme ist sechs Monate nach dem tatsächlichen Projektbeginn vorgesehen.

Die Anforderungsverfolgungstabelle für dieses Projekt zeigt, wie jede Anforderung nach Eingang formuliert, priorisiert, überprüft und dokumentiert wird:

Nachdem das Dokument von zwei Teammitgliedern und einem Testkunden geprüft wurde, wird es an drei konkurrierende Anbieter weitergeleitet. Jeder Anbieter antwortet, indem er für jede Anforderung angibt, ob, in welchem ​​Umfang und mit welchem ​​Ansatz sie abgedeckt ist. Alle „wesentlichen“ Anforderungen, die in einem Angebot nicht berücksichtigt werden, führen ohne weitere Verhandlungen zum Ausschluss des jeweiligen Angebots aus dem Vergleich.

Um eine nachhaltige Zusammenarbeit zu gewährleisten und die Verpflichtungen jeder Partei von Anfang an klar zu definieren, müssen die allgemeinen Projektbedingungen innerhalb eines festgelegten Zeitraums festgelegt werden. Projektauftrag formalisiert den Governance-Rahmen und die Verantwortlichkeiten jeder Partei von Beginn an.

Häufige Fehler und wie man sie korrigiert

Dieselbe Fehlerart findet sich in zahlreichen Funktionsspezifikationen, unabhängig von Branche und Unternehmensgröße. Werden diese Fehler vor der Einreichung erkannt, können sie korrigiert werden, ohne dass das gesamte Dokument neu geschrieben werden muss.

Jeder dieser Fehler lässt sich direkt beheben, ohne dass das gesamte Dokument neu geschrieben werden muss. Dazu geht es darum, die relevanten Passagen anhand dreier einfacher Fragen erneut zu prüfen: Drücke ich ein Bedürfnis oder eine Lösung aus? Lässt sich diese Anforderung am Tag der Abnahme ohne Diskussion überprüfen? Würde ein externer Leser verstehen, was ich von dieser Zeile erwarte?

Organisieren Sie das Projektmonitoring mit Djaboo nach der Dokumentenvalidierung.

Djaboo ist eine All-in-One-Management-Software, die für Kleinstunternehmen und KMU entwickelt wurde und die Verwaltung von Projekten, Kunden, Aufgaben und Rechnungsstellung in einer Benutzeroberfläche zentralisiert, die ohne technische Kenntnisse zugänglich ist.

Sobald Ihre Funktionsspezifikationen genehmigt und der Dienstleister ausgewählt sind, können Sie mit Djaboo die nächsten Schritte organisieren. Ein erstelltes Projekt hat einen Namen, einen Kunden, eine Beschreibung, einen Status, ein Startdatum, eine Frist, eine geschätzte Stundenzahl und eine Fortschrittsanzeige. Jede diesem Projekt zugeordnete Aufgabe hat einen Namen, eine Beschreibung, eine Priorität, einen Status, Start- und Enddatum, eine Meilensteinzuordnung sowie zwei Indikatoren, die angeben, ob die Aufgabe abrechnungsfähig ist und ob sie bereits abgerechnet wurde. Das Projekt bietet einen Bereich zum Hochladen von Dateien mit einer Einstellung, die festlegt, ob die jeweilige Datei für den Kunden sichtbar ist, sowie Notizen, Diskussionen und ein mit Zeitstempel versehenes Aktivitätsprotokoll.

Es ist wichtig, die Einschränkungen von Djaboo klar zu benennen, ohne diese zu umgehen. Das Tool verfügt über kein „Spezifikations“-Objekt: keine spezielle Vorlage, kein „Anforderungsfeld“ und keine Checkbox, um beim Empfang zu bestätigen, ob eine Anforderung erfüllt ist. Das „Prioritätsfeld“ einer Aufgabe ist eine Freitextbezeichnung und keine formale Klassifizierung der Anforderungen nach Wichtigkeit. Einzelnen Aufgaben sind weder Budget noch Dauer zugeordnet; nur für das gesamte Projekt werden Stunden geschätzt. Es gibt keine Matrix, die eine Anforderung mit der entsprechenden Aufgabe oder Datei verknüpft, und eine formale Signatur oder Validierung eines Dokuments ist innerhalb des Tools nicht möglich.

So arbeiten Sie trotz dieser Einschränkungen effizient: Die Funktionsspezifikationen werden außerhalb des Tools in einem Textverarbeitungsprogramm oder einer Tabellenkalkulation erstellt und anschließend als Projektanhang mit den entsprechenden Sichtbarkeitseinstellungen hochgeladen, je nachdem, ob Sie sie mit dem Kunden teilen möchten oder nicht. Jede ausgewählte Anforderung wird dann zu einer separaten Aufgabe im Projekt, sodass Sie deren Ausführung verfolgen und gegebenenfalls in Rechnung stellen können. Die Priorität der Anforderung, wie sie im Dokument angegeben ist, wird in die Prioritätsbezeichnung der Aufgabe übernommen und ist somit täglich sichtbar. Die Überprüfung nach der Lieferung erfolgt manuell durch die Prüfung der einzelnen Anforderungen im Dokument: Das Tool kann dies nicht automatisch durchführen.

Die Beschreibung eines Bedarfs statt einer Lösung ist keine formale Einschränkung, sondern ermöglicht die optimale Lösung. Ein Dienstleister, der Ihre Ziele versteht, kann Ihnen einen Ansatz vorschlagen, den Sie noch nicht in Betracht gezogen haben – einen, der sich als relevanter, kostengünstiger oder langfristig wartungsfreundlicher erweist. Ein Anbieter, der sich auf eine Liste technischer Komponenten beschränkt, liefert genau das, was angefordert wurde, selbst wenn es nicht Ihren Bedürfnissen entspricht.

Eine Anforderung, die bei der Lieferung nicht erfüllt wird, war nie eine Anforderung, sondern lediglich eine Absichtserklärung. Der Unterschied zwischen beiden zeigt sich bei der Abnahme, wenn entschieden werden muss, ob das Ergebnis den Anforderungen entspricht oder nicht. Ein Dokument, das auf Absichtserklärungen basiert, überlässt diese Entscheidung der individuellen Interpretation. Ein Dokument, das auf überprüfbaren Anforderungen beruht, macht sie objektiv und unabhängig von momentanen Stimmungen und Interpretationen.