Understanding where requirements are implemented

Trace links between requirements and code reveal where requirements are implemented. Such trace links are essential for code understanding and change management. The lack thereof is often cited as a key reason for software engineering failure. Unfortunately, the creation and maintenance of requirements-to-code traces remains a largely manual and error prone task due to the informal nature of requirements. This paper demonstrates that reasoning about requirements-to-code traces can be done, in part, by considering the calling relationships within the source code (call graph). We observed that requirements-to-code traces form regions along calling dependencies. Better knowledge about these regions has several direct benefits. For example, erroneous traces become detectable if a method inside a region does not trace to a requirement. Or, a missing trace (incompleteness) can be identified. Knowledge of requirement regions can also be used to help guide developers in establishing requirements-to-code traces in a more efficient manner. This paper discusses requirement regions and sketches their benefits.

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

[2]  Mikael Lindvall,et al.  Practical implications of traceability , 1996 .

[3]  Olly Gotel,et al.  Extended requirements traceability: results of an industrial case study , 1997, Proceedings of ISRE '97: 3rd IEEE International Symposium on Requirements Engineering.

[4]  Martin P. Robillard,et al.  Concern graphs: finding and describing concerns using structural program dependencies , 2002, Proceedings of the 24th International Conference on Software Engineering. ICSE 2002.

[5]  Giuliano Antoniol,et al.  Recovering Traceability Links between Code and Documentation , 2002, IEEE Trans. Software Eng..

[6]  Carl K. Chang,et al.  Event-Based Traceability for Managing Evolutionary Change , 2003, IEEE Trans. Software Eng..

[7]  Alexander Egyed,et al.  A Scenario-Driven Approach to Trace Dependency Analysis , 2003, IEEE Trans. Software Eng..

[8]  Paolo Tonella,et al.  Using a Concept Lattice of Decomposition Slices for Program Understanding and Impact Analysis , 2003, IEEE Trans. Software Eng..

[9]  Jane Huffman Hayes,et al.  Helping analysts trace requirements: an objective look , 2004, Proceedings. 12th IEEE International Requirements Engineering Conference, 2004..

[10]  Andrea Zisman,et al.  Rule-based generation of requirements traceability relations , 2004, J. Syst. Softw..

[11]  Rainer Koschke,et al.  On dynamic feature location , 2005, ASE.

[12]  Betty H. C. Cheng,et al.  Retrieval by Construction: a Traceability Technique to Support Verification and Validation of Uml Formalizations , 2005, Int. J. Softw. Eng. Knowl. Eng..

[13]  Julia Rubin,et al.  Model traceability , 2006, IBM Syst. J..

[14]  Richard N. Taylor,et al.  An end-to-end industrial software traceability tool , 2007, ESEC-FSE '07.

[15]  Stephen Clark,et al.  Best Practices for Automated Traceability , 2007, Computer.

[16]  Arie van Deursen,et al.  Identifying Crosscutting Concerns Using Fan-In Analysis , 2006, TSEM.

[17]  Alfred V. Aho,et al.  CERBERUS: Tracing Requirements to Source Code Using Information Retrieval, Dynamic Analysis, and Program Analysis , 2008, 2008 16th IEEE International Conference on Program Comprehension.

[18]  Lionel C. Briand,et al.  Automated traceability analysis for UML model refinements , 2009, Inf. Softw. Technol..

[19]  Collin McMillan,et al.  Combining textual and structural analysis of software artifacts for traceability link recovery , 2009, 2009 ICSE Workshop on Traceability in Emerging Forms of Software Engineering.