Designing requirements engineering research

Engineering sciences study different different topics than natural sciences, and utility is an essential factor in choosing engineering research problems. But despite these differences, research methods for the engineering sciences are no different than research methods for any other kind of science. At most there is a difference in emphasis. In the case of requirements engineering research - and more generally software engineering research - there is a confusion about the relative roles of research and about design and the methods appropriate for each of these activities. This paper analyzes these roles and provides a classification of research methods that can be used in any science—engineering or otherwise

Advanced Cloud Privacy Threat Modeling

Privacy-preservation for sensitive data has become a challenging issue in cloud computing. Threat modeling as a part of requirements engineering in secure software development provides a structured approach for identifying attacks and proposing countermeasures against the exploitation of vulnerabilities in a system . This paper describes an extension of Cloud Privacy Threat Modeling (CPTM) methodology for privacy threat modeling in relation to processing sensitive data in cloud computing environments. It describes the modeling methodology that involved applying Method Engineering to specify characteristics of a cloud privacy threat modeling methodology, different steps in the proposed methodology and corresponding products. We believe that the extended methodology facilitates the application of a privacy-preserving cloud software development approach from requirements engineering to design

Design science, engineering science and requirements engineering

For several decades there has been a debate in the computing sciences about the relative roles of design and empirical research, and about the contribution of design and research methodology to the relevance of research results. In this minitutorial we review this debate and compare it with evidence about the relation between design and research in the history of science and technology. Our review shows that research and design are separate but concurrent activities, and that relevance of research results depends on problem setting rather than on rigorous methods. We argue that rigorous scientific methods separate design from research, and we give simple model for how to do this in a problem-driven way

Dynamic Analysis can be Improved with Automatic Test Suite Refactoring

Context: Developers design test suites to automatically verify that software meets its expected behaviors. Many dynamic analysis techniques are performed on the exploitation of execution traces from test cases. However, in practice, there is only one trace that results from the execution of one manually-written test case. Objective: In this paper, we propose a new technique of test suite refactoring, called B-Refactoring. The idea behind B-Refactoring is to split a test case into small test fragments, which cover a simpler part of the control flow to provide better support for dynamic analysis. Method: For a given dynamic analysis technique, our test suite refactoring approach monitors the execution of test cases and identifies small test cases without loss of the test ability. We apply B-Refactoring to assist two existing analysis tasks: automatic repair of if-statements bugs and automatic analysis of exception contracts. Results: Experimental results show that test suite refactoring can effectively simplify the execution traces of the test suite. Three real-world bugs that could previously not be fixed with the original test suite are fixed after applying B-Refactoring; meanwhile, exception contracts are better verified via applying B-Refactoring to original test suites. Conclusions: We conclude that applying B-Refactoring can effectively improve the purity of test cases. Existing dynamic analysis tasks can be enhanced by test suite refactoring