Pattern-Based Refinement of Unbounded Requirements

Pattern-based refinement of unbounded requirements Michal Korenko 1st Supervisor: Fabiano Dalpiaz 2nd Supervisor: Jan Martijn van der Werf Department of Information and Computing Sciences University of Utrecht September 2015 2 There are several requirement types that have been recognized by require- mentsabstract engineering. We propose a new type of requirements - unbounded requirements. Unbounded requirements are a special type of functional requirements, which can only be partially satisfied. We have provided vast evidence of their existence; We illustrated the notion on examples retrieved from various applications such as Spotify, PopcornTime, Nimble, Salesforce, OneDrive for Business, Firefox, Skype and PicCollage. This notion has been further evaluated by interviewing field experts and their existence has been confirmed. While there is a small amount of awareness about unbounded requirements in practice, these interviews uncovered that unbounded requirements are hard to implement and address as they are considered to be standard requirements. By addressing unbounded requirements we can uncover further criteria for their satisfaction that might otherwise have been neglected. Unbounded requirements are hard to be satisfied fully. Therefore, we present a model-driven method for unbounded requirements. The modeling technique introduces a source construct that allows to feed a software system with necessary expertise or data. The modeling approach allows for multisourcing - composing various sources together. Opinions on the applicability of this model-driven method have been gathered from poten- tial future users. The modeling technique was found to be useful, however, can remain unadopted amid the coexistence with other more known tech- niques. We demonstrate the applicability and capabilities of the modeling technique by modeling context and solution in the patterns for refinement of unbounded requirements. Refinement patterns facilitate the refinement process of unbounded requirements and reuse the knowledge in regards to the refinement the complex requirements like the unbounded. We defined atomic patterns - al- ternative and complementary source composition, and crowdsourcer. The three patterns are basic building blocks when modeling source composi- tions. We also defined aspect patterns that address a unique functionality of an unbounded requirement. We applied these aspect patterns on a testing sample of 36 requirements to test their applicability and effectiveness. We were able to model 80% of cases by using the patterns. 3 This work would not have been possible without the advice and support ofacknowledgement many people. First and foremost, I would like to express my gratitude to my supervisor dr. Fabiano Dalpiaz for his guidance, endless patience, invaluable inputs and interest in my work. I would also like to thank to dr. Jan Martijn van der Werf for his feedback and supervision. Furthermore, I would like to thank to dr. Marsha Chechik and dr. Rick Salay from the University of Toronto without who the notion of unbounded requirement probably would not exist. Their ideas, valuable inputs and cooperation made this research possible. I would also like to thank to all interview participants without which this research would have not been possible. They provided very insightful and constructive comments on the main deliverables of this project. Finally, I thank my family and friends who supported me in all imagin- able ways during this project. A special thank you and my deepest admi- ration goes to my mother, Anna, for her continuous support, advice and encouragement. CONTENTS 7 1.1 Motivation . 7 11 Introduction.2 Research Approach . 11 1.3 Thesis Organization . 17 19 2.1 Definitions . 19 22 Unbounded.2 Finding Requirements Unbounded Requirements in Practice . 20 2.3 Observations on Unbounded Requirements . 24 2.4 Study of Important Quality Attributes . 25 29 3.1 Background . 29 33 Modelling.2 Principles Language . 31 3.3 Modelling Concepts . 32 3.4 Labelling Conventions . 34 3.5 Runtime Semantics . 36 45 4.1 Pattern Forms . 45 44 Patterns.2 Discerning Patterns . 47 4.3 Atomic Patterns . 50 4.4 Content Related Patterns . 55 4.5 Content & Suitability Related Patterns . 60 4.6 Suitability Related Patterns . 65 4.7 Summary of Patterns . 68 70 5.1 Pattern Validation . 70 55 Evaluation.2 Expert Interviews . 73 83 6.1 Conclusion . 83 66 Discussion.2 Limitations . 84 6.3 Future Work . 85 94 Appendices 95 A Sample of Unbounded Requirements 101 B Assignment of Attributes 105 C Social Network Analysis 107 D Testing Sample 110 E Testing Patterns 4 FigureLISTOFFIGURES1.1 The relationship between unboundedness and unclarity 9 Figure 1.2 Design Science Research Methodology [1]. 13 Figure 1.3 Pattern discerning loop . 14 Figure 1.4 Variables and values for the evaluation of DSR arti- facts [2]............................ 16 Figure 3.1 Software development methodologies compared [3]. 31 Figure 3.2 The relationship between the refinement and the source composition . 32 Figure 3.3 The graphical notation of basic modelling features . 32 Figure 3.4 The graphical notations of the relationships . 34 Figure 3.5 The graphical notations of labelling prefixes . 34 Figure 3.6 Source types labelling icons . 36 Figure 3.7 The graphical notations of decomposition primitives 38 Figure 3.8 The runtime semantics of the AND decomposition . 39 Figure 3.9 The runtime semantics of the XOR decomposition . 40 Figure 3.10 The runtime semantics of the USER decomposition . 41 Figure 3.11 The graphical notations of composition operators . 42 Figure 3.12 The runtime semantics of the Sequential operator . 42 Figure 3.13 The runtime semantics of the Concurrent operator . 43 Figure 3.14 The runtime semantics of the Fallback operator . 44 Figure 4.1 Clusters of requirements and attributes . 49 Figure 4.2 Requirements clusters identified by network analysis 50 Figure 5.1 Cost-oriented approach to unbounded requirements 76 5 TableLISTOFTABLES1.1 Mapping of the research activities on subquestions . 16 Table 2.1 Terms explained . 21 Table 2.2 List of applications . 22 Table 2.3 Unbounded requirements in numbers for individual applications . 22 Table 2.4 Examples of unbounded requirements . 23 Table 2.5 Overview of quality attributes for unbounded requirements . 28 Table 3.1 Mapping of the events onto the operators . 37 Table 4.1 Cluster descriptions . 49 Table 4.2 Mapping of atomic patterns on attributes . 68 Table 4.3 Mapping of aspect patterns on attributes . 69 Table 4.4 Mapping of patterns on the unboundedness types . 69 Table 5.1 Pattern application data . 73 Table 5.2 Percentages on pattern application . 73 Table 5.3 Overall applicability of the patterns for individual applications . 73 Table 5.4 Expert overview . 75 Table A.1 List of unbounded requirements 1/4 .......... 95 Table A.2 List of unbounded requirements 2/4 .......... 96 Table A.3 List of unbounded requirements 3/4 .......... 97 Table A.4 List of unbounded requirements 4/4 .......... 98 Table A.5 Details about unbounded requirements 1/2 ...... 99 Table A.6 Details about unbounded requirements 2/2 ...... 100 Table B.1 Unbounded requirements and attributes 1/4 ..... 101 Table B.2 Unbounded requirements and attributes 2/4 ..... 102 Table B.3 Unbounded requirements and attributes 3/4 ..... 103 Table B.4 Unbounded requirements and attributes 4/4 ..... 104 Table C.1 Attributes and their correlations . 106 Table C.2 Assignement of requirements to attributes . 106 Table D.1 Testing requirements 1/2 ................. 107 Table D.2 Testing requirements 2/2 ................. 108 Table D.3 Details about testing requirements . 109 6 1 Nowadays, peopleINTRODUCTION require difficult tasks from software and hardware. Some of these tasks can be so complex that the underlying software or hardware is incapable to perform the essential functions. For example, independently thinking robots, virtual intelligent agent, self-stocking fridge, self-driving cars and many others. Today, the complexity of systems is ubiquitous in the social and economic environment. Complexity of systems is present in financial, public and private sector [4]. [4] ascribe this complexity to emo- tions, infrastructure and the environment which drive society. Complexity of the software system can be into some extent determined by its functionality [5]. Several studies have shown that complexity is causing software failures [6, 7]. These two studies implied that software is one of the most complex and error-prone products due to its intellectual nature. It has been argued the complexity causes software faults. According to Hobbs faults are one of the cause of failure [8]. A software failure is described as an inability to perform required functions [9]. This inability can be ascribed to poorly defined requirements and their specifications, as a result of communication gap between developers and stakeholders, which led to their humble or par- tial satisfaction [10]. Another point of view describes a study by [11]. He warns that the costs of bugs may become catastrophically high due to grow- ing software in scale, integration and development costs. It is estimated that the costs of maintenance account for over 70% of software costs [11]. IT projects and software systems fail due to various reasons. Various au- thors implied the failure of the process of delivering software, not in the software itself. Software usually involves correct implementation of the speci- fied behavior, but a misunderstanding prevails about that behavior. These issues are usually related to erroneous requirements, not coding or design complications [12]. Most of the IT projects and software fail due to their inability to fulfill the targets [13, 14]. This has been caused due to poorly defined or underspecified requirements which resulted into a non-functioning system [13, 14]. In 2014, 31 % of IT projects failed [15]. Another very com- mon case occurs, when an IT project do not fail but is challenged. In 2014, 53% of IT projects were challenged. Meaning that the project resulted into a system with less features, ran over budget or was not finished on time [15].

Load more