Zum Inhalt

Anforderungsarten

Lernziele

Nach diesem Kapitel können Sie: * Funktionale und nicht-funktionale Anforderungen unterscheiden * Verschiedene Kategorisierungsmethoden anwenden * Beziehungen zwischen Anforderungsarten verstehen * Anforderungen korrekt klassifizieren

1. Einführung: Anforderungsarten verstehen

Kernkonzept

Eine Anforderung ist eine Aussage über ein Attribut, eine Eigenschaft oder eine Eigenschaft, die ein System besitzen muss.

1.1 Warum Anforderungsarten wichtig sind

Nicht jede Anforderung ist gleich. Verschiedene Arten von Anforderungen erfordern unterschiedliche Analyse-Methoden und unterschiedliche Teststrategien.

Anforderungsart Analyse-Methode Test-Strategie
Funktionale Anforderungen Use Cases, User Stories Systemtests, Akzeptanztests
Nicht-funktionale Anforderungen KPIs, Benchmarks Performance-Tests, Load-Tests
Randbedingungen Compliance-Checklists Compliance-Audits
Geschäftsanforderungen Business-Case-Analysis ROI-Analyse

2. Funktionale Anforderungen (Functional Requirements)

2.1 Definition

Funktionale Anforderungen beschreiben, was ein System tun soll.

Kernmerkmal: Es ist immer eine Funktion oder Handlung, die das System ausführen muss.

2.2 Struktur einer funktionalen Anforderung

Eine gute funktionale Anforderung besteht aus:

