Funktionale und nicht-funktionale Anforderungen: Was sind sie und wie erstellt man sie?

Der Weg von einer Geschäftsanforderung zu funktionstüchtiger Software ist eine tückische Reise

Dieser Weg ist voller Schlaglöcher, gefährlicher Kurven und Sackgassen. Die Anzahl der Entscheidungen, die getroffen werden müssen, ist überwältigend, und jede falsche Entscheidung kann das gesamte Softwareentwicklungsprojekt zum Scheitern bringen. Die richtigen Softwareanforderungen können über Erfolg oder Misserfolg eines Projekts entscheiden.

User Stories sind eine beliebte und weit verbreitete Methode zur Definition von Anforderungen für Softwareprojekte. Im Vergleich zu herkömmlichen Anforderungen verbessern sie die Kommunikation zwischen denjenigen, die die Software benötigen, und denjenigen, die sie liefern können, erheblich, was zu besseren digitalen Lösungen führt.

User Stories sind nicht genug für eine erfolgreiche Umsetzung

Für Requirements Engineers, Product Owners und Business-Analysten sind User Stories ein nützliches Tool zur Kommunikation mit Stakeholdern. Die User Story allein reicht jedoch nicht aus, um mit dem Codieren zu beginnen. Entwickler benötigen funktionale und nicht-funktionale Anforderungen.

In diesem Beitrag geht es darum, eine User Story zu analysieren und sie in etwas umzuwandeln, das Softwareentwickler liefern können. Es wird davon ausgegangen, dass Sie mit dem User Story-Paradigma vertraut sind oder meinen früheren Beitrag User Story Best Practices: Ein Leitfaden für agile Anforderungen gelesen haben.

Funktionale vs. nicht-funktionale Anforderungen: Was ist der Unterschied?

User Stories sind kurze Aussagen, die eine Funktion aus der Sicht der Person beschreiben, die die Funktion haben möchte. Sie hilft Ihnen, das WER, WAS und WARUM einer Funktionsanforderung in Worte zu fassen. Für Entwickler ist das erst der Anfang einer Diskussion. Um funktionierende Software zu liefern, benötigen sie viel mehr Details.

Insbesondere müssen die Entwickler folgendes verstehen:

• was die Software TUN soll (Funktionale Anforderungen) und
• wie GUT sie es tun sollte (nichtfunktionale Anforderungen)

Das ist der Hauptgrund, warum das Entwicklungsteam und die Geschäftsbereiche zusammenarbeiten müssen, um Akzeptanzkriterien für die User Story zu erstellen.

Dieser Beitrag zeigt Ihnen eine Methode, um eine User Story effektiv in ihre funktionalen und nicht funktionalen Elemente zu zerlegen. Diese Technik wird funktionale Dekomposition (auch bekannt als funktionale Aufschlüsselung) genannt und wird verwendet, um das Anforderungsniveau zu erreichen, das das International Institute of Business Analysis™ (IIBA®) als Lösungsanforderungen bezeichnet.

Funktionale und nicht-funktionale Anforderungen sind der Dreh- und Angelpunkt der Softwareentwicklung. Doch bevor wir uns damit beschäftigen, wie man FRs und NFRs erstellt, möchte ich sie zunächst einmal definieren.

Was sind funktionale Anforderungen?

Funktionale Anforderungen (FRs) sind das Rückgrat der meisten Softwareentwicklungsprojekte. Sie sind das, was Ihr Produkt für Benutzer tun wird und was die Leute dazu bringt, es zu verwenden.

FRs sind das detaillierte „Was“ einer Lösung. Sie umfassen die Funktionen und die damit verbundenen Daten, die eine Lösung, ein Feature oder ein Produkt bereitstellen wird. Die Begriffe „Funktionale Anforderungen“ und „Funktionale Spezifikationen“ werden oft synonym verwendet.

