case study on requirements traceability

Login to your account

Change password, your password must have 8 characters or more and contain 3 of the following:.

• a lower case character, 
• an upper case character, 
• a special character 

Password Changed Successfully

Your password has been changed

Create a new account

Can't sign in? Forgot your password?

Enter your email address below and we will send you the reset instructions

If the address matches an existing account you will receive an email with instructions to reset your password

Request Username

Can't sign in? Forgot your username?

Enter your email address below and we will send you your username

If the address matches an existing account you will receive an email with instructions to retrieve your username

• This Journal
•   
• Institutional Access

Cookies Notification

Our site uses javascript to enchance its usability. you can disable your ad blocker or whitelist our website www.worldscientific.com to view the full content., select your blocker:, adblock plus instructions.

• Click the AdBlock Plus icon in the extension bar
• Click the blue power button
• Click refresh

Adblock Instructions

• Click the AdBlock icon
• Click "Don't run on pages on this site"

uBlock Origin Instructions

• Click on the uBlock Origin icon in the extension bar
• Click on the big, blue power button
• Refresh the web page

uBlock Instructions

• Click on the uBlock icon in the extension bar

Adguard Instructions

• Click on the Adguard icon in the extension bar
• Click on the toggle next to the "Protection on this website" text

Brave Instructions

• Click on the orange lion icon to the right of the address bar
• Click the toggle on the top right, shifting from "Up" to "Down

Adremover Instructions

• Click on the AdRemover icon in the extension bar
• Click the "Don’t run on pages on this domain" button
• Click "Exclude"

Adblock Genesis Instructions

• Click on the Adblock Genesis icon in the extension bar
• Click on the button that says "Whitelist Website"

Super Adblocker Instructions

• Click on the Super Adblocker icon in the extension bar
• Click on the "Don’t run on pages on this domain" button
• Click the "Exclude" button on the pop-up

Ultrablock Instructions

• Click on the UltraBlock icon in the extension bar
• Click on the "Disable UltraBlock for ‘domain name here’" button

Ad Aware Instructions

• Click on the AdAware icon in the extension bar
• Click on the large orange power button

Ghostery Instructions

• Click on the Ghostery icon in the extension bar
• Click on the "Trust Site" button

Firefox Tracking Protection Instructions

• Click on the shield icon on the left side of the address bar
• Click on the toggle that says "Enhanced Tracking protection is ON for this site"

Duck Duck Go Instructions

• Click on the DuckDuckGo icon in the extension bar
• Click on the toggle next to the words "Site Privacy Protection"

Privacy Badger Instructions

• Click on the Privacy Badger icon in the extension bar
• Click on the button that says "Disable Privacy Badger for this site"

Disconnect Instructions

• Click on the Disconnect icon in the extension bar
• Click the button that says "Whitelist Site"

Opera Instructions

• Click on the blue shield icon on the right side of the address bar
• Click the toggle next to "Ads are blocked on this site"

System Upgrade on Tue, May 28th, 2024 at 2am (EDT)

Requirements traceability: a systematic review and industry case study.

• RICHARD TORKAR , 
• TONY GORSCHEK , 
• ROBERT FELDT , 
• MIKAEL SVAHNBERG , 
• UZAIR AKBAR RAJA , and 
• KASHIF KAMRAN

http://www.bth.se/com/serl Blekinge Institute of Technology, S-371 79 Karlskrona, Sweden

Search for more papers by this author

Requirements traceability enables software engineers to trace a requirement from its emergence to its fulfillment. In this paper we examine requirements traceability definitions, challenges, tools and techniques, by the use of a systematic review performing an exhaustive search through the years 1997–2007. We present a number of common definitions, challenges, available tools and techniques (presenting empirical evidence when found), while complementing the results and analysis with a static validation in industry through a series of interviews.

