Tool-Based Requirement Traceability between Requirement and Design Artifacts

Bernhard Turban

Tool-Based Requirement Traceability between Requirement and Design Artifacts

Foreword by Prof. Dr. Christian Wolff

Bernhard Turban Nabburg, Germany

Turban, Bernhard: Tool-Based Requirements Traceability between Requirement and Design Artifacts for Safety-Critical SystemsZugl.: Regensburg, Univ., Diss., 2011

Th is work was accepted as a Ph. D. dissertation thesis by the Faculty of Languages, Lit-erature and Cultural Studies of the University of Regensburg in 2011.

D 355

ISBN 978-3-8348-2473-8 ISBN 978-3-8348-2474-5 (eBook) DOI 10.1007/978-3-8348-2474-5

Th e Deutsche Nationalbibliothek lists this publication in the Deutsche Nationalbibliografi e; detailed bibliographic data are available in the Internet at http://dnb.d-nb.de.

Library of Congress Control Number: 2013933878

Springer Vieweg© Springer Fachmedien Wiesbaden 2013Th is work is subject to copyright. All rights are reserved by the Publisher, whether the whole or part of the material is concerned, specifi cally the rights of translation, reprinting, reuse of illustrations, recitation, broadcasting, reproduction on microfi lms or in any other physical way, and transmission or information storage and retrieval, electronic adaptation, computer soft ware, or by similar or dissimilar methodology now known or hereaft er developed. Ex-empted from this legal reservation are brief excerpts in connection with reviews or scholarly analysis or material supplied specifi cally for the purpose of being entered and executed on a computer system, for exclusive use by the purchaser of the work. Duplication of this pub-lication or parts thereof is permitted only under the provisions of the Copyright Law of the Publisher’s location, in its current version, and permission for use must always be obtained from Springer. Permissions for use may be obtained through RightsLink at the Copyright Clearance Center. Violations are liable to prosecution under the respective Copyright Law.Th e use of general descriptive names, registered names, trademarks, service marks, etc. in this publication does not imply, even in the absence of a specifi c statement, that such names are exempt from the relevant protective laws and regulations and therefore free for general use. While the advice and information in this book are believed to be true and accurate at the date of publication, neither the authors nor the editors nor the publisher can accept any legal responsibility for any errors or omissions that may be made. Th e publisher makes no warranty, express or implied, with respect to the material contained herein.

Printed on acid-free paper

Springer Vieweg is a brand of Springer DE.Springer DE is part of Springer Science+Business Media.www.springer-vieweg.de

While the discerning layman understands that in the design of large constructions,

a new town or an airport, the problems are overwhelming, he probably does not realise so clearly that there are problems just as pressing

and difficult for the designer in the design of almost any trivial product.

A bad town will do more harm than a bad toothbrush but the designer of either will experience his job

as the necessity to make a series of decisions between alternative courses of action,

each affecting the decisions which come after it; and if no life hangs on the outcome

of the series of decisions about the toothbrush, the livelihood of several people does.

David Pye [Py78; p.75]

Foreword

What is the way design decisions are made in Software design and implementa-tion? What is the relationship between a software artifact and customer require-ments? What are the reasons, what is the rationale for a specific technical solu-tion? How should design decisions be documented? These are only some of the questions which Bernhard Turban tackles in his dissertation on Tool-Based Re-quirements Traceability.

One of the major merits of this book is the successful bridging from design theories to practical tool design for embedded real-time software: Bernhard Tur-ban actually puts design theory to work, in a way from which software designers and engineers may directly benefit. At the same time, this effort is firmly rooted in current software engineering standards like SPICE (Software Process Im-provement and Capability Determination, ISO/IEC 15 504).

Tackling the documentation needs for software design decisions by imple-menting a tool using a specific algorithm or forwarding these decisions shows the authors inventiveness: For a problem many software engineers are constantly confronted with, this solution provides an innovative solution. At the same time, this approach generates traceability-relevant information.

In addition, the author does not only present a plausible and functional algo-rithm for documenting design decisions across different levels of the develop-ment process, he also realizes a complex interactive interface tool which seam-lessly adds to the functionality of modeling tools. Based on this work, a commer-cial software development tool was created.