Mit anderen Worten, sie sind die detaillierte Beschreibung dessen, was eine Lösung (oder ein Feature/Produkt) tun wird. Anstatt sich darauf zu konzentrieren, wie oder warum etwas funktioniert, beschreiben sie, was die Endbenutzer erleben, wenn sie mit dem System interagieren.

Betrachten Sie sie als eine Art Bauplan; sie enthalten alle Details, die Sie für den Bau Ihres neuen Hauses benötigen – sie sagen Ihnen, wie viele Zimmer es geben wird, wie groß sie sein werden, wie viele Fenster es pro Zimmer geben wird usw. – so dass Sie sich während des Baus keine Gedanken über diese Dinge machen müssen.

Funktionale Anforderungen stellen sicher, dass sich alle Entscheidungen, die während der Softwareentwicklung getroffen werden, auf die Lösung des vorliegenden Problems konzentrieren, und zwar in einer Weise, die den Anforderungen Ihrer Geschäftsinteressenten und Benutzer entspricht.

In einer Lean/Agile- Umgebung werden funktionale Anforderungen in den Akzeptanzkriterien einer User Story erfasst. Das Team konkretisiert eine User Story während der Ausarbeitung und definiert die funktionalen Details als User Story Acceptance Criteria.

In einer klassischen Softwareentwicklungsumgebung (Waterfall, etc.) werden die funktionalen Anforderungen in der Regel in Software Requirement Specifications (SRS-Dokument) zusammengefasst. Auch der Begriff Funktionsspezifikationen  oder Functional Specification Document ist mir bei verschiedenen Projekten begegnet.

Was sind nichtfunktionale Anforderungen (NFR)?

NFRs beschreiben die Aspekte eines Produkts, die über die Kernfunktionalität hinausgehen. Sie sind letztlich das, was Ihr Produkt einzigartig macht und Ihre Stakeholder (insbesondere die Nutzer) zu begeistern vermag.

Die am häufigsten vorkommenden NFRs sind Qualitätsanforderungen (Merkmale) und Einschränkungen (Constraints).

• Eine Qualitätsanforderung ist etwas, das die Kundenzufriedenheit erhöhen würde, z.B., „Arzneimittelrezepte müssen innerhalb von 30 Minuten abgewickelt werden“.
• Eine Einschränkung ist eher eine gesetzliche Anforderung oder ein Naturgesetz: „Arzneimittelrezepte für kontrollierte Substanzen müssen täglich dem National Institute for Health gemeldet werden“.

Der Unterschied zwischen einer Qualitätsanforderung und einer Einschränkung besteht in der Reaktion der Anwender wenn das System eine der Anforderungen nicht beachtet.

• Wenn eine Qualitätsanforderung nicht erfüllt wird, ist der Stakeholder wahrscheinlich mit der Lösung unzufrieden.
• Wenn eine Einschränkung verletzt wird (dh Regeln, Gesetze, Vorschriften, Umgebungsfaktoren usw.), kann die Lösung nicht implementiert werden.

Aufgrund dieser Unterscheidung sollten Sie sich darauf konzentrieren, so viele Einschränkungen wie möglich so früh wie möglich zu entdecken, um kostspielige Korrekturen oder Fehler zu vermeiden.

Was ist funktionale Dekomposition oder Funktions-Zerlegung?

Die funktionale Dekomposition ist eine nützliche Technik, um User Stories in funktionale und nicht-funktionale Anforderungen (NFR) zu unterteilen. Das Entwicklungsteam nutzt sie, um Epics und große User Stories in kleinere aufzuteilen, die in eine Iteration passen, aber auch, um Details in Vorbereitung auf die Codierung herauszuarbeiten.

In der agilen Methode ist dieser Prozess wichtiger denn je, da er es ermöglicht, funktionierende Software in Inkrementen oder Sprints zu erstellen. Mit dem Ende jedes Inkrements stehen den Benutzern neue Funktionen zur Verfügung. Auf diese Weise können Sie Ihr Produkt auf eine Weise testen, die vorher nicht möglich war: mit tatsächlichen Nutzern, die es verwenden und Feedback geben.

