Einheit 12. Das Expertengespräch, RFI/RFC/RFQ und das Proposal: wie aus einem Gespräch über das Unternehmen ein Gespräch über das Projekt wird

20. Oktober 2026 · Vorlesung 7 · 1 Std. 26 Min. 48 Sek. Grundlage ist das automatische Transkript IgorSikorskyKPI_L7_20102026.mp4. Dies ist ein redigiertes Lehrskript, keine wörtliche Abschrift: offensichtliche Erkennungsfehler wurden korrigiert und die Terminologie an frühere Einheiten angeglichen. Der Kunde Otto, sein Unternehmen und die technische Aufgabe sind ein Unterrichtsszenario. Das Beispiel der Industrieanlage hat der Dozent nur allgemein geschildert, ohne Details, die einer Geheimhaltungsvereinbarung (NDA) unterliegen. Die Einheit wurde durch Luftalarm unterbrochen; auf den Inhalt der Notizen hatte das keinen Einfluss.

Stellung im Kurs: der letzte Schritt vor einer konkreten Anfrage

In den Einheiten 10–11 ging das Team vom Messekontakt bis zum ersten Follow-up: Es stellte das Unternehmen, seine Expertise, Standorte und Werkzeuge vor und erfuhr, wo dem Kunden „der Schuh drückt“. Einheit 12 behandelt das zweite Follow-up — ein Expertengespräch, nach dem das Gespräch von „wer wir sind“ zu „welches Projekt wir machen“ wechseln muss. Das wichtigste Ergebnis ist eine formale Anfrage des Kunden: RFI, RFC, RFQ oder gleich Anforderungen.

Der Dozent betonte, dass alles im Kurs Empfehlungen aus eigener Erfahrung und der Erfahrung von Kollegen sind, keine einzig mögliche Vorgehensweise. Sie sollten an den jeweiligen Kunden, Markt und die Unternehmenskultur angepasst werden.

0. Organisatorisches: Bewertung und die große selbstständige Aufgabe

• Die Prüfungsleistung (Zalik) wird mit 60 Punkten oder mehr automatisch anerkannt; wer darunter bleibt, schreibt eine Abschlussklausur.
• Auch die Anwesenheit bringt Punkte, daher ist die Teilnahme wichtig.
• Nach der zweiten Zwischenbewertung folgt eine große selbstständige Aufgabe — die Simulation eines Engineering-Unternehmens: statische Website, simulierte Reise zu einer Konferenz oder Messe, Gewinnung eines Leads, Umwandlung in einen Kunden, Anforderungen, Proposal, Projekt in GitHub oder Jira, Teamzuordnung und Release. Die Arbeit wird von regelmäßigen Treffen begleitet, etwa zweimal pro Woche.
• Die Prüfungsfragen decken den gesamten Kurs ab; die Liste wird vorab bereitgestellt.

1. Warum ein zweites Follow-up

Das erste Treffen auf der Konferenz schuf eine Bekanntschaft. Das erste Follow-up stellte das Unternehmen breit vor: Jahre am Markt, Engineering-Kapazität, Kompetenzen, Werkzeuge, Standorte, Zertifizierungen. Sein eigentlicher Zweck war zu verstehen, wo der Kunde Schmerzen hat und welche „Tablette“ man ihm anbieten sollte.

Im Unterrichtsszenario möchte der Kunde Otto eine zerstörungsfreie Diagnose eines Verbrennungsmotors: ohne den Motor zu zerlegen und ohne menschliches Eingreifen prüfen, ob Nockenwellen, Kipphebel oder Brennraumwände im Zylinderkopf beschädigt sind. Das Zerlegen ist teuer und erfordert sofort Ersatzteile, daher ist der Wert einer Lösung offensichtlich. Das zweite Follow-up ist das Gespräch, in dem das Unternehmen gezielte Expertise genau für dieses Problem zeigt. Ideal ist es, Otto bereits in dieser Phase als Kunden zu gewinnen.

