Vom Lastenheft zum Pflichtenheft

In dieser Lerneinheit erfährst du, wie du die Kundenanforderungen aus dem Lastenheft systematisch in konkrete technische Spezifikationen für das Pflichtenheft überführst. Du lernst die wichtigsten Schritte und Methoden kennen, um Anforderungen präzise zu analysieren und in umsetzbare Vorgaben zu transformieren. Diese Fähigkeit ist zentral für deine spätere Projektarbeit, da sie die Basis für eine erfolgreiche technische Realisierung und Kundenzufriedenheit bildet.

Einführung

Stell dir vor: Dein Team erhält ein Lastenheft mit der Anforderung “Das System soll eine benutzerfreundliche Login-Funktion haben”. Klingt klar, oder? Doch beim ersten Entwickler-Meeting hagelt es Fragen: Welche Authentifizierungsmethode? Wie lange bleiben Sessions aktiv? Was passiert nach 3 Fehlversuchen? Single-Sign-On unterstützen?

Vom WAS zum WIE: Das Pflichtenheft übersetzt vage Anforderungen in konkrete Spezifikationen — Bildrechte: Ausbildung-in-der-IT.de (KI-unterstützt)

Ohne präzise technische Spezifikation kann kein Entwickler mit der Umsetzung beginnen.

Genau hier kommt das Pflichtenheft ins Spiel: Es übersetzt die Kundenanforderungen aus dem Lastenheft in konkrete, technische Vorgaben. In dieser Lerneinheit lernst du, wie diese Transformation systematisch gelingt.

Lernziele

Nach dieser Lerneinheit kannst du:

• Die Transformation von Lastenheft-Anforderungen in technische Spezifikationen durchführen
• Traceability zwischen Anforderungen herstellen (LH-01 → PH-01a, PH-01b)
• Die relevanten Standards (ISO/IEC/IEEE 29148, DIN 69901-5) für die Strukturierung anwenden
• Funktionale und nicht-funktionale Anforderungen präzisieren und mit SMART-Kriterien messbar machen
• Ein Pflichtenheft systematisch strukturieren mit technischen Spezifikationen, Architektur-Vorgaben und Test-Anforderungen

Der rote Faden

Nachdem wir in den vorherigen Lerneinheiten die Grundlagen gelegt haben, schließen wir jetzt den Kreis:

• Lerneinheit “Stakeholder und Anforderungserhebung”: Du hast gelernt, wie Anforderungen von verschiedenen Stakeholdern gesammelt werden
• Lerneinheit “Arten von Anforderungen im Lastenheft”: Du kennst funktionale, nicht-funktionale und Randbedingungen

Jetzt der entscheidende Schritt: Wie werden diese Anforderungen aus dem Lastenheft in technisch umsetzbare Spezifikationen im Pflichtenheft überführt?

Was bedeutet “Überführung”?

Das Lastenheft beschreibt das “WAS” - die Anforderungen aus Kundensicht. Das Pflichtenheft beschreibt das “WIE” - die technische Umsetzung aus Entwicklersicht.

Überführung bedeutet:

• Kundenanforderungen in technische Spezifikationen übersetzen
• Aus “Das System soll benutzerfreundlich sein” wird “Login-Formular mit max. 3 Eingabefeldern, Antwortzeit < 200ms, WCAG 2.1 Level AA konform”
• Lücken schließen: Anforderungen präzisieren, technische Details ergänzen
• Nachvollziehbarkeit herstellen: Jede Pflichtenheft-Spezifikation lässt sich auf eine Lastenheft-Anforderung zurückführen

Die Überführung ist kein 1:1-Mapping - eine Lastenheft-Anforderung kann in mehrere technische Spezifikationen aufgespalten werden.

Traceability - Anforderungen nachvollziehbar machen

Traceability (Rückverfolgbarkeit) bedeutet: Jede technische Spezifikation im Pflichtenheft muss sich auf eine Anforderung im Lastenheft zurückführen lassen.

Warum ist das wichtig?

• Vertragsrelevanz: Bei Streitigkeiten kann nachgewiesen werden, welche Anforderung wie umgesetzt wurde
• Änderungsmanagement: Wenn eine Lastenheft-Anforderung geändert wird, weiß man sofort, welche Pflichtenheft-Spezifikationen betroffen sind
• Vollständigkeitsprüfung: Keine Anforderung geht verloren

Konkret: Lastenheft-Anforderung LH-01: “Benutzer-Login implementieren”

→ wird zu 3 Pflichtenheft-Spezifikationen:

