Vom Vertrag zu Anforderungen und erster Architektur

Chronologie: 22. September 2026 · sechste Veranstaltung. Primärquelle: vollständiges Transkript. Übergang: Die Pre-Sales-Phase endet; die Aufgaben der studentischen Teams verlagern sich von Vertrieb und Engagement zum Systems Engineering.

1. Wann ein Lead im Kursmodell zum Kunden wird

Die Vorlesung zieht eine didaktische Grenze: Solange es um Gespräche, RFI, RFQ, RFC und Angebote geht, besteht ein Lead oder eine Geschäftschance. Sobald rechtliche Dokumente und kommerzielle Ausgangsbedingungen vereinbart sind, beginnt die Kunden- beziehungsweise Projektbeziehung.

Redaktionelle Präzisierung 01

In tatsächlichen CRM-, Buchhaltungs- und Vertragsprozessen können Lead, Opportunity, Prospect, Customer und Client unterschiedlich abgegrenzt sein. Ebenso muss einen Vertrag nicht zwingend eine Führungskraft des C-Levels unterzeichnen: Die Zeichnungsberechtigung bestimmt das jeweilige Unternehmen. „Unterschriebene Vereinbarung → Kunde“ ist in diesem Kurs ein hilfreiches Lehrmodell, keine universelle rechtliche Definition.

2. Personalvorlauf bereits im Angebot berücksichtigen

Ein unterzeichneter Vertrag erzeugt nicht augenblicklich ein Team. Hardware-, Firmware- und Systemrollen können lange Rekrutierungs- und Einarbeitungszeiten benötigen. Vor Projektbeginn sind deshalb zu dokumentieren:

• der frühestmögliche Starttermin;
• Annahmen zur Personalbesetzung;
• welche Personen bereits verfügbar sind;
• welche Rollen noch besetzt oder zugewiesen werden müssen;
• Abhängigkeiten von Kundenzugang, Hardware, Benutzerkonten und Dokumenten;
• was geschieht, wenn diese Voraussetzungen verspätet vorliegen.

Praktischer Grundsatz: Keinen Projektstart für Montag versprechen, wenn am Donnerstag das Team noch gar nicht existiert.

3. Das Kernteam bereits während des Pre-Sales aufbauen

Für Kontinuität sorgen am besten jene Personen, die sich bereits in der Pre-Sales-Phase mit der Problemstellung befasst haben:

• Architekt / Systemingenieur;
• Technical Lead oder mehrere Technical Leads;
• Engineering- / Delivery-Manager;
• Domänenexperten.

Diese Rollen bilden den Kern. Anschließend wird das Team passend zum tatsächlichen Umfang erweitert.

Pre-Sales-Kernteam
          ↓
Vertrag
          ↓
bestehendes Kernteam + neu zugewiesene Fachkräfte
          ↓
Delivery-Team

4. Eine wichtige Realität: Discovery nach Vertragsabschluss kann die Lage verändern

Die Vorlesung beschreibt Situationen, in denen ein Kunde vor Vertragsabschluss einen Teil des Kontexts zurückhält oder die Pre-Sales-Aufgabe zur Bewertung der Kompetenz nutzt. Die tatsächlichen ersten Eingaben der Lieferphase können daher von der ursprünglichen Problembeschreibung abweichen.

Die richtige Reaktion ist weder gekränkt zu sein noch einen veralteten Angebotsentwurf einfach zu implementieren. Stattdessen müssen Umfang, Annahmen und Lücken neu abgestimmt werden.

Das ist ein weiterer Grund für Rückverfolgbarkeit und Änderungssteuerung.

5. Lehrfall: Roboter zur automatisierten Prüfung von Leiterplatten

Der Kundeninput wird in der Vorlesung absichtlich als lange, teilweise strukturierte mündliche Beschreibung gegeben. Das Systemkonzept umfasst:

