Beiträge

Spezifikationen: Problembewusstsein schaffen – und Lösungen finden

In diesem Beitrag möchte ich auf die Frage eingehen, wie Projekte mit dem Problem der vielen, aber kaum gelesenen Spezifikationen umgehen – und wie sie damit umgehen sollten.

Welche Spezifikationen? Oder: Duck an cover

Den ersten und häufigsten Weg nenne ich gerne „duck and cover“ nach dem amerikanischen Spruch aus dem kalten Krieg. Diese Variante liegt in zwei Ausprägungen vor.

Aus Last mach Pflicht – Variante I

Die eine Ausprägung: Man nehme sich das Lastenheft, kopiere stumpf einfach alles – und schreibe darüber „Pflichtenheft“. Das habe ich als Troubleshooter in einem Projekt gehabt und schließlich gefragt: „Wie ist eigentlich diese Systems-Requirements-Specification entstanden?“ „Die ist aus dem Lastenheft kopiert. Wir haben keine Zeit und es sind viel zu viele Anforderungen.“

Das waren in der Tat 40.000 Anforderungen. Ich bin das durchgegangen, habe das analysiert und schnell zeigte sich, dass sie damit auch alle nicht-technischen Projektanforderungen kopiert haben – inklusive einiger unsinniger Anforderungen … Damit haben sie gleichzeitig akzeptiert, was dort drinsteht – und einfach weggeschaut.

In einem anderen Fall hatte ein klassisches, mittelständisches Maschinenbau-Unternehmen ihr System entwickelt, nämlich das, was auf der technischen Zeichnung stand, das waren ja die Anforderungen.

Die Probleme mit einem Teilsystem, das im Feld Schwierigkeiten machte, waren dann groß, denn Elektronik und Software, die mit verbaut waren, hat keiner richtig betrachtet. Und es gab auch kein Lastenheft, denn niemanden interessierte das – bis ich hinzukam. Für sie war es eher überflüssiger Ballast. Sie haben sich geduckt und gehofft, dass der Sturm an ihnen vorbeizieht.

Das große Nichtstun – Variante II

Die zweite Variante sehe ich häufiger bei kleinen und mittelständischen Unternehmen: Einfach gar nichts machen.

Diesen Fall habe ich mit absolut extensiven Spezifikationen bei einem Elektromobilitäts-Projekt erlebt. In der Vorprojektphase brachte der Hersteller ein 600-Seiten starkes Dokument und sagte, dies seien die Spezifikationen.

Parallel waren damit auch viele Widersprüchlichkeit verbunden, denn in der Automobilindustrie wird heutzutage regelrecht in einem Lego-Schema gearbeitet, vieles ist also „reused“. Das ist generell ein großes Thema, weil oft einfach mehrere Bauteile zusammengesteckt werden und ein Lastenheft ergeben sollen und zwar ein extrem ausführliches – das niemand lesen will.

Da wir zudem in einem Innovations-Projekt saßen, hatte gerade mal ein gefühltes Drittel überhaupt Relevanz für uns. Die anderen zwei Drittel dieses Lastenheftes waren zwar da und wir mussten die durchgehen, aber im Grunde konnten wir das hinterher alles komplett wegkehren.

Wirklich hinschauen – die Visualisierung der Spezifikationen

Der dritte Weg, der sich nun mehr und mehr durchsetzt, ist, die Anforderungen erstmal zu visualisieren und sich ein Gesamtbild zu machen.

Ich habe als Mentor in vielen Projekten genau das gemacht: Wir haben den System Footprint aufgehängt, die unterschiedlichsten Spezialisten und auch Bereiche wie Marketing, Vertrieb, Produktmanagement etc. eingeladen und sind gemeinsam durch diesen Footprint gegangen.

Durch diese Visualisierung wird allen erstmal bewusst, was die Anforderungen an dieses gesamte System sind. Wenn ich dann eine Spezifikation lese, habe ich dieses Bild auch im Kopf. Das ist einer der großen Gewinne daran – und dass es für alle funktioniert.

In einem Projekt beispielsweise was es für das Marketing sehr wichtig. Diese Abteilung gab sehr viele Anforderungen mit hinein, doch mit dem Footprint hat das alles wunderbar funktioniert. Er wird dort mittlerweile in den ganzen Business Units eingesetzt und die Unternehmensführung weiß, dass es für sie ein extrem wertvolles Mittel ist.