2. Zerlegung des Problems: wer gehört ins Gespräch

Schon eine kurze Problembeschreibung zerfällt sofort in mehrere Fachrichtungen:

So kommen fünf starke Fachleute zusammen. Erscheint diese Gruppe aber einfach zum Termin, scheitert er: Otto wird von der Anzahl der Personen überfordert, und unvorbereitete Experten sehen ihn nur schweigend an. Deshalb sind Hausaufgaben nötig.

3. Hausaufgaben: eine zugeschnittene Präsentation und eine Nachricht an den Kunden

Die vorherige Präsentation deckte das gesamte Unternehmen ab: Web, Mobile, Cloud, AI, Embedded, Automotive, Robotics, Fintech, Healthcare, Mining. Jetzt muss sie auf den erkannten Bedarf zugeschnitten werden. Die Zahl der Büros und die Größe des Unternehmens spielen keine Rolle mehr. Die Kernbotschaft lautet etwa: „Als Fortsetzung unseres letzten Gesprächs möchten wir unsere Expertise in den Themen zeigen, die aus unserer Sicht gerade für Sie nützlich sind. Wir haben einige Fallbeispiele vorbereitet und möchten hören, wie gut sie zu Ihrem Problem passen.“

Das erwartete Ergebnis des Gesprächs ist ein tiefes Verständnis des Problems und möglicher Lösungswege. Es muss genau geklärt werden, was der Kunde bereits hat. Vielleicht sind Hardware, Firmware und Mechanik fertig, und es fehlen nur Ingenieure. Vielleicht gibt es nichts, und dann muss das Proposal die vollständige Vision beschreiben: von der Systemebene bis zur Umsetzung.

Spielen Sie fair: Informieren Sie Otto, dass Sie eine neue Präsentation vorbereiten und Ihre Fachexperten mitbringen. Dann kann er eigene Fachleute mitbringen und Unterlagen vorbereiten, die seinen Bedarf besser erklären. Stimmt der Kunde einem solchen zweiten Termin zu, ist das gegenseitige Interesse bereits vorhanden.

4. Die Einladung: Zeitfenster, Kommunikationswerkzeug und Agenda

Eine Einladung zum Expertengespräch hat drei Pflichtbestandteile.

1. Zeitfenster. Bieten Sie etwa drei Optionen im Abstand von einem Tag an und verteilen Sie sie auf Morgen, Mittag und Abend. Lassen Sie immer Raum für einen eigenen Terminvorschlag des Kunden.
2. Kommunikationswerkzeug. Das erste Gespräch fand in der für Sie bequemen Umgebung statt, etwa Google Meet. Fragen Sie nun, was der Kunde bevorzugt: Google Meet, Microsoft Teams, Slack oder etwas anderes. Wählt er Teams, organisieren Sie sich so, dass Sie die Einladung dort erzeugen können. Die Anpassung an die Geschäftswerkzeuge des Kunden zeigt Flexibilität und Respekt.
3. Agenda. Die Person muss verstehen, wozu sie eingeladen wird. Nennen Sie fünf bis sechs Punkte, zum Beispiel: kurze Zusammenfassung des Kontexts, Zerlegung der Aufgabe, Fallbeispiele je Fachrichtung, Diskussion des Kundenproblems, nächste Schritte.

Eine gute Einladung zeigt zugleich Respekt, Flexibilität, eine Investition von Zeit und Geld und ein konkretes Ziel. Genau eine solche Nachricht liest der Kunde als Zeichen für ein gutes Geschäft.

5. Ein E-Mail-Thread vom Erstkontakt bis zum Vertrag

Die gesamte Kommunikation — die erste E-Mail nach der Konferenz, Vereinbarungen, Einladungen, Präsentationen und Follow-ups — sollte in einem einzigen E-Mail-Thread geführt werden. Nach Vertragsunterzeichnung wird dieser Thread geschlossen und ein neuer, technischer Thread begonnen.

