Kostenlose Vorlagen für funktionale Spezifikationen: Die Roadmap für eine reibungslosere Entwicklungserfahrung

„Agile“ konzentriert sich darauf, den effizientesten Weg zu finden, um einem Benutzer ein nützliches Produkt bereitzustellen. In der Agile-Entwicklung werden traditionelle funktionale Anforderungsunterlagen und -prozesse manchmal als finanziell unerschwinglich angesehen. Das Erfassen detaillierterer Pläne und Skizzen kann jedoch für mehr Klarheit sorgen.

Eines der häufigsten Tools für Agile-Anforderungen ist die Benutzergeschichte. Benutzergeschichten stellen Funktionen in den Kontext der Anforderungen des Benutzers. Sie können ähnliche Benutzergeschichten zu Agile-Epen gruppieren. Wie bei herkömmlichen Spezifikationen für funktionale Anforderungen beschreiben Benutzergeschichten die Aufgabe oder Funktion, aber nicht die Art und Weise, wie die Entwickler sie implementieren sollten.

Benutzergeschichten verwenden die folgende Syntax: „Als Benutzer möchte ich etwas haben, damit sich daraus ein Nutzen ergibt.“ Nachfolgend finden Sie einige Beispiele:

• Als Fahrer möchte ich wissen, wann meine Batterie ausgetauscht werden muss.
• Als Koch möchte ich, dass ein Tablet-Bildschirm aktiviert bleibt, während ich nach einem Rezept koche.
• Als Katze möchte ich jeden Nachmittag um 16 Uhr meine Portion Futter in meine Schüssel erhalten.

Um zu testen, ob eine Benutzergeschichte gut ausgearbeitet ist, wenden Sie das Akronym INVEST an.

• Unabhängig: Kann die Geschichte für sich allein stehen?
• Verhandelbar: Können Sie diese Geschichte ändern oder entfernen, ohne den Rest des Projekts zu beeinträchtigen?
• Wertvoll: Hat diese Geschichte einen Mehrwert für den Endbenutzer?
• Abschätzbar: Können Sie die Größe der Geschichte abschätzen?
• Klein: Ist die Benutzergeschichte klein genug?
• Testbar: Können Sie diese Geschichte testen?

Zum Projektmanagement können Sie im Tracking-Tool Benutzergeschichten einen Namen und eine nummerierte ID geben. Darüber hinaus können Sie den Entwicklungsprioritäts-, Sprint- und Story-Status markieren. Geschichten werden in das Agile-Produkt-Backlog aufgenommen.

Vorlagen für Benutzergeschichten sind normalerweise ziemlich einfach: Sie konzentrieren sich darauf, die Rolle und Aufgaben des Benutzers zu identifizieren und was mit der Aufgabe erreicht werden soll. Darüber hinaus enthält die folgende Vorlage Platz, um die Informationen zur Geschichte und zum Entwicklungszyklus zu identifizieren.

Einfache Vorlage für Agile-Benutzergeschichte herunterladen

Excel | Word

Die Planung einer Website erfordert ein umfassendes Verständnis der notwendigen Technologie sowie detaillierte Kenntnisse dazu, wer die Website nutzt und was der Benutzer Ihrer Ansicht nach (Sie als Inhaber der Website) erreichen soll. Die in der Agile-Entwicklung verwendeten Benutzergeschichten helfen Ihnen, sich auf die Bedürfnisse der Benutzer zu konzentrieren. Andere Fragen helfen auch, die Website in den Kontext zu setzen.

In der folgenden Vorlage für die Spezifikation von Websites wird eine Reihe von Fragen gestellt, die Ihnen helfen, den Zweck der Website zu definieren, herauszufinden, für wen diese Website gedacht ist, die Aktivitäten zu ermitteln, die auf der Website durchgeführt werden, sowie besondere Erwägungen wie Sicherheitsstandards wie PCI für Finanztransaktionen zu definieren.

Vorlage für funktionale Spezifikationen für Websites herunterladen

Word

Vorlage für technische Spezifikationen für Websites herunterladen