This work was developed not in an academic context, but in an industrial setting within a group of software engineers working in the domain of automo-tive embedded real-time systems. Thus, the author can draw all examples for his work from immediate observations in the development projects he was working on. This adds to the credibility of the work presented here, and I am sure that both academia as well as industrial software design can learn a good deal lot from Bernhard Turban’s work.

With the complexity of software projects still rising, the demand for better documentation and traceability will grow beyond typical fields like the engineer-ing of embedded systems. Therefore, it is to be hoped for that many software projects will benefit from Bernhard Turban’s theoretical approach towards design decisions as well as from the tool solutions he has created.

Prof. Dr. Christian Wolff

Acknowledgements

This work would not have been accomplished without the support of so many people. I would like to thank them all for their support.

University of Regensburg To begin with, I would like to thank my supervisors at the University of Regens-burg Professor Dr. Christian Wolff and Professor Dr. Rainer Hammwöhner for their constant support. I specially thank them for giving me the chance to write this thesis.

University of Applied Sciences in Regensburg Particularly, I would like to thank Professor Dr. Athanassios Tsakpinis from the University of Applied Sciences Regensburg and director of the Competence Cen-ter for Software Engineering. Without his very significant support the results described here might not have been accomplishable.

I further want to thank Professor Dr. Markus Kucera and Professor Dr. Bernhard Kulla for their advice and support.

Former Micron Electronic Devices AG Further, I would like to thank Peter Schiekofer and Jörg Aschenbrenner for giv-ing me a chance to perform my doctor’s thesis with the Micron Electronic Devic-es AG and specially thank them for their open-mindedness to the vague ideas I first sketched to them seeing the innovative potential within the ideas.

Mercedes Benz technology (MBtech) At the MBtech Group, I would like to thank Dr. Nico Hartmann for giving the R2A-project a home, after the integration of Micron Electronic Devices AG.

The PROVEtech:R2A development team I also would like to thank the R2A development team for their good work and enthusiasm. My Editors I also want to thank Florian Weiss and my brother Andreas Turban for cross-reading my thesis. Futher, I especially want to thank Anita Wilke from Springer Fachmedien Wiesbaden GmbH for helping me bringing this thesis to a book.

X Acknowledgements

Family and Friends Last but not least, I would like to especially thank my parents, grandparents and all my friends for their patience and encouragements in difficult situations.

Bernhard Turban

Abstract

Developing safety-critical systems imposes special demands for ensuring quality and reliability of the developed systems. Process standards such as SPICE (ISO15504) or CMMI have been developed to ensure high quality processes, leading to the development of high quality systems. Central principles of these standards are demands for requirements traceability. Traceability means compre-hensible documentation of all origins and later influences of a requirement throughout the complete development endeavor. Among other uses ascribed, the traceability concept tries to ensure that every requirement is adequately consid-ered in development and that if changes on the requirement are needed, impacts of these changes can be adequately estimated and consistently implemented later on. Even though the traceability concept seems promising in theory, it faces sub-stantial problems in practice. One problem is that despite the needed efforts, the perceived benefits for developers are often low because the quality of captured traceability information is often coarse grained, does not prove helpful in the situational context, or has already degraded.

This thesis tries to show that traceability between requirements and design is an especially difficult problem. To analyze the problem context, the thesis at first analyzes theories, in which the problem is cross-cutting. These are embedded systems development, systems engineering, software engineering, requirements engineering and management, design theory and process standards for safety-critical systems.

This analysis mainly identifies a twofold gap between the requirements and the design domain. Obviously a tooling gap exists because different tools are used for the requirements and design domain. However, more important, between requirement descriptions and designs a substantial inherent gap exists because design is a creative decision process of designers often guided by intuition and tacit knowledge thus difficult to trace by current traceability concepts. To prove this argumentation, the author analyzes four design theories (symbolic infor-mation processing (Simon), wicked problems (Rittel), reflective practice (Schön) and patterns (Alexander)). As a solution to the gap problem, the thesis introduces a tool-based traceability method that supports designers in their thinking, avoids disturbing designers in their intuitive phases of creativity, allows establishing traceability nearly as a by-product, provides early benefit to designers, improves collaboration between designers and extends usual traceability concepts by two integrated decision models allowing further decision information (rationale) to be documented. The decision models also allow deriving new design internal

XII Abstract