Der Grund ist praktisch: Wenn später Eskalationen auftreten, lassen sich die ursprünglichen Vereinbarungen leicht finden und ihr genauer Wortlaut zeigen. Am Anfang sind beide Seiten sozusagen verliebt, doch Projekte enden manchmal im Konflikt. Damit die „Scheidung“ nach für Sie günstigen und transparenten Regeln verläuft, braucht es einen unterschriebenen Vertrag und eine dokumentierte Historie der Vereinbarungen.

6. Was ein Expertengespräch kostet

Ab diesem Punkt kostet der Pre-Sale echtes Geld. Vier bis fünf hochqualifizierte Architekten und Leads sind die teuersten Menschen im Unternehmen. Sobald sie an einem Termin teilnehmen, muss ihre Zeit bezahlt werden, obwohl es noch kein Projekt gibt. Legen Sie daher vorab fest, wen genau Sie mitnehmen, wie viele Personen und wie lange das Gespräch dauert. Es ist eine Investition, die bewusst begrenzt werden muss.

7. Rollen im Gespräch: das bekannte Gesicht, Engagement und die Experten

Der Dozent nutzte eine Jagdanalogie: Es gibt Treiber, die das Wild auf den richtigen Weg lenken, und Schützen, die auf ihren Positionen warten. Engagement sind die Treiber; Architekten, Ingenieure und das bekannte Gesicht sind die Schützen. In Unternehmen ist Engagement oft eine eigene Abteilung von Menschen, die stets voller Energie sind und das Kommunikationstempo halten.

Wer teilt zuerst den Bildschirm? Wer einlädt. Sie haben das Team zusammengestellt und die Präsentation vorbereitet, also beginnen Sie mit dem Teilen.

8. Ablauf des Gesprächs

1. Aufwärmen. Der Engagement Manager begrüßt Otto, fragt, wie es ihm und seinem Geschäft geht, und stellt einige vorbereitete Fragen, die den Kunden nach seinem Gespür interessieren. Alle Kameras sind eingeschaltet: Otto soll das bekannte Gesicht sehen.
2. Vorstellungsrunde. Ist die Zeit knapp, nennt Engagement rasch alle Teilnehmenden und ihre Rollen. Gibt es mehr Zeit oder ist er sicher, dass sich die Kolleginnen und Kollegen gut präsentieren, stellt sich jede Person selbst vor.
3. Vorstellung des Kunden. Engagement bittet Otto, sich vorzustellen — nicht, weil er unbekannt wäre, sondern als Zeichen des Respekts. Sind Kolleginnen oder Kollegen mitgekommen, stellen auch sie sich vor.
4. Einführungsfolien. Engagement zeigt die Agenda und die Systemzerlegung: Robotics, Computer Vision, AI, Embedded.
5. Fallbeispiele der Experten. Engagement übergibt die Steuerung der Präsentation nacheinander an die Experten: zwei Fälle zu Computer Vision, zwei zu Robotics und so weiter. Nach jedem Block fragt er: „Otto, was meinen Sie? Passt das zu Ihrem Problem?“
6. Frage an den Kunden. Warten Sie nach dem letzten Block nicht darauf, dass der Kunde von selbst zu sprechen beginnt. Fragen Sie direkt: „Erzählen Sie uns bitte, welches Problem Sie haben und was genau Sie lösen wollen. Wir möchten verstehen, wie wir helfen können.“
7. Offene Diskussion. Etwa 10–15 Minuten sprechen die Experten beider Seiten direkt miteinander.
8. Zusammenfassung und nächster Schritt. Engagement fasst das Gespräch zusammen und bietet an, ein Proposal vorzubereiten.