Excel

Wenn Sie Software und andere Technologien mit der Wasserfall-Methode entwickeln, können Sie oft eine traditionelle Vorlage für funktionale Anforderungen oder Spezifikationen verwenden. Funktionale Anforderungen listen Merkmale und Funktionen dessen auf, was das Produkt tun „soll“. Zum Beispiel: „Der Staubsauger soll Partikel aufnehmen, die kleiner als 5 mm sind.“

‌ Vorlage für funktionale Spezifikationen herunterladen – Word

Vielleicht möchten Sie auch eine Vorlage, die sich stärker auf die Geschäftsanforderungen konzentriert. Diese minimalistische Vorlage bietet Platz, um den Zweck Ihres Produkts oder Upgrades im Zusammenhang mit Ihren Geschäftszielen detailliert zu beschreiben, zusätzlich zu Designüberlegungen auf höherer Ebene.

‌ Vorlage für funktionale Anforderungen herunterladen – Word

 

Sie können Anwendungsfälle für viele Arten von Produkten erstellen, einschließlich Websites und Software. Anwendungsfälle konzentrieren sich auf Aufgaben, die ein Benutzer mit dem Produkt ausführen muss. Indem sie sich auf die Aufgaben konzentrieren, helfen die Dokumente zu Anwendungsfällen den Entwicklern, benutzerorientierte Produkte zu erstellen. Diese Dokumente verhindern außerdem, dass die Beteiligten das Produktdesign falsch interpretieren. Verwenden Sie diese Vorlage für Anwendungsfälle, um eine Aufgabe in Bezug auf Akteure, Schritte und Zweige zu definieren.

Vorlage für Anwendungsfälle herunterladen

Word

Ein funktionales Spezifikationsdokument (FSD), auch bekannt als funktionales Anforderungsdokument (FAD), wird von vielen Experten für Projektmanagement und Softwareentwicklung als das wichtigste Instrument angesehen, um Verwirrung und Irreführung bei einem Projekt zu verhindern.

Obwohl FSDs häufig mit Software- und Webentwicklung verbunden sind, spielen sie in jedem Projekt eine Rolle, sei es die Einführung eines neuen Produkts oder Upgrades, die Entwicklung eines Softwareprodukts oder eines materiellen Objekts oder die Etablierung von Prozess- oder Organisationsänderungen. Dokumente mit funktionalen Spezifikationen stellen sowohl geschäftliche als auch technische Erwartungen dar. Alle Beteiligten prüfen und genehmigen das Dokument. Das Ergebnis ist ein Referenzdokument für das vorgeschlagene Produkt, das sich an alle Bereiche der Organisation richtet, von Programmierern über Designer bis hin zu Vertriebsmitarbeitern.

Sie können eine Dokumentvorlage für funktionale Spezifikationen verwenden, um sicherzustellen, dass Sie alle wichtigen Entwicklungsinformationen in ein Dokument aufnehmen. Außerdem garantieren Vorlagen, dass sich die Teams bei jeder neuen Initiative auf die Anforderungen an das Produkt konzentrieren, anstatt Zeit damit zu verschwenden, das Design des Spezifikationsdokuments festzulegen. Vorlagen sollten an die individuellen Bedürfnisse jedes Teams oder Unternehmens angepasst werden.

Traditionell sind FRDs meist lang, trocken und oft technisch. Aber solche Dokumente sind möglicherweise nicht notwendig oder nicht einmal besonders nützlich. Da der Zweck des Dokuments für funktionale Anforderungen darin besteht, den Umfang des Projekts für alle Beteiligten darstellen, vermeiden FRDs langwierige Diskussionen über technische Themen. Sie können zwar viele Arten von Anforderungen und unterstützende Informationen enthalten (siehe die Liste unten), aber die beste Vorgehensweise besteht darin, nur die grundlegenden Absichten des FRD zu beschreiben. Im Kern muss das Dokument den Kontext und die zu entwickelnden Merkmale und Funktionen beschreiben. Ein technisches Designdokument wird basierend auf den akzeptierten Funktionsanforderungen erstellt. Das FRD keine anderen Anforderungen oder Prozessdokumente doppelt enthalten.

