Methoden der Funktionsentwicklung Flashcards
(18 cards)
Warum beschäftigt man sich mit solchen Tools wie dem V-Modell oder Systems Engineering? (Komplexität usw.)
Antwort (detaillierter, aber noch karteikartenfreundlich):
Moderne Fahrzeuge sind hochkomplex: viele Sensoren, Software, Vernetzung, Sicherheitsfunktionen.
Anforderungen ändern sich oft, viele Fachbereiche arbeiten zusammen.
Tools wie das V-Modell oder Systems Engineering helfen,
- die Entwicklung zu strukturieren,
- Fehler früh zu finden
- und alle Beteiligten zu koordinieren.
Beispiel:
Früher öffnete man eine Tür mechanisch.
Heute: Funkschlüssel, App, Sensor, Kindersicherung – alles muss zusammen funktionieren.
Was bedeutet Komplexität?
Komplexität bedeutet, dass ein System aus vielen Teilen besteht, die miteinander vernetzt sind und sich gegenseitig beeinflussen.
Je mehr Elemente und Wechselwirkungen, desto schwerer ist es, alles zu überblicken und vorherzusagen.
Beispiel:
Ein Auto hat viele Systeme (Motor, Bremsen, Sensoren, Software), die zusammenarbeiten müssen.
Wenn man z. B. bremst, greifen ABS, ESP, Sensoren und Steuergeräte gleichzeitig ein.
Zusatz:
Komplexität steigt durch:
viele Anforderungen,
viele Beteiligte,
häufige Änderungen,
internationale Vorgaben.
Was ist Systems Engineering? (In eigenen Worten)
Systems Engineering ist eine strukturierte Methode, um komplexe technische Systeme zu planen, zu entwickeln und umzusetzen – von der Idee bis zum fertigen Produkt.
Es verbindet alle Fachbereiche (z. B. Mechanik, Elektronik, Software) und stellt sicher, dass alle Anforderungen erfüllt werden – technisch, wirtschaftlich und für den Nutzer.
Ziel:
Das richtige System richtig entwickeln, und zwar gemeinsam, methodisch und effizient.
Was bedeutet Komposition & Dekomposition? (nach Seite 24)
Dekomposition:
Man zerlegt ein großes System in kleinere, handhabbare Teile, z. B. nach Funktionen, Eigenschaften oder Disziplinen.
→ So wird die Aufgabe übersichtlicher und besser lösbar.
Komposition:
Man fügt die Einzelteile wieder zu einem Gesamtsystem zusammen, sodass sie gemeinsam funktionieren.
Ziel:
Bessere Verständlichkeit, gezielte Bearbeitung und klare Verantwortlichkeiten bei der Entwicklung.
Beispiel:
Ein Auto wird in Teilsysteme zerlegt: Bremse, Licht, Motorsteuerung – später alles integriert.
Welche Entwicklungsprozesse gibt es? (inkl. V-Modell, Validieren/Verifizieren)
Es gibt zwei Hauptarten von Entwicklungsprozessen:
V-Modell (klassisch, strukturiert)
Agile Methoden (flexibel, iterativ)
In der Automobilbranche ist das V-Modell Standard, vor allem bei sicherheitskritischen Funktionen (z. B. nach ISO 26262).
Das V-Modell (vereinfacht):
Links = Planung und Entwicklung
Rechts = Tests und Integration
Ablauf:
Anforderungen
↓
System- und Softwaredesign
↓
Implementierung
↓
Komponententest
↑
Integrationstest
↑
Systemtest
↑
Abnahmetest
↑
Verifikation bedeutet: „Richtig gebaut?“
Man prüft, ob die Technik korrekt umgesetzt wurde (zum Beispiel: misst der Sensor wie geplant?).
Validierung bedeutet: „Das Richtige gebaut?“
Man prüft, ob die Lösung zum Kundenwunsch passt (zum Beispiel: erkennt der Sensor Hindernisse zuverlässig im Alltag?).
Merksatz:
Das V-Modell hilft, systematisch zu entwickeln und in jeder Phase passende Tests durchzuführen.
Welche Kreativitätsmethoden gibt es?
Kreativitätsmethoden helfen dabei, neue Ideen zu finden – z. B. für Lösungen, Funktionen oder Konzepte. Sie regen das Denken an und brechen alte Muster auf.
Beispiele aus der Datei (Folie 75–76):
-
Brainstorming
Alle Ideen werden frei in der Gruppe gesammelt – ohne Bewertung. Ziel: möglichst viele, auch verrückte Ideen. -
Brainwriting
Wie Brainstorming, aber schriftlich. Jeder schreibt seine Ideen auf, dann tauschen alle die Blätter und schreiben weiter. -
Mind Mapping
Zentrales Problem in die Mitte schreiben, drum herum Äste mit Ideen und Unterideen zeichnen. Gut zur Strukturierung. -
Morphologischer Kasten
Teilfunktionen auflisten (z. B. Tür öffnen, Tür schließen) und für jede Funktion mehrere Lösungsansätze sammeln. Dann alles kombinieren. -
Methode 6-3-5
6 Personen schreiben je 3 Ideen auf ein Blatt → Blatt wird 5-mal weitergegeben → am Ende entstehen 108 Ideen. -
Denkhüte (De Bono)
Jeder im Team übernimmt eine Denkrolle (z. B. kreativ, kritisch, emotional), um ein Problem aus mehreren Perspektiven zu beleuchten.
Merksatz:
Kreativitätsmethoden bringen neue Ideen – am besten in Gruppen, ohne Bewertung, mit klarer Struktur oder gezielter Abwechslung.
Wie definiert und bewertet man Anforderungen? (nach Seite 84)
Frage:
Wie definiert und bewertet man Anforderungen? (nach Seite 84 der Präsentation)
Antwort:
Die Definition und Bewertung von Anforderungen ist ein zentraler Schritt in jedem Entwicklungsprojekt. Nur wenn Anforderungen klar und nachvollziehbar formuliert sind, kann man gute Lösungen entwickeln und später prüfen, ob alles richtig umgesetzt wurde.
1. Anforderungen definieren – Was soll das System können?
Anforderungen beschreiben, was das Produkt leisten soll. Es gibt:
-
Funktionale Anforderungen:
Was das System tun soll. Beispiel: „Das System muss automatisch bremsen, wenn ein Hindernis erkannt wird.“ -
Nicht-funktionale Anforderungen:
Wie gut das System funktionieren soll. Beispiel: „Das System muss innerhalb von 0,5 Sekunden reagieren.“ Oder: „Die Anzeige muss bei Sonnenlicht lesbar sein.“
Gute Anforderungen sind:
- Eindeutig (kein Raum für Interpretation)
- Messbar (z. B. Zeit, Reichweite, Genauigkeit)
- Überprüfbar (es muss einen Test dafür geben)
- Positiv formuliert (was es tun soll, nicht was es nicht tun darf)
2. Bewertung – Welche Lösung ist die beste? (Nutzwertanalyse)
Oft gibt es mehrere technische Lösungen. Um die beste zu finden, nutzt man die Nutzwertanalyse. Dabei geht man so vor:
- Man legt Bewertungskriterien fest (z. B. Kosten, Sicherheit, Energieverbrauch, Einfachheit, Erweiterbarkeit).
- Jedes Kriterium bekommt eine Gewichtung, je nach Wichtigkeit (z. B. Sicherheit = 40 %, Kosten = 20 % usw.).
- Dann bewertet man jede Lösung nach jedem Kriterium (z. B. Schulnoten oder Punkteskala).
- Am Ende werden die Punkte mit den Gewichtungen verrechnet → die Lösung mit dem höchsten Gesamtnutzwert gewinnt.
Vorteile:
- Auch subjektive Meinungen werden begründet und dokumentiert.
- Die Entscheidung ist transparent und nachvollziehbar.
- Man kann die Analyse auch dem Kunden zeigen.
Beispiel:
Zwei Konzepte für ein Türsystem:
- Konzept A ist günstig, aber technisch weniger sicher.
- Konzept B ist teurer, erfüllt aber mehr Sicherheitsanforderungen.
→ Mit der Nutzwertanalyse kann man sauber abwägen, welches Konzept insgesamt besser passt.
Merksatz:
Gute Anforderungen sind klar, messbar und überprüfbar.
Mit der Nutzwertanalyse kann man verschiedene Lösungen fair vergleichen und die beste auswählen.
Was ist der Unterschied zwischen Lastenheft und Pflichtenheft?
Frage:
Was ist der Unterschied zwischen Lastenheft und Pflichtenheft?
Antwort (klar und vollständig):
Lastenheft:
- Wird vom Auftraggeber erstellt
- Beschreibt was das System können soll
- Enthält die Ziele, Anforderungen und Rahmenbedingungen des Projekts
- Technisch noch nicht detailliert
- Dient als Grundlage für Angebote oder die Pflichtenhefterstellung
- Kann in frühen Phasen noch verändert werden
Beispiel:
„Das Fahrzeug soll selbstständig einparken können.“
→ Zielbeschreibung ohne technische Details
Pflichtenheft:
- Wird vom Auftragnehmer erstellt
- Beschreibt wie die Anforderungen aus dem Lastenheft umgesetzt werden
- Enthält konkrete technische Lösungen, Methoden, Schnittstellen und Umsetzungsschritte
- Nach Auftragserteilung meist festgelegt (Vertrag)
Beispiel:
„Ein Ultraschallsensor misst den Abstand zu Hindernissen, die Einparkfunktion wird über Steuergerät X geregelt.“
Merksatz:
Lastenheft = Was soll das System tun? (vom Kunden)
Pflichtenheft = Wie wird es technisch umgesetzt? (vom Entwickler)
Beide Dokumente sind zentrale Bausteine im Entwicklungsprozess und bilden die Basis für klare Kommunikation zwischen Kunde und Entwickler.
Was ist eine Anforderungsspezifikation?
Die Anforderungsspezifikation ist ein Dokument, das alle Anforderungen an ein System präzise und eindeutig beschreibt. Sie stellt sicher, dass alle Beteiligten (z. B. Entwickler, Kunden, Tester) das gleiche Verständnis darüber haben, was gebaut werden soll.
Sie ist eine konkrete Ausarbeitung des Lastenhefts und Grundlage für das Pflichtenheft.
Wozu dient sie?
Klare Kommunikation zwischen Kunde und Entwickler
Grundlage für Tests (jede Anforderung kann überprüft werden)
Basis für Zeit- und Kostenplanung
Vermeidung von Missverständnissen
Was steht drin?
Funktionale Anforderungen: Was das System tun soll
Nicht-funktionale Anforderungen: Wie gut es funktionieren soll (z. B. Reaktionszeit, Sicherheit)
Randbedingungen: Normen, Schnittstellen, Umgebungsbedingungen
Abnahmekriterien: Wann gilt eine Anforderung als erfüllt?
Beispiel:
„Das System muss den Abstand zu einem Hindernis innerhalb von 0,5 Sekunden nach Erkennung anzeigen.“
Merksatz:
Die Anforderungsspezifikation ist das präzise Pflichtenheft der Anforderungen – sie beschreibt, was genau erwartet wird, damit Entwickler und Tester wissen, was zu tun ist.
Was ist ein Stakeholder und was ist eine Stakeholderanalyse?
Stakeholder sind alle Personen oder Gruppen, die ein Interesse am Projekt haben oder davon betroffen sind – direkt oder indirekt.
Beispiele für Stakeholder:
Kunden und Nutzer
Entwickler, Projektleiter, Manager
Gesetzgeber, Prüforganisationen
Zulieferer
Versicherungen, Werkstätten
Gesellschaft (z. B. bei Umweltschutz, Sicherheit)
Warum sind Stakeholder wichtig?
Weil sie Anforderungen, Erwartungen und Meinungen haben, die berücksichtigt werden müssen.
Wenn wichtige Stakeholder ignoriert werden, kann das zu Problemen oder Ablehnung des Produkts führen.
Stakeholderanalyse:
Das ist der Prozess, bei dem man:
alle Stakeholder identifiziert,
ihre Interessen, Macht und Einfluss analysiert
und daraus ableitet, wer wie stark berücksichtigt werden muss.
Ziel:
Erwartungen verstehen
Konflikte früh erkennen
Entwicklung zielgerichtet und akzeptiert gestalten
Merksatz:
Stakeholder sind alle, die vom Projekt betroffen sind.
Die Stakeholderanalyse hilft, ihre Erwartungen gezielt in die Entwicklung einzubeziehen.
Was ist eine Customer Story und was ist ein Use Case?
Customer Story:
Eine kurze Beschreibung aus Sicht des Nutzers, was er will und warum.
Formuliert wird meist in der Ich-Form, z. B.:
„Ich möchte, dass mein Auto automatisch bremst, wenn ein Hindernis auftaucht, damit ich sicher fahren kann.“
→ Ziel: Verständnis für Nutzerbedürfnisse schaffen (emotional & alltagsnah)
Use Case (Anwendungsfall):
Beschreibt konkret, wie das System in einer bestimmten Situation genutzt wird – also Ablauf und Beteiligte.
Beispiel:
„Fahrer startet Motor → Sensor erkennt Hindernis → System löst Bremse aus.“
→ Ziel: technisch nachvollziehbare Szenarien abbilden
Merksatz:
Customer Story = Was will der Nutzer?
Use Case = Wie läuft das ab?
Beides hilft, Anforderungen nutzerorientiert zu erfassen.
Wie werden aus unscharfen Aussagen klare Anforderungen?
Auf Seite 118 geht es darum, wie man aus vagen Aussagen konkrete Anforderungen ableitet. Gezeigt wird, wie man aus einer unscharfen Idee Schritt für Schritt eine präzise Anforderung entwickelt.
Beispielhafte Aussagen aus Seite 118:
„Das Auto soll schnell fahren.“
→ Unklar, was „schnell“ heißt.
„Das Fahrzeug soll 250 km/h fahren.“
→ Klar messbare, technische Anforderung.
„Huiiiiii“
→ Emotionale Aussage – kein technischer Wert, aber Hinweis auf Kundenwunsch oder Gefühl.
Wichtig dabei:
Man muss zwischen Wunsch, Ziel und technischer Anforderung unterscheiden:
Problembeschreibung: allgemein („soll schnell sein“)
Lastenheft: Zielbeschreibung („250 km/h erreichen“)
Pflichtenheft: technische Umsetzung („Motorleistung X, Getriebe Y“)
Merksatz:
Aus vagen Aussagen (z. B. „schnell“) müssen klare, überprüfbare Anforderungen (z. B. „250 km/h“) gemacht werden. Nur so kann später richtig entwickelt und getestet werden.
Was ist Requirements Engineering? (nach Seite 124)
Requirements Engineering ist der strukturierte Prozess zum Sammeln, Verstehen, Dokumentieren und Prüfen von Anforderungen an ein System.
Ziel:
Die Wünsche und Bedürfnisse aller Stakeholder frühzeitig und vollständig erfassen, um spätere Fehler, Missverständnisse und teure Änderungen zu vermeiden.
Typische Schritte:
Anforderungen ermitteln (z. B. durch Interviews, Beobachtungen)
Anforderungen analysieren und strukturieren
Anforderungen dokumentieren (klar, messbar, eindeutig)
Anforderungen prüfen und abstimmen (z. B. durch Tests oder Reviews)
Herausforderungen laut Folie 124:
Unklare Ziele
Sich ändernde Anforderungen
Sprachprobleme zwischen Technik & Fachbereichen
Verlust von Wissen im Projektverlauf
Merksatz:
Requirements Engineering sorgt dafür, dass das richtige System entwickelt wird, und zwar auf Basis klarer und abgestimmter Anforderungen.
Was sind FA (funktionale Anforderungen) und NFA (nicht-funktionale Anforderungen)?
FA = Funktionale Anforderungen
→ Beschreiben, was ein System tun soll.
Beispiel: „Das Fahrzeug soll automatisch bremsen, wenn ein Hindernis erkannt wird.“
NFA = Nicht-funktionale Anforderungen
→ Beschreiben, wie gut das System etwas tun soll.
Beispiel: „Das System muss innerhalb von 0,5 Sekunden reagieren“ oder „Die Anzeige muss bei Sonnenlicht lesbar sein.“
Unterschied:
FA = Funktion
NFA = Qualität, Leistung, Sicherheit, Benutzerfreundlichkeit
Merksatz:
FA = Was tut das System?
NFA = Wie gut tut es das?
Was bedeutet Systemintegration?
Systemintegration ist der Schritt, bei dem alle entwickelten Einzelteile eines Systems (z. B. Software, Hardware, Sensoren, Aktoren, Steuergeräte) zusammengeführt und als Gesamtsystem getestet werden.
Ziele der Systemintegration:
Prüfen, ob alle Komponenten zusammen funktionieren
Sicherstellen, dass alle Anforderungen erfüllt werden
Fehler im Zusammenspiel frühzeitig erkennen und beheben
System auf Akzeptanz und Nutzbarkeit testen
Wichtige Begriffe:
Verifikation: Prüfen, ob das System korrekt gebaut wurde (technisch richtig)
Validierung: Prüfen, ob das richtige System gebaut wurde (für den Nutzer sinnvoll)
Testfälle basieren immer auf Anforderungen:
Verwendung der Methode „Given – When – Then“
Beispiel:
Given: Tür ist verriegelt
When: Entriegelungssignal kommt
Then: Tür wird in 0,2 s entriegelt
Warum ist Systemintegration so wichtig?
Fehler in Schnittstellen oder Wechselwirkungen sind schwer vorherzusehen, aber häufig
Integration erlaubt, echte Szenarien zu simulieren
Grundlage für Akzeptanztests und Qualitätsprüfung
Beispiel:
Im Auto muss die Kombination aus Radar, Bremssystem, Software und Anzeige beim Notbremsassistenten fehlerfrei zusammenarbeiten.
→ Nur durch Systemintegration kann man das vollständig testen.
Merksatz:
Systemintegration heißt: Einzelteile zusammenfügen, testen und prüfen, ob das gesamte System funktioniert, sicher ist und die Anforderungen erfüllt.
Was bedeutet Produktlebenszyklus?
Der Produktlebenszyklus beschreibt alle Phasen, die ein Produkt durchläuft – von der ersten Idee bis zur Entsorgung.
Typische Phasen:
Entwicklung – Planung, Anforderungen, Konstruktion, Tests
Produktion – Herstellung, Qualitätssicherung
Nutzung – Betrieb beim Kunden (Wartung, Updates)
Service – Reparatur, Ersatzteile
Entsorgung/Recycling – Lebensende des Produkts
Wichtig laut Seite 165:
Die Lebensdauer eines Systems hängt stark von den Einzelkomponenten ab.
Beispiel: Wenn ein Bauteil nur 300 statt 500 Stunden hält →
→ mehr Ersatzteile, mehr Personal, mehr Lagerplatz nötig
Das wirkt sich direkt auf Kosten, Planung und Service aus.
Ziel:
Schon in der Entwicklung überlegen, wie langlebig, wartbar und wirtschaftlich das Produkt über seine gesamte Nutzungszeit ist.
Merksatz:
Der Produktlebenszyklus umfasst Entwicklung, Nutzung und Entsorgung – und beeinflusst Qualität, Kosten und Service über die gesamte Lebensdauer hinweg.
Warum sollte man Systemintegration schon in frühen Phasen durchführen?
Wenn man früh mit der Systemintegration beginnt, kann man Probleme im Zusammenspiel der Komponenten rechtzeitig erkennen und lösen – bevor es teuer und aufwendig wird.
Vorteile der frühen Integration:
Fehler werden früh entdeckt (z. B. bei Schnittstellen, Signalübertragung)
Kosten und Zeit werden gespart, weil Änderungen später viel aufwendiger sind
Test und Entwicklung laufen parallel → schnelleres Feedback
Risiken werden minimiert, z. B. bei sicherheitskritischen Systemen
Typische Methoden:
Model-in-the-Loop (MiL)
Software-in-the-Loop (SiL)
Hardware-in-the-Loop (HiL)
→ Damit kann man auch ohne fertige Hardware testen
Merksatz:
Frühe Integration spart Zeit, Kosten und Nerven – und verbessert die Qualität des Gesamtsystems deutlich.