Bei der funktionalen Zerlegung wird eine User Story so lange verfeinert, bis klar ist, wie alle Teile zusammenarbeiten werden. Einfach ausgedrückt: Die Funktionsanalyse unterteilt eine komplexe Aufgabe in eine Reihe von einfacheren Aufgaben.

Wie schreibt man funktionale Anforderungen?

Funktionen sind das Herzstück jeder digitalen Lösung. Der Wert einer Softwareanwendung ergibt sich aus ihrer Funktionalität. Jedes Softwareprogramm hat mindestens eine Funktion, und das ist der Grund, warum es existiert.

Zum Beispiel,

• Mit der Funktion „Bestellung prüfen“ können Sie überprüfen, ob die in Ihr Bestellsystem eingegebenen Daten korrekt sind.
• Die Funktion „Umsatzsteuer berechnen“ fügt die Umsatzsteuer zu den Gesamtkosten der Bestellung hinzu.
• . . . usw.

Bei der Benennung von Funktionen sollten Sie Verben und direkte Objekte verwenden. Auf diese Weise drückt der Name genau aus, was die Funktion tut. „E-Mail-Adresse eingeben“, „Kunde aktualisieren“ und „Rechnung drucken“ sind alles Beispiele für Funktionen mit eindeutigen Namen.

Funktionale Dekomposition hilft beim Schreiben von Akzeptanzkriterien oder zur Aufteilung von User Stories

Die funktionale Zerlegung ist ein Zwei-für-Eins-Deal:

• Sie können User Stories in überschaubare Häppchen zerlegen.
• Sie können Akzeptanzkriterien so definieren, dass sie sowohl für die Business Stakeholder als auch für die technischen Teams sinnvoll sind.

Funktionen sind wie die sprichwörtliche russische Puppe – aber mit einem Twist.

• Wenn Sie in eine russische Puppe hineinschauen, finden Sie eine weitere, kleinere Puppe. In dieser befindet sich eine weitere, und noch eine usw.
• Wenn Sie in eine Funktion schauen, finden Sie möglicherweise mehrere Funktionen oder sogar User Storys!

Wenn eine User Story zu komplex oder zu umfangreich ist, um in einer Iteration abgeschlossen zu werden, wird sie in kleinere Stories aufgeteilt. Diese werden „Mini-Stories“ oder „Sub-Stories“ genannt. Sie können in weitere Sub-Stories zerlegt werden wenn sie immer noch zu groß sind.

Wenn alle identifizierten Funktionen in einer Iteration ausgeführt werden können, werden sie in Akzeptanzkriterien für die User Story umgewandelt.

Die funktionale Zerlegung kann als ein Prozess beschrieben werden, bei dem eine User Story oder Anforderung in ihre Bestandteile zerlegt wird, um herauszufinden, was zu tun ist, um sie umzusetzen. Das Ergebnis ist eine Liste kleinerer Benutzergeschichten oder Funktionen, die leichter zu verstehen sind als die ursprüngliche Riesenaufgabe.

User Stories zerlegen: Beispiele für funktionale Anforderungen

Bei der Aufschlüsselung einer User Story können die Funktionen, die die Story enthält, explizit angegeben sein, oder sie müssen abgeleitet werden.

Zum Beispiel:

Als Kunde kann ich nur Artikel auswählen, die auf Lager sind, um Fehler bei der Auftragseingabe zu reduzieren.

In dieser Story habe ich die folgenden abgeleiteten und explizit angegebenen Funktionen gefunden:

• Artikel auswählen (explizit angegeben)
• Artikelbestand prüfen (abgeleitet)
• Bestellten Artikel reservieren (abgeleitet)
• Fehler bei der Auftragserfassung verfolgen (abgeleitet)
• . . .

Es liegt in der Verantwortung des Teams, den Umfang jeder Funktion zu bewerten. Wenn sie nicht innerhalb eines Zyklus kodiert werden kann, wird diese Funktion in Sub-Stories gesplittet, die die obligatorischen WHO-, WHAT- und WHY-Fragen beantwortet. Andernfalls habe ich gerade high-level Akzeptanzkriterien für diese User Story definiert.

