An Integrated Decision Model For Efficient Requirement Traceability In SPICE Compliant Development

Requirement traceability ensures that (SW-)products meet their requirements and additionally makes the estimation of the consequences of requirement changes possible. It is especially difficult to establish at the transition from requirements specification to its provision in the design, because design processes represent creative and complex transfers of mostly unique problem constellations into a sustainable solution (so-called Wicked Problems). At first, this article searches for symptoms of the problem in analyzing the process model of ISO 12207, the foundation of SPICE or CMMi. This analysis mainly serves the derivation of a concept for the integrated extension of today's traceability models with the aspect of documented design decisions. In the context of current approaches in Rationale Management, our concept proofs as sustainable solution that supports - heavyweight" prescriptive approaches as well as - lightweight" pragmatic approaches and -moreover -shows interdependencies between both kinds.

[1]  Barry Boehm,et al.  The Future of Software and Systems Engineering Processes , 2005 .

[2]  Gerald W. Both,et al.  Object-oriented analysis and design with applications , 1994 .

[3]  Mikael Lindvall.  A study of traceability in object-oriented systems development , 1994 .

[4]  Matthias Jarke,et al.  The NATURE of Requirements Engineering , 1999 .

[5]  Ralf Kneuper,et al.  CMMI - Verbesserung von Softwareprozessen mit Capability Maturity Model Integration (2. Aufl.) , 2003 .

[6]  C. P. Goodman,et al.  The Tacit Dimension , 2003 .

[7]  Michael E. Atwood,et al.  Effective Design Rationale: Understanding the Barriers , 2006 .

[8]  Paul Clements,et al.  Capturing and Using Rationale for a Software Architecture , 2006 .

[9]  Oscar Nierstrasz,et al.  Software Evolution as the Key to Productivity , 2002, RISSEF.

[10]  R.G. Pettit.  Lessons learned applying UML in embedded software systems designs , 2004, Second IEEE Workshop on Software Technologies for Future Embedded and Ubiquitous Systems, 2004. Proceedings..

[11]  Raymond McCall,et al.  Rationale Management in Software Engineering , 2006 .

[12]  Patricia Lago,et al.  Recovering architectural assumptions , 2006, J. Syst. Softw..

[13]  Muhammad Ali Babar,et al.  A Survey of the Use and Documentation of Architecture Design Rationale , 2005, 5th Working IEEE/IFIP Conference on Software Architecture (WICSA'05).

[14]  Klaus Pohl.  A process centered requirements engineering environment , 1994 .

[15]  Matthias Jarke,et al.  Toward Reference Models of Requirements Traceability , 2001, IEEE Trans. Software Eng..

[16]  Raymond McCall,et al.  Rationale Management in Software Engineering: Concepts and Techniques , 2006 .

[17]  Jeff Tyree,et al.  Architecture decisions: demystifying architecture , 2005, IEEE Software.

[18]  D. Schoen,et al.  The Reflective Practitioner: How Professionals Think in Action , 1985 .

[19]  Andrew Dillon,et al.  Design rationale: Concepts, techniques, and use , 1997 .

[20]  Bashar Nuseibeh,et al.  Weaving Together Requirements and Architectures , 2001, Computer.

[21]  Jonathan Grudin,et al.  Evaluating Opportunities for Design Capture , 1996 .

[22]  Jeremy Dick,et al.  7.1.2 The Systems Engineering Sandwich: combining requirements, models and design , 2004 .

[23]  R. J. Bogumil,et al.  The reflective practitioner: How professionals think in action , 1985, Proceedings of the IEEE.

[24]  Olly Gotel,et al.  An analysis of the requirements traceability problem , 1994, Proceedings of IEEE International Conference on Requirements Engineering.

[25]  Meir M. Lehman,et al.  The Role and Impact of Assumptions in Software Engineering and its Products , 2006 .

[26]  Antje von Knethen,et al.  Change-Oriented Requirements Traceability: Support for Evolution of Embedded Systems , 2002, ICSM.

[27]  Pericles Loucopoulos,et al.  A generic model for reflective design , 2000, TSEM.

[28]  Kuntz Werner,et al.  Issues as Elements of Information Systems , 1970 .

[29]  Frank M. Shipman,et al.  Formality Considered Harmful: Experiences, Emerging Themes, and Directions on the Use of Formal Representations in Interactive Systems , 1999, Computer Supported Cooperative Work (CSCW).

[30]  Barbara Paech,et al.  Functional requirements, non-functional requirements, and architecture should not be separated -A position paper , 2002 .

[31]  Antje von Knethen.  A trace model for system requirements changes on embedded systems , 2001, IWPSE '01.

[32]  Kurt Schneider.  Rationale as a By-Product , 2006 .

[33]  Vasant Dhar,et al.  Supporting Systems Development by Capturing Deliberations During Requirements Engineering , 1992, IEEE Trans. Software Eng..

[34]  Klaus Birken,et al.  Basiswissen Softwarearchitektur - verstehen, entwerfen, bewerten und dokumentieren , 2004 .

[35]  R. B. Hunter,et al.  Processes for software in safety critical systems , 2001, Softw. Process. Improv. Pract..