Dokumente mit funktionalen Spezifikationen erfordern ein Genehmigungsverfahren: Business-Benutzer überprüfen, ob die Lösung auf ihre Belange eingeht, und technische Prüfer überprüfen, ob die beschriebene Lösung implementiert werden kann. Zu den wichtigsten Prüfern gehören häufig Tester, Endnutzer, technische Redakteure sowie Produkt- oder Systemeigentümer. Sie erklären das Dokument für abgeschlossen, wenn alle mit dem Inhalt einverstanden sind. Einige Organisationen erstellen dann ein Dokument für die Systemarchitektur.

Eine funktionale Anforderungsspezifikation dient als Referenzdokument für das gesamte Team. Es zeigt, was Produktentwickler entwickeln sollten, was Tester testen sollten, welche Autoren dokumentieren sollten und welche Vertriebsmitarbeiter für den Verkauf zuständig sein werden. Eine schriftliche Funktionsspezifikation zeigt, dass Design und Absicht vor Beginn der Entwicklung umfassend berücksichtigt wurden. Sie zeigt auch, dass sich nach der Genehmigung der Spezifikation alle Beteiligten einig sind. Die Spezifikationen sollten nicht geschrieben werden, um das Dokument nach dem Kodieren des Produkts aufzufüllen.

Einige Geschäftsanalysten und Entwickler unterscheiden funktionale Spezifikationen von funktionalen Anforderungen. Sie sind der Ansicht, dass Anforderungen beschreiben, was die Software tun muss, und dass Spezifikationen beschreiben, wie die Software dies tun muss. In der Praxis kombinieren Sie diese beiden Rollen in der Regel.

Dokumentvorlagen für funktionale Spezifikationen (oder Anforderungen) können auch verschiedene Formate annehmen. Das von Ihnen gewählte Format hängt davon ab, was für Ihr Unternehmen am besten funktioniert.

• Funktionale Anforderungen: Dies ist für Software und andere Technologien, die die Wasserfall-Entwicklungsmethode verwenden, üblich. Funktionale Anforderungen listen Merkmale und Funktionen auf, was das Produkt tun „soll“. Zum Beispiel: „Der Staubsauger soll Partikel aufnehmen, die kleiner als 5 mm sind.“
• Anwendungsfälle: Anwendungsfälle stehen oft für sich allein. Organisationen, die die Benutzererfahrung schätzen, integrieren Anwendungsfälle allerdings in der Regel in funktionale Anforderungen. In Anwendungsfällen werden Merkmale und Funktionen im Kontext von Benutzeraktionen festgelegt. Beispiel: „Der Benutzer tippt doppelt auf den Telefonbildschirm. Der Bildschirm ist beleuchtet. Der Benutzer wischt auf dem Bildschirm nach rechts, um das Telefon und seine Funktionen zu entsperren.“
• Benutzergeschichten: Benutzergeschichten bilden den Kern der Agile-Entwicklung, denn sie beschreiben Produktdesign als das, was der Benutzer tun muss. Dieser prägnante Ansatz hilft Teams, den Benutzern auf die effizienteste Weise einen Mehrwert zu bieten. Benutzergeschichten haben folgendes Format: „Als Benutzer kann ich etwas tun, damit ich einen Nutzen erzeuge.“

In der Regel erstellen Geschäftsanalysten und technische Leiter Vorlagen und funktionale Spezifikationen, die sie an Beteiligte und Techniker weitergeben. Diese geben dann Bewertungen ab, um sicherzustellen, dass die erwartete Leistung dem festgelegten Ziel entspricht.

Sie können bei der Entwicklung neuer Software und Upgrades funktionale Spezifikationen verwenden. Sie können sie auch für organisatorische und Änderungen, Änderungen beim System-Engineering, Webentwicklung und mehr verwenden. Benutzer von Spezifikationen umfassen die folgenden Gruppen:

