Skip to content

Lastenheft

Software Das Lastenheft stellt eine grobe Produktskizze für ein zu erstellendes Software-Produkt dar. Damit ist das Lastenheft vereinfachte Form des Pflichtenhefts. Da es nicht detailliert ausfallen soll, muss es vom Umfang so knapp wie erforderlich gehalten werden, meist werden nur wenige Seiten benötigt.

Es wird nicht beschrieben, "wie" etwas gemacht werden soll, sondern nur "was" die neue Software leisten soll. Die Basisfunktionen der neuen Software und ihr Sinn muss deutlich herausgearbeitet werden.

Da das Lastenheft die Grundlage für Entscheider darstellt, muss es sprachlich so gehalten sein, dass diese es verstehen und vor allem die Argumente nachvollziehen können. Wenn der Auftraggeber eine Fachsprache verwendet, sollten die entsprechenden Begriffe auch an den erforderlichen Stellen eingesetzt werden, hier sollte eine Fachkraft der Branche gegebenenfalls noch einmal Korrektur lesen.

Hier sagt ein Bild auch oft mehr als 1000 Worte - eine Zeichnung kann viele Abläufe verdeutlichen! Auch Tabellen sollten eigesetzt werden, um Werte übersichtlich zu präsentieren. Zahlenreihen sollten in grafischer Darstellung visualiert werden.

Die Gliederung des Lastenhefts ist nicht verbindlich geregelt und es gibt verschiedene Empfehlungen dazu: Balzert empfiehlt
Zielbestimmung: Was soll die Software können?
Produkteinsatz: Wer soll die Software einsetzen?
Produktfunktionen: Welches sind die Hauptfunktionen?
Produktdaten: Welche Daten werden verarbeitet?
Produktleistungen: Wie schnell, umfassend, genau?
Qualitätsanforderungen: Wie zuverlässig, portabel...?
Ergänzungen: Was sonst noch?

Projektstudie (feasibility study)

Software Die Projektstudie wie sie nach DIN 69905 richtig heißt, auch Machbarkeitsstudie oder auf plattdeutsch auch "feasibility study" genannt, steht am Anfang größerer Projekte als erste Projektphase, teilweise noch vor dem Kick-off. Über die Tätigkeiten und Ergebnisdokumente gibt es in der Literatur keine Einigkeit. da die Gestaltung dieser Phase sehr von der Situation abhängt.

Mit der Projektstudie soll das Risiko für eine Erreichen des Projektziels geprüft werden, wenn nicht sicher ist ob dies überhaupt möglich ist. So kann man versuchen herauszubekommen, mit welchen Aufwand (zeitlich und damit auch finanziell) der Projekt realisiert werden kann. Rein organisatorisch bringt die Projektstudie Ordnung ins anfängliche Chaos.

Im Hauptteil der Projektstudie steht die Machbarkeitsprüfung: Hier wird die organisatorische Umsetzung und wirtschaftliche Machbarkeit (z.B. Kostenrahmen, Finanzierung), aber auch die technische Machbarkeit und die Verfügbarkeit von Ressourcen (Mitarbeiter, Räume, Geräte und Zeit) geklärt.

Für die Projektstudie wird üblicherweise ein strammes Zeitfenster angesetzt, nach deren die Untersuchungen abgeschlossen sein müssen.

Ist das Ergebnis dieser Studie negativ muss das Projekt abgelehnt oder komplett geändert werden. Nach der Machbarkeitsstudie fällt auf jeden Fall die Entscheidung "stop-or-go".

Im Bereich der Software-Entwicklung hat die Projektstudie auch noch eine weitere Funktion neben der eigentlichen Untersuchung der Machbarkeit, nämlich festzulegen, was die Software überhaupt leisten soll.

Neben den Anforderungen an die Software und die Funktionen sind auch die Gestaltung des Benutzer-Interfaces der Inhalt einer Vorstudie zu einer Software-Entwicklung. Ergebnis der Studie sollte daher auch ein Lastenheft sein.

Dazu sind Ausschreibungsunterlagen und gesetzliche Vorgaben zu beachten, es muss der Markt oder die bestehende Software analysiert werden sowie Interviews mit Anwendern und späteren Fachleuten geführt werden.

Wasserfall-Modell

Software Das Wasserfallmodell ist eine klassische Vorstellung von der Aufeinanderfolge von Projektphasen im Software-Engineering, der Softwareentwicklungsprozess in Phasen aufgeteilt. Der Name kommt daher, weil man dabei davon ausgeht, dass Ergenisse einer Phase wie bei einem Wasserfall immer als bindende Vorgaben für die nächst tiefere Phase eingehen.

Das Problem des Wasserfallmodells ist jedoch, dass es nur dann problemlos eingesetzt werden kann, wenn sich die Anforderungen und Kundenwünsche an das Projekt und das fertige Software-Produkt schon in der Planungsphase präzise beschreiben lassen.

Ende jeder Projektphase sind dabei sogenannte Meilensteine, Sitzungen an denen die Ergebnisse der Projektphasen dokumentiert werden.

Die Phasen können dabei in ihrer Anzahl und Bezeichnung unterschiedlich ausfallen, aber immer findet man die grafischen Darstellung der fünf bis sechs als Kaskade angeordneten Phasen:
wasserfallmodell
Davon gibt es einige Varianten, beispielsweise gehört in bei der Integration gehört auch ein Test zur Qualitätssicherung mit dazu. Zum Kickoff kann es nur ein kurzes Meeting geben, diese Phase kann aber auch die Durchführung einer Studie bedeuten, nach der erst weiter über das Projekt entschieden wird.

