Arten von Anforderungen im Lastenheft
In dieser Lerneinheit verstehst du die verschiedenen Arten von Anforderungen, die in einem Lastenheft dokumentiert werden müssen - von funktionalen bis hin zu nicht-funktionalen Anforderungen. Du lernst, wie du Kundenanforderungen korrekt kategorisierst und formulierst, sodass keine wichtigen Aspekte übersehen werden. Diese Fähigkeit ist essentiell für deine tägliche Projektarbeit, da präzise definierte Anforderungen die Grundlage für erfolgreiche Softwareentwicklung bilden.
Einführung
Ein Kunde kommt zu dir: “Wir brauchen eine Software für unser Lager.” Du fragst nach Details. Der Kunde antwortet: “Das System soll einfach alles können, was man so braucht.”
Ohne klare Kategorisierung von Anforderungen wird jedes Projekt zum Ratespiel. Was bedeutet “alles”? Welche Funktionen sind kritisch?
Die Lösung: Anforderungen systematisch kategorisieren. Funktionale Anforderungen beschreiben das WAS, nicht-funktionale das WIE, und Constraints setzen den Rahmen.
In dieser Lerneinheit lernst du, die verschiedenen Anforderungsarten zu unterscheiden, sie korrekt zu formulieren und nach Priorität zu ordnen.
Lernziele
Nach dieser Lerneinheit kannst du:
- Funktionale Anforderungen von nicht-funktionalen Anforderungen unterscheiden
- Die verschiedenen Kategorien nicht-funktionaler Anforderungen erkennen
- Constraints (Rahmenbedingungen) identifizieren und dokumentieren
- Anforderungen mit der MoSCoW-Methode priorisieren
- Anforderungen klassifizieren und systematisch strukturieren
Überleitung
Um aus der vagen Anfrage “das System soll alles können” ein präzises Lastenheft zu machen, musst du verstehen, welche Arten von Anforderungen es gibt.
Wir beginnen mit funktionalen Anforderungen – dem Kern jedes Lastenhefts.
Was sind funktionale Anforderungen?
Funktionale Anforderungen beschreiben, was eine Software tun soll. Sie definieren die spezifischen Aufgaben und Funktionen, die das System ausführen muss.
Sie legen fest, wie das System mit seiner Umgebung interagiert: mit Benutzern, externen Systemen und anderen Stakeholdern.
Beispiele:
- Ein Online-Shop soll dem Benutzer erlauben, Produkte in einen Einkaufswagen zu legen
- Ein Bankensystem soll Überweisungen durchführen können
- Ein Buchungssystem soll die Auswahl von Sitzplätzen ermöglichen
Wie formuliert man funktionale Anforderungen?
Gute funktionale Anforderungen haben vier Merkmale:
Spezifisch: Eindeutig und präzise formuliert. Verständlich: Auch für Nicht-Techniker nachvollziehbar. Vollständig: Keine wesentlichen Funktionalitäten fehlen. Überprüfbar: Die Erfüllung muss testbar sein.
Strukturiertes Vorgehen:
- Identifiziere die Akteure (Wer nutzt die Funktion?)
- Definiere die Aktionen (Was soll getan werden? Nutze aktive Verben)
- Berücksichtige Ausnahmen (Was passiert bei Fehler?)
Beispiel: Funktionale Anforderung strukturieren
Schauen wir uns eine vollständig strukturierte Anforderung an — aus dem Lagerverwaltungssystem der vorherigen Lerneinheit:
Titel: Artikel per Barcode-Scanner erfassen
Beschreibung: Ein Lagerarbeiter soll Artikel per Barcode-Scanner erfassen können, um den Bestand in Echtzeit zu aktualisieren.
Akteure: Lagerarbeiter (primär), Lagerleiter (sekundär)
Vorbedingung: Scanner ist eingeschaltet und mit dem System verbunden.
Hauptfluss:
- Lagerarbeiter scannt Artikel-Barcode
- System erfasst Artikelnummer und aktualisiert Bestand
- System zeigt Bestätigung an
Alternative Flüsse: Barcode unleserlich → System zeigt Fehlermeldung, ermöglicht manuelle Eingabe
Nachbedingung: Artikelbestand ist aktualisiert und im System sichtbar
Was sind nicht-funktionale Anforderungen?
Nicht-funktionale Anforderungen (NFRs) beschreiben, wie ein System funktionieren soll. Im Gegensatz zu funktionalen Anforderungen, die das WAS definieren, legen NFRs die Qualitätsattribute fest.
Sie beeinflussen oft die Benutzererfahrung und die Systemleistung stärker als funktionale Anforderungen.
Faustregel: Funktionale Anforderungen sagen was das System tut, nicht-funktionale sagen wie gut es das tut.
Kategorien nicht-funktionaler Anforderungen
NFRs lassen sich in verschiedene Kategorien einteilen:
| Kategorie | Beschreibung | Beispiel |
|---|---|---|
| Performance | Antwortzeiten, Durchsatz | Suchanfrage in < 500ms |
| Zuverlässigkeit | Korrekte Funktion über Zeit | 99,9% Uptime pro Monat |
| Verfügbarkeit | System steht zur Verfügung | 24/7 erreichbar |
| Sicherheit | Schutz vor Zugriff/Diebstahl | OWASP Top 10 konform |
| Wartbarkeit | Einfachheit bei Änderungen | Bugfix in < 4 Stunden |
| Portabilität | Übertragung auf andere Plattform | Läuft auf Windows + macOS |
| Skalierbarkeit | Leistung bei steigender Last | Bis 10.000 Nutzer gleichzeitig |
| Benutzbarkeit | Benutzerfreundlichkeit | Checkout in max. 3 Klicks |
Diese 8 Kategorien decken die wichtigsten Qualitätsaspekte ab. In der Praxis kommen oft mehrere Kategorien gleichzeitig zum Einsatz — ein System benötigt sowohl Performance als auch Sicherheit und Wartbarkeit.
NFRs formulieren: SMART-Prinzip
Die Formulierung von NFRs sollte nach dem SMART-Prinzip erfolgen:
Spezifisch, Messbar, Erreichbar (Achievable), Relevant, Zeitgebunden (Time-bound).
Schlecht formuliert: “Das System soll schnell sein.”
SMART formuliert: “Eine Suchanfrage soll innerhalb von 500 Millisekunden eine Antwort liefern.”
Konkrete Zahlen machen NFRs überprüfbar. Ohne Messwerte sind sie nur Wünsche.
Praxis-Beispiel aus dem Lagerverwaltungssystem: “Das System reduziert die Inventur-Zeit bis zum 31.12.2025 von 3 Tagen auf max. 4 Stunden.”
Was sind Constraints (Rahmenbedingungen)?
Constraints sind Einschränkungen oder Vorgaben, die den Rahmen für die Lösung festlegen. Sie haben direkten Einfluss auf die Gestaltung des Systems.
Constraints sind nicht verhandelbar. Im Gegensatz zu funktionalen oder nicht-funktionalen Anforderungen beschreiben sie keine gewünschten Features, sondern feste Grenzen.
Vier Arten von Constraints:
- Technische Constraints: Plattformen, Technologien
- Geschäftliche Constraints: Budget, Zeitrahmen
- Benutzerbezogene Constraints: Barrierefreiheit, Lokalisierung
- Sicherheitsconstraints: Verschlüsselung, Compliance
Beispiele für Constraints
Schauen wir uns die Constraints des Lagerverwaltungssystems an:
Technisch: Das System muss auf Windows 10 lauffähig sein (vorhandene Hardware im Lager).
Geschäftlich: Das Entwicklungsbudget beträgt maximal 50.000 Euro. Die Implementierung muss bis Q4 2025 abgeschlossen sein.
Benutzerbezogen: Die Benutzeroberfläche muss für Lagerarbeiter mit Touchscreen-Handscannern bedienbar sein.
Sicherheit: Alle Bestandsdaten müssen verschlüsselt gespeichert werden. Zugriff nur für autorisierte Mitarbeiter.
Constraints begrenzen den Lösungsraum, sind aber oft nicht verhandelbar (Budget, Plattform, Compliance).
Warum Priorisierung von Anforderungen?
Du hast jetzt funktionale Anforderungen, NFRs und Constraints gesammelt. Aber welche sind am wichtigsten?
Priorisierung hilft dir, die kritischsten Anforderungen zuerst zu behandeln. In der Realität sind Ressourcen (Zeit, Budget, Personal) begrenzt.
Ohne Priorisierung riskierst du, dass unwichtige Features entwickelt werden, während kritische Funktionen fehlen.
Priorisierung schafft Konsens zwischen Entwicklungsteam und Auftraggeber über das, was wirklich zählt.
Die MoSCoW-Methode
Die MoSCoW-Methode ist eine der verbreitetsten Priorisierungstechniken:
| Kategorie | Bedeutung | Beschreibung |
|---|---|---|
| Must have | Muss haben | Kritische Anforderungen, ohne die das Projekt scheitert |
| Should have | Sollte haben | Wichtige Anforderungen, aber nicht kritisch |
| Could have | Könnte haben | Wünschenswerte Features, die die Nutzererfahrung verbessern |
| Won’t have | Wird nicht haben | Anforderungen, die explizit NICHT umgesetzt werden |
Won’t have ist wichtig, um Erwartungen zu managen. Es verhindert Scope Creep.
Praktisches Beispiel: Priorisierung anwenden
Wenden wir MoSCoW auf das Lagerverwaltungssystem an:
Anforderungen sammeln:
- Funktional: Artikel per Barcode-Scanner erfassen
- Funktional: Lagerplätze automatisch zuweisen
- Nicht-funktional: Barcode-Erfassung in unter 1 Sekunde
- Constraint: Budget max. 50.000 Euro, bis Q4 2025
Priorisierung mit MoSCoW:
- Must have: Barcode-Erfassung (Kern-Funktionalität ohne die das System nutzlos ist)
- Must have: Budget- und Zeit-Constraint (nicht verhandelbar)
- Should have: Performance unter 1 Sekunde (wichtig für Akzeptanz, aber nicht kritisch)
- Could have: Automatische Lagerplatzzuweisung (Optimierung, kann später nachgerüstet werden)
Diese Priorisierung fokussiert das Team auf das Minimum Viable Product (MVP) und verhindert Scope Creep.
Weitere Priorisierungsmethoden
Neben MoSCoW gibt es weitere Methoden:
100-Punkte-Methode: Jeder Stakeholder bekommt 100 Punkte, die er auf Anforderungen verteilen kann. Die Anforderungen mit den meisten Punkten erhalten höchste Priorität.
First Things First: Kombiniert Kosten-Nutzen-Analyse mit Abhängigkeiten zwischen Anforderungen. Berücksichtigt technische und geschäftliche Faktoren.
Kano-Modell: Unterscheidet zwischen Basis-Features, Leistungs-Features und Begeisterungs-Features basierend auf Kundenzufriedenheit.
Klassifizierung von Anforderungen
Klassifizierung ordnet Anforderungen nach Typ oder Kategorie. Häufige Kategorien:
Funktionale Anforderungen: Beschreiben spezifische Funktionen des Systems.
Nicht-funktionale Anforderungen: Beschreiben Systemeigenschaften wie Performance, Sicherheit und Usability.
Rahmenbedingungen (Constraints): Stellen Einschränkungen dar wie verwendete Technologien oder rechtliche Vorgaben.
Die Klassifizierung hilft, Anforderungen systematisch zu strukturieren und sicherzustellen, dass alle Aspekte abgedeckt sind.
Zusammenfassung und Ausblick
Zusammenfassung
Du hast in dieser Lerneinheit die drei Hauptkategorien von Anforderungen kennengelernt:
Funktionale Anforderungen beschreiben das WAS: welche Funktionen das System ausführen muss. Sie sind spezifisch, vollständig und überprüfbar.
Nicht-funktionale Anforderungen beschreiben das WIE: Qualitätsattribute wie Performance, Sicherheit und Usability. Sie sollten nach dem SMART-Prinzip formuliert werden.
Constraints (Rahmenbedingungen) setzen feste Grenzen: technische, geschäftliche, benutzerbezogene und Sicherheitsvorgaben. Sie sind nicht verhandelbar.
Priorisierung hilft, die wichtigsten Anforderungen zuerst zu behandeln. Die MoSCoW-Methode teilt Anforderungen in Must have, Should have, Could have und Won’t have.
Klassifizierung ordnet Anforderungen systematisch nach Typ, um sicherzustellen, dass alle Aspekte abgedeckt sind.
Ausblick
In der nächsten Lerneinheit lernst du, wie du die gesammelten Anforderungen aus dem Lastenheft in ein Pflichtenheft überführst und dabei technische Spezifikationen erstellst.