meine antworten auf die fragen von der se-seite frei nach erinnerung (also kein anspruch auf richtigkeit):
Wieso sind die Lastenhefte viel dicker geworden, seit die Zulieferer reifere Prozesse haben?
weil man für reifere prozesse auch viel genauere informationen braucht (und spätere änderungwünsche vom auftraggeber auch meist nicht mehr drin sind).
Nennen Sie zwei Beispiele für "mitgeltende Unterlagen". Wieso sollte ein OEM nicht einfach alle nennen, die ihm einfallen?
mitgeltende unterlagen sind dokumente, die der auftragnehmer zusätzlich zum lastenheft zu berücksichtigen hat. hier kommt theoretisch jedes beliebige dokument in frage, sinnvoll sind aber eher so sachen wie normen oder vorgaben für den code etc..
der oem sollte deshalb nicht alles nennen, was ihm einfällt, weil das den auftragnehmer unnötig zeit und den oem damit unnötig geld kostet.
Wieso findet man in Lastenheften selten UML?
weil uml nicht zum standardhandwerkzeug von maschinenbauern und anderen leuten aus der automobilbranche gehört.
Wieso ist gerade Requirements Engineering so wichtig für die deutschen OEMs?
weil es beim autobau so RICHTIG teuer wird, wenn man am anfang etwas vergisst und es später ergänzen muss (teilweise lassen die verträge es gar nicht zu).
Wieso schreiben gerade Informatiker Lastenhefte? Wie wird mit Umweltschutz- und Korrosionsaspekten umgegengen, von denen sie nichts verstehen?
informatiker haben (zumindest in der theorie) von anforderungserhebung, lastenheften usw. am meisten ahnung. bei spezialbereichen müssen sie sich entweder einlesen oder einen fachmann zur hilfe rufen.
Bei der Lastenheftprüfung gibt es harte und mögliche Schwachstellenbefunde. Nennen Sie je ein Beispiel und erklären Sie den Unterschied.
harte Schwachstellenbefunde sind eindeutige fehler. z.b. eine referenz auf ein nicht vorhandenes dokument.
mögliche Schwachstellenbefunde sind halt potenzielle fehler wie passiv-sätze oder weak words.
Nennen Sie einen Grund, wieso eine modellbasierte Spezifikation (z.B. Statemate) zu insgesamt schlechteren Ergebnissen führt als eine textuelle.
modellbasierte spezifikationen wirken häufig schon fertig und stehen im verdacht fehlerfrei zu sein, weshalb die gefahr besteht, dass die entwickler sie nur noch ausprogrammieren und nicht mehr überprüfen.
So berichte uns weiter, sagte Diarmuid Donn, um der Liebe Gottes willen.
Fürwahr, sagte Finn, ich will nicht.
This post has been edited 1 times, last edit by "Finn MacCool" (Feb 13th 2011, 12:03am)