Anforderungsverwaltung mit ENOVIA 3DEXPERIENCE

Produktentwicklung darf sich nicht außerhalb der Begrenzungen bewegen, die durch die Produktanforderungen vorgegeben sind. Doch dabei ergeben sich viele Fragen:

  • Wie wird sichergestellt, dass das Produkt entsprechend aller gestellten relevanten Anforderungen entwickelt und keine Anforderung "vergessen" wird?
  • Wie wird festgelegt, welche Anforderungen relevant sind und wie die Anforderungen untereinander in Beziehung stehen sollen?
  • Wie werden Anforderungsabhängigkeiten und -konflikte berücksichtigt?

PLM-Systeme enthalten Mechanismen, diese Anforderungenzusammenzuführen, zu dokumentieren und in Kontext zu bringen. Die dabei auftretenden Anforderungen können aus verschiedenen Quellen kommen - von Personen, z.B. von Kunden, vom Marketing, vom Produktplaner - genauso wie aus Gesetzeslagen, z.B. umweltbezogene Materialeinschränkungen. Sie können in vielfältigen Dokumentformaten formuliert worden sein und sie können sich ändern.

Die in PLM-Systemen enthaltene Anforderungsverwaltung übernimmt genau diese Aufgabe:

aus allen Anforderungen einen Kontext zu bilden und sicherzustellen, dass die Entwicklung eines Produktes immer innerhalb dieses Anforderungskontextes erfolgt.

Dadurch wird späterer Änderungsaufwand verringert und der Entwicklungsprozess weiter beschleunigt.

  • Anforderungsmanagement in ENOVIA 3DEXPERIENCE ermöglicht eine Produktentwicklung von der Anforderungsidentifikation/-spezifikation bis zur finalen Produktvalidierung.
  • Anforderungen sind unterschiedlichen Ursprungs, wie z.B. Kundenanforderungen, Marktanforderungen, gesetzliche Bestimmungen und Vorschriften, etc.
  • Anforderungen können direkt ins System eingegeben oder aus verschiedensten Formaten wie z.B. Lastenheften, Vorschriften, Protokollen, Word-/Exceldokumenten, RIF-Files (DOORS) übernommen werden.
  • Um Kundenanforderungen neu zu formulieren und aufzuteilen, können diese als "Subrequirements" angelegt oder einzelne Anforderungen zu "Gruppen" zusammengefasst werden.
  • Anforderungen können nach einer Prüfung als machbar gekennzeichnet werden (Status "Release" im Lifecycle der Anforderung).
  • Zusätzliche Informationen werden z.B. als Dokumente an die Anforderung angehängt.
  • Änderungen in Anforderungen sind jederzeit transparent. Ändert man eine Anforderung, wird eine neue Revision erzeugt, an die alle neuen Dokumente angehängt werden (z.B. Revision B des Customer Request 000016).
  • Querverweise von Änderungen, Produkten, Projekten, Test Cases sind logisch miteinander verknüpfbar. Man pflegt Product Lines mit den jeweiligen Produkten. Für neue Produkte kann ein Projekt angelegt werden. Dem sind Arbeitspakete, Phasen, Meilensteine, Gates zugeordnet.
  • Alle Anforderungen, Test Cases, technische Dokumente, CAD Daten, etc. sind logisch mit einander verknüpft und über verschiedene Views sehr übersichtlich darstellbar.
  • Verwaltung von Testcases und Testkriterien mit z.B. Prüfplänen ist leicht möglich.
  • Jeder Anforderung können ein oder mehrere Testcases zugeordnet werden. Diese werden Personen oder Gruppen zugewiesen. Im Testcase finden die zugeordneten Personen alle benötigten Informationen wie z.B. Prüfplane.
  • Jeder Testcase wird im Validation Status als
    Not Validated
    Validation Passed
    Validation Failed
    gekennzeichnet.
  • TestCases und die Testergebnisse sind im jeweiligen "Testcase" zu dokumentieren.
  • Jeder Testcase ist am Requirement verlinkt. Somit ist jeder Anforderung eindeutig das Ergebnis des Testcases zugeordnet.