Ein Beispiel für eine funktionale Dekomposition, die nicht zu Akzeptanzkriterien, sondern zu gesplitteten User Stories führt, wäre folgendes:

Als Autobesitzer kann ich online eine Kfz-Versicherung beantragen, um den staatlichen Gesetzen zu entsprechen.

Für den Online-Verkauf von Kfz-Versicherungen könnten Sie die folgenden Funktionen in Betracht ziehen:

• Deckungsart auswählen (User Story)
• Personen- und Fahrzeugdaten eingeben (User Story)
• Antrag online übermitteln (User Story)

In diesem Fall sind alle Funktionen zu komplex, um als brauchbare Akzeptanzkriterien zu dienen. Schreiben Sie diese als User Stories und lassen Sie sie den gleichen Prozess noch einmal durchlaufen. Denken Sie daran, dass Akzeptanzkriterien prüfbar sind, sie sollten also einfach genug sein, um getestet zu werden.

Vervollständigen Sie funktionale Anforderungen durch Benutzeransichten und Datenelemente

Zu den funktionalen Anforderungen gehört auch eine datenbezogene Dimension. Alle Funktionen verwenden, erstellen, ändern, löschen oder präsentieren Daten.

Tatsächlich kann der Begriff „Daten“ irreführend sein. Sie müssen sich mit allen „Informationskomponenten“ befassen, um einen vollständigen Satz funktionaler Anforderungen für eine User Story zu entwickeln.

Informationskomponenten können entweder Benutzeransichten (z. B. Berichte, Bildschirme, Fenster, Webseiten, Audiodateien, Videodateien, Textdateien, Datenbanken) oder einzelne Datenelemente (z. B. Straße, Hausnummer, Stadt, Bundesland, Postleitzahl usw.) sein.

Was ist der Unterschied zwischen einer Benutzeransicht (User View) und einem Datenelement?

Eine Benutzeransicht ist einfach eine Sammlung von Datenelementen.
Datenelemente sind „atomare Daten“, also Daten in ihrer einfachsten Form.

Beispielsweise besteht eine Benutzeransicht von „Kundenadresse“ in den Vereinigten Staaten normalerweise aus einem Kundennamen, einer Straße, einer Stadt, einem Bundesland und einem Zip-Code. Letztere sind Datenelemente, während die Kundenadresse eine Benutzeransicht ist, die es jedem ermöglicht, den Kunden geografisch zu lokalisieren. Die Kundenadresse liefert den Wert, den der Benutzer braucht.

Jemand im Team muss die Daten einer Funktion identifizieren und definieren. Dies wird normalerweise in einem User Story-Gespräch erreicht, an dem Mitglieder des Business-Teams und des technischen Teams teilnehmen.

Sobald Sie die Funktionen und die zugehörigen Daten einer User Story kennen, können Sie mit Gherkin-Szenarien schnell und einfach Akzeptanzkriterien und Abnahmetests erstellen die beweisen, ob die User Story wie vorgesehen funktioniert.

Warum brauchen Entwickler nichtfunktionale Anforderungen (NFRs)?

Fehlende und missverstandene nichtfunktionale Anforderungen sind oft die Ursache für das Scheitern von Produkten und Projekten. Die Annalen von IT-Projekten sind voll von Beispielen, bei denen Anwendungen jede einzelne funktionale Anforderung implementierten – aber sie erfüllten die nicht-funktionalen Geschäftsanforderungen nicht einmal annähernd gut genug, um die Wünsche der Kunden zu erfüllen.

Jeder, der die Einführung der Obamacare-Website in den USA miterlebt hat, kann sich mit dieser Realität identifizieren. Die Website stürzte ständig ab, und wenn sie verfügbar war, wurden Wartezeiten oft in Stunden gemessen.