• einen handelsüblichen Roboterarm mit sechs Freiheitsgraden;
• einen kundenspezifischen Endeffektor;
• drei Methoden zur Objektinteraktion: elektromagnetische Aufnahme, mechanischer Greifer und Kontaktprüfmatrix;
• automatische Werkzeugwahl und Ausrichtung;
• Steuerung und Rechentechnik;
• maschinelles Sehen / Computer Vision;
• Netzwerkkommunikation;
• Integration von ROS 2;
• Berichte und Cloud-Speicherung;
• Betrieb in der Nähe von Menschen.

Es geht nicht um die Auswahl einer bestimmten Robotermarke. Der Lehrfall zeigt, wie aus einer mündlichen Kundenbeschreibung eine technisch bearbeitbare Struktur abgeleitet wird.

6. Business-Analyse: zuerst zerlegen, nicht Anforderungen erfinden

Ein Business- oder Systemanalyst sollte nicht sofort beginnen, „Anforderungen zu erfinden“. Zunächst ist die Eingabe in logische Domänen und Komponenten zu zerlegen.

Beispiel für die in der Vorlesung entwickelte Zerlegung:

Kundenaussage
          ↓
1. Roboterarm 2. Endeffektor 3. Sensorik / Bildverarbeitung 4. Steuerung 5. Kommunikation 6. Funktionale Sicherheit 7. Prüfung / Berichterstattung / Cloud

So entsteht eine Karte, auf deren Grundlage Fragen gestellt und Informationslücken sichtbar gemacht werden können.

7. Von Themenblöcken zu User Stories

Nach der Zerlegung führt die Vorlesung User Stories ein, die das System aus Sicht eines Akteurs oder einer Rolle beschreiben.

Eine übliche Form lautet:

Als <Rolle> möchte ich <Fähigkeit>, damit <Nutzen / Ergebnis> entsteht.

Ein Beispiel nahe der Vorlesung:

Als Bediener möchte ich das benötigte Werkzeug des Endeffektors auswählen und aktivieren, damit der Roboter verschiedene Objekttypen ohne manuelle Umrüstung handhaben kann.

Redaktionelle Präzisierung 02 — Akteur und Komponente

Im Transkript wird gelegentlich eine Komponente oder ein Steuerungssubsystem als „Benutzer“ beschrieben. Zur Modellierung von Interaktionen kann das hilfreich sein. Im klassischen agilen Verständnis erfasst eine User Story jedoch üblicherweise die Bedürfnisse eines Akteurs oder Stakeholders. Komponentenverhalten wird später in System-, Software-, Hardware- oder Schnittstellenanforderungen präzisiert.

8. Vom Benutzerbedarf zu technischen Anforderungen

Der Kurs entwickelt folgende Rückverfolgbarkeitskette:

Kundenbedarf / mündliche Aussage
          ↓
geschäftliche Zerlegung
          ↓
User Stories / Stakeholder-Bedürfnisse
          ↓
Systemanforderungen
          ↓
Hardware- / Software- / Firmware- / Mechanik- / Schnittstellenanforderungen
          ↓
Architektur / Komponentenbeschreibung
          ↓
Implementierung
          ↓
Verifikation und Validierung

Dies ist die zentrale Engineering-Idee der Veranstaltung: Jede untergeordnete Ebene muss erklären, welche übergeordnete Anforderung sie erfüllt.

9. Merkmale einer guten Anforderung

Die Vorlesung legt mehrere wichtige Regeln fest, die erhalten bleiben müssen.

Atomar

Eine Anforderung beschreibt genau einen verifizierbaren Bedarf, statt mehrere voneinander unabhängige Bedingungen in einem langen Satz zu bündeln.

Eindeutig

Wörter wie „ausreichend“, „schnell“, „bequem“ oder „zuverlässig“ sind ohne Quantifizierung oder Abnahmekriterium zu vermeiden.

Prüfbar / verifizierbar

Es muss klar sein, wie die Erfüllung einer Anforderung nachgewiesen werden kann.

Identifizierbar und rückverfolgbar

Jede Anforderung benötigt eine Kennung, Versions- beziehungsweise Änderungshistorie sowie einen Bezug zur übergeordneten Anforderung und zum Verifikationsnachweis.