“requirements” (design constraints and budgeted resource constraints) as conse-quences. In this way, it is possible to clearly distinguish real requirements origi-nating from customers from ‘requirements’ arising from internal decision pro-cesses during design leading to the definition of a ‘requiremental items taxono-my’. As the thesis further shows, these concepts also prove to be helpful to avoid unnecessary redundancies in the artifact process models of SPICE (ISO15504) or CMMI, where different requirement (system requirements, hardware require-ments and software requirements) and design artifacts (system design, hardware design and software design) are considered in their interplay. Last but not least, mechanisms for graphical impact analysis, consistency management and supplier management complete the approach.

Through funding of the support program IUK-Bayern, the results presented here could be integrated into a commercial tool solution called PROVEtech:R2A, now offered by the MBtech Group as a decisive means to significantly improve requirement-based design processes with improved support to achieve real bene-fit from the traceability concept.

Contents

Foreword .......................................................................................................... VII

Acknowledgements ........................................................................................... IX

Abstract .............................................................................................................. XI

Contents ......................................................................................................... XIII

List of Figures ...................................................................................... XIX List of Tables .................................................................................... XXIII Abbreviations ..................................................................................... XXV

Introduction .......................................................................................................... 1

Introduction to the Topic .......................................................................... 1 Context of this Thesis Project .................................................................. 4 General Remarks on this Thesis .............................................................. 7

Registered Trademarks ....................................................................... 7 Argumentation .................................................................................... 7 Citations ............................................................................................. 8

General Structure of this Thesis .............................................................. 9 I. General Context and Theories ...................................................................... 11

I.1 The Model Concept .......................................................................... 13 I.2 Embedded Systems Development ................................................... 16

I.2.1 Definition and Context ............................................................ 16 I.2.2 Characteristics ......................................................................... 16 I.2.3 Embedded Development in the Automotive Domain ............. 19

I.3 Software Engineering (SE) .............................................................. 24 I.4 Systems Engineering (SysEng) ........................................................ 26 I.5 Requirements Engineering and Management ............................... 31

I.5.1 The Term 'Requirement' .......................................................... 34 I.5.2 Phases, Artifacts and Techniques in REM ............................... 40 I.5.3 Requirements Management ..................................................... 43 I.5.4 Models in REM ....................................................................... 44

XIV Contents

I.5.5 Separation between Requirements and Design ...................... 48 I.5.6 The Role and Nature of Requirement Change ........................ 49 I.5.7 Traceability in the Context of Requirements Management .... 55

I.5.7.1 Traceability in Different Aspects of Development Activities ..................................................................... 57

I.5.7.2 Traceability as an Issue of Quality .............................. 61 I.5.7.3 The Potential Uses of Traceability .............................. 62

I.5.8 Deficiencies of Today's REM Practices .................................. 64 I.6 Design in Systems and Software Development .............................. 65

I.6.1 Different Design Phases in SysEng and SE ............................ 66 I.6.1.1 System Design ............................................................ 67 I.6.1.2 Software Architecture ................................................. 67 I.6.1.3 Detailed Design ........................................................... 70

I.6.2 General Theories about Design .............................................. 70 I.6.2.1 Design as Symbolic Information Processing .............. 71 I.6.2.2 Design as Wicked Problems ........................................ 84 I.6.2.3 Design as Situated Action ........................................... 89 I.6.2.4 Design as a Language of Patterns ............................... 94

I.6.3 Comparison of General Design Theories ............................. 103 I.6.4 Dependency between Design Models and Code .................. 105 I.6.5 Architecture Documentation ................................................. 107 I.6.6 Design in the Automotive Domain ........................................ 110

I.6.6.1 Modeling Methods and Tools Used in Automotive Design ........................................................................ 111

I.6.6.2 Integrating other Organizations into a Design ........... 115 I.7 Quality Standards for Safety-Critical Development Processes .... 116

I.7.1 SPICE (ISO 15504) ............................................................... 119 I.7.1.1 The Process Reference Model of SPICE .................. 120 I.7.1.2 The Measurement Framework .................................. 121 I.7.1.3 The Process Assessment Model (PAM) .................... 122