Element Beschreibung Beispiel
ID Eindeutige Identifikation FR-001
Titel Kurze, prägnante Beschreibung User Registration
Priorität Wichtigkeit (Must, Should, Could, Won't) Must have
Beschreibung Detaillierte Beschreibung der Funktionalität System muss neue Benutzer registrieren können
Akzeptanzkriterien Wann ist die Anforderung erfüllt? • Benutzer gibt E-Mail und Passwort ein
• System validiert E-Mail-Format
• System versendet Bestätigungs-E-Mail
Stakeholder Wer fordert diese Anforderung? Product Owner, Key User
Verknüpfung Mit welcher Geschäftsanforderung verknüpft? BR-001: Kundenakquise steigern

2.3 Beispiele für funktionale Anforderungen

ID Funktionale Anforderung Akzeptanzkriterien
FR-001 User Registration • Benutzer gibt E-Mail und Passwort ein
• System validiert E-Mail-Format
• System versendet Bestätigungs-E-Mail
FR-002 User Login • Benutzer authentifizieren mit E-Mail/Passwort
• Session Management
• Password Reset
FR-003 Password Reset • Benutzer fordert Password Reset an
• System versendet Reset-Link
• Link ist 24 Stunden gültig
FR-004 Order Placement • Kundenbestellungen annehmen
• Warenkorb-Funktionalität
• Versandkostenberechnung
FR-005 Payment Processing • Zahlung mit Kreditkarte, PayPal, Sofortüberweisung
• Payment Gateway-Integration
• Transaktionsstatus anzeigen
FR-006 Order Cancellation • Bestellungen stornieren
• Stornierungs-Regeln (z.B. nicht nach Versand)
• Rückerstattung veranlassen
FR-007 Order Tracking • Kunden können Bestellstatus verfolgen
• Real-Time-Updates
• E-Mail-Benachrichtigungen
FR-008 Customer Support • Support-Ticket erstellen
• Chat-Funktionalität
• Ticket-Workflow
FR-009 Product Search • Volltextsuche
• Filter (Kategorie, Preis, Marke)
• Auto-Vervollständigung
FR-010 Wish List • Kunden können Artikel auf die Wunschliste setzen
• Wunschliste speichern
• Mit anderen teilen

2.4 Kategorisierung funktionaler Anforderungen

Funktionale Anforderungen können weiter unterteilt werden:

Unterkategorie Beschreibung Beispiele
Benutzer-interaktive Funktionen Funktionen, die der Benutzer direkt nutzt Login, Suche, Warenkorb
Daten-Management-Funktionen Funktionen zur Verwaltung von Daten Datenerfassung, Datenänderung, Datenlöschung
Reporting-Funktionen Funktionen zur Berichterstattung Dashboards, Reports, Export
System-integrierte Funktionen Funktionen, die im Hintergrund laufen Batch-Jobs, Daten-Sync, Backup
Admin-Funktionen Funktionen für Administratoren User Management, System-Config
Security-Funktionen Funktionen zur Sicherheit Authentifizierung, Autorisierung, Logging

3. Nicht-funktionale Anforderungen (Non-Functional Requirements)

3.1 Definition

Nicht-funktionale Anforderungen (NFRs) beschreiben, wie gut ein System eine Funktion ausführt.

Kernmerkmal: Es ist ein Qualitätsattribut des Systems.

Fehlerhafte NFR-Formulierungen

  • ❌ "Das System muss schnell sein" (nicht testbar)
  • ✅ "Die Antwortzeit muss < 2 Sekunden sein" (konkret, testbar)

3.2 Kategorien von NFRs (ISO/IEC 25010)

ISO/IEC 25010 definiert 8 Qualitätsmodelle für Software-Produkte:

Qualitätsmodell Unter-Kategorien Beispiele
Performance Response Time, Throughput, Latency "Antwortzeit < 2 Sekunden bei 1000 req/sec"
Reliability Availability, MTBF, Fehlerrate "Verfügbarkeit 99.9%, Fehlerrate < 0.01%"
Usability Learnability, Efficiency, Satisfaction "Neue Benutzer können sich in < 3 Minuten registrieren"
Security Confidentiality, Integrity, Availability "Datenverschlüsselung, MFA, DSGVO"
Maintainability Modularity, Testability, Code Quality "Code-Coverage > 80%, Unit-Tests für alle Funktionen"
Compatibility Browser, OS, Versionen "Chrome 90+, iOS 14+, Android 10+"
Scalability Horizontal Scaling, Vertical Scaling "System skalierbar auf 10x mehr User"
Compliance Regulatorische Anforderungen "DSGVO-konform, ISO 27001-zertifiziert"

3.3 Performance-Anforderungen

ID NFR Beschreibung Akzeptanzkriterien
NFR-P001 Login Response Time Der Login-Prozess muss in < 2 Sekunden abgeschlossen sein • Login erfolgreich in < 2 Sekunden bei 1000 gleichzeitigen Usern
• Password-Reset-E-Mail wird in < 5 Sekunden versendet
NFR-P002 Search Performance Die Produktsuche muss Ergebnisse in < 1 Sekunde zurückgeben • 1000 Produkte in < 1 Sekunde durchsuchbar
• 10.000 Produkte in < 2 Sekunden durchsuchbar
NFR-P003 Checkout Throughput Das System muss 100 gleichzeitige Checkouts verarbeiten • System verarbeitet 100 Transaktionen/Minute
• Fehlerrate < 0.1%

3.4 Availability-Anforderungen

ID NFR Beschreibung Akzeptanzkriterien
NFR-A001 System Availability Das System muss 99.9% verfügbar sein • Geplante Wartungszeitfenster: < 4 Stunden/Monat
• Ungeplante Downtime: < 8 Stunden/Jahr
NFR-A002 Disaster Recovery Im Katastrophenfall muss das System in < 4 Stunden wiederhergestellt sein • RPO (Recovery Point Objective): < 1 Stunde
• RTO (Recovery Time Objective): < 4 Stunden

3.5 Security-Anforderungen

ID NFR Beschreibung Akzeptanzkriterien
NFR-S001 Authentication Benutzer müssen mit MFA authentifiziert werden • MFA für alle administrativen Accounts
• Optional für End-User
NFR-S002 Encryption Alle Daten müssen verschlüsselt gespeichert werden • AES-256 für Ruhedaten
• TLS 1.3 für Übertragung
NFR-S003 Compliance Das System muss DSGVO-konform sein • Consent-Management
• Data Deletion
• Data Portability

3.6 Usability-Anforderungen

ID NFR Beschreibung Akzeptanzkriterien
NFR-U001 Learnability Neue Benutzer müssen ohne Training arbeiten können • Time-to-First-Task: < 5 Minuten
• < 3 Klicks bis zum Ziel
NFR-U002 Accessibility System muss barrierefrei sein • WCAG 2.1 AA konform
• Screenreader-kompatibel

3.7 Maintainability-Anforderungen

ID NFR Beschreibung Akzeptanzkriterien
NFR-M001 Code Quality Code muss gut dokumentiert sein • Code-Coverage > 80%
• Unit-Tests für alle Funktionen
• SonarQube-Qualitäts-Score > B

3.8 Scalability-Anforderungen

ID NFR Beschreibung Akzeptanzkriterien
NFR-SC001 Horizontal Scaling System muss horizontal skalieren können • System kann bei Bedarf weitere Instanzen hinzufügen
• Load Balancer automatisch
NFR-SC002 Vertical Scaling System muss vertikal skalieren können • System nutzt alle CPU-Kerne
• System nutzt bis zu 80% des RAM

3.9 Compatibility-Anforderungen

ID NFR Beschreibung Akzeptanzkriterien
NFR-C001 Browser Support System muss auf gängigen Browsern laufen • Chrome 90+, Firefox 88+, Safari 14+, Edge 90+
NFR-C002 Mobile Support System muss auf mobilen Geräten laufen • iOS 14+, Android 10+
• Responsive Design

4. Randbedingungen (Constraints)

4.1 Definition

Randbedingungen sind Einschränkungen, die das Projekt oder das System betreffen.

Kernmerkmal: Es sind Bedingungen, die erfüllt sein müssen, aber keine Funktionalität beschreiben.

4.2 Typen von Randbedingungen

Typ Beschreibung Beispiele
Technische Randbedingungen Einschränkungen durch Technik Legacy-Systeme, Cloud-Provider, Programmiersprache
Organisatorische Randbedingungen Einschränkungen durch Organisation Budget, Timeline, Team-Größe
Rechtliche Randbedingungen Einschränkungen durch Gesetze DSGVO, Compliance-Vorschriften
Markt-Randbedingungen Einschränkungen durch Markt Wettbewerber, Kundenbedarf
Betriebliche Randbedingungen Einschränkungen durch Betrieb Standort, Support-Zeiten, Sprachen

4.3 Technische Randbedingungen

ID Randbedingung Beschreibung
RC-T001 Cloud Provider System muss auf AWS laufen
RC-T002 Programmiersprache Backend muss in Python entwickelt werden
RC-T003 Legacy-System System muss an bestehendes SAP ERP angebunden werden
RC-T004 Database System muss PostgreSQL als Datenbank nutzen

4.4 Organisatorische Randbedingungen

ID Randbedingung Beschreibung
RC-O001 Budget Projektbudget liegt bei €500.000
RC-O002 Timeline Go-Live bis Ende Q3 2026
RC-O003 Team Size Team besteht aus 5 Entwicklern und 2 Testern
RC-O004 Vendor Lock-in Kein Vendor Lock-in (Open Source bevorzugen)

4.5 Rechtliche Randbedingungen

ID Randbedingung Beschreibung
RC-L001 DSGVO System muss DSGVO-konform sein
RC-L002 ISO 27001 System muss ISO 27001-zertifiziert sein
RC-L003 PCI-DSS System muss PCI-DSS-Level 1 konform sein (für Kreditkarten)
RC-L004 Data Sovereignty Kundendaten müssen in Deutschland gespeichert werden

4.6 Markt-Randbedingungen

ID Randbedingung Beschreibung
RC-M001 Wettbewerber System muss Features haben, die Wettbewerber haben
RC-M002 Pricing System muss konkurrenzfähig preisen
RC-M003 Time-to-Market System muss vor Wettbewerber auf den Markt kommen

4.7 Betriebliche Randbedingungen

ID Randbedingung Beschreibung
RC-B001 Standort System muss in Deutschland gehostet werden
RC-B002 Support Times Support muss 24/7 verfügbar sein
RC-B003 Sprachen System muss Englisch, Deutsch, Französisch unterstützen
RC-B004 Scalability System muss skalierbar für 10.000+ User sein

5. Geschäftsanforderungen (Business Requirements)

5.1 Definition

Geschäftsanforderungen beschreiben, warum das Projekt gemacht wird. Sie sind das Business-Ziel, das erreicht werden soll.

Kernmerkmal: Es ist ein Ziel, das für das Business relevant ist.

5.2 Struktur einer Geschäftsanforderung

Element Beschreibung Beispiel
ID Eindeutige Identifikation BR-001
Titel Kurze Beschreibung des Ziels Umsatzsteigerung
Priorität Wichtigkeit High
Beschreibung Detaillierte Beschreibung des Ziels Umsatz soll um 10% gesteigert werden
KPIs Wie wird der Erfolg gemessen? • Umsatz-Steigerung: 10%
• Conversion-Rate: 1.5% → 3%
Zeitraum Bis wann soll das Ziel erreicht sein? Bis Ende 2026
Stakeholder Wer fordert dieses Ziel? CEO, CRO

5.3 Beispiele für Geschäftsanforderungen

ID Geschäftsanforderung KPIs Zeitraum
BR-001 Umsatzsteigerung • Umsatz-Steigerung: 10%
• Conversion-Rate: 1.5% → 3%
• AOV (Average Order Value): €50 → €75		 Bis Ende 2026
BR-002 Kostensenkung • OPEX-Reduzierung: 20%
• Automatisierungsgrad: 20% → 80%		 Bis Ende Q3 2026
BR-003 Kundenzufriedenheit • NPS (Net Promoter Score): 30 → 50
• Customer Satisfaction: 3.5 → 4.5/5		 Bis Ende 2026
BR-004 Time-to-Market • Time-to-Market: 6 Monate → 3 Monate Bis Mitte 2026
BR-005 Competitive Advantage • Feature-Parity mit Wettbewerber
• USP (Unique Selling Point) definieren		 Bis Ende 2026

6. Beziehungen zwischen Anforderungsarten

6.1 Der Anforderungs-Hierarchie

Anforderungen stehen in einer Hierarchie zueinander:

graph TD
    A[Geschäftsanforderungen<br>Warum?] --> B[Funktionale Anforderungen<br>Was?]
    A --> C[Nicht-funktionale Anforderungen<br>Wie gut?]
    B --> D[Randbedingungen<br>Welche Einschränkungen?]
    C --> D

    A1[BR-001: Umsatz +10%] --> B1[FR-001: Mobile App]
    A1 --> B2[FR-002: Personalisierung]
    A1 --> C1[NFR-P001: Performance < 2s]
    A1 --> C2[NFR-S001: MFA]

    style A fill:#f96,stroke:#333,stroke-width:3px

6.2 Traceability Matrix

Die Traceability Matrix verknüpft Anforderungen über die Hierarchie-Hinweg:

Geschäftsanforderung (BR) Funktionale Anforderung (FR) Nicht-funktionale Anforderung (NFR) Randbedingung (RC)
BR-001: Umsatz +10% FR-001: Mobile App NFR-P001: Performance < 2s RC-M001: Competitive Advantage
FR-002: Personalisierung NFR-U001: Usability RC-L001: DSGVO
FR-003: KI-Scoring NFR-S001: MFA
BR-002: Kostensenkung -20% FR-004: Automatisierung NFR-M001: Maintainability RC-O001: Budget €500k
FR-005: Cloud-Migration NFR-SC001: Scalability RC-T001: AWS

6.3 Konflikte zwischen Anforderungsarten

Anforderungen können im Konflikt stehen. Als Berater müssen Sie diese Konflikte identifizieren und lösen.

Konflikt Beispiel Lösung
Performance vs. Security Encryption reduziert Performance Balancing: AES-256 statt AES-512, Hardware-Acceleration
Cost vs. Quality Kostensenkung vs. High-End Features Priorisierung: MVP zuerst, Premium-Features später
Speed vs. Quality Time-to-Market vs. Code Quality Agile-Methode: Iterative Verbesserung
Flexibility vs. Standardisierung Customization vs. Standard-Prozesse Modularisierung: Core standardisiert, Add-ons flexibel

7. Praxis-Beispiel: Kategorisierung von Anforderungen

Szenario: E-Commerce-Shop

Die ShopNow GmbH plant einen neuen E-Commerce-Shop. Sie kategorisieren die Anforderungen.

7.1 Geschäftsanforderungen

ID Geschäftsanforderung KPIs
BR-001 Umsatzsteigerung +10% Umsatz, CR 1.5% → 3%, AOV €50 → €75
BR-002 Kundenzufriedenheit NPS 30 → 50, CSAT 3.5 → 4.5/5

7.2 Funktionale Anforderungen

ID Funktionale Anforderung Verknüpfung zu BR
FR-001 Mobile App BR-001 (Mobile Commerce)
FR-002 Personalisierung BR-001 (Upselling)
FR-003 KI-gestütztes Lead-Scoring BR-001 (Conversion)
FR-004 Omnichannel-Integration BR-001 (Kundenbindung)
FR-005 Loyalty-Programm BR-002 (Kundenbindung)

7.3 Nicht-funktionale Anforderungen

ID NFR Beschreibung Verknüpfung zu FR
NFR-P001 Performance Response Time < 2s FR-001 (Mobile App)
NFR-S001 Security MFA, Encryption Alle FRs
NFR-U001 Usability < 3 Klicks bis zum Ziel FR-001, FR-002
NFR-SC001 Scalability 10x mehr User FR-001, FR-004

7.4 Randbedingungen

ID Randbedingung Beschreibung
RC-T001 Cloud Provider AWS
RC-O001 Budget €1.000.000
RC-L001 DSGVO DSGVO-konform
RC-M001 Competitive Advantage Feature-Parity mit Wettbewerber

7.5 Traceability Matrix

BR FR NFR RC
BR-001 FR-001, FR-002, FR-003, FR-004 NFR-P001, NFR-S001, NFR-U001, NFR-SC001 RC-M001
BR-002 FR-005 NFR-S001, NFR-U001 RC-L001

8. Zusammenfassung und Checkliste

8.1 Erfolgsfaktoren

  • Konsistente Kategorisierung: Nutzen Sie ein einheitliches Schema (FR, NFR, RC, BR)
  • Traceability: Verknüpfen Sie Anforderungen über die Hierarchie
  • Konflikte identifizieren: Anforderungen können im Konflikt stehen
  • Validierung: Lassen Sie Stakeholder die Anforderungen validieren
  • Dokumentation: Alles dokumentieren (Anforderungen, Traceability Matrix)

8.2 Checkliste für Ihre Anforderungen

Kategorisierung

  • Geschäftsanforderungen definiert: Warum wird das Projekt gemacht?
  • Funktionale Anforderungen ermittelt: Was soll das System tun?
  • Nicht-funktionale Anforderungen ermittelt: Wie soll das System performen?
  • Randbedingungen identifiziert: Welche Einschränkungen gibt es?

Verknüpfung

  • Traceability erstellt: Anforderungen mit Geschäftsanforderungen verknüpft?
  • Konflikte identifiziert: Anforderungen im Konflikt?
  • Priorisierung durchgeführt: Wichtigste Anforderungen?

Qualität

  • Qualitätskriterien geprüft: Complete, Correct, Consistent, ...?
  • Akzeptanzkriterien definiert: Wann ist eine Anforderung erfüllt?
  • Validierung durchgeführt: Stakeholder haben bestätigt?

9. Weiterführende Themen

  • Anforderungsermittlung: Methoden (Interviews, Workshops, Persona, Kano-Modell)
  • Anforderungsanalyse: Verifikation, Priorisierung (MoSCoW, Kano)
  • Anforderungsmanagement: Traceability, Change Management, Versionierung

Nächster Schritt: Lernen Sie Qualitätskriterien für Anforderungen (Kapitel 02).