Widerspruchsfrei

Die Gesamtheit der Anforderungen darf keine versteckten Widersprüche enthalten.

Beispiel

Schwache Formulierung:

Der Roboter muss das Werkzeug sehr genau positionieren.

Bessere Formulierung:

SYS-POS-001: Der Roboter muss den aktiven Werkzeugmittelpunkt unter der definierten Prüflast mit einer Abweichung von höchstens ±0,2 mm von der befohlenen kartesischen Position positionieren.

Prüfbedingungen, Bezugskoordinatensystem und Messverfahren müssen noch festgelegt werden. Gerade diese Präzisierungen machen die Anforderung professionell einsetzbar.

10. Systemanforderungen gegenüber Komponentenanforderungen

Die Vorlesung trennt zu Recht folgende Ebenen:

Systemanforderung

Beschreibt Verhalten oder Eigenschaften des Gesamtsystems oder das Zusammenwirken wesentlicher Komponenten.

Hardware-, Software-, Firmware- oder Mechanikanforderung

Ordnet einen Teil des Systemverhaltens einer bestimmten Ingenieurdisziplin oder Komponente zu.

Beispiel:

SYS-COM-001: Robotersteuerung und Endeffektorsteuerung müssen Befehls- und Statusdaten über das definierte Systemnetz austauschen.
          ↓
Zuordnung zu HW-COM-..., SW-COM-... und IF-COM-...

11. Redaktionelle Präzisierung — ROS 2, YOLO und Safety

Der Lehrfall nennt ROS 2, YOLO, Kamera, LiDAR und RADAR als mögliche Lösungsbestandteile. Sie dürfen nicht allein deshalb zu Anforderungen werden, weil sie in Discovery-Gesprächen erwähnt wurden.

• ROS 2 ist eine Technologie- oder Plattformentscheidung. Zunächst müssen Interaktions- und Einsatzanforderungen geklärt, erst danach Lösungen gewählt werden.
• YOLO ist eine Familie von Objekterkennungsmodellen, nicht automatisch das beste Verfahren zur Klassifizierung oder Leiterplattenprüfung.
• LiDAR, RADAR und Kameras sind mögliche Sensortechnologien, aber keine allgemeingültige Antwort auf Fragen der funktionalen Sicherheit.
• Die Sicherheitsarchitektur einer Roboterzelle muss aus Risikobeurteilung, Betriebsarten und anwendbaren Normen abgeleitet werden. Die Sensorwahl folgt der Analyse statt einer ungeprüften Vorannahme.

Dies ist eine Kerndisziplin des Requirements Engineerings: Bedarf nicht mit einer vorschnell gewählten Lösung verwechseln.

12. Erste Architekturskizze

Sobald Systemanforderungen und wesentliche Komponenten erkennbar werden, kann eine erste Topologie oder Architekturdarstellung entstehen.

Das didaktische Fallschema:

Übergeordneter Testrechner → Berichte / Speicherung und Vision / Wahrnehmung → Systemnetz → Robotersteuerung + Endeffektorsteuerung → Roboterarm + Werkzeugrotation / Greifer / Magnet / Kontaktmatrix → mechanische Kopplung

Es handelt sich noch nicht um eine Detailarchitektur. Die Skizze soll vielmehr Lücken offenlegen: Schnittstellen, Verantwortlichkeiten, Versorgung, Zeitverhalten, Sicherheitsgrenzen, Datenflüsse und mechanische Kopplung.

13. Das V-Modell beschreibt Rückverfolgbarkeit, nicht nur den Buchstaben V

In der Vorlesung führen Anforderungen zur Implementierung und anschließend zurück zur Verifikation.

Bedürfnisse ↔ Validierung; Systemanforderungen ↔ Systemtest; Komponentenanforderungen ↔ Integrationstest; Entwurf / Architektur ↔ Komponentenprüfung; Implementierung am unteren Verbindungspunkt.