I.7.2 Requirements, Design and Traceability in the Context of SPICE .................................................................................... 124 I.7.2.1 ENG.1: Requirements Elicitation .............................. 124 I.7.2.2 ENG.2: System Requirements Analysis .................... 126 I.7.2.3 ENG.3: System Architectural Design ........................ 130 I.7.2.4 ENG.4: Software Requirements Analysis ................. 132 I.7.2.5 ENG.5: Software Design ........................................... 133 I.7.2.6 ENG.6: Software Construction .................................. 134 I.7.2.7 SUP.10: Change Management ................................... 135

Contents XV

I.7.3 Traceability in SPICE ........................................................... 137 I.7.3.1 Intersect: Dangers of Prescriptive Process Models ... 138 I.7.3.2 The Nature of the ENG-Processes, Traceability, and

its Implications .......................................................... 142 I.7.4 Automotive SPICE ................................................................ 148 I.7.5 Safety Engineering: IEC 61508, ISO 26262 ......................... 151

I.8 Feedback from Embedded Practice .............................................. 153

II. Rationale Management and Traceability in Detailed Discussion ........... 159

II.9 Rationale Management in Systems and Software Engineering ................................................................................... 159 II.9.1 Characterization Criteria for Rationale Approaches ............ 162

II.9.1.1 Representation .......................................................... 162 II.9.1.2 Basic Rationale Processes ........................................ 163 II.9.1.3 Descriptive versus Prescriptive Approaches ............ 164 II.9.1.4 Intrusiveness ............................................................. 164

II.9.2 Rationale Management Systems (RMS) .............................. 165 II.9.3 Overview of Different Rationale Approaches ..................... 166

II.9.3.1 Schemas for Argumentation ..................................... 166 II.9.3.2 Approaches beyond Argumentation ......................... 173 II.9.3.3 Alternative Categorization........................................ 175

II.9.4 Why Rationale Management Could not yet Succeed in Practice ......................................................................... 177

II.9.4.1 Cognitive Limitations ............................................... 178 II.9.4.2 Rationale Capture Limitations as Central Challenge

in Rationale Management ......................................... 179 II.9.4.3 Retrieval Limitations ................................................ 186 II.9.4.4 Usage Limitations .................................................... 186 II.9.4.5 Synopsis of Rationale Limitations

Concerning Alternative Design Theories ................ 187 II.9.5 The Role of Rationale in System and Software Design ... 188

II.10 Requirements Traceability ......................................................... 192

II.10.1 Overview ........................................................................... 192 II.10.2 Traceability and Consistency Gaps between Artifacts ....... 194 II.10.3 Impact Analysis and Traceability ....................................... 197 II.10.4 Core Dimensions for Characterization .............................. 201

II.10.4.1 Purpose ................................................................... 202

XVI Contents

II.10.4.2 Conceptual Trace Model ..................................... 204 II.10.4.3 Process ................................................................ 229 II.10.4.4 Tools .................................................................... 234

II.10.5 Traceability and its Benefit Problem ................................. 242 II.10.6 Traceability between Requirements and Design ............... 245

II.10.6.1 Theoretic Research Results ................................. 245 II.10.6.2 Tool Couplings between REM- and Design

Tools in Practice .................................................. 248 II.10.7 Traceability between Requirements, Design and Code ..... 254 II.10.8 Rationale Management and Traceability ........................... 257

III. PROVEtech:R2A – A Tool for Dedicated Requirements Traceability 259

III.11 Research Goals .......................................................................... 261 III.12 Accompanying Case Study ....................................................... 265 III.13 Closing the Tool Gap ................................................................ 268 III.14 Closing the Gap between Requirements and Design ............. 271 III.15 Abstraction Layers and Abstraction Nodes ............................ 27 III.16 Models Crossing Tool-Barriers ................................................ 280

III.16.1 Insertion: Coupling Different REM- and Modeling Tools ................................................................................. 280

III.16.2 Integrating Several Modeling Tools in a Single Model .... 281 III.17 Basic Support Features of R2A ............................................... 284

III.17.1 Support for Collaborative Design Tasks .......................... 284 III.17.2 The Notes Mechanism ..................................................... 285 III.17.3 Extensibility: XML-Reporting and User Tagging ........... 286 III.17.4 Unique Identifier Support for any Item in R2A ............... 287 III.17.5 Evolutionary Traceability – Recording History and

Baselines ........................................................................ 287 III.17.6 The Properties Dialog ...................................................... 288