Der Dozent verglich den Architekten mit einem Liftführer in einem Hochhaus: Er fragt, in welches Stockwerk man möchte, und erfährt unterwegs, was auf jeder Etage geschieht. Der Architekt transportiert Informationen zwischen den Ebenen des Systems und zwischen Menschen, hält bei Folien inne, fragt nach, bemerkt eine hochgezogene Augenbraue, einen abgewandten Blick oder den Griff zum Telefon.

9. Offene Diskussion mit Dirigent: zweiter Bildschirm und interner Chat

Beginnt die offene Diskussion, sollte jedes Mitglied Ihres Teams zwei Bildschirme haben: auf einem das Gespräch mit dem Kunden, auf dem anderen den internen Team-Chat. Engagement, die Führungskraft und andere nichttechnische Teilnehmende halten sich aus der Fachdebatte heraus. Sie beobachten und steuern: Gerät ein Ingenieur in einen unnötigen Streit oder setzt den Kunden unter Druck, erscheint im Chat ein kurzes „Stopp“, und der Kollege ändert den Ton.

Das ist ein Orchester, und der interne Chat ist der Taktstock des Dirigenten. Dem Kunden in dieser Phase offen zu widersprechen ist riskant; Unterstützung und Rückfragen wirken besser.

10. Abschluss: die zugesagte Anfrage und der „Hebel“ für Erinnerungen

Zum Schluss sagt Engagement etwa: „Die Intensität dieses Gesprächs zeigt, dass wir dieselbe Sprache sprechen und verstehen, wie es geht. Lassen Sie uns ein Proposal für Sie vorbereiten.“ Der Kunde antwortet, dass er ein RFI, RFQ oder RFC schicken wird. Das Team verspricht seinerseits, die Präsentation als Follow-up zu senden.

Dieses Versprechen ist ein Hebel. Vergisst der Kunde die Anfrage, wird die E-Mail mit der Präsentation zu einem weiteren natürlichen Anlass zur Erinnerung: „Hier ist die zugesagte Präsentation; wir warten auf das RFI.“ Oft hat der Kunde das Anfragedokument noch gar nicht geschrieben: Im Gespräch sagt er das nicht, verwendet aber einen oder zwei Tage auf eine Tabelle mit Fragen. Nach einigen Erinnerungen kommt die Anfrage in der Regel.

Die entscheidende Veränderung nach diesem Gespräch: Davor ging es um Kompetenzen, das Unternehmen, das Team — um alles außer dem Projekt. Danach dreht sich das gesamte Gespräch um das Projekt, das den Kunden interessiert.

11. Was der Kunde schicken kann: „fragen“ oder „sagen“

Wie in Einheit 04 bedeutet RFC hier Request for Clarification in der Terminologie des Kurses. In der allgemeinen Beschaffungspraxis heißt eine Anfrage „beschreiben Sie Ihre Lösung“ eher RFP (Request for Proposal), während RFC in der Softwaretechnik meist Request for Comments bedeutet. Im realen Prozess sollte der Dokumentname daher bei der ersten Verwendung ausgeschrieben werden.

12. RFI: eine Fragentabelle mit „doppeltem Boden“

Ein typisches RFI ist eine Excel-Tabelle: eine Spalte mit Fragen, eine zweite für Antworten. Beispiele aus der Vorlesung:

• Verfügen Sie über Kompetenz in Model-Based Development? Nachfrage: Welche Werkzeuge nutzen Sie für modellbasierte Entwicklung und für modellbasiertes Testen? Mögliche Antwort: MATLAB/Simulink, OpenModelica; für das Testen Simulink Test, für Modell- und Codeabdeckung Simulink Coverage.
• Haben Sie Expertise im Embedded Engineering? Nachfrage: Mit welchen Mikrocontrollern arbeiten Sie? Antwort ist eine Liste von Familien, etwa STM32 (STMicroelectronics), NXP, Xilinx (heute AMD).
• Haben Sie Erfahrung mit System on Chip (SoC)?
• Ist Ihr Unternehmen oder sind die im Projekt eingesetzten Ingenieure nach einer Norm für funktionale Sicherheit zertifiziert? Wenn ja, nach welcher?