• PH-01a: Login-Formular (HTML/CSS)
• PH-01b: JWT-Authentifizierung (Backend)
• PH-01c: Session-Management (Redis, 30 Min. Timeout)

Standards für die Strukturierung

Für die Strukturierung des Pflichtenhefts gibt es internationale und nationale Standards:

ISO/IEC/IEEE 29148 (seit 2011, ersetzt IEEE 830)

• Internationaler Standard für Requirements Engineering
• Definiert Struktur und Inhalte von Requirements-Dokumenten
• Fokus auf Software- und System-Requirements

DIN 69901-5 (seit 2009, ersetzt DIN 69905)

• Deutscher Standard für Projektmanagement
• Definiert Lastenheft und Pflichtenheft im Projektkontext
• Produktfokussierte Gliederung

Diese Standards geben bewährte Vorlagen für die Gliederung - im zweiten Teil dieser Lerneinheit schauen wir uns die detaillierte Struktur nach DIN 69901-5 an.

Strukturierung nach DIN 69901-5

DIN 69901-5 definiert eine produktfokussierte Gliederung für das Pflichtenheft. Die Hauptabschnitte sind:

Abschnitt	Inhalt	Beispiel
1. Ausgangssituation & Ziele	Projekthintergrund, Ziele	”E-Commerce-Plattform für 10.000 Nutzer”
2. Produkteinsatz	Anwendungsszenarien	”B2C Online-Shop, Mobile-First”
3. Produktfunktionen	Funktionale Anforderungen	”Login, Produktkatalog, Warenkorb, Checkout”
4. Produktdaten	Datenstrukturen	”User, Product, Order (Entity-Relationship)“
5. Produktleistungen	Nicht-funktionale Anforderungen	”1000 concurrent users, 99.9% Verfügbarkeit”
6. Qualitätsanforderungen	Test- und QA-Vorgaben	”80% Code-Coverage, Performance-Tests”

Diese Struktur ist produktorientiert - sie fokussiert auf WAS entwickelt wird, nicht auf den Entwicklungsprozess.

Funktionale Anforderungen detaillieren

Funktionale Anforderungen aus dem Lastenheft sind oft High-Level - im Pflichtenheft werden sie detailliert und technisch präzisiert.

Beispiel:

Lastenheft (High-Level): “Benutzer soll sich anmelden können”

→ Pflichtenheft (detailliert):

• Login-Formular: 2 Eingabefelder (E-Mail, Passwort), “Passwort vergessen”-Link, Responsive Design
• Authentifizierung: JWT-Token, bcrypt für Passwort-Hashing (12 Runden), Rate-Limiting (max. 5 Versuche/Min.)
• Session-Management: Redis-basiert, 30 Min. Idle-Timeout, Refresh-Token (7 Tage gültig)

Rolle von UML:

• Use-Case-Diagramme: Visualisieren Benutzer-Interaktionen
• Aktivitätsdiagramme: Zeigen Prozessabläufe (z.B. Login-Flow mit Fehlerbehandlung)
• Sequenzdiagramme: Interaktion zwischen Komponenten (Frontend → Backend → Datenbank)

Nicht-funktionale Anforderungen präzisieren

Nicht-funktionale Anforderungen (NFRs) aus dem Lastenheft sind oft vage - “Das System soll schnell sein”, “Die Software soll sicher sein”.

Im Pflichtenheft müssen NFRs messbar und testbar werden. Wie du bereits gelernt hast, helfen die SMART-Kriterien dabei, vage Anforderungen zu präzisieren:

• Specific (Spezifisch): Konkrete Metrik benennen
• Measurable (Messbar): Zahlenwert angeben
• Achievable (Erreichbar): Realistisch umsetzbar
• Relevant (Relevant): Für das Projekt wichtig
• Time-bound (Zeitgebunden): Deadline festlegen

Beispiele für NFRs:

Performance:

• Vage: “System soll schnell sein”
• SMART: “API-Antwortzeit < 200ms bei 95% der Anfragen unter Last (1000 concurrent users)”

Sicherheit:

• Vage: “Software soll sicher sein”
• SMART: “TLS 1.3 für alle Verbindungen, bcrypt (12 rounds) für Passwörter, OWASP Top 10 abgedeckt”

Umfang: Wie groß wird das Pflichtenheft?

Das Pflichtenheft ist deutlich umfangreicher als das Lastenheft - aber warum?

Typische Größenverhältnisse:

• Vertragsrelevantes Pflichtenheft: 2-3x so groß wie das Lastenheft
• Vollständig ausgearbeitetes Pflichtenheft: 4-10x so groß wie das Lastenheft

Gründe für den höheren Umfang:

• Detaillierungsgrad: “Benutzerfreundliches Login” (1 Satz im LH) → 2 Seiten technische Spezifikation im PH
• Technische Ergänzungen: Architektur, Datenbank-Schema, API-Spezifikationen
• Test-Anforderungen: Für jede Funktion Test-Szenarien beschreiben
• Deployment-Vorgaben: CI/CD, Monitoring, Backup-Strategie
• Diagramme & Visualisierungen: UML, ER-Diagramme, Architektur-Diagramme

Ein 10-seitiges Lastenheft kann zu einem 40-100 seitigen Pflichtenheft werden - das ist normal und gewollt.

⏳ Lädt Dataview-Inhalt...

Technische Spezifikationen: System-Architektur

Im Pflichtenheft werden konkrete Architektur-Entscheidungen getroffen:

Architektur-Muster:

• Monolith: Eine einzige Anwendung (z.B. Django-App mit PostgreSQL)
• Client-Server: Frontend getrennt von Backend (z.B. React + REST-API)
• Microservices: Mehrere unabhängige Services (z.B. User-Service, Product-Service, Order-Service)

Technologie-Stack festlegen:

• Frontend: React 18, TypeScript, TailwindCSS
• Backend: Node.js 20, Express, PostgreSQL 16
• Caching: Redis 7
• Deployment: Docker, Kubernetes

Schnittstellen definieren:

• REST-API: GET /api/products, POST /api/orders
• Datenformate: JSON, UTF-8
• Authentifizierung: JWT Bearer Token
• Versionierung: URL-basiert (/api/v1/)

Jede Entscheidung muss begründet werden: Warum React? Warum PostgreSQL? Warum Microservices?

Technische Spezifikationen: Datenhaltung & Security

Datenbank-Design:

• Entity-Relationship-Modell erstellen (z.B. User 1:N Order, Product M:N Order via OrderItem)
• Tabellen-Schema definieren:
  • users (id, email, password_hash, created_at)
  • products (id, name, price, stock, category_id)
  • orders (id, user_id, total, status, created_at)
• Indizes festlegen für Performance (z.B. Index auf users.email, products.category_id)

Sicherheitsanforderungen:

• Verschlüsselung: TLS 1.3 für Transport, AES-256 für Daten at rest
• Passwort-Hashing: bcrypt mit 12 Runden
• Zugriffskontrolle: Role-Based Access Control (RBAC) mit Rollen: Admin, User, Guest
• Input-Validierung: SQL-Injection-Schutz, XSS-Prevention

Backup-Strategie:

• Tägliche automatische Backups (3:00 Uhr UTC)
• 7 Tage aufbewahren, dann wöchentlich für 4 Wochen
• Recovery-Test monatlich

Entwicklungsvorgaben

Das Pflichtenheft definiert wie entwickelt wird - nicht nur was entwickelt wird:

Coding-Standards:

• Style Guide: ESLint + Prettier Konfiguration (z.B. 2 Spaces, max 80 Zeichen/Zeile)
• Namenskonventionen: camelCase für Variablen, PascalCase für Klassen, UPPER_CASE für Konstanten
• Kommentare: JSDoc für öffentliche Funktionen, TODO mit Ticket-Nummer

Versionskontrolle (Git):

• Branching-Strategie: GitFlow (main, develop, feature/, hotfix/)
• Commit-Messages: Conventional Commits (feat:, fix:, docs:)
• Pull Requests: Mindestens 2 Reviews erforderlich vor Merge

Code-Review-Prozess:

1. Feature-Branch erstellen
2. Code schreiben + Tests
3. Pull Request öffnen
4. Automatische Checks (Linting, Tests, Security Scan)
5. 2 Team-Mitglieder reviewen
6. Änderungen einarbeiten
7. Merge nach Approval

Test-Anforderungen

Testing ist kein “Nice-to-have” - das Pflichtenheft definiert klare Test-Vorgaben:

Test-Pyramide:

• Unit-Tests (70%): Einzelne Funktionen/Klassen testen (Jest, Vitest)
  • Beispiel: calculateTotal() mit verschiedenen Warenkorb-Szenarien
• Integrationstests (20%): Komponenten-Zusammenspiel testen
  • Beispiel: API-Endpoint → Service → Datenbank
• E2E-Tests (10%): Komplette User-Flows testen (Playwright, Cypress)
  • Beispiel: Registrierung → Login → Produkt kaufen → Logout