III.18 Requirements and Requirements Traceability ....................... 290 III.18.1 Managing Requirement Sources ...................................... 290 III.18.2 Establishing Requirements Traceability........................... 293

III.18.2.1 Traceability Operations in R2A ......................... 296 III.18.2.2 The Requirement Influence Scope (RIS) ........... 299 III.18.2.3 Representing Requirement Contextual Data ..... 302 III.18.2.4 The Requirement Dribble Process (RDP) .......... 304 III.18.2.5 Overview over Navigation and Handling of

Requirements Aspects in R2A ........................... 311

Contents XVII

III.19 Taxonomy of Requiremental Items .......................................... 313 III.20 Support for Capturing Decisions ............................................. 316

III.20.1 Relation to Approaches of Rationale Management .......... 319 III.20.2 Effects on the Traceability Model .................................... 322 III.20.3 Example How to Tame the Development Process Model

of SPICE ........................................................................ 324 III.20.4 Implementation of the Decision Model in R2A ............... 326 III.20.5 Additional Support of the Decision Model for Designers 337

III.20.5.1 Patterns ............................................................ 338 III.20.5.2 Ensuring Adequate Realization of Design and

Decisions ......................................................... 339 III.20.5.3 Support for Architecture Evaluation ............... 339

III.21 Resource Allocation as a Special Decision Making Case ....... 341 III.21.1 Budgeted Resource Constraints as further

Requiremental Items ......................................................... 343 III.21.2 Advantages for Collaboration and Sharing Project

Knowledge ...................................................................... 345 III.21.2.1 Within Project Refinement .............................. 345 III.21.2.2 Communicating Information across Organizational Boundaries .............................. 346 III.21.2.3 Change Management ....................................... 347 III.21.2.4 Different Views on the Same Problem ............ 348

III.21.3 Representing Budgeted Resource Constraints in SysML . 349 III.21.4 Combining both Decision Models .................................... 351

III.22 Managing Changes and Consistency ....................................... 352 III.22.1 Usage of Traces – Managing Requiremental Changes ..... 353

III.22.1.1 Selective Tracing: Impact Analysis ................. 353 III.22.1.2 Interactive Tracing: The Model Browser ......... 357 III.22.1.3 Non-Guided Tracing: Additional Features for Fast Look-Up ............................................. 358

III.22.2 Consistency Maintenance of Requirements, Traceability and Design ...................................................................... 359

III.23 Aspects of Embedding R2A in a Process Environment .......... 362 III.23.1 Avoiding Redundancies in Supplier Management ........... 363 III.23.2 Traceability over Several Artifact Models without

Redundancies ................................................................. 365 III.23.3 Decoupled Development of Requirement and Design

Artifacts .......................................................................... 368

XVIII Contents

III.24 Overall Architecture of R2A .................................................... 370 III.24.1 General Architecture ........................................................ 370 III.24.2 The Meta-Model .............................................................. 372 III.24.3 Further Interfaces ............................................................. 376

IV. Synopsis ...................................................................................................... 379

IV.25 Summary of the Achieved Research Results ........................... 379 IV.26 Perspectives for Further Research ........................................... 385

IV.27 Conclusions ................................................................................ 392

Bibliography ......................................................................................... 395 Index ...................................................................................................... 435

List of Figures

Figure 1-1 Properties of original and model [LL07; p.6 (*)] ........................ 14 Figure 4-1 The view of systems engineering processes of Hood et al.

[HWF+08; p.29] .......................................................................... 30 Figure 5-1 Functional and nonfunctional requirements [HR02; p.86 ff] ...... 37 Figure 5-2 The Requirements Engineering framework defined by Pohl

[Po08; p.39 (*)] ........................................................................... 41 Figure 5-3 The view of Hood et al. [HWF+08] logically derived by the

author. .......................................................................................... 44 Figure 5-4 Overview over different traceability terms oriented on Brcina

[Br07a; p.4] ................................................................................. 58 Figure 5-5 The three dimensions of the RE framework

[Po93; p.284], [Po08; p.42] ......................................................... 61 Figure 6-1 The design problem space according to Goel [Go99; fig.1] ....... 93 Figure 7-1 Processes defined in ISO/IEC 15504-5 basing on