Nachfragen müssen nicht beantwortet werden, wenn die Hauptfrage mit „nein“ beantwortet wurde. Ein RFI umfasst eine bis 10–20 Seiten. Solche Fragebögen haben oft einen „doppelten Boden“: Dieselbe Frage taucht an anderer Stelle aus einem anderen Blickwinkel wieder auf, um die Konsistenz zu prüfen. Ihre Antworten dürfen sich daher nicht widersprechen.

Rechnen Sie damit, dass der Kunde Ihre Antworten nach einer eigenen Vorlage auswertet, möglicherweise mit AI, und Ihre technologische Eignung bewertet. Das ist kein Grund zu beschönigen: Unwahrheiten kommen früher oder später ans Licht. Erfüllen Sie die Anforderungen nicht, ist es schlicht nicht Ihr Kunde.

13. RFC und Proposal: wie viel man offenlegt

Manchmal erkennt der Kunde nach dem Gespräch, dass Sie den Prozess besser verstehen als er. Dann schickt er weder Anforderungen noch User Stories, sondern nur ein kurzes RFC aus zwei Sätzen: „Hallo. Könnten Sie bitte in Word, Markdown oder einem anderen Format Ihre Vision einer Lösung unseres im Gespräch besprochenen Problems beschreiben?“

Die Antwort auf ein RFC ist ein Proposal, dessen Struktur in früheren Einheiten behandelt wurde: Summary, Architectural View, Design View, Umsetzungsplan, Risiken, kommerzieller Teil. Der Umfang reicht von zwei bis hundert Seiten; das umfangreichste Proposal in der Praxis des Dozenten hatte etwa hundert Seiten. Architekten schreiben es, und das Team investiert eigene Zeit. Ein RFC direkt nach dem Gespräch ist ein sehr gutes Zeichen: Der Kunde weiß nicht, wie er die Aufgabe lösen soll, und möchte, dass Sie Kreativität zeigen.

Die Gefahr, die einer der Studierenden in der Einheit treffend benannte: Das Team erstellt unentgeltlich ein Dokument, das das Problem faktisch löst, und der Kunde bedankt sich und verschwindet. Der Dozent gab ein Beispiel aus seiner Praxis (ohne Details wegen einer NDA). Ein großes Werk hatte eine Anlage mit einer gefährlichen Leckage, die nicht direkt gemessen werden konnte. Benötigt wurde ein mathematisches und rechnergestütztes Modell der Leckage in die Umgebung. Im Proposal beschrieb der Dozent ein Verfahren zur Bestimmung der Leckagemenge auf Grundlage von MATLAB/Simulink-Modellierung und analytischen Berechnungen. Danach bedankte sich der Kunde und verschwand: Die eigenen Ingenieure hatten genug, um die Lösung selbst umzusetzen.

Die Grenze zwischen „zu wenig“ und „zu viel“ ist sehr schmal. Zu wenig, und der Kunde glaubt nicht, dass Sie es schaffen. Zu viel, und er macht es selbst.

14. Format und Versionierung des Proposals

Traditionell wird ein Proposal in einem Textverarbeitungsprogramm (Microsoft Word, LibreOffice, OpenOffice) geschrieben, weil es Text, Abbildungen, Formeln und Tabellen verbindet. Pflichtattribute eines solchen Dokuments:

• Autor — die Person, die die erste Fassung erstellt hat; sie bleibt dauerhaft Autor;
• Last changed by — wer die letzten Änderungen vorgenommen hat;
• Änderungshistorie am Anfang des Dokuments — was sich zwischen Release-Versionen und in welchen Abschnitten geändert hat.

