systems.camp OWL 2025 in Paderborn
Du willst dich mit anderen über agiles Systems Engineering, MBSE oder Architekturarbeit austauschen? Dann ist das systems.camp OWL im IoT Experience Center beim Heinz Nixdorf MuseumsForum in Paderborn genau das Richtige für dich!
Evolution statt Perfektion – Warum technische Systeme sich entwickeln sollten
In der letzten Oktober-Ausgabe in „Die Zeit“ wurde eine spannende Illustration veröffentlicht: die Entwicklung des Rades – von einer einfachen Walze hin zu einem ausgereiften Radsystem. Diese Evolution zeigt, dass Innovation oft nicht durch detaillierte Planung entsteht, sondern durch schrittweise Verbesserung. Doch genau dieses Prinzip wird in der heutigen Technikentwicklung oft ignoriert.
Lastenheft vs. Pflichtenheft – Was ist der Unterschied?
Immer wieder taucht die Frage auf: Was ist der Unterschied zwischen einem Lastenheft und einem Pflichtenheft? In der Welt des Systems Engineering gehört diese Unterscheidung zum Basiswissen
Kreislaufwirtschaft und Systems Engineering – Nachhaltigkeit neu denken
Die Kreislaufwirtschaft ist nicht nur ein Trend, sondern eine zukunftsweisende Herangehensweise an die Entwicklung technischer Systeme und Produkte.
Ganzheitliches Denken in der Krise – Warum wir umdenken müssen
Es reicht nicht, die Ursachen oberflächlich zu betrachten. Trockenheit, Erderwärmung, Klimawandel – all das sind keine neuen Phänomene
Kfz-Neuzulassungen im ersten Halbjahr 2024 in China: 40% Verbrenner und 60% E-Autos
Der Artikel diskutiert Deutschlands Tendenz, technologische Trends zu verschlafen, am Beispiel der E-Mobilität.
Die Rollen im Anforderungsmanagement
Neben den Anforderungsdokumenten haben wir auch noch die verschiedenen Rollen bei der Erstellung von Spezifikationen.
Auf der einen Seite haben wir den Kunden, der in seinem Lastenheft ein Problem beschreibt, das er gelöst haben will. Zusätzlich haben wir die Interessensgruppen, die ebenfalls ein Problem beschreiben, das sie allgemeingültig gelöst haben wollen.
Auf der anderen Seite haben wir das Projektteam mit jemandem, der sich mit dem ganzen Thema Requirements Engineering beschäftigt und versucht, überhaupt das Problem zu begreifen. Dann gibt es jemanden, der sich mit dem ganzen Systemdesign beschäftigt. Das ist jemand, der versucht, aus den Anforderungen eine Lösung zu definieren. Und dann haben wir einen Projektmanager, der halt in diesem ganzen Kontext noch versucht, das Team zum Erfolg zu führen.
Das zusammen ist genau die Schnittstelle, und wir sehen auch da: Auf der einen Seite liegen die Lastenhefte und auf der anderen Seite die Pflichtenhefte nach der klassischen Beschreibung.
Rollen im Anforderungsmanagement
Am Ende bilden die Rollen auch die Arbeitsergebnisse ab. Ein Requirements Engineer wird also die Anforderungsspezifikation (SRS) erschaffen. Ein Systemdesigner oder ein Systemarchitekt wird die Architekturspezifikation (SAS) schreiben, und der Projektmanager beschreibt in der Regel in seinem Projekthandbuch all die nichttechnischen Anforderungen an ein System.
Je komplexer Systeme werden oder je dynamischer ihre Funktion ist, desto wichtiger wird es, sich intensiv mit diesen Dokumenten und Spezifikationen zu beschäftigen. Ein System, das einen relativ einfachen Aufbau hat und auch keine großartige Dynamik besitzt, muss nicht in aller epischer Breite sämtliche oben beschriebenen Spezifikationen besitzen, wenn eigentlich klar ist, was wichtig ist. Das bedeutet aber, sie nicht komplett wegzulassen, sondern mit Sinn und Verstand nur das, was gebraucht wird, umzusetzen.
Je komplexer ein System wird oder gar je mehr Unterlieferanten dabei sind, also je mehr Menschen auch in diesem Projekt eingebunden sind, desto wichtiger werden Spezifikationen. Denn Spezifikationen sind am Ende nichts anderes als eine Dokumentation von Wissen.
Requirements-Engineering mit Word und Excel
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.
Ich werde im Folgenden die vielen Fragen aufgreifen, die sich um Requirements Engineering mit Word und Excel drehen.
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 KnowHow 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.