Es ersetzt keine Spezifikationen, das ist ganz wichtig, es visualisiert diese nur. Aber dann lässt sich mit ihnen auch arbeiten.

Der System Footprint – Aufbau und Inhalt

Im letzten Beitrag habe ich die Entwicklungsgeschichte des System Footprints beschrieben. Nun möchte ich mehr in die Tiefe gehen und erläutern, wie das Ganze funktioniert. Zunächst gehe ich im Detail darauf ein, wie der System Footprint aufgebaut ist.

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 Key-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 die Value-Proposition über die Use-Cases und die Liefereinheiten an den Kunden, während wir gleichzeitig dieses Nutzerversprechen über die Schnittstellen, die Features und die Components, 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.

 

Spezifikationen: Essentiell – und ungelesen

Warum werden Spezifikationen oft nicht gelesen? Alle wissen, dass sie essentiell sind, dennoch befinden wir uns häufig in Situationen, in denen plötzlich niemand weiß, worum es geht. Weiterlesen

Requirement Engineering für komplexe Systeme – Teil I

In diesem Beitrag möchte ich auf die Frage eingehen, warum Requirement Engineering für komplexe Systeme so wichtig ist. Hierfür erläutere ich zunächst die ersten großen Schwierigkeiten in solchen Situationen: Das fehlende Lastenheft und die fehlende Trennung zwischen System- und Projekt-Anforderungen. Weiterlesen

Zwei völlig unterschiedliche Dokumente: Lastenheft vs. Pflichtenheft

Mehrfach durfte ich schon die Erfahrung machen, dass in Projekten nicht allen klar war, was der Unterschied zwischen Lastenheften und Pflichtenheften ist – und warum beide in einem Projekt erstellt werden sollten.

Von Äpfeln und Birnen

Häufig werden diese beiden Dokumente durcheinandergeworfen. Dabei haben Lastenhefte und Pflichtenhefte sehr unterschiedliche und sehr wichtige Zwecke, wenn es darum geht, ein System zu entwickeln. Leider habe ich viele Projekte erlebt, die entweder kein Lastenheft angelegt hatten oder sich das Pflichtenheft sparen wollten.

Im extremsten Fall wird versucht, beide zu vereinen, sodass ein Lastenheft gleichzeitig auch das Pflichtenheft darstellen soll. Ich habe tatsächlich erlebt, dass diese zwei Dokumente sich einzig durch die Farbe der Sätze voneinander unterschieden. Das ist eine Katastrophe und führt mit Sicherheit zu nicht lösbaren Schwierigkeiten. Weiterlesen

Requirements-Engineering mit Word und Excel – Teil III

Klickt auf die Links, um den ersten und zweiten Teil dieser Reihe zum Requirements-Engineering mit Word und Excel zu lesen.

Kommen wir in diesem Teil der Reihe nun auf die Organisation der Spezifikationen zu sprechen. Bei diesem Thema kommen fast automatisch die entsprechenden Tools ins Spiel. Meine erste Empfehlung vorweg:

Besser Word anstelle von Excel verwenden!

Wenn ihr keine Requirements-Engineering-Werkzeuge habt, nutzt lieber Word als Excel. Mit jahrelanger Erfahrung möchte ich mich wirklich nachdrücklich dafür aussprechen.

Der Hintergrund ist relativ einfach. Man kann in Excel zwar recht schnell viele (Unter-)Tabellen produzieren und gleichzeitig über diverse Makros auch noch eine „Pseudo-Traceability“ einbauen. Doch meiner Meinung nach geht Excel an dieser Stelle auch ganz schnell nach hinten los.

Es gibt zunächst einen ganz pragmatischen Grund, warum Excel nicht gut funktioniert: Wir können keine Bilder in die Excel-Tabellen kopieren. Wenn ich aber ein gutes beschreibendes Bild für mein System habe, ist es natürlich mehr als blöd, wenn ich es in der Spezifikation nicht darstellen kann.

Hinzu kommt, dass der Ausdruck bzw. der PDF-Export einer Excel-Tabelle beispielsweise für Kunden oder einen Dritten bedeutend aufwändiger ist als bei Word. Daher also meine Empfehlung aus der Praxis: Nutzt lieber Word, dort könnt ihr schließlich auch mit Spalten arbeiten.

