Lastenheft erstellen – in zwei Wochen zur Freigabe
Vor einiger Zeit hat mich ein Kunde angesprochen und mich Folgendes gefragt: „Herr Schorre, ich brauche ein Lastenheft – in den nächsten zwei Wochen. Geht das?“
Risikominimierung unter Zeitdruck
Dieser Kunde kannte meinen Blog und meinen Podcast, ihm war durchaus bewusst, dass wir Systemingenieure für die Erstellung eines freizugebenden Lastenheftes für ein komplexes System erfahrungsgemäß zwischen zwei und sechs Monate Zeit brauchen.
Dennoch stand er mit dieser Frage vor mir – denn dieser Kunde hatte schlicht keine Zeit: Seine Einkaufsabteilung wollte für fünf Millionen Euro eine Robotik-Anlage bestellen, doch das Einzige, was für die Ausschreibung seinerzeit vorlag, war eine kleine Excel-Liste mit sage und schreibe zehn Zeilen Inhalt. Zehn Zeilen, für fünf Millionen Euro.
Als Projektleiter war ihm das verständlicherweise zu heikel und so suchte er nach einer praktikablen Lösung für seinen Wunsch, ein Lastenheft innerhalb von zwei Wochen zu erstellen. Als er mich fragte, ob das möglich sei, lautete meine Antwort: „Ja!“
In meinen Jahren als Systemingenieur und Projektleiter wurde mir häufig die Aufgabe übertragen, in kurzer Zeit ein akzeptables Lastenheft zu erstellen. So habe ich über die Jahre einen smarten Prozess entwickelt, um innerhalb von zwei Wochen ein freigegebenes Lastenheft zu erschaffen.
Natürlich kann solch ein Lastenheft nicht die Reife und Güte erlangen wie ein Lastenheft, das über Monate erstellt worden ist. Darüber war sich der genannte Kunde auch durchaus im Klaren, doch er wusste, dass das Ergebnis wesentlich besser sein würde als das, was er bis dahin hatte.
Die Zutaten: Ein smarter Prozess – und klare Spielregeln
Der von mir entwickelte Prozess besteht aus fünf Schritten:
Erfassen – Sammle die Anforderungen. Verschaffe dir einen Überblick und visualisiere die Anforderungen an das System. Diskutiere die vorhandenen Wünsche und kläre, was dazugehört.
Sortieren – Strukturiere den Inhalt. Bringe die vorhandenen Ergebnisse in eine sinnvolle Struktur. Sortiere die Inhalte, sodass sie ihren korrekten Platz erhalten.
Füllen – Schließe vorhandene Lücken. Schaffe ein Lastenheft, das inhaltlich korrekt gefüllt ist: Finde und fülle bestehende Lücken und verbessere doppelte oder unklare Inhalte.
Prüfen – Reflektiere das Ergebnis. Überprüfe, ob die vorhandenen Inhalte wirklich stimmig sind. Kläre offene Fragen und passe die Inhalte konstant an.
Freigeben – Erstelle den finalen Stand. Prüfe gemeinsam mit allen Beteiligten, ob das Ergebnis dem aktuellen Wissensstand und den bekannten Vorstellungen entspricht. Korrigiere alles den Änderungswünschen entsprechend und erstelle den finalen Stand.
Hier findest du die einzelnen Schritte noch einmal dargestellt.
Die Spielregeln sind sogar noch einfacher:
- Wer sich nicht einbringt, kann sich hinterher nicht beschweren.
- Das Timing wird eingehalten. Nur was bis zum vereinbarten Zeitpunkt da ist, wird berücksichtigt. Alles andere nicht.
Mit diesem klaren Vorgehen hat der erwähnte Kunde innerhalb von zwei Wochen ein freigegebenes Lastenheft erhalten. Er war glücklich und zufrieden – denn er konnte das Risiko, fünf Millionen Euro in die falschen Anforderungen zu versenken, deutlich reduzieren.
Viele meiner Kunden waren schon mal in ähnlichen Situationen: Plötzlich erkennt man seinen dringenden Bedarf nach einem Lastenheft, hat aber keine acht Wochen geschweige denn sechs Monate Zeit, um es herzustellen. Mit meinem Lösungsansatz lässt sich diese Herausforderung meistern – wenn sich alle an die genannten Schritte und Regeln halten.
Ich brauche ein professionelles Lastenheft
Du möchtest das Risiko in Deinem Projekt signifikant senken?
Vereinbare einen Termin mit mir und ich helfe Dir mit meinem erprobten Prozess. Du erhältst in 2 Wochen ein Lastenheft.
Sieben Möglichkeiten um Requirements zu finden
Um Requirements an ein System zu finden müssen wir eine Übersicht erlangen. Das bedeutet, sich die Zeit zu nehmen, um alle relevanten Quellen zu sammeln und sich einen Überblick zu verschaffen.
Oft können wir Requirements aus diesen Quellen wunderbar nutzen, um unsere Lastenhefte zu verbessern. Aber wo findet man Quellen, die relevante Requirements für das Lastenheft beinhalten?
- Projektlaufwerke
Informationen sind oft in Projektlaufwerken verteilt. Das können Projektlaufwerke der Entwicklung, aber auch Verzeichnisse des Produktmanagements oder des Vertriebs sein. In diesen Laufwerken finde ich oft Präsentationen, Beschreibungen, Angebote, Aufträge, Gesprächsnotizen und so weiter.
- Lastenhefte von alten Projekten
In Lastenheften von alten Projekten habe ich schon viele relevante Informationen gefunden. Allerdings sind sie nicht immer in den Ablagestrukturen vorhanden. So schaue ich explizit auch noch mal in alte Projekte rein, ob dort noch relevante Lastenhefte vorliegen.
- Normenvorgaben
Jedes System unterliegt verschiedenen Normen. Manche sind bekannt, andere werden oft übersehen. Ich schaue in alten Projekten nach, ob ich alle relevante Normen in den jeweils geltenden Versionen vorliegen habe. Dabei sollte auch geprüft werden, ob die in (Haupt-) Normen angezogenen (Unter-) Normen vorliegen. Diese Normen bewerte ich dann in einer Normenübersicht.
- Pflichtenhefte alter Projekte
Oft befinden sich auch in Pflichtenheften alter Projekte wertvolle Requirements, die ich nutzen kann. Dazu besorge ich mir die Dokumente von Kollegen, vom Projektserver oder aus dem Requirement-Management-System.
- Auslieferungsdokumentation alter Projekte
Requirements befinden sich oft auch in Auslieferungsdokumentationen alter Projekte. Auch wenn diese Projekte keine vollständigen Spezifikationen besitzen, haben die Kollegen häufig in den Auslieferungsdokumenten wichtige Anforderungen dokumentiert.
- Prozessbeschreibungen
Eine weitere interessante Quelle sind Prozessbeschreibungen. Dort werden die im Unternehmen zu nutzenden Entwicklungsprozesse beschrieben. Diese Prozessbeschreibungen sind dem Projektteam/Projektleiter meist nicht bekannt, werden darum nicht verwendet, und Wissen wird dann in irgendwelchen Verzeichnissen abgelegt. Aber es gibt auch die Projekte, die sich an diesen Prozessvorgaben orientieren. Diese können mir helfen, die Requirements dort zu suchen, wo sie normalerweise auch hingehören.
- Erfahrene Kollegen
Eine der wertvollsten Quellen sind erfahrene Kollegen. Ich sehe zu, dass ich mit möglichst vielen von ihnen spreche und versuche herauszubekommen, wo Informationen möglicherweise dokumentiert sein können. Alternativ kann auch eine grobe Beschreibung der Kollegen mir zu verstehen helfen, welche Requirements wichtig sind.
Risikoreduktion - ich will weniger Risiko in meinem Projekt haben
Du musst ein Lastenheft erstellen und alle relevanten Anforderungen finden?
Vereinbare einen Termin mit mir und ich helfe Dir mit meinem erprobten Prozess. In zwei Wochen liegt ein freigegebenes Lastenheft auf Deinem Tisch!
Der System Footprint – Entwicklung und Einsatz
In diesem Abschnitt stelle ich den System Footprint als strukturierte Systemvisualisierung vor. Denn obwohl dieser Überblick enorm wertvoll und effektiv ist, wird er oft unterschätzt.
Die Geschichte des System Footprint
Der System Footprint ist im Troubleshooting entstanden. Ich befand mich immer wieder in Situationen, in denen ich mir recht schnell einen Überblick und ein klares Verständnis des Systems verschaffen musste: Wie genau ist es aufgebaut und welches sind die wichtigsten Anforderungen?
Meist hatten wir in diesen Situationen kaum noch Zeit und konnten nur die wichtigsten Dinge umsetzen. Dazu musste entschieden werden, welche von den existierenden Anforderungen an das System in diesem Kontext überhaupt noch relevant waren.
Und so habe ich angefangen, mir eine Mindmap aufzubauen, in welche ich zunächst alles hineingekippte, was wahrscheinlich relevant war und Sinn machte. Das funktionierte eine Zeit lang ganz gut – allerdings noch nicht optimal.
Kurze Zeit später bin ich über das Buch „Business Modell Generation“ von Alexander Osterwalder gestolpert. Es beschreibt eigentlich, wie ein Business Modell visualisiert werden kann. Ich habe allerdings die Grundidee dieser Visualisierung und den Nutzen der Post-Its genommen und die nötigen Schwerpunkte integriert.
Dann habe ich die Inhalte auf ein „Canvas“ – so nennt sich die Fläche, auf der wir alles darstellen – übertragen und in die bereits bestehende Mindmap eingesetzt. So konnte ich dann in den Blöcken des Footprints alles Nötige wesentlich besser visualisieren als zuvor. Seit dieser zweiten Version heißt das Ganze nun System Footprint.
Universell anwendbar
In den letzten Jahren hat sich der System Footprint enorm weiterentwickelt, zum einen durch seinen Einsatz in der Praxis, zum anderen aber auch durch starkes Feedback. Ich habe intensive Diskussionen geführt und die neuen Erkenntnisse konstant eingebaut.
Besonders spannend war für mich auch, dass der System Footprint in zwei verschiedenen Kontexten sehr gut funktioniert: In mechatronischen, technischen Projekten – und bei IT-Systemen.
Ich betrachte als Software-Architekt bzw. als System-Ingenieur Systeme als mechatronische, technische Systeme: Wir erfassen im System Footprint also alle Fraktionen, Konstruktionen, die Elektronik, Software, Optik etc. – eben alles, was es in diesem System gibt.
Mittlerweile habe ich aber auch eine Menge Anfragen rund um IT-Systeme. Das war für mich zunächst überraschend, da ich das anfänglich gar nicht im Fokus hatte, aber offensichtlich liegt dort auch Bedarf vor. Und das Gute ist: Der System Footprint funktioniert auch dort super.
Auf allen Ebenen nutzbar
Ursprünglich habe ich das Ganze als Visualisierung der Systemanforderung für ein Troubleshooting-Projekt entwickelt – also für die Systemebene. Ich greife die Ebenen hier nochmals kurz auf: Die oberste Ebene ist die Kundenebene. Auf dieser existieren Lastenhefte, Normen und weitere Spezifikationen – kurz, das „Wünsch-Dir-Was“.
Die Ebene darunter ist die Systemebene, umgangssprachlich auch als Pflichtenheft bezeichnet, was am Ende die Antwort des Projekts auf das Lastenheft ist. Diese lässt sich aufteilen in Problembereich – die exakte und testbare Beschreibung des Kundenproblems – und Lösungsbereich – die Systemarchitektur-Spezifikation, also die Lösungsbeschreibung.
Auf der Systemebene funktioniert der System Footprint unglaublich gut und wirkungsvoll – dafür war er ja ursprünglich gedacht. Doch er unterstützt auch die Erstellung von Lastenheften extrem gut: Wir visualisieren damit Aspekte, die bis dahin vielleicht gar nicht sichtbar waren.
Die Visualisierung der Anforderungen ist ein extrem großer Nutzen. In den zahlreichen Workshops, die ich in den letzten Jahren durchgeführt habe, haben wir den System Footprint in ca. zwei bis vier Stunden erstellt – und konnten dann sehr effektiv damit arbeiten: Die Visualisierung nahm eigentlich das gesamte Team vor, während ich es dabei begleitete und vor allem half, ein gemeinsames Verständnis für das große Gesamtbild zu erschaffen.
Ein weiterer Gewinn war die viel bessere Kommunikation. Bei einem großen Unternehmen aus der feinmechanischen-optischen Industrie beispielsweise haben wir zum Workshop nicht nur die Entwickler eingeladen, sondern auch Leute aus Vertrieb, Marketing, Produktion, Produktmanagement etc. Das Feedback sprach für sich.
Insgesamt hat sich das gemeinsame Verständnis enorm weiterentwickelt und die Kommunikation untereinander ist wesentlich besser geworden. Alle konnten das System gemeinsam betrachten, die Kundensicht nachvollziehen und mit dem Lastenheft das große Ganze erkennen. Außerdem konnten wir zusammen mit dem Project Footprint die Trennung zwischen den technischen und den Projektanforderungen auch ganz bewusst herbeiführen.
Der System Footprint – Aufbau und Inhalt
User- und Use-Cases & die Value-Proposition
Im Grunde kann man sich das Ganze als großes Poster vorstellen, welches in mehrere Kästchen aufgeteilt ist, die – ähnlich wie Puzzlestücke – ineinanderpassen.
Auf der rechten Seite des System Footprints platziere ich den Kunden bzw. den Benutzer, der das System hinterher verwendet. In der Mitte findet sich die Value-Proposition, also das Nutzenversprechen, der Grund dafür, dass der Kunde dieses System überhaupt kauft.
Die Value-Proposition sollte unbedingt klar definiert und verstanden werden, denn so können wir später im Requirements Engineering unproblematischer entscheiden, ob eine Anforderung notwendig bzw. wie nützlich sie ist. Manchmal gibt es auch Anforderungen, die einen Nutzen zerstören können. Kenne ich die Value-Proposition eines Systems, kann ich auch hier besser entscheiden, ob diese Anforderung tatsächlich kontraproduktiv ist.
Dieses Nutzenversprechen transportieren wir über zwei Wege zum Kunden: Über die Nutzungsfälle und über die Liefereinheiten. Bei ersterem sind die Key-Use-Cases gemeint, also die Einsatzfälle des Systems. Bei den Liefereinheiten kann es sich entweder um einen ABC-Musterstand handeln oder um Ausprägungen in Basis-, Mittel- und Premium-Varianten.
Beide platzieren wir rechts von der Mitte. Diese beiden Wege sind allein für das Grundverständnis sehr wichtig, denn darüber schafft ein System den essentiellen Wert für den Kunden.
Key Features, Key Components und Schnittstellen
Im mittleren Teil auf der linken Seite des System Footprints setzen wir zwei Aspekte, die den Nutzen erzeugen können: Zum einen die Key-Features bzw. die Hauptfunktionalitäten, die auch in Use-Cases sichtbar werden, und zum anderen die Key Components, also die Hauptkomponenten des Systems. Diese können mechanische, elektronische oder auch Software-Komponenten sein, in denen die Key Features ja häufig verhaftet werden.
Nichtsdestotrotz ist das keine architektonische Vorgabe. Vielmehr ist es oft so, dass es neue Features gibt – schließlich handelt es sich häufig um Entwicklungsprojekte, die noch nicht zwingend ein eigenes Key-Component als „Zuhause“ finden.
Dennoch ist diese Trennung wichtig, weil wir aus den Key-Components ja auch die Haupt-Liefereinheiten, die Key-Deliverables darstellen können. Wir können also sagen: „Okay, hier gibt es diesen ABC-Musterstand und da werden diese Key-Components und diese Features einfließen.“
Gleichzeitig kann es diese Ausprägungen für den Markt geben – beispielsweise Basis, Medium, Premium oder Ähnliches -, hierbei sind die Komponenten ebenso notwendig.
Links neben diesem linken Mittelteil finden wir schließlich die Interfaces – also die Schnittstellen des Systems. In jedem Workshop machen wir auch eine große Systemabgrenzung und definieren, was drin und was draußen ist.
Dies ist einer der Schritte, die häufig vergessen werden. Ich kann hier nur nochmals bekräftigen, wie wichtig diese Abgrenzung des Systems und die dazugehörigen Schnittstellen sind.
Der System Footprint im Feinschliff
Das Besondere an diesen Teilen ist, dass wir von links nach rechts quasi einen Wertstrom erstellen: Wir schaffen ein Nutzerversprechen über die Anwendungsfälle und die Liefereinheiten an den Kunden, während wir gleichzeitig dieses Nutzerversprechen über die Schnittstellen, die Features und die Komponenten, also die Funktionen und die Komponenten, erzeugen.
In der Fortentwicklung des System Footprints habe ich die Dimensionen hierbei ein wenig angepasst und die Value-Proposition verkleinert, sodass ich maximal vier Post-Its einfügen kann. In der alten Form war die Value-Proposition in der Mitte ein ziemlich großer Bereich, mit dem die Verlockung wuchs, hier sehr viele Post-Ist einzufügen. Meine Erfahrung über die Jahre ist jedoch, dass zwei, drei Value-Propositions im Kern die beschreibenden Inhalte für ein System abbilden können.
Dies hat zwar die Diskussion um die Value-Proposition noch mal deutlich verschärft, weil ich keinen fünften Post-It zulasse, aber meine Gegenfrage lautet dann: „Wie viele echte KERN-Nutzenversprechen kann es denn realistisch geben?“ Weniger ist auch in diesem Fall mehr.
Alle relevanten Anforderungen in 3 Stunden finden
Du brauchst eine Übersicht über die Anforderungen an Dein Produkt.
Vereinbare mit mir ein erstes Gespräch – absolut kostenlos!
5 Schritte zur erfolgreichen Systemabgrenzung im Lastenheft
Eine erfolgreiche Systemabgrenzung hilft im Lastenheft zu entscheiden, wo drinnen und wo draußen ist.
Ein System existiert niemals alleine, sondern interagiert immer mit anderen Systemen oder Menschen. Die Grenzen zeigen uns, was im System drinnen und draußen ist. Gleichzeitig ermöglicht uns die Systemgrenze auch, die Schnittstellen des Systems zu identifizieren und festzulegen, was über die Systemgrenzen hinweg ausgetauscht wird. Schnittstellen sind der entscheidende Faktor in einem System.
Oft werden Schnittstellen nicht richtig identifiziert und dann auch nicht richtig bedient. Das führt häufig zu schweren Systemfehlern, die dann aber oft auch nicht so einfach berichtigt werden können.
Ich nutze bei der Erstellung der Systemabgrenzung fünf Schritte:
Definiere, was draußen und was drinnen ist
Entscheidend für das Systemverständnis ist zu wissen, was zum System gehört. Auch wenn viele Entwickler meinen zu wissen, was zum System gehört, ist in den Projekten die klare Abgrenzung nicht vorhanden.
In diesem Schritt verschaffe ich mir einen Überblick über alle Komponenten und (Teil-) Systeme auf der obersten Ebene. Dazu nutze ich ein Whiteboard und Post-Its. Auf dem Whiteboard zeichne ich ein großes Rechteck und klebe die Post-Its in das Rechteck, wenn ich diese Komponenten oder Teilsystem als intern definiere. Wenn das System als externes System definiert wird, dann klebe ich es außerhalb des Rechtecks auf.
Als Quellen dienen mir der Systems Footprint und die Notizen aus der Analyse der alter Dokumente wie z.B. Lasten- und Pflichtenhefte vorheriger Systeme. So erhalte ich langsam einen Ãœberblick und kann entscheiden, wie die erste grobe Systemabgrenzung aussehen muss.
Gruppiere die externen Systeme
Durch den ersten Schritt habe ich nun alle externeren Systeme als Post-Its außen um das Rechteck aufgeklebt. Nun beginne ich, die Zettel nach einem ersten Schema zu gruppieren. Beispielsweise alle Systeme, die für die Fahrdynamik zuständig sind. Oder alle Systeme, die zur Erweiterung eines Systems hinzugekauft werden können. Wie Sie die Gruppierung durchführen, hängt von Ihrem System ab. Es gibt hier kein Richtig oder Falsch. Bei mir ist oft die zweite oder dritte Version deutlich unterschieden vom ersten Entwurf. Wichtig ist, dass Sie mit der Gruppierung beginnen und Muster dafür finden.
Definiere die Schnittstellen auf einer groben Ebene
In diesem Schritt zeige ich die Schnittstellen auf, die zwischen dem eigenen System und den externen Systemen existieren. Dazu nutze ich Boardmaker in drei verschiedenen Farben, um die vier Grundtypen für Systemschnittstellen (Austausch von Information, Energie oder Stoffen und Störungen) darzustellen. Ich zeichne eine Linie zwischen dem eigenen und dem externen System in der jeweiligen Farbe. Gibt es mehrere unterschiedliche Schnittstellen, dann zeichne ich mehrere unterschiedlich farbige Linien. Am Ende der Linien zeichne ich Pfeilspitzen. Je nach Richtung der Schnittstelle zeichne ich eine oder zwei Pfeilspitzen an die Linie.
Visualisiere das Ergebnis
Im letzten Schritt geht es darum, das Ergebnis vom Whiteboard zu übertragen und für die nächsten Schritte nutzbar zu machen. Ich übertrage das Ergebnis gerne in ein SysML Schaubild. Wer kein SysML kennt oder kein Werkzeug dafür hat, kann auch hervorragend Powerpoint dafür nutzen. Welches Werkzeug Sie nutzen, ist am Ende des Tages egal. Auf den Inhalt kommt es an.
Systemabgrenzung reviewen
Reviews sind ein wichtiger Schritt während des Entwicklungsprojekts. Sie sind meiner Erfahrung nach eine Geheimwaffe, mit der früh Fehler oder Verständnisprobleme abgefangen werden können.
Nehmen Sie sich Ihre Systemabgrenzung und suchen Sie sich ein oder mehrere Kollegen, die Ihnen ein Feedback geben können.
Seien Sie nicht überrascht, wenn Ihre späteren Versionen der Systemabgrenzung anders aussehen als die erste Version. Die Rückmeldungen durch die Kollegen sind wichtig und führen bei mir oft zu einer neuen Version, mit denen ich mich Schritt für Schritt einem guten Ergebnis nähere. Ich habe noch nie erlebt, dass meine dritte oder vierte Version der Systemabgrenzung noch genau so aussah, wie mein erster Wurf.
Systemfunktionen identifizieren
Die Funktionen eines Systems sind entscheidend für die Erzeugung eines Nutzens für den Kunden. Dabei ist egal, ob die Funktion über Software, Hardware oder Konstruktion umgesetzt wird. Deshalb ist es wichtig, die Systemfunktionen zu identifizieren.
Wenn ich mich mit der Erstellung eines Lastenheft beschäftige, ist es für mich zunächst entscheidend zu verstehen, welche Funktionen ein System benötigt. Dazu habe ich den ersten Schritt mit dem System Footprint gemacht. Nun habe ich die Lasten aus Sicht des Kunden analysiert und einen sehr detaillierten Überblick, welche Funktionen das System benötigt, gewonnen.
Ich nutze dazu wieder Post-Its und klebe jede Funktion des Systems auf ein Whiteboard oder ein Flip-Chart. Anschließend gruppiere ich die Post-Its zu logischen Einheiten. Dabei versuche ich, möglichst nur die Problemsicht zu betrachten und keine Lösungssicht einzunehmen. Damit schaffe ich die Voraussetzung, die Struktur des Lastenheft möglichst unabhängig von der Lösung abzubilden. Anschließend klebe ich die Post-Its mit auf den System Footprint und erzeuge eine neue Version.
Verschaffe Dir einen Überblick über die relevanten Funktionen deines Systems. Nutze dazu den System Footprint und das Wissen, das Du aus der Arbeit mit den Lastenheften gewonnen hast.
So einfach, wie dieser Schritt klingt, so schwer kann er manchmal sein. Er ist aber für die spätere Erstellung eines Lastenheft unbedingt notwendig. Nur so kann die Struktur möglichst nachvollziehbar abgebildet werden. Auch für die späteren Änderungen an dem Lastenheft ist dieser Schritt wesentlich, denn so kann jederzeit eine Änderung einer Funktion zugeordnet werden.
Aus der Praxis für die Praxis: Der System Footprint in der Anwendung
Poster oder Beamer-Bild
Die Vorlage zum System Footprint findet Ihr in der Online-Bibliothek, dort könnt Ihr sie einfach herunterladen.
Wenn Ihr die Canvas ausdruckt, verwendet ruhig einen DIN-A0-Ausdruck. Das mag zunächst riesig klingen, aber es verschafft Euch eine sehr effektive Übersicht und zudem genug Raum, um Eure Inhalte auch wirklich unterzubringen. Dafür braucht Ihr nur eine passende Wand.
Alternativ könnt Ihr auch einen Beamer verwenden und den System Footprint als pdf-Datei an die Wand projizieren. Die Post-Its bzw. Sticky Notes (siehe weiter unten) heftet Ihr dann einfach an die Wand in die „virtuellen“, nur visualisierten Felder.
Bei dem Posterdruck liegt der Vorteil darin, dass Ihr das Ganze nach Beendigung einfach zusammenrollen und mitnehmen könnt – der erste Dokumentationsschritt ist sozusagen inklusive und den Rest könnt Ihr später erledigen.
Bei der Arbeit mit dem Beamer müsst Ihr unbedingt daran denken, Fotos von Eurem Footprint zu erstellen, da Ihr nach Beendigung des Workshops oder Meetings die Projektion beendet und die Zettel abnehmt.
Fotos können manchmal zu einem Problem werden, das wissen alle, die mit Geheimhaltungsregeln in Entwicklungszentren und ähnlichen Institutionen oder Projekten gearbeitet haben. Klärt dies im Vorfeld oder verwendet im Zweifelsfall das ausgedruckte Poster, um auf der sicheren Seite zu sein.
Zettelwirtschaft mit System
Für die Befüllung bietet es sich extrem an, Klebezettel – bekannter als Post-Its – zu nehmen. Mein Durchsatz bei System-Footprint-Workshops wie auch bei meinen Moderationstätigkeiten ist extrem hoch, aber mit diesen kleinen Zetteln kann ich wunderbar flexibel arbeiten:
Einfach einen nehmen, etwas draufschreiben, drankleben, fertig. Umpositionieren, inhaltlich auffüllen, übereinander kleben, abnehmen – all das funktioniert einfach und schnell und ist besonders für die Arbeit in Teams sehr wertvoll: Bei Diskussionen und Klärungen von Problemen müssen die Materialien flexibel bleiben.
Es gibt eine feine „Premium-Variante“ der klassischen Post-Its mit den Klebestreifen oben auf der Rückseite: Die sogenannten „Sticky Notes“ sind Zettel, die nicht mit Kleber haften, sondern sich dank ihrer statischen Aufladung an diverse Untergründe wie z.B. Fenster, Wände etc. binden.
Das sind sehr coole kleine Dinger, die natürlich auch leicht wieder zu entfernen sind. Diese „Statty Notes“ sind kein Massenprodukt und etwas teurer als die üblichen Post-Its, aber ich kann sie dennoch nur empfehlen. Hier könnt Ihr sie finden: www.stattys.com
Sie halten wesentlich besser auf unterschiedlichen Untergründen als Post-Its – und nichts ist ärgerlicher, als wenn die Zettel plötzlich nicht mehr an ihrem Platz bleiben, sondern alle herunterpurzeln, weil die Oberfläche für Kleber nicht geeignet oder es zu warm geworden ist.
Stifte mit Reichweite
Ebenso solltet Ihr die Vorteile guter Stifte nicht unterschätzen – und diese müssen überhaupt nicht teuer sein. Ich nutze klassische Filzstifte (wie meine Kinder), die es außerdem noch häufig im Angebot gibt. Die haben eine dünne und eine dickere Spitze an je einem Ende und können also multifunktional eingesetzt werden.
Verwendet bitte keine Bleistifte, Kugelschreiber oder ähnliches, das funktioniert alles nicht, wenn mehr als zwei Leute das Ganze auch wirklich lesen können sollen. Erspart Euch den Ärger und den Frust der ewigen Nachfragen und nutzt die Filzstifte.
Lastenhefte analysieren
Lastenhefte analysieren – ein wichtiges Puzzlestück in der Entwicklung, um zu verstehen, was der Kunde sich wünscht. Denn Lastenhefte beschreiben das „Wünsch-dir-was“ eines Kunden.
Entsprechend der DIN 69901-5 sind Lastenhefte die „vom Auftraggeber festgelegte Gesamtheit der Forderungen an die Lieferungen und Leistungen eines Auftragnehmers innerhalb eines Auftrages“.
Nun begebe ich mich daran, die vorhandenen Lastenhefte zu bewerten. Diese Bewertung ist notwendig, um genau zu beurteilen, was aus dem „Wünsch-dir-was“ des Kunden wirklich für das Projekt relevant ist. Gerade dann, wenn es darum geht, dass oftmals Lastenhefte im Nachhinein aktualisiert werden, ist die Bewertung des jetzigen Stands der Lastenhefte wichtig, um mit dem Kunden bei Änderungen auf Augenhöhe sprechen zu können. Dazu gehe ich folgendermaßen vor:
Alle Lasten verfügbar machen
In diesem Schritt bringe ich alle gefundenen Lastenhefte, Informationen, Präsentationen, Dokumente, Normen und so weiter in das Requirement-Management-Werkzeug. Falls schon Module vorhanden sind, dann bringe ich diese in einem gemeinsamen Ordner für die Lasten unter. Für jedes noch nicht vorhandene Artefakt lege ich ein eigenes Modul in dem gemeinsamen Ordner an.
Je nach Werkzeug kann diese Aufgabe einfach oder komplizierter werden. Oft ist dieser erste Schritt ziemlich zeitraubend. Falls ich zu viele Artefakte habe, die noch nicht im Werkzeug verfügbar sind, nehme ich mir im ersten Durchlauf die wichtigsten Artefakte und bringe sie in das Werkzeug.
Anschließend schaue ich, ob für die Anforderungen in den Modulen auch eine entsprechende Nummerierung vorgenommen worden ist. Diese Nummerierung ist wichtig, um später auf eine Anforderung wieder Bezug nehmen zu können.
Die notwendigen Attribute für eine Bewertung einfügen
Ich nutze fünf Attribute, um die Anforderungen zu bewerten. Wenn die Attribute noch nicht vorhanden sind, füge ich sie ein:
Typ: Mit diesem Attribut lege ich fest, welchen Typ die Anforderung besitzt.
Die von mir verwendeten Typen sind:
- Heading = Identifiziert eine Ãœberschrift,
- Req = Identifiziert eine Anforderung,
- ReqInfo = Identifiziert eine Information zu einer Anforderung,
- DocInfo = Identifiziert eine Information zum vorliegenden Dokument.
Domäne: Mit diesem Attribut lege ich fest, in welchen fachlichen Bereich die Anforderung fällt. Dabei kann ich auch mehrere Bereiche auswählen.
Die Domänen sind:
- Project = Anforderungen, die das Projekt und nicht das System betreffen,
- System = Anforderungen, die das System als Ganzes betreffen,
- Mechanic = Anforderungen, die die Mechanik betreffen,
- Hardware = Anforderungen, die die Hardware betreffen,
- Software = Anforderungen, die die Software betreffen,
- Testing = Anforderungen, die den Testbereich betreffen.
Status: Mit diesem Attribut lege ich fest, in welchem Status die Bearbeitung der Anforderung ist.
Die Werte sind:
- n/a = noch nicht begonnen,
- in review = in der Bewertung,
- in Klärung = Anforderung wird gerade geklärt,
- geschlossen = Bewertung abgeschlossen.
Bewertung: Mit diesem Attribut dokumentiere ich die Entscheidung zu der Anforderung.
Die Werte sind:
- akzeptiert = die Anforderung wird akzeptiert,
- teilweise akzeptiert = Die Anforderung kann nur in Teilen akzeptiert werden,
- abgelehnt = Die Anforderung wird abgelehnt.
Kommentar: Je nach Anforderung und Bewertung kann ich hier noch als Klartext einen Kommentar einfügen.
Die Bewertung vornehmen
Jetzt bewerte ich die Anforderungen und setze die von mir angelegten Attribute.
Falls ich zu viele Anforderungen zu bewerten habe, dann nehme ich mir im ersten Durchlauf die wichtigsten Anforderungen und gehe sie durch. Alternativ binde ich zur Bewertung auch die Fachkollegen mit ein. Das geht besonders gut, wenn die Artefakte nach dem fachlichen Schwerpunkt organisiert sind. Beispielsweise kann das Lastenheft für die mechanischen Komponenten auch ein Konstrukteur bewerten.
Offene Fragen dokumentieren
Mit dem Attribut „Status“ kann ich nun die offenen Fragen herausziehen, in dem ich nach dem Wert „in Klärung“ filtere. Das Ergebnis schicke ich als entsprechende Mail an die Kollegen, die mir dazu eine Rückmeldung geben können.#
Den aktuellen Stand versionieren
Wenn ich diesen Schritt abgeschlossen habe, versioniere ich das Ergebnis mit einer Baseline. Dieser Schritt ist wichtig, um später bei Änderungen die alten Ergebnisse nachvollziehen zu können.
Ich brauche ein professionelles Lastenheft
Du möchtest das Risiko in Deinem Projekt signifikant senken?
Vereinbare einen Termin mit mir und ich helfe Dir mit meinem erprobten Prozess. Du erhältst in 2 Wochen ein Lastenheft.
