FI-AE 03 Anforderungsanalyse und Lastenheft

FI-AE 03 Anforderungsanalyse und Lastenheft

In diesem Modul erlernen Sie die systematische Erhebung und Dokumentation von Softwareanforderungen. Sie verstehen, wie Sie funktionale und nicht-funktionale Anforderungen strukturi erfassen, priorisieren und in verbindliche Dokumente überführen. Die Fähigkeit, präzise Lasten- und Pflichtenhefte zu erstellen, bildet die Grundlage für erfolgreiche Softwareprojekte.

Sie werden lernen, Anforderungen mit der MoSCoW-Methode zu priorisieren, User Stories effektiv zu formulieren und den Unterschied zwischen Lasten- und Pflichtenheft klar zu bestimmen. Diese Kompetenzen sind essenziell, um Erwartungen von Stakeholdern zu managen und Projektziele eindeutig zu definieren.

Konzepte und Hintergrund

Funktionale Anforderungen

Beschreiben, was das System tun soll. Sie beantworten die Frage "Was soll das System können?" und sind direkt testbar. Beispiel: "Das System muss es Benutzern ermöglichen, sich mit E-Mail und Passwort zu authentifizieren."

Nicht-funktionale Anforderungen

Definieren Eigenschaften des Systems, wie es etwas tun soll. Sie betreffen Qualität, Leistung, Sicherheit und Usability. Beispiel: "Die Login-Funktion muss innerhalb von 2 Sekunden nach Anfrage antworten."

MoSCoW-Priorisierung

Methode zur Kategorisierung von Anforderungen in vier Prioritätsstufen: Must-have (unbedingt erforderlich), Should-have (wichtig), Could-have (nützlich) und Won't-have (nicht in dieser Version). Sie hilft bei der Entscheidungsfindung bei begrenzten Ressourcen.

Lastenheft

Dokument, das die Anforderungen aus Sicht des Auftraggebers (Kunden) beschreibt. Es ist verbindlich und dient als Grundlage für die Vertragsgestaltung. Das Lastenheft wird vom Auftraggeber erstellt und freigegeben.

Pflichtenheft

Detaillierte technische Spezifikation, die den Umsetzungsplan für das Entwicklungsteam darstellt. Es basiert auf dem Lastenheft und beschreibt, wie die Anforderungen technisch realisiert werden sollen. Das Pflichtenheft wird vom Auftragnehmer erstellt.

Praktische Schritte

1. Stakeholder-Interviews durchführen, um alle relevanten Perspektiven zu erfassen. Dies stellt sicher, dass keine wichtigen Anforderungen übersehen werden.
2. Funktionale Anforderungen als konkrete, testbare Aussagen formulieren. Verwenden Sie aktive Verben und vermeiden Sie vage Formulierungen.
3. Nicht-funktionale Anforderungen in quantifizierbare Kriterien umwandeln. Beispielsweise: "Das System muss 99,9 % der Zeit verfügbar sein" statt "Das System muss sehr stabil sein".
4. Anforderungen mit der MoSCoW-Methode priorisieren und dokumentieren. Erstellen Sie eine Tabelle mit allen Anforderungen und ihrer jeweiligen Prioritätsstufe.
5. User Stories im Format "Als [Rolle] möchte ich [Funktionalität], damit [Nutzen]" erstellen. Fügen Sie bei Bedarf Akzeptanzkriterien hinzu.
6. Lastenheft gemäß DIN 69905 strukturieren und formal freigeben lassen. Enthalten Sie mindestens Projektziele, funktionale und nicht-funktionale Anforderungen sowie Abnahmekriterien.
7. Pflichtenheft als technische Umsetzung des Lastenhefts erstellen. Definieren Sie hier Architektur, Schnittstellen, Datenmodelle und Implementierungsdetails.
8. Anforderungen in einem Traceability Matrix verknüpfen, um sicherzustellen, dass jedes Anforderungsmerkmal im System umgesetzt wird.
9. Regelmäßige Reviews der Anforderungen durchführen, um Änderungen zu erfassen und die Dokumentation aktuell zu halten.

