-
HINTERGRUND DER ERFINDUNG
-
1. Gebiet der Erfindung
-
Diese Erfindung bezieht sich im Allgemeinen auf ein Verfahren zum Verwalten von Entwurfsanforderungen für ein Fahrzeugentwicklungsprogramm und insbesondere auf einen Anforderungsverwaltungsprozess, der ein Archiv von geeignet definierten Anforderungen erzeugt und der die Konsistenz von technischen Begriffen und Datenelementen, wenn sie auftreten, prüft.
-
2. Erläuterung der verwandten Technik
-
Moderne Fahrzeuge sind sehr komplexe Anordnungen von mechanischen und elektronischen Systemen, und der Prozess des Definierens der Spezifikationen für ein Fahrzeug und seine Anforderungen kann gleichermaßen komplex sein. Die Systeme eines Fahrzeugs werden als Gruppen von Merkmalen definiert, wobei jede Merkmalsspezifikation mehrere Anforderungen aufweist. Ein beispielhaftes Merkmal ist ein ferngesteuerter schlüsselloser Zugang, und jede Anforderung spezifiziert eine Betriebseigenschaft des Merkmals. Sogar bei einem Beispiel wie diesem, bei dem das Merkmal und die Anforderungen zuerst einfach erscheinen mögen, können die Anforderungen in Wirklichkeit von verschiedenen Quellen stammen und in verschiedenen Formaten dokumentiert werden, und dies führt zu Komplikationen, wenn sie genau erfasst werden. Ferner können verschiedene Personen einem bestimmten technischen Begriff oder Datenelement eine unterschiedliche Bedeutung beimessen, und dieser Definitionsunterschied kann in dem Anforderungsdefinitionsprozess Verwirrung und Unsicherheit erzeugen.
-
Über die Jahre wurden verschiedene Computerwerkzeuge und Verfahren entwickelt, um den Prozess des Definierens von Produktmerkmalen und des Erfassens von Anforderungen zu unterstützen. Während jedes einzelne Werkzeug oder Verfahren für einen Aspekt des Merkmalsdefinitionsprozesses nützlich sein kann, wurde nicht nachgewiesen, dass sie beim Übermitteln des gewünschten Endergebnisses effektiv sind – was einen Satz von Merkmalsdefinitionen umfasst, die von jedem Produktentwicklungsteam verwendet werden können, die auf klaren, prägnanten und genauen Anforderungen basieren und die nur Daten enthalten, die durch einen geeigneten Inhaber überprüft, getestet und zugelassen wurden.
-
Es besteht Bedarf an einem Satz von Verfahren und Unterstützungssoftwarewerkzeugen, um Merkmalsdefinitionen zu erfassen, gültige Anforderungen zu konstruieren, Begriffe und Datenelemente klar zu definieren und alle diese Dokumente und Daten in einem Archiv zu verwalten, das jedem zur Verfügung steht, der einen Beitrag dazu leisten oder sie verwenden muss.
-
ZUSAMMENFASSUNG DER ERFINDUNG
-
Gemäß den Lehren der vorliegenden Erfindung werden Verfahren zum Verwalten von Entwurfsanforderungen für ein Fahrzeugentwicklungsprogramm offenbart. Es werden ein Anforderungsverwaltungsprozess und ein Softwarewerkzeug beschrieben, die sicherstellen, dass nur geeignet definierte Anforderungen in einem Archiv gespeichert werden. Anforderungen werden hinsichtlich eines strukturierten Satzes von Regeln validiert, bevor sie in das Archiv eingebracht werden dürfen, und es können nur validierte Anforderungen ausgelesen und für Fahrzeugentwicklungsaktivitäten verwendet werden. Der Prozess und das Werkzeug prüfen auch die Konsistenz von technischen Begriffen und Datenelementen, wenn sie auftreten.
-
Weitere Merkmale der vorliegenden Erfindung werden aus der folgenden Beschreibung und den beigefügten Ansprüchen in Verbindung mit den begleitenden Zeichnungen ersichtlich.
-
KURZBESCHREIBUNG DER ZEICHNUNGEN
-
1 ist ein Flussdiagramm eines Merkmalsentwicklungsprozesses;
-
2 ist ein beispielhaftes Zustandsübergangsdiagramm wie es bei dem in 1 gezeigten Merkmalsentwicklungsprozess verwendet wird;
-
3 ist ein beispielhaftes Kontextdiagramm wie es bei dem in 1 gezeigten Merkmalsentwicklungsprozess verwendet wird;
-
4 ist ein Flussdiagramm eines Anforderungserhebungsprozesses;
-
5 ist ein Bildschirmbild einer Anforderungseditierungsvorlage von einem Anforderungserhebungssoftwarewerkzeug;
-
6 ist ein Blockdiagramm eines Softwarewerkzeugs, das für die Verwaltung von Datenelementen, technischen Begriffen und Akronymen verwendet wird;
-
7 ist ein Bildschirmbild einer Funktionsdefinitionsvorlage von einem Begriffsverwaltungssoftwarewerkzeug;
-
8 ist ein Bildschirmbild einer Datenelementdetailvorlage von einem Begriffsverwaltungssoftwarewerkzeug;
-
9 ist ein Flussdiagramm eines Prozesses zum Prüfen von Anforderungen in ein und aus einem Anforderungsarchiv; und
-
10 ist ein Blockdiagramm eines Softwarewerkzeugs, das für den in dem Flussdiagramm von 9 gezeigten Anforderungseinbringungs- und -ausleseprozess verwendet wird.
-
DETAILLIERTE BESCHREIBUNG DER AUSFÜHRUNGSFORMEN
-
Die folgende Erläuterung der Ausführungsformen der Erfindung, die auf ein Verfahren zum Verwalten von Entwurfsanforderungen für ein Fahrzeugentwicklungsprogramm gerichtet sind, ist lediglich beispielhafter Natur und beabsichtigt keineswegs, die Erfindung oder ihre Anwendungen oder Verwendungen zu beschränken.
-
Der Prozess des Entwerfens und Entwickelns eines modernen Kraftfahrzeugs ist in der Tat ein komplexer. Wettbewerbsdruck und Kundenerwartungen haben Kraftfahrzeughersteller dazu gebracht, mehr Merkmale zu einem geringeren Preis auf einer inflationsangepassten Basis bereitzustellen. Der Wettbewerbsdruck erfordert auch, dass Kraftfahrzeughersteller neue Fahrzeugprogramme in einem zunehmend schnelleren Zeitzyklus entwickeln. Um ein neues Fahrzeugentwicklungsprogramm in weniger als zwei Jahren abzuschließen, wie es nun der Maßstab in der Industrie ist, müssen Kraftfahrzeughersteller sicherstellen, dass Merkmale, die in Fahrzeugen umfasst sein sollen, klar spezifiziert und getestet werden, bevor ein neues Fahrzeugprogramm die Merkmale verwendet. Dies bedeutet, dass Merkmale, wie beispielsweise ein Speichersitzsystem oder eine Heckscheibenheizung, unabhängig von der Fahrzeugplattform, an der sie angewandt werden, hinsichtlich klarer Anforderungen definiert werden müssen.
-
Während ein großer Fortschritt beim Verkürzen des Zeitzyklus für eine neue Fahrzeugentwicklung und beim Verbessern des Inhalts und der Qualität der resultierenden Fahrzeuge gemacht wurde, müssen weitere Verbesserungen gemacht werden. Die Verfahren der vorliegenden Erfindung würden einem Kraftfahrzeughersteller ermöglichen, Fahrzeugmerkmale auf eine plattformunabhängige Weise zu entwickeln, jene Merkmale hinsichtlich geeignet konstruierter Anforderungen zu definieren, sicherzustellen, dass alle technischen Begriffe und Datenelemente auf eine konsistente und zulässige Weise definiert sind und alle Dokumente und Daten, die mit den Merkmalen und Anforderungen in Verbindung stehen, auf eine Weise zu organisieren, die für jeden zugänglich ist, der sie verwenden oder einen Beitrag dazu leisten muss.
-
An dieser Stelle ist es hilfreich, die Terminologie zu definieren, die in dieser Offenbarung verwendet wird. Ein System besteht aus einem oder mehreren Merkmalen. Ein Merkmal besteht aus der Software und Hardware, die benötigt werden, um einen eindeutigen Fahrzeugbetrieb bereitzustellen. Sowohl Systeme als auch Merkmale erfordern ein Spezifikationsdokument. Eine Spezifikation ist ein strukturiertes Dokument, das vorgibt, was gebaut werden soll, indem Zeichnungen, Dokumente und Anforderungen einbezogen werden. Eine Anforderung ist eine eindeutige, widerspruchsfreie, strukturierte Aussage, die testbar ist. Eine Einrichtung ist ein physikalisches Element, das einen Betrieb, entweder mit Hardware und/oder mit Software, durchführt.
-
Um die oben beschriebenen Ziele zu erreichen ist ein Gesamtprozess für eine Merkmalsentwicklung erforderlich. 1 ist ein Flussdiagramm 10 eines Merkmalsentwicklungsprozesses. Der Prozess beginnt in Kasten 12 mit einer Merkmalsidee. Das Merkmal könnte etwas Neues sein, wie es vor einigen Jahren ein Fahrzeugnavigationssystem gewesen wäre, oder es könnte eine neue Definition eines alten Merkmals sein, wie beispielsweise ein Scheibenwischersystem. Die Merkmalsidee könnte von einer beliebigen einer Vielzahl von Quellen stammen, die interne Firmenabteilungen wie Marketing oder Engineering oder externe Quellen wie Kundenrückmeldungen umfassen. Sobald eine Merkmalsidee erfasst wurde, werden in Kasten 14 Anforderungen auf hoher Ebene entwickelt. Die Anforderungen auf hoher Ebene sollten die Haupteigenschaften des Merkmals auflisten, indem die Verhalten spezifiziert werden, deren Auftreten erwartet wird. Nach einer vorbereitenden Referenzüberprüfung und einer Zulassung der Anforderungen auf hoher Ebene werden in Kasten 16 detailliertere Anforderungen entwickelt. An dieser Stelle sollten die Anforderungen unter Verwendung eines formalen Anforderungsdefinitionsprozesses entwickelt werden, der später erläutert wird.
-
Auf dem Gebiet der Anforderungsdefinition gibt es viele verschiedene Typen von Anforderungen und verschiedene Anforderungsebenen, die verstanden werden müssen. Typen von Anforderungen umfassen funktionale Anforderungen, parafunktionale Anforderungen, nicht funktionale Anforderungen, Diagnoseanforderungen, Gefahrenanforderungen und andere. Funktionale Anforderungen beschreiben, was von einem System erwartet wird, das es tun soll, beschreiben jedoch nicht, wie dies getan werden soll. Wenn beispielsweise ein Merkmal erfordert, dass eine Maschinendrehzahl unter einer bestimmten Anzahl von Umdrehungen pro Minute bleiben soll, würde die Anforderung dies aussagen, würde jedoch nicht versuchen, zu beschreiben, wie der Controller diese Anforderung realisieren würde. Parafunktionale Anforderungen beschreiben eine Umgebungs- oder Unterstützungsanforderung anstatt einer Funktion, die das Merkmal ausführen soll. Ein Beispiel einer parafunktionalen Anforderung wäre, dass ein Merkmal eine Spannung in dem Bereich von 12,0–14,5 Volt DC für den Betrieb benötigt. Nicht funktionale Anforderungen berücksichtigen Dinge wie Zuverlässigkeit, Wartungsfreundlichkeit und Fehlertoleranz eines Merkmals. Diagnoseanforderungen definieren die Fähigkeiten, die für die Diagnose von Problemen und Status eines Merkmals erforderlich sind. Gefahrenanforderungen betreffen potentiell gefährliche Konsequenzen möglicher Ausfallbedingungen.
-
Die Ebenen von Anforderungen umfassen eine höhere Ebene, architekturunabhängige Merkmalsanforderungen und fahrzeugplattformspezifische Realisierungsanforderungen einer unteren Ebene. Architekturunabhängige Merkmalsanforderungen umfassen Benutzeranforderungen, funktionale Anforderungen, Gefahrenanforderungen, Diagnoseanforderungen, nicht funktionale Anforderungen, Testfälle, Zustandsübergangsdiagramme und Kontextdiagramme. Fahrzeugplattformspezifische Realisierungsanforderungen umfassen Entwurfsanforderungen, Hardwareanforderungen und aktualisierte Versionen von Testfällen, Zustandsübergangsdiagrammen und Kontextdiagrammen zusammen mit gelernten Lektionen. Realisierungsanforderungen sollten aus einer Kopie der Merkmalsanforderungen erzeugt werden, so dass die ursprünglichen Anforderungen einer höheren Ebene nicht verloren gehen oder modifiziert werden.
-
Nachdem in Kasten 16 funktionale und andere Anforderungen entwickelt wurden, sollte eine Testreihe definiert werden. Dies erfolgt in Kasten 18 durch Entwickeln eines oder mehrerer Tests für jede Anforderung in dem Merkmal. In Kasten 20 werden alle Datenelemente, die in den Anforderungen verwendet werden, identifiziert und werden ihre Attribute definiert. Dies erfolgt, um sicherzustellen, dass Datenelemente präzise definiert werden, um jegliche Ambiguität zu beseitigen. Diese Präzision ist in späteren Stufen des Prozesses absolut notwendig, in denen Simulationsmodelle und schließlich physikalische Prototypen gebaut werden. Die Tasks der Kasten 16, 18 und 20 werden wie durch Kasten 22 gezeigt als Gruppe abgeschlossen. Die Aktivitäten in Kasten 22 stellen die erste umfassende Definition eines Merkmals über die Anforderungen, die in Verbindung stehenden Datenelemente und die Testfälle dar. Im Verlauf der Entwicklungsaktivitäten einer detaillierten Anforderung und eines Testfalls in Kasten 22 wird eine Anzahl an unterstützenden Dokumenten erzeugt. Diese umfassen Zustandsübergangsdiagramme, Kontextdiagramme, Anwendungsfallbeschreibungen und eine vorbereitende Gefahrenanalyse.
-
In 2 ist ein allgemeines Beispiel eines Zustandsübergangsdiagramms 40 gezeigt. Ein Zustandsübergangsdiagramm ist eine Darstellung der verschiedenen Zustände, in denen ein System vorliegen kann, und der Aktionen oder Ereignisse, die bewirken, dass das System von einem Zustand zu einem anderen übergeht. In dem Zustandsübergangsdiagramm 40 umfassen Beispiele für Systemzustände einen aktiven Zustand 42 und einen Ausfallzustand 44. Beispiele für Aktionen und Ereignisse umfassen eine Umschaltaktion 46 und ein Fehler-Trigger-Ereignis 48. Dieser Typ von Diagramm ist in der Technik weithin bekannt.
-
In 3 ist ein allgemeines Beispiel eines Kontextdiagramms 50 gezeigt. Ein Kontextdiagramm ist ein Diagramm, das bei einem Systementwurf verwendet wird, um die wichtigeren externen Faktoren darzustellen, die mit dem vorliegenden System in Interaktion stehen. Dieser Typ von Diagramm zeigt für gewöhnlich das System umgeben von seinen interagierenden Systemen, seiner interagierenden Umgebung und seinen interagierenden Aktivitäten. Das Ziel eines Kontextdiagramms ist, die Aufmerksamkeit auf externe Aktoren und Ereignisse zu richten, die beim Entwickeln eines vollständigen Satzes von Systemanforderungen und Beschränkungen in Betracht gezogen werden sollten. in dem Kontextdiagramm 50 ist das System 52 in der Mitte zusammen mit Eingängen, wie beispielsweise einer Entität 54, und Ausgängen, wie beispielsweise einem Datenspeicher 56, gezeigt. Dieser Typ von Diagramm ist in der Technik auch weithin bekannt. Ein Anwendungsfalldokument beschreibt, wer mit dem System was machen kann und wie das System auf die Aktionen reagiert. Eine Gefahrenanalyse bewertet Risiken, die mit dem System in Verbindung stehen, und identifiziert ein Mittel zum Kontrollieren oder Beseitigen dieser. Diese Dokumente unterstützen alle die detaillierte Anforderungsdefinition und unterstützen die Modellerstellungs- und Verifikationsaktivitäten, die nachfolgend vorgenommen werden.
-
In Kasten 24 werden Systemsimulationsmodelle auf der Grundlage der detaillierten Anforderungen wie definiert entwickelt. Die Systemsimulationsmodelle können eine Vielzahl von Typen umfassen, wobei jedoch ein sehr häufig verwendeter und leistungsstarker Typ von Modell zum Simulieren von elektronischen Systemen und elektronisch gesteuerten mechanischen Systemen unter Verwendung der MATLAB/Simulink-Softwaresuite von The Mathworks entwickelt werden kann. Ein Systemsimulationsmodell dieses Typs kann nicht nur das Echtzeitverhalten des Merkmals simulieren, sondern kann auch Code in Form von Softwarefunktionsblöcken erzeugen, die in einer elektronischen Steuereinheit (ECU von electronic control unit) verwendet werden sollen. Andere Typen von Modellen und Simulationen können auch verwendet werden, um die Anforderungen wie definiert zu analysieren und zu verifizieren. Die Modelle werden oftmals verwendet, um die in Kasten 18 definierten Tests auszuführen, wodurch eine Möglichkeit zum Aktualisieren und Verbessern von sowohl den Anforderungen als auch der Testreihe vor dem kostspieligen Schritt des Aufbauens von Hardware bereitgestellt wird.
-
Wie in Kasten 26 gezeigt sollten alle Datenelemente und Attribute, die bei der Erzeugung der Systemsimulationsmodelle verwendet werden, in einem zentralen Datenwörterbuch definiert werden. Dies stellt sicher, dass die Person, die die Modelle aufbaut und die Anforderungen analysiert, nur Datenelemente verwendet, die durch geeignete Referenzgruppen überprüft und zugelassen wurden. Als Ergebnis der Dokumentation von Datenelementen in dem obigen Kasten 20 wurden auch jegliche neuen Datenelementdefinitionen, die für die Merkmalsanforderungen und Testfälle erforderlich sind, für eine Einbeziehung in das Datenwörterbuch vorgeschlagen und wurden sie entweder akzeptiert oder modifiziert. Wie in Kasten 28 angegeben finden die Aktivitäten der Kasten 24 und 26 zusammen statt; das heißt, nur Datenelemente, die von dem zentralen Datenwörterbuch abgerufen wurden, sollten in den Systemsimulationsmodellen und Anforderungen verwendet werden.
-
Nachdem Modelle erzeugt wurden, um das Verhalten des entwickelten Merkmals zu simulieren, können die Modelle in einer Hardware-in-the-Loop-Umgebung (HIL-Umgebung) wie in Kasten 30 gezeigt verwendet werden. Bei HIL-Simulationen wird das Systemsimulationsmodell verwendet, um das Verhalten des Steuersystems, typischerweise einer elektronischen Steuereinheit, zu modellieren. Die Einrichtung, die gesteuert wird, oftmals Anlage genannt, wird jedoch von dem Modell entfernt und durch tatsächliche physikalische Hardware in einer Laborumgebung ersetzt. HIL-Testen liefert eine Simulationsumgebung, die die Annäherung und Unsicherheit beseitigt, die bei der Modellerstellung der Anlage umfasst sind. Das Verwenden der tatsächlichen physikalischen Hardware für die Anlage verbessert die Wiedergabetreue der Simulation für die ausgewählte Hardware erheblich, insbesondere, wenn die Anlage ein komplexes mechanisches System ist, das Reibung, Spiel, Federung und andere Nichtlinearitäten umfasst, die sehr schwer genau zu modellieren sind. Wenn das Merkmal nicht gut funktioniert, kann eine andere Hardware getestet werden, bis das gewünschte Leistungsvermögen erreicht wird. Im Verlauf des Ausführens des HIL-Simulators werden Betriebsgrenzen für das Merkmal detektiert, wie es in Kasten 32 gezeigt ist. Die Betriebsgrenzen umfassen Grenzen der Anlage, wie beispielsweise Bewegungsbereich, und andere physikalische und funktionale Grenzen. Wenn während einer HIL-Simulation Betriebsgrenzen detektiert werden, sollten die Grenzen zu der Anforderungsdefinition hinzugefügt werden. Kasten 34 zeigt, dass die Betriebsgrenzendetektion von Kasten 32 an die HIL-Simulation von Kasten 30 gebunden ist. Ein weiteres wichtiges Ergebnis der Aktivitäten in Kasten 34 ist die Auswahl von Hardwarekomponenten, wie beispielsweise Sensoren und Aktoren. Die Typen, Größen und Bewegungsbereiche dieser Komponenten können mit der HIL-Simulation sorgfältig ausgewertet werden, und die Ergebnisse werden als Teil der Merkmals- und Anforderungsdefinition dokumentiert.
-
Bei Beendigung der HIL-Simulation in Kasten 30 sollte das Steuersystem gut definiert sein. An dieser Stelle kann eine elektronische Steuereinheit eines Prototyps aufgebaut werden, und sie kann mit Softwarefunktionsblöcken programmiert werden, die in einigen Fällen durch die oben beschriebenen Simulationswerkzeuge erzeugt werden können. In Kasten 36 kann das entwickelte Merkmal in einem Fahrzeug getestet werden. Ein fahrzeugbasiertes Testen liefert die beste Simulation dessen, wie ein Merkmal in einer realen Serienfahrzeugumgebung funktioniert. Obwohl nicht alle Elemente der Anlage und des Steuersystems in dieser Stufe eine Serienhardware darstellen, liefert, da das Merkmal auf eine fahrzeugplattformunabhängige Weise entwickelt wird, das fahrzeugbasierte Testen immer noch einen Einblick über den hinaus, der durch eine laborbasierte HIL-Simulation verfügbar ist. Die Vorteile eines fahrzeugbasierten Testens umfassen die Verwendung von realen Fahrzeugdatennetzen und elektrischen Bussen und das Vermögen, ein Fahrzeug tatsächlich unter einer Vielzahl von Testbedingungen zu fahren, anstatt jene Bedingungen in einem Laboraufbau zu simulieren. Das Gefahrenanalysedokument, das in Kasten 22 in einer vorbereitenden Form erzeugt wird, würde in Kasten 36 auch aktualisiert werden.
-
Wenn die Merkmalsentwicklung von den Aktivitäten in Kasten 22 mit Kasten 28, mit Kasten 34 und weiter fortfährt, werden die Anforderungen durch Referenzgruppen überprüft und durch entsprechende Verwaltungsberechtigte zugelassen. Zu dem Zeitpunkt, zu dem das fahrzeugbasierte Testen in Kasten 36 ausgeführt wurde, sollte die Definition des Merkmals und seiner unterstützenden Anforderungen eine hohe Qualitäts- und Detailebene erreicht haben. In dieser Stufe kann in Kasten 38 die technische Merkmalsspezifikation (FTS von Feature Technical Specification) entwickelt werden. Das FTS-Dokument ist der Höhepunkt des Merkmalsentwicklungsprozesses. Die FTS umfasst; alle Anforderungen wie durch den Merkmalsentwicklungsprozess definiert und entwickelt, alle Datenelemente von dem Datenwörterbuch, die zum Unterstützen der Anforderungen erforderlich sind, Zustandsübergangsdiagramme, Kontextdiagramme, Anwendungsfälle, Testprozeduren, Gefahrenanalysen, alle für eine Systemsimulation entwickelten Modelle, eine Komponentenauswahl- und Betriebsgrenzeninformation, die während der HIL-Simulation entwickelt wurde, und alle während der Entwicklung des Merkmals gelernten Lektionen.
-
Aus einem Folgen des umfassenden Merkmalsentwicklungsprozesses können viele Vorteile realisiert werden. Ein Hauptvorteil ist, dass ein Merkmal und seine Anforderungen gründlicher definiert, simuliert, überprüft und zugelassen werden können als mit herkömmlichen stückweisen Verfahren. Die resultierenden Dokumente, Modelle und Simulationsergebnisse liefern ein viel vollständigeres Verständnis dessen, wie ein Merkmal funktionieren kann und wird. Ein weiterer Vorteil ist, dass, sobald ein Merkmalssystemsimulationsmodell entwickelt wurde, es möglich ist, die Merkmalsfunktionen über elektronische Steuereinheiten zu verteilen, die in einem Fahrzeug zur Verfügung stehen würden, wodurch ermöglicht wird, dass existierende ECUS verwendet werden und nicht eine neue ECU zum Unterstützen eines neuen Merkmals erforderlich ist. Während des Merkmalsentwicklungsprozesses können auch Controller- und Softwarefunktionsblöcke definiert werden, sodass sie von verschiedenen Verkäufern bezogen werden können und durch den Kraftfahrzeughersteller, wenn sie einmal entwickelt wurden, wiederverwendet werden können. Dies ist eine wichtige Kostenreduzierungsstrategie für den Kraftfahrzeughersteller. Nach dem Verwenden des fahrzeugplattformunabhängigen Merkmalsentwicklungsprozesses kann das FTS-Dokument durch jedes Fahrzeugentwicklungsteam an jeder Fahrzeugplattform oder -architektur verwendet werden. Dadurch, dass Merkmale und ihre Anforderungen vollständig definiert und entwickelt wurden, bevor ein Fahrzeugentwicklungsprogramm beginnt, kann der Fahrzeugentwicklungsprozess viel schneller abgeschlossen werden, was heutzutage auf dem Markt extrem wichtig ist.
-
In dem Merkmalsentwicklungsprozess ist die genaue Definition von Anforderungen eine wichtige Aktivität. Es wurde beobachtet, dass, obwohl die meisten Ingenieure und anderen Personen, die an einer Produktentwicklung arbeiten, die Anforderungen auf hoher Ebene angemessen beschreiben können, detaillierte Anforderungen oftmals mit Begriffen dokumentiert werden können, die unklar oder mehrdeutig sein können. Aus diesen Gründen wurden ein Anforderungserhebungsprozess und ein entsprechendes Softwarewerkzeug entwickelt. 4 ist ein Flussdiagramm 60 eines Anforderungserhebungsprozesses. In Kasten 62 wird eine Idee erdacht. Die Idee könnte von jemandem in einer Abteilung innerhalb der Firma, wie beispielsweise Engineering oder Marketing, stammen, oder die Idee könnte von einer externen Quelle, wie beispielsweise einem Kunden, stammen. Die Idee könnte sich auf ein Merkmal eines vollständig neuen Produkts beziehen, oder sie könnte eine Idee für eine Verbesserung eines existierenden Merkmals sein. Ungeachtet der Quelle oder Art der Idee ist die nächste Aktivität in Kasten 64 eine Anforderungsaufnahme. Eine Anforderungsaufnahme ist das Herausziehen von oder Führen zu Anforderungen für ein System oder Merkmal durch Diskutieren dieses mit Benutzern, Entwicklern und anderen Berechtigten. Eine Anforderungsaufnahme bietet eine stark ausgedehnte Basis einer Dokumentation für eine Merkmalsidee im Vergleich zu dem Ideenkonzept selbst, das sehr kurz und undetailliert sein kann.
-
Kasten 66 umfasst eine Anforderungsentwicklung, was an und für sich eine signifikante Aktivität ist. Eine Anforderungsentwicklung umfasst das Hernehmen jeder rohen Anforderung, die in dem Aufnahmeschritt dokumentiert wurde, und das Einbauen dieser in eine vollständig entwickelte Anforderungsaussage, die bestimmten Strukturregeln folgt, Klarheitsstandards erfüllt und ein bestimmtes Format annimmt. Der auf die Anforderungsentwicklung ausgedehnte Aufwand soll sicherstellen, dass die dokumentierten Anforderungen klar, prägnant und genau sind und durch jeden zu einem späteren Zeitpunkt ohne Missverständnis aufgenommen und verwendet werden können. Die Entwicklung geeigneter Anforderungen ist so wichtig, dass ein Anforderungserhebungssoftwarewerkzeug erzeugt wurde, um sie zu unterstützen. Das Werkzeug ist entworfen, um das Entwickeln von Anforderungen zu vereinfachen und zu beschleunigen, und um die Qualität und Konsistenz der Anforderungen, die erzeugt werden, zu verbessern.
-
5 ist ein Bildschirmbild einer Anforderungseditierungsvorlage 90 von dem Anforderungserhebungssoftwarewerkzeug. Die Anforderungseditierungsvorlage 90 besteht aus mehreren Abschnitten und hat das Ziel des Einschränkens der zulässigen Worte in bestimmten Feldern zum Verbessern der Klarheit und des Verständnisses von Anforderungen. In dem Eingabetextabschnitt 92 wird eine anfängliche Textdefinition einer Anforderung angezeigt. Die Textbeschreibung einer Anforderung stammt normalerweise von einer früheren Aktivität, wie beispielsweise der Anforderungsaufnahme oder vorherigen Spezifikationen, und beschreibt, welche Aktion durch ein bestimmtes System unternommen werden saute, falls und wenn ein bestimmtes Ereignis auftritt. Das Anforderungserhebungssoftwarewerkzeug umfasst einen Parser zum Auseinanderziehen des Eingabetexts und Einsetzen von Stücken des Texts in entsprechende Felder einer Aufbauvorlage 94. Die Aufbauvorlage 94 umfasst zahlreiche Datenfelder, die verwendet werden, um jede Anforderung hinsichtlich spezifischer Elemente und Aktionen aufzubauen. Jede Anforderung weist eine Anforderungsidentifikation (Anf ID) und eine Anforderungsnummer (Anf #) auf. Die Anforderungsidentifikation ist lediglich ein sequentieller numerischer Wert, der verwendet wird, um jede Anforderung eindeutig zu identifizieren. Die Anforderungsnummer ist ein Code, der konstruiert wird, um den Typ von Anforderung, beispielsweise eine Benutzeranforderung oder eine Gefahrenanforderung, zu bezeichnen und auch, um die Ebene der Anforderung in der Hierarchie von Anforderungen zu bezeichnen.
-
System von Interesse bezeichnet, welches Fahrzeugmerkmal der Gegenstand dieser Anforderung ist. Das System von Interesse muss genau definiert werden. In Verbindung damit werden dann ein Imperativfeld und eine Aktionsaussage verwendet, so dass das Imperativfeld die Einleitung der Aktionsaussage ist. Der Imperativwert muss aus einer Klappliste ausgewählt werden, wobei die zulässigen Werte umfassen; soll, muss, ist oder sollte. Das Aktionsfeld beschreibt, welche Aktion das System von Interesse ausführen soll. Ziel ist die Einrichtung, auf die eingewirkt wird. Beispielsweise könnte die Aktion umfassen, einen Ton unter Verwendung des Fahrzeuglautsprechersystems erklingen zu lassen, oder eine Informationsnachricht für den Fahrer an der Armaturenbrettanzeige anzuzeigen. Dem Aktions- und Zielfeld folgt eine Bedingungsaussage. Die Bedingungsaussage besteht aus mindestens zwei Teilen. Der erste Teil ist eine Klapplistenauswahl, bei der der üblichste Wert wenn ist. Der zweite Teil der Bedingung ist eine Textbeschreibung der Bedingung, die getestet wird, wenn beispielsweise das Bremspedal niedergedrückt wird. Es ist auch möglich, eine Verbundbedingungsaussage zu definieren, die mehr als eine getestete Bedingung umfasst, verbunden durch einen 'und'-Operator oder einen 'oder'-Operator. Schließlich wird ein Bedingungsergebnisfeld auf die Bedingungsaussage angewandt, um zu ermitteln, ob die Aktion ausgeführt werden soll. Wenn beispielsweise das Bedingungsergebnis auf Wahr gesetzt wird, wird die Aktion in dem Fall ausgeführt, dass herausgefunden wird, dass die Bedingung wahr ist. Das Bedingungsergebnis kann auch auf Falsch gesetzt werden. Der Endteil der Aufbauvorlage 94 ist ein Begründungsfeld, das für den Anforderungsautor verwendet wird, um den Grund hinter der Anforderung zu beschreiben. Die Textbeschreibung in dem Begründungsfeld ist oftmals hilfreich für andere Personen als den Autor, die die Anforderung zu einem späteren Zeitpunkt lesen können.
-
In dem Ausgabetextfeld 96 schreibt das Softwarewerkzeug erneut die Anforderung auf der Grundlage der spezifischen Elemente, die in der Aufbauvorlage 94 definiert wurden. Zusammenfassend liest die Anforderungseditierungsvorlage 90 eine Textanforderungsaussage in das Eingabetextfeld 92, parst sie sie in ihre Komponenten in der Aufbauvorlage 94, ermöglicht sie dem Benutzer, die Anforderungskomponenten in der Aufbauvorlage 94 interaktiv zu aktualisieren und schreibt das Anforderungserhebungssoftwarewerkzeug die Endform der Anforderung in das Ausgabetextfeld 96. Die Endform der Anforderung hält alle Regeln und Standards für Syntax, Inhalt, Klarheit und Format ein. Es ist wichtig, zu erkennen, dass eine einzelne ursprüngliche Anforderung von dem Eingabetextfeld 92 durch das Softwarewerkzeug in zwei oder mehr Endanforderungen aufgeteilt werden kann, so dass jede Endanforderung eine einzelne, widerspruchsfreie testbare Aussage über ein Fahrzeugmerkmal ist. Es sind andere wichtige Anforderungsautorregeln in das Softwarewerkzeug eingebaut. Diese Regeln umfassen; es sind nur positive Aussagen von Anforderungen zulässig, keine negativen Aussagen; Anforderungen können nur für ausgehende Übergänge von Zuständen festgelegt werden, nicht für eingehende Übergänge; es werden konditionale Anforderungen mit 'wenn' verwendet und nicht mit 'wenn-dann'; und es ist nur eine Aktionsaussage pro Anforderung zulässig. Schließlich verwendet das Softwarewerkzeug ein Nachrichtenfeld 98 zum Aufzeichnen von Informationsnachrichten über die Anforderung, die von dem Autor oder Anderen gesehen werden können.
-
Das Anforderungserhebungssoftwarewerkzeug enthält auch eine Indexseite, um Benutzern zu ermöglichen, nach existierenden Merkmalsanforderungen zu suchen, und eine Attributseite zum Definieren von Attributen jeder Anforderung, wie beispielsweise von Anforderungsstatus und Priorität, Autoren, Prüfern, und anderen Attributen. Das Anforderungserhebungssoftwarewerkzeug tastet auch automatisch Anforderungen hinsichtlich Datenvariablen ab und gleicht beim Parsen einer Anforderung in ihre Komponenten die Variablen mit dem zentralen Datenwörterbuch ab. Ein automatisches Durchsuchen nach Variablen stellt sicher, dass das zentrale Datenwörterbuch mit neuen Anforderungen aktuell gehalten wird, und stellt sicher, dass neue Anforderungen in dem Datenwörterbuch definierte existierende variable Namen verwenden.
-
Wieder auf das Flussdiagramm 60 Bezug nehmend kann das in den vorstehenden Absätzen beschriebene Anforderungserhebungssoftwarewerkzeug verwendet werden, um die Anforderungsentwicklungsaktivität von Kasten 66 abzuschließen. Es ist nicht notwendig, das Anforderungserhebungssoftwarewerkzeug zu verwenden, wobei jedoch die in dem Werkzeug umfassten Regeln und Verfahren einem Autor dabei helfen können, bessere Anforderungen in kürzerer Zeit zu entwickeln. Kasten 68 ist eine Anforderungsanalyse, bei der ein Analyseteam Anwendungsfälle anwendet, Testfälle anwendet, Datenelemente überprüft und andere Analysen durchführt, um zu sehen, ob die entwickelten Anforderungen Sinn machen. Die Personen, die eine Analyse durchführen, können Anforderungen zurück zu der Entwicklung in Kasten 66 senden. Es ist auch möglich, eine Anforderung zu beenden, entweder aus dem Entwicklungskasten 66 an Endpunkt 70 oder aus dem Analysekasten 68 an Endpunkt 72. Wenn eine Anforderung beendet wurde, was bedeutet, dass sie im Kontext des entwickelten Merkmals keinen Sinn mehr macht, sollte die Anforderung einschließlich der Gründe für deren Beendigung dokumentiert werden, sodass eine Information zur Verfügung steht, wenn sie in der Zukunft wieder benötigt wird. Im Verlauf der Anforderungsentwicklung in Kasten 66 oder der Anforderungsanalyse in Kasten 68 könnten auch zusätzliche Anforderungen in Bezug auf die ursprüngliche Idee von Kasten 62 abgeleitet werden. Diese abgeleiteten Anforderungen sollten zurück zu Kasten 62 fließen, um erfasst, erweitert, entwickelt und analysiert zu werden. Die Anforderungen, die in Kasten 68 analysiert wurden, können für eine Zulassung in Kasten 74 weiter gesendet werden. Die Zulassung von Anforderungen erfolgt durch entsprechende Verwaltungsberechtigte für die Anforderung. Vollständig zugelassene Anforderungen gelangen weiter zu einem Anforderungsarchiv am Speicherort 76, an dem sie indiziert werden und für eine zukünftige Verwendung bei einem Merkmalsentwicklungs- oder Fahrzeugentwicklungsprogramm verfügbar bleiben. Es können auch Zulassungspersonen gewählt werden, um eine Anforderung zu beenden, eine Anforderung zur Analyse in Kasten 68 zurückzusenden oder eine Anforderung für eine weitere Entwicklung in Kasten 66 zurückzusenden. Ein Unternehmen kann beständige Anforderungsreferenzüberprüfungsteams für eine Anforderungsanalyse wie in Kasten 78 gezeigt und Anforderungsverwaltungsüberprüfungs- und -zulassungsteams wie in Kasten 80 gezeigt wählen.
-
In der obigen Erläuterung wurde das Konzept eines zentralen Datenwörterbuchs wiederholt erwähnt. Die Wichtigkeit einer klaren Auflistung von Fahrzeugmerkmalen und -funktionen, eines Definierens von Datenelementen und ihren Attributen, eines Vorhandenseins einer einzelnen Standardbedeutung für technische Begriffe und eines zentralen Auflistens der Bedeutung aller Akronyme kann nicht zu stark betont werden. Aus diesem Grund wurde ein weiteres Softwarewerkzeug entwickelt, um alle diese Daten in einem zentralen Archiv zu verwalten, sie jedem zur Verfügung zu stellen, der auf sie zugreifen muss oder einem Beitrag dazu leisten muss, und eine Schnittstelle zu anderen Systemen, wie beispielsweise dem Anforderungserhebungssoftwarewerkzeug, herzustellen.
-
6 ist ein Blockdiagramm eines Begriffsverwaltungssoftwarewerkzeugs 100. Das Begriffsverwaltungssoftwarewerkzeug 100 unterstützt die Definition von Fahrzeugmerkmalen, Softwarefunktionen, Datenelementen oder Variablen, technischen Begriffen und Akronymen. Alle diese Elemente und ihre Attribute und Beziehungen sind in einer Begriffsverwaltungsdatenbank 102 enthalten. Wenn ein Benutzer das Begriffsverwaltungssoftwarewerkzeug 100 startet, wird er aufgefordert, eine Option auszuwählen, wie es in Kasten 104 gezeigt ist. Wenn der Benutzer eine Merkmalsliste 106 auswählt, liefert das Begriffsverwaltungssoftwarewerkzeug 100 eine Liste aller Fahrzeugmerkmale, die in der Datenbank 102 enthalten sind. Ein Merkmal ist ein Fahrzeugsubsystem, wie beispielsweise ein Spurwechselwarnungs- oder ein Speichersitzmerkmal, wie es zuvor bei dem Merkmalsentwicklungsprozess beschrieben wurde. Jedes Merkmal weist einen Merkmalsnamen, eine Beschreibung, ein Akronym und den Namen eines Unternehmensteams auf, das die Inhaberverantwortung für dieses Merkmal hat. Ein Merkmal besteht aus Softwarefunktionen, Sensoren und Aktoren. Während die Merkmalsliste 106 verwendet wird, kann der Benutzer ein neues Merkmal erzeugen, um es zu der Datenbank 102 hinzuzufügen, wie es in Kasten 108 gezeigt ist. Details jedes Fahrzeugmerkmals, das in der Datenbank 102 existiert, können in Kasten 110 angesehen werden oder mit geeigneter Autorität in Kasten 112 editiert werden, indem ein Element aus der Merkmalsliste 106 ausgewählt wird.
-
Wenn der Benutzer die Softwarefunktionsliste 114 auswählt, liefert das Begriffsverwaltungssoftwarewerkzeug 100 eine Liste von Softwarefunktionen in der Datenbank 102. Das Auswählen einer Funktion aus der Softwarefunktionsliste 114 ermöglicht dem Benutzer, die Attribute einer definierten Funktion zu definieren oder die Details einer existierenden Funktion zu betrachten. 7 ist ein Bildschirmbild einer Funktionsdefinitionsvorlage 126 von dem Begriffsverwaltungssoftwarewerkzeug 100. Die in der Vorlage 126 definierte Funktion ist eine Softwarefunktion, die einen Teil eines Merkmals realisiert. Die Funktionsdefinitionsvorlage 126 sorgt für die Definition von allen wichtigen Attributen einer Softwarefunktion, um zu ermöglichen, dass die Funktion verstanden wird, eine Schnittstelle zu ihr hergestellt wird oder sie durch eine andere Person als den Erzeuger der Funktion wiederverwendet wird. Ein Funktionsname, eine Beschreibung und ein Merkmalsname sind alles obligatorische Felder, wobei der Merkmalsname das Merkmal identifiziert, das die Funktion enthält. Der Merkmalsname wird aus einer Klappliste ausgewählt, die als Optionen alle Merkmale in der Datenbank 102 wie oben beschrieben enthält. Es wird ein ECU-Feld verwendet, um zu definieren, welche elektronische Steuereinheit am Fahrzeug die Funktion enthält, wenn diese Information bekannt ist. Ein Taskfeld identifiziert jegliche in Beziehung stehenden Softwarefunktionen, die mit der gleichen Frequenz wie die definierte Funktion ausgeführt werden. Ein Speichertypfeld wird verwendet, um zu definieren, in welchem Typ von Speicher sich die Funktion befindet. Der Speichertyp könnte beispielsweise als RAM oder EPROM ausgewählt werden. Die Speichergröße wird verwendet, um zu definieren, wie viel Speicher von der Funktion eingenommen wird. Die Ausführungszeit gibt an, wie lange es dauert, die Funktion laufen zu lassen oder auszuführen. Die Frequenz bezeichnet das Zeitintervall, in dem die Funktion läuft. Ein Quellenfeld gibt an, wo eine Quellcodedatei, die die Funktion enthält, gespeichert ist. Und ein Modellfeld zeigt, wo ein Systemsimulationsmodell, das die Funktion enthält, gespeichert ist, wenn solch ein Modell existiert.
-
Ein Teil der wichtigsten Information an der Funktionsdefinitionsvorlage 126 ist die Identifikation von Datenelementen, die die Funktion aufnimmt. Ein Eingangsvariablenabschnitt liefert eine Kandidatendatenelementliste, die verwendet werden kann, um Eingangsvariablen für die Funktion auszuwählen. Die Kandidatenliste wird hinsichtlich Relevanz auf der Grundlage des Merkmals, innerhalb dem die Funktion existiert, gefiltert. Aus der Kandidatendatenelementliste kann der Benutzer spezifische Einträge wählen, um sie in eine Eingangsvariablenliste hinüberzuziehen. Die Eingangsvariablenliste identifiziert, welche Datenelemente tatsächlich durch die Funktion verwendet werden. Ein Ausgangsvariablenabschnitt funktioniert in der Hinsicht ähnlich wie der Eingangsvariablenabschnitt, das eine Kandidatendatenelementliste verwendet wird, um tatsächliche Ausgangsvariablen auszuwählen. Zusätzlich zu der Identifikation von Eingangsvariablen und Ausgangsvariablen können andere Konstanten und Variablen identifiziert werden, die in der Funktion verwendet werden, jedoch nicht eingegeben oder ausgegeben werden.
-
Die oben beschriebenen Eingangs- und Ausgangsdatenvariablen werden in dem Datenwörterbuchteil des Begriffsverwaltungssoftwarewerkzeugs 100 gespeichert. Das Datenwörterbuch 116 ist eine Auflistung von allen Datenelementen, die in Softwarefunktionen verwendet werden, und Attributen für jedes Datenelement. Wenn ein Datenelement aus dem Datenwörterbuch 116 ausgewählt wird, können die Details dieses Datenelements betrachtet und, mit entsprechenden Privilegien, editiert werden. 8 ist ein Bildschirmbild einer Datenelementdetailvorlage 130 von dem Datenwörterbuchteilabschnitt des Begriffsverwaltungssoftwarewerkzeugs 100. Die Datenelementdetailvorlage 130 wird durch einen Softwarefunktionsautor, um die wichtigen Attribute eines Datenelements, das in einer Softwarefunktion verwendet wird, zu definieren, oder durch irgendeine andere Person verwendet, um die Attribute eines Datenelements anzusehen. Ein Datenelementname und eine Beschreibung sind obligatorische Felder für einen Abschluss bei einem Erzeugen eines neuen Datenelements. Es ist auch obligatorisch, eine Datenelementkategorie zu definieren, die das Datenelement entweder als Konstante oder als Variable identifiziert. Es wird ein Typfeld verwendet, um den Typ von Datenelement anzugeben, der ein ganzzahliger Typ oder ein Dezimaltyp sein könnte. Ein Auflösungsfeld gibt die Genauigkeit des Datenelements an. Ein Minimalwertfeld und ein Maximalwertfeld enthalten den minimalen bzw. maximalen zulässigen Wert des Datenelements. Ein Anfangswertfeld gibt den Wert des Datenelements an, wenn die Funktion beginnt, wenn nicht und bis das Datenelement auf einen anderen Wert gesetzt wird. Ein Fail-Soft-Wert wird verwendet, um einen Wert des Datenelements zu bezeichnen, der in dem Fall verwendet werden soll, dass die Funktion aufgrund eines Fehlens von Eingangsdaten oder eines anderen Problems keinen geeigneten Wert des Datenelements berechnen kann. Wenn das Datenelement ein Array ist, kann ein Array-Markierungskästchen verwendet werden, um dies anzugeben. In dem Fall einer Array-Variable kann die Anzahl an Dimensionen in dem Array in einem Dimensionsfeld definiert werden.
-
Ein Feld eines beschreibenden Namens liefert ein beschreibenderes Pseudonym, unter dem das Datenelement auch bekannt sein kann. Ein Inhabermerkmalsfeld gibt an, zu welchem Fahrzeugmerkmal das Datenelement gehört, wobei der Wert aus einer Liste von Fahrzeugmerkmalen in der Begriffsverwaltungsdatenbank 102 ausgewählt wird. Es wird ein Bereichsfeld verwendet, um eine Gruppe von Merkmalen zu bezeichnen, zu denen das Inhabermerkmal gehört, wenn solch eine Gruppe existiert. Ein Beispiel eines Bereichs ist eine Gruppierung von Türverriegelungsmerkmalen für 2-türige Fahrzeuge, 4-türige Fahrzeuge und 5-türige Fahrzeuge. Es wird ein Markierungskästchen, bezeichnet mit 'ist Trigger', verwendet, um anzugeben, ob ein Datenelement verwendet wird, um eine Aktion einer Softwarefunktion auszulösen. Die Inhaberfunktion gibt an, welche Softwarefunktion das Datenelement besitzt. Ein Verbraucherfunktionenfeld gibt an, welche Softwarefunktionen das Datenelement verwenden. Es kann null, eine oder mehr als eine Verbraucherfunktion geben. Das Inhaberfunktions- und das Verbraucherfunktionenfeld werden durch Auswählen aus der Liste von Softwarefunktionen in der Begriffsverwaltungsdatenbank 102 belegt. Es wird ein Speicherfeld verwendet, um zu identifizieren, wie viel Speicher für die Inhaberfunktion erforderlich ist. Die Größe gibt die Größe des Datenelements in Bit an. Es kann ein Skalenfeld verwendet werden, um einen Skalenfaktor zur Multiplikation mit dem Datenelement zu definieren, wenn dies notwendig ist. Periode gibt in Millisekunden an, wie lange die Ausführung der Inhaberfunktion dauert. Schließlich weist jedes Datenelement einen eindeutigen Identifikator, eine Versionsnummer und einen Inhaber auf.
-
Das Datenwörterbuch 116 bietet auch eine alphabetische Liste für ein schnelles Durchsuchen aller Datenelemente. Aus der alphabetischen Liste kann ein Element angeklickt werden, um die Details zu sehen, oder das Element zu editieren, wenn der Benutzer ein entsprechendes Privileg besitzt. Die alphabetische Liste zeigt die Ebene der Abgeschlossenheit jedes Datenelements über einen roten, gelben oder grünen Indikator. In Kasten 118 können die Datenelemente auch zur Verwendung bei anderen Anwendungen aus dem Datenwörterbuch 116 exportiert werden.
-
Ein weiterer wichtiger Teil des Begriffsverwaltungssoftwarewerkzeugs 100 ist ein Glossar 120. Das Glossar 120 ist eine Bibliothek von global definierten und zugelassenen Begriffen. Bei einem großen Unternehmen ist es kritisch, eine einzelne zugelassene Definition für jeden technischen Begriff zu haben, die leicht verfügbar für jeden ist, der sie benötigt. Hinsichtlich der Begriffsverwaltungsdatenbank 102 umfasst das Glossar 120 einen Namen für jeden Begriff, eine Beschreibung für jeden Begriff, eine Versionsnummer und einen Zulassungsstatus. Der Name kann mehr als ein Wort umfassen. Nur Begriffe, die durch ein geeignetes Unternehmensteam überprüft und zugelassen wurden, können aus dem Glossar 120 exportiert und in einem Bericht verwendet werden. Wenn ein Begriff eine Definition aufweist, die von einer Normungsorganisation oder einer Regierungsbehörde verfügbar ist, kann diese Definition angenommen und in das System importiert werden, um die Notwendigkeit des Erzeugens einer Definition zu vermeiden.
-
Das Begriffsverwaltungssoftwarewerkzeug 100 umfasst auch eine Akronymbibliothek 122. Die Akronymbibliothek 122 enthält einen Namen jedes definierten Akronyms, seine Beschreibung oder Bedeutung, eine Versionsinformation und einen Zulassungsstatus. Wie bei dem Glossar 120 kann ein neuer Eintrag in die Akronymbibliothek 122 durch jeden in dem Unternehmen vorgeschlagen werden, er muss jedoch durch ein entsprechendes Team überprüft und zugelassen werden, bevor er durch andere verwendet werden kann. In dem Begriffsverwaltungssoftwarewerkzeug 100 werden einzelnen Benutzern Rollen zugeordnet. So kann eine Verantwortung für eine Zulassung verwaltet werden, wodurch die Integrität der eingegebenen Daten aufrecht erhalten wird.
-
Das Begriffsverwaltungssoftwarewerkzeug 100 liefert zahlreiche Vorteile für ein Unternehmen, das versucht, die Verwendung von Datenelementen, technischen Begriffen und Akronymen zu standardisieren, die Wiederverwendung von Merkmalen und Softwarefunktionen, die entwickelt wurden, zu fördern, und die Verfügbarkeit aller dieser Informationen für die Personen, die sie benötigen, zu maximieren. Durch Speichern aller dieser Informationen in einer einzelnen Begriffsverwaltungsdatenbank 102 kann das Begriffsverwaltungssoftwarewerkzeug 100 die Eindeutigkeit jedes Merkmals, jeder Funktion, jedes Datenelements, jedes technischen Begriffs oder jedes Akronyms sicherstellen. Dies beseitigt das potentielle Problem mehrerer verschiedener Definitionen für ein bekanntes Datenelement oder einen bekannten technischen Begriff. Aufgrund dessen, dass es das einzige anerkannte Archiv dieses Typs von Information ist, erleichtert es das Begriffsverwaltungssoftwarewerkzeug 100 jeder Person in dem Unternehmen, jedes dieser Elemente zu suchen, zu finden und wiederzuverwenden. Ferner hilft die in dem Begriffsverwaltungssoftwarewerkzeug 100 enthaltene relationale Information Benutzern, den Kontext zu verstehen, in dem ein Datenelement oder eine Funktion verwendet wird, und kann sie sogar Benutzern helfen, eine Information zu finden, von der sie nicht wussten, dass sie existiert. Beispielsweise könnte ein Benutzer versuchen, ein neues Datenelement oder einen neuen Variablennamen in dem Begriffsverwaltungssoftwarewerkzeug 100 zu erzeugen, Herausfinden, dass ein ähnliches Datenelement bereits existiert, und dann entdecken, dass bereits eine Softwarefunktion existiert, die sehr ähnlich zu der ist, die der Benutzer vor hatte zu erzeugen. Diese Art von hierarchischer Verlinkung kann zusätzlich zu einem Beseitigen von Ambiguität und Missverständnis eine Wiederverwendung fördern und eine Neuformulierung verhindern. Während alle oben beschriebenen Vorteile durch eine Implementierung von Geschäftsprozessen realisiert werden konnten, macht ein Einbeziehen jener Prozesse in ein datenbankgetriebenes Softwaresystem dies viel effizienter und effektiver.
-
Die oben beschriebenen Prozesse und Softwarewerkzeuge für die Entwicklung von Anforderungen und die Verwaltung von zugehörigen Merkmalen, Funktionen, Datenelementen, technischen Begriffen und Akronymen ermöglichen einem Unternehmen, jene Typen von Dokumenten und Daten effektiv zu erzeugen und zuzulassen. Um diese Elemente jedoch geeignet zu verwalten und zu verwenden und eine Ausuferung zu verhindern wird ein Verfahren zum Katalogisieren der Anforderungen und Prüfen dieser hinsichtlich einer geeigneten Verwendung von Standardbegriffen benötigt. 9 ist ein Flussdiagramm 140 eines Prozesses zum Einbringen und Auslesen von Anforderungen in ein und aus einem Archiv, und 10 ist ein Blockdiagramm eines Anforderungsverwaltungssoftwaresystems 180, das für den Einbringungs- und Ausleseprozess verwendet werden kann. In dem Flussdiagramm 140 beginnt der Prozess in Kasten 142. In der Entscheidungsraute 144 muss der Benutzer angeben, oh er Anforderungen in das Archiv einbringen oder Anforderungen aus dem Archiv auslesen möchte. Wenn dem Einbringungsprozess gefolgt wird, können in Kasten 146 eine oder mehrere Anforderungen aus einer Datei gelesen werden. In dem Anforderungsverwaltungssoftwaresystem 180 liest ein Anforderungseinbringungs-/-auslesewerkzeug 182 eine Anforderungsdatei als durch den Benutzer identifiziert. Die Anforderungsdatei kann entweder eine xml-(Extensible Markup Language-)formatierte Datei 184 oder eine rtf-(Rich Text Format-)Datei 186 sein. Die xml-Anforderungsdatei 184 könnte durch das zuvor beschriebene Anforderungserhebungssoftwarewerkzeug erzeugt werden oder könnte von einem anderen Werkzeug stammen. Die rtf-Anforderungsdatei 186 würde üblicherweise Anforderungen enthalten, die unter Verwendung eines Textverarbeitungsprogramms erzeugt wurden.
-
Sobald die Anforderungen aus einer Datei gelesen wurden, durchsucht das Einbringungs-/Auslesewerkzeug 182 in Kasten 148 die Anforderungen nach Datenelementen, technischen Begriffen und Akronymen. In Kasten 150 vergleicht das Einbringungs-/Auslesewerkzeug 182 alle Datenelemente, technischen Begriffe und Akronyme von den Anforderungen wie gelesen mit ähnlichen Elementen in der zuvor beschriebenen Begriffsverwaltungsdatenbank 102 und interagiert es mit dem Benutzer, um jegliche Unterschiede abzugleichen. Die folgenden Optionen stehen zur Verfügung, um Unterschiede abzugleichen; ein Datenelement, einen Begriff oder ein Akronym zu der Begriffsverwaltungsdatenbank 102 in Abhängigkeit von einer Zulassung hinzuzufügen; die Buchstabierung eines Elements in den eingegebenen Anforderungen zu modifizieren; ein Element von den eingegebenen Anforderungen zu ändern, um mit einem Element von der Begriffsverwaltungsdatenbank 102 übereinzustimmen wie durch das Werkzeug 182 vorgeschlagen; oder ein Wort als kein Datenelement, Begriff oder Akronym, das oder der in Übereinstimmung gebracht werden muss, zu identifizieren. Sobald alle Datenelemente, Begriffe und Akronyme von den eingegebenen Anforderungen mit der Begriffsverwaltungsdatenbank 102 abgeglichen wurden, werden die Anforderungen nach Bedarf in Kasten 152 aktualisiert, um Standardbegriffe aus der Datenbank 102 zu verwenden. In Kasten 154 wird jede Anforderung hinsichtlich einer Einhaltung von Anforderungsautorregeln wie in dem zuvor beschriebenen Anforderungserhebungssoftwarewerkzeug umfasst analysiert. Dies sind Regeln wie beispielsweise, dass nur positive Anforderungen angegeben werden dürfen und nur Anforderungen für ausgehende Übergänge von Zuständen angegeben werden dürfen. Wenn die eingegebenen Anforderungen modifiziert werden müssen, um die Autorregeln einzuhalten, erfolgt dies in Kasten 156. Schließlich werden in Kasten 158 die neuen modifizierten Anforderungen in eine Anforderungsdatenbank 190 geschrieben. Die Anforderungsdatenbank 190 ist das Anforderungsarchiv, das durch jede Person verwendet werden soll, die Anforderungen für Fahrzeugmerkmale oder Softwarefunktionen beitragen, überprüfen oder verwenden möchte. Die Anforderungen werden in der Anforderungsdatenbank 190 als Datenfelder gespeichert – wie beispielsweise imperativ, Aktion, Ziel und Bedingung – nicht lediglich als Textaussagen. Durch Speichern der Anforderungen als Daten wird die Integrität der Validierungsaktivitäten aufrecht erhalten.
-
Wenn aus der Entscheidungsraute 144 der Ausleseprozess verfolgt werden soll, muss der Benutzer in Kasten 160 eine oder mehrere Anforderungen für einen Export aus der Anforderungsdatenbank 190 auswählen. In Kasten 162 werden die ausgewählten Anforderungen, die bereits hinsichtlich der Begriffsverwaltungsdatenbank 102 validiert wurden und deren Einhaltung hinsichtlich der Anforderungsautorregeln verifiziert wurde, durch das Einbringungs-/Auslesewerkzeug 182 in die xml-Datei 184 geschrieben. In Kasten 164 können die in die xml-Datei 184 geschriebenen Anforderungen in einem Spezifikationsdokument oder für andere Zwecke verwendet werden.
-
Die oben beschriebenen Verfahren und Softwarewerkzeuge stellen einen signifikanten Durchbruch bei der Entwicklung von wiederverwendbaren Fahrzeugmerkmalen, der Definition guter Anforderungsaussagen, die die Merkmale unterstützen, der Verwaltung von Datenelementattributen und Begriffsdefinitionen, die in Dokumenten und Fahrzeug eingebetteter Software verwendet werden, und der Organisation aller dieser Dinge in zentralen Archiven dar. Es wurde gezeigt, dass ein Verwenden der Verfahren und Werkzeuge wie beschrieben einem Unternehmen ermöglicht, bessere Produkte zu entwickeln und sie schneller zu entwickeln, was zwei wichtige Ziele jedes Herstellers sind.
-
Die vorstehende Erläuterung offenbart und beschreibt lediglich beispielhafte Ausführungsformen der vorliegenden Erfindung. Ein Fachmann wird aus solch einer Erläuterung und aus den begleitenden Zeichnungen und Ansprüchen leicht erkennen, dass verschiedene Änderungen, Modifikationen und Variationen daran vorgenommen werden können, ohne von dem Gedanken und Schutzumfang der Erfindung wie in den folgenden Ansprüchen definiert abzuweichen.