Ein unabhängiges Prüfteam stellte fest, dass das Problem auf eine schlechte Planung und unzureichende Beachtung des Qualitätsaspekts zurückzuführen war. Das Entwicklungsteam hatte es versäumt, den Umfang des Verkehrsaufkommens nach Inbetriebnahme des Produkts richtig einzuschätzen.

Das ist ein Beispiel dafür, was passiert, wenn der Qualitätsdimension zu wenig Beachtung geschenkt wird. Die Obamacare-Website konnte Anträge sofort nach Eingang bearbeiten; es dauerte einfach viel zu lange, bis die Anträge vorlagen.

Beispiele für nicht-funktionale Anforderungen:

Um Ihnen eine Vorstellung davon zu geben, wie man NFRs schreibt, sind hier ein paar Beispiele.

Der Radioaktivitätsmonitor des Kernkraftwerks muss 24/7/365 verfügbar sein.

Dies impliziert, dass die Funktion niemals fehlschlagen darf. Angesichts der schwerwiegenden Folgen eines Scheiterns ist dies wahrscheinlich eine ziemlich vernünftige Anforderung seitens der Geschäftswelt.

Das nächste Beispiel für nicht-funktionale Anforderungen ist technischer Natur, da es auflistet, welche spezifischen Technologien zur Durchsetzung der Zugriffskontrolle verwendet werden sollen.

Der Zugang wird mit Retina-Scanning, Fingerabdruck und Spracherkennung kontrolliert.

NFRs wirken sich jedoch nicht nur auf Funktionen aus. Sie können sich auch auf Daten auswirken, wie Sie in diesem NFR-Beispiel sehen können:

Eine Kunden-ID muss eine eindeutige (d. h. sich nicht wiederholende), 15-stellige (die spezifische Länge), positive (darf nicht kleiner als 0 sein), reelle Zahl haben (Zahl mit beliebigen Ziffern nach dem Komma), die einen einzelnen Kunden identifiziert.

NFRs, die für das gesamte Produkt relevant sind, sollten zu Beginn einer Initiative definiert werden. NFRs, die für eine User Story oder ein Feature einzigartig sind, sollten im Verlauf der Iteration definiert werden.

Bevor ich Ihnen zeige, wie Sie NFRs identifizieren können, möchte ich Ihnen eine kurze Klassifikation geben.

Nicht-funktionale Anforderungen können grob in vier Kategorien eingeteilt werden:

1. Einschränkungen (Constraints)
2. Leistungsanforderungen (Performance Requirements)
3. Anforderungen an die Benutzererfahrung (User Experience Requirements)
4. Architektur-Fähigkeiten (Architectural Capabilities)

Schauen wir uns jede von ihnen genauer an.

Die verschiedenen Arten von nicht-funktionalen Anforderungen erklärt

Einschränkungen oder Constraints
Digitale Lösungen existieren nicht in einem Vakuum. Es gibt viele externe Faktoren, die Ihr Produkt beeinflussen oder einschränken können. Ich nenne sie Constraints. Hier sind einige allgemeine Gruppierungen, über die Sie sich Gedanken machen sollten.

• Von der Natur erzwungene Beschränkungen
• Gesetze und behördliche Anforderungen
• Organisatorische Richtlinien und Regeln
• IT-Sicherheit: Zugriffs- und Datensicherheit
• Geografischer Standort von Funktionen und Daten

Leistungsanforderungen
In der Kategorie „Leistung“ sind der Geschwindigkeit und Effizienz von Anwendungen und Unternehmenslösungen Grenzen gesetzt. Das Hauptproblem bei der Leistung ist nicht, dass sie schwer zu erreichen ist, sondern dass sie teuer ist. Moderne Anwendungen können erstaunliche Leistungsniveaus erreichen, wenn sie notwendig sind und das Unternehmen bereit ist, dafür zu zahlen.

• Frequenz: Wie oft wird eine Funktion verwendet?
• Aktualitätsgrad: Reaktionszeit vs. Aktualisierungszeit
• Datenvolumen an Informationen
• Präzision und Aktualität der Informationen

