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 re- quirements, 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 re- quirements 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 model- ing 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 re- quirements and reuse the knowledge in regards to the refinement the com- plex 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 test- ing 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 1 Introduction1.2 Research Approach ...... 11 1.3 Thesis Organization ...... 17
19 2.1 Definitions ...... 19 2 Unbounded2.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 3 Modelling3.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 4 Patterns4.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 5 Evaluation5.2 Expert Interviews ...... 73
83 6.1 Conclusion ...... 83 6 Discussion6.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 require- ments ...... 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 function- ality [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 soft- ware 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 de- fined 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]. In other words, the resulting system is underperforming or have met the re- quirements only partially. The factors negatively influencing the challenged project were described as lack of user input, incomplete requirements and specifications and changing requirements and specifications [15].
In requirements engineering there have been recognized many different 1.1types ofmotivation requirements such as softgoals, quality requirements, functional requirements and system constraints. Unbounded requirements are a spe- cial type of functional requirements, which are unable to be fully satisfied. We conjecture, that the reasons of their limitless nature are numerous. For instance, unbounded requirements are intelligent, ungeneralizable, hard to
7 motivation 8 obtain, subjective, dynamic, uncertain or impractical. For these reasons, un- bounded requirements are unrealistic to compute. The key characteristic of unbounded requirements is their infinite number of possible solutions in order to achieve their satisfaction. Although, unbounded requirements may seem to be difficult to implement and it indeed often is the case. How- ever, difficult to implement requirements do not have to be unbounded. Unbounded requirements can be partially satisfied on the evidential basis. Collecting the evidence may aid to increase their partial satisfaction into an acceptable level. Hence, we define unbounded requirements.
Definition 1. An unbounded requirement is a functional requirement that can only be partially satisfied, and the level of satisfaction can be increased by gathering evidence for its satisfaction [16].
Unbounded requirements are often not recognized and perceived as un- bounded. It is important to distinguish between unboundedness and unclar- ity. Unclarity in our research refers to underspecified requirements. Under- specified requirements are such, that are confusingly formulated and the functionality, which they call for is either too broad, ambiguous or unclear. It is known that software requirements can be very vague and stakeholders require something which they are not able to specify in detail [17]. This might lead to misunderstanding and ambiguity. The IEEE standard states that requirements should be unambiguous. Unambiguity is one way of in- terpreting the requirement [18].
A problem is bounded when there is a set of finite acceptable solutions to the original problem [19]. On the other hand a problembounded is & unbounded unbounded. when it appears that there is an infinite number of possible solutions at a time. Unstructured problems are in the front line and yet have to be examined. Unstructured problems have no existing knowl- edge or clear-cut way of solving them. There are two opposite types of problems: bounded-structured and unstructured-unbounded. A bounded- structured problem can be a simple linear equation. The most thrilling prob- lems, however, are unstructured-unbounded. The authors claim that most of the social problems are of this kind [19]. Unboundedness, on the other hand, is a state which is infinite, unobtain- able, has no boundaries or limits. We propose a hypothetical four-quadrant matrix to better illustrate these two terms. Figure 1.1 depicts the relationship between unclarity and unboundedness from a perspective of four quadrants.
Quadrant I: Describe classical bounded requirements which are easy to implement but due to the user’s vagueness and ambiguity it is hard to understand what is required. For example: Add signature to my mails. This is an example of an unclear requirements since we do not know if the user means post mails or e-mails. Similarly, the signature could be digitalized or just a copy of a written signature. Either way the requirement can be easily implemented and fully satisfied by an algorithm. Quadrant II: Describes requirements that are both unclear and unbounded. The desired function or information is unclear. Even though the require- ment would have been clear it would be infeasible or overly complex to acquire it. [19] refer to this type as unstructured unbounded. In their opin- ion this type of requirements is the most thrilling. For example: Determine the most skillful living person on earth? This is unclear chiefly because of the notion “skillful”. We are unable to determine what the user means by motivation 9
The relationship between unboundedness and unclarity
Figure 1.1.: skillful. Skillful in forgery or soccer? Unbounded because there is a finite number of people living on earth. Yet unbounded, since there is 7 billion of us. It would not be feasible to inquire every living person. Quadrant III: Describes requirements which are both easy to implement and easy to understand. In other words, requirements which ask for a simple functionality formulated in a comprehensible unambiguous manner. For example: Show the number of the person calling me. This type of requirement is a no-brainer. It is clear in terms of required functionality by showing the number of the person calling and is bounded since it can be fully satisfied algorithmically. Quadrant IV: Describes a functionality or a state which is precise in terms of requested functionality or information, but it is still unbounded as it can- not be fully satisfied. For example: Determine the exact number of people living on earth right now. This type of requirement is clear. It asks for the exact number of the people living on earth at a moment. However, still unbounded since this number can be approximated only based on the his- torical data and therefore is not precise. Similarly as for Quadrant II, it is infeasible to inquire every woman in the world if she gave birth at a moment. Or to find out how many people died at a moment. Another good example of an unbounded functionality is Google glass and its built-in artificial intelligence and natural language processing sys- tem. Google Glass exemplifies the unboundedness in several aspects. Al- though, the glasses are limited in terms of functionalities, the command to the glasses varies with every input. Every input results in a distinct output and occasionally in no output. This shows the limitless nature of this gadget what we refer to as unboundedness. Often, it is the case that the functionality of the requirement is wanted by the majority of users, however, these users can have varying views on the requirement satisfaction. Varying views cause that a requirement can be fully satisfied in the short term for a concrete instance of stakeholders. In motivation 10 the long run, however, the full satisfaction cannot be achieved as the original implementation is not satisfactory for another instance of stakeholders when the same functionality is addressed. We argue, that the variation of views can be ascribed to people’s diverse opinions on the same matter. For this reason, there are several answers to the same matter and objectively it is hard to say which of the answers is better than the other. We surmise, that collecting these opinions or answers from different sources can achieve a satisfactory level of objectivity, where the majority of stakeholders or at least the bigger masses of people are pleased with the results. research approach 11
In this section, the objective, problem statement and research approach are presented.1.2 research The subsections approach elaborate on formulation of the main research question and related sub questions. Next, research design by design sci- ence is described and explained. The evaluation part explains its systematic method to evaluate the results in practice. The section concludes by address- ing validity and reliability. An unbounded requirement cannot be adequately satisfied without using several sources. By confining oneself only to one source, may lead to a limited satisfaction of the given unbounded requirement. Eventually, this may lead to an overall unsatisfactory of the requirement since its relatively never-ending potential to broaden satisfactory boundaries.
Is to propose several patterns to refine unbounded require- ments in order to achieve higher satisfaction levels and reuse the knowledge ofobjective. solving such complicated requirements. For the majority of unbounded requirements there is virtually unlimited amount of sources which could be consulted in order to achieve their partial satisfaction. From the develop- ment perspective it is not feasible, economic and effective to access every source. Nowadays, in software development unbounded requirements are not rec- ognized as a distinct group. Majority of unbounded requirements is satis- fied only partially and their full satisfaction must overcome immoderate time and investment costs. The answer may lie in a trade-off or exclu- sion/inclusion criteria. Our investigation aims to find the repetitive phe- nomenon in the unbounded requirements and provide patterns which can resolve these highly complex requirements, as it may seem. The key objec- tive is to support the identification and refinement of unbounded require- ments. To do so, we will devise:
• patterns to refinement solutions allowing for engaging numerous sources
• modeling technique that has an ability to depict and decompose un- bounded requirements to several sources
Unbounded requirements are hard to answer and many times impractical to compute as the information for their satisfaction isproblem fragmented statement. over numerous sources. Existing approaches are inadequate in modeling a multisource decomposition that we propose. We suggest the three main reasons why unbounded requirements are seldom addressed:
1. Nowadays software development tries to implement as least as pos- sible in order to save costs and avoid further maintenance costs. De- velopment teams struggle with overloaded implementation backlogs. Too many requirements make development teams to prioritize as much as possible and decide carefully which to implement first. Therefore, options beyond the actual requirement are not considered at all.
2. At present, there is no existing approach or modeling notation that challenges multisourcing. That means satisfying requirements by em- ploying several sources of information that provide evidence for the requirement satisfaction. Currently, there is no notation which sup- ports the source construct. research approach 12 3. Until recently, the internet has not played a big role in the software products. Today, the internet plays a significant role in terms of in- tegration of the current software products. The internet as such is an infrastructure of web services, information and people. Since this infrastructure has not existed until recently there was no need of em- ploying a number of sources of information as these were not available. The availability is no longer an issue and employing freely available sources could significantly increase user satisfaction.
To1.2.1 achieveResearch the objective Questions and tackle the problem statement mentioned in the previous chapter we formulate these research questions. The main research question and sub questions will be unravelled within the research model proposed in the following subsections. The main research question and subsequent sub-questions are stated as follow:
What is an adequate model-driven method to support the refinement of unbounded requirements? rq What is the evidence of the existence of unbounded requirements?
What are the modeling primitives to refine unbounded requirements? sq1 What are the refinement patterns that can support the refinement process? sq2 How to evaluate the effectiveness of the pattern-based refinement? sq3 sq4The main research question suggests to create a method and a modeling technique to conduct the refinement process of unbounded requirements. The main deliverable to answer the main research question will be the mod- eling technique which is able to do a decomposition with respect to employ- ing many different sources. Sub-question 1 attempts to prove that unbounded requirements exist in practice. We attempt to provide real examples formulated by users of the systems. Sub-question 2 addresses the modeling notation itself. What primitives and constructs should the modeling notation consist of in order to be able to model and define unbounded requirements. This sub question is concerned more about the design of the notation, logical constructs, relationships be- tween entities within the notation and ability to depict and provide a correct decomposition to any unbounded requirement. By Sub-question 3 we attempt to define patterns which will represent a generic reusable solution within a given context. Since the refinement to sources as we anticipate may grow into a huge extent. We believe that these patterns present recurring problems that do not have to be solved every time from scratch. But rather use the reuse of knowledge embodied in these patterns. Concerning Sub-question 4 we evaluate the modeling technique, approach and patterns with respect to the quality and applicability.
1.2.2[20] proposeResearch design Method science in information systems research. Their design science framework suggest to build and evaluate artifacts. Developing arti- research approach 13 facts is done by assessing field studies, case studies, simulating, experiment- ing and analyzing. The assessment identifies weaknesses in the artifact itself and further the need to refine the artifact. This research follows the Design Science Research Methodology proposed by [1]. The method consists of several phases: Problem identification, Objective, Design & Development, Demonstration, Evaluation, Communication and Contribution. The DSRM is presented in Figure 1.2.
Design Science Research Methodology [1].
Figure 1.2.: Problem Statement In the previous subsection the foundation and main issues have been out- lined. Nowadays, the internet has allowed for an enormous amount of in- formation which can be freely accessed. Using this information in terms of software development has not been specified within existing requirements modeling frameworks.
Objective The objective is to propose a method in order to decompose unbounded requirements by using not only web services but also people, other sources of information or diverse systems.
Design & Development The research method includes the identification of unbounded requirements for several applications. For each of the selected application we try to iden- tify several unbounded requirements by using the definition from Section 1.1 . Out of the identified requirements we believe we can come up with patterns towards solutions. These patterns are aimed to be defined by ob- serving recurring phenomenon and by matching with the existing pattern research approach 14 forms based on the literature review. The loop of discerning patterns is depicted in Figure 1.3.
Pattern discerning loop
In the literature reviewFigure we 1.3.: will follow the snowballing method. We be- lieve that this method is the most appropriate, given the fact that the re- search topic is novel and has not been researched yet. The purpose of the literature review is to deliver insights in the state of the art and providing supportive evidence to position the topic and provide convincing artifacts of the relevance of this study. We aim to identify and interpret gaps in the body of knowledge within the field of requirements engineering. Relevant studies found by the snowball method will be included in the literature re- view. There will no coherent section about related work rather the literature review will be fragmented over chapters and sections to build convincing chain of evidence and bridge various topics. As described by [20] design science builds and evaluates. We applied the design science framework proposed by [20] on our research. The patterns that will be defined will be assessed internally by experts participating on the creation of the patterns.
Demonstration The approach by any of its means which is constituted of, will be demon- strated on the refinement process of the identified unbounded requirements. By modelling and refining unbounded requirements we are able to demon- strate the capabilities of the method. The demonstration will be done in- ternally by applying the method on a group of testing requirements that are possibly unbounded. This should prove that the completeness of the re- quirement satisfaction is challenged. Also, by creating and defining patterns the modeling technique is being demonstrated.
Evaluation The evaluation of the modeling technique and the existence of unbounded requirements is performed by experts from the industrial sphere. The pat- terns that will be defined will be further evaluated internally by applying them on a sample of unbounded requirements to validate how well the pro- posed patterns can help to refine unbounded requirements. The goals of the evaluation are:
• To find out whether or not the unbounded requirements are addressed in practice. research approach 15 • To point out positives and drawbacks of using the modelling technique and patterns.
The evaluation will follow the design science alternatives for the evalua- tion proposed by [2]. Their framework is shown in Table 1.4. This thesis is a qualitative action research that aims to evaluate a method used in require- ments engineering, where the validation is performed internally and the evaluation is performed externally. The artifacts under evaluation are the patterns, the notion of unbounded requirements and the modelling tech- nique. All these artifacts constitute a method that we call multisourcing. Furthermore, there are different aspects that an evaluation can focus on. Ac- cording to [21] efficacy, accuracy and utility are the most important aspects in evaluating design science artifacts. [22] discusses how to evaluate the value of patterns in business analysis. The paper describe 4 stages of eval- uation: assessment by experts, evaluation by the pattern users, case study and measurement using scorecards. The first two stages are intended for a short-term evaluation, whereas the next two are intended for a long-term evaluation that might take years. The evaluation of patterns is done inter- nally due to the constrained time scope of this project. Based on the possible ways of evaluation of DSR artifacts we follow the framework shown in Table 1.4. The chosen approach is qualitative rather than quantitative as the outcome, which is requirement satisfaction, is hardly measurable. Furthermore, the artifact focus and type are centralized around the main research question. The goal of this thesis is to develop a technical modeling method for unbounded requirements. Next, we follow positivism as a research subarea of philosophy of science. Diverse applications and their requirements were identified, therefore we surmise that the results of the evaluation can be generalized. The function of the evaluation is cross- cutting all four as the purpose of the evaluation is to point out drawbacks and assesss the acceptance of the method. The method chosen for the eval- uation is active research and therefore the evaluation would be done by method users. The object under investigation is the method (artifact) and its constituents not the process of developement of these artifacts. The refer- ence model is further evaluated from deployment perspective as the method addresses how to model and refine unbounded requirements and if such an approach will be broadly accepted. The method will be evaluated externally by potential pattern users as suggested by [22]. The patterns however are evaluated internally. Considering the novelty of the term unbounded re- quirements, the reference point of the evaluation is artifact against research gap. This is predominantly due to exploratory nature of this project. The method by any of its constituents will be evaluated ex ante. Meaning before the approach was implemented and can be observed.
Communication The results of this graduation project can be possibly published at any con- ference concerned with requirements engineering. The results are commu- nicated with various academic staff on a weekly basis. The following table describes tracking of the research activities to research sub-questions.
Contribution To sum up the research method the following artifacts will be created:
• The notion of unbounded requirement research approach 16
Variables and values for the evaluation of DSR artifacts [2].
ResearchFigure 1.4.: Literature Demonstration Expert Method Question Review Survey Design SQ1 XX SQ2 XX SQ3 XX SQ4 XX Mapping of the research activities on subquestions
Table 1.1.: • Modeling technique
• Refinement patterns
This1.2.3 researchRelevance is believed to contribute to the scientific sphere of software development and provide better IT systems to society. The topic of the thesis is positioned in in the field of information science specified as requirements engineering. Requirements engineering is frequently addressed as the first phase of software development where the users’ requirements on software are elicited, identified and refined.
Scientific Relevance This work aims to investigate unbounded requirements, method and ap- proach how to cope with them, and patterns which have an ability to solve them effectively. We surmise that patterns might be the way to go in the refinement process of unbounded requirements. We search for an answer whether or not there is an objective user view on desired software function- ality to satisfy as many users as possible. To put this topic into a broader perspective we ultimately attempt for an answer as how to cope with the vagueness of requirements and how to achieve their satisfaction. How to find the most objective specification for the requirements that are perceived as not implementable, infeasible or impractical to compute. We believe that this investigation may provide a foundation for further and ever perfecting research in the industry.
Social Relevance The results are believed to provide a solution how to make the refinement process more effective and ultimately how to develop less error-prone soft- thesis organization 17 ware. The main contribution, however, lies in the aim of delivering such a method which will diminish the risk of IT software failure, by satisfying user needs into a high degree. Hence, minimize underspecified require- ments, provide a relatively objective view on unbounded requirements, de- crease the occurrence of software failures, diminish development costs and provide a better functioning software for the good of all.
There1.2.4 isValidity a number & Reliability of validity types which have to be addressed and con- sidered in order to carry out high quality research. We state a few types of validity and the ways how to approach the anticipated threats.
Internal Validity Internal validity is the authenticity of the findings regarding the cause-effect relationships. To assure that the research has been conducted properly and there are no external or other forces influencing the outcomes several threats to internal validity are anticipated. In our case, the threat is the process of obtaining the input from experts. For instance, do not influence the inter- viewees opinion, do not use any other materials but own knowledge. The experts in the study should express their true opinion under no external or other influence and avoid the confirmation bias. To guarantee there are no threats to internal validity the researcher will be interviewing the experts individually.
External Validity External validity represents generalizability of the results. To achieve this type of validity we include unbounded requirements from several different software products. Furthermore, not to affect the generalizability we will evaluate the result by experts with different level of expertise. The evalua- tion will take place at a number of companies, preferably within dissimilar countries.
Reliability Reliability refers to a state that the results are not a one-off matter, but the same results will be obtained if the same research within the same setting is conducted. All the sources, instruments and retrieved data will therefore be properly documented and described.
Chapter 1 shows the research approach, main research questions and sub- questions,1.3 thesis and the organization literature review. In Chapter 2 we provide insights into unbounded requirements. This chapter shows some fundamental notions and characteristics of unbounded requirements. In this chapter we make use of empirical screening of idea generation platforms. We report on the ex- istence of unbounded requirements by presenting unbounded requirements retrieved from a real world setting. There is no related work chapter for the exploratory nature of this re- search. Various unrelated parts that are attempted to be bridged would not thesis organization 18 make much sense in the initial parts of this document. Hence, different parts of the literature review are scattered over chapters and its sections to give the reader more comprehensible chain of evidence. Chapter 3 presents a modeling technique that is built on the i* framework. It shows the composition and decomposition operators and their runtime semantics expressed with perti nets. Chapter 4 is dedicated to patterns for refinement of unbounded require- ments. We report on the process of their definition by using the knowledge gathered in Chapter 1 & 2. The definition of patterns consisted of a social network analysis and the process of modeling and analyzing unbounded requirements. It shows two different types of patterns - atomic and aspect patterns. Each pattern shows the context, problem, solution and examples. Patterns are modelled using the modeling technique from Chapter 3. In Chapter 5 we evaluate the artifacts produced in this research. Also, we report on the way of conducting the evaluation. The results from the evaluation are discussed. Chapter 6 then summarizes and concludes the results and shows the main contributions. Furthermore, it identifies the direction of future research. 2
This sectionUNBOUNDEDREQUIREMENTS describes the set-up of an exploratory screening. On a hunt on unbounded requirements we accessed and searched several real world idea generation platforms with feature requests expressed by real users of a particular software. We present application data, examples of unbounded requirements and theory behind the unbounded requirements.
Requirements engineering is acknowledged to be a human-oriented activity 2.1[23]. Adefinitions requirement is a social entity [24]. Requirement is information and information are social thereby requirements are social and can be consid- ered to be social entities. This is a crucial point in understanding the re- quirements. Understanding of requirements, understanding of the purpose of the system can be described by these social relationships that are crucial in building a successful product. These requirements set the relationships among each other and aid to build a better cross-functional program [23]. There are different types of requirements that have been addressed in science. A functional requirement specifies functions that a system should be capable to perform [25]. A non-functional requirement specifies qualities or performance characteristics that a system should possess [25]. A goal describes a state that the system-to-be should be trying to achieve. A hard-goal is a goal with clearly defined criteria. A soft-goal is a goal whose satisfaction criteria are not defined in a clear-cut manner [5]. No clear- cut criteria cause softgoals "to be satisifed only partially", hence softgoals are satisficed not satisfied. [5, 26] [5] recognizes three types of goals: non-functional requirements goals, sat- isficing goals and argumentation goals. Non-functional requirements goals represent what is called quality attributes. The purpose of satisficing goals is to adopt ways to satisfice the non-functional requirements goals. Argu- mentation goals state formal and informal evidence and counter-evidence to support the goal and its rationale. We define a new type of requirements - unbounded requirements. To remind Definition 1 from Chapter 1 a requirement can be classified as un- bounded when is "functional and only partially satisfiable and the level of its sat- isfaction can be increased by gathering evidence for its satisfaction" [16]. There can be different combinations of requirements in terms of their non-/functional characteristic and the level of satisfaction. In the list below, the third exam- ple refers to what we define an unbounded requirement.
1. fully satisfiable, functional: A button that enlarges the lyrics font
2. fully satisfiable, non-functional: Premium membership should not cost more than 10 EUR a month
3. partially satisfiable, functional: Provide access to every song that existed to mankind
19 finding unbounded requirements in practice 20 4. partially satisfiable, non-functional: Ensure confidentiality of the mes- sages
The main cause of partiality of unbounded requirements is information frag- mentation. Information fragmentation means that information is scattered over various applications and storages [27]. Furthermore information can be distributed over multiple physical mediums, virtual storages and people. Unbounded requirements differ based on the type of unboundedness. The types of unboundedness present in unbounded requirements are:
• Uncertain These requirements are uncertain in terms of their inputs and outputs and often include a desire for prediction. The prediction is not guaranteed to be correct and therefore these requirements are unbounded. Example: Search field to recognize what is going to be searched and access the website directly instead of performing the search by search engine • Intelligent Satisfying these requirements requires understanding of the context. Often, emotions and subjective perception of the world are involved. Example: Identify explicit songs. • Dynamic These requirements can be fully satisfied for a few instances. In the long-run partially satisfiable instances can outweigh the fully satisfiable instances. This inability can be ascribed to constant changes of the sources producing the information. Example: Suggest social media contacts to follow. • Ungeneralizable These requirements have numerous inputs and out- puts. Hence, they are hard to be generalized into a stable solution. Inputs that are required in these requirements are dynamically chang- ing and therefore unbounded. Example: Business card snapshots to be transformed into structured data • Subjective These requirements determine suitability and or determine something based on subjective opinions. They are unbounded because the subjective has to be refined into the objective. Example: Suggest songs that the user is interested in. • Impractical These requirements can be partially satisfied, however, non-existent infrastructure or inaccessibility make them hard to com- pute or retrieve. Often, increased time and costs are associated with these requirements. Example: Provide complete TV-shows database. [16]
Throughout this research we will be referring to multiple quality and process terms. These terms are explained in Table 2.1.
An2.2 exploratory finding screening unbounded on the existence requirements of unbounded requirements in prac- has been conducted.tice In this screening 8 modern and traditional applications were included. Namely, Spotify, PopcornTime, Firefox, Nimble, Salesforce, One Drive for Business, Skype and PicCollage. The applications were se- lected according to the suitability within the overall sample. The study in- cludes modern web 2.0 applications and more traditional software. The em- phasis was given to the feature requests stated by the business-to-business and business-to-consumer relationships. Open and publicly available re- 21 TERM EXPLANATIONfinding unbounded requirements in practice Completeness Definition 2. Refers to a state of providing all needed facts to the user or application under de- sign [28].
Satisfaction Definition 3. The sum of feelings or affective re- sponses to distinguishable factors of the computer- based information products and services that are provided within the organization [29].
Refinement Definition 4. The improvement or clarification of something by the making of small changes [30]. Synonym: decomposition.
Information Definition 5. Is the condition of having a user’s Fragmentation data tied to different formats, distributed across multiple locations, manipulated by different appli- cations, and residing in a generally disconnected manner [31].
Composition Definition 6. The action of putting things together; formation or construction [30]. In our specific case, it is a process of combining different sources in or- der to resolve fragmentation.
Terms explained
Table 2.1.: quirements were an inclusion prerequisite. Apart from that, the applications were selected based on application type, public availability, completeness of the database, commerce relationship type, platform and random and subjec- tive element. The applications overview is shown in Table 2.2. Spotify is a non-commercial music streaming service which allows you to play songs either online or off-line. PopcornTime is a modern web application which combines data from torrents and other movie databases in a single application. The service allows to watch movies and TV-shows on demand. The application serves as a connector to torrents. Firefox is a well-known open-source web browser. It is one of the most popular web browsers. Skype is a telecommunication application that provides chat, video and calls over the internet. PicCollage is a smartphone application available on Android and iOS. It is intended to create collages of multiple pictures. The applica- tion has embedded camera functionality. One Drive for Business is a cloud storage system for commercial use. Developed by Microsoft it is a product line intended for companies to share data. Nimble is a CRM tool which is integrated into your social networks such as LinkedIn, Facebook, Google+ etc. It integrates the existing email providers and registers phone calls from mobile phones. Similarly, Salesforce is a modern CRM tool that manages relationships with your business partners and customers. We investigated idea generation platforms of the aforementioned soft- ware. Idea generation platforms allow for collective creativity. Creativity arises from the collaboration of many individuals and therefore generates collective ideas. Collective ideas are hard to be tracked to an individual rather are a result of collaboration [32]. The innovative process originates 22 findingAPPLICATION unbounded LIST requirements in practice Application Name Platform Application Commerce Type Relationship Spotify PC & Mobile Modern B2C PopcornTime PC Modern B2C Firefox PC Traditional B2B/B2C Skype PC Traditional B2B/B2C PicCollage Mobile Modern B2C OneDrive for Business PC Modern B2B Nimble PC Modern B2B Salesforce PC Modern B2B List of applications
TableAPPLICATION 2.2.: DATA Application Name Number of Number of Percentage of investigated unbounded unbounded requirements requirements requirements Spotify 386 21 5.44% PopcornTime 300 30 10.00% Firefox 300 13 4.33% Skype 300 5 1.67% PicCollage 300 12 4.00% OneDrive for Business 152 3 1.96% Nimble 500 38 7.60% Salesforce 300 6 2.00% Total 2,539 128 5.04%
Unbounded requirements in numbers for individual applications
Table 2.3.: in the user domain not in the internal structures [33]. A survey of CEOs re- vealed top sources of new ideas and innovations. These chiefly come from employees, business partners and customers directly [34]. The requirements screened on the idea exchange platforms were formulated by the users of the particular application. We tested feature requests against the definition of unbounded requirement. If the requirement was complaint with Defi- nition 1 then such requirement was classified as unbounded. Altogether, more than 2,500 feature requests were screened. Overall, unbounded re- quirements accounted for 5% of all requirements. Meaning roughly 120 requirements were possibly unbounded. The overall percentages of unbounded requirements for the individual applications are shown in Table 2.3. As the table shows, there are big differ- ences of the overall ratio of unbounded requirements. We surmise, that the ratio of unbounded requirements is dependent on the type of application, its overall functionality and its stage in the product lifecycle. As shown in Table 2.3, some applications have a slightly bigger or smaller sample size. The reason for OneDrive for Business having a smaller sample size is that the number of available feature requests was limited to the size shown in Table 2.3. To even up the gaps among sample sizes, applications like Spotify and Nimble have therefore larger sample sizes compared to other applications. The goal was to keep the sample size of 300 requirements for each of the applications. All of the feature requests are available online via the uservoice idea exchange platform or community forums. A few 23 R1 Spotify Showfinding original unbounded year of album requirements re- bit.ly/ in1SCQonp practice lease R2 Spotify Provide access to every song bit.ly/1SCQmvI ever existed to mankind R3 Spotify Filter out inappropriate content bit.ly/1LEaixZ for the youth R4 Spotify Show scrolling lyrics bit.ly/1LEa7mk R5 PopcornTime Show reliable movie ratings bit.ly/1LEa5e3 R6 PopcornTime Sort out the insufficient number bit.ly/1LE9VU1 of seeders R7 Firefox Disable shortcut functionalities mzl.la/1LEa0qR while playing a game Examples of unbounded requirements
Table 2.4.: examples of unbounded requirements from the empirical screening can be found in Table 2.4. Table 2.4 presents several unbounded requirements found in practice and try to show evidence of their existence. A complete list can be found in AppendixA. In the list below, we explain the unboundedness of these re- quirements:
R1 is identified as unbounded due to the inability to retrieve some of the release dates. It is important to note that not every album is digitalized or not every release date is known especially from decades ago.
R2 is possible to be implemented, however, we would have to inquire every single minute every person in the world if he/she has composed a song.
R3 shows that without involving humans into classifying inappropriate- ness of pictures we would not be able to satisfy this requirement.
R4 can be satisfied by using a language processing tool, which could tran- scribe the spoken word. Often, these tools are not precise enough and misidentify a significant amount of words such as slang.
R5 has been identified as unbounded for PopcornTime, shows a differ- ent subjective nature of unbounded requirements. This requirement shows that users are not satisfied with showing only one type of rat- ing. At the moment, PopcornTime possesses only the IMDB movie rating that has led to partial satisfaction as the user is apparently not satisfied with the existing solution.
R6 needs to be smart and suggest torrents which are of the best fit and availability at the present time. The availability changes over time and different torrents should be unified within one mechanism.
R7 is describing a functionality which is able to determine if the user is playing a game in Firefox. This might seem as a trivial issue by inquiring Adobe Flash or similar embedded software. The problem is how one could tell the user is not watching a video instead of playing a game. observations on unbounded requirements 24
For each application there was a certain shared characteristic among the 2.3identified observations unbounded requirements. on unbounded requirements Spotify’s unbounded requirements involved a lot of subjectivity and asked to determine personal suitability such as discover function, suggest function. All unbounded requirements were specifying interactive actions. Meaning involving the user into some extent. This might have to do with the subject- prone content and usage. PopcornTime has a broad range of functionalities ranging from subjective and dynamic to ungeneralizable. This is an innovative highly interactive modern application. The proportion of unbounded requirements was 10%. This application scores the highest on the percentage of unbounded require- ments. Firefox with its nearly 2% this application scored among the lowest on the ratio of unbounded requirements. For example, search prediction. The handful of requirements showcased functionalities that required to omit, recognize or detect something. Skype scored the lowest on the percentage of unbounded requirements with its 1.67%. The few unbounded requirements were describing spelling and grammar checking functionalities. We can see that the overall function- ality can have an impact on the occurrence of unbounded requirements. Most of the unbounded requirements found for PicCollage were asking for suitability to show appropriate content or chased for subjectively deter- mined solution. There were also requirements that were asking for more complete content. The ratio of unbounded requirements is just below the overall average, which is 4%. The least unbounded requirements were those of One Drive for Business. Due to the constrained sample size the proportion of unbounded require- ments was not the smallest and slightly surpassed Skype. We do not inter- pret these requirements as there were only 3 requirements that were identi- fied as unbounded. Nimble is a modern B2B application. It integrates various systems, such as calendars, email accounts, phonebooks, etc. In this group there were all kinds of unbounded requirements found. This group was exceptionally rich on unboundedness. This could be possibly ascribed to the integration of var- ious services. This application scores the second highest on the percentage of unbounded requirements with its 7.6% of unbounded requirements. Salesforce did not contain as many unbounded requirements either. The unbounded requirements for this application were intended to form a test- ing sample. The couple of unbounded requirements was showing a desire for language processing capabilities, such as translation and spell checking. We analyzed comments on Spotify’s unbounded requirements from de- velopers and people in charge of handling feature requests. For Spotify we found a group of ideas that was labelled not implementable. This group con- tained 21 ideas out of which 28% were classified as unbounded when Defi- nition 1 was used. Another group found for Spotify was called implemented. This group contained 239 requirements, only 2% of these requirements were classified as unbounded. The last significant Spotify’s group of ideas was new ideas. We screened 122 requirements that were labelled as new ideas. Unbounded requirements accounted for 7%. study of important quality attributes 25 Unbounded requirements are prone to mis- interpretation. Often the formulation of what the requirements engineering practicecreative calls misinterpretation. requirements are in fact ideas. Particularly, requirements gen- erated by users. In other words feature requests. In requirements engineer- ing these are addressed as functional requirements. The notion of functional requirement, however can merely be describing ideas. These ideas are cre- ating better products by an active involvement of users on the creation of the winning product. The investigation of unbounded requirements have shown that the word unbounded describes a challenge. The same challenge which is embodied in a great idea. David Hume, a famous philosopher, sees ideas or human thoughts as unbounded as they are not restrained to any limits. Although, it is not possible to measure a quality of an idea and it often is hard to determine which idea is great and which is not so great.
There have been many studies done on software systems quality attributes. 2.4In this sectionstudy we of provide important an overview of quality quality attributes attributes that can be pos- sibly a significant factor for unbounded requirements. We present simple and composite quality attributes. Simple quality attributes do not embed any other attributes and are descriptive on their own. Composites are nest- ing a number of simpler attributes and are explained by a number of other attributes. Performance has been recognized as one of the most important measures imposed on software [35]. Performance consists of multiple measures such as throughput, response time and deadlines [36]. Unbounded requirements are not an exception and similarly as for any other software, high perform- ing outcome is expected. The main challenge for unbounded requirements is to provide an adequate result within an acceptable time window. We therefore divide performance into two measures - time and responsiveness. If an algorithm is invoked and this algorithm relies on composite sources which need to provide an answer. These sources have to be able to response in time to assure that the algorithm will be successfully executed. Respon- siveness is defined as follows: Definition 7. Responsiveness is the ability of a functional unit to perform an assigned function such as computer or telecommunication service within the required time interval [37]. On the contrary, response time is formulated by the following definition: Definition 8. Response time is associated with the time an application takes to respond to some output [36]. When a software system is designed as a composite. The overall execution time of the algorithm might soar. For that reason, the overall time of execution must be considered. Response time is denoted as time. The difference between responsiveness and time is that responsiveness is meant to be a metric of how well a source performs. Contrariwise, time measures the performance of the application as a whole. In software development reliability is seen as another crucial quality. Re- liability has been addressed continuously by many studies and researchers [38, 39, 40, 41]. A source should be reliable in terms of continuous produc- tion of correct results and reachable state. Reliability is defined as: Definition 9. The ability to maintain its level of performance under stated conditions for a stated period of time [42]. study of important quality attributes 26 Reliability is often confused with other quality attributes such as integrity, security or consists of other attributes such as accuracy, availability, etc. It is inevitable for unbounded requirements to work with several sources of a good information quality. Credibility is considered to be a key compo- nent for information sources [43]. Credibility is broken down into two main dimensions - expertise and trustworthiness. It is important to distinguish between reputation of a source and actual information quality. Trustworthi- ness is based on emotional perception of a source. Physical attractiveness often leads to preferring one source over the other. Definition 10. Trustworthiness is a receiver judgement based primarily on the subjective factor [43]. Expertise can be relatively subjective but importantly it includes objective characteristics as well [43]. Expertise refers to high quality sources of ac- curate information. It is more logical to invoke such sources rather than information from amateur services or people. Expertise is based on rational perception of the world. The SOA principles state that services should be reusable, composable, loosely coupled, discoverable, autonomous, etc [44]. We introduce stability as a measure of the reusability principle. Stability refers to stability of a system over time without having to change much [45]. Stability is a part of maintainability. By choosing sources stable over time the implementation will not need many updates and replacements of wrong implementation. Stability is correlating with maintainability as a stable solution is expected to consume less amount of maintenance [42]. As we suggest, the more sources the better. The overall solution, however, should put emphasis on the maintainability. These kind of systems are very likely to grow in scale and the maintainability of the system can grow rapidly. Maintainability is the ease of maintaining a piece of software. Composability is meant to present the composability principle of SOA. Composability is defined as an ability of participant sources to work to- gether [46]. The method of solving unbounded requirements entails multi- sourcing and composing of various services. For this reason the composabil- ity is important to be addressed. Modifiability describes various operations over existing implementations, e.g. the ability of new services to be added [47]. We position deployability within the structure of modifiability. There are millions of sources of information. The implementation of unbounded requirements should remain agile, allow to deploy a new source at any time to upkeep its functionalities and add new ones. Deployablity describes abil- ity to deploy a new source without having much negative impact on the original implementation and users. Another term similar to our explana- tion of deployability is extensibility [47]. A candidate pattern Composition extension addresses this issue however has not yet been proven and adopted [44]. As it is important to be able to compose and deploy new sources it is equally important to have these sources available when required. Consider- ing an implementation without properly functioning services would most likely fail to deliver the desired effect. Definition 11. Availability is the proportion of time a system or component is operational and accessible when required for use [47]. Although, we addressed the credibility that is into a big extent subjective we conjecture that the objective element of the information quality such as correctness has to be introduced. As expertise is not infallible, objectivity or facts often need to be determined. Sometimes even the most expert source can provide a false value. study of important quality attributes 27 Definition 12. Correctness is an extent to which a program satisfies its spec- ifications and fullfils the user’s mission objectives [41]. Next, safety also denoted as security has various aspects. As unbounded requirements are not only unbounded but also just mere requirements. Un- bounded requirements might be present in security and safety sensible sys- tems. Definition 13. Safety is addressed as preventing errors before they happen [48]. The suitable meaning for unbounded requirements describes safety as pro- tection against harm or error. Safety encompasses the social impact of safety in software systems. That is preventing users against damage caused by software. Cost refers to a financial measure of invocation of a piece of code. Costs become essential when people and crowd workers are a part of an al- gorithm. Some sources such as crowd workers when used as a source need to be paid. When a certain feature which is designed on the crowd workers grounds is invoked a million times a day, the costs of maintaining such a system may become unbearably high. Lastly, integrity is the likelihood of the source to produce unexpected results. Integrity is also meant to address coherence among information being provided from multiple sources as this might be conflicting. Some sources might be confusing by nature and may either provide a wrong result or may just collapse unexpectedly. A desire to remain coherent and avoid conflicts is reflected in this attribute. This is particularly important when overly relying on one expert or involving people in the algorithm. Table 2.5 gives on overview of suitable quality attributes and shows the meaning of the individual attributes. study of important quality attributes 28
SINGLE ATTRIBUTES Composability ACMP Ability to be deployed independently or within the existing ecosystem of sources. Availability AAVL A source is in a specific operable and commit- table state. Deployability ADPL The extent to which a new source is deploy- able within the existing ecosystem of sources. Stability ASTB Much of sources will be stable over time and will not need any interference. Time ATME Overall, how quickly the designed solution provides the results. Cost ACST Cost of source invocations in terms of finan- cials. Reliability ARLB Continuity of correct service. Addresses ac- curacy, consistency and error proneness [49]. Expertise AEXP Quality and accuracy of the information. Trustworthiness ATRS Physical attractiveness or reputation. Correctness ACRC Conformity to the truth or fact. Addresses completeness and consistency [49]. Responsiveness ARSP Latency of a source invocation. A so called input-output loop. Safety ASFT Protection against consequences of error, fail- ure accident or harm. Maintainability AMNT How easily the sources can be maintained. Integrity AINT The likelihood that the source will produce unexpected results. Addresses coherence. Overview of quality attributes for unbounded requirements
Table 2.5.: 3
In this sectionMODELLINGLANGUAGE the foundation of our modelling notation is explained. The proposed modelling notation aims to support the refinement process of un- bounded requirements. The notation has been inspired by the i* modelling framework [50]. The i* framework provides a familiar environment for var- ious experts from practice. The proposed modelling notation is a slight modification to the i* framework by adding the labelling rules, the source construct and the semantics of modelling features. Next, to allow for com- posability of considerable amount of sources, prioritization and runtime semantics have to be brought in. Prioritization is an important factor in composing a conglomerate of different information feeds. It has to be dis- tinguished which source should have precedence over others. At the time of invocation there are different type of runtime flows that conceive the infor- mation. Traditional ways of invocation such as sequence and concurrency are discussed. Moreover, the fallback invocation type has been introduced. The modelling notation has been inspired by the i* framework. There are new constructs and rules introduced, however much of the former con- structs have been omitted with the intention to provide a comprehensible framework. The goal is to keep the modelling language minimal and well founded.
Model-driven software development will play the key role in the future as 3.1it helps background to abstract better the growing complexity and demand, predicts analyst Forrester [51]. Model-driven software development is a procedure applied in agile methodology which aims to cope with large-scale software development [52]. [5] describes three types of refinement methods that are related to the three types of goals they propose. These methods are: goal decomposition methods, goal satisficing methods and argumentation methods. The goal decomposition methods are simple AND refinements where a goal is de- composed into a set of goals. The goal satsficing methods refine a goal into a set of satisficing goals. The argumentation methods then provide claims why the satsficing of a goal is important. For modeling behavioral, declarative and interactive aspect of software system Object Oriented Analysis [53] and Object Oriented Modeling tech- nique [54] were first proposed. One of the first requirements modeling tech- niques called the Requirements Modeling Language (RML) was proposed by [55]. The RML framewok provides object-centralism and ontology for requirements modeling. The RML is a foundation for other requirements modeling languages. It has been further implemented and elaborated in many other requirements modeling techniques such as Telos, Concept Base, ACME [56]. Perhaps one of the first attempts for a requirements modeling language was the Conceptual Information Model [57]. The RML successor Telos is a requirements modeling technique that supports development of
29 background 30 information systems [58]. The reasons for the success of Telos could be ascribed to its ability to add new ontologies and domains [56]. AUML stands for agent interaction diagrams. AUML introduces agents into the classical UML diagrams In AUML agents correspond to objects [59]. The Gaia methodolgy puts forward statements of requirements to such a state that they can be implemented directly. There are two types of Gaia con- cepts: abstract and concrete. The abstract concepts can be roles, permissions, responsibilities, etc. The concrete concepts can be agent types, services, etc. The Gaia methodology encourages developers to use agents when design- ing systems. When the idea of the system as a society is conceptualized the Gaia introduces roles [60]. The KAOS is a multi-pardigm specification language that consist of two layers: an outer semantic net layer and the inner formal assertion layer. The outer semantic layer serves for the declaring concepts. The formal definition layer defines concepts [61]. The KAOS captures why, who, when as an addition to usual what requirements specification [62]. The language is goal oriented and provides a wealthy ontology of various constructs such as goals, objects, constraints, agents, etc. [61]. For the sake of this research we will be using goal modeling. Goal model- ing has become a mainstream in requirements engineering [63]. According to the authors, context can affect the user goals. Hence, contextual goal modeling represents an update of goal modeling by introducing the context construct. Context is defined as “a partial state of the world that is relevant to an actor’s goals“ [63]. One of the main goal modeling languages is the i* framework. The i* framework [64] is an attempt to shift the main focus of requirements modeling from the information flow to social analysis. The notion of i* stands for "distributed intentionality" The i* framework centers around the actors and dependency links. The i* modeling comprises of two main models - Strategic Dependency Model and Strategic Rational Model. The Strategic Dependency Model defines dependency links between actors. It shows how one actor is dependent on another for something. The Strate- gic Rational Model is describing the rationale why an actor is dependent on others [65]. Tropos is an agent oriented software development methodology. Tropos consists of agents that are represented as actors, goals, dependencies, be- liefs, resources, plans and capabilities. There two main key characteristics of Tropos: the notion of agent and the emphasis on early requirements analysis. Tropos support 5 different types of modeling. These are actor modeling, goal modeling, dependency modeling, capability modeling and plan modeling. Tropos addresses 4 stages of software development - early requirements analysis, late requirements analysis, architectural design and detailed designed. The first phase is modeling social interactions between stakeholders and possible users of the system. It is merely showing rela- tionships with one another and showing their mutual dependencies. The second stage aims to model the to-be state. The architectural phase defines input and control flows in the systems through dependencies. It shows in- put and output of the concerned actors. The detailed design phase models actors capabilities, beliefs, goals as well as communication paths. In com- parison with other software development methodologies Tropos supports all phases of software development from early requirements through late requirements, architectural design and detailed design [3]. In comparison with the i* and KAOS. The i* focuses on early requirements engineering and the KAOS is oriented more on late requirements analysis. principles 31 Figure 3.1 gives an overview of various software development methodolo- gies and the stages of software development they address as described in [3].
Software development methodologies compared [3]
Figure 3.1.:
The tandem of our modelling technique and patterns consists of two crucial 3.2types ofprinciples elements – decomposition of tasks and composition of sources. De- composition means that generic primary tasks are gradually getting refined into more specific subtasks. Composition is a significant factor in retrieving available data to achieve a sufficient satisfaction level for a given task. The approach is positioned within the service oriented architecture. The hourglass principle is applied in our approach. The hourglass princi- ple describes how the refinement meets the composition. Refinement or in other words decomposition is depicted as the upper part of the hourglass where specification level is getting narrower and narrower. The refinement constituent is modifying coarse grained requirements into fine grained, nar- rowly specified requirements. Composition is shown as the lower part of the hourglass, where dependency on a few or many sources is shown. To provide a good foundation for a particular subtask we assume the more sources the better. For this reason, the source composition part is depicted as an expanding constituent. There are two types of service composition: single and composite. Single composition does not rely on other services. Composite composition relies on other services working in tandem to pro- vide added value [46]. For that reason, the source composition part of the hourglass is shown as growing top-down.
Outsourcing has been on the rise since the early nineties. For instance, increased outsourcing in production of au- tomobileoutsourcing parts & had crowdsourcing been documented [66]. In the nineties evidence on the rise of outsourcing was provided in thirteen US states [67]. The major shift towards outsourcing has happened due to narrower specialization [68]. Out- sourcing has expanded into every area of business and life. As we can see outsourcing in many areas of the world, it is not surprising that it plays its role in the IT industry [69]. Specifically, its possible potential in require- ments engineering. In particular, refining requirements and assigning their functionalities to external parties via APIs, making use of their information infrastructure and knowledge. We refer to this approach as multisourcing. Multisourcing delineates a state of moving beyond the current outsourcing modelling concepts 32
The relationship between the refinement and the source composition
Figure 3.2.: options, while blending business and IT services from both internal and external environment [70]. A new approach to outsourcing that has evolved is crowdsourcing. Hu- man computation is a paradigm that is concerned with involving online people. A special form of human computation is crowdsourcing [71]. So- cial computation has been recognized as an approach where people are assisting computers in problem solving [72]. A crowdsourcing platform is a system that allows to distribute work to a big amount of workers [73] Crowd- workers are people that can get engaged on a crowdsourcing platform and perform small tasks for a small amount of money. These tasks are mostly, describing pictures, labelling pictures, extracting sentiments and snippets and so on. [74]. People get engaged into computing because increasing task complexity increases the likelihood of human involvement [75]
The main constructs used in the modelling notation describe links and 3.3nodes tomodelling express logic and concepts relationships between functional modules of a software system. There are four main types of constructs used in the lan- guage - task, subtask, source and relationship. These modelling constructs are built on the i* framework [50]. Our modelling constructs slightly dif- fer from the i*, as they either have degraded or upgraded semantics. The graphical notations of the modelling features are depicted in Figure 3.3.
The graphical notation of basic modelling features
Figure 3.3.:
Definition 14. A task specifies a particular way of doing something [50]. task modelling concepts 33 It is a depiction of a software functionality. It is a basic functional unit that is the proprietor of the functionality itself. As a task is meant to be a bigger functional unit, a task might be decomposed into smaller subtasks.
Definition 15. An actor is is an active entity that carries out tasks (actions) actor to achieve satisfaction (goals) by exercising its knowhow [50].
The term actor refers to any unit upon which dependencies can be drawn. We do not address goals in our modeling technique, therefore goals are replaced by satisfaction in the definition.
Definition 16. A resource is a physical or informational entity that is not resource considered problematic by the actor. The main concern is whether it is available [50].
Resources in our modeling technique are considered to be inputs and outputs from one actor to a task or another actor.
Definition 17. A source is an entity that is able to provide information and source knowledge that serve as a computing or information capacity for a task.
Therefore, satisfaction originates in the nature of information present in a source. Sources are practically feeding tasks with information and knowl- edge. This process is of utmost importance in satisfying unbounded require- ments mainly due to information fragmentation. The difference between the actor and the source is that the source feeds the actor with computational or informational capacity. Sources have the information or computing capac- ities that the actors desire. The actor construct is the system under design that needs sources as its feeds. Actors are able to execute their knowhow when they get the inputs from sources.
Definition 18. A subtask is a subcomponent of a task and is on a lower subtask hierarchical level than a task.
A subtask has a parental task that is hierarchically higher. A subtask is smaller functional entity than a task and is created to break down the process for comprehensibility purposes. Normally, a task consists of several subtasks. It represents a basic functional module. It is not a basic modelling concept rather a subcomponent. Thus, modelled as a task.
To depict relationships among tasks and sources some of the i* relationships have been used in this modelling language. There are threerelationship types of relationships among sources and tasks - decomposition and composition links. The Decomposition relationship applied on tasks il- lustrates that a task is decomposed into smaller subtasks. A task can be decomposed into an arbitrary number of subtasks. Similarly, a subtask may consists of a set of linked tasks and subtasks. A decomposition link reads top-down. The Composition relationship is used solely between a task and a source and depicts a state of assigning sources to a task. It shows that a labelling conventions 34 task is fed by information or computing capacity from the linked sources. A task can be linked to an arbitrary amount of sources. For the graphical vi- sualization a means end link is used. The means end link describe a means that is expressed by a source and an end that is represented by a task. This link indicates a relationship between an end and a means for attaining it [50]. A composition link reads bottom-up. Composition is a crucial element in dealing with unbounded requirements. As we emphasize the combination of the two contrary approaches, namely: composition and decomposition. The means end link will be further labelled as composition link. The Depen- dency link shows a dependency of one actor on another. The dependency link is adopted from the i* framework [50]. The dependency link reads as depender depends on dependee. The depender requires something and is on the left hand side of the link. Whereas, depender provides something and is on the right hand side of the link. The dependency link is a sort of input and output relationship where one party can provide a dependum and the other party wants the dependum. The graphical notations of these links are shown in Figure 3.4.
The graphical notations of the relationships
Figure 3.4.:
The labelling prefixes as a property of the language support formalization. The3.4 labellinglabelling concepts pattern conventions the language for the sake of consistency and intelligibility. The labelling prefixes can be only used for tasks and sources. The labelling remains formalized and is defined. Meaning that any labelling can be introduced and defined and then used as a valid construct. As a matter of fact this gives the modelling language a degree of flexibility. There are two main groups of labelling prefixes: task and source labelling. The graphical visualization of these constructs is shown in Figure 3.5.
The graphical notations of labelling prefixes
Figure 3.5.: Tasks are labelled in a generic format
Sources are labelled in a similar way as tasks
To3.4.1 satisfySource unbounded Types requirements we need sources of information that will provide inputs to tasks and eventually satisfy a requirement. Sources of information are labelled on the source construct only. We employ icons to visually differentiate between different source types. The icons identifying the source types are shown in Figure 3.6. These icons are usually situated in the top right corner of the trapezoid. We distinguish 4 main types of sources: runtime semantics 36 • Algorithm is being executed within the context of the calling system.
• Information is a corpus of unstructured information that can be queried using a search engine and aggregated statistically.
• Service is being executed outside the context of the system under de- sign, such as a third-party web service.
• People refers to the assignment of tasks to crowd-workers or the user/s of the application via a direct communication platform.
Source types labelling icons
Figure 3.6.:
In this subsection we state a tool for expressing the semantics and basic principles3.5 runtime we use throughout semantics this thesis. Petri Nets are a promising tool in describing behaviour of information processing systems. They are particu- larly useful in expressing concurrent activities, flows charts, mathematical models governing the behaviour of systems [77]. With Petri Nets we express the semantics of fallback, sequence and concurrent operators, and, user & xor decompositions.
The refinement and composition operators are depicted as Petri Nets. We use Petri Nets as a tool for describing runtime semantics of thesepetri operators. nets Definition 19. A Petri Net is a directed biparite graph consisting of places and transitions, where arcs are either from a place to a transition of from a transition to a place [77].
Places represent conditions and are signified by circles. Transitions repre- sent events and are drawn as bars. Arcs, drawn as arrows, connect places and transitions. Petri Nets use tokens. Tokens are sort of fuel for transitions in order to be fired. Transitions consume these tokens and move the tokens to another place [77]. General Petri Nets rules apply in our graphs. How- ever, to better understand the flow of information we explain the rationale of the Petri Nets and its specific features we adopted:
• The epsilon transition is a special type of transition that is fired when- ever the pre-conditions have been met.
• The initial state of the system features a token and indicates that a task or invocation starts from this place. The initial state of the system is denoted as P0.
• The final place has no outbound arc and is marked as P-end. When the token reaches the final state either the task is satisfied or the invocation is terminated. 37 Operator Start Failruntime semantics End AND ti start ti fail ti end XOR ti start ti fail ti end USER ti start ti fail ti end Sequence si invoke si fail si return Concurrency si invoke si fail si return Fallback si invoke si fail si return Mapping of the events onto the operators
Table 3.1.: • A parameter over an arc specifies its weight.
• A Petri Net is terminated when the final place obtains a token. Next, we specify events that are used to express the meaning of possible transitions. We devise three different types of events: • Start - describes the point in time at which an event begins.
• End - describes a final part of an activity.
• Fail - refers to a state of being unsuccessful in reaching the final place. For the source composition operators we have used different labelling of the events than for the refinement operators. Particularly, the start of a source transition is referred to as invoke. Since we do not start a source rather invoke a source. Similarly, the end of a source transition is marked as return. As we do not end a source but a source returns an answer. We attempt to remain cohesive in the semantics, therefore the meaning of the three above stated events present a foundation. However, dissimilar nature of the source composition and refinement on its own requires a more natural labelling. Table 3.1 demonstrates the events for the source composition and refinement.
A semantics of a task calling a source and a source returning information to a task is explained here. The runtimetask to semantics source to from task a task on runtime to a source starts with task invoking the operator that is then calling the designed sources. A task features an oper- ator that control the operations over sources. The operator specifies which type of invocation to employ. The operator then activates the invocation of sources and returns answers or capabilities to the task if provided. The task then performs necessary actions. After the task has started. In case that sources that have been invoked were successful the entire invocation was successful. The information from sources are then returned back to the task. The task is treated as successful when it obtained the necessary information. It can be concluded that the execution was accomplished. If the source does not provide desired inputs within a given time frame such source is consid- ered to fail. In this case it is a failure of the operator. Consequently, it is a failure of the task as well. The execution has not succeeded and results have not been retrieved.
3.5.1DecompositionDecomposition primitives Primitives describe functional decomposition into smaller logical entities - tasks. These primitives aspire to restructure the require- ment complexity. Since unbounded requirements by its description are re- runtime semantics 38 quirements with no boundaries or limits, these refinements frequently result in interlinking trees consisting of subtasks. The functional decomposition of unbounded requirements is motivated by the SOA functional decomposition pattern [44]. Where higher level func- tions are refined into lower level functions. This abstraction break down enables for formulating functional modules. Later, in the composition part sources of information are appointed to these modules. The decomposition primitives were defined to introduce logic of refine- ment in modelling unbounded requirements. They are an important factor in dealing with these intricate requirements levied on software. The logic they introduce is very similar to programming languages logical operations [78] and requirements refinement logical constructs [79]. This is particu- larly important when alternative ways of decomposition must be modelled. We introduce an AND decomposition operator which is always modelled between two tasks and commands to execute both tasks. Next, we intro- duce an XOR decomposition operator that is modelled between two tasks and commands to execute only one of them. The XOR primitive facilitates modelling of alternative refinement branches. On one hand, software engineering is often unable to fully capture what precisely the user requires. On the other hand, users are not able to specify what their truly demand from a software system [17]. We introduce an oper- ator where the user overtakes control over the refinement process. This gives the model an ability to be flexible and meet the user’s need accordingly. It is important to note that the user is involved at two different stages of a requirement refinement. That is the composition, where the user serves as a source and refinement where the user is engaged to participate in the decision process of the refinement itself. Furthermore, it is defined that the user can pick only one alternative, mainly due to practical reasons such as avoiding conflicts. As the user should have the power to decide himself what is the appropriate solution. The graphical visualization of the above decompositions are depicted in Figure 3.7.
The graphical notations of decomposition primitives
Figure 3.7.: The AND decomposition is intended to break down the multiplex tasks into smaller subtasks. The logical operator AND be- tweenand decomposition two subtasks orders to execute both of them. Hence, executing both t2 and t3 is a way to execute t1. Used when all tasks should be involved in order to achieve the wanted state. Do not provide the option of an al- ternative rather gives order to perform all actions. This is suitable to use when the primary task needs to be refined into smaller chunks in order to satisfy the requirement. Usually used to decompose the primary task or refine associated tasks. Expresses "both". runtime semantics 39 Semantics: The execution of task ti requires task tj and tk and ... and tn. n is the number of subtasks. Runtime semantics: Transitions tjtotn can be started in an arbitrary or- der. As soon as these transitions are fired, tokens move one place forward which leads to the end transitions that inform that all subtasks have been ex- ecuted successfully. Next, the token moves. After that an epsilon transition is fired at the moment when all places required to enable the epsilon transi- tion are populated with a token. The epsilon transition fires automatically. After its execution the token moves to the final place that indicates that the primary task consisting of the specified subtasks has been successfully exe- cuted. For example, let us suppose an AND decomposition directive over tasks t2 and t3 that are the decomposed subtasks of task t1. When the al- gorithm to execute task t1 is activated both tasks represented by t2 and t3 must be executed. The algorithm executes both t2 and t3 and their onward tasks and sources. A Petri Net describing the AND runtime semantics is shown in Figure 3.8.
The runtime semantics of the AND decomposition
Figure 3.8.: To solve large and complex unbounded requirements we establish an XOR logical operator in order to address alternative task re- finementxor decomposition to a given problem. Providing several alternative paths of invoking sources can have beneficial effect on varying stakeholder views. This oper- ator gives a high-level control of entire solution branching. Should be used when the implementation considers different high level alternatives. It is tar- geted to decompose a primary task or associated subtasks where only one option out of few may be chosen. Let us suppose we have a primary task t1 decomposed into a subtask t2 and t3. Over the subtasks an XOR operator has been drawn. Therefore only one of the subtasks can be executed. Also called exclusive disjunction. Expresses "either one, but not both". Semantics: The execution of task ti requires only one task tj or tk or ... or tn. n is the number of subtasks. Runtime semantics: Transitions tjstart to tnstart can be started when- ever necessary. However, only one route can be initiated at a time as there is only one token in their pre-condition place. As soon as one of the tran- sitions is fired, the token move one place forward which leads to the end transition that suggest the concerned subtask has been successful. After the firing of the end transition the transition is terminated. Finally, the token moves to the last place and shows that the primary task has been successful. For example, let us suppose an XOR decomposition directive over tasks t2 runtime semantics 40 and t3 that are the decomposed subtasks of task t1. When the algorithm to execute task t1 is activated only one of the two options represented by t2 and t3 can be executed. If t2 is chosen, the algorithm abandons the execu- tion of t3 and its adjacent tasks and sources. These tasks are not going to be carried out. If the algorithm chooses t3 the execution of t2 and its onward tasks and sources is abandoned. A Petri Net describing the XOR runtime semantics is shown in Figure 3.9.
The runtime semantics of the XOR decomposition
Figure 3.9.: The USER decomposition objective is to involve the user in the refinement process in order to let the user decide as it may facilitateuser decomposition the level of satisfaction. Occasionally, it is hard to say what is best for the user. Providing several alternative paths of invoking sources may in- crease satisfaction. This operator stipulates a user control over the returned results and execution. The control over the results is defined as a priori state since the user could not know what the result will be beforehand. Should be used when the implementation considers a few dissimilar alternatives in terms of functionality. Advised to decompose primary task or refine associ- ated subtasks by involving the user in this process. Expresses "user choice". Semantics: The execution of task ti requires user ui to opt one of tasks tj or tk or ... or tn. n is the number of subtasks. Runtime semantics: Transitions tj to tn can be initiated by a user choice. Showing that the user of the application can favour the routing of the solu- tion. However, only one route can be used as there is only one token in their pre-condition place. Right after the user has chosen an option a start tran- sition is fired, the token move one place forward, which leads to the next place. An end transition is fired if a subtask succeeded. The end transitions indicate that the concerned subtask has been successful. After that T2 or T3 is fired and indicates the end of the runtime. Finally, the token moves to the final place and shows that the primary task has been successful. For exam- ple, let us suppose a user decomposition to instruct execution over tasks t2 and t3 that are the decomposed subtasks of task t1. When the algorithm to execute task t1 is activated, user U is asked to opt one of the two options represented by t2 and t3. If user chooses t2 the algorithm abandons the execution of t3 and its connected tasks and sources. These tasks are not going to be carried out. If the user chooses t3 the algorithm abandons the execution of t2 and its onward tasks and sources. Either way, after selecting one of the options the start transition (t2startort3 start) starts. This transi- tion shows that a subtask has started. Next, when a task is successful the runtime semantics 41 end (t2endort3 end) transition is activated. The end transition illustrates that the subtask has been successful. The token moves to the final marking and and the parent task is ti is regarded as successful. A Petri Net describing the USER runtime semantics is shown in Figure 3.10.
The runtime semantics of the USER decomposition
Figure 3.10.:
3.5.2CompositionComposition primitives Primitives intend to supply a framework for aggregating sources. These primitives define basic solution and notion technique in order to em- ploy many relevant sources into a solution. The idea of composition of sources have been inspired by service composition patterns by Erl. Service composition patterns aim to blend services into conglomerate distributed so- lutions [44]. Composites can be combinations of any type of source, amount of sources and type of invocation. Composition primitives are recognized for evidence collection purposes. As we put it by the definition, unbounded requirements can be partially satisfied by gathering evidence. The way to gather the evidence is composition. Combining web services can provide added value to a software application that can itself become an independent service [80]. Composite sources are outsourced aggregates that yield added value [46]. Fundamentally, composition and refinement are two essentially opposite approaches. Combination of the two, attempts to strengthen the refinement process by using two practically inverse approaches. The evidence can be gathered from on-line, off-line and on-site sources or web services. There are four types of sources: information, service, al- gorithm and people. These types of sources should be used based on their suitability. The suitability should be determined with respect to the nature of an unbounded requirement. The source composition feature embedded prioritization of sources supported by modelling constructs. This is particu- larly important when the emphasis is given to availability, time of execution and source responsiveness. The fallback, sequential and concurrent operators manage prioritization and the way of invocation. Fallback means that the most left source is al- ways called first. The order of invocation is directed by the rule from left to right. The invocation operators can be combined in any way and can be used in combinations. The sequential operator instructs execution of tradi- tional invocation sequence. Sequence delineates runtime semantics when one source after another is being employed. The same rule from left to runtime semantics 42 right applies. The concurrent operator is to be used in case of invocation in parallel. This operator calls all sources at once. For the satisfaction and avail- ability purposes, this operator has a parametric function, which controls the minimum amount of responses. As all the aforementioned operators deal with multiple source it is necessary to tackle a composition that deals with bounded tasks. Bounded tasks can frequently occur in the complicated de- composition trees. To model a single source that is linked to a bounded task and therefore does not require more than one source no operator is used. Figure 3.11 show the graphical notations of the above operators. Moreover, as an invocation attempts to invoke third parties, we assume a timeout that is the maximal allowed time for an invocation to be finished.
The graphical notations of composition operators
Figure 3.11.: The sequence operator steer an invocation mech- anism. Sequence is a type of invocation that is done in a particular order insequential which sources operator linked to this operator are invoked one after another from left to right. A sequence operator must always be assigned to a task. Runtime semantics: When a sequential invocation starts the transitions are fired one by one. Technically, the initial transition invokes the first source in the sequence, when the source returns an answer the token is moved forward to another place. Then transition s2 invoke is activated. When s2 returns an answer the token moves on and go on until it has gone through an invocation cycle of all sources. When the token reaches P-end, the invocation is finished. When the token does not reach P-end within the timeout, the invocation is finished. For example, let us assume a sequence operator that is bounded to task t1 and connected to sources s1, s2 and s3, respectively. The execution starts with activating s1 and calling the first source from left to right. As soon as s1 has provided and an answer or timed out the next source is called, which is s2. As soon as s2 has provided an answer the next source is called. Which is s3. When s3 has provided an answer or timed out the process is finished. A Petri Net describing the sequential runtime semantics is shown in Fig- ure 3.12.
The runtime semantics of the Sequential operator
Figure 3.12.: The concurrent operator is a composition con- struct that describes a parallel invocation. Concurrency is a type of invo- cationconcurrent that commands operator to call all the sources joined with this operator at the same time. The concurrent operator features a parameter x that delim- runtime semantics 43 itates how many sources ought to provide an answer in order to achieve a satisfaction level. Runtime semantics: The invocation is started by the start transition that sends a token to n routes in parallel. Each route now represents an invoca- tion route for a source. Any time when a source provides an answer a return transition for the affected source is fired and stored in two places. Place P n+1 is storing tokens to make sure that the satisfactory number of sources have given a reply after a concrete timeout. The weight of the incoming arc to Timeout transition is always the x parameter. Place P n+2 stores tokens in case all sources will provide an answer before the timeout. If all sources re- ply before the timeout, there is no need to wait for the timeout and therefore the weight of the incoming arc to Epsilon transition is n. Furthermore, the Epsilon transition is able to be fired at the moment when the pre-condition is met. This allows to fire at the moment when the last source among all sources provides a reply as well. This aids to the overall performance so there is no need to wait until the timeout when all sources have succeeded. The final place P-end terminates a Petri Net at the moment of obtaining a token. Hence, it is not possible to fire both the Epsilon and Timeout tran- sitions at the same time. For example, let us assume a concurrent operator with parameter x that is bounded to task t1 and linked to sources s1, s2 and s3, respectively. The execution starts with activating t1 and calling all sources in parallel. As soon as x of the source will provide the answer after the timeout, the invocation is terminated. When all sources provide an an- swer before the timeout the invocation is immediately terminated by firing the Epsilon transition. A Petri Net describing the concurrency runtime semantics is shown in Figure 3.13.
The runtime semantics of the Concurrent operator
Figure 3.13.: The fallback operator is a special type of a composi- tion construct that drops off to the next source in a predetermined order if thefallback previous operator source was unable to provide an answer. The fallback operator continues the invocation until it gets precisely one answer. Runtime semantics: A fallback is invoked by running transition s1 invoke. This invokes the first source. When the first source is invoked transition s1 invoke releases from its input place a token to the output place. Provided that the first source has replied the invocation is terminated by firing s1 return. Transition s1 return then sends a token to the final state P-end and cease the invocation. Provided that the first source fails to reply the second source is called by running s1 fail. Then the second source is invoked by firing s2 invoke. If the second source replies s2 return is activated and the token will move to the final state. Provided that the second source has runtime semantics 44 failed to answer. The invocation moves to the next source by activating s2 fail. If this source answers, again, the invocation is terminated. If this is the last designed source that was unable to answer the invocation is terminated either way. For example, let us assume a fallback operator that is bounded to task t1 and linked to sources s1, s2 and s3, respectively. The execution starts with activating t1 and calling the first source from left to right. First, s1 is called. If s1 has provided an answer the invocation will terminate here. If the s1 call timed out the next source is called. That is s2 as the next in the order. As soon as s2 has provided an answer the invocation is terminated. If the s2 call timed out the next source is called. That is s3 as the next in the order. If s3 has provided an answer or timed out the process is finished. A Petri Net describing the fallback runtime semantics is shown in Figure 3.14.
The runtime semantics of the Fallback operator
The modellingFigure 3.14.: technique that we have proposed in this chapter will be demonstrated further in Chapter 4. In the following section we will explain refinement patterns that were built from lessons learned while modeling unbounded requirements by using this technique. 4
In this sectionPATTERNS we describe refinement patterns for the identification of ap- propriate solutions to unbounded requirements. These patterns contain as- is, to-be states and definition of the main pattern features. In this section we present various pattern forms based on the review of literature.
The idea of patterns originates in civil engineering. Christopher Alexander, 4.1theacknowledged pattern inventor forms of the pattern idea has described patterns as a relationship between three subjects, a context, a problem and a solution [81]. Jim Coplien explains a pattern by a problem and a general solution in a specific context. He argues that if we are able to understand the forces in a pattern then we understand the problem and the solution. Hence, the Coplien pattern form focuses on the forces [82]. There is a distinguishing element between patterns, best practices and processes. Processes are more formal compared to patterns, best practices are not detailed enough and patterns remain focused while relatively informal. Processes need to be strictly defined within an organization. Best practices can grow in scale over time significantly. For this reasons, patterns are required to be relevant, applicable and reliable [83]. “Each pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice” [84]. “The term pattern appeals to the replicated similarity in a design, and in particular to similarity that makes room for variability and customization in each of the elements” [85]. We perceive patterns as generic reusable solution to a recurring problem. We see patterns as solutions to a given context.
Patterns have adopted widely in software development, from architectural solutions to software design. [86] suggest to use sim- ilarpattern approach forms for the software analysis stage. Applying patterns to non- functional requirements can be beneficial since quality requirements are in- comparably more stable than functional requirements [86]. Security require- ments refinement patterns can increase effectiveness of the development process [87]. There have been many security patterns produced to tackle software design tasks, however these were not well incorporated with the requirements analysis phase [88]. The security patterns consist of four con- cepts:
• Context which is presented as domain property via and/or operator within the contextual goal-based framework.
• Problem which is presented in terms of the contextual goal-based framework as goals and soft goals.
• Force is modelled either as soft goals or domain assumptions as used in the contextual goal-based framework.
45 pattern forms 46 • Solution described as detailed actions and within the contextual goal- based framework modelled as tasks [88].
There are many different forms of patterns and many variations and adap- tations of pattern forms. The first and the most known pattern form is the Alexandrian form. This form consists of picture, context, problem, solution, diagram and at the end a paragraph with related atomic patterns which are part of the pattern language [84]. The GOF form is conceptually bigger and has greater granularity. The GOF form breaks up the pattern into several concepts such as: Intent, Motivation, Applicability, Structure, Participants, Collaborations, Consequences, Implementation, Sample Code, Known Uses, and Related Patterns [89]. The Portland form is a highly simplified pattern form describing the Problem, Therefore and the Solution. The Portland form is very brief and consist of only a few paragraphs [89]. Another short type of a pattern form is the Coplien form. The key elements are: Pattern Name, Context, Problem, Forces and Solution [90]. The Canonical form is a slight adaptation of the Coplien form with a few varying headings. For the sake of simplicity and comprehensibility we will use this form as a core. We will embellish this form with some extra concepts suitable for the refinement of unbounded requirements. The POSA form is an extensive structured form. The headings of the form are formulated as follows: summary, example, context, problem, solution, structure, dynamics, implementation, example resolved, variants, known uses, consequences, and see also [91].
In information and computing sci- ence there are many kind of patterns being used. Such as traditional soft- warepatterns development in information patterns [systems89], service oriented architecture design pat- terns [44], workflow patterns [76]and many others. The importance of pat- terns for refinement, analysis and building supporting rationale for non- functional requirements have been recognized [92]. By the definition, unbounded requirements can be partially satisfied by engaging various diverse sources. SOA patterns engage services in the de- sign architecture. We believe that SOA services and design can be reused in the refinement process of unbounded requirements. For instance, the functional decomposition pattern [44] refines capabilities into smaller parts which are then executed by various services. Workflow patterns describe a sequence in which a task needs to be executed as various inputs from differ- ent sources are required. The sources could be either people executing the task or other automated systems. The deferred choice pattern describes a sequence where there is a validation or a decision made by a source in order to determine the next flow of the sequence or to validate that the sequence has been executed properly [76]. A study by [93]argues that some require- ments may have an impact on numerous system structures. These type of requirements are cross-cutting aspects. Therefore, to support them, there is a necessity to access multiple classes of the system. By accessing multi- ple classes the software may become too difficult to understand, reuse and extend. The authors argue that the scattering and tangling makes object oriented software difficult to further upgrade. The authors propose com- position patterns to mitigate the scattering and tangling by separating the design of cross-cutting requirement [93]. After a literature review of diverse pattern forms, we adopted some of the concepts and created a hybrid form consisting of the following parts: discerning patterns 47 • Context - describes the circumstances that form the setting of an event. In essence, the context describes the fundamental environment and conditions that apply in a typical case.
• Problem - delineates a matter that needs to be dealt with. A pattern aims to solve a problem.
• Solution - is a well founded approach how to tackle the problem. The solution is based on recurrences in practice.
• Example - illustrates the three stated before by showing as-is and to-be states. The example shows a real requirement taken from practice.
Discerning patterns of unbounded requirements in the sample is described 4.2in this discerning section. We modeled patterns and analyzed all unbounded requirements that formed our sample. By analyzing these models the similarities among requirements, models were compared and generic solutions drawn. The generic solutions are preliminary models of patterns. As this approach can be considered biased we adopted two other ways of discerning patterns of unbounded requirements. One is to study existing patterns and enhance them chiefly for the applicability purposes. The other is to assign the at- tributes, that have been chosen by the review of literature in Section 2.4, to the identified requirements from Chapter 2. It is feasible to identify patterns based on combinations of most common attributes among the requirements that share certain properties. However, such a process has to be automated to preserve accuracy and correctness of the results. The second approach can become difficult to process due to the high number of possible com- binations. To calculate the number of possibilities we use binomial coef- ficient, where n is the total number of attributes and k is the number of possible attributes that may constitute a pattern. Using Formula 1 there are 16,483 candidate patterns. To facilitate the process of distinguishing pat- terns among 80 entities and their 13,000 interlacing edges, an experimental approach have been employed. This experimental approach is solely in- tended to aid pattern recognition and is not the subject of this research and evaluation. Consult AppendixC for the full details of this process.
As4.2.1 requirementsSocial Network are seen Analysis as social in Requirements entities [24]. Engineering In this spirit, social network analysis has been used in a variety of studies concerned with requirements engineering. Social network analysis is an approach for investigating social structures [94]. "Social network analysis is motivated by a structural intuition based on ties linking social actors" [95]. Social network analysis has been increasingly used in the academic and industry research [94]. Social network analysis has possibly gained its im- portance amid emergence of the internet [96, 97]. Moreover, the emergence of social network sites enabled acccess to rich sources of naturalistic behav- ior data [98]. In a study on security and privacy requirements i* agent ori- discerning patterns 48 ented modeling language was used to model relationships between various actors [99].
n n! (1) k!(n − k)! k=0 X
The4.2.2 i*Social framework Network has Analysis ability to model social relationships in requirements [64]. A social network analysis is employed in this research. The following steps have been taken to help discover potential groups of requirements: 1. Assigning attributes to requirements Requirements are treated as social entities that have relationships among themselves based on the assigned at- tributes. The sample size consisted of 80 possibly unbounded requirements that have been discovered by empirical screening of features request of var- ious application. We informed on the process of retrieving theses require- ments in Chapter 2. We inform on the process of assigning the attributes to requirements in AppendixC. 2. Run social network analysis To identify potential groups of socially bound requirements a social network analysis was executed. The relation- ships data from AppendixB were used.The aim of the social network anal- ysis is to provide insights in the structure of our sample. The network has an ability to show the strengths and relationships in the overall sample and among individual requirements. In the first analysis, attributes network analysis, attributes and requirements were used as nodes. Altogether, there were 94 nodes displayed, out of which 80 were requirements and 14 were attributes (See AppendixC). This analysis only demoed the significance of individual attributes. The results revealed the most important attributes. The size of a node signifies the number of incoming and outcoming edges. Hence, affirms the standing of an attribute among others. The modularity class (p=0.6) executed over the network divided the requirements based on the most common attribute in multiple groups. 3. Run clustering algorithm The network analysis displays the clusters based on attributes and therefore shows relationships among attributes and requirements. Clusters represent hypothetical social groups. Clusters are differentiated by colors. The number of groups discovered was 9. Show- ing that not every attribute has deserved its own group. The sociogram of attributes and requirements and their adjacent edges is visulized in Figure 4.1. 4. Removing attributes The second analysis, requirements network analysis, was run solely among requirements themselves. The second analysis re- quired manual labor to remove the attribute nodes. The requirements rela- tionship analysis consisted of 80 nodes, roughly 13,000 single weight edges that were recalculated into approximately 5,100 weighted edges. The weight of an edge states the number of attributes the two requirements had in com- mon. For example, if 18 requirements were assigned to availability, each of the requirements will have a direct relationship with each other. The more shared attributes the higher weight of the edge and smaller distance between two requirements in the network. Consequently, the higher prob- ability that the two requirements are closely akin and end up in the same cluster. 5. Run clustering algorithm The modularity class algorithm (p=0.75) re- sulted in dividing the network into 8 clusters of related requirements. discerning patterns 49
Clusters of requirements and attributes
Figure 4.1.: 6. Analyze requirements in the groups The groups of requirements re- vealed by the social network analysis were further analyzed. Each of the groups have a buzz word that delineates the functionality that is common for that group of requirements. As the resulting classification is built on the grounds of ascribing attributes to requirements, we refer to these groups as patterns. The patterns defined concentrate on 8 different aspects discovered by the social network analysis. Consult AppendixA to see requirements belonging to each group. To be specific we present these pattern groups in Table 4.1. These groups were further analyzed and refined in order to con- ceive meaningful patterns. The buzz word describes common functionality of the requirements belonging to a particular cluster. The most right col- umn shows a pattern that was fully defined and is shown in the following sections.
CLUSTER DETAILS Cluster Initial name Buzz word Pattern 0 Satisfactory "Get content" Completeness 1 Presenter "Determine suitability" Subjectivity 2 Observer "Do automatically" Detector 3 Pattern 3 Outlier None 4 Subjectivity "Determine subjectively" Subjectivity 5 Unsatisfactory "Add more content" Completeness 6 Detect "Filter out content" Separator 7 Subscriber "Notify me" Detector Cluster descriptions
Table 4.1.: atomic patterns 50
Requirements clusters identified by network analysis
Figure 4.2.: The sociogram of relationships among requirements is visualized in Fig- ure 4.2. Each node represents a requirement, there are no attributes shown as these were deleted. Similarly, as for attribute network analysis, clusters can be distinguished by different colors. The method to recognize the patterns follows the DSRM and the artifact creation loop shown in Sec. 1.2. Our patterns are divided into two groups: atomic and aspect patterns. Atomic patterns are simple blocks that can be combined and embed principles of source selection strategy. The aspect patterns are oriented on functional characteristics. They are divided into three groups - content patterns, content & suitability patterns and suitability patterns The following sections build on the pattern groups we discovered by applying the network analysis on the sample of requirements. Moreover, we demonstrate the capabilities of the modeling language from Chapter 3 by applying it to the patterns and examples.
This section introduces three basic patterns and their descriptions. They present4.3 atomic basic source patterns composition principles. These patterns are fundamen- tal in order to enhance some of the most important quality attributes of un- atomic patterns 51 bounded requirements such as correctness, credibility, reliability, time and availability.
• The Complementary source composition advises to use sources that supplement each other to provide better satisfaction levels. It shows how to achieve greater correctness by engaging more information types more sources are used [75]. Hence, each source type have specific in- formation and when combined they complement each other in terms of information quality. Furthermore, invoking sources in parallel con- tribute to lowered response time. Availability manifests itself in using different source types as a complementary solution is a mix of exter- nal and internal sources, where internal sources are more likely to be available. Composability is expressed by invoking all types of source - people, service, algorithm and information. Providing an operational and committable solution with all different types contribute to the abil- ity to remain aligned with other sources. As a consequence a better deployability of future sources can be achieved.
• The Alternative source composition advises to use multiple alterna- tive solutions to the same problem. This pattern shows how to model backups by using the fallback invocation and how to achieve higher response times by invoking sources in parallel. It mainly tackles reli- ability and availability which are expressed by designing redundant backup sources. Credibility is tackled by using prioritization of the most renown sources as for the fallback solution.
• The Crowdsourcer uses crowdworkers to fulfill a requirement in case there is no algorithmic way to do so. This pattern introduces peo- ple as an entity that can undertake tasks similar to algorithms in an intelligent way. It showcases credibility in two different aspects - trust- worthiness and expertise. These are expressed by engaging people who in general have subjective opinions but often based on rational choices. Also, it exhibits responsiveness in the use of the concurrent operator, when calling crowdworkers. Only the fastest crowdworkers get engaged. atomic patterns 52
How4.3.1 toComplementary achieve a maximal Source level ofComposition completeness and credibility?
Context A requirement necessitates a high level of completeness and cred- ibility. A broad spectrum of information, knowledge or skills has to be covered.
Problem Retrieving information from a single source limits the satisfaction. How to supply high completeness?
Solution Employing sources that hold nonsimilar information. Nonsimi- larity is achieved by using diverse source types. Diverse source types con- tribute to higher completeness, credibility and satisfaction levels of the re- sults. Use a concurrent composition operator with the parameter x slightly smaller than n to provide high completeness of information, knowledge and skills.
Example
The complementariness is ex- pressed by using different types of sources such as the uploader of the song who can provide his opinion on the song, the user of the system who has the ability to validate if the song bothers him in terms of explicit content, consulting a dictionary can be a fast solution to find vulgarisms, a list of explicit songs from ex- plicitsongs.com can easily deter- mine if it is in the database of explicit songs, etc. Each source aims to fulfill the gaps that the other source may miss out. atomic patterns 53
How4.3.2 toAlternative increase reliability Source of Composition the designed solution?
Context An unbounded requirement consists of refined parts that can be partially satisfied by one source or require a source that is critical and has to provide an answer by any means. The likelihood of the designed source to fail is aimed to be diminished. The pattern is useful when it is necessary to employ a source that is critical in order to meet the requirement.
Problem Dependency on a single source may result in reduced reliability. A single source introduces a potential single point of failure. The single point of failure may become critical and jeopardize the reliability and availability.
Solution Insure the single source with other similar alternative sources of a same type. The sources have to be prioritized based on their credibility. There are two options how to apply this pattern. One using a fallback op- erator by the rule the highest priority first. The other one using alternatives with a concurrent operator and its parameter x being a much smaller num- ber than n increases the response time and availability, while reliability is emphasized.
Example
Two back-up sources are mod- eled - Gigbeat and onTour. The primary source is Songkick. Pri- oritization is organized in this order - Songkick, Gigbeat and onTour. This prioritization ex- presses the credibility of the sources. The most credible source is Songkick, followed by Gigbeat and onTour. Allowing for concurrency among alternatives leads to increased availability and re- sponsiveness as only a reply from the fastest source will be considered. Consequently, reliability is embedded in the concurrent parameter where only 1 out of 3 has to reply. atomic patterns 54
How4.3.3 toCrowdsourcer refine requirements that require human judgement, understanding or cre- ativity?
Context An algorithmic solution is insufficient in terms of the results it offers. This pattern aims to solve intelligent requirements that are very challenging for the current technology. The possible algorithmic solutions are curbed by technological constraints. Therefore, they yield disappointing outcomes. Intelligent capabilities intended to be algorithmized are peculiar to human beings. These could be demands such as determining suitability, asking for advice, suggestion, opinion, etc.
Problem Algorithms fail when trying to compute socially related matters such as suitability, advisory, suggestions, etc. This is caused due to the fact that they lack the understanding of a broader context and intelligence.
Solution To deliver personalization, socially knowledgeable entities such as humans have to be engaged. Inclusion of crowdworkers and crowdsourcing platforms in the computing algorithm is a way of treating these type of requirements. Crowdworkers should be treated as an intelligent computing capacity that possess subjective, emotional and rational knowledge.
Example A job is posted on a crowdsourcing platfrom and crowdworkers get engaged to fulfill tasks. Availability and responsiveness are underlined. content related patterns 55 In the following sections, patterns for refinement of unbounded require- ments are explained from the functional perspective. These patterns show different solutions to unbounded requirements. The context either describes the former implementations or what the desired functionality is, expressed in the form of a requirement. When the context conditions hold then the pat- tern may be applied. Actors in the context visualization show, what is the state of the requirement and what are the social interactions in the context. The context does not provide a way how to resolve the problem. The prob- lem then states what obstacles has to be overcome. The solution describes how to get from the context through the problem to the satisfaction of the requirement. The difference between the actor in the context and the source in the solution is that the actor is visualized to show social interactions only, whereas the source shows the solution and how the source participates in the solution.
While several types of unbounded requirements exist, they share two funda- 4.4mental content characteristics related - the inherent patterns segmentation of satisfaction due to in- formation/knowledge fragmentation and inability to be fully satisfied. The information fragmentation is caused by partitioning as the information is not easily accessible and available at a single information source [27]. All unbounded requirements are sharing these two qualities. Without having to fall into one of these categories, such requirement cannot be classified as unbounded. In this section two content related patterns are introduced - the Com- pleteness pattern and the Scraper pattern. These patterns target unbounded requirements related solely to content completeness. There is no subjective element involved. The reasons why content related unbounded requirements cannot be fully satisfied can be various, such as non-existent infrastructure, inaccessible, no digitalized form, unlimited amount of sources, rapidly changing ecosys- tems, creation of new sources, continuous and constant knowledge creation, innovation, ever-changing technology, etc. If an unbounded requirement does not have qualities such as dynam- ics, subjectivity, uncertainty, intelligence or ungeneralizability. Such require- ment falls under the Completeness pattern. These types of requirements are mostly just plain and the unboundedness is described only as a desire for the information completeness. The Completeness pattern is intended to solve mainly unbounded impractical requirements. The Scraper pattern essentially describes modern website scrapers. The Scraper pattern aims to refine requirements that are ungeneralizable, dy- namic and impractical at the same time. Given the fact, scraping is a tailor made software for every entity that has to be scraped, it is hard to generalize rules which would be able to scrape any source. The reasons for complexity are various. Mostly due to the fact that the layout and format of the content are not fixed variables. They vary from source to source. content related patterns 56
How4.4.1 toCompleteness retrieve missing, Pattern hard to obtain or inaccessible information?
Context It is required to supplement the present pool of information by auxiliary sources of information. A requirement points out that present implementation is either unsatisfactory or the user requires more detailed information. However, the required information does not exist in a digital form, does not have an existent infrastructure, is fragmented over multiple storages, materials, entities, documents, etc. Therefore, these type of re- quirements are predominantly impractical to compute as they keep chang- ing continuously.
Problem How to assure that ample information is provided. Refactoring the original implementation only to internal sources such as internal database or processing algorithm may reduce the correctness of the outcome and deployability of external sources.
Solution Introducing new information rich external sources may deliver the greater correctness. Enrich the current implementation by adding more source leaves. There two possible options how to apply this pattern - using a sequential operator or using a concurrent operator with x being slightly smaller than n. 57 Example content related patterns
• Provide complete TV-shows database. • Access to all existing song in the world. • Display the original song artist.
Context
Solution
A more complete database of TV-shows can be achieved by introducing addi- tional services to the former implementation. Using concurrent operator we can combine various TV-show producers rather than limit the solution only to the convenient once. Multiple complementary sources are introduced to provide greater completeness of information. In this solution users are al- lowed to upload TV-shows they downloaded manually and contribute to the pool of information. Next, various torrent sites are used to provide even more TV-shows. content related patterns 58
How4.4.2 toScraper scrape unstructured information sources?
Context Required information is available in an unstructured non-digitalized or digitalized form and needs to be further manipulated in order to be stored in a form of structured data. The required data is available from a number of different sources and formats. Frequently, the data sources belong to the information source type. The input of this functionality is a physical entity such as business cards, books, documents, covers, etc. or un- structured freely available data such as websites, blogs, rich texts, etc. These requirements are ungeneralizable and dynamic due to the high number of possible inputs.
Problem The quantity of possibly scraped formats in which the entities can be found is vast, resulting in reduced availability and response time. It is difficult to set generic rules that are well established for all sources and formats.
Solution Set valid prioritization of the most common sources, formats and layouts. Availability and response time can be tackled by engaging crowd- workers into the computing algorithm when the algorithmic part of the so- lution fails. 59 Example content related patterns
• Business card snapshot to be transformed into structured data. • Ability to retrieve contacts from any website. • Email signatures should be stored in the database.
Context
Solution
Contact details from different types of business cards are required to be stored in the database in a structured form. The solution engages people as computing units in order to structure data that is being retrieved as unstruc- tured and the present algorithms are unable of doing so. content & suitability related patterns 60
In this section two cross-cutting patterns are presented. These patterns in- 4.5terrelate content content and suitability & suitability focused requirements. related These patterns patterns point out a recognition functionality that interacts with content and suitability to the user at the same time. The core of these patterns is to observe events and execute a pre-programmed action when an event occurs. The action can be executed either automatically or semi-automatically. Semi-automatically is a means for requiring other than pre-programmed input. For instance, a user input. The unboundedness of these patterns lies in its dynamics and varying inputs and outputs. The varying inputs necessary to execute an al- gorithm can often be of subjective nature and therefore an individual query needs to be created automatically. This category aspires to extract wanted or unwanted fragments either from a stream of information or a relatively stable set of data. These patterns detect, recognize, observe and monitor multiple indepen- dent parties. The independent parties that are being observed are the source of unboundedness. An algorithmic solution that would be able to perform these actions with any transmitter of information is unlikely to be general- izable. These patterns are described by a buzz word "do automatically". Con- sidering the present, the user requirements and the technology, users will impose more and more sophisticated requirements on software as software itself has been becoming more sophisticated. The goal of this group of pat- terns is to observe and consequently perform an action independently either with user approval or without it. Particularly, observing of phenomenons in a context. Often, the context is a changing element that can easily become outdated. These patterns are focused on dynamic, uncertain, subjective and ungeneralizable requirements. The Detector pattern observes states of entities. If an event is spotted an action is to be performed. Possible actions vary, such as highlight, disable, protect, release, warn, allow, amend, etc. The Separator pattern is concerned with content and attempts to omit any unwanted or wanted entities. The requirements belonging to this pattern may require full automation or can be activated manually. This pattern does not address individual queries. The subjective factor is suppressed. It deals with generic filtering of the content. The Separator pattern is intended to be applied on large scale systems where large amounts of data have to be manipulated. content & suitability related patterns 61
How4.5.1 toDetector detect an uncertain event?
Context A couple of information streams is being observed for an event to occur, which makes these requirements dynamic. The event that is being monitored is meant to be a data object, an object of attributes or any piece of information. The desired event should be recognized out of various inputs. Requirement asks to detect something.
Problem As the inputs and outputs are varying it is very unlikely that the solution will not be altered over a course of time. This may negatively affect stability. Likewise, the reliability is challenged due to uncertainty of the inputs and outputs.
Solution A mix of relevant sources shall be used to spot that the event has occurred. When the event is detected the requirement is satisfied. 62 Example content & suitability related patterns
• Release warning when accessing a harmful website. • Mechanism to propose best fitting torrents to the user when the num- ber of seeders is insufficient. • Disabling shortcut functionalities while playing a game in the browser.
Context
Solution
The main task of the solution is to react by releasing a warning when a harmful website is detected. There are two possible events to be detected - worms and malware. To aid detection of these undesired events internal plu- gins are being constantly engaged. However, another third party antivirus software is engaged to supply more reliable solution. content & suitability related patterns 63
How4.5.2 toSeparator omit unsuitable data?
Context These requirements describe a state where unsuitable entities are expected to be taken out. For instance, pictures, text, audio, video, and so on. The content itself is hard to be identified and is likely to be embedded in the data object. For this reason, these requirements are ungeneralizable. The content that needs to be filtered out is non-personal and there is a contextual consensus on its meaning and suitability.
Problem How to assure the solution to be reliable and accurate in filtering out the unwanted content.
Solution Set generic rules that are fed by other sources in order to identify the undesired content. The system’s content serves as an input where the Filter task is a separator that provides the output. Variety of atomic patterns may be used. Where algorithm, information and service fail to provide value engage people as sources. Any invocation operator can be used. 64 Example content & suitability related patterns • Filter out explicit songs. • Ability to get rid of swearing and online dating. • Filter out negative comments and cussing.
Context
Solution
In this example the user requires to omit explicit songs and show only non- explicit art work. First, the algorithm that is able to detect explicit song is engaged. Then a third party service that consist of explicit songs and com- pares the content against its database. After that crowdsourcing is activated to find out if there are any explicit songs, album covers, titles, etc. suitability related patterns 65
This section shows a subjectivity pattern that deals with subjective unbounded 4.6requirements. suitability Unbounded related subjective requirements patterns entail the need for a cus- tomizable solution. Implementing unbounded requirements that are sub- jective necessitate a high-level generic solution, which allow to instantly determine a tailor-made output for every user. Given the fact, there can be countless amount of users, we surmise there can be countless amount of solution to a single unbounded subjective requirement. The pattern in this section take on the issue of well suited solutions for a crowd of individuals. The subjectivity pattern is a fundamental constituent in refining unbounded subjective requirements. Likewise for other groups of patterns, unbounded subjective requirements can be of a cross type - subjective and dynamic, sub- jective and ungeneralizable, subjective and uncertain, etc. Consequently, the subjectivity pattern can be found as a component in other patterns described in this research. From practice and by analyzing existing implementation of originally unbounded requirements we can see the user-oriented approach. Specifically, oriented on the user data and behavior. Much of the subjective satisfaction originates in the user data, as users are very likely to be engaged in other than the concerned system. It is worth it to investigate the other systems and capture relevant information from these sources to better ful- fill the requirement. The user orientation and the definition of this pattern might have to do with inclusion of social-interactive systems in this study. Provided that the multisourcing approach for the sake of expanding in- formation retrieval is used, the partiality of subjective satisfaction can be gradually diminished. While introducing integrations with any other soft- ware system can at first sight seem as a basic marketing move, intent such as gathering information about users is far more crucial. The information gathering and composability is of a big importance in knitting subjective solutions to unbounded requirements. suitability related patterns 66
How4.6.1 toSubjectivity refine a requirement pattern which has to be tailored for every user individually?
Context Requirements belonging to this pattern suggest to determine per- sonal suitability, suggest a list, collection, catalogue, menu of information, etc. The unboundedness of these requirements can be categorized as subjec- tive. Current software solutions offer a generic solution to personal queries, consults only internal database or use a random function to generate sug- gestions. Solution partitioning is an integral part of the functionality that has been outlined.
Problem How to refine the impersonal generic solution into a personal so- lution. Subjective results decrease correctness. Ensuring the stability and correctness of the outcomes.
Solution Offer a personal solution for every user to increase trustworthiness and and overall credibility. User data and preferences serve as an input variable. Validating the outcomes by the user is highly recommended by refining the requirement in a way that the user is used as a source. 67 Example suitability related patterns
• Discover function: suggest relevant songs a user has not listened to. • Implement additional suitable movie rating systems. • Suggest social media contacts to follow.
Context
Solution
The solution describes how to treat a requirement based on subjectivity. User data and history are used to provide possibly suitable songs to a user of Spotify. Other than determining suitable song algorithmically with a ran- dom function, three other services concerned with discovering similar songs can be implemented. The user of the application has the power to determine himself if he finds a song similar or not. To provide a satisfactory outcome 4 sources have to reply to assure correctness. summary of patterns 68
To sum up the patterns, an overview of different unboundedness types and properties4.7 summary addressed by of individual patterns pattern are presented in Tables 4.4, 4.2 & 4.3. Complementary source composition is a basic pattern that can address any types of unboundedness. It is particularly useful when addressing so called impractical requirements. It tries to enhance correctness and credibil- ity by using multiple different types of sources. Alternative source compo- sition may be applied on any unboundedness type and confirms its funda- mental position among other patterns. It addresses reliability as it advises to use backup sources. The use of the fallback operator emphasizes credibil- ity and the use of the concurrent operator emphasizes availability and time. The Crowdsourcer advises to engage people, and hence logically addresses subjective and ungeneralizbale requirements. It tries to tackle response time and the correctness of the results that are either determined or validated by people. The response time is addressed by engaging people through the parallel invocation. The Completeness pattern shows how to achieve better completeness of the results. Completeness is expressed as part of correctness. Deployability is addressed by enriching the former implementation with additional feeds. The Scraper pattern addresses availability and time by engaging the parts of the Crowdsourcer pattern. Reliability and correctness are established as accurate content is aimed to be achieved. Detector works with uncertain and dynamic content, and therefore the stability of the solution has to be prevented by using both internal and external sources. Reliability is manifested in the form of observation of various entities and in the form of overall functionality to detect something. The Separator pattern is useful for requirements that can be ungeneralizable and are hard to be detected. This pattern makes use of crowdsourcing and establishes reliability and correctness by engaging people and various types of sources. Lastly, the Subjectivity pattern advises to use the user of the sys- tem and by this means showcases the correctness. Reliability is addressed by using the complementary sources. Stability is expressed in terms of the overall solution since for every user the inputs and the outputs differ based on his unique choices. Table 4.2 shows which quality attributes are addressed by which atomic patterns. It clearly shows that some of the quality attributes are more impor- tant than the others. Credibility, correctness and reliability are mentioned in the patterns the most. However, availability, credibility and cost are con- sidered to be one of the most important quality attributes of unbounded requirements [16].
Complementary Alternative Crowdsourcer AAVL x ADPL ASTB ARLB x ACRC x x ACRD x x ATME x x Mapping of atomic patterns on attributes
Table 4.2.: summary of patterns 69 Each of the patterns in Table 4.3 addressed specific combinations of qual- ity attributes. None of the patterns is a subset of another pattern. A pattern has a unique combination of quality attributes that it aims to solve.
Completeness Scraper Detector Separator Subjectivity AAVL x ADPL x ASTB x x ARLB x x x ACRC x x x x ACRD x ATME x Mapping of aspect patterns on attributes
Different unboundednessTable 4.3.: types can be addressed by different patterns. Table 4.4 shows which unboundedness types are predominantly addressed by which pattern. The intelligent unboundedness type turns out not to be used as often as defined by study of [16]. There is no clear pattern for this type of unboundedness. Furthermore, the intelligent unbounded requirements might be broken down into subjective, ungenarlizable and ucertain types of requirements. The atomic patterns are suitable for any type of unboundedness.
Uncertain Intelligent Impractical Complementary x x x Alternative x x x Crowdsourcer x x x Completeness x Scraper x Detector x Separator Subjectivity Ungeneralizable Dynamic Subjective Complementary x x x Alternative x x x Crowdsourcer x x x Completeness Scraper x x Detector x Separator x Subjectivity x Mapping of patterns on the unboundedness types
Table 4.4.: 5
EVALUATION
Nonexperimental research was performed to evaluate the applicability of 5.1the patterns.pattern The patterns validation have been validated by nonexperimental ap- proach on a set of unbounded requirements. The validation of patterns is a long-term process which might take a few years [22]. The process of evaluation of patterns in business analysis has four different stages: assess- ment of patterns by experts, evaluation by the pattern users, organizational case study and measurement using score-cards [22]. Due to the time scope of this project we carried out internal validation. We employed a qualitative research. Qualitative research is a type of nonexperimental research. The qualitative research generally consists of large amount of data from a small amount of participants and explains their data using nonstatistical methods. [100]. The sample that was used to evaluate the patterns consisted of 36 un- bounded requirements. We tested the applicability of the patterns for the refinement of an unbounded requirement. The lessons learned and per- centages of how well the patterns were fitting with requirements present in this sample are reported in this section. Furthermore, the applications in- cluded in the sample were Nimble (8), PopcornTime (22) and Salesforce (6). These requirements were withdrawn from the process of defining patterns. These requirements were only used to validate the patterns. Requirements retrieved for Salesforce were solely used for the evaluation purposes. There were no Salesforce requirements used for the definition of the patterns. We qualitatively summarize the outcomes of the pattern application and report on the experience of applying them on unbounded requirements.
The5.1.1 firstScoping activity of our nonexperimental approach is scoping. We define the object of study, purpose, quality focus, perspective and context. We make use of the goal template [101] to present the scope of the internal validation:
Analyze the patterns for refinement of unbounded requirements for the purpose of evaluation with respect to its applicability from the point of view of the researcher in the context of requirements engineering
The5.1.2 useAtomic of atomic pattern patterns was demonstrated on numerous examples (please consult AppendixE). They are intended to be the basic building blocks of source composition. They have been used in almost every example mod-
70 pattern validation 71 elled to validate these patterns. The atomic patterns represent basic princi- ples of source composition and in all cases they are being used on the level of sources. The frequent use has to do with the embedding of these princi- ples in the form of patterns. There could be various combinations of source composition added and enrich the source design principles.
Within5.1.3 Completeness the testing sample pattern the completeness pattern covered 17 cases which accounted for 47% of all requirements in the testing sample. The complete- ness pattern have often used the alternative composition pattern, crowd- sourcer and the complementary composition pattern. These were used mostly due to the fact that the completeness pattern embodies the mul- tisourcing principle. The completeness pattern can be confused with the complementary source composition pattern. The complementary source composition is a basic building block, whereas the completeness pattern addresses the particular issue of a requirement. The completeness pattern was used in cases when other patterns were not suitable or the requirement was merely asking for the completeness of the data.
The5.1.4 scraperScraper pattern was applied on two cases, both requirements on which this pattern was applied were identified for Nimble. The context, problem and solution described these two requirements very well. The model de- scribing the solution, however, did not fully capture the bottom line. The scraper pattern was very easy to apply without much further modeling. The reason why this pattern is easily to be applied could be possibly ascribed to the very specific functionality this pattern solves. This pattern covered roughly 6% of the cases from the testing sample.
The5.1.5 detectorDetector pattern was applied on 4 cases. The cases described always asked for an additional action such as notify and release warning. The core of the requirement was modelled easily. The detector pattern is missing a branch of the additional action that has to be executed when something is detected. This patterns is not so much oriented on the solution rather just models relationships between modules. The main problem with the require- ments this pattern aims to solve is the process of the detection. For each requirement this will be a different process. This is not fully captured in the Detector pattern and therefore makes this pattern unclear and very generic. Within the testing sample, this pattern was applied on approximately 11% of the requirements from which the sample consisted.
5.1.6Similarly,Separator as the Scraper the Separator pattern seems to be used in very specific cases. This pattern has been applied on two cases only. Overall, that accounts for almost 6% of the cases. This pattern can be very easily and elegantly applied as there are not so many modeling constructs added to the solution proposed by the pattern. When applying this pattern the pattern validation 72 user does not have to think deeply how to model inputs and outputs as this pattern clearly states that some unwanted content has to be taken out.
The5.1.7 SeparatorSubjectivity pattern was applied on 4 cases that accounted for roughly 11%. This pattern is seen to be useful on requirements that are subjec- tive as the name of the pattern describes. The name of the pattern is very snappy which makes this pattern easily matchable with the right require- ments. From the application of the pattern we can see that the most changes to the original solution proposed by the pattern are made to the sources and occasionally the main task is broken down into smaller subtasks. Other than that this pattern did not show any alterations to the dependencies, resources or actors.
5.1.8Interestingly,Lessons we learned were able to apply the patterns on 5 out of 6 Salesforce re- quirements. Salesforce requirements were not used for the definition of the patterns at all. The patterns used for Salesforce requirements were Detector, Seprator and Completeness. Furthermore, when none of the patterns fits a requirement the complete- ness pattern serves as a universal pattern to enrich the completeness of the data that are described by the requirement. There were 3 requirements on which we could not apply any pattern, 2 of them were identified for Nimble and one for PopcornTime. There were 4 requirements when it was not clear which pattern to use. It could be either that the requirement was cross-cutting multiple patterns or the pattern was not fully capturing the bottom line of the requirement. The patterns make the modeling of the requirements very easy on a high level. By using the patterns it is very easy and time efficient to model a requirement as different constructs do not have to be added. This can be particularly important when there is a lot of requirements being elicited. Unbounded requirement can be very rare and therefore it is at question how useful these patterns can be in terms of the frequency of their use. For every application there seem to be domain specific unbounded re- quirements. We paid attention to this observation in Chapter 2. Patterns bring an elegant and easy way how to refine unbounded requirements. Us- ing the patterns can support the knowledge reuse from other requirements that have already been refined. As mentioned in Chapter 2 each application has some domain specific unbounded requirements. It might be worth to consider patterns for various types of organizations when there are recur- ring requirements. If we look at the overall coverage of the testing sample by patterns, we can see that the Completeness pattern covered approximately 47% of cases. By adding two more patterns, namley the Detector and the Subjectivity pattern, we covered 22% more requirements from which the testing sample consisted. Next, the Separator and the Scraper pattern added to the overall coverage of the testing sample almost 11%. We could follow the process of adding more and more patterns for very specific cases. However, this would not be feasible as the occurrence of such possible requirements that could have been addressed by the defined patterns would be very small. Overall, 80% of cases are addressed by 5 aspect patterns. The use of pattern for individual expert interviews 73 applications are shown in Table 5.1. The percentages on how many cases which pattern has been applied are shown in Table 5.2. Table 5.3 shows percentages to what extent we were able to model requirement using the patterns for individual applications.
Nimble Salesforce PopcornTime Total Completeness 2 3 12 17 Scraper 2 0 0 2 Detector 2 1 1 4 Separator 0 0 2 2 Subjectivity 0 1 3 4 None 2 1 4 7 Total 8 6 22 36 Pattern application data
Table 5.1.: Nimble Salesforce PopcornTime Total Completeness 5.6% 8.3% 33.3% 47.2% Scraper 5.6% 0% 0% 5.6% Detector 5.6% 2.8% 2.8% 11.1% Separator 0% 0% 5.6% 5.6% Subjectivity 0% 2.8% 8.3% 11.1% None 5.6% 2.8% 11.1% 19.4% Total 22.2% 16.7% 61.1% 100% Percentages on pattern application
Table 5.2.: Nimble Salesforce PopcornTime Total Refined with patterns 75% 83.3% 81.8% 80.6% Not refined with patterns 25% 16.7% 18.2% 19.4% Overall applicability of the patterns for individual applications
TheTable full 5.3.: list of testing requirements and how we applied patterns on them can be found in AppendixE.
The objective of these interviews is to evaluate the applicability and use- 5.2fulness expert of the proposed interviews modeling technique and the notion of unbounded requirements. Five experts from 3 companies were interviewed. The par- ticipants were either project managers or business analysts. Altogether, 2 project managers and 3 business analysts were interviewed. The subjects were chosen based on differences as suggested by [102]. The first project manager was invited to retrieve an overall management point of view. This expert is not greatly involved in requirements engi- neering. The second expert was included due to her management role in requirements engineering. She represents a management point of view within requirements engineering. The third expert is a project manager and is actively involved in requirements engineering. This expert represent a cross-cutting perspective between project management and business analy- sis. Expert 4 works in agile environment and therefore provides a view from expert interviews 74 the agile development perspective. Lastly, Expert 5 has vast experience in business analysis. [103] suggests that sufficient amount of interviews was conducted when a saturation point was reached. After the fifth interview we reached the point of saturation when no new comments were added. We conducted semi-structured informal face-to-face interviews. The ques- tions were planned in advance. On the interview there were powerpoint slides presented to the interviewee. The presentation consisted of two parts - unbounded requirements and the modeling technique. First, the part about unbounded requirements was presented. Subsequently, open ques- tions about unbounded requirements followed. Next, the second part about the modeling technique was presented to explain the constructs and logic behind the modeling. After the explanation open questions were asked. The questions were focused on the applicability and usefulness. The interviews were conducted informally to compel the interviewees to express their real thoughts and opinions on the subject and avoid the confirmation bias. Dur- ing the interviews, the following questions had been asked: Unbounded Requirements
• Have you ever encountered an unbounded requirement? • Can you provide an example of such an unbounded requirement? • How important is it for you/your company to take unbounded re- quirements into account to deliver better products? - Is it worth to address unbounded requirements? - How do you perceive unbounded requirements in terms of im- plementation? - Can unbounded requirements provide added value to your prod- ucts? • Would you put an unbounded requirement on your product backlog? - How would you proceed in refining and implementing such an unbounded requirement? - How did you proceed with regards to the example of unbounded requirement you provided?
Modeling technique
• Do you find the modelling technique useful? - Can this modeling technique help to refine unbounded require- ments? - Could this modeling technique be applied on other than un- bounded requirements? • To what extent do you find this modeling technique applicable? - What are the strengths of this modeling technique? - What are the weaknesses of this modelling technique? - What are the obstacles in applying it? • Assuming you are going to deal with unbounded requirements would you use this modeling technique? - What is the main reason why you would/wouldn’t use it? • Would you adopt this modeling technique in your company/day-to- day practice? - Can you assess how long would it take for your company to adopt it? - How complicated in terms of understanding do you find this modeling technique? 75 No Role Company Countryexpert interviewsExperience Expert 1 Project manager Datalan Slovakia 17 years Expert 2 Senior BA Bookmaker UK 10 years Expert 3 Project manager Javra Software Netherlands 10 years Expert 4 Business analyst Bookmaker UK 25 years Expert 5 Business analyst Bookmaker UK 10 years Expert overview
Table 5.4.:
5.2.1ExpertExpert1 is a project 1 manager at Datalan. He has worked as a project man- ager for over 17 years and has vast experience in the IT industry. Datalan is a software developement company that specifies on IT infrastructure solu- tions, their major clients are represented by the Slovak government bodies. This expert is not actively involved in business analysis rather has a high- level knowledge of business analysis for the projects he works on. Have you ever encountered an unbounded requirement? The expert in- dicated they have come across unbounded requirements and they have im- plemented this requirement algorithmically. By creating various functional modules they were able to capture the majority of scenarios. Can you provide an example of such an unbounded requirement? There was one potentially unbounded requirement mentioned by the expert. Each municipality is issuing their own directives, fees and templates for automat- ically created documents for residents. These are different for each munici- pal unit. Even though there is a final set of 138 municipalities, however, the directives, fees and documents being created can be considered unbounded as they keep changing all the time. Regarding the example provided, they created as many modules in the system as possible when they could fit in the budget and implemented the most general ones to cover the most of the cases. How important is it for you/your company to take unbounded require- ments into account to deliver better products? The perceived value of unbounded requirements is cost-oriented. The following chart was drawn by the expert. The chart shows how unbounded requirements should be addressed and that is also the approach how they dealt with the example he provided. The slope of the line is changing for each case so each unbounded require- ment will be treated differently. The cost of additional implementation to provide a higher satisfaction of unbounded requirements can be increasing immensely. It is important to consider cost effectiveness when implementing unbounded requirements. It is not effective to implement a functional module that is ex- tremely expensive when it increases the satisfaction level by a small amount. In general, it is hard to say if unbounded requirements have any added value, it depends on the case. Would you put an unbounded requirement on your product backlog? The example provided is being implemented at the moment and all exceptions are covered by hard-coded functional modules. In the example they fol- lowed the cost-oriented approach. Within their software project they were able to cover 90% of municipalities. Do you find the modelling technique useful? The expert has expressed himself that it is hard to evaluate a modeling technique that has just been expert interviews 76
Cost-oriented approach to unbounded requirements
Figure 5.1.: presented. This technique is not directly intended for unbounded require- ments as this type of modeling should be performed for every requirement. This modeling describes how the system should function and it is a classical modeling language. To what extent do you find this modeling technique applicable? The weak- ness of the modeling technique is that it is nothing novel and this type of modeling tools already exist. Moreover, it is hard to express the strengths when it is seen for the first time. In the experts opinion unbounded require- ment is no different from a standard requirement as both types have to be modelled and implemented eventually. The logic of unbounded requirement lies in the fact how many cases are you able to cover and how effectively can you satisfy this requirement. The certain fact is that you cannot satisfy an unbounded requirement for 100%. The expert stated that each unbounded requirement is becoming bounded when being refined and implemented because there has to be a budget, time scope and milestone exactly as it is for a standard requirement. An unbounded requirement has to have a start and an end when being imple- mented. Assuming you are going to deal with unbounded requirements would you use this modeling technique? The expert do not see clear advantages and reasons why this modeling technique should be used and not some other. The weakness in using of this modeling language is that it is unknown and it is not used by other teams within the organization. It is necessary to use standard modeling tools that are understood by all teams engaged in the development. Would you adopt this modeling technique in your company/day-to-day practice? According to the expert this modeling technique would not be easily adopted as it does not make much sense to replace a modeling tool for another tool. Eventually an unbounded requirement has to be trans- formed to a bounded requirement. The expert was unable to assess how complicated the language is as he is not an active user of a modeling tool. Lessons Learned:
• Unbounded requirements cannot be satisfied for 100% expert interviews 77 • Unbounded requirements are becoming bounded when being refined and implemented
• The approach how should one address unbounded requirements is cost-oriented and cost-effectiveness should be taken into account
• The main weakness of the modeling language is that it has not become a standard and it is not broadly accepted
5.2.2ExpertExpert2 is a senior 2 business analyst at a bookmaker. She has worked as a business analyst for over 10 years and manages a team of business analysts to deliver better betting service and products. This bookmaker is active on the British, Irish and Belgian market. The company is active on the global online betting market as well. Have you ever encountered an unbounded requirement? The initial re- action of the expert was no. As the expert looked at the examples of un- bounded requirement she was able to provide an example of an unbounded requirement. The examples provided uncovered this area of requirements for this expert. Can you provide an example of such an unbounded requirement? One po- tentially unbounded requirement mentioned by the expert is the area who could potentially access the company website that integrates various sys- tems and has various levels of systems integrated. According to the expert it is hard to capture every possible scenario for unbounded requirements. How important is it for you/your company to take unbounded require- ments into account to deliver better products? The expert had not been aware of these type of requirements. For that reason, they do not really take these requirements into account. It is worth to address unbounded require- ment because by addressing them you might be able to uncover different criteria to satisfy that requirement. According to the expert unbounded re- quirements are very hard to be implemented. The added value is at question as you cannot have an unbounded requirement open for an unlimited time. Would you put an unbounded requirement on your product backlog? The expert does not work in agile therefore was unable to answer this question. Hypothetically, even if there is an unbounded requirement and it is impor- tant for the business they would do the best they could even though they would not be able to satisfy it for 100% and the rest would be put on the backlog. In terms of refinement of an unbounded requirement, such a re- quirement should be broken down to as many scenarios as possible that could satisfy it and in terms of implementing the following was expressed: "as best as you can". Do you find the modelling technique useful? The expert has not expressed an opinion what this modeling technique can be used for. However, the expert expressed that the technique could be useful for not only unbounded requirements but any kind of requirement. To what extent do you find this modeling technique applicable? The ex- pert was hesitant in answering the question and did not see anything par- ticular that is missing in this modeling technique. Also, the expert uses no modeling technique to model and refine unbounded requirements. Assuming you are going to deal with unbounded requirements would you use this modeling technique? The expert did not see a reason why expert interviews 78 not to use it but she is not a user of any modeling technique. It is hard to express an opinion on a modeling technique that is seen for the first time. Would you adopt this modeling technique in your company/day-to-day practice? According to the expert this modeling technique seems to be slightly complicated for day-to-day use. Once the modeling technique would have been adopted, it would be easy to use it and understand. Individually, the modeling technique could be adopted immediately. Business wide this modeling approach was estimated to be adopted in a month. Lessons Learned: • It is hard to capture every possible scenario for an unbounded require- ment
• Unbounded requirements are very hard to be implemented
• Unbounded requirement should come to an end in terms of imple- mentation
• Unbounded requirements should be implemented as best as you can
• The modeling technique seems to be slightly complicated for day-to- day use
• Within the organization the modeling technique could be adopted in a month
5.2.3ExpertExpert3 is a project 3 manager at Javra Software. Javra is active on the Dutch market and is providing software products such as big data and business intelligence, e-commerce and web application, mobile business applications and progress services. He has worked as a project manager actively in- volved in business analysis for over 5 years. Before that he was a developer with 5 years of experience. Have you ever encountered an unbounded requirement? The expert con- firmed that they have encountered plenty of unbounded requirements. Can you provide an example of such an unbounded requirement? One potentially unbounded requirement mentioned by the expert was that a website should have more lively colors. This requirement was explained in a way that it is hard to say what a lively color is and each customer can consider lively something different. How important is it for you/your company to take unbounded require- ments into account to deliver better products? The expert said that the questions seems to be unclear. Also, in his opinion unbounded require- ments have to be addressed. Moreover, any unbounded requirement has to be refined and made more clear. Before implementing an unbounded requirement, every unbounded requirement has to become bounded. In the experts opinion unbounded requirement is a dangerous term as a require- ment has to be clear. Unbounded requirements indicate that you do not understand the requirement. Such requirement has to be made explicit. Would you put an unbounded requirement on your product backlog? The expert work in agile environment and said that he would put an unbounded requirement on the product backlog. In the agile environment the require- ment would be discussed within the team if it is still not clear then the requirement is discussed with the owner who specified it. This expert is involved in requirements engineering as defined by normal agile practice. expert interviews 79 Do you find the modeling technique useful? By using this modeling tech- nique you cannot guarantee that the requirement is refined correctly. Re- quirements have to be refined with the requirement owner. From academic prospective it is good to use this modeling technique. In practice you can get lost in the models. This modeling can be used to refine unbounded requirements but that is not enough as you are unable to see the clearer picture. This modeling can be used on standard requirements as well. To what extent do you find this modeling technique applicable? Accord- ing to the expert the strength of this modeling is that requirements can be broken down. Another advantage is that subrequirements can be co-related. This modeling allows for modeling of a big picture and can be useful when modeling subrequirements. The main weakness is that the user should un- derstand the modeling language. Also, the modeling language seems to be a little bit complicated. The modeling does not show inputs and outputs very well. In daily life the technique is seen to be time consuming to refine an unbounded requirement to a bounded requirement. It can be quicker to refine unbounded requirement with the requirement owner. Assuming you are going to deal with unbounded requirements would you use this modeling technique? No as this modeling is time consuming and the expert has a very close relationship with his requirement owners. Would you adopt this modeling technique in your company/day-to-day practice? The expert would not use it in day to day practice, because it is too complicated to understand and time consuming. One important aspect to consider is the relationship with the requirements engineer and the re- quirements owner. In case that there is a very distant relationship between the analyst and requirements owner, this technique can be very useful. Lessons Learned:
• Before implementing an unbounded requirement it has to become bounded
• This modeling can be helpful in terms of refinement provided that it is hard to approach the requirements owner
• The modeling technique is slightly complicated
• Using this modeling technique would be time consuming
• The modeling does not show inputs and outputs very well
5.2.4ExpertExpert4 is a business 4 analyst at the earlier mentioned bookmaker. She has worked as a business analyst for over 18 years and before that 7 years as a developer. Have you ever encountered an unbounded requirement? The expert con- firmed that unbounded requirements are being encountered. Especially, when the business is engaged for the first time there are ideas that are very high level and do not give very clear boundaries or do not clearly specify what the requirements are. These requirements have to be broken down and limits have to be set. Unbounded requirements have to be refined and made more clear what can be realistically done, because the only thing that you know about an unbounded requirement is that you cannot deliver it. expert interviews 80 Can you provide an example of such an unbounded requirement? The expert could not give a specific example but used the provided example: all songs that ever existed to mankind. The expert explained that when you put some boundaries and limitations to that example this could be satisfied. For example, all songs from UK until specific time in history. This could be doable, however, this would not meet the original requirement How im- portant is it for you/your company to take unbounded requirements into account to deliver better products? You can take unbounded requirement into account but at the same time you cannot deliver it. Limitations have to be set on what your product can do. A boundary requirement has to be specified when trying to deliver an unbounded requirement. Also, the requirement should be made very clear to say what your product is cable to do. Would you put an unbounded requirement on your product backlog? The expert would not put an unbounded requirement to the product backlog because you will never achieve it. In the product backlog there should be only requirements that you will deliver in the future. For that reason, there is no point of putting an unbounded requirement on the product backlog. In terms of refinement a boundary requirement should be formulated and then this boundary requirement would have to be approved by the stake- holder. Then the unbounded requirement is descoped and can be put on the product backlog. In terms of implementation unbounded requirements are neither easy or complicated. It all depends what your stakeholder is like. Do you find the modeling technique useful? According to the expert this modeling can be used for unbounded requirements and general purpose requirements. To what extent do you find this modeling technique applicable? The mod- eling technique in the experts opinion makes you think more structurally rather just going by experience. The modeling technique can help you to structure your thoughts. The main weakness of the modeling technique is that when you show a model modelled by this modeling technique your stakeholder will not understand that. There should be some decriptive way of showing the model to your stakeholder. This modeling technique can be helpful for the business analyst, designer and the developer but is not seen to be useful for the stakeholder. For the stakeholder it should be translated into a more descriptive description. The modeling can be also useful for decomposing requirements into smaller chunk requirement. The majority of modeling techniques can help people to have a more structure approach to a problem. An advantage of this modeling technique is its flexibility as the construct can be altered, added or interpreted to the adopter’s needs. Another advantage of this modeling it to model different types of sources Assuming you are going to deal with unbounded requirements would you use this modeling technique? The expert would like to try out the modeling technique and see how it works. In general, when a business analyst is very experienced this break down and modeling is done mentally. This kind of modeling technique can help you think more structurally and think of scenarios that you might have missed out on. Would you adopt this modeling technique in your company/day-to-day practice? The expert is curious about the modeling technique and would like to give it a try. Individually, the modeling technique can be adopted. Across the company it might be hard to get it used as a corporate tool. The expert interviews 81 technique is not seen to be complicated by the expert but it is important to understand the notation. Lessons Learned:
• Unbounded requirements should be descoped and a boundary re- quirement has to be specified
• Unbounded requirements can occur when the business gets engaged for the first time
• The modeling technique can provide a structured way into require- ments refinement
• Within the organization it would be hard to adopt it. Individually, this modeling language could be adopted easily.
• The main weakness of this modeling is that it cannot be understood by majority of stakeholders
5.2.5ExpertExpert5 is a business 5 analyst at the same bookmaker as the other two busi- ness analysts. He has worked as a business analyst for over 5 years and has plenty of experience in the IT industry. Have you ever encountered an unbounded requirement? The expert con- firmed the existence of unbounded requirements by providing an example. He stated that requirement should never be ambiguous and should always clearly state what is required. There can be several ways how to look at requirements depending on the development methodology such as water- fall, agile, etc. The reason why requirements cannot be fully satisfied is that there might exist dependencies that can block the issue and cause that the requirement cannot be fully satisfied. Can you provide an example of such an unbounded requirement? The example provided was: Cash out option on every single market. It is achiev- able but it is not achievable at the moment. For that reason, they do not do it. The reason why is not achievable is that different markets are set up in different ways. In terms of implementation limitations have to be discussed with various development teams and would need to be reported back to the business. The result of the analysis would be a specific subset of markets for a specified amount of money, time or any other measure. The cash out example would be implemented by third party suppliers. How important is it for you/your company to take unbounded requirements into account to deliver better products? The expert stated that in agile different pieces of work are dependent on each other so it is hard to say overall how better the product can be. Would you put an unbounded requirement on your product backlog? In agile an unbounded requirement would be delivered incrementally. Accord- ing to the expert unbounded is ambiguous and therefore such requirement has to be redefined. The example provided was broken down into groups of scenarios and refined as a few requirements. Meaning that the unbounded requirement was broken down into smaller requirements. Do you find the modeling technique useful? According to the expert it needs some time to understand any modeling technique and to pick it up. The usefulness can be assessed by its benefits. Depends if a modeling is used for yourself to understand it or for somebody else to understand it. expert interviews 82 The expert uses process models to visualize systems for his own under- standing. This type of modeling can be definitely used for modeling of any requirements. To what extent do you find this modeling technique applicable? This mod- eling is not useful for the product owner or the stakeholder as it cannot be understood by them. The stakeholder is concerned about the functionality. Another weakness is that there are many different modeling languages avail- able. The questions is why to model requirements that cannot be achieved and why to model something that cannot be achieved. The strength of this modeling is that modeling of unbounded requirements has not been addressed yet. Assuming you are going to deal with unbounded requirements would you use this modeling technique? The expert has not come across this modeling. The expert stated that he would use a modeling technique that is better for him to understand and what is better to visualize to stakeholders. Would you adopt this modeling technique in your company/day-to-day practice? At first glance this modeling seems to be similar to use cases. Use cases are similar to this modeling technique therefore this modeling does not seem to be complicated. In business analysis there is no definite way of modeling requirements. Also, there are many diagrams that are used in practice. It is all up to the business analyst which modeling he uses. Often, it depends on the software development methodology which modeling technique to use. Lessons Learned:
• Unbounded requirements are the same as ambiguous requirements
• Unbounded requirements have to be broken down and become bounded in order to be implemented
• In agile environment unbounded requirements would be implemented incrementally
• In business analysis there is no definite way of modeling requirements
• This type of modeling would not be used as this modeling cannot be understood by stakeholders 6
This chapterDISCUSSION concludes this document. We discuss the main conclusions based on the evaluation, limitations to this work and which directions should the future research go.
Guided by the main research question "What is an adequate model-driven 6.1method conclusion to support the refinement of unbounded requirements?" this project is an extensive study on unbounded requirements that explains the notion, introduces a model-driven method how to model them and cope with them. Furthermore, refinement patterns make use of the proposed modeling tech- nique and demonstrate its applicability. In regards to SQ3 we identified core refinement patterns. The refinement patterns show repetitive unbounded functionalities that have occurred in practice. We provided much evidence of the existence of unbounded requirements by presenting real-world requirements. By this process we answered SQ1. Also, we interviewed experts to confirm the existence of unbounded require- ments. Unbounded requirements are seen to be standard requirements as implementing or refining unbounded requirements requires a redefinition, a new boundary requirement has to be specified or an unbounded require- ment has to simply become bounded. We address SQ2 by proposing the modeling language. Next, the mod- eling language was evaluated by experts from relevant fields to confirm its usability and applicability. The modeling language was marked as useful for any type of requirements not just unbounded. This modeling language was not known by either of the interviewees. There is a long way to its broad acceptance by the potential future adopters. The modeling language can help the engineer to think more structurally in the refinement process. By using the modeling additional criteria for the requirement satisfaction can be uncovered. This modeling, however, can be inefficient, as sometimes it is quicker to refine a requirement with the stakeholder. The main drawback of this modeling language is its complexity. It can be useful for the engineer, however it is not useful for the stakeholder as the stakeholder would not understand its meaning. The patterns are an elegant and easy way to refine unbounded require- ments. SQ4 was addressed by exhibiting the applicability of the patterns. The patterns have been evaluated in a way that we applied them on a group of unbounded requirements. By using the patterns we were able to model 80% of all requirements from the testing sample. The applicability of the the patterns might be constrained by domain specific unbounded require- ments that might differ for each application. Moreover, from the experience of applying the patterns we observed that the patterns can bring efficiency into the refinement process as very often only the sources and the names of entities were changed. The requirements that seemed to be cross-cutting
83 limitations 84 various aspect patterns were not modelled and marked as there is no pattern that can be applied. The main contribution of the patterns we defined is the use of the atomic patterns as these were repetitively used when designing the source solution for a requirement. The atomic patterns can be seen to be applied in almost every case.
One of the limitations is that this framework is not sufficiently mature to 6.2enable tolimitations easily recognize unbounded requirements. It is still hard to iden- tify an unbounded requirement. Often, unboundedness is confused with unclarity. Sometimes it is very hard to say if a requirement can be con- sidered unbounded or the requirement is just underspecified. Currently, there is no rule of thumb in order to identify an unbounded requirement. The only way how to identify an unbounded requirement is by looking at our definition and considering two elements: the functional nature of the requirement and its inability to be fully satisfied. An important constraint to this research is that the approach does not consider the development costs. The implementation backlog is often over- loaded no matter the stage of the software product lifecycle. This might represent a challenge for prioritization in terms of implementing different sources into a software product. We do not consider the integration within existing software development methods. Neither have we suggested in what order the designed sources should be implemented. Whether the implemen- tation of sources should be done at once or gradually with respect to agile development. There is a number of validity types which have to be addressed and con- sidered in order to carry out high quality research. We state a few types of validity that could have potentially affect the outcomes of this research.
6.2.1InternalInternal validity Validity is the authenticity of the findings regarding the cause-effect relationships. To assure that the research has been conducted properly and there are no external or other forces influencing the outcomes several threats to internal validity are anticipated. The process of identification of unbounded requirements was described as comparing the screened requirements against the definition. In this pro- cess a broader understanding of unbounded requirements could have been built which could cause that also unbounded requirements that were not compliant with the definition were identified as unbounded. Another threat to internal validity is presented by the internal evaluation of the pattens. The patterns were validated by the researcher with broad knowledge and understanding of unbounded requirements. This could pos- sibly yield overly positive results. Furthermore, the testing sample consisted of requirements from 3 appli- cations. In the sample there was only one application that was not used in the process of defining patterns. The questions were formulated in a manner that encouraged to express ex- perts opinions to avoid yes and no answers. The interviews were conducted future work 85 informally face-to-face or via Skype. The participants were encouraged to express their true opinion to avoid the confirmation bias.
6.2.2ExternalExternal validity Validity refers to generalizability of the results. We attempted to include various different types of application to retrieve unbounded require- ments and define the patterns. There were 8 applications included in this study in order to diminish the bias and increase the generalizability of the results. Furthermore, we interviewed various experts with different type of expertise such as project managers and business analysts to get a view on the modeling technique and unbounded requirements from various perspec- tives. The evaluation took place at a number of companies, within dissimilar countries. Furthermore, the applications which we included in this research were mostly chosen with regards to the completeness and level of detail of their requirements database. Next, the applications included are modern web 2.0 applications and traditional application to make this research more general- izable.
6.2.3ReliabilityReliability refers to a state that the results are not a one-off matter, but the same results will be obtained if the same research within the same setting is conducted. All the sources, instruments and retrieved data are properly doc- umented and described and can be found in Appendices. Due to the novelty of the topic and exploratory nature of the study, different researcher could come up with different results. This leaves an open window to improve this research and build on the findings presented in this thesis. It is also at question how important is to increase the awareness about unbounded requirements.
Unbounded requirements can be addressed by various sources. The prob- 6.3lem comesfuture up when work it comes to the selection of the sources. The future work should focus on the selection process of the most suitable sources, how to prioritize them, how to select them with respect to the cost-oriented approach and why to select this source over the other. A whole new source selection strategy can be developed to aid to address unbounded require- ments and the process of source selection. This trade-off analysis still needs to be researched. Moreover, conflicts and synergies should be addressed when developing a trade-off analysis method. To enable such an analysis, development of a proper software tool is essential. The modeling technique that we proposed is a product of this research. Each product has to have a good marketing and there is a long way to its broad acceptance in practice. Similarly, the notion of unbounded require- ment is still unknown in practice and needs to be marketed by ever per- fecting research on this topic. The more studies addressing this subject the greater the awareness. future work 86 The experimental approach of assigning characteristics to unbounded re- quirements such as quality attributes can be further evaluated and a method to discern groups of patterns can be created. The social network analysis in requirements engineering could possibly uncover a new area - requirements mining. Similarly, as data mining, requirements mining could be a counter- part to data mining. Uncovering hidden characteristics between various entities - requirements. This area could allow for gathering and uncover- ing additional data about relationships between requirements. This can be crucial to understand why and how various requirements are related and this should be reflected in the system as well. Furthermore, these require- ment relationships can be further tracked to the users that have formulated these requirement and discover relationships within the organization. These two types of network analysis can be further compared and the enterprise organizational structure can be easily reflected on the system architecture. This theoretical approach could theoretically provide a framework for mod- eling and understanding requirements and capturing scenarios that are hid- den from traditional requirements elicitation and identification techniques. Also, the quality attributes that are particularly important for unbounded requirements can be evaluated in practice by conducting a questionnaire. The patterns can be further evaluated as suggested by [22] by the pattern users, in an organizational context, and then on real world cases to be able to measure the outcomes. This would allow to get them fully approved by the future pattern adopters. This process of evaluation may take up to a few years. Another short-term approach would be to perform an experiment on two groups of people with and without the patterns and evaluate the patterns with respect to their effectiveness and efficiency. Lastly, a question raises what is the presence of unbounded requirements in the public domain and software intended for various bodies of govern- ment. The public domain is extremely complex and complicated and public software is very often monstrous. The failure of public IT projects can be possibly ascribed to excessive presence of unbounded requirements and in- ability to meet them which can possibly cause the eventual failure. BIBLIOGRAPHY[1] Ken Peffers, Tuure Tuunanen, Marcus A Rothenberger, and Samir Chatterjee. A design science research methodology for information systems research. Journal of management information systems, 24(3):45– 77, 2007.
[2] Anne Cleven, Philipp Gubler, and Kai M Hüner. Design alternatives for the evaluation of design science research artifacts. In Proceedings of the 4th International Conference on Design Science Research in Information Systems and Technology, page 19. ACM, 2009.
[3] Paolo Bresciani, Anna Perini, Paolo Giorgini, Fausto Giunchiglia, and John Mylopoulos. Tropos: An agent-oriented software development methodology. Autonomous Agents and Multi-Agent Systems, 8(3):203– 236, 2004.
[4] Gilbert Probst and Andrea Bassi. Tackling complexity: a systemic ap- proach for decision makers. Greenleaf publishing, 2014.
[5] John Mylopoulos, Lawrence Chung, and Brian Nixon. Representing and using nonfunctional requirements: A process-oriented approach. Software Engineering, IEEE Transactions on, 18(6):483–497, 1992.
[6] Sakthi Kumaresh and Baskaran Ramachandran. Defect prevention based on 5 dimensions of defect origin. International Journal of Software Engineering & Applications (IJSEA), 3(4), 2012.
[7] Shawulu Hunira Nggada. Software failure analysis at architecture level using fmea. International Journal of Software Engineering and Its Applications, 6(1):61–74, 2012.
[8] Chris Hobbs. The changing nature of software failure. China Technol- ogy Innovation Conference, 2011.
[9] Paul Robertson and Brian Williams. Automatic recovery from soft- ware failure. Communications of the ACM, 49(3):41–47, 2006.
[10] The Standish Group. The chaos report. Technical report, The Standish Group, 2006.
[11] Edward E Ogheneovo. Software dysfunction: Why do software fail? Journal of Computer and Communications, 2014, 2014.
[12] Nancy G Leveson. System safety in computer-controlled automotive systems. Technical report, SAE Technical Paper, 2000.
[13] Taimour Al Neimat. Why it projects fail. The project perfect white paper collection, 8, 2005.
[14] R. N. Charette. Why software fails [software failure]. IEEE Spectr., 42(9):42–49, September 2005.
[15] The Standish Group. The chaos report. Technical report, The Standish Group, 2014.
87 Bibliography 88 [16] Fabiano Dalpiaz, Michal Korenko, Rick Salay, and Marsha Chechik. Using the crowds to satisfy unbounded requirements. In The First International Workshop on Crowd-Based Requirements Engineering, vol- ume 1, 2015.
[17] Christof Ebert and Jozef De Man. Requirements uncertainty: Influ- encing factors and concrete improvements. In Proceedings of the 27th International Conference on Software Engineering, ICSE ’05, pages 553– 560, New York, NY, USA, 2005. ACM.
[18] Ieee recommended practice for software requirements specifications. IEEE Std 830-1998, pages 1–40, Oct 1998.
[19] Ian I. Mitroff and Harold A. Linstone. The unbounded mind : breaking the chains of traditional business thinking / Ian I. Mitroff and Harold A. Linstone. Oxford University Press New York, 1993.
[20] R Hevner von Alan, Salvatore T March, Jinsoo Park, and Sudha Ram. Design science in information systems research. MIS quarterly, 28(1):75–105, 2004.
[21] Nicolas Prat, Isabelle Comyn-Wattiau, and Jacky Akoka. Artifact eval- uation in information systems design-science research–a holistic view. In 18th Pacific Asia Conference on Information Systems, Chengdu, China, 2014.
[22] Kurt Sandkuhl. Patterns in business analysis and enterprise modeling: How to evaluate their value? In Proceedings of the 2nd International Business and System Conference BSC 2013, pages 57–70, 2013.
[23] Irum Inayat, Sabrina Marczak, and Siti Salwah Salim. Studying rel- evant socio-technical aspects of requirements-driven collaboration in agile teams. In Empirical Requirements Engineering (EmpiRE), 2013 IEEE Third International Workshop on, pages 32–35. IEEE, 2013.
[24] Joseph A Goguen. Formality and informality in requirements engi- neering. In ICRE, volume 96, pages 102–108, 1996.
[25] M Karthika, Jasaline Anitha, X Joshphin, and K Alagarsamy. An ap- proach to analyse and quantify the functional requirements in soft- ware system engineering. International Journal of Computer Applications, 43(24), 2012.
[26] Lawrence Chung, Brian A Nixon, Eric Yu, and John Mylopoulos. Non- functional requirements in software engineering, volume 5. Springer Sci- ence & Business Media, 2012.
[27] David R. Karger and William Jones. Data unification in personal in- formation management. Commun. ACM, 49(1):77–82, January 2006.
[28] Vinay Sachidananda, Abdelmajid Khelil, and Neeraj Suri. Quality of information in wireless sensor networks: A survey. ICIQ (to appear), 2010.
[29] Sammy W Pearson and James E Bailey. Measurement of computer user satisfaction. ACM SIGMETRICS Performance Evaluation Review, 9(1):59–68, 1980. Bibliography 89 [30] Henry Watson Fowler, Francis George Fowler, and David Crystal. The Concise Oxford Dictionary: The Classic First Edition. Oxford University Press, 2011.
[31] Manas Tungare, Pardha S Pyla, Miten Sampat, and M Perez-Quinones. Defragmenting information using the syncables framework. In Pro- ceedings of the 2nd Invitational Workshop on Personal Information Manage- ment at SIGIR, volume 2006, 2006.
[32] Satu Parjanen, Lea Hennala, and Suvi Konsti-Laakso. Brokerage func- tions in a virtual idea generation platform: Possibilities for collective creativity? Innovation, 14(3):363–374, 2012.
[33] Eric Von Hippel. The sources of innovation. Springer, 2007.
[34] George Pohle and Marc Chapman. Ibm’s global ceo report 2006: busi- ness model innovation matters. Strategy & Leadership, 34(5):34–40, 2006.
[35] Len Bass, Mark Klein, and Felix Bachmann. Quality attribute design primitives and the attribute driven design method. Springer, 2002.
[36] Ian Gorton. Software quality attributes. In Essential Software Architec- ture, pages 23–38. Springer, 2011.
[37] Martin Weik. Computer science and communications dictionary. Springer Science & Business Media, 2000.
[38] Norman Fenton and James Bieman. Software metrics: a rigorous and practical approach. CRC Press, 2014.
[39] Barry W Boehm, John R Brown, and Hans Kaspar. Characteristics of software quality. 1978.
[40] Thomas P Bowen, Gary B Wigle, and Jay T Tsai. Specification of software quality attributes. Rome Air Development Center, Air Force Systems Command, 1985.
[41] General Electric Company, Jim A McCall, Paul K Richards, and Gene F Walters. Factors in Software Quality: Final Report. Information Systems Programs, General Electric Company, 1977.
[42] ISO. ISO/IEC 9126-1:2001, Software engineering – Product quality – Part 1: Quality model. Technical report, International Organization for Standardization, 2001.
[43] Andrew J Flanagin and Miriam J Metzger. Digital media and youth: Unparalleled opportunity and unprecedented responsibility. Digital media, youth, and credibility, pages 5–27, 2008.
[44] Thomas Erl. SOA design patterns. Pearson Education, 2008.
[45] Mohamed Fayad. Accomplishing software stability. Communications of the ACM, 45(1):111–115, 2002.
[46] Brahim Medjahed and Athman Bouguettaya. A multilevel composabil- ity model for semantic web services. Knowledge and Data Engineering, IEEE Transactions on, 17(7):954–968, 2005. Bibliography 90 [47] Liam O’Brien, Paulo Merson, and Len Bass. Quality attributes for service-oriented architectures. In Proceedings of the International Work- shop on Systems Development in SOA Environments, SDSOA ’07, pages 3–, Washington, DC, USA, 2007. IEEE Computer Society.
[48] Brian Moriarty. System safety engineering and management. John Wiley & Sons, 1990.
[49] Patrik Berander, Lars-Ola Damm, Jeanette Eriksson, Tony Gorschek, Kennet Henningsson, Per Jönsson, Simon Kågström, Drazen Milicic, Frans Mårtensson, Kari Rönkkö, et al. Software quality attributes and trade-offs. Blekinge Institute of Technology, 2005.
[50] S Yu Eric. Modelling strategic relationships for process reengineering. 1995.
[51] Diego Lo Giudice. The state of model-driven development. Technical report, Forrester, 2007.
[52] Jorn Bettin. Model-driven software development. MDA Journal, 1, 2004.
[53] Peter Coad and Edward Yourdon. Object oriented analysis. 1991.
[54] James Rumbaugh, Michael Blaha, William Premerlani, Frederick Eddy, William E. Lorensen, et al. Object-oriented modeling and design, volume 199. Prentice-hall Englewood Cliffs, 1991.
[55] Sol J Greenspan, John Mylopoulos, and Alex Borgida. Capturing more world knowledge in the requirements specification. In Proceedings of the 6th international conference on Software engineering, pages 225–234. IEEE Computer Society Press, 1982.
[56] Sol Greenspan, John Mylopoulos, and Alex Borgida. On formal re- quirements modeling languages: Rml revisited. In Proceedings of the 16th International Conference on Software Engineering, ICSE ’94, pages 135–147, Los Alamitos, CA, USA, 1994. IEEE Computer Society Press.
[57] Janis A Bubenko Jr. Information modeling in the context of system development. In IFIP Congress, volume 1980, pages 395–411, 1980.
[58] John Mylopoulos, Alex Borgida, Matthias Jarke, and Manolis Koubarakis. Telos: Representing knowledge about information sys- tems. ACM Trans. Inf. Syst., 8(4):325–362, October 1990.
[59] Lawrence Cabac and Daniel Moldt. Formal semantics for auml agent interaction protocol diagrams. In Agent-Oriented Software Engineering V, pages 47–61. Springer, 2005.
[60] Michael Wooldridge, Nicholas R Jennings, and David Kinny. The gaia methodology for agent-oriented analysis and design. Autonomous Agents and multi-agent systems, 3(3):285–312, 2000.
[61] Robert Darimont, Emmanuelle Delor, Philippe Massonet, and Axel van Lamsweerde. Grail/kaos: an environment for goal-driven require- ments engineering. In Proceedings of the 19th international conference on Software engineering, pages 612–613. ACM, 1997. Bibliography 91 [62] Axel Van Lamsweerde, Robert Darimont, and Philippe Massonet. Goal-directed elaboration of requirements for a meeting scheduler: Problems and lessons learnt. In Requirements Engineering, 1995., Pro- ceedings of the Second IEEE International Symposium on, pages 194–203. IEEE, 1995.
[63] Raian Ali, Fabiano Dalpiaz, and Paolo Giorgini. A goal-based frame- work for contextual requirements modeling and analysis. Requirements Engineering, 15(4):439–458, 2010.
[64] S Yu Eric. Social modeling and i*. In Conceptual Modeling: Foundations and Applications, pages 99–121. Springer, 2009.
[65] Jaelson Castro, Manuel Kolp, and John Mylopoulos. Towards requirements-driven information systems engineering: the tropos project. Information systems, 27(6):365–389, 2002.
[66] Susan Helper. Strategy and irreversibility in supplier relations: the case of the us automobile industry. Business history review, 65(04):781– 824, 1991.
[67] Katharine G Abraham and Susan K Taylor. Firms’ use of outside contractors: Theory and evidence. Technical report, National Bureau of Economic Research, 1993.
[68] John Hagel and John Seely Brown. The only sustainable edge: Why business strategy depends on productive friction and dynamic specialization. Harvard Business Press, 2005.
[69] Suzanne Rivard and Benoit A Aubert. Information technology outsourc- ing. Routledge, 2015.
[70] Linda Cohen and Allie Young. Multisourcing: moving beyond outsourc- ing to achieve growth and agility. Harvard Business Press, 2006.
[71] Luis Von Ahn. Human computation. In Design Automation Conference, 2009. DAC’09. 46th ACM/IEEE, pages 418–419. IEEE, 2009.
[72] Fei-Yue Wang, Kathleen M Carley, Daniel Zeng, and Wenji Mao. Social computing: From social informatics to social intelligence. Intelligent Systems, IEEE, 22(2):79–83, 2007.
[73] Joel Ross, Lilly Irani, M Silberman, Andrew Zaldivar, and Bill Tomlin- son. Who are the crowdworkers?: shifting demographics in mechani- cal turk. In CHI’10 Extended Abstracts on Human Factors in Computing Systems, pages 2863–2872. ACM, 2010.
[74] Adam Marcus, Eugene Wu, David R Karger, Samuel Madden, and Robert C Miller. Crowdsourced databases: Query processing with people. CIDR, 2011.
[75] Katriina BystrÖm. Information and information sources in tasks of varying complexity. Journal of the American Society for information Sci- ence and Technology, 53(7):581–591, 2002.
[76] Wil MP van Der Aalst, Arthur HM Ter Hofstede, Bartek Kiepuszewski, and Alistair P Barros. Workflow patterns. Distributed and parallel databases, 14(1):5–51, 2003. Bibliography 92 [77] Tadao Murata. Petri nets: Properties, analysis and applications. Pro- ceedings of the IEEE, 77(4):541–580, 1989.
[78] Kenneth E. Iverson. A programming language. In Proceedings of the May 1-3, 1962, Spring Joint Computer Conference, AIEE-IRE ’62 (Spring), pages 345–351, New York, NY, USA, 1962. ACM.
[79] Robert Darimont and Axel Van Lamsweerde. Formal refinement pat- terns for goal-driven requirements elaboration. In ACM SIGSOFT Soft- ware Engineering Notes, volume 21, pages 179–190. ACM, 1996.
[80] S Tsur, S Abiteboul, R Agrawal, U Dayal, J Klein, and G Weikum. Are web services the next revolution in ecommerce. VLDB2001, pages 614–617, 2001.
[81] Christopher Alexander. The timeless way of building, volume 1. New York: Oxford University Press, 1979.
[82] James O Coplien and A Word On Alexander. Software patterns. 1996.
[83] Lars Hagge and Kathrin Lappe. Sharing requirements engineering experience using patterns. Software, IEEE, 22(1):24–31, 2005.
[84] Christopher Alexander, Sara Ishikawa, and Murray Silverstein. A pat- tern language: towns, buildings, construction, volume 2. Oxford Univer- sity Press, 1977.
[85] James O Coplien. Software design patterns: Common questions and answers. The Patterns Handbook: Techniques, Strategies, and Applications. Cambridge University Press, NY, pages 311–320, 1998.
[86] Xavier Franch, Cristina Palomares, Carme Quer, Samuel Renault, and François De Lazzer. A metamodel for software requirement patterns. In Requirements Engineering: Foundation for Software Quality, pages 85– 90. Springer, 2010.
[87] Dan Matheson, Indrakshi Ray, Indrajit Ray, and Siv Hilde Houmb. Building security requirement patterns for increased effectiveness early in the development process. In Proceedings of Symposium on Re- quirements Engineering for Information Security, 2005.
[88] Tong Li and John Mylopoulos. Modeling and applying security pat- terns using contextual goal models. In The 7th International i* Workshop, iStar14, 2014.
[89] Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides. De- sign patterns: elements of reusable object-oriented software. Pearson Edu- cation, 1994.
[90] Michael Adams, James Coplien, Robert Gamoke, Robert Hanmer, Fred Keeve, and Keith Nicodemus. Fault-tolerant telecommunication system patterns. Rising [45], pages 81–94, 1996.
[91] Frank Buschmann, Regine Meunier, Hans Rohnert, Peter Sommerlad, and Michael Stal. A system of patterns: Pattern-oriented software architecture. 1996.
[92] Daniel Gross and Eric Yu. From non-functional requirements to de- sign through patterns. Requirements Engineering, 6(1):18–36, 2001. Bibliography 93 [93] Siobhán Clarke and Robert J Walker. Composition patterns: An ap- proach to designing reusable aspects. In Proceedings of the 23rd inter- national conference on Software engineering, pages 5–14. IEEE Computer Society, 2001.
[94] Evelien Otte and Ronald Rousseau. Social network analysis: a pow- erful strategy, also for the information sciences. Journal of information Science, 28(6):441–453, 2002.
[95] Linton Freeman. The development of social network analysis. A Study in the Sociology of Science, 2004.
[96] Lennart Björneborn and Peter Ingwersen. Perspective of webometrics. Scientometrics, 50(1):65–82, 2001.
[97] Christine L Borgman. From Gutenberg to the global information infras- tructure: access to information in the networked world. Mit Press, 2000.
[98] Nicole B Ellison et al. Social network sites: Definition, history, and scholarship. Journal of Computer-Mediated Communication, 13(1):210– 230, 2007.
[99] Lin Liu, Eric Yu, and John Mylopoulos. Security and privacy require- ments analysis within a social setting. In Requirements Engineering Con- ference, 2003. Proceedings. 11th IEEE International, pages 151–161. IEEE, 2003.
[100] Paul C. Prince. Psychology Research Methods: Core Skills and Concepts. Creative Commons, 2012.
[101] Victor R Basili and H Dieter Rombach. The tame project: Towards improvement-oriented software environments. Software Engineering, IEEE Transactions on, 14(6):758–773, 1988.
[102] Claes Wohlin, Per Runeson, Martin Höst, Magnus C Ohlsson, Björn Regnell, and Anders Wesslén. Experimentation in software engineering. Springer Science & Business Media, 2012.
[103] Juliet Corbin and Anselm Strauss. Basics of qualitative research: Tech- niques and procedures for developing grounded theory. Sage publications, 2014. Appendices
94 A SAMPLEOFUNBOUNDED ID RefinedREQUIREMENTS Title RP02 New TV episodes notification - The system shall notify the user about a new episode or release date that is relevant to him/her RP03 The system shall provide descriptive information about all movies such as cast list, technical specification including re- views and comments RP05 New rating systems - The application shall feature additional desired movie rating systems RP06 Missing movie and TV series information - Assure the com- pleteness of descriptive content for TV series and movies RP07 Smart torrent assignment - Determine and assign torrents for each user individually so that no user can face an issue of insufficient amount of seeders RS01 Recently added tab - The system shall list relevant songs to the user that have been added recently RS03 Announced album release date - The application shall pro- vide release dates of announced albums RS04 Where do I know the artist from - The system shall list songs that the artist performed in RS05 Lyrics - The application shall provide lyrics for all songs RS06 Upcoming concerts in my area - The system to notify the user of all upcoming concerts in the current area that are of his/her interest RS08 Discover function - The software to suggest music songs that the user has not listened to before RS12 Disable explicit content - The software to recognise all explicit songs and filter them out RS13 Advanced suggestion system - Advanced up-to-date list of 50 music songs that the user has not listened to based on user preferences RS15 Original album release - The system shall provide informa- tion on original date of release RS17 Did you mean function - Search correction for the search field if the spelling is incorrect RS18 Suggest similar songs - The application should be creating recommendations based on user preferences RS24 All existent songs available - The system shall be able to pos- sess all songs that existed to mankind RS25 Automatically complete metadata - The software shall auto- matically check and correct the metadata by using existent services List of unbounded requirements 1/4
Table A.1.:
95 96 ID Refined Title A. Sample of Unbounded Requirements RS26 Teacher mode - The application to filter out inappropriate content for the youth RS27 Cover original artist - The application to list the original artist for covers RS28 Unofficial release sandbox - A feature that allows unofficial uploads, determine if sound quality is sufficient, check dupli- cates and correct metadata RS29 Mixtape inclusion - The system shall make popular mixtapes accessible RS30 Ticket purchase - The application shall allow to buy tickets for concerts for favorite artists RS31 Popular meter - All songs shall have a popular meter that measures the popularity or mark the song as a hit RS32 Events calendar - The app shall show concerts of favorite artists in your current and nearby areas in a calendar RS33 Relevant and accurate recommendations for upcoming con- certs in the current area - The system shall provide integra- tion with services providing recommendations on upcoming concerts in the local area RFF01 Website home page - The browser should have an ability to go back to the homepage after clicking a button RFF03 Phishing and malware protection - The browser to warn the user when accessing a harmful website RFF05 Search field to recognize what is going to be searched and access the website directly instead of performing a search by search engine RFF06 Automatic disabling of shortcut functionalities while playing a game RSY02 Brand names recognition - The software should recongnize using other language than set and disable capitalization of brand names that are inappropriate for the language used RSY03 Spell check - The software shall support spell checking RSY04 Blocking spammers - The system should recognize spammers and prevent adding spammers into a contact list RSY05 Spell check - The software shall support spell checking for Windows 7 users RSY06 Chat to recognise top-level domains - The system to highlight URLs by inquiring DNS servers if a valid url is used in chat RC01 No hating feature - The system should filter negative com- ments, cussing or hating RC04 Low amount followers users on featured page - The system should determine which user with low amount of followers should be listed on the featured page RC05 Redefine popular list - Determine subjectively in a fair man- ner which users are featured on the featured page RC06 Celebrity stickers - The app should feature popular celebrity stickers RC07 More fonts - Introduce popular modern fonts RC08 New fonts - Introduce more likeable new fonts List of unbounded requirements 2/4
Table A.2.: A. Sample of Unbounded Requirements 97
ID Refined Title RC09 Orginality measures on the popular page - The app should not allow users who copy the content of other users to get featured RC10 Filtering swears and online dating - The app should filter out swears and online dating from comments RC11 Unpopular page - Users with a few followers that post qual- ity collages should get featured RC12 Original collages - Users that post original collages should be featured RC13 Popular page - Feature users who deserve it in a fair manner RC14 Feature users with low amount of followers - The app shall determine which users with low amount of followers deserve to be featured on the popular page ROD03 Accurate sync indicator - System to provide precise informa- tion on the duration of a file sync ROD04 Let users decide which version of OneDrive they want to use ROD05 Trusted devices access - Determine if a device can be trusted based on its security state and grant access accordingly RN01 Find & Merge Duplicates - The app to detect accurately all duplicates and merge them with other RN02 Email associating - Recognize and associate business emails with business email accounts RN03 Website Contact Retrieval - Retrieve contacts from any web- site on the web and store in nimble RN05 Social Stream Alerts - Nimble shall notify users if their com- pany was mentioned online RN06 Expanded social feeds - The system should be connected to any social media RN08 Associate emails sent by third parties or unknown email ids to contacts to which the message concerns RN09 Tighter Google apps integration - Integrate Nimble with Google apps RN10 Current Contact’s time - The system should have information of the contact’s current time zone and suggest when to phone up RN11 Find unconnected social profiles - Suggest list of contacts that the user is not connected to on social media List of unbounded requirements 3/4
Table A.3.: A. Sample of Unbounded Requirements 98
ID Refined Title RN12 Localizations - Nimble should have more language options RN13 Contact’s location - Map contacts according to their current location RN14 Client information - Nimble shall have more useful informa- tion about clients RN15 List unengaged contacts - Suggest contacts that have various social media profiles and the user is not linked to RN16 Influential contacts - Nimble to determine the most influen- tial contacts RN18 Scrape signatures from emails - Nimble should scrape con- tact details from emails accurately RN19 Auto-format phone numbers RN21 Suggest contacts to follow - Nimble shall suggest contacts that have social media profiles and are not linked to user profile RN22 Find & Merge Duplicates - The app to detect accurately all duplicates and merge them with other RN23 Browser plugin able to scrape contacts - Browser plugin to harvest contact details from any content shown in the browser RN24 Contact’s activity records - Provide data on the contact’s ac- tivity, clicked newsletters, products, website activity RN25 Tag meaning - Show the meaning of a tag when hovering over it RN26 Exclude personal social content - Filter personal emails auto- matically and show only the business content RN27 Integrate with iOS apps - Provide closer integration with iOS application ecosystem RN28 Business cards storing - The system shall save the informatio on business cards in a structured way after snapping it RN29 Contact tracker - The system shall feature a reporting tool that reports on the contacts activity on the company’s website RN30 Hang up automatically - The phone should hang up a call automatically RN31 Dial the next contact progressively - The phone should dial the next contact progressively right after hanging up RN32 Social media grouping - Group social media navigation tabs into one RN33 Unreachable follow ups - The system should automatically follow up a contact that did not pick up his/her phone RN34 Company mentioned alerts - Receive an alert when the com- pany is mentioned on the web List of unbounded requirements 4/4
Table A.4.: A. Sample of Unbounded Requirements 99
ID App Cluster Link RP02 PopcornTime 7 http://bit.ly/1IRlJOy RP03 PopcornTime 5 http://bit.ly/1IRlOlf RP05 PopcornTime 4 http://bit.ly/1LEa5e3 RP06 PopcornTime 5 http://bit.ly/1IRlXoJ RP07 PopcornTime 2 http://bit.ly/1LE9VU1 RS01 Spotify 7 http://bit.ly/1IRm5EI RS03 Spotify 0 http://bit.ly/1IRm8k2 RS04 Spotify 5 http://bit.ly/1IRmbwg RS05 Spotify 6 http://bit.ly/1LEa7mk RS06 Spotify 7 http://bit.ly/1IRmneR RS08 Spotify 7 http://bit.ly/1IRmqrf RS12 Spotify 6 http://bit.ly/1IRmtTO RS13 Spotify 7 http://bit.ly/1IRmE1v RS15 Spotify 5 http://bit.ly/1SCQonp RS17 Spotify 6 http://bit.ly/1IRmM0P RS18 Spotify 7 http://bit.ly/1IRmN4X RS24 Spotify 5 http://bit.ly/1IRmQOn RS25 Spotify 5 http://bit.ly/1IRmSFI RS26 Spotify 6 http://bit.ly/1LEaixZ RS27 Spotify 0 http://bit.ly/1IRn0VN RS28 Spotify 5 http://bit.ly/1IRnk6U RS29 Spotify 5 http://bit.ly/1IRnn2G RS30 Spotify 7 http://bit.ly/1IRnoDP RS31 Spotify 7 http://bit.ly/1IRnsU1 RS32 Spotify 1 http://bit.ly/1IRnw6m RS33 Spotify 4 http://bit.ly/1IRnCLh RFF01 Firefox 2 http://mzl.la/1IRnHOY RFF03 Firefox 6 http://mzl.la/1IRnKua RFF05 Firefox - http://mzl.la/1IRnOKp RFF06 Firefox 6 http://mzl.la/1LEa0qR RSY02 Skype 6 http://bit.ly/1IRnVp7 RSY03 Skype 6 http://bit.ly/1IRnWtg RSY04 Skype 6 http://bit.ly/1IRo0tc RSY05 Skype 6 http://bit.ly/1IRo4Ja RSY06 Skype 6 http://bit.ly/1IRo8J4 RC01 PicCollage 6 http://bit.ly/1IRob7O RC04 PicCollage 4 http://bit.ly/1IRofnS RC05 PicCollage 4 http://bit.ly/1IRogZ0 RC06 PicCollage 4 http://bit.ly/1IRokI9 RC07 PicCollage 4 http://bit.ly/1IRoorA Details about unbounded requirements 1/2
Table A.5.: A. Sample of Unbounded Requirements 100
ID App Cluster Link RC08 PicCollage 4 http://bit.ly/1IRonUC RC09 PicCollage 4 http://bit.ly/1IRosaF RC10 PicCollage 6 http://bit.ly/1IRoAXK RC11 PicCollage 4 http://bit.ly/1IRoFe7 RC12 PicCollage 4 http://bit.ly/1IRoH5I RC13 PicCollage 4 http://bit.ly/1IRoKyj RC14 PicCollage 4 http://bit.ly/1IRoMGv ROD03 OneDrive 6 http://bit.ly/1IRoNKH ROD04 OneDrive 1 http://bit.ly/1IRoQGl ROD05 OneDrive 6 http://bit.ly/1IRoUFU RN01 Nimble 6 http://bit.ly/1zFV3vR RN02 Nimble 0 http://bit.ly/1OBF7Sm RN03 Nimble 5 http://bit.ly/1HQ3sUk RN05 Nimble 0 http://bit.ly/1DIlViN RN06 Nimble 1 http://bit.ly/1HeD4V4 RN08 Nimble 4 http://bit.ly/1J6tqoc RN09 Nimble 4 http://bit.ly/1J6v2OJ RN10 Nimble 4 http://bit.ly/1Qf2HI1 RN11 Nimble 3 http://bit.ly/1Eo4VSv RN12 Nimble 4 http://bit.ly/1PblToP RN13 Nimble 4 http://bit.ly/1Damy0R RN14 Nimble 4 http://bit.ly/1aOSkK5 RN15 Nimble 3 http://bit.ly/1HQZ5Zm RN16 Nimble 4 http://bit.ly/1yMfOuO RN18 Nimble 5 http://bit.ly/1PbDooL RN19 Nimble 2 http://bit.ly/1G3wSd4 RN21 Nimble 4 http://bit.ly/1DJ7OcX RN22 Nimble 6 http://bit.ly/1Htnrb5 RN23 Nimble 5 http://bit.ly/1Oe8rmW RN24 Nimble 4 http://bit.ly/1HUqdXb RN25 Nimble 7 http://bit.ly/1bivzPi RN26 Nimble 6 http://bit.ly/1bivPh8 RN27 Nimble 4 http://bit.ly/1cZroZO RN28 Nimble 6 http://bit.ly/1JtxNGJ RN29 Nimble 5 http://bit.ly/1HkrfwS RN30 Nimble 2 http://bit.ly/1IHocvJ RN31 Nimble 2 http://bit.ly/1IHocvJ RN32 Nimble 7 http://bit.ly/1HkuEf7 RN33 Nimble 3 http://bit.ly/1biA8cr RN34 Nimble 2 http://bit.ly/1bug3R6 Details about unbounded requirements 2/2
Table A.6.: B ASSIGNMENTOFATTRIBUTES ACMP AAVL ADPL ASTB ACST ATME ARLB RP02 x x RP03 x x x RP05 x x RP06 x x x RP07 x x x RS01 x RS03 x RS04 x x x x x RS05 x x x x RS06 x x RS08 x RS12 x x x x RS13 x RS15 x RS17 x RS18 x RS24 x x x x x RS25 x x x RS26 x x x x RS27 x RS28 x RS29 x x RS30 x x RS31 x RS32 x x x x RS33 x x RFF01 x x x x RFF03 x x x x RFF05 RFF06 x x RSY02 x x RSY03 x x x x RSY04 x x x x RSY05 x x x x RSY06 x x x x RC01 x x x x RC04 x x RC05 x x RC06 x x x RC07 x x Unbounded requirements and attributes 1/4
Table B.1.:
101 102 ACMP AAVL ADPL ASTB B.ACST AssignmentATME of AttributesARLB RC08 x x RC09 x x RC10 x x x x RC11 x x RC12 x x RC13 x x RC14 x x ROD03 x x x ROD04 x ROD05 x x x x RN01 x x RN02 x RN03 x x x x RN05 x x RN06 x x RN08 x x x RN09 x x RN10 x x RN11 x x x RN12 x x x RN13 x x RN14 x x RN15 x x x RN16 x x RN18 x x x x RN19 x RN21 x x x RN22 x x RN23 x x x x RN24 x x RN25 RN26 x x x x RN27 x x RN28 x x RN29 x x x RN30 x x x RN31 x x x RN32 RN33 x x x RN34 x x x Unbounded requirements and attributes 2/4
Table B.2.: 103 AEXP ATRS ACRC ARSP B.ASFT AssignmentAMNT of AttributesAINT RP02 x x x RP03 x x RP05 x x x RP06 x x x x RP07 x x x x x RS01 x x x RS03 x x x x x x RS04 x x RS05 x x x RS06 x x x RS08 x x x RS12 x x x RS13 x x RS15 x x x x RS17 x x x RS18 x x RS24 x x x x x x RS25 x x x RS26 x x x RS27 x x x x RS28 x x x RS29 x x x x RS30 x x x x x RS31 x RS32 x x x x RS33 x x x x RFF01 x x x x x RFF03 x x x x RFF05 RFF06 x x RSY02 x x RSY03 x x RSY04 x x x RSY05 x x RSY06 x x RC01 x x RC04 x RC05 x RC06 x x RC07 x x x Unbounded requirements and attributes 3/4
Table B.3.: 104 ACMP AAVL ADPL ASTB B.ACST AssignmentATME of AttributesARLB RC08 x x x RC09 x RC10 x x x RC11 x RC12 x RC13 x RC14 x ROD03 x x ROD04 x x x ROD05 x x x x RN01 x x RN02 x x x x RN03 x x x x x x RN05 x x x x x RN06 x x x x RN08 x x RN09 RN10 x x RN11 x RN12 x RN13 x x RN14 x x RN15 x RN16 x RN18 x x x x x x RN19 x x RN21 x x RN22 x x RN23 x x x x x x RN24 x RN25 x x x RN26 x x x RN27 RN28 x x x RN29 x x x RN30 x RN31 x RN32 x x x RN33 x RN34 x x x Unbounded requirements and attributes 4/4
Table B.4.: C SOCIALNETWORKANALYSIS
As shown in Chapter 2 we identified quality attributes that are of potential importanceattributes to unbounded assignment requirements. On grounds of existing literature the attributes are used to identify patterns in unbounded requirements. As recognizing patterns manually can yield distortions and inaccurate results we attempt to utilize a less biased algorithmic solution. Manual pat- tern recognition is infeasible due to the amount of labor needed and the prospective error-prone process. To recognize patterns in requirements we first attempted to find out about the qualities of these unknown require- ments. Based on the identified quality attributes from Ch. 2 we determine the descriptive qualities of our sample by assigning them to requirements. The attributes were chosen and allocated to requirements based on the de- scriptions, suitability and meaning of the requirements and attributes. This process has been carried out subjectively. The goal is to aid the pattern recognition and form reasonable set of pattern groups. The purpose of this procedure is to deliver an algorithmic solution for pattern recognition. The process of assignment has followed certain logical principles. Such as using people as a computing capacity will be more costly than an al- gorithm; people will be less likely available instantly than a service or an algorithm; people’s opinions can vary and therefore are not suitable for com- posing multiple sources; people are inherently unreliable and cause errors; the more sources used the more resources have to be allocated for maintain- ing the system; the more sources the more possible threats to integrity and coherence of results; external sources can be of a potential risk to safety; us- ing services in forms of APIs might be charged and might be free of charge; etc. With using common sense we came up with the following hypothetical effects of the types of unboundedness on the attributes: (+) shows positive correlation, (0) neutral relation or both negative and positive at the same time. Lastly, (-) expresses negative relation. TableC. 1 shows these effects in detail. A shortened version of which attributes were assigned to which require- ments is shown in TableC. 2. Please consult AppendixB for the full tables.
105 C. Social Network Analysis 106
Algorithm Information Service People Composability + + + - Availability + 0 - - Deployablity - 0 0 + Stability + + - - Cost - 0 0 + Time + + 0 - Reliability + - + - Expertise 0 0 0 + Trustworthiness + 0 0 + Correctness + + + - Responsiveness + 0 - - Safety + + - - Maintainability - - + + Integrity - - + + Attributes and their correlations
Table C.1.:
RP02 RP03 RP05 RP06 RP07 RS01 RS03 ACMP x x x AAVL x x x x ADPL x x x x ASTB x x ACST ATME x ARLB x AEXP x x x x x x ATRS x x x x x ACRC x x x x ARSP x x x ASFT AMNT x x x x AINT x x x x Assignement of requirements to attributes
Table C.2.: D TESTINGSAMPLE ID Refined Title PT-T-01 Dubbing - Provide audio tracks for movies and TV shows in the main world languages PT-T-02 The app should have english versions of anime shows PT-T-03 The app should suggest similar movies to a particular movie PT-T-04 Suggest movies that are suitable for the user based on his/her ratings PT-T-05 The app should feature multiple audio languages for movies and TV shows PT-T-06 User rating system that shows popular movies on a pop- ular tab PT-T-07 The app shall release an alert when a new episode of the user’s interest is released PT-T-08 Original movie subtitles translation - PopcornTime should translate the orginal subtitles of a movie into the user pre- ferred language PT-T-09 The app shall auto mark movies that the user has finished watching PT-T-10 Suggest movies that are suitable for the user PT-T-11 Suggest movies that the user has not seen and are possibly of his/her interest PT-T-12 The app should provide other torrents than YTS PT-T-13 The app shall feature Live TVs PT-T-14 Translations for movie/series descriptions PT-T-15 Add more torrent sources for TV shows PT-T-16 The system should remember permanently which movies a user has seen PT-T-17 The app should have more versions of subtitles for a par- ticular language Testing requirements 1/2
Table D.1.:
107 108 ID Refined Title D. Testing Sample PT-T-18 Add subtitles automatically to movies that use fictional languages PT-T-19 The app should introduce a reasonable amount of docu- mentaries PT-T-20 The app shall provide more TV shows and complete sea- sons PT-T-21 The app should feature multiple audio languages for movies and TV shows PT-T-22 The app should have more complete database of movies and TV shows RS-T-01 Translation - The user interface should be avialable in any language RS-T-02 Current Contact’s time - The system should have informa- tion of the contact’s current time zone and suggest when to phone up RS-T-03 Autopopulate the contact address after entering a zip code RS-T-04 Spell check feature for Rich text fields RS-T-05 Email servers - Allow to integrate any email client RS-T-06 Auto follow and unfollow - The system should accurately determine which contacts should be followed and which should be unfollowed based on suitability RN-T-01 Identify important people - The app should automatically identify important contacts with respect to their position in a company RN-T-02 The app should release a notification when company’s name or user’s name is mentioned anywhere on the web RN-T-03 Automatically fetch company logo from company website - Auto-detect a company logo on a company website and store it in Nimble RN-T-04 Harvest email signature - The app should be able to har- vest email signatures and store contacts structurally RN-T-05 Localisation support - Nimble shall support any language available in the world RN-T-06 Nimble shall track all contact’s interactions including calls, social media, emails, personal meetings RN-T-07 Determine relationships among contacts - Nimble to link contacts based on their mutual relationship RN-T-08 Import 2nd degree contacts from social media to deter- mine possible relationship among contacts Testing requirements 2/2
Table D.2.: 109 ID App Matching Pattern Link D. Testing Sample PT-T-01 PopcornTime Completetness http://bit.ly/1I1KQxc PT-T-02 PopcornTime Completetness http://bit.ly/1Gstflh PT-T-03 PopcornTime Separator http://bit.ly/1I1LmLn PT-T-04 PopcornTime Subjectivity http://bit.ly/1GstCfB PT-T-05 PopcornTime Completeness http://bit.ly/1Gsw8T1 PT-T-06 PopcornTime Separator http://bit.ly/1GswIQG PT-T-07 PopcornTime None http://bit.ly/1GszMfz PT-T-08 PopcornTime None http://bit.ly/1I1RS4Z PT-T-09 PopcornTime Detector http://bit.ly/1ICZ4Vl PT-T-10 PopcornTime Subjectivity http://bit.ly/1BYC46A PT-T-11 PopcornTime Subjectivity http://bit.ly/1BYLcIc PT-T-12 PopcornTime Completeness http://bit.ly/1ID7kVq PT-T-13 PopcornTime Completeness http://bit.ly/1BYLxLd PT-T-14 PopcornTime Completeness http://bit.ly/1ID7Pia PT-T-15 PopcornTime Completeness http://bit.ly/1BYLPli PT-T-16 PopcornTime None http://bit.ly/1ID97d8 PT-T-17 PopcornTime Completeness http://bit.ly/1BYNkjc PT-T-18 PopcornTime None http://bit.ly/1BYNAPh PT-T-19 PopcornTime Completeness http://bit.ly/1IDb4pZ PT-T-20 PopcornTime Completeness http://bit.ly/1BYPwY3 PT-T-21 PopcornTime Completeness http://bit.ly/1BYPNds PT-T-22 PopcornTime Completeness http://bit.ly/1BYPSOm RS-T-01 Salesforce Completeness http://sforce.co/1Fk8NBi RS-T-02 Salesforce Completeness http://sforce.co/1Fo8feI RS-T-03 Salesforce Completeness http://sforce.co/1ebqNVn RS-T-04 Salesforce Detector http://sforce.co/1eIAT0B RS-T-05 Salesforce None http://sforce.co/1eICDXN RS-T-06 Salesforce Subjectivity http://sforce.co/1LzbPqf RN-T-01 Nimble Detector http://bit.ly/1e5xzfz RN-T-02 Nimble Detector http://bit.ly/1e5xOHl RN-T-03 Nimble Scraper http://bit.ly/1e5xRTr RN-T-04 Nimble Scraper http://bit.ly/1e5xWXt RN-T-05 Nimble Completeness http://bit.ly/1e5y5dn RN-T-06 Nimble Completeness http://bit.ly/1FnxcqR RN-T-07 Nimble None http://bit.ly/1FnxhdW RN-T-08 Nimble None http://bit.ly/1FjIOKb Details about testing requirements
Table D.3.: E TESTINGPATTERNS
PT-T-01 - Completeness PT-T-02 - Completeness
PT-T-03 - Separator PT-T-06 - Separator
PT-T-04 - Subjectivity PT-T-05 - Completeness
110 E. Testing Patterns 111
PT-T-07 - None PT-T-09 - Detector
PT-T-10 - Subjectivity PT-T-11 - Subjectivity
PT-T-12 - Completeness PT-T-13 - Completeness
PT-T-14 - Completeness PT-T-15 - Completeness
PT-T-17 - Completeness PT-T-18 - None E. Testing Patterns 112
PT-T-19 - Completeness PT-T-20 - Completeness
PT-T-21 - Completeness PT-T-22 - Completeness
RS-T-01 - Completeness RS-T-02 - Completeness
RS-T-03 - Completeness RS-T-04 - Detector
RS-T-06 - Subjectivity RN-T-01 - Detector E. Testing Patterns 113
RN-T-02 - Detector RN-T-03 - Scraper
RN-T-04 - Scraper RN-T-05 - Completeness
RN-T-06 - Completeness RN-T-07 - None
RN-T-08 - None