Eintrag kommentierenEintrag bewerten
Dieser Eintrag wurde im Schnitt mit 0 von 5 Punkten bewertet
Erfahrung
Mythen im Requirements-Engineering
Erfahrung:24926
Externe Quellen zum Thema NEU: Externe Quellen zum Thema suchen 
Beschreibung der Erfahrung
Die werkzeugbasierte Verwaltung von Software-Anforderungen kann im Automotive Software-Engineering mittlerweile als Stand der Praxis bezeichnet werden. Zur weiteren Verbesserung im Requirements Engineering finden sich in der Literatur viele Lösungsvorschläge, die aber aus der täglichen Praxis heraus kritisch betrachtet werden müssen. Im folgenden werden vier Vorschläge näher betrachtet:

Mythos der formalen Spezifikation
Die menschliche Sprache als Spezifikationsmittel wird oft kritisiert, da sie oft unvollständig, ungenau, missverständlich usw. ist. Formale Spezifikationssprachen werden hier meist als Allheilmittel empfohlen. Sie sind aus unserer Sicht aber nur für bestimmte (z.B. sicherheitskritische) Teilsysteme sinnvoll, denn:
  • Anforderungen sind ein Mittel zur Kommunikation über das Produkt. Formale Spezifikationen sind nur für wenige verständlich.
  • Nicht alle Anforderungen lassen sich formal spezifizieren (z.B. Sicherheits-Anforderungen)
  • Formale Spezifikation nimmt Design-Entscheidungen vorweg. Dies liegt daran, dass jeder Beschreibungsformalismus bestimmte Sachverhalte sehr gut beschreiben kann (z.B. zustandsbasiertes Verhalten), andere Sachverhalte aber mit den beschränkten Mitteln des Formalismus „ausprogrammiert“ werden müssen.
Beispiel für ein formal spezifiziertes Teilssystem
Beispiel für ein formal spezifiziertes Teilsystem


Mythos der vollen Verfolgbarkeit
Oft wird die vollständige und feingranulare Verfolgbarkeit der Anforderungen zum Design, über die Implementierung bis zum Testen gefordert. Diese ist aus unserer Sicht nicht erstrebenswert:
  • Der Aufwand für ein vollständiges Tracing steht in keinem Verhältnis zum Nutzen
  • Teillösungen (z.B. der Einsatz von hierarchischen Beziehungen) bieten oft vergleichbaren Nutzen (beantworten z.B. die Frage „welche Funktionen sind in welchem Steuergerät umgesetzt“), sind aber deutlich einfacher umzusetzen und zu pflegen
Mythos der perfekten Anforderungsspezifikation von Anfang an
Alle Anforderungen gleich zu Projektbeginn fest zu haben ist nach unseren Erfahrungen nicht realistisch. Insbesondere reicht es nicht, den Kunden beim ersten Treffen gründlich genug zu fragen.
  • Nicht alle Eigenschaften lassen sich zu vernünftigen Kosten früh festlegen.
  • Änderungen und Ergänzungen während der Entwicklung sind wichtig, um ein konkurrenzfähiges, optimales Produkt zu entwickeln. Ein effizienter Entwicklungsprozess zeichnet sich daher dadurch aus, dass er gut mit Änderungen umgehen kann.
Mythos der gemeinsamen Datenbank
Viele Hersteller von Requirements-Management-Tools preisen die Vorzüge an, die eine gemeinsame Datenbank zwischen Auftraggeber und Auftragnehmer hat.
Aus drei essenziellen Gründen ist dies jedoch in der Automobilindustrie (und auch anderen Branchen) nicht möglich:
  • Haftung: wer haftet bei Ausfällen der gemeinsamen Datenbank?
  • Geistiges Eigentum: nicht alle Informationen sollen für jeden sichtbar sein. Da jeder OEM mehrere Lieferanten hat und jeder Lieferant für mehrere OEM arbeitet, kann keiner vollständiger Eigner (Administrator) der Datenbank sein.
  • Online-Zugriff erschwert systematische Entwicklung (tagesaktuelle Änderungen verhindern einen klaren Bezugspunkt für die Entwicklung)
Erfahrungen bereitgestellt durch:
Dr. Frank Houdek , DaimlerChrysler Research

Die Erfahrungen sind auch in einem Papier veröffentlicht (s. Future Trends in Automotive Requirements Engineering).
Studientypen
Einzelbeobachtung
Externe Quellen zum Thema NEU: Externe Quellen zum Thema suchen 
 Eintrag kommentieren 
 Eintrag bewerten 
Zu dieser Seite wurden noch keine Kommentare oder Bewertungen abgegeben.
 
Zum Seitenanfang Top Drucken Impressum AGB
Home

VSEK ©2001-2017