„Rückverfolgbarkeit (Anforderungsmanagement)“ – Versionsunterschied
| [ungesichtete Version] | [ungesichtete Version] |
verbesserte Strukturierung der Nutzungsmöglichkeiten von Traceability |
Strukturierung der Herausforderungen verbessert |
||
| Zeile 10: | Zeile 10: | ||
== Nutzung von Traceability-Informationen == |
== Nutzung von Traceability-Informationen == |
||
Die Nutzung von erfassten Traceability-Informationen |
Die Nutzung von erfassten Traceability-Informationen unterstützt zahlreiche Entwicklungsaktivitäten:<ref>{{Literatur|Autor=Karl Wiegers, Joy Beatty|Titel=Software Requirements|Hrsg=Microsoft|Sammelwerk=|Band=Band 3|Nummer=|Auflage=|Verlag=|Ort=|Datum=|Seiten=|ISBN=}}</ref><ref>{{Internetquelle|url=http://www.jamasoftware.com/blog/requirements-traceability-links-in-the-requirements-chain-part-1/|titel=Requirements Traceability: Links in the Requirements Chain, Part 1|autor=Karl Wiegers|hrsg=|werk=|datum=2013-01-16|sprache=en|zugriff=2016-12-13}}</ref> |
||
* '''Auswirkungsanalyse''' (engl. Impact Analysis) von Änderungen -- ändert sich eine [[Anforderung (Informatik)|Anforderung]], geben deren Trace Links Auskunft darüber, welche anderen Artefakte mit dieser in Beziehung stehen. Diese können leicht geprüft und bei Bedarf modifiziert werden. |
* '''Auswirkungsanalyse''' (engl. Impact Analysis) von Änderungen -- ändert sich eine [[Anforderung (Informatik)|Anforderung]], geben deren Trace Links Auskunft darüber, welche anderen Artefakte mit dieser in Beziehung stehen. Diese können leicht geprüft und bei Bedarf modifiziert werden. |
||
* '''Abdeckungsanalyse''' (engl. Coverage Analysis) -- nicht verlinkte Anforderungen sind ein Indiz dafür, dass die spezifizierte Funktionalität nicht vollständig implementiert wurde. Insbesondere für den Zertifizierungsprozess von sicherheitskritischen Systemen ist nachzuweisen, dass alle (Sicherheits-)Anforderungen vollständig umgesetzt und getestet wurden. |
* '''Abdeckungsanalyse''' (engl. Coverage Analysis) -- nicht verlinkte Anforderungen sind ein Indiz dafür, dass die spezifizierte Funktionalität nicht vollständig implementiert wurde. Insbesondere für den Zertifizierungsprozess von sicherheitskritischen Systemen ist nachzuweisen, dass alle (Sicherheits-)Anforderungen vollständig umgesetzt und getestet wurden. |
||
| Zeile 17: | Zeile 17: | ||
* '''Persistierung und Darstellung von Zusammenhängen''' -- Wissen über eine Entwicklung ist häufig nur in den Köpfen einzelner Personen verankert. Trace Links speichern dieses Wissen und visualisieren Zusammenhänge zwischen Artefakten. Selbst wenn [[Stakeholder]] ein Projekt verlassen, bleibt deren Wissen erhalten. |
* '''Persistierung und Darstellung von Zusammenhängen''' -- Wissen über eine Entwicklung ist häufig nur in den Köpfen einzelner Personen verankert. Trace Links speichern dieses Wissen und visualisieren Zusammenhänge zwischen Artefakten. Selbst wenn [[Stakeholder]] ein Projekt verlassen, bleibt deren Wissen erhalten. |
||
* '''Testoptimierung''' -- durch die Verlinkung von [[Anforderung (Informatik)|Anforderungen]], [[Quelltext|Quellcode]], [[Software Test Documentation|Testfällen und Testergebnissen]] kann nach Änderungen und bei Fehlern schnell identifiziert werden, welche Tests ausgeführt werden müssen und wo identifizierte Fehler lokalisiert sind. |
* '''Testoptimierung''' -- durch die Verlinkung von [[Anforderung (Informatik)|Anforderungen]], [[Quelltext|Quellcode]], [[Software Test Documentation|Testfällen und Testergebnissen]] kann nach Änderungen und bei Fehlern schnell identifiziert werden, welche Tests ausgeführt werden müssen und wo identifizierte Fehler lokalisiert sind. |
||
Einen umfangreicheren Überblick über unterstützte Entwicklungsaktivitäten und deren Relevanz liefert <ref>{{Literatur|Autor=Elke Bouillon, Patrick Mäder, Ilka Philippow|Titel=A Survey on Usage Scenarios for Requirements Traceability in Practice|Sammelwerk=Requirements Engineering: Foundation for Software Quality|Nummer=7830|Verlag=Springer Berlin Heidelberg|Datum=2013-04-08|Reihe=Lecture Notes in Computer Science|Seiten=158–173|ISBN=9783642374210|DOI=10.1007/978-3-642-37422-7_12|Online=http://link.springer.com/chapter/10.1007/978-3-642-37422-7_12|Abruf=2016-12-18}}</ref>. |
|||
== Herausforderungen == |
== Traceability-Herausforderungen == |
||
Die durchgängige Erfassung von Traceability-Informationen ist mit mehreren Schwierigkeiten verbunden: |
|||
Auch wenn Requirements Traceability durch die genannten Aspekte verschiedene Vorteile mit sich bringt, so steht man bei der Umsetzung doch auch vor mannigfaltigen Herausforderungen: |
|||
| ⚫ | * '''Hohe Erfassungskosten''' -- Heutige Entwicklungsprojekte mit einer Vielzahl von Artefakten bedingen eine Vielzahl von Trace Links und einen enormen Aufwand zu deren Erfassung<ref>{{Literatur|Autor=Alexander Egyed, Paul Grünbacher, Matthias Heindl, Stefan Biffl|Titel=Value-Based Requirements Traceability: Lessons Learned|Sammelwerk=Design Requirements Engineering: A Ten-Year Perspective|Nummer=14|Verlag=Springer Berlin Heidelberg|Datum=2009-01-01|Reihe=Lecture Notes in Business Information Processing|Seiten=240–257|ISBN=9783540929659|DOI=10.1007/978-3-540-92966-6_14|Online=http://link.springer.com/chapter/10.1007/978-3-540-92966-6_14|Abruf=2016-12-18}}</ref>. Zum Beispiel in Entwicklungsprojekten der Automobilindustrie sind mehrere zehntausend [[Anforderung (Informatik)|Anforderungen]] und daraus resultierenden große Mengen an [[Software Design Description|Design-Artefakten]], [[Quelltext|Quellcode]], und [[Software Test Documentation|Testfällen]] üblich.<ref>{{Literatur|Autor=Houdek|Titel=Managing Large Scale Specification Projects|Hrsg=|Sammelwerk=19th Intl. Working Conference on Requirements Engineering: Foundation for Software Quality|Band=|Nummer=|Auflage=|Verlag=|Ort=Essen, Germany|Datum=2013|Seiten=|ISBN=|Online=https://refsq.org/2013/files/2013/04/Managing-Large-Scale-Specification-Projects_Houdek.pdf}}</ref> |
||
* |
* '''Heterogene Entwicklungswerkzeuge''' -- Verschiedene Entwicklungsartefakte wie [[Anforderung (Informatik)|Anforderungen]], [[Softwaredesign]], [[Quelltext|Quellcode]] oder [[Software Test Documentation|Testprotokolle]] werden häufig mit individuellen Werkzeugen erstellt und verwaltet. Viele Werkzeuge sind nicht interoperabel und erlauben keine werkzeugübergreifende Traceability. Artefakt-Daten aus heterogenen Werkzeugen müssen daher aufwendig homogenisiert werden. |
||
* |
* '''Komplexe Analyse''' -- Artefakte sind häufig nicht direkt, sondern mittelbar über andere Artefakte verlinkt. Für Traceability-Analysen müssen somit vor allem Pfade (engl. Trace Path) und Teilbäume im Trace-Graphen betrachtet werden. Eine Auswertung erfordert daher potentiell aufwendige Algorithmen basierend auf Tiefen- oder Breitensuche. |
||
| ⚫ | * |
||
Aufgrund dieser Herausforderungen ist das Erreichen einer vollständigen Rückverfolgbarkeit von Anforderungen aufwendig. |
Aufgrund dieser Herausforderungen ist das Erreichen einer vollständigen Rückverfolgbarkeit von Anforderungen aufwendig. |
||
Version vom 18. Dezember 2016, 19:37 Uhr
Rückverfolgbarkeit (auch Nachvollziehbarkeit oder engl. Requirements Traceability) bezeichnet in der System- und Softwareentwicklung die Zuordenbarkeit von Anforderungen zu beliebigen Artefakten über den gesamten Entwicklungsprozess[1] und ist somit Teil des Anforderungsmanagements. So soll z. B. für einen Testfall nachvollziehbar sein, aufgrund welcher Anforderung(en) er entstanden ist. Umgekehrt soll verfolgbar sein, welche Testfälle die korrekte Umsetzung einer Anforderung sicherstellen.
Mit Hilfe der Rückverfolgbarkeit von Anforderungen wird die Erstellung qualitativer Aussagen über den Entwicklungsfortschritt und –Prozess ermöglicht. Dies ist speziell bei der Entwicklung sicherheitskritischer Systeme relevant, wo Normen wie etwa die ISO 26262, Automotive SPICE, oder die EN 50128 die Einführung von Requirements Traceability fordern, um damit nachweisen zu können, dass kritische Anforderungen in angemessen hoher Qualität umgesetzt sind. Weiter wird mit Requirements Traceability die Analyse der Auswirkung von Änderungen erleichtert.
Konzepte und Terminologie
Requirements Traceability entsteht, wenn Artefakte eines Entwicklungsprozesses mittels Trace Link verbunden werden. Jeder Trace Link verbindet genau ein Quellartefakt mit einem Zielartefakt. Die Menge aller Trace Links und verknüpfter Artefakte eines Entwicklungsprojektes bilden die Kanten und Knoten eines Graphen, welcher mit Mitteln der Graphentheorie analysiert und bewertet werden kann um die Qualität des Entwicklungsprojektes zu bewerten.[2]
Welche Artefakte in einem Projekt verlinkt werden, wird in einem Traceability Information Model (TIM) definiert. Ein TIM ist ein Metamodell, welches projektspezifisch die zu erfassenden Trace Link-Typen (z.B. Trace zwischen Quellcode und Testfall) und die dabei verknüpften Artefakt-Typen (z.B. Anforderung, Komponente, Testfall) definiert.[3][4] Ein TIM erlaubt es auch bei einer großen Anzahl von Stakeholdern an einem Entwicklungsprojekt, gleichmäßige Traceability-Qualität zu erreichen und diese prüfbar zu machen.[2][4]
Nutzung von Traceability-Informationen
Die Nutzung von erfassten Traceability-Informationen unterstützt zahlreiche Entwicklungsaktivitäten:[5][6]
- Auswirkungsanalyse (engl. Impact Analysis) von Änderungen -- ändert sich eine Anforderung, geben deren Trace Links Auskunft darüber, welche anderen Artefakte mit dieser in Beziehung stehen. Diese können leicht geprüft und bei Bedarf modifiziert werden.
- Abdeckungsanalyse (engl. Coverage Analysis) -- nicht verlinkte Anforderungen sind ein Indiz dafür, dass die spezifizierte Funktionalität nicht vollständig implementiert wurde. Insbesondere für den Zertifizierungsprozess von sicherheitskritischen Systemen ist nachzuweisen, dass alle (Sicherheits-)Anforderungen vollständig umgesetzt und getestet wurden.
- Projektstatusanalyse -- die Vollständigkeit des mittels TIM spezifizierten Traceability-Graphen gibt einen Überblick über den Stand und Fortschritt eines Entwicklungsprojektes. Zum Beispiel Anforderungen ohne Trace Link oder mit verlinktem Quellcode, aber ohne Test befinden sich noch in der Entwicklung.
- Wiederverwendung von Produktkomponenten -- Mittels Trace Links können Anforderungen inklusive aller realisierenden Artefakte in Einheiten zusammengefasst und für verschiedene Produkte genutzt werden.
- Persistierung und Darstellung von Zusammenhängen -- Wissen über eine Entwicklung ist häufig nur in den Köpfen einzelner Personen verankert. Trace Links speichern dieses Wissen und visualisieren Zusammenhänge zwischen Artefakten. Selbst wenn Stakeholder ein Projekt verlassen, bleibt deren Wissen erhalten.
- Testoptimierung -- durch die Verlinkung von Anforderungen, Quellcode, Testfällen und Testergebnissen kann nach Änderungen und bei Fehlern schnell identifiziert werden, welche Tests ausgeführt werden müssen und wo identifizierte Fehler lokalisiert sind.
Einen umfangreicheren Überblick über unterstützte Entwicklungsaktivitäten und deren Relevanz liefert [7].
Traceability-Herausforderungen
Die durchgängige Erfassung von Traceability-Informationen ist mit mehreren Schwierigkeiten verbunden:
- Hohe Erfassungskosten -- Heutige Entwicklungsprojekte mit einer Vielzahl von Artefakten bedingen eine Vielzahl von Trace Links und einen enormen Aufwand zu deren Erfassung[8]. Zum Beispiel in Entwicklungsprojekten der Automobilindustrie sind mehrere zehntausend Anforderungen und daraus resultierenden große Mengen an Design-Artefakten, Quellcode, und Testfällen üblich.[9]
- Heterogene Entwicklungswerkzeuge -- Verschiedene Entwicklungsartefakte wie Anforderungen, Softwaredesign, Quellcode oder Testprotokolle werden häufig mit individuellen Werkzeugen erstellt und verwaltet. Viele Werkzeuge sind nicht interoperabel und erlauben keine werkzeugübergreifende Traceability. Artefakt-Daten aus heterogenen Werkzeugen müssen daher aufwendig homogenisiert werden.
- Komplexe Analyse -- Artefakte sind häufig nicht direkt, sondern mittelbar über andere Artefakte verlinkt. Für Traceability-Analysen müssen somit vor allem Pfade (engl. Trace Path) und Teilbäume im Trace-Graphen betrachtet werden. Eine Auswertung erfordert daher potentiell aufwendige Algorithmen basierend auf Tiefen- oder Breitensuche.
Aufgrund dieser Herausforderungen ist das Erreichen einer vollständigen Rückverfolgbarkeit von Anforderungen aufwendig.
Auswirkungen in der Praxis sind:
- Oftmals wird eine normkonforme Rückverfolgbarkeit gar nicht erst erreicht. So weist etwa eine Analyse der Einreichungen zur Vor-Markt-Prüfung von Software in medizinischen Geräten an die US Food and Drug Administration (FDA) aus dem Jahr 2013 grade im Bereich Traceability signifikante Lücken zwischen Einreichung und Behördenvorgabe nach.[10]
- Das Erreichen einer normkonformen Rückverfolgbarkeit führt zum „Big Freeze“: Jede Weiterentwicklung wird vermieden, weil eine erneute Zertifizierung der Normkonformität wesentlich aufwendiger wäre als die Weiterentwicklung selbst.[11]
Visualisierung von Traceability Informationen
Ein Ziel von Traceability besteht darin, die Zusammenhänge zwischen einzelnen Artefakten darzustellen. Da die Anzahl und Komplexität der Links steigt, werden Techniken zur Visualisierung der Trace Links benötigt. Dabei sollten relevante Informationen zu den Artefakten (z. B. um welchen Typ handelt es sich, Metadaten zum Lebenszyklus und Attribute) und deren Trace Links (Linktyp, d.h. welche Artefakte sind miteinander verlinkt, Metadaten zum Lebenszyklus oder die Linkstärke) ebenfalls abbildbar sein.[12]
Gängige Visualisierungen sind Traceability Matrizen, Graphen, Listen und Hyperlinks.
Traceability Matrix
Eine Traceability Matrix ist eine tabellarische Darstellung, in der Anforderungen z. B. in Spalten, andere Artefakte in Zeilen abgebildet sind. Die Markierung einzelner Zellen visualisiert, mit welchen Artefakten Anforderungen verlinkt sind.[12]
Der Vorteil von Traceability Matrizen besteht darin, dass alle Artefaktverlinkungen in einer Darstellung visualisiert werden können. Weiterhin können Filter helfen, die Menge an Informationen einzuschränken. Traceability Matrizen eigenen sich vor allem für Management-Aufgaben.[12] Problematisch werden sie dann, wenn ein Projekt – wie in der Industrie häufig der Fall – aus mehreren tausenden Artefakten besteht. Die entsprechenden Tabellen werden entsprechend sehr groß und unübersichtlich.
Traceability Graph
Bei der Graph-Visualisierung werden Artefakte als Knoten dargestellt. Sind Artefakte miteinander verlinkt, wird dies durch Kanten zwischen diesen Knoten visualisiert.
Graphen eigenen sich vor allem für Entwicklungsaufgaben. Sie ermöglichen explorativ einen Überblick über Verlinkungen zu bekommen und zeichnen sich durch eine hohe Verständlichkeit der abgebildeten Informationen aus.[12] Durch Navigation durch die Graphen kann leicht identifiziert werden, an welchen Stellen Links fehlen und weitere Artefakte erzeugt werden müssen.
Listen
Listen repräsentieren jeden Trace Link als ein Eintrag. Dieser besteht z. B. aus Informationen zum Quell- und Ziel-Artefakt und zugehörigen Attributen.
Sie eignen sich vor allem, wenn Aktionen auf mehreren Artefakten gleichzeitig ausgeführt werden sollen. Auch erleichtern Filter- und Sortiermechanismen den Umgang mit dieser Visualisierungsform. Listen werden jedoch im Vergleich zu den anderen beiden Visualisierungen als weniger geeignet empfunden, um Projektmanagement, Entwicklungs- oder Testaufgaben auszuführen.[12]
Hyperlinks
Hyperlinks sind Links zwischen einzelnen Artefakten und ermöglichen es, schnell zwischen verlinkten Artefakten hin und her zu "springen".
Sie sind insbesondere geeignet, wenn detaillierte Informationen zu Artefakten benötigt werden: Sie erlauben es zu Artefakten in ihrer natürlichen Umgebung zu navigieren und dort weitere Informationen einzusehen.[12] Eine reine Nutzung von Hyperlinks hat den Nachteil, dass viel Navigationsaufwand betrieben werden muss, um einen Überblick über alle Verlinkungen zu bekommen: Linkinformationen werden nicht kompakt visualisiert. Hyperlinks lassen sich jedoch auch mit den anderen Visualisierungen kombinieren, um diesem Nachteil entgegenzuwirken.
Umsetzung
Manuell oder halbautomatisch
Vielfach wird die Traceability manuell oder halbautomatisiert erreicht, indem Trace-Daten werkzeuggestützt und/oder manuell, z. B. in MS Excel, ausgewertet werden. Aufgrund der o.g. Herausforderungen ist dieses Vorgehen aufwendig und führt zu Aussagen in schlechter Qualität.[13]
Werkzeuggestützt
Bei der werkzeuggestützten Traceability gilt es, die über die verschiedenen Bestandteile der Werkzeuglandschaft verteilten Daten zu homogenisieren und zu aggregieren. Hierzu gibt es folgenden Ansätze:
Homogenisierung der Werkzeuglandschaft – ALM Werkzeuge
ALM Werkzeugketten decken homogen den gesamten Lebenszyklus eines Systems ab und Verwalten dabei in einem ganzheitlichen Ansatz alle Artefakte des Entwicklungsprozesses.
Vorteil dieses Ansatzes ist, dass sich aufgrund der Homogenisierung die Verlinkung von Artefakten leicht verwalten und mit dedizierten Werkzeugen innerhalb des ALM-Tools auswerten lässt.
Nachteil hierbei ist, dass eine ALM-Werkzeugkette ganzheitlich eingeführt werden muss und dass sich einzelne Werkzeuge in dieser Kette nur schwer austauschen lassen. Hier droht ein „Big Freeze“ (s.o.) für die Werkzeugkette.
Homogenisierung der Daten - Quasi-Requirements
Requirements-Management-Werkzeuge bieten die Möglichkeit zur Verwaltung und Auswertung von Links zwischen Requirements. Um eine vollständige Verlinkung auch zu anderen Artefakten des Entwicklungsprozesses zu ermöglichen, können bei einigen dieser Werkzeuge andere Artefakte als „Quasi-Anforderung“ importiert werden. Hier wird z. B. erklärt, wie Elemente eines Matlab Modells als sog. „Surrogate“ nach IBM DOORS importiert werden.
Der Vorteil hierbei ist, dass viele am Markt etablierte Werkzeuge die Möglichkeit bieten, die Daten als Quasi-Requirements darzustellen.
Nachteil hierbei ist, dass für die verschiedenen Artefakt-Typen verschiedene Adapter oder Konvertierer benötigt werden, die in Version und Datenformat konsistent sein müssen. Im Gegensatz zu einer ALM-Werkzeugkette muss man hier die Konsistenz der Adapter und Konvertierer in Eigenregie sicherstellen.
Homogenisierung der Daten – dedizierte Traceability Werkzeuge
Der Ansatz dedizierter Traceability-Werkzeuge ist, die relevanten Daten aus den Artefakten im Entwicklungsprozess zu extrahieren und in einem einheitlichen Traceability-Modell darzustellen. Die Anbindung der bestehenden Bestandteile der Werkzeuge erfolgt dabei über Adapter. Zudem bieten diese Werkzeuge Schnittstellen, um beliebige – auch proprietäre – Werkzeuge einzubinden.
Der Einsatz dedizierter Traceability-Werkzuge vereint die Vorteile der beiden oben genannten Ansätze: Die Konsistenz der Adapter und Konvertierer wird durch den Anbieter des Traceability-Werkzeugs sichergestellt, während die Flexibilität der Werkzeugkette durch anpassbare Schnittstellen im Werkzeug selbst gewährleistet wird.
Der Nachteil bei diesem Ansatz ist, dass aufgrund der Flexibilität dieser Werkzeuge bei der Definition des Traceability Information Model nicht nur die Artefakt-Typen und deren Verlinkung definiert werden, sondern dass auch die technische Anbindung der Werkzeuge konfiguriert werden muss.
Dedizierte Traceability Werkzeuge
Capra
Capra ist ein dediziertes Traceability Management Werkzeug, welches die Erzeugung, Verwaltung, Visualisierung und die Analyse von Trace Links innerhalb Eclipse ermöglicht. Capra ist Bestandteil der Open Source Tool Platform AMALTHEA 4public, die wiederum aus dem EUREKA Forschungsprojekt AMALTHEA hervorgegangen ist.
Reqtify
Reqtify ist eine leicht benutzbare, interaktive Anwendung, um Requirements zu verwalten. Es ermöglicht Traceability und Auswirkungsanalysen über den kompletten Lebenszyklus in der Hardware- und Softwareentwicklung. Reqtify ist ein kommerzielles Werkzeug der Firma Claytex.
traceMaintainer
traceMaintainer ist ein Werkzeug zur Aufrechterhaltung von Traceability in Enterprise Architect UML Modellen. Es versucht semantische Zusammenhänge in inkrementellen Änderungen eines Entwicklers zu erkennen und führt Traceability entsprechend diesen Änderungen mit. traceMaintainer ist aus einem DFG Forschungsprojekt hervorgegangen.
YAKINDU Traceability
YAKINDU Traceability ermöglicht unkompliziertes und anpassbares Traceability-Management – zum Beispiel, um Standards wie die ISO 26262 zu erfüllen. YAKINDU Traceability ist ein kommerzielles Produkt der Firma itemis und hat wie Capra seinen Ursprung im EUREKA Forschungsprojekt AMALTHEA.
Werkzeugauswahl
Die Entscheidung für eine Traceability Lösung ist nicht trivial, da sich die vermeintlich einfachen und kostengünstigen Lösungen im Verlauf der Entwicklung häufig als unzulänglich und nicht wartbar erweisen.[10] Daher sollte die Entscheidung für ein Werkzeug das Ergebnis einer systematischen Analyse sein.[14]
Literatur
- Cleland-Huang, Gotel, Zisman: Software and Systems Traceability, London, Dordrecht, Heidelberg, New York 2012, ISBN 978-1-4471-2238-8.
- Mary Beth Chrissis: CMMI Top10 Interpretation Issues. (PDF; 2,6 MB) CarnegieMellon Software Engineering Institute, Pittsburgh 2004, S. 8–9.
- Chris Rupp: Requirements-Engineering und Management. 4. Auflage. Hanser, München, Wien 2007, ISBN 3-446-40509-7, S. 409–442.
Einzelnachweise
- ↑ Gotel, Finkenstein: An analysis of the requirements traceability problem. In: Proceedings of the 1st IEEE International Conference on Requirements Engineering. Colorado Springs, CO, USA 1994, S. 94 ff.
- ↑ a b P. Rempel, P. Mäder: A quality model for the systematic assessment of requirements traceability. In: 2015 IEEE 23rd International Requirements Engineering Conference (RE). 1. August 2015, S. 176–185, doi:10.1109/RE.2015.7320420 (ieee.org [abgerufen am 18. Dezember 2016]).
- ↑ P. Mader, O. Gotel, I. Philippow: Getting back to basics: Promoting the use of a traceability information model in practice. In: 2009 ICSE Workshop on Traceability in Emerging Forms of Software Engineering. 1. Mai 2009, S. 21–25, doi:10.1109/TEFSE.2009.5069578 (ieee.org [abgerufen am 18. Dezember 2016]).
- ↑ a b Orlena Gotel, Jane Cleland-Huang, Jane Huffman Hayes, Andrea Zisman, Alexander Egyed: Traceability Fundamentals. In: Software and Systems Traceability. Springer London, 2012, ISBN 978-1-4471-2238-8, S. 3–22, doi:10.1007/978-1-4471-2239-5_1 (springer.com [abgerufen am 18. Dezember 2016]).
- ↑ Karl Wiegers, Joy Beatty: Software Requirements. Hrsg.: Microsoft. Band 3.
- ↑ Karl Wiegers: Requirements Traceability: Links in the Requirements Chain, Part 1. 16. Januar 2013, abgerufen am 13. Dezember 2016 (englisch).
- ↑ Elke Bouillon, Patrick Mäder, Ilka Philippow: A Survey on Usage Scenarios for Requirements Traceability in Practice. In: Requirements Engineering: Foundation for Software Quality (= Lecture Notes in Computer Science). Nr. 7830. Springer Berlin Heidelberg, 2013, ISBN 978-3-642-37421-0, S. 158–173, doi:10.1007/978-3-642-37422-7_12 (springer.com [abgerufen am 18. Dezember 2016]).
- ↑ Alexander Egyed, Paul Grünbacher, Matthias Heindl, Stefan Biffl: Value-Based Requirements Traceability: Lessons Learned. In: Design Requirements Engineering: A Ten-Year Perspective (= Lecture Notes in Business Information Processing). Nr. 14. Springer Berlin Heidelberg, 2009, ISBN 978-3-540-92965-9, S. 240–257, doi:10.1007/978-3-540-92966-6_14 (springer.com [abgerufen am 18. Dezember 2016]).
- ↑ Houdek: Managing Large Scale Specification Projects. In: 19th Intl. Working Conference on Requirements Engineering: Foundation for Software Quality. Essen, Germany 2013 (refsq.org [PDF]).
- ↑ a b P. Mäder, P. L. Jones, Y. Zhang, J. Cleland-Huang: Strategic Traceability for Safety-Critical Projects. In: IEEE Software. Band 30, Nr. 3, 1. Mai 2013, ISSN 0740-7459, S. 58–66, doi:10.1109/MS.2013.60 (ieee.org [abgerufen am 12. Dezember 2016]).
- ↑ About Open-DO. In: www.open-do.org. Abgerufen am 12. Dezember 2016.
- ↑ a b c d e f Yang Li, Walid Maalej: Which Traceability Visualization Is Suitable in This Context? A Comparative Study. In: Lecture Notes in Computer Science. 7195. Auflage. Requirements Engineering: Foundation for Software Quality. 2012, S. 194–210.
- ↑ Traceability-Anforderungen kennen und mit ALM effizient umsetzen. In: All-Electronics.de. 25. November 2015 (all-electronics.de [abgerufen am 12. Dezember 2016]).
- ↑ Orlena Gotel, Patrick Mäder: Acquiring Tool Support for Traceability. In: Software and Systems Traceability. Springer London, 2012, ISBN 978-1-4471-2238-8, S. 43–68, doi:10.1007/978-1-4471-2239-5_3 (springer.com [abgerufen am 18. Dezember 2016]).