Die Zahl vor dem Punkt ist die Release-Nummer für den Kunden; die Zahl nach dem Punkt zählt interne Iterationen. Wie oft das Dokument auch intern hin- und hergeht — die erste versandte Fassung ist immer 1.0.

Der Dozent bevorzugt Excel: Jeder Reiter dient als eigener Abschnitt (Einleitung, Architektur usw.), die Daten sind strukturiert, und der finanzielle Teil — Menge, Dauer und Kosten — lässt sich direkt im Dokument für beide Seiten transparent berechnen. Im AI-Zeitalter hat sich Markdown verbreitet: Es ist ein bequemes Format für die Zusammenarbeit von Menschen und Sprachmodellen, und kleine moderne Unternehmen akzeptieren es gern. Große konservative Unternehmen haben eigene Regeln zum AI-Einsatz; mit ihnen arbeitet man anfangs besser klassisch in Word oder Excel und schlägt Markdown später vor, wenn diese Praxis dort besteht.

15. RFQ: Teil des ersten Proposals und vierteljährliche Anfrage

Das erste Proposal enthält immer einen kommerziellen Teil: Menge und Preis — die Kosten der Ingenieurzeit und der Materialressourcen. Zu Beginn ist das RFQ daher eng mit dem RFC verbunden.

Ein eigenständiges Dokument wird das RFQ nach Projektstart: Etwa einmal pro Quartal bittet der Kunde um eine Schätzung der Kosten für das nächste Quartal. Dann gibt es bereits Jira, ein GitHub Project oder ein anderes Tracking-Werkzeug, doch die Prognose künftiger Kosten wird weiterhin als Dokument erstellt. Sie umfasst Engineering-Leistungen, Material und Nebenkosten wie Kurier- und Postdienste.

Ein weiterer häufiger Weg: Der Kunde liest Ihr Proposal iterativ und schickt Kommentare zurück („diesen Teil bitte anders formulieren“). Faktisch baut er die Architektur des künftigen Systems auf Ihre Kosten. Das ist ein geschickter Ansatz, doch nach der Erfahrung des Dozenten münden solche Geschichten meist in einen Vertrag.

16. Der beste Fall: Anforderungen und eine Teamschätzung

Weiß der Kunde genau, was er will, schickt er Anforderungen auf drei Ebenen: System Requirements (wie sich das System verhält), Software Requirements und Hardware Requirements. Dann wird von Ihnen bereits in der ersten Phase ein RFQ erwartet.

Eine einzelne Person kann nicht das ganze System schätzen. Das Team muss zusammenkommen; jedes Mitglied schätzt einzelne Features oder Anforderungen und beschreibt, wie es die Umsetzung sieht. Die Liste der erwarteten Dauern wird zur Antwort auf das RFQ, etwa: „Funktion X — 2 bis 10 Tage bei einem Tagessatz von 400 US-Dollar für einen Ingenieur einer bestimmten Stufe“ (der Satz ist illustrativ). So sieht der Kunde, um welche Summen es geht.

17. Probleme, die die Schätzung mit sich bringt

Die Schätzphase bringt interne Probleme mit sich — sie werden Thema der nächsten Einheiten:

1. Niemand, der schätzen kann. Im „goldenen Zeitalter“ der ukrainischen IT (etwa 2016–2018, vor COVID-19) hielten Unternehmen Ingenieure in einem „Pool“ auf der Bench, bereit für neue Projekte. Heute ist diese Praxis fast verschwunden.
2. Externe Experten einbinden. Eine bekannte Fachperson aus einem anderen Unternehmen kann helfen, muss aber bezahlt werden; ein Vergütungsmodell ist nötig.
3. Freelancing als Ressourcenquelle und seine Risiken.
4. Verantwortung für die Schätzung. Ein externer Experte kann eine Aufgabe unterschätzen, weil er sie nicht selbst ausführt. Wie erhält man eine durchdachte Schätzung, und wie bringt man die Schätzenden ins Projekt?
5. Kosten von Engineering und Produkt. Im Embedded-Bereich kommen zur Ingenieurzeit Mechanik, Leiterplattenentwicklung, Bauteilbeschaffung, Bestückung, Validierung und Verifikation, Logistik und Zollabwicklung hinzu.
6. Risikoanalyse verspäteter Lieferung für beide Seiten.
7. Fixed Price oder Time & Material in der heutigen europäischen Embedded-Praxis.