• Entwickler, die das Produkt kodieren
• Designer, die die Benutzeroberfläche für die Software, das Gerät oder die Website erstellen
• Tester, die sicherstellen, dass der Code korrekt und nach Spezifikation funktioniert
• Marketingexperten, die Dokumente anforderungsgemäß zur neuen Funktion erstellen
• Vertriebsteams, die die Funktion und das Produkt verkaufen
• Technische Redakteure oder Autoren von Benutzerhandbüchern, die dokumentieren, wie das Produkt für Administratoren, Endbenutzer und andere Rollen funktioniert

Obwohl viele Kombinationen und Permutationen von Dokumenten vorhanden sind, sind funktionale Spezifikationsdokumente (FSDs) und Dokumente für Geschäftsanforderungen (DGAs) manchmal getrennt.

DGAs beschreiben die übergeordneten Geschäftsanforderungen für ein Produkt (also was ein Produkt tut). DGAs enthalten weniger technische Details, dafür aber eine detaillierte Begründung für das Produkt. Ein klares Verständnis dafür, was das Produkt bietet und warum es notwendig ist, kann oft helfen, die Entwicklung bei Uneinigkeiten über die Produktausrichtung voranzutreiben. FSDs können sich darauf konzentrieren, die Merkmale und Funktionen des Produkts zu erläutern, die Sie benötigen, um Ihr oberstes Ziel zu erreichen.

Bei der Erstellung eines Produkts, ob konkret oder transaktional, können viele Dokumente erstellt werden. Vorlagen für funktionale Spezifikationen können in Verbindung mit folgenden Vorlagen verwendet werden:

• Benutzeranforderungen: Dieses Dokument stellt dar, was der Benutzer von dem Produkt erwartet. Einige betrachten die Benutzeranforderung als Teil des Dokuments für funktionale Anforderungen. Wenn dieses Dokument vorhanden ist, sollte es in Ihren gesamten Entwicklungsprozess einbezogen werden. In der agilen Entwicklung werden Benutzeranforderungen (ausgedrückt als Benutzergeschichten) als Herzstück funktionaler Anforderungen betrachtet.
• Produktanforderungen: Dieses Dokument, das austauschbar mit einem Dokument für Marktanforderungen verwendet wird, beschreibt den Zweck eines Produkts.
• Dokumente zum Geschäftsprozess: In diesem Dokument wird ein Geschäftsprozess detailliert dargestellt.
• Einschätzungen von Unternehmensanforderungen: In diesem Dokument werden die Lücken zwischen den aktuellen Gegebenheiten und den gewünschten geschäftlichen Gegebenheiten beschrieben.
• Technische Designspezifikationen: In diesem Dokument werden (im Detail) die für das vorgeschlagene Design erforderlichen Programmierelemente beschrieben.
• Validierungsdokumente: Validierungsdokumente können eine Nachverfolgbarkeitsmatrix (die Funktionen während des gesamten Entwicklungsprozesses nachverfolgt), Testpläne und Betriebsanforderungen enthalten.
• Systemanforderungen: In diesem Dokument wird eine Erwartung für ein System oder Produkt skizziert.
• Geschäftsanforderungen: In diesem Dokument werden die Gründe für das Schaffen eines Produkts oder Updates beschrieben.
• Anwendungsfälle: Dieses Dokument bietet funktionale Details und Kontext für Funktionen aus einer Benutzerperspektive.
• Benutzergeschichten: Dieses Dokument wird hauptsächlich für die Agile-Entwicklung verwendet. Es kommuniziert die Absicht des Produkts, indem es detailliert erläutert, was der Benutzer damit macht.

Anforderungen können als funktionale und nichtfunktionale Spezifikationen (was und wie) kategorisiert werden.