• Requirements traceability
• systematic review
• A.   Abran et al. (eds.) , Guide to the Software Engineering Body of Knowledge (SWEBOK) ( IEEE Computer Society , Los Alamitos , 2004 ) . Google Scholar
• W. Afzal, R. Torkar and R. Feldt, Information and Software Technology   51 (6), 957 (2009). Web of Science ,  Google Scholar
• S. Ahn and K. Chong , A feature-oriented requirements tracing method: A study of cost-benefit analysis , Proc. of the 2006 International Conference on Hybrid Information Technology (IEEE Computer Society, 2006 ) pp. 611–616. Google Scholar
• G. Antoniol et al. , IEEE Transactions on Software Engineering   28 (10), 970 (2002). Web of Science ,  Google Scholar
• P. Arkley and S. Riddle , Overcoming the traceability benefit problem , Proc. of the 13th IEEE International Conference on Requirements Engineering ( 2005 ) pp. 385–389. Google Scholar
• A.   Aurum and C.   Wohlin , Engineering and Managing Software Requirements ( Springer-Verlag , New York , 2005 ) . Google Scholar
• S. C.   Bailin et al. , Software Requirements Engineering , 2nd edn. ( IEEE Computer Society Press , Los Alamitos , 1997 ) . Google Scholar
• M. F. Bashir and M. A. Qadir , Traceability techniques: A critical study , IEEE Multitopic Conference ( 2006 ) pp. 265–268. Google Scholar
• F. Blaauboer , K. Sikkel and M. N. Aydin , Deciding to adopt requirements traceability in practice , CAiSE , LNCS , eds. J. Krogstie , A. L. Opdahl and G. Sindre (Springer, 2007 ) pp. 294–308. Google Scholar
• F. Bouquet et al. , SIGSOFT Software Engineering Notes   30 (4), 1 (2005). Web of Science ,  Google Scholar
• F. Bubl and M. Balser , Tracing cross-cutting requirements via context-based constraints , Proceedings of the 9th European Conference on Software Maintenance and Reengineering ( 2005 ) pp. 80–90. Google Scholar
• P. Carlshamre et al. , An industrial survey of requirements interdependencies in software product release planning , Proceedings of the Fifth IEEE International Symposium on Requirements Engineering ( 2001 ) p. 84. Google Scholar
• L.   Chung et al. , Non-functional Requirements in Software Engineering , The Kluwer International Series in Software Engineering   5 ( Kluwer Academic Publisher , 1999 ) . Google Scholar
• J. Cleland-Huang , Toward improved traceability of non-functional requirements , Proceedings of the 3rd International Workshop on Traceability in Emerging Forms of Software Engineering (ACM, New York, NY, USA, 2005 ) pp. 14–19. Google Scholar
• J. Cleland-Huang et al. , IEEE Computer   40 (6), 27 (2007). Web of Science ,  Google Scholar
• J. Cleland-Huang, C. K. Chang and M. Christensen, IEEE Transactions on Software Engineering   29 (9), 796 (2003). Web of Science ,  Google Scholar
• J. Cleland-Huang , C. K. Chang and Y. Ge , Supporting event based traceability through high-level recognition of change events , Proceedings of the 26th International Computer Software and Applications Conference on Prolonging Software Life: Development and Redevelopment (IEEE Computer Society, 2002 ) pp. 595–602. Google Scholar
• J. Cleland-Huang et al. , Automating speculative queries through event-based requirements traceability , Proceedings of the 10th Anniversary IEEE Joint International Conference on Requirements Engineering (IEEE Computer Society, 2002 ) pp. 289–298. Google Scholar
• J. Cleland-Huang, C. K. Chang and J. C. Wise, Requirements Engineering   8 (3), 171 (2003). Google Scholar
• J. Cleland-Huang et al. , Goal-centric traceability for managing non-functional requirements , Proceedings of the 27th International Conference on Software Engineering (ACM, New York, NY, USA, 2005 ) pp. 362–371. Google Scholar
• J. Cleland-Huang et al. , Utilizing supporting evidence to improve dynamic requirements traceability , Proceedings of the 13th IEEE International Conference on Requirements Engineering (IEEE Computer Society, 2005 ) pp. 135–144. Google Scholar
• J. Cleland-Huang , G. Zemont and W. Lukasik , A heterogeneous solution for improving the return on investment of requirements traceability , Proceedings of the 12th IEEE International Requirements Engineering Conference (IEEE Computer Society, 2004 ) pp. 230–239. Google Scholar
• Software Engineering Institute|Carnegie Mellon, http://www.sei.cmu.edu/cmmi/ October 2008 . Google Scholar
• L. M. Cysneiros and J. C. S. do Prado Leite, IEEE Transactions on Software Engineering   30 (5), 328 (2004). Web of Science ,  Google Scholar
• A. Dekhtyar, J. H. Hayes and S. K. Sundaram, IEEE Transactions on Software Engineering   32 (1), 4 (2006). Web of Science ,  Google Scholar
• Department of Defence, US. Military standard: Defense system software development (DOD-STD-2167A), Technical report, Space and Naval Warfare Systems Command, Washington, DC, February 1988 . Google Scholar
• J. Dick, IEEE Software   22 (6), 14 (2005). Web of Science ,  Google Scholar
• J. C. S. do Prado Leite and K. K. Breitman, Experiences using scenarios to enhance traceability, in 2nd International Workshop on Traceability in Emerging Forms of Software Engineering in Conjunction with the 18th IEEE International Conference on Automated Software Engineering, Montreal, Canada, October 2003, pp. 63–70 . Google Scholar
• T. Dybå, V. B. Kampenes and D. I. Sjøberg, Information and Software Technology   48 (8), 745 (2006). Web of Science ,  Google Scholar
• M. Edwards and S. L. Howell, A Methodology for system requirements specification and traceability for large real-time complex systems, Technical report, Naval Surface Warfare Center, 1991 . Google Scholar
• A. Egyed and P. Grünbacher , Automating requirements traceability: Beyond the record and replay paradigm , Proceedings of the 17th IEEE International Conference on Automated Software Engineering ( 2002 ) p. 163. Google Scholar
• E. Engström, P. Runeson and M. Skoglund, Information and Software Technology   52 (1), 14 (2010). Web of Science ,  Google Scholar
• R. Feldt et al. , Searching for cognitively diverse tests: Towards universal test diversity metrics , Proceedings of 1st Search-Based Software Testing Workshop (SBST'08) ( 2008 ) pp. 178–186. Google Scholar
• T. Gorschek, Requirements Engineering Supporting Technical Product Management, PhD thesis, Department of Systems and Software Engineering, Blekinge Institute of Technology, May 2006 . Google Scholar
• T. Gorschek et al. , IEEE Software   23 (6), 88 (2006). Web of Science ,  Google Scholar
• T. Gorschek and C. Wohlin, Requirements Engineering   11 (1), 79 (2005). Web of Science ,  Google Scholar
• O. Gotel and A. Finkelstein , An analysis of the requirements traceability problem , International Conference on Requirements Engineering ( 1994 ) pp. 94–101. Google Scholar
• O. Gotel and A. Finkelstein , Extended requirements traceability: Results of an industrial case study , Proceedings of the 3rd IEEE International Symposium on Requirements Engineering ( 1997 ) p. 169. Google Scholar
• O. Gotel and S. J. Morris , Crafting the requirements record with the informed use of media , Proceedings of the First International Workshop on Multimedia Requirements Engineering ( 2006 ) p. 5. Google Scholar
• D. Gross and E. Yu, Requirements Engineering   6 (1), 18 (2001). Google Scholar
• V. L. Hamilton and M. L. Beeby , Issues of traceability in integrating tools , Proceedings of the IEE Colloquium Tools and Techniques for Maintaining Traceability during Design ( 1991 ) pp. 4/1–4/3. Google Scholar
• J. Han, Australian Computer Science Communications   23 (1), 60 (2001). Google Scholar
• Ø. Hauge, C. Ayala and R. Conradi, Information and Software Technology   52 (11), 1133 (2010). Web of Science ,  Google Scholar
• J. H. Hayes , A. Dekhtyar and J. Osborne , Improving requirements tracing via information retrieval , Proceedings of the 11th IEEE International Conference on Requirements Engineering ( 2003 ) p. 138. Google Scholar
• J. H. Hayes, A. Dekhtyar and S. K. Sundaram, IEEE Software   22 (6), 30 (2005). Web of Science ,  Google Scholar
• J. H. Hayes et al. , Innovations in Systems and Software Engineering   3 (3), 193 (2007). Web of Science ,  Google Scholar
• M. Heindl and S. Biffl, A case study on value-based requirements tracing, in Proceedings of the 10th European Software Engineering Conference Held Jointly with 13th ACM SIGSOFT International Symposium on Foundations of Software Engineering, New York, NY, USA, 2005, pp. 60–69 . Google Scholar
• R. A.   Howard and J. E.   Matheson (eds.) , Readings on the Principles and Applications of Decision Analysis ( Strategic Decision Group , Menlo Park, California , 1984 ) . Google Scholar
• IEEE Society, IEEE recommended practice for software requirements specifications (IEEE Std. 830–1998), Technical report, IEEE Computer Society, 1998 . Google Scholar
• M. Ivarsson and T. Gorschek, Requirements Engineering   14 (3), 155 (2009). Web of Science ,  Google Scholar
• M. Jarke, Communications of the ACM   41 (12), 32 (1998). Web of Science ,  Google Scholar
• W. Jirapanthong and A. Zisman, XTraQue: Traceability for product line systems, Software and Systems Modeling, 2007 . Google Scholar
• N. Kececi , J. Garbajosa and P. Bourque , Modeling functional requirements to support traceability analysis , 2006 IEEE International Symposium on Industrial Electronics 4 ( 2006 ) pp. 3305–3310. Google Scholar
• J. Kelleher , A reusable traceability framework using patterns , Proceedings of the 3rd International Workshop on Traceability in Emerging Forms of Software Engineering ( 2005 ) pp. 50–55. Google Scholar
• B. Kitchenham, Procedures for performing systematic reviews, Technical report, Keele University and NICTA, 2004 . Google Scholar
• M. Lormans and A. van Deursen , Reconstructing requirements coverage views from design and test using traceability recovery via LSI , Proceedings of the 3rd International Workshop on Traceability in Emerging Forms of Software Engineering ( 2005 ) pp. 37–42. Google Scholar
• A. de Lucia et al. , ACM Transactions on Software Engineering and Methodology   16 (4), 13 (2007). Web of Science ,  Google Scholar
• A. Marcus, J. I. Maletic and A. Sergeyev, International Journal of Software Engineering and Knowledge Engineering   15 (5), 811 (2005). Link , Web of Science ,  Google Scholar
• L. Naslavsky et al. , Using scenarios to support traceability , Proceedings of the 3rd International Workshop on Traceability in Emerging Forms of Software Engineering ( 2005 ) pp. 25–30. Google Scholar
• R. P. Noll and M. B. Ribeiro , Enhancing traceability using ontologies , Proceedings of the 2007 ACM Symposium on Applied Computing ( 2007 ) pp. 1496–1497. Google Scholar
• I. Ozkaya and O. Akin, Automation in Construction   16 , 674 (2007). Web of Science ,  Google Scholar
• K. Pohl , R. Dömges and M. Jarke , Towards method-driven trace capture , Proceedings of the 9th International Conference on Advanced Information Systems Engineering ( 1997 ) pp. 103–116. Google Scholar
• B. Ramesh, Communications of the ACM   41 (12), 37 (1998). Web of Science ,  Google Scholar
• B. Ramesh and M. Jarke, IEEE Transactions on Software Engineering   27 (1), 58 (2001). Web of Science ,  Google Scholar
• B. Ramesh et al. , Annals of Software Engineering   3 , 397 (1997). Google Scholar
• R. Ravichandar, J. D. Arthur and M. Perez-Quinones, Pre-requirement specification traceability: Bridging the complexity gap through capabilities, 2007 . Google Scholar
• M. Riebisch and M. Hubner , Traceability-driven model refinement for test case generation , Proceedings of the 12th IEEE International Conference and Workshops on Engineering of Computer-Based Systems ( 2005 ) pp. 113–120. Google Scholar
• S. Rochimah , W. M. N. Wan Kadir and A. H. Abdullah , An evaluation of traceability approaches to support software evolution , Proceedings of the 2007 International Conference on Software Engineering Advances ( 2007 ) p. 19. Google Scholar
• A. M. Salem , Improving software quality through requirements traceability models , Proceedings of the IEEE International Conference on Computer Systems and Applications ( 2006 ) pp. 1159–1162. Google Scholar
• C. B. Seaman, IEEE Transactions on Software Engineering   25 (4), 557 (1999). Web of Science ,  Google Scholar
• Requirements tracing — An overview, http://www.sei.cmu.edu/str/descriptions/reqtracing.html, October 2008 . Google Scholar
• S. A. Sherba and K. M. Anderson, A framework for managing traceability relationships between requirements and architectures, in Second International Software Requirements to Architectures Workshop Part of 2003 International Conference on Software Engineering, New York, NY, USA, 2003, pp. 150–156 . Google Scholar
• J. E. Shin, A. G. Sutcliffe and A. Gregoriades, Requirements Engineering   10 (2), 132 (2005). Web of Science ,  Google Scholar
• I.   Sommerville and G.   Kotonya , Requirements Engineering: Processes and Techniques ( John Wiley & Sons , New York , 1998 ) . Google Scholar
• I.   Sommerville and P.   Sawyer , Requirements Engineering: A Good Practice Guide ( John Wiley & Sons , New York , 1997 ) . Google Scholar
• G. Spanoudakis et al. , Journal of Systems and Software   72 , 105 (2004). Web of Science ,  Google Scholar
• D. Streitferdt , Traceability for system families , Proceedings of the 23rd International Conference on Software Engineering ( 2001 ) pp. 803–804. Google Scholar
• R. Torkar, T. Gorschek, R. Feldt, U. A. Raja and K. Kamran, Questionnaire with answers, http://dl.dropbox.com/u/2437798/questions_and_answers.pdf, October 2008 . Google Scholar
• R. Torkar, T. Gorschek, R. Feldt, U. A. Raja and K. Kamran, Rejected articles, http://dl.dropbox.com/u/2437798/rej_art.pdf, October 2008 . Google Scholar
• B. Tvete , Introducing efficient requirements management , Proceedings of the 10th International Workshop on Database and Expert Systems Applications ( 1999 ) p. 370. Google Scholar
• T. Verhanneman et al. , Requirements traceability to support evolution of access control , Proceedings of the 2005 Workshop on Software Engineering for Secure Systems — Building Trustworthy Applications (ACM, New York, USA, 2005 ) pp. 1–7. Google Scholar
• C.   Wohlin et al. , Experimentation in Software Engineering: An Introduction ( Kluwer Academic Publishers , Norwell , 2000 ) . Google Scholar
• S. Yadla, J. H. Hayes and A. Dekhtyar, Innovations in Systems and Software Engineering   1 (2), 116 (2005). Google Scholar

• A systematic literature review of pre-requirements specification traceability Julia Mucha, Andreas Kaufmann and Dirk Riehle 26 January 2024 | Requirements Engineering, Vol. 29, No. 2
• Requirements and software engineering for automotive perception systems: an interview study Khan Mohammad Habibullah, Hans-Martin Heyn, Gregory Gay, Jennifer Horkoff and Eric Knauss et al. 24 January 2024 | Requirements Engineering, Vol. 29, No. 1
• Analyzing Tools and Techniques for Evaluating Requirements Traceability Shoaib Hassan, Qianmu Li, Affan Yasin and Muhammad Zubair 17 Nov 2023
• A Proposal to Trace and Maintain Requirements Constraints of Real-time Embedded Systems Fabíola Gonçalves C. Ribeiro, Achim Rettberg, Carlos E. Pereira, Charles Steinmetz and Michel S. Soares 17 February 2023
• Natural Language Processing for Requirements Engineering Liping Zhao, Waad Alhoshan, Alessio Ferrari, Keletso J. Letsholo and Muideen A. Ajagbe et al. 17 April 2021 | ACM Computing Surveys, Vol. 54, No. 3
• A validation of QDAcity-RE for domain modeling using qualitative data analysis Andreas Kaufmann, Julia Krause, Nikolay Harutyunyan, Ann Barcomb and Dirk Riehle 16 August 2021 | Requirements Engineering, Vol. 27, No. 1
• Goal-Oriented Software Design Reviews Michiyo Wakimoto and Shuji Morisaki 1 Jan 2022 | IEEE Access, Vol. 10
• What have we learnt from the challenges of (semi‐) automated requirements traceability? A discussion on blockchain applicability Selina Demi, Mary Sanchez‐Gordon and Ricardo Colomo‐Palacios 4 July 2021 | IET Software, Vol. 15, No. 6
• WITHDRAWN: An adaptive optimization based meta-heuristic approach for tracing software requirements K. Swathine and N. Sumathi 1 Mar 2021 | Materials Today: Proceedings, Vol. 39
• Empirical studies on software traceability: A mapping study Sofia Charalampidou, Apostolos Ampatzoglou, Evangelos Karountzos and Paris Avgeriou 30 June 2020 | Journal of Software: Evolution and Process, Vol. 33, No. 2
• Smart and Agile Manufacturing Framework, A Case Study for Automotive Industry Gullelala Jadoon, Ikram Ud Din, Ahmad Almogren and Hisham Almajed 3 November 2020 | Energies, Vol. 13, No. 21
• Comparative study on web-based and cloud-based application Anisha Tandon, Mamta Madan and Meenu Dave 14 August 2020 | Journal of Information and Optimization Sciences, Vol. 41, No. 7
• Ethical Considerations in Case Studies Liang Yu 1 Aug 2020
• Traceability Framework for Requirement Artefacts Foziah Gazzawe, Russell Lock and Christian Dawson 4 July 2020
• Improving Requirement Prioritization and Traceability using Artificial Intelligence Technique for Global Software Development Wasi Haider, Yaser Hafeez, Sadia Ali, Muhammad Jawad and Fahad Burhan Ahmad et al. 1 Nov 2019
• Johnny Marques  and 
• Adilson Marques da Cunha
• Mitigating Threats to Validity in Empirical Software Engineering: A Traceability Case Study Nasser Mustafa, Yvan Labiche and Dave Towey 1 Jul 2019
• Towards A Knowledge Base for Software Developers to Choose Suitable Traceability Techniques Haruhiko Kaiya, Atsuo Hazeyama, Shinpei Ogata, Takao Okubo and Nobukazu Yoshioka et al. 1 Jan 2019 | Procedia Computer Science, Vol. 159
• Requirements traceability technologies and technology transfer decision support: A systematic review Bangchao Wang, Rong Peng, Yuanbang Li, Han Lai and Zhuo Wang 1 Dec 2018 | Journal of Systems and Software, Vol. 146
• A method of requirements change analysis Shalinka Jayatilleke, Richard Lai and Karl Reed 14 July 2017 | Requirements Engineering, Vol. 23, No. 4
• Software traceability in the automotive domain: Challenges and solutions Salome Maro, Jan-Philipp Steghöfer and Miroslaw Staron 1 Jul 2018 | Journal of Systems and Software, Vol. 141
• Traceability information model for very small entities with ISO/IEC 29110 Marco Antonio García Carrión, Medardo Delgado Paredes, Percy Huertas Niquen and Álvaro Fernández del Carpio 20 April 2018
• Automated Extraction and Clustering of Requirements Glossary Terms Chetan Arora, Mehrdad Sabetzadeh, Lionel Briand and Frank Zimmer 1 Oct 2017 | IEEE Transactions on Software Engineering, Vol. 43, No. 10
• The Need for Traceability in Heterogeneous Systems: A Systematic Literature Review Nasser Mustafa and Yvan Labiche 1 Jul 2017
• Challenges of Establishing Traceability in the Automotive Domain Salome Maro, Miroslaw Staron and Jan-Philipp Steghöfer 12 November 2016
• An Event-Based Technique to Trace Requirements Modeled with SysML Telmo Oliveira de Jesus and Michel S. Soares 15 July 2017
• Preliminary Systematic Literature Review of Software and Systems Traceability Haruhiko Kaiya, Ryohei Sato, Atsuo Hazeyama, Shinpei Ogata and Takao Okubo et al. 1 Jan 2017 | Procedia Computer Science, Vol. 112
• A method to realize traceability in development processes Rainer Dreves, Frank Hällmayer, Lutz Haunert, Bernhard Sechser and Armin Rieß 21 November 2016 | Journal of Software: Evolution and Process, Vol. 28, No. 11
• Achieving Better Requirements to Code Traceability: Which Refactoring Should Be Done First? Farina Faiz, Rubaida Easmin and Alim Ul Gias 1 Sep 2016
• TraceBoK: Toward a Software Requirements Traceability Body of Knowledge Ana Marcia Debiasi Duarte, Denio Duarte and Marcello Thiry 1 Sep 2016
• An approach to estimate the size of ERP package using package points Thangavel Chandrakumar and Sudhaman Parthasarathy 1 Aug 2016 | Computer Standards & Interfaces, Vol. 47
• An approach to estimation of degree of customization for ERP projects using prioritized requirements Sudhaman Parthasarathy and Maya Daneva 1 Jul 2016 | Journal of Systems and Software, Vol. 117
• Hyun-Seok Min
• Automated Checking of Conformance to Requirements Templates Using Natural Language Processing Chetan Arora, Mehrdad Sabetzadeh, Lionel Briand and Frank Zimmer 1 Oct 2015 | IEEE Transactions on Software Engineering, Vol. 41, No. 10
• Change impact analysis for Natural Language requirements: An NLP approach Chetan Arora, Mehrdad Sabetzadeh, Arda Goknil, Lionel C. Briand and Frank Zimmer 1 Aug 2015
• The impact of global dispersion on coordination, team performance and software quality – A systematic literature review Anh Nguyen-Duc, Daniela S. Cruzes and Reidar Conradi 1 Jan 2015 | Information and Software Technology, Vol. 57
• Achievements and Challenges in State-of-the-Art Software Traceability Between Test and Code Artifacts Reza Meimandi Parizi, Sai Peck Lee and Mohammad Dabbagh 1 Dec 2014 | IEEE Transactions on Reliability, Vol. 63, No. 4
• Empirical research methodologies and studies in Requirements Engineering: How far did we come? Maya Daneva, Daniela Damian, Alessandro Marchetto and Oscar Pastor 1 Sep 2014 | Journal of Systems and Software, Vol. 95
• Systematic reviews in requirements engineering: A systematic review Muhammad Imran Babar, Masitah Ghazali and Dayang N.A. Jawawi 1 Sep 2014
• Proposing a Systematic Approach to Verify Software Requirements Zuhoor Abdullah Salim Al-Khanjari 1 Jan 2014 | Journal of Software Engineering and Applications, Vol. 07, No. 04
• A review of traceability research at the requirements engineering conference^re@21 Sunil Nair, Jose Luis de la Vara and Sagar Sen 1 Jul 2013

Recommended

Received 18 February 2010 Revised 11 February 2011 Accepted 28 March 2011

• All Content

Articles & Posts

• Videos & Webinars
• White Papers
• Templates & Aids
• On the Lighter Side
• Top Contributors
• All Contributors
• How to Contribute
• Advertise with Us

Requirements traceability refers to the capability of a requirements management process or tool which enables the process participant or tool user to follow the life of a requirement both forwards and backwards.  It also refers the the ability to link requirements (via specific relationships) to other constructs or artifacts of the product developmetnt lifecycle.  Here are some examples of common requirements traceability relationships:

• business goal -> detailed requirement
• detailed requirement -> test script
• detailed requirement -> system component

I. Introduction to requirements traceability?

Requirements traceability ensures that each business need is tied to an actual requirement, and that each requirement is tied to a deliverable. This is a valuable practice for the business analyst. According to A Guide to the Business Analyst’s Body of Knowledge, (BABOK 2.0), all requirements are “related to other requirements, to solution components, and to other artifacts such as test cases. . . . The goal of tracing is to ensure that requirements (and ultimately, solution components) are linked back to a business objective.” 1 In other words, traceability ensures that every requirement has a business purpose, and that no requirement is superfluous.

A requirement may be traced in one of four distinct ways, according to Karl Weigers in his book Software Requirements

“Customer needs are traced forward to requirements, so that you can tell which requirements will be affected if those needs change.

Conversely, you can trace backward from requirements to customer needs to identify the origin of each software requirement.

You can trace forward from requirements by defining links between individual requirements and specific product elements.

Specific product elements [may be traced] backward to requirements so that you know why each item was created.” 2

Requirements may also be traced to other related requirements. So quite simply, requirements traceability traces relationships between requirements in a set, between business needs and corresponding requirements, and between requirements and the various deliverables of a project.

As to the granularity of tracing requirements, BABOK notes that “tracing may be performed at the individual requirement level, at the model or package level, or at the feature level as appropriate.” This decision, along with which requirements to trace, by what method, and indeed whether to trace requirements at all are all part of responsible requirements management.  

II. Why is requirements traceability important?

Tracing requirements, when done properly, saves time, money, and effort on the part of the analyst, the project sponsors and the parent organization. Business analysis industry experts have detailed the following benefits of requirements traceability:

​ 1. It ensures that final deliverables directly tie to initial business needs. Forward requirements traceability offers an analyst a means to be sure that business needs are tied to actual requirements, and that actual requirements are tied to deliverables. (Therefore, each business need is tied to a deliverable.) Conversely, backward traceability ensures that if a product feature is developed that no one remembers asking for or authorizing, the analyst can determine whether it is simply a case of gold-plating or if it is indeed tied to a requirement (and corresponding business need). According to BABOK, “When business objectives are traced to detailed require¬ments such as business rules, data elements, and use cases, it is clear how they will be accomplished. Each business objective can be reviewed to make sure that it will be addressed by the appropriate solution components.” 3

2. Done properly, it ensures that organizations do not waste time and resources repeating research. Without requirements traceability, organizations have the potential to waste a lot of money on backtracking, duplicate research, and lost business needs. In their article, “Why Software Requirements Traceability Remains a Challenge,” authors Andrew Kannenberg and Dr. Hossein Saiedian note that “inadequate traceability is an important contributing factor to software project failures and budget overruns.” 4 In his book Business Rule Concepts , Ronald G. Ross makes a similar point (writing specifically about business rule traceability, but the concept also applies to requirements traceability): “Discovering or reconstructing the pedigree of a business rule is time-consuming, error-prone, and sometimes impossible. Worse, once discovered or reproduced for a particular need . . . the history is often not retained. That means the whole process must be repeated, ad nauseum. Think of rulebook management [or requirements traceability] as a practical means to create pinpoint corporate memory, always keeping it right at your fingertips.” 5

3. It complies with established industry standards. Kannenberg and Saiedian further point out that traceability is a key ingredient in many respected industry standards for software development, including the CMMI and ISO 9001:2000. 6

4. If offers much easier impact analysis. Requirements traceability enables intelligent impact analysis; if a stakeholder wants to change a requirement once it is in development or testing, traceable links to business needs and other requirements enable an analyst or project manager to report the full impact of the requested change.

In addition to these benefits, BABOK also notes that traceability helps “to assist in scope and change management, risk management, time management, cost management, and communication management.” 7 For all of these reasons, many experts agree that requirements traceability is an essential practice for the business analyst. 

III. The Requirements Traceability Matrix

Requirements traceability often takes the physical form of a requirements traceability matrix (RTM), which is a manual spreadsheet or table that demonstrates the interconnections between requirements and business needs, other requirements, and/or deliverables. (The columns in a table or spreadsheet, for example, might list primary requirements, while the rows might list requirements that are somehow tied to them—thus creating a visual juxtaposition of related requirements.) A traceability matrix is the most common way to demonstrate requirements traceability. An example of a requirements traceability matrix that links requirements to test cases is viewable here: http://en.wikipedia.org/wiki/Traceability_matrix .

The matrix method is commonly considered to be appropriate only for smaller projects. According to BABOK, “It is typically used when there are relatively few requirements or when tracing is limited to high-level requirements (e.g. features or models).” 8 Author Karl Weigers agrees, noting that it’s “impossible to perform requirements tracing manually for any but very small applications. You can use a spreadsheet to maintain traceability data for up to a couple hundred requirements, but larger systems demand a more robust solution.” 9

Further, the integrity of a matrix is inextricably tied to the dedicated time commitment of often already-overworked analysts. Weigers further asserts that “tracing requirements is a manually intensive task that requires organizational commitment. Keeping the link information current as the system undergoes development and maintenance takes discipline. If the traceability information becomes obsolete, you’ll probably never recreate it.” 10 Weigers is not alone in his assessment that the sheer commitment of time and effort makes maintaining the integrity of matrices prohibitive in larger projects; many scholars have cited similar issues with manual traceability. In fact, in his master’s thesis, one scholar cites the maintenance of the requirements traceability matrix as the reason that requirements traceability is often not implemented any more effectively at some organizations: “The generation of RTMs is tedious and error-prone, though. Thus RTMs are often not generated or maintained. . . . Automating the process can save time and potentially improve the quality of the results.” 11 (More on traceability automation follows in the next section.) Authors Kannenberg and Saiedian state the problems with manual traceability even more strongly, noting that “manual traceability methods are not suitable for the needs of the software engineering industry. . . . It is easy for manually created traceability data to become out-of-sync with the current set of requirements, design, code, and test cases.” They further note, “Manual traceability methods are also prone to errors that are not easy to catch. Errors can arise from simple typographic mistakes . . . or from carelessness by the individual capturing the data. Because traceability artifacts for large projects are often hundreds or even thousands of pages in length, such errors are difficult to detect when depending on manual methods for error checking.” 12

The manually intensive aspect tightly links requirements matrices to version control; each time a requirements document is updated, the matrix must be thoroughly reviewed as well. Nonetheless, requirements matrices are quite useful for many organizations and analysts, depending on the size of the project and the level of granularity needed. 

IV. Requirements Traceability Automation

Automated requirements traceability is a function of many types of requirements management software, which purport to include automated systems that catch changes and redundancies that human users may miss. This type of automation can reduce the workload in larger projects, but as Ellen Gottesdiener points out in The Software Memory Jogger , the onus remains on the analyst to diligently monitor and maintain changes. “Tools do not manage requirements; people do. Be sure that requirements management procedures are being practiced before implementing an automated requirements management tool.” 13

For this reason, some authors, including Kannenberg and Saiedian, are critical of automated traceability tools, noting, “Regrettably, currently existing . . . traceability tools are not adequate for the needs of the software engineering industry. . . . Surprisingly, the tools that are available do not fully automate the entire traceability process; instead, they require users to manually update many aspects of the traceability data.” Nonetheless, for large projects, automated traceability is likely to provide a level of redundancy and efficiency that manual matrices cannot.

Some automated traceability applications offer rather simple techniques, such as displaying a table alongside a text document or diagram that shows which requirements link to which test cases, but not allowing these relationships to be viewed in any dynamic way. Other applications offer more sophisticated traceability techniques, such as allowing the analyst to create quick diagrams linking various requirements together (with arrows to show forward and backward traceability). The system then reads this diagram and automatically embeds links between related requirements within a rich text document. With one click, these relationships can also be viewed in a tree structure, displaying all of the requirements and their relations and dependencies within a project at once.

Whether an organization chooses to adopt a matrix or automated system, the efficacy of either method is greatly benefit from best practices. 

V. Requirements Traceability Best Practices

The following practices will enable more efficient traceability:

Unique identifiers must be adopted for requirements and business rules. “To permit traceability, each requirement must be uniquely and persistently labeled so that you can refer to it unambiguously through the project.” 14 This is a good practice for the analyst to employ, period, but particularly so for traceability, where each requirement or business rule must have an immutable, unique identifier throughout its life cycle.

A responsible party must take ownership of traceability. Whether using a manual method or an automated tool, a knowledgeable analyst must take ownership of the traceability process. “Gathering and managing requirements traceability data must be made the explicit responsibility of certain individuals or it won’t happen.” 15 Further, if someone who is not familiar with the system or the requirements attempts to make updates, errors will abound.

The analyst must practice consistency in updates. This will require a significant commitment on the part of the analyst. “Whenever such changes occur, it is necessary to update the traceability data to reflect these changes. This requires discipline on the part of those making the change to update the traceability data.” 16

When tracing all requirements is simply time-prohibitive, the analyst may be selective based on cost. If the prospect of tracing every requirement is overwhelming, an analyst may choose to only trace the expensive ones. “One method of dealing with the high cost of traceability is to practice value-based requirement tracing instead of full tracing. This can save a significant amount of effort by focusing traceability activities on the most important requirements.” 17 Naturally, a prerequisite to this practice is intelligently prioritizing all requirements according to the time and resources involved.

An organization must adopt consistent practices in requirements management, including traceability. If all stakeholders and team members buy into a traceability practice, take ownership of it, and become accustomed to it, it greatly increases a traceability method’s chances of success. As Kannenberg and Saiedian note, “Perhaps the best way to deal with the problem of different stakeholder viewpoints on traceability is to create an organizational policy on traceability to apply uniformly to all projects.” 18  

VI. Resources for Further Research

Explore the following online or printed resources for further information:

A Guide to the Business Analyst’s Body of Knowledge® (BABOK® Guide), Version 2.0, International Institute of Business Analysis, Toronto, Ontario, Canada, ©2005, 2006, 2008, 2009.

Weigers, Karl E. Software Requirements:Practical techniques for gathering and managing requirements throughout the product development cycle. Redmond, Washington: Microsoft Press, 2003.

Egyed, Alexander and Grunbacher, Paul. “Supporting Software Understanding with Automated Requirements Traceability.” International Journal of Software Engineering and Knowledge Engineering, Vol. 0, No. 0 (1994). Accessible at http://www.alexander-egyed.com/publications/Supporting_Software_Understanding_with_Automated_Requirements_Traceability.pdf

Kannenberg, Andrew and Dr. Hossein Saiedian. “Why Software Requirements Traceability Remains a Challenge.” CrossTalk: The Journal of Defense Software Engineering . July/August 2009.  

1 A Guide to the Business Analyst’s Body of Knowledge® (BABOK® Guide), Version 2.0, International Institute of Business Analysis, Toronto, Ontario, Canada, ©2005, 2006, 2008, 2009.

2 Weigers, Karl E. Software Requirements: Practical techniques for gathering and managing requirements throughout the product development cycle . Redmond, Washington: Microsoft Press, 2003.

3 A Guide to the Business Analyst’s Body of Knowledge® (BABOK® Guide), Version 2.0, International Institute of Business Analysis, Toronto, Ontario, Canada, ©2005, 2006, 2008, 2009.

4 Kannenberg, Andrew and Dr. Hossein Saiedian. “Why Software Requirements Traceability Remains a Challenge.” CrossTalk: The Journal of Defense Software Engineering . July/August 2009. 5 Ross, Ronald G. Business Rule Concepts: Getting to the Point of Knowledge . Third edition. Business Rule Solutions, 2009, 36.

6 Kannenberg, Andrew and Dr. Hossein Saiedian. “Why Software Requirements Traceability Remains a Challenge.” CrossTalk: The Journal of Defense Software Engineering . July/August 2009.

7 A Guide to the Business Analyst’s Body of Knowledge® (BABOK® Guide), Version 2.0, International Institute of Business Analysis, Toronto, Ontario, Canada, ©2005, 2006, 2008, 2009.

8 A Guide to the Business Analyst’s Body of Knowledge® (BABOK® Guide), Version 2.0, International Institute of Business Analysis, Toronto, Ontario, Canada, ©2005, 2006, 2008, 2009.

9 Weigers, Karl E. Software Requirements: Practical techniques for gathering and managing requirements throughout the product development cycle . Redmond, Washington: Microsoft Press, 2003.

10 Weigers, Karl E. Software Requirements: Practical techniques for gathering and managing requirements throughout the product development cycle . Redmond, Washington: Microsoft Press, 2003.

11 Cuddeback, David. “Automated Requirements Traceability: The Study of Human Analysts.” Master’s thesis for California Polytechnic Institute. http://digitalcommons.calpoly.edu/theses/317/. Accessed October 20, 2010.

12 Kannenberg, Andrew and Dr. Hossein Saiedian. “Why Software Requirements Traceability Remains a Challenge.” CrossTalk: The Journal of Defense Software Engineering . July/August 2009.

13 Gottesdiener, Ellen. The Software Requirements Memory Jogger . Salem, New Hampshire: GOAL/QPC, 2005. 293.

14 Weigers, Karl E. Software Requirements: Practical techniques for gathering and managing requirements throughout the product development cycle . Redmond, Washington: Microsoft Press, 2003.

15 Weigers, Karl E. Software Requirements: Practical techniques for gathering and managing requirements throughout the product development cycle . Redmond, Washington: Microsoft Press, 2003.

16 Kannenberg, Andrew and Dr. Hossein Saiedian. “Why Software Requirements Traceability Remains a Challenge.” CrossTalk: The Journal of Defense Software Engineering . July/August 2009.

17 Kannenberg, Andrew and Dr. Hossein Saiedian. “Why Software Requirements Traceability Remains a Challenge.” CrossTalk: The Journal of Defense Software Engineering . July/August 2009.

18 Kannenberg, Andrew and Dr. Hossein Saiedian. “Why Software Requirements Traceability Remains a Challenge.” CrossTalk: The Journal of Defense Software Engineering . July/August 2009.

Related Content

• Modern Requirements Receives Gold Award, Earning #1 Spot in 2023 Data Quadrant Best Requirements Management Solution Report by SoftwareReviews
• Modern Requirements Named a Champion in the 2023 SoftwareReviews Best Requirements Management Awards

Comments / Discussions

2 comments on article "what is requirements traceability".

Regarding the section about "Requirements Traceability Best Practices":

I'm missing one point: Be benfitial! With well managed traceabiltiy data, it is so easy to provide reports that help both managers and engineers in their daily work. Here's a rough illustration and an emperical prove for this point: https://www.itemis.com/en/yakindu/traceability/documentation/user-guide/benefits_of_requirements_traceability#benefits_of_requirements_traceability

Because we (manufacturers of traceability tools) are criticized in the article, I would like to comment on this: The most recent source in the article is from 2009... it is perhaps a bit outdated. We have actually done something since then ... and continue to work.

Here is a customer statement as proof:

“The elimination of manual effort, especially the manual maintenance of Excel matrices, is a great relief; YAKINDU Traceability helps us to work 70% more efficiently and clearly structured in our projects ... The use of this professional software tool was very well received by the OEMs (and strengthened the relationship of trust)”

Take a look yourself: http://itemis.com/traceability

Please login or register to post comments.

Free newsletter.

Requirements.com is trusted by leaders and experienced professionals across the world. Start your subscription today, for free.

Sustainable Product Performance through Requirements-Based Engineering

Requirements gathering: pants or not, 10 recently showcased requirements management and alm/plm software, product lifecycle management for semiconductors, requirements-related resources by dan tasker, where product managers can shine, how to categorize customer requirements.

A problem occurred while loading content.

Learn - Share - Connect

it's all about requirements

Join the Premier Community

for business analysts, data analysts and more...

Tech Solutions

one byte at a time!

Requirements traceability: Theory and practice

• Published: January 1997
• Volume 3 , pages 397–415, ( 1997 )

Cite this article

• Balasubramaniam Ramesh 1 ,
• Curtis Stubbs 2 ,
• Timothy Powers 3 &
• Michael Edwards 4  

405 Accesses

47 Citations

3 Altmetric

Explore all metrics

Current literature as well as standards that mandate requirements traceability do not provide a comprehensive model of what information should be captured and used as a part of a traceability scheme, leading to wide variation in the quality and usefulness of traceability practice across systems development efforts. In this paper, we present a framework for representing and developing a traceability scheme. The experiences of an organization using traceability as an important component of a quality software engineering process are discussed. Models describing the traceability practice in the organization, as well as issues and lessons learned, both from organizational and technical perspectives, from implementing a comprehensive traceability practice are presented.

This is a preview of subscription content, log in via an institution to check access.

Access this article

Price includes VAT (Russian Federation)

Instant access to the full article PDF.

Rent this article via DeepDyve

Institutional subscriptions

Similar content being viewed by others

A Survey on Usage Scenarios for Requirements Traceability in Practice

Traceability

Requirements traceability across organizational boundaries - a survey and taxonomy.

Alford, M. (1991), “Strengthening the Systems Engineering Process,” In Proceedings of NCOSE , San Jose, CA.

Baldo, J. (1990), “Reuse in Practice Workshop Summery,” IDA .

Brown, B.J. (1987), “Assurance of Software Quality,” In SEI Curriculum Model SEI-CM-7-1.1 ( Preliminary ), Carnegie Mellon University, Software Engineering Institute.

Conklin, J. and M. Begeman (1988), “gIBIS: A Hypertext Tool for Exploratory Policy Discussion,” ACM Transactions on Office Information Systems 6 , 303–331.

Article   Google Scholar  

Cordes, D.W. and D.L. Carver (1989), “Evaluation for User Requirements Documents,” Information and Software Technology 34 , 4.

Google Scholar  

Curtis, B., H. Kransner, and N. Iscoe (1988), “A Field Study of the Software Design Process for Large Systems,” Communications of the ACM 31 , 1268–1287.

DoD (1988), “Defense System Software Development,” DoD-STD-2167A .

Dorfman, M. and R.F. Flynn (1984), “Arts-An Automated Requirements Specification and Traceability System,” Journal of Systems and Software 4 .

Edwards, M. and S. Howell (1992), “A Methodology for Requirements Specification and Traceability for Large Real-Time Complex Systems,” Technical Report, Naval Surface Warfare Center.

Fiksel, J.D. (1994), “New Requirements Management Software Supports Concurrent Engineering,” In CimFlex Teknowledge Corporation , Washington, DC.

Gathman, T. and D. Halker (1990), Towards a Manageable Solution to the Iterative Development of Embedded Knowledge-Based Systems , Rockwell International Corporation.

Gotel, O. and A. Finkelstein (1994), “An analysis of the requirements traceability problem,” In Proceedings of the First International Conference on Requirements Engineering , Colorado Springs,CO.

Greenspan, S.J. and C.L. McGowan (1978), “Structuring Software Development for Reliability,” Microelectronics and Reliability 17 .

Hamilton, V.L. and M.L. Beeby (1991), “Issues of Traceability in Integrating Tools,” In Proceedings of the Colloquium by the Institution of Electrical Engineers Professional Group C1 ( Software Engineering ), London .

IEEE (1984), “IEEE Guide to Software Requirements Specifications,” ANSI/IEEE Standard 830-1984, New York, USA.

Jackson, J. (1991), “A Keyphrase Based Traceability Scheme,” In Proceedings of the Colloquium by the Institution of Electrical Engineers Professional Group C1 ( Software Engineering ), London .

Jarke, M., J. Bubenko, C. Rolland, A. Sutcliff, and Y. Vassiliou (1993), “Theories Underlying Requirements Engineering: An Overview of NATURE at Genesis,” In Proceedings of the First IEEE International Symposium on Requirements Engineering , pp. 19–31.

Jarke, M. and K. Pohl (1993), “Establishing Visions in Context: Toward a Model of Requirements Engineering,” In 14th International Conference on Information Systems .

Keuffel, W. (1990), “Extra Time Saves Extra Money,” Computer Language .

Lee, J. (1990), “SIBYL: A qualitative decision management system,” In Artificial Intelligence at MIT: Expanding Frontiers , P. Winston and S. Shellard, Eds., MIT Press, Cambridge, MA, pp. 106–133.

Maclean, A., R. Young, V. Bellotti, and T.P. Moran (1991), “Questions, Options, and Criteria: Elements of Design Space Analysis,” Human Computer Interaction 6 , 201–250.

Macmillan, J. and J.R. Vosburgh (1986), Software Quality Indicators , Scientific Systems.

Marconi Systems Technology (1991), RTM Requirements and Traceability Management ( Product Overview ), Arlington, VA.

McCausland, C.D. (1991), “A Case Study in Traceability,” In Proceedings of the Colloquium by the Institution of Electronic Engineers Professional Group C1 ( Software Engineering ), London .

Murine, G. (1986), “Secure Software's Impact on Reliability,” Computers and Security 5 .

Pinheiro, F.A.C. and J. Goguen (1996), “An Object-Oriented Tool for Tracing Requirements,” IEEE Software , 52–64.

Pohl, K. and S. Jacobs (1994), “PRO-ART: PROcess based Approach to Requirements Traceability,” NATURE Report Series 94-07, RWTH Aachen, Germany.

QSS Ltd (1995), Dynamic Object Oriented Requirements System, Reference Manual, version 2.1 , Oxford.

Ramesh, B. and V. Dhar (1992), “Supporting Systems Development by Capturing Deliberations During Requirements Engineering,” IEEE Transactions On Software Engineering 18 , 498–510.

Ramesh, B., T. Powers, C. Stubbs, and M. Edwards (1995), “Implementing Requirements Traceability,” In Proceedings of the IEEE International Symposium on Requirements Engineering, York, UK , pp. 89–95.

Roetzheim, W.H. (1991), Developing Software to Government Standards , Prentice Hall, Englewood Cliffs, NJ.

Schneidewind, N. (1982), “Software Maintenance,” Technical Report, Naval Postgraduate School.

Smithers, R., M.X. Tang, and N. Tomes (1991), “The Maintenance of Design History in AI-based Design,” In Proceedings of the Colloquium by the Institution of Electrical Engineers Professional Group C1 ( Software Engineers ), London .

Stehle, G. (1990), “Requirements Traceability for Real Time Systems,” In Proceedings of EuroCASE II, London .

TD Technologies (1996), SLATE User Manual , Dallas, TX.

West, M. (1991), “The Use of Quality Function Deployment in Software Development,” In Proceedings of the Colloquium by the Institution of Electrical Engineers Professional Group C1 ( Software Engineering ), London .

Wright, S. (1991), “Requirements Traceability — What? Why? and How?,” In Proceedings of the Colloquium by the Institution of Electrical Engineers Professional Group C1 ( Software Engineering ), London .

Download references

Author information

Authors and affiliations.

Department of Computer Information Systems, Georgia State University, Atlanta, GA, 30303, USA

Balasubramaniam Ramesh

Air Test and Evaluation Center Squadron One (VX‐1), Patuxent River, MD, 20670, USA

Curtis Stubbs

US Coast Guard Commander (TMM), 17th Coast Guard District, Juneau, AK, 99802, USA

Timothy Powers

Code B44, NSWCDD, 10901 New Hampshire Avenue, Silver Spring, MD, 20903, USA

Michael Edwards

You can also search for this author in PubMed   Google Scholar

Rights and permissions

Reprints and permissions

About this article

Ramesh, B., Stubbs, C., Powers, T. et al. Requirements traceability: Theory and practice. Annals of Software Engineering 3 , 397–415 (1997). https://doi.org/10.1023/A:1018969401055

Download citation

Issue Date : January 1997

DOI : https://doi.org/10.1023/A:1018969401055

Share this article

Anyone you share the following link with will be able to read this content:

Sorry, a shareable link is not currently available for this article.

Provided by the Springer Nature SharedIt content-sharing initiative

• Life Cycle Cost
• Requirement Engineer
• Traceability Link
• Traceability Model
• Find a journal
• Publish with us
• Track your research

• Conferences
• New Conferences
• search search
• You are not signed in

External Links

• Google Scholar
• TorkarGFSRK12
• References: 0
• Cited by: 0
• Bibliographies: 0
• [Upload PDF for personal use]

Researchr is a web site for finding, collecting, sharing, and reviewing scientific publications, for researchers by researchers.

Sign up for an account to create a profile with publication list, tag and review your related work, and share bibliographies with your co-authors.

Requirements Traceability: a Systematic Review and Industry Case Study

Richard Torkar , Tony Gorschek , Robert Feldt , Mikael Svahnberg , Uzair Akbar Raja , Kashif Kamran . Requirements Traceability: a Systematic Review and Industry Case Study . International Journal of Software Engineering and Knowledge Engineering , 22(3): 385-434 , 2012. [doi]

• Bibliographies

Abstract is missing.

• Web Service API

• Resource Scheduling
• Roles and Responsibilities Template
• Setting Sprint Goals
• Stakeholder Engagement Model
• Stakeholder Identification
• Stakeholder Mapping
• Stakeholder-theory
• Team Alignment Map
• Team Charter
• Templates for Managers
• What is Project Baseline
• Work Log Templates
• Workback Schedule
• Workload Management
• Assumption Mapping
• Work Breakdown Structures
• Agile Team Structure
• Avoding Scope Creep
• Cross-Functional Flowcharts
• Precision VS Accuracy
• Scrum-Spike
• User Story Guide
• Creating Project Charters
• Guide to Team Communication
• How to Prioritize Tasks
• Mastering RAID Logs
• Overcoming Analysis Paralysis
• Understanding RACI Model
• Achieving Big Hairy Audacious Goals
• Critical Success Factors
• Deadline Management
• Eisenhower Matrix Guide
• Guide to Multi Project Management
• Procure-to-Pay Best Practices
• Procurement Management Plan Template to Boost Project Success
• Project Execution and Change Management
• Project Management Success Factors
• Project Plan and Schedule Templates
• Resource Planning Templates for Smooth Project Execution
• Risk Management and Quality Management Plan Templates
• Risk Management in Software Engineering
• Setting and Achieving Stretch Goals
• Stage Gate Process
• Stakeholder Management Planning
• Understanding the S-Curve
• Visualizing Your To-Do List
• 30-60-90 Day Plan
• Work Plan Template
• Weekly Planner Template
• Task Analysis Examples
• Cross-Functional Flowcharts for Planning
• Inventory Management Tecniques
• Inventory Templates
• Six Sigma DMAIC Method
• Visual Process Improvement
• Value Stream Mapping
• Creating a Workflow
• Fibonacci Scale Template
• Supply Chain Diagram
• Kaizen Method
• Procurement Process Flow Chart
• Guide to State Diagrams
• UML Activity Diagrams
• Class Diagrams & their Relationships
• Visualize flowcharts for software
• Wire-Frame Benefits
• Applications of UML
• Selecting UML Diagrams
• Create Sequence Diagrams Online
• Activity Diagram Tool
• Archimate Tool
• Class Diagram Tool
• Graphic Organizers
• Social Work Assessment Tools
• Using KWL Charts to Boost Learning
• Editable Timeline Templates
• Kinship Diagram Guide
• Power of Visual Documentation
• Graphic Organizers for Teachers & Students
• Visual Documentation Techniques
• Visual Tool for Visual Documentation
• Concept Maps in Science
• Conducting a Thematic Analysis
• Visualizing a Dichotomous Key
• 5 W's Chart
• Circular Flow Diagram Maker
• Cladogram Maker
• Comic Strip Maker
• Course Design Template
• AI Buyer Persona
• AI Data Visualization
• AI Diagrams
• AI Project Management
• AI SWOT Analysis
• Best AI Templates
• Brainstorming AI
• Pros & Cons of AI
• AI for Business Strategy
• Using AI for Business Plan
• AI for HR Teams
• BPMN Symbols
• BPMN vs UML
• Business Process Analysis
• Business Process Modeling
• Capacity Planning Guide
• Case Management Process
• How to Avoid Bottlenecks in Processes
• Innovation Management Process
• Project vs Process
• Solve Customer Problems
• Spaghetti Diagram
• Startup Templates
• Streamline Purchase Order Process
• What is BPMN
• Approval Process
• Employee Exit Process
• Iterative Process
• Process Documentation
• Process Improvement Ideas
• Risk Assessment Process
• Tiger Teams
• Work Instruction Templates
• Workflow Vs. Process
• Process Mapping
• Business Process Reengineering
• Meddic Sales Process
• SIPOC Diagram
• What is Business Process Management
• Process Mapping Software
• Business Analysis Tool
• Business Capability Map
• Decision Making Tools and Techniques
• Operating Model Canvas
• FAB Analysis Guide
• Mobile App Planning
• Product Development Guide
• Product Roadmap
• Timeline Diagrams
• Visualize User Flow
• Sequence Diagrams
• Flowchart Maker
• Online Class Diagram Tool
• Organizational Chart Maker
• Mind Map Maker
• Retro Software
• Agile Project Charter
• Critical Path Software
• Brainstorming Guide
• Brainstorming Tools
• Concept Map Note Taking
• Types of Concept Maps
• Visual Tools for Brainstorming
• Brainstorming Content Ideas
• Brainstorming in Business
• Brainstorming Questions
• Brainstorming Rules
• Brainstorming Techniques
• Brainstorming Workshop
• Design Thinking and Brainstorming
• Divergent vs Convergent Thinking
• Group Brainstorming Strategies
• Group Creativity
• How to Make Virtual Brainstorming Fun and Effective
• Ideation Techniques
• Improving Brainstorming
• Marketing Brainstorming
• Plot Diagrams
• Rapid Brainstorming
• Reverse Brainstorming Challenges
• Reverse vs. Traditional Brainstorming
• What Comes After Brainstorming
• Flowchart Guide
• Spider Diagram Guide
• 5 Whys Template
• Assumption Grid Template
• Brainstorming Templates
• Brainwriting Template
• Innovation Techniques
• 50 Business Diagrams
• Business Model Canvas
• Change Control Process
• Change Management Process
• Decision Making Framework
• Decision Making Model
• Decision Making Techniques
• Digital Customer Journey
• Macro Environmental Analysis
• NOISE Analysis
• Product Portfolio
• Profit & Loss Templates
• Scenario Planning
• SPACE Analysis
• Stakeholder Communication Plan
• Strategic Vs Tactical Planning
• Strategy vs Plan
• What are Tree Diagrams
• Winning Brand Strategy
• Work Management Systems
• Balanced Scorecard
• Developing Action Plans
• Guide to setting OKRS
• How to Write a Memo
• Improve Productivity & Efficiency
• Mastering Task Analysis
• Mastering Task Batching
• Monthly Budget Templates
• Program Planning
• Top Down Vs. Bottom Up
• Weekly Schedule Templates
• Cash Cow Matrix
• Kaizen Principles
• Opportunity Mapping
• Strategic-Goals
• Strategy Mapping
• Strategy vs Tactics
• T Chart Guide
• Business Continuity Plan
• Developing Your MVP
• Experience Mapping Guide
• Incident Management
• Needs Assessment Process
• Product Development From Ideation to Launch
• Value-Proposition-Canvas
• Visualizing Competitive Landscape
• Communication Plan
• Graphic Organizer Creator
• Fault Tree Software
• Bowman's Strategy Clock Template
• Decision Matrix Template
• Communities of Practice
• Goal Setting for 2024
• Meeting Templates
• Meetings Participation
• Microsoft Teams Brainstorming
• Retrospective Guide
• Skip Level Meetings
• Visual Documentation Guide
• Visual Note Taking
• Weekly Meetings
• Affinity Diagrams
• Business Plan Presentation
• Post-Mortem Meetings
• Team Building Activities
• WBS Templates
• Online Whiteboard Tool
• Communications Plan Template
• Idea Board Online
• Meeting Minutes Template
• Genograms in Social Work Practice
• Conceptual Framework
• How to Conduct a Genogram Interview
• How to Make a Genogram
• Genogram Questions
• Genograms in Client Counseling
• Understanding Ecomaps
• Visual Research Data Analysis Methods
• House of Quality Template
• Customer Problem Statement Template
• Competitive Analysis Template
• Creating Operations Manual
• Knowledge Base
• Folder Structure Diagram
• Online Checklist Maker
• Lean Canvas Template
• Instructional Design Examples
• Genogram Maker
• Work From Home Guide
• Strategic Planning
• Employee Engagement Action Plan
• Huddle Board
• One-on-One Meeting Template
• Story Map Graphic Organizers
• Introduction to Your Workspace
• Managing Workspaces and Folders
• Adding Text
• Collaborative Content Management
• Creating and Editing Tables
• Adding Notes
• Introduction to Diagramming
• Using Shapes
• Using Freehand Tool
• Adding Images to the Canvas
• Accessing the Contextual Toolbar
• Using Connectors
• Working with Tables
• Working with Templates
• Working with Frames
• Using Notes
• Access Controls
• Exporting a Workspace
• Real-Time Collaboration
• Notifications
• Using Creately VIZ
• Meet Creately VIZ
• Unleashing the Power of Collaborative Brainstorming
• Uncovering the potential of Retros for all teams
• Collaborative Apps in Microsoft Teams
• Hiring a Great Fit for Your Team
• Project Management Made Easy
• Cross-Corporate Information Radiators
• Creately 4.0 - Product Walkthrough
• What's New

How to Create and Use a Requirements Traceability Matrix

In this blog post, we delve into what an RTM is, how to create one and how it helps run projects successfully.

What is a Traceability Matrix (TM)?

A requirements traceability matrix (RTM) is a powerful tool that helps you manage the scope, quality and risks of your project. It is a document that links the requirements of your project to the deliverables, test cases, design specifications and other artifacts that fulfill them. By creating and maintaining a RTM, you can ensure that your project meets the expectations of your stakeholders, avoid scope creep, identify gaps and inconsistencies, and track the progress and status of your project. A traceability matrix is a table that shows the relationship between two or more sets of items. It can be used for various purposes, such as:

Verifying that the requirements are met by the design, development and testing activities.

Mapping the dependencies and impacts of changes in one set of items on another.

Analyzing the coverage and completeness of the items.

Tracking the status and progress of the items.

A traceability matrix can have different levels of granularity and complexity depending on the scope and nature of the project. For example, a high-level traceability matrix can show the link between the business objectives and the project deliverables, while a low-level traceability matrix can show the link between the test cases and the code modules.

What is a Requirements Traceability Matrix (RTM)?

A requirements traceability matrix (RTM) is a specific type of traceability matrix that focuses on the requirements of a project. It shows how each requirement is derived from a source (such as a stakeholder need, a business goal, or a regulatory standard), how it is allocated to one or more components or subsystems, how it is verified by one or more test cases or methods, and how it is validated by one or more acceptance criteria or measures.

An RTM can have different formats and structures depending on the type and level of requirements. For example, a hierarchical RTM can show the parent-child relationship between different levels of requirements (such as functional, non-functional, system, subsystem, etc.), while a flat RTM can show the relationship between each requirement and its corresponding artifacts in a single table.

RTMs involve multiple roles and stakeholders in a project, such as:

Project manager: Responsible for initiating, planning, executing, monitoring and controlling the project.

Business analyst: Responsible for eliciting, analyzing, documenting and managing the requirements.

System engineer: Responsible for designing, developing, integrating and testing the system or product.

Quality assurance engineer: Responsible for verifying and validating the quality of the system or product.

Customer: Responsible for providing feedback and approval of the requirements and deliverables

Requirements Traceability Matrix Template

• Ready to use
• Fully customizable template
• Get Started in seconds

7 Steps to Create a Requirements Traceability Matrix

The process of creating a RTM can vary depending on the methodology and tools used in the project. However, here are some general steps that can be followed:

Step 1 - Define the Scope and Objectives of the Project

Identify the sources of requirements (such as stakeholders, documents, standards, etc.) and prioritize them according to their importance and urgency. You can use a project scope template for this purpose.

Step 2 - Elicit the Requirements

Gather project requirements from the sources using various techniques (such as interviews, surveys, workshops, observation, etc.). Document them in a clear, concise and consistent manner using a standard format (such as user stories , use cases, etc.).

Step 3 - Analyze the Requirements

Make sure all requirements pertaining to your project are complete, correct, feasible, testable and traceable. Resolve any conflicts or ambiguities among them. Categorize them into different types (such as functional, non-functional, system, subsystem, etc.) and levels (such as high-level, low-level, etc.).

Step 4 - Allocate Requirements

to one or more components or subsystems that will implement them. Define the interfaces and interactions among them. Document them in a design specification using diagrams (such as UML, SysML, etc.).

Step 5 - Verify and Validate Requirements

Verify that each requirement is met by one or more design elements using various methods (such as inspection, review, walkthrough, etc.). Document them in a verification plan using matrices (such as V&V matrix, V-model, etc.).

Validate requirements using acceptance criteria or measures (such as testing, demonstration, simulation, etc.). Document them in a validation plan using matrices (such as test plan, test case, test report, etc.).

Step 6 - Create a Requirement Traceability Matrix

The RTM should link each requirement to its source, allocation, verification and validation artifacts. Use a tool (such as Creately) that supports traceability and collaboration. Update the RTM as the project progresses and changes occur.

Step 7 - Review and Audit the RTM

Conduct periodic reviews and audits of the RTM to ensure that it is accurate, consistent and complete. Identify and address any gaps, inconsistencies or errors in the RTM. Use metrics (such as traceability coverage, traceability completeness, etc.) to measure and improve the quality of the RTM.

Why is a Requirements Traceability Matrix important?

A RTM is important because it helps you:

Manage the scope of the project by ensuring that all the requirements are captured, allocated, verified and validated.

Ensure the quality of the project by enabling you to track and monitor the status and progress of each requirement and its corresponding artifacts.

Reduce the risks of the project by allowing you to identify and analyze the dependencies and impacts of changes in one set of items on another.

Improve the communication and collaboration among the project team and stakeholders by providing a common and consistent view of the requirements and their traceability.

How an RTM is Connected to the Project Life Cycle

An RTM helps you define the scope and objectives of the project, prioritize the requirements, and allocate them to the components or subsystems during the planning phase of the project.

It supports the execution phase of the project by helping you design, develop, integrate and test the system or product that meets the requirements.

You can use an RTM to verify and validate that each requirement is fulfilled by the system or product, track and report the status and progress of each requirement and its corresponding artifacts, and manage any changes or issues that arise in the project.

Ultimately, an RTM helps deliver and deploy a product that satisfies the customer, document and archive the RTM and other artifacts, and conduct a lessons learned session to identify and share best practices and improvement opportunities.

Challenges in Using a Requirements Traceability Matrix

It can be time-consuming and tedious to create and maintain a RTM, especially for large and complex projects with many requirements and artifacts.

Difficult to ensure that all the requirements are traced to their sources, allocations, verifications and validations, especially when there are changes or updates in any of them.

It can be a challenge to keep track of all the relationships among different sets of items in a RTM, especially when there are multiple levels of granularity and complexity in them.

Tracking and tracing different types of items which are in different formats, structures and standards.

How to Create a Requirements Traceability Matrix with Creately

Create a RTM using various templates (such as hierarchical RTM, flat RTM, etc.) or from scratch. You can customize the format, structure and style of your RTM according to your preferences and standards.

Identify the sources of requirements, such as stakeholders, documents, or systems, and list them in the first column of the matrix.

Identify the types of requirements, such as functional, non-functional, or business, and list them in the first row of the matrix.

Assign a unique identifier and a description, and enter them in the corresponding cells for each requirement.

For each requirement, identify the deliverables, test cases, and other artifacts that satisfy it, and enter their identifiers or names in the corresponding cells of the matrix. You can use the notes panel to add any additional information and attach docs or links.

Use different colors or symbols to indicate the status or priority of each requirement and its related artifacts. You can also use display rules to differentiate between various types of requirements.

Wrapping Up

A requirements traceability matrix (RTM) is a valuable tool for managing project requirements and ensuring that they are met throughout the project lifecycle. It helps to establish the link between the business needs, the project scope, the deliverables, the test cases, and the final product. By creating and using an RTM, project managers and stakeholders can avoid scope creep, reduce rework, improve quality, and enhance customer satisfaction.

An RTM is not a static document, but a dynamic and evolving one that reflects the changes and progress of the project. It is a powerful way to ensure that the project meets the expectations and needs of the customers and stakeholders. By following the steps above, project managers and teams can create and use an effective RTM that will help them deliver successful projects.

Also read other blog posts on project management:

• Key Project Documents Every Project Manager Needs
• Using Gantt Charts and Flowcharts in Project Planning
• 10 Biggest Project Management Challenges and How to Avoid Them
• How to Better Manage Your Projects with Kanban Boards

Join over thousands of organizations that use Creately to brainstorm, plan, analyze, and execute their projects successfully.

More Related Articles

Hansani has a background in journalism and marketing communications. She loves reading and writing about tech innovations. She enjoys writing poetry, travelling and photography.

• Corpus ID: 18792568

Documenting Requirements Traceability Information : A Case Study Master ' s thesis

• Virve Leino , R. Sulonen
• Published 2001
• Computer Science

Figures and Tables from this paper

10 Citations

Documenting requirements traceability information for small projects.

• Highly Influenced
• 10 Excerpts

A document based traceability model for test management

A design-rule-based constructive approach to building traceable software, a survey report on requirement traceability of service oriented architecture, a matrix-less model for tracing software requirements to source code, a new traceable software requirements specification based on ieee 830, change impact analysis - integrating traceability to it organizations using trace requirement artifacts log model (tralm), traceability patterns: an approach to requirement-component traceability in agile software development, visual sdlc: improving requirements engineering for object-oriented systems, tracing user interface design pre-requirement to generate interface design specification, 45 references, factors influencing requirements traceability practice, implementing requirements traceability: a case study, an analysis of the requirements traceability problem, requirements engineering: processes and techniques, adapting traceability environments to project-specific needs.

• Highly Influential

HOW TO DO AND USE REQUIREMENTS TRACEABILITY EFFECTIVELY

Improving reviews by extended traceability, towards requirements traceability models, and productivity, pro-art: enabling requirements pre-traceability, related papers.

Showing 1 through 3 of 0 Related Papers

IEEE Account

• Change Username/Password
• Update Address

Purchase Details

• Payment Options
• Order History
• View Purchased Documents

Profile Information

• Communications Preferences
• Profession and Education
• Technical Interests
• US & Canada: +1 800 678 4333
• Worldwide: +1 732 981 0060
• Contact & Support
• About IEEE Xplore
• Accessibility
• Terms of Use
• Nondiscrimination Policy
• Privacy & Opting Out of Cookies

A not-for-profit organization, IEEE is the world's largest technical professional organization dedicated to advancing technology for the benefit of humanity. © Copyright 2024 IEEE - All rights reserved. Use of this web site signifies your agreement to the terms and conditions.

Academia.edu no longer supports Internet Explorer.

To browse Academia.edu and the wider internet faster and more securely, please take a few seconds to  upgrade your browser .

Enter the email address you signed up with and we'll email you a reset link.

• We're Hiring!
• Help Center

Implementing a Document-based Requirements Traceability: A Case Study

2005, … International Conference on …

Related Papers

International Conference on Information Technology in Asia

Suhaimi Ibrahim

It is inevitable that a software undergoes some change in its lifetime. With some change requests comes a need to estimate the scope (e.g. size and complexity) of the proposed changes and plan for their implementation. Software traceability and its subsequent impact analysis help relate the consequences or ripple-effects of a proposed change across different levels of software models. In

Prof Norbik , Suhaimi Ibrahim

The International Arab Journal of Information Technology

Suhaimi Ibrahim , Malcolm Munro , Norbik Idris

Prof Norbik

Proceedings of the International Conference on …

- Software traceability and its subsequent impact analysis help relate the consequences or ripple-effects of a proposed change across different levels of software system. Our software traceability approach can be observed at its ability to integrate the high level with the low ...

International Journal of Software Engineering and Knowledge Engineering

Abdullah Abdullah

Software evolution is inevitable. When a system evolves, there are certain relationships among software artifacts that must be maintained. Requirement traceability is one of the important factors in facilitating software evolution since it maintains the artifacts relationship before and after a change is performed. Requirement traceability can be expensive activities. Many researchers have addressed the problem of requirement traceability, especially to support software evolution activities. Yet, the evaluation results of these approaches show that most of them typically provide only limited support to software evolution. Based on the problems of requirement traceability, we have identified three directions that are important for traceability to support software evolution, i.e. process automation, procedure simplicity, and best results achievement. Those three directions are addressed in our multifaceted approach of requirement traceability. This approach utilizes three facets to ge...

International Journal of Digital Information and Wireless Communications

Proceedings of the 20th …

Stefan Biffl

Loading Preview

Sorry, preview is currently unavailable. You can download the paper by clicking the button above.

RELATED PAPERS

International Conference on Software Engineering Advances (ICSEA 2007)

Proceedings of the 3rd …

… Requirements Engineering: A …

Jane Cleland-Huang

Tihamér Levendovszky

Kiran Fernandes , Richard Paige

Christian M. Adriano , Xinlu Tong

Proceedings of the 6th ECMFA Traceability Workshop on - ECMFA-TW '10

Andrzej Wasowski

Empirical Software Engineering

13th IEEE International Conference on Requirements Engineering (RE'05)

Proceedings of the 10th European software …

Markus Borg , Per Runeson

A. Etien , Cédric Dumoulin

IEEE Software

Yi Zhang , Jane Cleland-Huang

ECMDA Traceability …

João Paulo Araújo

ACM Transactions on Software Engineering and Methodology

Fausto Fasano

Journal of Software: Evolution and Process

Annibale Panichella

Bonita Sharif

Markus Borg

… Advances, 2008. ICSEA'08. The Third …

Salma Imtiaz

Pedro Alarcon

Proceedings - Working Conference on Reverse Engineering, WCRE

Romain Robbes , A. Bacchelli

Bedir Tekinerdogan

2013 17th European Conference on Software Maintenance and Reengineering

Denys Poshyvanyk , Annibale Panichella

IFIP – The International Federation for Information Processing

Jens Dibbern

Relating Software Requirements and Architectures

Hans van Vliet

Mikael Svahnberg , Tony Gorschek , Richard Torkar , Uzair Raja , Kashif Kamran

Markus Aleksy

Dawn Lawrie

Research abstract submitted to the ASE

2009 ICSE Workshop on Traceability in Emerging Forms of Software Engineering

Michael L Collard

Ana Marcia Debiasi Duarte

Gerardo Canfora

Dave Binkley

2008 23rd IEEE/ACM International Conference on Automated Software Engineering

Carl K Chang

David C Brown

Software and System Modeling

RELATED TOPICS

•   We're Hiring!
•   Help Center
• Find new research papers in:
• Health Sciences
• Earth Sciences
• Cognitive Science
• Mathematics
• Computer Science
• Academia ©2024