Entscheidend ist, dass der Testnachweis zu der Ebene gehört, auf der die betreffende Anforderung verifiziert werden soll.

14. Praktische Teamaufgabe

Am Ende wird das erste umfangreichere Praxisszenario definiert. Die Teams sollen wie kleine Dienstleistungsunternehmen handeln.

In der nächsten Phase sollen sie:

1. Teams bilden;
2. anfängliche Rollen in Engagement, Geschäftsführung, technischer Leitung und Management vergeben;
3. eine Firmenidentität entwickeln;
4. Visitenkarten und digitale Kontaktdaten vorbereiten;
5. eine öffentlich nutzbare Unternehmensvorstellung oder Landing-Materialien erarbeiten;
6. so handeln, als würden sie morgen zu einer Branchenkonferenz abreisen;
7. den Dozenten als potenziellen Lead ansprechen und ein Folgegespräch vereinbaren;
8. danach Gespräche → RFI/RFQ/RFC → Proposal → Zerlegung → Anforderungen bearbeiten.

Damit prüft der erste Leistungsnachweis nicht ein isoliertes Thema, sondern den gesamten seit dem 1. September behandelten Weg.

15. Kontrollfragen

1. Weshalb muss der Vorlauf für die Personalbesetzung vor Vertragsbeginn berücksichtigt werden?
2. Was ist zu tun, wenn der tatsächliche Umfang nach Vertragsabschluss von der Pre-Sales-Darstellung abweicht?
3. Warum beginnt Business-Analyse mit Zerlegung statt mit der Formulierung von Anforderungen?
4. Worin unterscheiden sich Stakeholder-Bedürfnisse, User Stories und Systemanforderungen?
5. Was macht eine Anforderung atomar?
6. Warum ist eine Anforderung schwach, wenn kein Verifikationsverfahren angegeben wird?
7. Warum darf eine genannte Technologie nicht automatisch zur Anforderung werden?
8. Welche Lücken soll das erste Architekturdiagramm sichtbar machen?
9. Wie verknüpft das V-Modell Anforderungen mit Testnachweisen?
10. Welche Arbeitsprodukte soll jede studentische „Firma“ vor der ersten Übung vorbereiten?

16. Ausblick auf die nächsten ein bis zwei Veranstaltungen — Stand 22. September 2026

Voraussichtliche Sitzung 07 — praktische Lead-Generierung und Simulation eines Erstgesprächs

Die Hausaufgabe weist bereits die nächste Richtung: Teams stellen ihre „Firmen“ vor, führen ein Erstgespräch, vereinbaren einen Folgetermin und dokumentieren Discovery-Fragen. Erwartete Ergebnisse sind Unternehmens-One-Pager, Rollenkarte, Kontaktkarte oder QR-Code, zwei bis drei Fallstudien oder Kompetenznachweise und eine Frageliste für den Lead.

Voraussichtliche Sitzung 08 — vom Folgegespräch zu RFI/Proposal und Anforderungsbasis

Nach der Simulation des Lead-Prozesses folgt logisch ein konkreter Kundenfall: RFI oder Problembeschreibung erhalten und beantworten, Annahmen und offene Fragen bestimmen, ein Grobangebot ausarbeiten und die erste Rückverfolgbarkeitskette von Bedarf über System- bis zu zugeordneten Komponentenanforderungen erstellen.

Wichtig: Das ist eine Prognose, keine eingefrorene Behauptung über den tatsächlichen weiteren Verlauf. Wenn eine neue Aufzeichnung vorliegt, wird die wirkliche Veranstaltung als neuer Inhalt hinzugefügt. Die Prognose wird nicht nachträglich umgeschrieben.

Geprüfte Referenzen

• ROS-2-Dokumentation: https://docs.ros.org/en/jazzy/
• AUTOSAR Classic Platform (Beispiel einer Schichtenarchitektur): https://www.autosar.org/standards/classic-platform
• ISO 26262-3:2018 (Beispiel für formale Konzept- und HARA-Arbeit im Automotive-Bereich): https://www.iso.org/standard/68385.html