• Funktionale Anforderungen: Dies beschreibt ein Verhalten, eine Aktivität oder ein erwartetes Ergebnis eines Produkts oder Systems. Zum Beispiel „Partikel aus Wasser filtern“ oder „Seite drucken“. Zu den häufigsten funktionalen Anforderungen gehören Verwaltungsfunktionen, Autorisierung und Authentifizierung, Audit-Tracking und Reporting sowie Geschäftsregeln.
• Nichtfunktionale Anforderung: Dies beschreibt, wie etwas funktioniert. Es kann auch als Einschränkung, Attribut oder Parameter betrachtet werden. Wenn das englische Wort, das den Prozess beschreibt, mit „ity“ endet, ist es nichtfunktional. Beispiele hierfür sind „Usability“, „Maintainability“ und „Security“ sowie Leistungs- und Regulierungsanforderungen.

In SAP ist ein Dokument mit funktionalen Spezifikationen eine Beschreibung des Produkts aus Sicht der Beteiligten, mit genauen Erwartungen, wie sich die Funktion auf SAP bezieht. Sie erstellen funktionale Spezifikationen, nachdem Sie das FSD und das Dokument für Softwareanforderungen zu einem Dokument kombiniert haben.

FSDs sollten mindestens folgende Elemente enthalten:

• Für wen ist das Produkt bestimmt?
• Wer ist berechtigt, das Produkt zu verwenden?
• Eingaben in das System
• Was sollte jeder Bildschirm tun?
• System-Workflows
• Ausgaben
• Regulatorische Anforderungen, die vom Produkt adressiert werden
• Spezifische Geschäftsanforderungen Ihres Unternehmens

Eine schriftliche Beschreibung der gewünschten Funktionen ist ein wesentlicher Bestandteil der Produktentwicklung, aber das Format, das die Vorlage für funktionale Anforderungen hat, sollte auch davon bestimmt sein, was für Ihr Team funktioniert.

Wenn Sie eine Vorlage entwickeln oder sogar Verbesserungen an einem bestehenden Entwicklungsprozess in Betracht ziehen, fragen Sie jeden, der ein Eigeninteresse am Ergebnis des Produkts hat, was in einer Vorlage enthalten sein soll. Jedes Format bietet Vor- und Nachteile:

• „Sollte“-Aussagen in traditionellen funktionalen Anforderungen sind in der Regel nicht kontextabhängig und unterliegen eher der Interpretation von Entwicklern.
• Anwendungsfälle bieten Kontext und Details, aber der Teufel kann genau in diesen Details stecken – es kann zu einem unbemerkten Umfangswachstum kommen, wenn echte Benutzeranforderungen klar werden. Kleinere Anforderungen können bei Anwendungsfällen verloren gehen.
• Benutzergeschichten bieten den Vorteil, Bedürfnisse der Benutzer im Kontext von Geschäftsanforderungen zu beschreiben. Sie können jedoch einen zusätzlichen Aufwand erfordern (d. h. Recherche zu einer angemessenen Umsetzung). Entwickler und andere Personen können sich auch so stark auf einzelne Geschichten konzentrieren, dass sie den größeren Kontext des Produkts nicht berücksichtigen.

Noch einmal: Bei der Überlegung, welches Tool für die Erstellung von Dokumenten für Softwareanforderungen verwendet werden soll, sind die Bedürfnisse Ihres Unternehmens von größter Bedeutung. Was für andere Unternehmen funktioniert, funktioniert möglicherweise für Sie nicht.

• Dokumentationsmanagement: Dies bietet eines der einfachsten und allgegenwärtigsten Tools, um Vorlagen zu erstellen und Dokumente zu rendern. Viele Dokumente mit funktionalen Anforderungen sind als Dokumentvorlagen verfügbar.
• Tabellenblatt-Software: Bei Tabellenblättern können Sie nach Bedarf Spalten hinzufügen. So besteht auch keine Notwendigkeit, perfekte Sätze zu formulieren, da Sie nur die wesentlichen Details erfassen müssen, die ein Leser benötigt, um das richtige Produkt zu erstellen.
• Agile Project Management-Plattform: Viele speziell entwickelten Plattformen bieten Funktionen für die Erfassung von Details zu Anforderungen und Benutzergeschichten und die Entwicklung von Funktions-Tracking.