ISO/IEC 12207 .......................................................................... 123 Figure 7-2 The example in current practice of the SPICE process model .. 143 Figure 7-3 The altered example above with less redundancies ................... 146 Figure 7-4 Summary of traceability BPs in A-SPICE [ASPICE08a;

Annex E] ................................................................................... 149 Figure 9-1 IBIS schema example outlining a discussion. ........................... 168 Figure 9-2 QOC schema as interpreted by [HHL+06; p.413] ..................... 169 Figure 10-1 A requirements specification with attributes in IBM Rational

DOORS ..................................................................................... 207 Figure 10-2 Efficiency gains, process orientation and tool support

[Eb08; p.290] ............................................................................ 235 Figure 10-3 Traceability tool couplings via surrogate modules .................... 250 Figure 10-4 Requirements fan-out effect according to Alderidge [Al03] ..... 253 Figure 12-1 Example use case of the case study ........................................... 265 Figure 12-2 Requirements specification for the case study in IBM

Rational DOORS ....................................................................... 266 Figure 12-3 Example SW design for the requirements specification

in fig. 12-2 ................................................................................. 267 Figure 13-1 R2A in combination with a design tool (Sparx Systems

Enterprise Architect) ................................................................. 268 Figure 13-2 Logical structure of the R2A tool approach .............................. 270

XX List of Figures

Figure 15-1 Hierarchical decomposition of a system shown as abstraction tree .......................................................................... 273

Figure 15-2 Detailed content and structure of an abstraction node (SubSystem1) ............................................................................ 274

Figure 15-3 Example of a UML project repository in Enterprise Architect . 276 Figure 15-4 With the AN tree view and the tab “Views and Description” ... 279 Figure 16-1 Different modeling tools integrated into one design model

via R2A ..................................................................................... 283 Figure 17-1 The properties dialog in R2A ................................................... 289 Figure 18-1 Managing different requirement sources in R2A ...................... 291 Figure 18-2 Requirements source document synchronized with IBM

Rational DOORS ...................................................................... 291 Figure 18-3 Ways of establishing requirements traceability via drag-

and-drop in R2A. ...................................................................... 298 Figure 18-4 Requirements and the requirement influence scope .................. 300 Figure 18-5 Showing requirements in the design situational context of

an AN ........................................................................................ 303 Figure 18-6 Overview of how the requirements-related features are

integrated into R2A concerning navigation and handling......... 312 Figure 19-1 Requiremental items, requirements and design constraints

taxonomy .................................................................................. 314 Figure 20-1 Interactions between nonfunctional, functional requirements

and architectural decisions [PDK+02] ...................................... 317 Figure 20-2 Documented decisions build the connection between

requirements, design elements and resulting design constraints ................................................................................ 318

Figure 20-3 The newly emerged and more detailed traceability information scheme................................................................... 323

Figure 20-4 The example of SPICE conforming design processes in the new way .............................................................................. 325

Figure 20-5 Decision dialog in R2A ............................................................ 326 Figure 20-6 R2A's visualization of the decision taken above ...................... 328 Figure 20-7 Architectural influence factors assessment with R2A's

decision model .......................................................................... 333 Figure 20-8 Consequences of the architectural influence factors

assessment of fig. 20-7 ............................................................. 334 Figure 21-1 Requiremental items taxonomy with budgeted resource

constraints ................................................................................ 343 Figure 21-2 Resource allocation example with budgeted resource

constraints ................................................................................ 344

List of Figures XXI

Figure 21-3 Sub budgeting of the Light_hdl module .................................... 346 Figure 21-4 Tabular view with corresponding abstraction hierarchies. ........ 348 Figure 21-5 Tabular view with assignment inconsistency (selected line) ..... 349 Figure 21-6 Representation of the same information as fig. 21-4 but

in SysML view .......................................................................... 350 Figure 21-7 Example for combining both decision models together ............ 352 Figure 22-1 Two examples for visualizing impact on the abstraction

nodes hierarchy ......................................................................... 354 Figure 22-2 Impact analysis dialog and R2A's main window with an

impact set taking decisions into account ................................... 356 Figure 22-3 The model browser in R2A ....................................................... 358 Figure 22-4 Life-cycle of a requiremental item and its color coding

in R2A ....................................................................................... 361 Figure 23-1 Process chain of an integrated design model for system, HW