Modularisierung der Spezifikationen

Meine zweite große Empfehlung: Eine Modularisierung. Versucht, eure Spezifikationen zu modularisieren. Nehmt ein Word-Dokument und sammelt dort das Inhaltsverzeichnis und alle dokumentenspezifischen Informationen für die Spezifikation.

Legt zudem eigene Doc-Files für die ganzen relevanten einzelnen Kapitel an. Nehmt euch dafür ein wenig Zeit und schaut mit Sinn und Verstand, was zusammen in ein Word-Dokument gehört. Nicht jedes Unterkapitel gehört hier in ein Doc-File, doch clever aufbereitet ist dieser modulare Aufbau sehr wertvoll.

Das Ganze hat zwei große Vorteile: Zum einen können mehrere Kollegen gleichzeitig an unterschiedlichen Kapiteln arbeiten, ohne dass sie sich gegenseitig behindern, alles doppeln und hinterher alle Änderungen aufwändig in einem Dokument zusammenführen müssen.

Zweitens ist Word so deutlich schneller. Gerade wenn ihr diese Dateien auf einem Firmen-Netzlaufwerk liegen habt, kann es sehr mühselig sein, ein 20 oder 30 Megabyte großes Word-Dokument überhaupt zu öffnen. Mit den Kapitel-Dokumenten habt ihr wesentlich angenehmere Größen und könnt flexibler arbeiten.

“Versionierung”

Modularisierung macht also extrem viel Sinn. Ein weiterer Aspekt, der damit zusammenhängt, ist die „Versionierung“, also die Nachverfolgung der Text-Revisionen: Achtet darauf, dass ihr bei euren Files immer die Möglichkeit habt, alte Stände wieder zurückzuholen!

Das hat den großen Vorteil, dass ihr zu jedem Zeitpunkt schauen könnt, wann ihr ein Requirement entfernt oder warum ihr ein neues hinzugefügt habt. Gleichzeitig habt ihr natürlich auch Sicherungskopien, wenn diese Form des Versionen-Managements auf euren Servern bzw. in eurer Firmen-Infrastruktur liegt und Backups produziert werden.

Wie ihr dieses Management handhabt, kann variieren. Das Einfachste ist, alles über Subversion und entsprechende Free Tools abzubilden. Das integriert sich sehr schön in die klassische Explorer-Sicht von Windows oder in den Finder auf Macs.

Damit habt ihr die Möglichkeit, alles effizient zu versionieren und müsst zudem jedes Mal ein- und auschecken, sodass ihr auch Kommentare hinterlassen und erläutern könnt, warum es diese neue Version gibt, welche Änderungen vorliegen etc.

Vergleichbarkeit der Strukturen

Ein weiterer Vorteil dieser Organisation von Spezifikationen ist die Vergleichbarkeit der Strukturen – wenn diese gut abgesprochen sind. Ich kann nur empfehlen, eine einheitliche Dokumentenstruktur zu vereinbaren. So bleiben alle Files ähnlich und werden auch gleich verständlich sein.

Ihr könnt hierfür gerne die Templates für die System-Requirements und System-Architecture-Spezifikationen nehmen, die ich in den Podcast-Episode 29 und Episode 30 online gestellt habe. Passt diese einfach für eure Bedürfnisse an.

Wenn Vergleichbarkeit vorliegt, könnt ihr eure Erfahrungen auch mit anderen Teams austauschen. Wenn ihr beispielsweise immer das gleiche Kapitel zu einer Basistechnologie habt, die ihr über alle verschiedenen Produkte in eurem Unternehmen einsetzt, dann könnt ihr dieses als feste Grundlage verwenden: „Das ist unser Kapitel für die Anforderungen an die Basistechnologie XY. Alle verweisen immer auf dieses Kapitel und verändern es nur gemeinsam.“

Schließlich hat diese Vergleichbarkeit auch den Vorteil, dass Kollegen, die das reviewen, es viel schneller verstehen, weil sie die Struktur und den Sinn dahinter kennen.

Im nächsten Teil werden wir uns mit den Tabellenformen in Word beschäftigen.

Requirements-Engineering mit Word und Excel – Teil II

Den ersten Teil zum Thema Requirements-Engineering könnt ihr hier lesen.

Im letzten Beitrag habe ich bereits die Aspekte erwähnt, die für eine handlungsorientierte Antwort auf die generelle Frage, welche Spezifikationen nötig sind, eine Rolle spielen.