Testabdeckung-Ziele:

• Mindestens 80% Code-Coverage (gemessen mit Coverage-Tool)
• 100% Coverage für kritische Business-Logik (Payment, Security)

Abnahmekriterien:

• Alle Tests müssen grün sein (CI/CD Pipeline)
• Performance-Tests: API-Antwortzeit < 200ms
• Security-Tests: OWASP Top 10 abgedeckt

Deployment & Betrieb

Das Pflichtenheft regelt auch wie die Software in Produktion geht und wie sie betrieben wird:

Deployment-Pipeline (CI/CD):

1. Continuous Integration: Bei jedem Push → Tests laufen, Code-Quality-Checks
2. Continuous Deployment: Bei Merge in main → automatisches Deployment auf Staging
3. Production-Deployment: Nach manuellem Approval → Deployment auf Production
4. Tools: GitHub Actions, GitLab CI, Jenkins

Monitoring & Logging:

• Application Monitoring: Response-Zeiten, Error-Rates (z.B. DataDog, New Relic)
• Infrastructure Monitoring: CPU, RAM, Disk (z.B. Prometheus, Grafana)
• Logging: Strukturierte Logs (JSON-Format), zentrale Log-Aggregation (z.B. ELK Stack)
• Alerting: Bei Fehlerrate > 5% → Slack-Benachrichtigung + On-Call-Team

Wartung & Support:

• Updates: Monatliche Security-Patches, quartalsweise Feature-Updates
• Support-Zeiten: Mo-Fr 9-17 Uhr, Response-Zeit < 4h

⏳ Lädt Dataview-Inhalt...

Zusammenfassung und Ausblick

Zusammenfassung

Die Überführung vom Lastenheft zum Pflichtenheft transformiert Kundenanforderungen (WAS) in technische Spezifikationen (WIE). Das Lastenheft beschreibt Anforderungen aus Kundensicht, das Pflichtenheft übersetzt diese in umsetzbare technische Vorgaben.

Traceability (Rückverfolgbarkeit) stellt sicher, dass jede Pflichtenheft-Spezifikation auf eine Lastenheft-Anforderung zurückführbar ist. Beispiel: “Benutzer-Login” (LH-01) → Login-Formular (PH-01a), JWT-Authentifizierung (PH-01b), Session-Management (PH-01c).

Relevante Standards: ISO/IEC/IEEE 29148 (internationaler Standard für Requirements Engineering) und DIN 69901-5 (deutscher Projektmanagement-Standard mit 6 Hauptabschnitten: Ausgangssituation & Ziele, Produkteinsatz, Produktfunktionen, Produktdaten, Produktleistungen, Qualitätsanforderungen).

Funktionale Anforderungen werden technisch detailliert. Aus “Benutzer soll sich anmelden können” wird: Login-Formular (2 Eingabefelder, Responsive), JWT-Authentifizierung (bcrypt, Rate-Limiting), Session-Management (Redis, 30 Min. Timeout). UML-Diagramme visualisieren Interaktionen.

Nicht-funktionale Anforderungen müssen messbar werden. SMART-Kriterien helfen: “System soll schnell sein” → “API-Antwortzeit < 200ms bei 95% der Anfragen (1000 concurrent users)“. “Software soll sicher sein” → “TLS 1.3, bcrypt (12 rounds), OWASP Top 10 abgedeckt”.

Technische Spezifikationen umfassen: System-Architektur, Technologie-Stack, REST-API-Schnittstellen, Datenbank-Design (ER-Modell, Schema, Indizes) und Sicherheit (Verschlüsselung, RBAC, Backup).

Entwicklungsvorgaben: Coding-Standards (ESLint, Prettier), Versionskontrolle (GitFlow, Conventional Commits), Code-Review-Prozess.

Test-Anforderungen: Test-Pyramide (70% Unit, 20% Integration, 10% E2E), mindestens 80% Coverage (100% für kritische Logik).

Deployment & Betrieb: CI/CD-Pipeline, Monitoring & Logging, Wartung & Support.

Umfang: Das Pflichtenheft ist 2-3x (vertragsrelevant) bis 4-10x (vollständig) größer als das Lastenheft durch technische Detaillierung, Architektur-Spezifikationen, Test-Anforderungen und Diagramme.

Ausblick

In der nächsten Lerneinheit “Inhalte und Gliederung des Pflichtenhefts” vertiefst du die praktische Strukturierung mit konkreten Beispielen, Templates und Best Practices.

---