Einige Anforderungen sind zwar grundlegend und unerlässlich, um die Absicht Ihres Produkts zu vermitteln, andere können für die Entwicklung Ihres Produkts wertvoll sein oder auch nicht. Das von Ihnen gewählte Format kann auch auf dem basieren, was Sie entwickeln. Hier ist eine Liste, die Sie als Leitfaden für die Erstellung funktionaler Anforderungen verwenden können:

• Frontbereich

  • Metadaten-Seite: Auf dieser wird alles über das Dokument zusammengefasst.
  • Anweisungen für Autoren: Hier werden die spezifischen Informationen erklärt, die Ihr Unternehmen in einem Spezifikationsdokument benötigt. Diese Anweisungen können in der Einführung oder in der gesamten Vorlage erscheinen.
  • Versionsnummer
  • Seite zu Änderung der Aufzeichnung/Revisionen: In der Vorlage und dem veröffentlichten Anforderungsdokument sollten alle Änderungen, Details, Datumsangaben und Genehmiger-Initialen enthalten sein.
  • Genehmigungsblock: Dies bedeutet, dass Sie jeder Revision abzeichnen und jede Anforderung mit einer Unterschrift genehmigen.
  • Verteilerliste: Bestimmte Teammitglieder müssen das Dokument möglicherweise überprüfen. Alternativ kann die Erlaubnis zur Anzeige nur auf wenige Teammitglieder beschränkt sein.

• Überblick

  • Produktbeschreibung
  • Übersicht über Geschäftsanforderungen
  • Umfang der Arbeiten (was wird abgedeckt und was nicht)
  • Beschreibung des aktuellen Systems
  • Dokumentkonventionen
  • Terminologie (einschließlich Akronyme)
  • Verweise
  • Allgemeine Einschränkungen und Annahmen
     

• Funktionalität

  • Geschäftsprozess
  • Vorgeschlagene Methoden
  • Benutzerrollen/Benutzer-Community
  • Anwenderfälle
  • Benutzergeschichten
  • Workflows innerhalb des Systems
  • Design-Prototypen
  • Wireframes oder Storyboards
  • Funktionslisten oder Funktionsbeschreibungen
  • Datenanforderungen
  • Administratorfunktion
  • Konfigurationsmanagement
  • Plattform
  • Installation
  • Portabilität
  • Erweiterbarkeit
  • Konfiguration
  • Drucken
  • Fehlerbehandlung
  • Support und Wartung
  • Internationalisierung
  • Hilfe und Dokumentation
     

• Andere Software

  • Eingaben, Ausgaben und Verarbeitung
  • Externe Schnittstellen
  • Benutzeroberflächen
  • Hardware-Schnittstellen
  • Software-Schnittstellen
  • Kommunikationsschnittstellen
  • Datenbank-Unterstützung
     

• Attribute

  • Sicherheit
  • Zuverlässigkeit, Verfügbarkeit, Wartbarkeit, Benutzerfreundlichkeit, Kompatibilität
  • Regulatorische Anforderungen
     

• Anhang

  • Analysemodelle

Befähigen Sie Ihr Team, über sich selbst hinauszuwachsen – mit einer flexiblen Plattform, die auf seine Bedürfnisse zugeschnitten ist und sich anpasst, wenn sich die Bedürfnisse ändern. Mit der Plattform von Smartsheet ist es einfach, Arbeiten von überall zu planen, zu erfassen, zu verwalten und darüber zu berichten. So helfen Sie Ihrem Team, effektiver zu sein und mehr zu schaffen. Sie können über die Schlüsselmetriken Bericht erstatten und erhalten Echtzeit-Einblicke in laufende Arbeiten durch Rollup-Berichte, Dashboards und automatisierte Workflows, mit denen Ihr Team stets miteinander verbunden und informiert ist. Es ist erstaunlich, wie viel mehr Teams in der gleichen Zeit erledigen können, wenn sie ein klares Bild von der geleisteten Arbeit haben. Testen Sie Smartsheet gleich heute kostenlos.