Diese waren die Komplexität des Systems, ein Lastenheft vom Kunden oder dem Produktmanagement, Vorgaben durch Normen und wie intensiv das Thema im Unternehmen aufgegriffen wird. Daraus können wir die eine entscheidende Antwort zu den Spezifikationen generieren.

Auch wenn mich die Qualitätsmanagementbeauftragten aus meiner Branche jetzt gerne erschlagen würden: Der Alltag hat vielfach gezeigt, dass ein Lastenheft und eine System-Architektur-Spezifikation zunächst ausreichen.

Mir ist bewusst, dass auch die anderen Spezifikationen sehr relevant sind. Dennoch sind die beiden gerade genannten die Wichtigsten, und ich möchte in diesem Beitrag erläutern, warum.

Spezifikation I: Das Lastenheft in der Problemsicht

Das Lastenheft ist die Vereinbarung mit Dritten, also mit Außenstehenden, über die Lasten an das System. Wie ich es gerne formuliere: Es ist das „Wünsch dir was“, welches ihr – je nach Größe eures Unternehmens – gemeinsam mit dem Kunden oder dem Produktmanagement erstellt.

Zudem ist das Lastenheft ein Dokument, das in der Problemsicht angesiedelt ist: Ihr schafft somit eine Spezifikation, die die Problembeschreibung beinhaltet. Und mit dieser vereinbart ihr gemeinsam und hundertprozentig, was genau ihr machen wollt.

Mit hundertprozentig meine ich, dass es so vollständig vereinbart ist, wie es zum Zeitpunkt der Erstellung möglich ist – mir ist bewusst, dass ein Lastenheft nicht zu 100% fertig sein kann, bevor man mit der Entwicklung beginnt.

Alle Spezifikationen – egal auf welcher Ebene und in welcher Sicht –, die in solchen komplexen Entwicklungsprojekten genutzt werden, sind lebende Dokumente. Sie entstehen am Anfang eines Projektes, das ein Jahr oder anderthalb Jahre Entwicklungszeit hat.

Wir kennen unsere Zukunft noch nicht: Nachdem wir die Spezifikationen definiert haben, werden wir oft mit technologisch neuen Ideen und Konzepten konfrontiert. Wir sind also ständig auch auf völlig neuem Terrain unterwegs.

Folglich werden die Spezifikationen auch mit uns wachsen und ihre Reife mit der Zeit steigern. Geht also nicht davon aus, dass euer Lastenheft zu Beginn schon hundertprozentig fertig ist – es muss nur zu 100% vereinbart werden, dass es für alle Beteiligten beim aktuellen Stand ausreichend gut und vollständig ist, um die Entwicklung zu starten.

Das ist also die erste wesentliche Spezifikation, die ich gerade kleinen und mittelständischen Unternehmen unbedingt ans Herz legen möchte: Das Lastenheft ist das wichtigste Dokument aus der Problemsicht.

Wie ihr dieses erstellt, könnt ihr z.B. in der Episode „Drei Wege im Umgang mit Lastenheften“ des ZukunftsArchitekten-Podcasts nachhören.

Spezifikation II: Die System-Architektur in der Lösungssicht

Die zweite Spezifikation ist die der System-Architektur. Diese beschreibt die Lösung – und ist damit meines Erachtens ebenso wichtig wie das Lastenheft. Es ist ein Dokument auf der Systemebene und zeigt das gesamte System, im mechatronischen Umfeld auch die Elektronik, die Software und die Mechanik, alle Domänen.

Es ist quasi die Blaupause dessen, was ihr entwickeln wollt, inklusive Requirements. Wenn wir also alle Prozesse durchgehen, wie es zum Beispiel in der Automobil-Branche üblich ist, dann entsteht dieses Dokument sozusagen automatisch.

Die Prozessschritte zwischen dem Lastenheft und der System-Architektur-Spezifikation beinhalten mehrere Spezifikationen. Aber für alle, die in einem kleinen oder mittelständischen Unternehmen sind und ein sehr überschaubares System vorliegen haben, ist die System-Architektur-Spezifikation für die konkrete Umsetzung ein entscheidendes Dokument, weil ihr damit das große Bild beschreibt.