In der Praxis überschneiden sich Projektphasen und es ist auch immer wieder mal erforderlich, einen Schritt zurück zu gehen. Dies kann das Wasserfallmodell mit dem Ansatz, dass die Phasen nacheinander ablaufen und voneinander sauber abgrenzbar sind nicht mehr abbilden.

Damit ist das Wasserfallmodell nur auf einfache Projekte anwendbar und unflexibel gegenüber Änderungen. Es ist nur dann verwendbar wenn es möglich ist, schon früh die Anforderungen festzuschreiben. Werden Fehler erst spät erkannt, müssen sie mit erheblichem Aufwand entfernt werden.

Wegen der gravierenden Nachteile des Wasserfallmodells, die meist erhöhten finanzielle Aufwand bedeuten, hat das Wasserfallmodell heute kaum noch praktischen Wert und wurde in der IT-Industrie durch eine Vielfalt alternativer oder ergänzender Vorgehensweisen ersetzt.

Use-Case-Analyse

Software Bei der "Use-Case"-Analyse (auf deutsch auch Anwendungsfall-Analyse) wird genau einen Ablauf oder einen Prozess beschrieben. Dabei definiert man eine Interaktion zwischen Akteuren (dargestellt als Strichmännchen) und dem betrachteten System.

Hintergrund ist dabei immer ein beestimmtes fachliches Ziel (plattdeutsch: "business goal") zu erreichen. Die UML2 vermeidet allerdings den Begriff "System" und verwendet stattdessen den Begriff "Subjekt" um zu betonen, dass ein Anwendungsfall das erforderliche Verhalten einer Vielzahl von Modellelementen der UML2 deklarieren kann.

Definition: Ein Use Case beschreibt eine abgeschlossene, ununterbrochene Abfolge von Aktionen eines Akteurs am System mit Ergebnis von fachlichem Wert.

Schwierig ist die Abgrenzung von Anwendungsfällen, vor allem da sie nicht immer an Geschäftprozessen festzmachen sind. Um festzustellen, ob ein Anwendungsfall schon zu komplex ist, wurde von Cockburn der "Kaffeepausen-Test" vorgeschlagen: Ein Anwendungsfall soll so weit gehen, wie ein Nutzer für diesen Anwendungsfall und die notwendige Interaktion keine Kaffeepause einlegen würde.

Ein CASE-Tool für die Darstellung von Use-Case ist Rational Rose, ein Werkzeuge für die Architektur- und Entwurfsmodellierung, die modellorientierte Entwicklung, die architekturbasierte zeiteffiziente Anwendungsentwicklung (Rapid Application Development, RAD) sowie die Durchführung von Komponententests und Laufzeitanalyse.

(aus einer Use-Case-Modellierung mit Rational Rose)

Volere-Schema

Software Das Volere-Schema wurde von der Atlantic Systems Guild entwickelt und stelt Hilfsmittel und Materialien um das Thema Anforderungsdefinition im Software Engineering bereit.

"il volere" ist italienisch und bedeutet auf Deutsch soviel wie "wollen", "mögen" aber auch "brauchen".

Am bekanntesten ist dabei sicher die "Snowcard", ein Karteikarten-Formular, mit dem die einzelnen Anforderungen strukturiert und formalisiert für ein Software-Projekt auch in einer Datenbank erfasst werden können.
volere snowcard
Der Name Snowcard soll übrigens von dem optischen Eindruck kommen, der ensteht wenn ein Karteikasten mit diesem A6-Kärtchen aus der Hand gleitet...

Jede Anforderung bekommt eine Nummer. Damit kann sie von weiteren Anforderungen referenziert und eindeutig identifiziert werden.

Dazu wird jede Anforderung einem "Requirement Type", also einem Anforderungstyp zugeordnet. [...]

Eine kurze Beschreibung und der Hintergrund dieser Anforderung, also was mit dieser Anforderung beweckt werden soll, sind dann die nächsten beiden Punkte, die erfasst werden.

Die Quelle der Anforderung wird ebenfalls vermerkt, wer hat diese Anforderung haben wollen?

Zusätzlich wird angeben, wie später überprüft werden kann, ob diese Anforderung vom fertigen Produkt erfüllt werden kann. Im idealen Fall kann hier schon ein Test für die Qualitätssicherung spezifiziert werden.

Zwei wichtige Felder sind die Kundenzufriedenheit, wenn das Feature implementiert wurde oder der Grad der Unzufriedenheit, wenn das Feature in der fertigen Software nicht vorhanden ist. Sie werden mit Werten von 1 bis 5 ausgefüllt, dabei stellt 1 relative Emotionslosikeit und 5 extreme Emotionen dar, aber sehr unzufrieden oder auch sehr zufrieden.

Damit kann man die sogenannten "goldenen Türklinken am Rolls-Royce" vermeiden, darunter versteht man Features die einige Benutzer gern hätten, die aber eigentlich gar nicht so wichtig sind.

Schließlich können noch Abhängigkeiten und Konflikte angegeben werden. Abhängigkeiten treten vor allem zu weiteren Anforderungskarten auf und können so mit der Angabe der Anforderungsnummer an dieser Stelle dokumentiert werden "wenn nicht dies, dann aber auch nicht das". Konflikte bedeuten eher "wenn jenes Feature, dann aber dieses Feature nicht".
tweetbackcheck