Anforderungen an die Benutzererfahrung
Die Benutzererfahrung oder User Experience ist eine nicht funktionale Dimension, die mit dem Aufkommen des Internets immer wichtiger wird. Hier trifft Technologie auf Menschen und kann, wie jeder Berührungspunkt zwischen Gegensätzen, schwierig sein.

Viele Ihrer nicht-funktionalen Anforderungen werden aus dieser Kategorie stammen. Vielleicht entdecken Sie Anforderungen an die Benutzererfahrung, die mit den Kompetenzen Ihrer Benutzer, ihrer Umgebung (wo werden sie die Anwendung nutzen), ihrem Schulungsbedarf oder vielleicht ihren kulturellen Bedürfnissen und Wünschen zusammenhängen.

• Intensität der Interaktion
• Unternehmens- und Personenkulturen

Architektur und Fähigkeiten
Wenn die Anwendung beispielsweise webbasiert wäre, müsste sie dann auf jedem Gerät funktionieren, das ein Nutzer verwenden könnte, z. B. auf einem Smartphone, Tablet, PC, Laptop usw.? Auch hier ist die Antwort einfach eine Frage des Geldes, denn je mehr Geräte Ihre Anwendung unterstützen muss, desto mehr wird sie kosten.

Nichtfunktionale Anforderungen, die die erforderlichen Architekturkapazitäten definieren, befassen sich mit der Reaktionsfähigkeit der Anwendung auf Veränderungen in ihrem geschäftlichen und technologischen Umfeld. Dazu gehören Änderungen der Hardwarekapazitäten, der Software, des Marktumfelds oder eine Kombination dieser Faktoren.

• Die Maintainability legt fest, wie schnell Ihre Funktion oder Anwendung auf Veränderungen im Geschäftsumfeld reagieren sollte.
• Bei der Portabilität geht es darum, wie schnell Sie die Anwendung von einer Hardwareplattform oder einem Software-Framework auf eine andere migrieren können.
• Die Skalierbarkeit definiert, wie einfach es für die Anwendung sein muss, mit dem Wachstum im Laufe der Zeit fertig zu werden.
• Bei der Verfügbarkeit geht es darum, wann die Anwendung für ihre Benutzer zugänglich ist.
• Die Ausfallsicherheit gibt an, wie zuverlässig die Anwendung im Vergleich zu den potenziellen Kosten eines Ausfalls sein muss.

Die Definition und Umsetzung nicht-funktionaler Anforderungen kann Kopfzerbrechen bereiten. Wenn Sie sie zu eng spezifizieren, könnte die Lösung zu kostspielig sein, um praktikabel zu sein; wenn Sie sie nicht gut genug spezifizieren, erfüllt das System möglicherweise nicht den beabsichtigten Zweck.

Abschließend

User Stories sind ein Werkzeug, das dazu dient, Gespräche zwischen Fachexperten und Entwicklern sowie innerhalb von Softwareentwicklungsteams zu fokussieren und zu steuern. Allerdings bieten User Stories allein nicht immer genügend Informationen für die Entwickler, mit denen sie arbeiten können.

Da es verschiedene Arten von Software gibt und die technischen Aufgaben sehr unterschiedlich sind, ist es wichtig, funktionale und nicht-funktionale Anforderungen hinzuzufügen.

Die von mir angewandte Methode der funktionalen Dekomposition ermöglicht es nicht-technischen Interessengruppen, ein größeres System in kleinere, unabhängige Elemente zu zerlegen. Da diese Elemente leichter zu verstehen sind und folglich die Qualität des gelieferten Produkts verbessern, werden sie mit größerer Wahrscheinlichkeit von den Kunden akzeptiert.

Ich würde mich freuen, wenn Sie Ihre Gedanken, Ideen und Techniken mit mir teilen würden. Gemeinsam können wir mehr über unser Handwerk lernen und das, was wir wissen, an andere weitergeben.