Das Schöne an dieser System-Architektur-Spezifikation ist außerdem: Es ist das erste Dokument, was du schaffst, wenn diese gesamte Ebene eigentlich noch fehlt. Du produzierst damit im Prinzip die Beschreibung dessen, was zu entwickeln ist.

Aus meinen Erfahrungen im Troubleshooting-Bereich weiß ich, dass es wirklich wichtig ist und beispielsweise neuen Kollegen im Team enorm dabei hilft, sehr schnell zu verstehen, was eigentlich entwickelt werden soll.

Die zwei entscheidenden Spezifikationen, die ihr also unabhängig von vielen individuellen Gegebenheiten unbedingt braucht, sind das Lastenheft aus der Problemsicht und die System-Architektur-Spezifikation aus der Lösungssicht.

Wie genau ihr euer Requirements-Engineering mit Word und Excel organisieren könnt, werde ich im nächsten Teil näher beschreiben.

Requirements-Engineering mit Word und Excel – Teil I

Ich werde im Folgenden die vielen Fragen aufgreifen, die sich um Requirements Engineering mit Word und Excel drehen.

Immer wieder melden sich Leser, die in ihren Unternehmen die nötigen Anforderungen und Spezifikationen für Projekte schaffen, aber kein Requirements-Engineering-Werkzeug haben. Entsprechend versuchen sie, mit Word und Excel zu arbeiten, was nicht immer einfach ist – und weswegen ich die nächsten Beiträge diesem Thema widmen möchte.

Viele, gerade kleine und mittelständische Firmen haben für ihre Projekte oftmals keine aufwändigen und großen Requirements-Engineering-Tools, wie man sie aus komplexen Projekten kennt.

Diese Tools sind in der Regel recht teuer, oft sehr vielschichtig und relativ komplex zu bedienen. Also nutzen viele Unternehmen – beinahe „traditionell“ – die Word- oder auch Excel-Werkzeuge.

Hinzu kommt häufig, dass die fachliche Ausbildung in Sachen Requirements Engineering fehlt: Viele wissen schlicht nicht, was es bedeutet und wie relevant es ist. Entsprechend nehmen sie einfach das, was sie haben – in der Regel Microsoft Office – und versuchen, ihre Requirements damit zusammenzubauen.

Das Ziel dieser Episoden ist es, euch das nötige How-to und viele Tipps zu vermitteln, um eure Spezifikationen mit Word zu handhaben. Zunächst habe ich ein paar Begriffsklärungen und ein wenig Hintergrundwissen für Leser, die die vorangegangenen Beiträge noch nicht kennen.

Ebenen und Sichtweisen von Spezifikationen

Ein wichtiger Punkt bei Spezifikationen ist die Unterscheidung verschiedener Ebenen: Die oberste Ebene, das sogenannte Customer-Level, beinhaltet alle Lasten aus Sicht des Kunden oder der involvierten Kundengruppen.

Die zweite Ebene ist die System-Ebene. Das ist im Prinzip die Ebene, die das gesamte System betrachtet. Sie bietet einen sehr generellen Überblick über das System und die entsprechenden Requirements.

Dann gibt es noch die dritte Ebene, die sogenannte Technologie-Ebene, die beispielsweise Software, Elektronik oder Konstruktion meint.

Im Überblick: Die oberste Ebene gilt dem Kunden und meint die Spezifikationen, die die Anforderungen beinhalten. Die zweite Ebene meint das System, also die Spezifikationen, die die Architektur beinhalten. Und die dritte umfasst eben die Technologie-Spezifikationen.

Neben diesen drei Ebenen gibt es bei Spezifikationen auch noch zwei grundsätzliche und grundsätzlich verschiedene Sichtweisen. Die eine Sicht ist die sogenannte „Problemsicht“. Das ist im Prinzip eine Beschreibung der Anforderungen in Bezug auf das Problem, in der nur Funktionen und nicht funktionale Anforderungen festgehalten werden.

Die zweite Sicht ist die „Lösungssicht“. Hier beschreiben wir die Anforderungen bezogen auf die Lösung. Das ist also ein Dokument, in dem die Lösung, die Komponenten und welche Anforderungen diese Komponenten übernehmen, im Fokus stehen.

Wer noch mehr dazu wissen möchte: Ich habe zahlreiche Podcast-Episoden zu diesen Themen online gestellt, beispielsweise Episode sieben, „Lastenheft versus Pflichtenheft“. In den Episoden 29 und 30 gehe ich explizit auf die beiden Dokumente – auf die System-Requirements-Spezifikation und System-Architecture-Spezifikation – auf der System-Ebene ein.

