Software-Anforderungen
Die Definition und das Management von Software-Anforderungen (Requirements Engineering) bilden das Fundament jeder Softwareentwicklung. Sie beschreiben Eigenschaften und Leistungen, die ein System erbringen muss, um die Bedürfnisse der Stakeholder zu erfüllen. In der Praxis wird zwischen funktionalen Anforderungen („Was soll das System tun?“) und nicht-funktionalen Anforderungen („Wie soll das System sein?“) unterschieden. Eine präzise Anforderungsanalyse reduziert das Risiko von Fehlentwicklungen und schafft eine verbindliche Kommunikationsbasis zwischen Auftraggebern und Entwicklungsteams.
Funktionale vs. Nicht-funktionale Anforderungen
Anforderungen werden grundlegend in zwei Kategorien unterteilt, die unterschiedliche Aspekte eines Systems beleuchten.
Funktionale Anforderungen
Funktionale Anforderungen legen fest, was das System tun soll. Sie beschreiben konkrete Funktionen, Dienstleistungen und das Verhalten der Software bei bestimmten Eingaben.
- Beispiel: „Das System muss es ermöglichen, Rechnungen als PDF zu exportieren.“
- Fokus: Geschäftsprozesse, Datenverarbeitung, Benutzerschnittstellen.
Nicht-funktionale Anforderungen (NFR)
Nicht-funktionale Anforderungen definieren, wie das System die Funktionen ausführen soll. Sie beschreiben Qualitätsmerkmale und Rahmenbedingungen, die oft systemweit gelten.
- Beispiel: „Der PDF-Export darf maximal zwei Sekunden dauern.“
- Fokus: Performance, Sicherheit, Benutzbarkeit, Zuverlässigkeit.
Für die Konzeption ist es entscheidend, beide Arten frühzeitig zu identifizieren, da NFRs massiven Einfluss auf die Architektur und die Kosten eines Projekts haben.
Softwarequalität nach ISO/IEC 25010
Die internationale Norm ISO/IEC 25010 bietet ein Modell zur Klassifizierung von Softwarequalität. Sie dient als Checkliste, um sicherzustellen, dass wesentliche Qualitätsaspekte systematisch berücksichtigt werden.
Die acht Hauptkategorien sind:
- Funktionale Tauglichkeit: Erfüllt die Software die fachlichen Aufgaben?
- Leistungseffizienz: Wie schnell reagiert das System (Antwortzeiten, Ressourcenverbrauch)?
- Kompatibilität: Wie gut arbeitet die Software mit anderer Software oder Hardware zusammen?
- Benutzbarkeit (Usability): Wie einfach lässt sich die Software erlernen und bedienen?
- Zuverlässigkeit: Wie stabil läuft das System auch unter Belastung oder bei Fehlern?
- Sicherheit: Wie gut sind Daten vor unbefugtem Zugriff geschützt (Datenschutz und Datensicherheit)?
- Wartbarkeit: Wie leicht lässt sich die Software ändern oder erweitern (Analysierbarkeit, Modifizierbarkeit)?
- Übertragbarkeit (Portabilität): Wie einfach kann die Software in eine andere Umgebung verschoben werden?
Dokumentation: Lastenheft und Pflichtenheft
In der klassischen Softwareentwicklung wird die Dokumentation in zwei zentralen Dokumenten festgehalten:
- Lastenheft: Wird vom Auftraggeber erstellt. Es beschreibt die Gesamtheit der Forderungen an die Lieferungen und Leistungen eines Auftragnehmers.
- Pflichtenheft: Wird vom Auftragnehmer auf Basis des Lastenhefts erstellt. Es beschreibt die technische Umsetzung der Anforderungen.
| Merkmal | Lastenheft | Pflichtenheft |
|---|---|---|
| Ersteller | Auftraggeber (Kunde) | Auftragnehmer (Entwickler) |
| Inhalt | Ziele, Anforderungen, Rahmenbedingungen | Konkrete Umsetzung, Spezifikationen |
| Zeitpunkt | Vor der Ausschreibung / Vergabe | Nach der Auftragsvergabe |
Agiles Requirements Engineering
In agilen Projekten werden Anforderungen kontinuierlich im Projektverlauf verfeinert, statt sie vorab vollständig statisch zu fixieren.
User Stories
Eine häufig genutzte Form sind User Stories. Sie beschreiben eine Anforderung aus der Sicht des Endanwenders:
- „Als [Rolle] möchte ich [Ziel/Wunsch], um [Nutzen].“
- Beispiel: „Als Buchhalter möchte ich alle offenen Posten filtern können, um Mahnungen schneller zu versenden.“
Ergänzt werden User Stories durch Akzeptanzkriterien, die festlegen, wann eine Anforderung als erfolgreich umgesetzt gilt.
Priorisierung mit der MoSCoW-Methode
Da Ressourcen begrenzt sind, müssen Anforderungen priorisiert werden. Die MoSCoW-Methode ist hierfür ein Standardwerkzeug:
- Must have: Anforderungen, die zwingend für den Erfolg notwendig sind.
- Should have: Wichtige Anforderungen, die nicht kritisch für den Start sind.
- Could have: Optionale Wünsche („Nice-to-have“).
- Won't have: Anforderungen, die in diesem Release explizit nicht umgesetzt werden.
Häufige Fehler und Best Practices
- Vage Formulierungen: Begriffe wie „schnell“ oder „benutzerfreundlich“ ohne messbare Kriterien erschweren die Abnahme. Statt „die Suche soll schnell sein“, sollte definiert werden: „Die Suche liefert Ergebnisse in unter 500 ms.“
- Fehlende Stakeholder: Eine unvollständige Stakeholder-Analyse führt dazu, dass Anforderungen von Endanwendern oder dem IT-Betrieb übersehen werden.
- Vernachlässigung von NFRs: Nicht-funktionale Anforderungen werden oft erst spät bemerkt. Sie müssen von Beginn an in die Planung einfließen.