Beiträge

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 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