Es gibt noch weitere Episoden, in denen ich auf Doors eingehe, also wie man Lastenhefte bewerten kann etc. Schaut einfach mal rein, wenn ihr sie noch nicht gehört habt.

Welche Spezifikationen sind notwendig?

Steigen wir nun also richtig ein: Ein besonders wichtiger Punkt sollte gut durchdacht werden: Welche Spezifikationen brauche ich? Wir haben schließlich die beiden Sichten Problem und Lösung und die Ebenen, das heißt also mindestens sechs verschiedene Spezifikationen, die eine Rolle spielen können.

Bei kleinen und mittelständischen Unternehmen ist die Frage, welche Spezifikationen benötigt werden, entscheidend. Wenn ich das gefragt werde, stelle ich den Firmen folgende Gegenfragen, um die Lösung zu fixieren.

Das Erste ist: Wie komplex ist das System? Reden wir über ein relativ klar abgegrenztes, überschaubares System oder ist es ein sehr komplexes, z.B. mit hohen Interaktionen zu anderen Systemen? Die Antwort auf diese Frage ist ein sehr guter erster Indikator für die nötigen Spezifikationen.

Das Zweite, was ich danach erfrage, ist: Gibt es überhaupt ein Lastenheft? Dies kann entweder von einem externen Kunden mitgebracht werden, der dann sagt, „genau das will ich haben“, oder aber es gibt ein Lastenheft vom Produktmanagement, Marketing, Vertrieb oder einer ähnlichen Abteilung. Die Entwicklung sagt hier also, „wir brauchen das, das und das für die zukünftige Generation unserer Produkte.“

Meine dritte Frage lautet: Welche Vorgaben liegen durch Normen vor? Je nach Kontext können diverse Normen einzuhalten sein, im Bereich Automotive oder Medizintechnik beispielsweise Safety- bzw. Sicherheitsnormen. In solchen Branchen werden also schon allein durch die Normen gewisse Spezifikationen definiert.

Und die letzte Frage ist: Wie oft betrifft Dich dieses Thema? Hast Du damit vielleicht alle sechs Monate zu tun, weil es ein sehr überschaubares System oder Produkt ist und Du vielleicht nur fünf Kollegen hast? Oder wird das Ganze kontinuierlich immer wieder sehr intensiv in die Entwicklung hineinspielen?

Im nächsten Teil beschreibe ich, wie ich mit diesen Fragen zu einer sehr pragmatischen Antwort auf die generelle Frage komme, welche Spezifikationen benötigt werden.

 

Episoden

SF009: Wie kann ich mein Anforderungsmanagement neu ausrichten?

22.09.2015 37 Minuten

On Air in dieser Episode

avatar Maik Pfingsten

In einem bestehenden Entwicklungsprojekt gibt es die Situation, das Anforderungsmanagement neu auszurichten. Ich gebe auf diese Frage meine 10 Tipps.

Ich habe eine Hörerfrage erhalten. Er hat die Situation, dass er in einem bestehenden, langfristigen Entwicklungsprojekt das Anforderungsmanagement neu ausrichten muss. Es geht um den Umgang mit vielen Anforderungen über eine lange Zeit, eine gute Strukturierung von Dokumenten bzw. Spezifikationen und den Einsatz von RE-Management-Tools. In dieser Episode erfährst du meine 10 Tipps, wie die typischen Probleme im RE/RM angehen kannst und ein paar Hinweise zu der Auswahl eines RE/RM Tools.

Wie kann ich mein Anforderungsmanagement neu ausrichten?

  • Tipp 1: Eine Meta-Ebene nutzen
  • Tipp 2: Releases müssen eingefroren werden
  • Tipp 3: Einsatz von Scripten
  • Tipp 4: Ohne Tracebility geht es leider nicht
  • Tipp 5: Aufräumen
  • Tipp 6: Vernünftige Werkzeuge, die das Unterstützen
  • Tipp 7: Festlegung von Begrifflichkeiten
  • Tipp 8: Abbildung der verschiedenen Ebenen und Sichten
  • Tipp 9: Detaillierung auf der richtigen Ebene halten
  • Tipp 10: Weitere Attribute nutzen