Software Evolution: a Requirements Engineering Approach by Neil Alexander Ernst A thesis submitted in conformity with the requirements for the degree of Doctor of Philosophy Graduate Department of Computer Science University of Toronto Copyright c 2012 by Neil Alexander Ernst Abstract Software Evolution: a Requirements Engineering Approach Neil Alexander Ernst Doctor of Philosophy Graduate Department of Computer Science University of Toronto 2012 This thesis examines the issue of software evolution from a Requirements Engineering perspective. This perspective is founded on the premise that software evolution is best managed with reference to the requirements of a given software system. In particular, I follow the Requirements Problem approach to software development: the problem of developing software can be characterized as finding a specification that satisfies user requirements, subject to domain constraints. To enable this, I propose a shift from treating requirements as artifacts to treating requirements as design knowledge, embedded in knowledge bases. Most requirements today, when they exist in tangible form at all, are static objects. Such artifacts are quickly out of date and difficult to update. Instead, I propose that requirements be maintained in a knowledge base which supports knowledge-level operations for asserting new knowledge and updating existing knowledge. Consistency checks and entailment of new specifications is done automatically by answering simple queries. Maintaining a requirements knowledge base in parallel with running code means that changes precipitated by evolution are always addressed relative to the ultimate purpose of the system. This thesis begins with empirical studies which establish the nature of the requirements evolution problem. I use an extended case study of payment cards to motivate the following discussion. I begin at an abstract level, by introducing a requirements engineering knowledge base (REKB) using a functional specification. Since it is functional, the specifics of the implementation are left open. I then describe one implementation, using a reason-maintenance system, and show how this implementation can a) solve static requirements problems; b) help stakeholders bring requirements and implementation following a change in the requirements problem; c) propose paraconsistent reasoning to support inconsistency tolerance in the REKB. The end result of my work on the REKB is a tool and approach which can guide software developers and software maintainers in design and decision-making in the context of software evolution. ii Ignoramus et ignorabimus ... \we do not know and will not know" We must not believe those, who today, with philosophical bearing and deliberative tone, prophesy the fall of culture and accept the ignorabimus. For us there is no ignorabimus, and in my opinion none whatever in natural science. In opposition to the foolish ignorabimus our slogan shall be: Wir m¨ussenwissen { wir werden wissen! (`We must know { we will know!') { David Hilbert iii Acknowledgements Many people have helped shaped this, the final result of my student years. This thesis may have my name on it but the majority of the work was done in the best traditions of scientific collaboration. I would like to thank my committee members Steve Easterbrook and Kelly Lyons, as well as erstwhile member Greg Jamieson, for excellent advice on scope and direction. My external examiner, Vincenzo Gervasi, made substantial improvement possible through his insightful comments. In particular I wish to thank Jorge Aranda, Yiqiao Wang, Alexei Lapouchnian, Jennifer Horkoff and Rick Salay for always answering my questions and provoking yet more. The consistent high standards of our lab are an inspiration and a challenge. Thanks to Abram Hindle for being a truly collaborative research partner. I was fortunate enough to spend three months visiting the University of Trento, and made great friends there, including Fabiano Dalpiaz, Amit Chopra, Raian Ali, Vitor Souza, Michele Vescovi and Alberto Griggio. I am indebted to them for welcoming me to the group, and making me feel at home. To Ivan Jureta, your commitment to the issue of the requirements problem has made my own work much stronger. For Alex Borgida, my co-supervisor, many thanks for your patience and interest. In explaining things to you I inevitably clarified my own thinking dramatically. Thank you for being understanding of a geographer turned part-time language designer. And naturally, many thanks to my co-supervisor and mentor, John Mylopoulos. Oftentimes I would pay too little heed to what you advised; it inevitably turned out to be the right approach. Any use of the personal pronoun herein should be seen as convention, because both Alex and John have greatly contributed to, helped with, and influenced all my work. My family have always been there for me, unquestioningly supportive. Sometimes it is nice not to have to explain things. To Kambria, \Love is not a big enough word. It's not a big enough word for how I feel about my wife." For Elliott, who wasn't yet there in person but was great motivation to wrap things up, and for Kieran, for showing me that thesis writing can be fun if you occasionally pause to enjoy the simple things, like throwing a ball. This thesis is dedicated to you guys. iv Contents 1 Introduction 1 1.1 Software Must Accommodate Unanticipated Change . .1 1.2 Software Development Solves Requirements Problems . .5 1.3 Research Questions and Contributions . .6 1.4 Publications . 10 2 Preliminaries 12 2.1 Goal Modeling in Requirements Engineering . 12 2.1.1 Turning Stakeholder Desires Into Goals . 13 2.1.2 The Requirements Problem in Techne ......................... 14 2.2 Formal Background . 19 2.2.1 Syntax of Propositional Logic . 19 2.2.2 Rules of Inference . 20 2.2.3 Semantics of Propositional Logic . 20 2.2.4 Abduction . 21 2.2.5 Propositional Satisfiability . 22 2.2.6 Belief Revision . 22 2.3 Knowledge Level Models . 23 3 Related Work 25 3.1 Historical Developments . 25 3.2 Evolution and Industrial Tools . 29 3.3 Implementation-level Approaches . 31 3.4 Studies of Evolving Requirements in Industrial Settings . 31 3.5 Current Approaches . 33 v 4 Empirical Studies of Changing Requirements 35 4.1 Mining Quality Requirements From Artifacts . 36 4.1.1 Controlled Vocabulary Mining of GNOME Projects . 37 4.1.2 Applying Latent Dirichlet Allocation to Extract Requirements Topics . 52 4.1.3 Related Work in Mining Requirements . 63 4.2 Tracing Software Evolution History with Design Goals . 65 4.2.1 Motivating the Study of Software History . 66 4.2.2 Related Work in Software Histories . 67 4.2.3 A history of distributed computing protocols . 67 4.2.4 Interpretation . 75 4.2.5 Conclusions From Software Histories . 77 4.3 Lessons . 78 5 Case Study: Payment Cards 82 5.1 Overview . 82 5.2 Standards for Securing Payment Card Systems . 83 5.3 The Payment Card Model . 85 5.4 Change Scenarios . 87 5.4.1 Alternative Compliance Choices . 88 5.5 PCI-DSS and Evolution . 89 5.5.1 Expansion . 89 5.5.2 Contraction . 89 5.5.3 Revision . 90 5.5.4 Conflicts in the Standard . 91 5.6 Conclusions . 91 6 A Functional View of Requirements Problems 93 6.1 Definitions . 95 6.2 TELL Operations . 97 6.3 ASK Operations . 98 6.3.1 Goal Achievement . 99 6.3.2 Finding Candidate Solutions . 100 6.3.3 Deciding Among Candidates . 101 6.4 Operations for Requirements Evolution Problems . 102 vi 6.4.1 Finding Minimal Change Tasks . 102 6.5 Complexity . 103 6.6 Related Work in Requirements Engineering KBs . 104 6.6.1 KAOS . 104 6.6.2 Other RE Approaches . 105 7 Solving Static Requirements Problems 107 7.1 Finding Solutions . 108 7.1.1 The Assumption-Based Truth Maintenance System ATMS)............. 108 7.1.2 ARE-GOALS-ACHIEVED-FROM . 110 7.1.3 MINIMAL-GOAL-ACHIEVEMENT . 111 7.1.4 GET-CANDIDATE-SOLUTIONS . 113 7.1.5 The Problem Solver . 114 7.2 Deciding on a Solution . 115 7.2.1 First Approach: pQGM . 117 7.2.2 Selecting Solutions . 124 7.3 Tool support . 125 7.3.1 DSLs . 125 7.3.2 Graphical Editor . 126 7.4 Implementation Feasibility . 126 7.4.1 Optimizations for pQGM . 130 7.4.2 Evaluating the ATMS Approach . 134 7.5 Other approaches . 138 8 Solving Evolving Requirements Problems 141 8.1 Methodological Guidance for Solving Unanticipated Changes . 142 8.2 Revising requirements . 144 8.2.1 Requirements Revision . 145 8.3 Finding Minimal New Changes . ..