Was ist der Unterschied zwischen funktionalen und nicht-funktionalen Anforderungen?
Funktionale Anforderungen betreffen laut IREB-Lehrplan ein Ergebnis oder Verhalten, das eine Funktion des Systems liefern soll, einschliesslich Anforderungen an Daten und an die Interaktion mit der Umgebung. Qualitätsanforderungen betreffen Qualitätsaspekte, die nicht durch funktionale Anforderungen abgedeckt sind, etwa Leistung, Verfügbarkeit, Sicherheit oder Zuverlässigkeit. Randbedingungen schränken den Lösungsraum über das hinaus ein, was zur Erfüllung der funktionalen und der Qualitätsanforderungen nötig wäre [1].
Der Begriff «nicht-funktionale Anforderungen» ist in der Praxis weit verbreitet und fasst Qualitätsanforderungen und Randbedingungen zusammen. Die Unterscheidung lohnt sich dennoch: Eine Qualitätsanforderung wie eine Antwortzeit kann mit dem Auftraggeber abgewogen werden, etwa gegen Kosten. Eine Randbedingung wie die Pflicht, Personendaten in der Schweiz zu speichern, ist dagegen vorgegeben und nicht verhandelbar.
| Art | Beispiel | Prüfbar durch |
|---|---|---|
| Funktional | Das System muss Zeiteinträge pro Projekt und Monat summieren. | Funktionstest |
| Qualität: Leistung | Die Monatsauswertung muss bei bis zu 10 000 Einträgen in höchstens drei Sekunden angezeigt werden. | Lasttest |
| Qualität: Benutzbarkeit | Neue Mitarbeitende müssen ohne Schulung einen Zeiteintrag in unter einer Minute erfassen können. | Usability-Test mit Personen ohne Vorkenntnis |
| Qualität: Verfügbarkeit | Das System muss werktags zwischen 7 und 19 Uhr verfügbar sein, Ausfälle höchstens vier Stunden pro Monat. | Monitoring |
| Randbedingung: rechtlich | Personendaten werden ausschliesslich in der Schweiz gespeichert. | Architektur- und Vertragsprüfung |
| Randbedingung: technisch | Das System muss mit dem bestehenden Buchhaltungssystem über dessen Schnittstelle Daten austauschen. | Integrationstest |
Warum werden nicht-funktionale Anforderungen oft vernachlässigt?
Der IREB-Lehrplan hält fest, dass Erhebungstechniken alle Arten von Anforderungen erfassen müssen, Qualitätsanforderungen und Randbedingungen in der Praxis aber oft weniger Aufmerksamkeit erhalten [1]. Das hat Gründe: Stakeholder sprechen in Workshops über Funktionen, die sie sehen und nutzen. Dass das System schnell, sicher und verfügbar sein soll, setzen sie voraus, ohne es zu sagen. Diese Erwartungen entsprechen den Basisfaktoren im Kano-Modell, siehe Anforderungen erheben.
Die Folgen zeigen sich spät und teuer. Ein System, das alle Funktionen erfüllt, aber bei vielen gleichzeitigen Nutzenden zusammenbricht, wird nicht abgenommen. Eine Lösung, die gegen Datenschutzvorgaben verstösst, darf nicht betrieben werden. Viele Qualitätsanforderungen beeinflussen zudem die Architektur grundlegend und lassen sich später kaum nachrüsten.
Welche Qualitätsmerkmale gibt es?
Für die Erhebung von Qualitätsanforderungen empfiehlt der IREB-Lehrplan, ein Qualitätsmodell wie ISO/IEC 25010 als Checkliste zu verwenden; es hilft auch, Anforderungen zu quantifizieren [1]. Die vom Lehrplan referenzierte Ausgabe von 2011 nennt acht Merkmale der Produktqualität, die jeweils weiter unterteilt sind.
| Merkmal | Leitfrage für die Erhebung |
|---|---|
| Funktionale Eignung | Sind die Funktionen vollständig, korrekt und angemessen? |
| Leistungseffizienz | Welche Antwortzeiten, Durchsätze und Ressourcen sind gefordert? |
| Kompatibilität | Mit welchen Systemen muss das System zusammenarbeiten? |
| Benutzbarkeit | Wer nutzt das System, mit welchem Vorwissen, welche Barrierefreiheit ist gefordert? |
| Zuverlässigkeit | Welche Verfügbarkeit, Fehlertoleranz und Wiederherstellbarkeit sind nötig? |
| Sicherheit | Welche Vertraulichkeit, Integrität, Nachweisbarkeit und Authentizität sind gefordert? |
| Wartbarkeit | Wie leicht muss das System änderbar, testbar und analysierbar sein? |
| Übertragbarkeit | Auf welchen Plattformen und in welchen Umgebungen muss es laufen? |
Die Merkmale eignen sich als Struktur für einen Workshop: Für jedes Merkmal wird geprüft, ob es für das Vorhaben relevant ist, und wenn ja, werden konkrete Anforderungen formuliert. So werden Lücken sichtbar, die in rein funktionalen Gesprächen unentdeckt bleiben. Nicht jedes Merkmal ist für jedes System gleich wichtig; die Wertorientierung des IREB-Lehrplans gilt auch hier.
Wie werden Qualitätsanforderungen messbar?
Eine Qualitätsanforderung wie «Das System soll schnell sein» ist nicht prüfbar und damit für eine Abnahme wertlos. Messbar wird sie, wenn Messgrösse, Messmethode und Zielwert festgelegt sind, oft ergänzt um einen Mindestwert und die Bedingungen, unter denen gemessen wird. Der Lehrplan nennt Formularschablonen für messbare Qualitätsanforderungen als eine Form schablonenbasierter Arbeitsprodukte [1].
| Feld | Inhalt |
|---|---|
| Kennung und Name | QA-07 Antwortzeit Monatsauswertung |
| Merkmal | Leistungseffizienz, Zeitverhalten |
| Messgrösse | Zeit von der Anforderung bis zur vollständigen Anzeige der Auswertung |
| Messmethode | automatisierter Lasttest mit 50 gleichzeitigen Nutzenden und 10 000 Einträgen |
| Zielwert | höchstens drei Sekunden bei 95 von 100 Anfragen |
| Mindestwert | höchstens fünf Sekunden bei 95 von 100 Anfragen |
| Begründung | Projektleitende rufen die Auswertung in Kundengesprächen auf |
| Quelle | Workshop mit Projektleitenden, Protokoll vom Projektstart |
Die Unterscheidung von Ziel- und Mindestwert schafft Spielraum für Abwägungen: Der Mindestwert ist Abnahmekriterium, der Zielwert die Ambition. Die Begründung hilft, später zu entscheiden, ob eine Anforderung angepasst werden kann, wenn sie zu teuer wird. Wie Anforderungen gegeneinander abgewogen werden, beschreibt der Beitrag Anforderungen priorisieren.
Welche Arten von Randbedingungen gibt es?
Randbedingungen findet man laut Lehrplan, indem man mögliche Einschränkungen des Lösungsraums betrachtet, etwa technische, rechtliche, organisatorische, kulturelle oder umweltbezogene [1]. Sie stammen oft nicht von Endnutzenden, sondern aus Dokumenten und von Stakeholdern wie Rechtsabteilung, Informatikbetrieb oder Beschaffung.
| Art | Beispiele | Typische Quelle |
|---|---|---|
| Technisch | vorgeschriebene Plattform, bestehende Schnittstellen, Betriebsumgebung | Informatikbetrieb, Architektur |
| Rechtlich | Datenschutzgesetz, Aufbewahrungspflichten, Barrierefreiheit, Vergaberecht | Rechtsdienst, Datenschutz, Gesetze |
| Organisatorisch | Budget, Termine, vorhandene Rollen, Prozesse | Auftraggeber, Projektauftrag |
| Kulturell | Sprachen, Begriffe, Gepflogenheiten der Nutzenden | Nutzende, Fachbereiche |
| Umweltbezogen | Energieverbrauch, Einsatzort, physische Bedingungen | Nachhaltigkeitsvorgaben, Betrieb |
Nicht-funktionale Anforderungen in agilen Teams
In agilen Teams passen Qualitätsanforderungen oft nicht in einzelne User Stories, weil sie für viele Einträge gleichzeitig gelten. Bewährt haben sich drei Wege: als Teil der Definition of Done, wenn sie für alle Einträge gelten, etwa Barrierefreiheit; als Akzeptanzkriterien einzelner Stories, wenn sie nur dort relevant sind; oder als eigene Backlog-Einträge, wenn sie eigenständige Arbeit verlangen, etwa ein Lasttest. Der Scrum Guide beschreibt die Definition of Done als formale Beschreibung des Zustands des Increments, wenn es die geforderten Qualitätsmassnahmen erfüllt [2].
Typische Fehler bei nicht-funktionalen Anforderungen
- Vage Formulierungen wie «benutzerfreundlich», «schnell» oder «sicher» ohne Messgrösse.
- Qualitätsanforderungen erst bei der Abnahme ansprechen, wenn die Architektur feststeht.
- Randbedingungen nicht erheben, weil sie niemand in Workshops nennt.
- Unrealistische Zielwerte ohne Bezug zu Kosten, etwa ununterbrochene Verfügbarkeit für ein internes Werkzeug.
- Keine Messmethode festlegen und später über die Auslegung streiten.
Nicht-funktionale Anforderungen im Werkzeug führen
Qualitätsanforderungen und Randbedingungen sollten im selben Werkzeug wie funktionale Anforderungen geführt werden, mit eigener Kategorie, Messgrösse und Verknüpfung zu den betroffenen Funktionen und Testfällen. In Flenio lassen sich dafür eigene Aufgabentypen oder Kennzeichnungen verwenden und mit Meilensteinen wie Lasttests oder Abnahmen verbinden. Wie Anforderungen über den Lebenszyklus verwaltet werden, beschreibt der Beitrag Requirements Management. Den Gesamtzusammenhang zeigt der Leitfaden Requirements Engineering.
So führen Sie einen Workshop zu Qualitätsanforderungen durch
- 1Vorbereiten: relevante Stakeholder einladen, etwa Fachbereich, Betrieb, Datenschutz und Sicherheit.
- 2Merkmale durchgehen: für jedes Merkmal von ISO/IEC 25010 prüfen, ob es relevant ist und warum.
- 3Szenarien sammeln: konkrete Situationen beschreiben, etwa «Monatsende mit allen Mitarbeitenden gleichzeitig».
- 4Messbar machen: Messgrösse, Messmethode, Ziel- und Mindestwert festlegen.
- 5Abwägen: Kosten und Nutzen besprechen, Konflikte zwischen Merkmalen klären.
- 6Dokumentieren und validieren: Ergebnisse festhalten und mit Stakeholdern bestätigen.
Szenarien sind dabei besonders hilfreich. Statt abstrakt über Leistung zu sprechen, wird eine konkrete Situation beschrieben: Am letzten Arbeitstag des Monats erfassen 200 Personen zwischen 16 und 18 Uhr ihre Zeiten, während die Buchhaltung Auswertungen abruft. Aus diesem Szenario lassen sich messbare Anforderungen ableiten, die realistisch und prüfbar sind.
Wie gehen Sie mit Zielkonflikten um?
Qualitätsanforderungen stehen oft im Konflikt zueinander. Höhere Sicherheit durch zusätzliche Anmeldeschritte kann die Benutzbarkeit verringern; höhere Verfügbarkeit erhöht die Betriebskosten; strengere Datenschutzvorgaben können die Leistung beeinträchtigen. Solche Konflikte lassen sich nicht vermeiden, sondern müssen bewusst entschieden werden. Hilfreich ist, die Begründung jeder Qualitätsanforderung festzuhalten und Konflikte mit den betroffenen Stakeholdern gemeinsam abzuwägen.
Die Norm ISO/IEC/IEEE 29148 beschreibt, welche Informationen eine Anforderungsspezifikation enthalten soll, einschliesslich der Qualitätsanforderungen und Randbedingungen, und kann als Struktur für entsprechende Kapitel dienen [3]. Entscheidungen zu Zielkonflikten werden in der Spezifikation oder einem Entscheidungsprotokoll festgehalten, damit sie später nachvollziehbar bleiben.
Für Projekte im öffentlichen Bereich lohnt sich zudem ein Blick in die Vorgaben der Auftraggeber: Viele Verwaltungen geben Sicherheits-, Datenschutz- und Barrierefreiheitsanforderungen als Randbedingungen vor, die in die Spezifikation übernommen werden müssen. Wie der Projektumfang insgesamt gesteuert wird, beschreibt der Beitrag Scope-Management und Änderungskontrolle im Hub Projektplanung.
So entsteht eine vollständige Spezifikation, in der funktionale Anforderungen, Qualitätsanforderungen und Randbedingungen gleichberechtigt nebeneinander stehen und gemeinsam validiert werden.
Eine kurze Prüfliste mit den acht Qualitätsmerkmalen und den fünf Arten von Randbedingungen, die bei jedem Anforderungsreview durchgegangen wird, stellt sicher, dass diese Anforderungen nicht nur am Anfang, sondern über das ganze Vorhaben hinweg berücksichtigt werden.