Häufige Fallstricke

Weiterführende Ressourcen

• DIN 69905 - Projektmanagement im Ingenieurwesen - Offizielle Norm für Lasten- und Pflichtenhefte
• IONOS Digital Guide - User Stories effektiv formulieren - Praktische Anleitung zur Erstellung von User Stories
• Scrum.org - Requirements Management - Ressourcen zum Anforderungsmanagement im agilen Kontext
• PMI - Priorisierungstechniken: MoSCoW-Methode - Offizielle Erklärung der MoSCoW-Priorisierung
• Bundesministerium für Wirtschaft und Energie - Leitfaden Lasten- und Pflichtenheft - Praxisorientierter Leitfaden mit Beispielen

Wissens-Check

Vier Fragen zur Selbstkontrolle. Klicken Sie jede Frage an, um die richtige Antwort und Erklärung zu sehen.

Was ist der Hauptunterschied zwischen einem Lastenheft und einem Pflichtenheft?

• A) Das Lastenheft ist detaillierter als das Pflichtenheft
• B) Das Lastenheft wird vom Auftraggeber erstellt, das Pflichtenheft vom Auftragnehmer
• C) Das Pflichtenheft enthält nur nicht-funktionale Anforderungen
• D) Das Lastenheft dient der internen Planung, das Pflichtenheft der Kundenkommunikation

Richtige Antwort: B. Das Lastenheft beschreibt Anforderungen aus Kundensicht und wird vom Auftraggeber erstellt, während das Pflichtenheft die technische Umsetzung durch den Auftragnehmer darstellt. Option A ist falsch, da das Pflichtenheft detaillierter ist. Option C ist falsch, da beide auch funktionale Anforderungen enthalten. Option D ist falsch, da das Lastenheft für die Kundenkommunikation dient.

Welche Kategorie der MoSCoW-Priorisierung beschreibt Anforderungen, die für die grundlegende Funktionalität unerlässlich sind?

• A) Should-have
• B) Could-have
• C) Won't-have
• D) Must-have

Richtige Antwort: D. Must-have-Anforderungen sind für die grundlegende Funktionalität unbedingt erforderlich. Should-have-Anforderungen sind wichtig, aber nicht kritisch. Could-have-Anforderungen sind nützlich, aber verzichtbar. Won't-have-Anforderungen werden für diese Version nicht umgesetzt.

Welche Aussage beschreibt eine funktionale Anforderung korrekt?

• A) Die Benutzeroberfläche muss intuitiv gestaltet sein
• B) Das System muss Benutzern die Authentifizierung per E-Mail und Passwort ermöglichen
• C) Die Antwortzeit des Systems darf maximal 2 Sekunden betragen
• D) Das System muss mit gängigen Browsern kompatibel sein

Richtige Antwort: B. Funktionale Anforderungen beschreiben, was das System tun soll und sind direkt testbar. Die anderen Optionen beschreiben nicht-funktionale Anforderungen (Usability, Leistung, Kompatibilität).

Warum ist die systematische Erhebung von Anforderungen in der Anforderungsanalyse wichtig?

• A) Um den Entwicklungsprozess zu verlangsamen und mehr Zeit für die Planung zu haben
• B) Um sicherzustellen, dass alle Stakeholder-Erwartungen erfasst und dokumentiert werden
• C) Um den Code komplexer zu gestalten und so mehr Arbeitszeit zu generieren
• D) Um die Dokumentation zu minimieren und sich auf die Programmierung zu konzentrieren

Richtige Antwort: B. Die systematische Erhebung stellt sicher, dass alle Anforderungen und Erwartungen der Stakeholder erfasst werden, was die Grundlage für erfolgreiche Projekte bildet. Die anderen Optionen widersprechen den Zielen der Anforderungsanalyse.