and SW design ........................................................................... 366 Figure 23-2 Process chain of multi-layered requirements and design

artifacts ...................................................................................... 367 Figure 23-3 Consistent integration of changes ( ) beyond version

barriers ...................................................................................... 369 Figure 24-1 High-level architecture of R2A ................................................. 372 Figure 24-2 The meta-model of R2A ............................................................ 374

List of Tables

Table 7.1 Maturity Levels and their Process Attributes (cf.[HDH+06; p.16]) ................................................................. 122

Table 9.1 Alternative categorization of rationale approaches [OM07; p.16]............................................................................. 176

Table 9.2 Relation to design theories and rationale in design according to [HA06a; p.77] ....................................................... 187

Table 10.1 Prioritization of stakeholders and usage purposes concerning traceability between requirement and design artifacts .............. 203

Table 10.2 Characteristics of low-end and high-end traceability users [RJ01; p.65] ............................................................................... 225

Table 10.3 Kinds of traceability tools according to [GF94] and [Kn01b; p.57] ............................................................................ 236

Table 20.1 Example of an architectural influence factors assessment ........ 332 Table 21.1 Example resource estimation of RAM consumption in

design ........................................................................................ 342

Abbreviations

The following lists the most common abbreviations used in this thesis over sever-al chapters: AIS Actual Impact Set AN Abstraction Node – a concept of R2A (cf. ch. III.15) ANH Abstraction Nodes Hierarchy – a concept of R2A (cf. ch.

III.15) A-SPICE Automotive SPICE (cf. ch. I.7.4) BRC Budgeted Resource Constraint – a concept of R2A (cf. ch.

III.21) CCB Change Control Board CMMI Capability Maturity Model integrated (cf. ch. I.7) COTS Commercial Off The Shelf CRS Customer Requirements Specification CTM Conceptual Traceability Model CusSysDes The Customer's System Design DC A Design Contraint as a concept of R2A (part III) DEC A conflict based Decision a concept of R2A (part III) DOD United States Department of Defense DRL Decision Representation Language an RatMan approach

(cf. ch. II.9) DXL DOORS eXtension Language ECU Embedded Control Unit EEPROM Electrically Erasable Programmable Read Only Memory EIS Estimated Impact Set FR Functional Requirement GUI Graphical User Interface GUID General Unique IDentifier HMI Human Machine Interface

XXVI Abbreviations

HIS Hersteller Initiative Software – Standardization Board of German Automotive OEMs (cf. ch. I.7)

HW Hardware HW_RS Hardware Requirements Specification IBIS Issue Based Information System an RatMan (cf. ch. II.9)

approach (see also gIBIS) IDE Integrated Development Environment ISO International Standards Organization MF Measurement Framework (see SPICE) NFR Nonfunctional Requirement OCL Object Contraint Language PAM Process Assessment Model (see SPICE) PRM Process Reference Model (see SPICE) QOC Questions, Options, Criteria an RatMan approach (cf. ch.

II.9) R2A PROVEtech:R2A – The tool environment resulting from

this research (part III) RatMan Rationale Management (cf. ch. II.9) RDP Requirements Dribble Process a heuristic supported by

R2A (part III) REM Requirements Engineering and Management REQ Requirement from the customer as a concept of R2A

(part III) RI Requiremental Item a concept of R2A (part III) RIF Requirement Interchange Format RIS Requirement Influence Scope a concept of R2A in con-

nection with the RDP (part III) ROM Read Only Memory RUP Rational Unified Process RE Requirements Engineering RM Requirements Management REM Requirement Engineering and Management RMS Rationale Management System

Abbreviations XXVII

RSD Requirement Source Document as a concept of R2A (part III)

RTF Rich Text Format SE Software Engineering SEI Software Engineering Institute (SEI) of the Carnegie

Mellon University in Pittsburg SIL Safety Integrity Level as described in IEC 61508 SIS Starting Impact Set SPICE Software Process Improvement Capability dEtermination

(IS0 15504), (cf. ch. I.7) SysEng Systems Engineering (ch. I.4) SYS_RS System Requirements Specification SuppRS Supplier Requirements Specifications SW Software SW_RS Software Requirements Specification SysML System Modeling Language TQM Total Quality Management (cf. ch. I.7) UML Unified Modeling Language