Praktische Schlussfolgerungen

• Das zweite Follow-up wird für das konkrete Problem des Kunden vorbereitet, nicht für ein allgemeines Unternehmensprofil.
• Die Einladung enthält mehrere Zeitfenster, die Wahl des Kommunikationswerkzeugs und eine Agenda.
• Die gesamte Kommunikation vor dem Vertrag läuft in einem E-Mail-Thread.
• Das bekannte Gesicht ist immer dabei, Engagement leitet, Experten zeigen Fallbeispiele und stellen Fragen.
• Ziel des Gesprächs ist ein RFI, RFC, RFQ oder Anforderungen; ohne sie ist weitere Arbeit Zeit- und Geldverschwendung.
• Antworten auf ein RFI müssen ehrlich und untereinander konsistent sein.
• Die Detailtiefe eines Proposals hängt davon ab, wo die Komplexität liegt: in der Technologie oder in der technischen Umsetzung.
• Ein Proposal hat einen Autor, eine Änderungshistorie und eine klare Versionsnummerierung.

Fragen zur Selbstkontrolle

• Worin unterscheidet sich das zweite Follow-up vom ersten in Ziel und Präsentationsinhalt?
• Welche Fachleute sollten für die zerstörungsfreie Motordiagnose eingebunden werden, und warum nicht alle auf einmal?
• Was muss eine Einladung zu einem Expertengespräch enthalten?
• Warum sollte die gesamte Korrespondenz vor dem Vertrag in einem E-Mail-Thread geführt werden?
• Welche Rolle hat das bekannte Gesicht, und warum schreibt gerade diese Person die allererste E-Mail?
• Wer teilt zuerst den Bildschirm, und wer eröffnet das Gespräch?
• Wozu braucht das Team während der offenen Diskussion einen zweiten Bildschirm und einen internen Chat?
• Wie unterscheidet sich der Modus „Kunde fragt“ vom Modus „Kunde sagt“?
• Was ist der „doppelte Boden“ in einem RFI, und wie vermeidet man widersprüchliche Antworten?
• Wann sollte ein Proposal allgemein und wann möglichst detailliert geschrieben werden?
• Wie ändert sich die Versionsnummer des Proposals zwischen internen Reviews und Übermittlungen an den Kunden?
• Warum existiert das RFQ nach Projektstart getrennt vom RFC?

Was als Nächstes angekündigt wurde

Der Dozent kündigte für die folgenden Einheiten an: Personalressourcen für Schätzungen bei leerem „Pool“, Vergütung externer Experten, Freelancing, Verantwortung für Schätzungen, Kostenanalyse von Engineering und Hardware, Risikoanalyse sowie einen Vergleich von Fixed Price und Time & Material. Danach geht der Kurs zu Vertragsabschluss, User Stories und internen Anforderungen, Teamzerlegung, Personalgewinnung und der Festlegung von Managementrollen über. Eigene Praxiseinheiten sind dem Schreiben eines Proposals und dem Ausfüllen eines RFI gewidmet. Das ist ein angekündigter Plan, keine bereits durchgeführten Einheiten.

Geprüfte Quellen

• ISO/IEC/IEEE 29148:2018, Systems and software engineering — Requirements engineering: https://www.iso.org/standard/72089.html
• Simulink Test (MathWorks): https://www.mathworks.com/products/simulink-test.html
• Simulink Coverage (MathWorks): https://www.mathworks.com/products/simulink-coverage.html
• OpenModelica: https://openmodelica.org/