Content

Towards a Knowledge Based Agile Product Line Requirements Engineering Framework: Collection of Expertise and its Application to RUP Based Process Templates Kunwu Feng April 29, 2008 Supervisor: Dr. Cooper, Kendra Committee members Dr. Cangussu, João W. Dr. Chung, Lawrence Dr. Mili, Rym 1 Abstract The development of software products that meet the stakeholders‘ needs, are high quality, and developed in a timely and cost-effective now faces additional, emerging challenges including geographic distribution (due to outsourcing, development in multi-national companies, etc.), rapidly changing business environments, and rapidly changing development technologies. These challenges have driven research in a number of (separate) areas in the software engineering community, including software product line engineering (SPLE) techniques and agile methods. Software product lines refer to engineering techniques for creating a portfolio of similar software systems from a shared set of software assets using a common means of production. SPLE techniques are practices-based, or plan-driven, software development processes in which a set of software-intensive systems that share a common, managed set of features are produced from a set of re-usable core assets in a prescribed way [76] [31]. A core asset is a software artifact that is re-used in the production of customized products in a software product line (SPL). The assets include the requirements, architecture, components, modeling and analysis, and plans. The core assets are identified in a separate activity, called domain engineering. A SPL product can be quickly assembled from core assets, called application engineering, to achieve manufacturing efficiency. A goal of SPLEs are to support mass customization, which is "producing goods and services to meet individual customer's needs with near mass production efficiency" [18][10]; customers can obtain a unique product by having their requirements assessed with respect to the core assets before production begins [10]. Numerous SPLE approaches for software development are available [31] [76] [20][21]; however, guidance on selecting the most appropriate choice is lacking. Agile methods offer solutions that provide lighter weight, faster, and nimbler software development processes that allow developers to quickly create high quality software in rapidly changing business environments. The Agile Manifesto [3] has been proposed to uncover better ways of developing software. The values presented are prioritized. For example, Individuals and interactions are valued more than processes and tool, working software is valued more than comprehensive documentation, customer collaboration over contract negotiation, and responding to change over following a plan. The agile manifesto also welcomes changing requirements, even late in development. Numerous agile process definitions are available; a survey on SCRUM, XP, DSDM, Crystal, Feature driven development is available in [60]. The relative degree of agility of well known methods is discussed in [20]; guidance on choosing the most appropriate AM for a project is lacking. The importance of defining an RE process that is best suited for a project has been discussed in the literature [32] [158][116][159]. The benefits of applying a well suited RE process on a project will increase the productivity of the development teams, reduce products‘ time-to-market and development costs, and improve customer satisfaction. To date, the definition of a RE process that is well suited for a project in terms of the degree of agility for SPLE projects has not been addressed. It is interesting to note that 2 although the goals of product line engineering and agile methods have similarities (rapidly develop high quality, complex software), very limited work to integrate the disciplines is available [34]. The broad scope of the research included proposing new approach that can assist in defining a well-suited RE process for developing agile, product line applications is needed. The approach should:      propose a product line RE process to a (non-expert ) user with a tailored level of agility for a project that an expert would propose use well recognized, widely available data as input (e.g., estimated size of the project in lines of code) use process standards (e.g., RUP) as the foundation for the process definitions present the recommend process to the user in a visual modeling language (e.g., UML activity diagrams) be automated and embodied in easy to use tool support The solution selected to address this broad problem is to provide an expert system. An expert system is a software application that ―contains knowledge about a particular field to assist human experts or to provide information to people who do not have access to an expert in the particular field‖ [92]; they emulate human cognitive skills such as decision making, language understanding, visual perception, etc. [48][52] [122][123][1][13][125]. For our problem, the challenges in easily finding experts (geographic distribution, mix of academic and practitioners, etc.) lead us to an expert system solution. Expert systems for software engineering problems have been discussed in the literature since the 1980‘s [163][164]. Examples include systems for project and risk management, change control, RE, design, quality and defect prediction, metrics and measurement, and rapid prototyping have been proposed; these have applied a variety of techniques including rule bases (traditional and fuzzy) and BBNs [10] [12][14]. For this dissertation, two major elements of the framework will be investigated, which are essential for developing the expert system. The first is the questionnaire and the second is the process template repository. A questionnaire to collect data from experts in the community will be used. Questionnaires are frequently used to collect a wide range of data from a potentially large number of respondents. Questionnaires vary in length, focus, and types of items (e.g., checklists, scaled items, or open-ended questions) and are particularly useful in gathering data from large groups of people about perceptions, attitudes, intended actions or application of learning. Often they are the only feasible way to ensure that the number of respondents is large enough to allow statistical analysis of the results. Questionnaires can be classified into open and close questions. An open-question questionnaire provides more information than a closed one. The complexity for the analysis of the data provided by open questions is higher than those in closed-questions [71]. It has been argued that the use of questionnaire consumes less time, effort and financial resources than other methods of data collection like interviews or document reviews [100]. A well-designed questionnaire can gather information on both the overall performance of the activity as well as information on specific components. Questionnaires have been used in many domains, such as customer 3 services [6][9], preventative medicine [10], and in software engineering [10][29]. The purpose of the questionnaire is to collect experts‘ opinions. These data will be used to feed into a Bayesian-Belief Network (BBN) Engine. The BBN Engine is automatically created using structured learning techniques and maintained (improved) using data mining techniques. Meanwhile, these data will be evaluated to develop APLE-RE Process Repository. The repository contains a set of process templates. In the template, the processes will be tailored versions of the RUP and will be presented in UML activity diagrams. The user can tailor the process definition and publish it. The set of tailored RUP process templates are range from very agile to plan driven approaches for single product and product line RE. In the future, the next steps are to develop the GUI for the expert system and integrate it with the BBN. The expert system GUI will prompt the user with a series of questions about the project, provide the data to the BBN engine layer, and present the most likely process definitions to the user. The processes will be tailored versions of the RUP and will be presented in UML activity diagrams, which comes from the APLE-RE Process Repository. 4 Table of Contents List of Figures ............................................................................................................. 9 List of Tables ............................................................................................................ 10 1 Introduction .................................................................................................. 11 1.1 Motivation................................................................................................. 11 1.2 Research Problems Addressed in this Dissertation ................................. 15 1.2.1 Questionnaire Problem ................................................................... 16 1.2.2 Process Repositoy Problem ............................................................ 16 1.2.3 Technique Repositoy Problem ........................................................ 17 1.3 Proposed Solution .................................................................................... 18 1.3.1 Introduction ..................................................................................... 18 1.3.2 Problem Analysis and Background Studies .................................... 18 1.3.3 Questionnaire Development ............................................................ 18 1.3.4 APLE-RE Process Repostitory Development .................................. 19 1.3.5 RE Process Models and Techniques Identification ......................... 19 1.3.6 APLE-RE Process Templates Validation ........................................ 19 1.4 Contributions ............................................................................................ 20 1.5 Structure of the Proposal ......................................................................... 20 2 Background.................................................................................................. 21 2.1 Software Engineering ............................................................................... 21 2.1.1 Introduction ..................................................................................... 21 2.1.2 Software Development Process Models ......................................... 22 2.1.2.1 The Waterfall Model .................................................................. 22 2.1.2.2 The Incremental Model ............................................................. 22 2.1.2.3 The Spiral Model ....................................................................... 23 2.2 Rational Unified Process .......................................................................... 23 2.3 Requirements Engineering ....................................................................... 26 2.3.1 Introduction ..................................................................................... 26 2.3.2 Why Requirement Engineering ....................................................... 27 2.3.3 Requirements Engineering Process ................................................ 28 2.3.3.1 Requirements elicitation ............................................................ 29 2.3.3.2 Requirements Analysis and Negotiation ................................... 29 2.3.3.3 Requirements Documentation................................................... 29 2.3.3.4 Requirements Verification and Validation .................................. 30 2.3.3.5 Requirements Management ...................................................... 30 2.4 Product Line ............................................................................................. 30 2.4.1 Overview ......................................................................................... 31 2.4.1.1 Domain Engineering ................................................................. 31 2.4.1.2 Application Engineering ............................................................ 32 2.4.1.3 Variability .................................................................................. 32 2.4.2 Documenting Variability in Requirement Artifacts ............................ 34 2.4.2.1 Domain Requirements Engineering .......................................... 36 2.4.2.2 Application Requirements Engineering ..................................... 37 2.5 Agile Methods .......................................................................................... 38 2.5.1 Overview ......................................................................................... 38 2.5.2 The Agile Manifesto......................................................................... 39 2.6 Conclusion ............................................................................................... 40 3 Related Work ............................................................................................... 42 5 Questionnaire Related Work .................................................................... 42 3.1.1 Questionnaire in Software Engineering ........................................... 42 3.1.2 Questionnaire in Requirement Engineering .................................... 43 3.2 Tailoring RUP Related Work .................................................................... 45 3.2.1 Introduction ..................................................................................... 45 3.2.2 Tailoring for Agility ........................................................................... 46 3.2.2.1 dX: A minimal RUP process: ..................................................... 46 3.2.2.2 Agile Unified Process ................................................................ 47 3.2.2.3 Open Unified Process ............................................................... 49 3.2.3 Tailoring for Product Line ................................................................ 51 3.2.3.1 Product Line UML-Based Software Engineering ....................... 51 3.2.3.2 Enhanced Milestones in Product Line ....................................... 52 3.2.3.3 Unified Process Enhanced with Product Line ........................... 53 3.3 Conclusion ............................................................................................... 53 4 A Framework for Agile Product Line Requirement Engineering Process Development (APLE-RE) ......................................................................................... 57 4.1 Introduction .............................................................................................. 57 4.2 Expert System .......................................................................................... 59 4.3 Methodologies and Repository................................................................. 60 4.3.1 APLE-RE Questionnaire ................................................................. 60 4.3.2 APLE-RE Repository....................................................................... 61 4.3.3 APLE-RE Techniques...................................................................... 61 4.4 Foundations ............................................................................................. 61 4.5 Conclusion ............................................................................................... 61 5 APLE-RE Questionnaire .............................................................................. 62 5.1 Introduction .............................................................................................. 62 5.2 Methodology ............................................................................................ 63 5.3 Collect Expert’s Background .................................................................... 65 5.4 Define Project Scenarios.......................................................................... 66 5.5 Present Scenarios to Expert .................................................................... 70 5.5.1 Project Scenarios ............................................................................ 71 5.5.2 Narrow Down Algorithm (informal description) ................................ 72 5.5.3 Narrow Down Algorithm (formal description) ................................... 79 5.5.3.1 Definitions ................................................................................. 79 5.5.3.2 Formal Description .................................................................... 82 5.6 Implementation ........................................................................................ 88 5.7 Conclusions ............................................................................................. 90 6 APLE-RE Process Repository ..................................................................... 91 6.1 Introduction .............................................................................................. 91 6.2 Methodology ............................................................................................ 91 6.3 Product Line RE Process Template.......................................................... 95 6.3.1 Domain Requirement Engineering .................................................. 96 6.3.1.1 Elicitation Phase ....................................................................... 97 6.3.1.2 Specification Phase ................................................................ 102 6.3.1.3 Analysis Phase ....................................................................... 105 6.3.1.4 Negotiation Phase .................................................................. 107 6.3.1.5 Validation Phase ..................................................................... 109 6.3.2 Application Requirement Engineering ........................................... 112 6.3.2.1 Elicitation Phase ..................................................................... 112 6.3.2.2 Specification Phase ................................................................ 113 3.1 6 6.3.2.3 Analysis Phase ....................................................................... 115 6.3.2.4 Negotiation Phase .................................................................. 115 6.3.2.5 Validation Phase ..................................................................... 116 6.4 Agile Product Line RE Process Template............................................... 117 6.4.1 Domain Requirement Engineering ................................................ 117 6.4.1.1 Elicitation Phase ..................................................................... 118 6.4.1.2 Specification Phase ................................................................ 121 6.4.1.3 Analysis Phase ....................................................................... 123 6.4.1.4 Negotiation Phase .................................................................. 125 6.4.1.5 Validation Phase ..................................................................... 127 6.4.2 Application Requirement Engineering ........................................... 128 6.4.2.1 Elicitation Phase ..................................................................... 128 6.4.2.2 Specification Phase ................................................................ 129 6.4.2.3 Analysis Phase ....................................................................... 130 6.4.2.4 Negotiation Phase .................................................................. 130 6.4.2.5 Validation Phase ..................................................................... 131 6.5 Conclusion ............................................................................................. 131 7 APLE-RE Techniques ................................................................................ 132 7.1 Introduction ............................................................................................ 132 7.2 Modified RE Process ............................................................................. 132 7.2.1 Elicitation Phase............................................................................ 133 7.2.2 Specification Phase ....................................................................... 133 7.2.3 Analysis Phase ............................................................................. 133 7.2.4 Negotiation Phase ......................................................................... 134 7.2.5 Validation Phase ........................................................................... 134 7.3 Methodology for Technique Evaluations................................................. 135 7.4 RE Techniques Review and Analysis ..................................................... 137 7.4.1 Elicitation Phase............................................................................ 137 7.4.1.1 Brainstorming .......................................................................... 137 7.4.1.2 Designer as Apprentice ........................................................... 137 7.4.1.3 Cooperative Requirements Capture (CRC) ............................ 138 7.4.1.4 Interviews ................................................................................ 138 7.4.1.5 Focus Groups ......................................................................... 139 7.4.1.6 Future Workshops................................................................... 141 7.4.1.7 Document Mining .................................................................... 141 7.4.1.8 Observation and Social Analysis / Ethnography ..................... 142 7.4.2 Specification Techniques ............................................................... 144 7.4.2.1 Informal Modeling ................................................................... 144 7.4.2.2 Semiformal Modeling .............................................................. 144 7.4.2.3 Formal Modeling ..................................................................... 146 7.4.2.4 Requirements checklists ......................................................... 146 7.4.2.5 Requirements Reuse .............................................................. 147 7.4.3 Analysis Phase ............................................................................. 149 7.4.3.1 Joint Application Development (JAD) ...................................... 149 7.4.3.2 Goal-Oriented RE ................................................................... 149 7.4.3.3 Prioritization ............................................................................ 150 7.4.3.4 Quality Function Deployment .................................................. 151 7.4.3.5 Blitz Quality Function Deployment .......................................... 152 7.4.4 Negotiation Techniques ................................................................. 153 7.4.4.1 Distributive Negotiation ........................................................... 153 7 7.4.4.2 Integrative Negotiation ............................................................ 153 7.4.5 Validation Techniques ................................................................... 153 7.4.5.1 Evolutionary Prototyping ......................................................... 153 7.4.5.2 Exploratory Prototyping........................................................... 154 7.4.5.3 Requirements Reviews ........................................................... 155 7.4.5.4 Requirements Testing ............................................................. 156 7.5 Conclusion ............................................................................................. 157 8 Conclusion and Future Work ..................................................................... 158 8.1 Summary of Research ........................................................................... 158 8.2 Limitations .............................................................................................. 159 8.3 Future Work ........................................................................................... 159 8.4 Key Issues ............................................................................................. 160 8.5 Anticipated Contributions of the Completed Research ........................... 161 Reference............................................................................................................... 162 Appendix A: Product Line Methods ........................................................................ 169 Appendix B: Agile Methods .................................................................................... 174 Appendix C: Constructive Research Approach ...................................................... 178 8 List of Figures Figure 1. The Planning Spectrum ................................................................................. 14 Figure 2. Iterative Waterfall Model ................................................................................ 22 Figure 3. Spiral Model .................................................................................................. 23 Figure 4. The Rational Unified Process ........................................................................ 24 Figure 5. Overview of UMA .......................................................................................... 25 Figure 6. “Class Diagram” of RUP ................................................................................ 25 Figure 7. Activity Diagram for Product Line Engineering ............................................... 31 Figure 8. Example of Variation point and Variant .......................................................... 33 Figure 9. Using include relationship to represent variation point and variant................. 35 Figure 10. Example of feature models .......................................................................... 36 Figure 11. The Components of the APLE-RE Framework ............................................ 58 Figure 12. Developing the Expert System .................................................................... 60 Figure 13. The Components of the Questionnaire ........................................................ 63 Figure 14. Developing the Questionnaire ..................................................................... 63 Figure 15. Developing the Questionnaire ..................................................................... 64 Figure 16. Developing the Scenarios ............................................................................ 68 Figure 17. Narrow Down Algorithm ............................................................................ 72 Figure 18. Identify initial set of project scenarios closely matching additional input constraints............................................................................................................. 75 Figure 19. Select Superset of Closely Matching Scenarios (relax constraints).............. 77 Figure 20. Select Subset of Closely Matching Scenarios .............................................. 79 Figure 21. APLE-RE Questionnaire Welcome Screen .................................................. 89 Figure 22. APLE-RE Questionnaire Part I .................................................................... 89 Figure 23. APLE-RE Process Repository ..................................................................... 93 Figure 24. Template to Structure of an APLE-RE Process Template ............................ 95 Figure 25. Activity Diagram for Product Line Engineering ............................................. 96 Figure 26. Activity Diagram for Domain Requirement Elicitation Phase ........................ 97 Figure 27. Activity Diagram for Domain Requirement Specification Phase ................. 102 Figure 28. Activity Diagram for Domain Requirement Analysis Phase ........................ 105 Figure 29. Activity Diagram for Domain Requirement Negotiation Phase ................... 107 Figure 30. Activity Diagram for Domain Requirement Validation Phase...................... 110 Figure 31. Activity Diagram for Application Requirement Elicitation Phase ................. 112 Figure 32. Activity Diagram for Application Requirement Specification Phase ............ 114 Figure 33. Activity Diagram for Application Requirement Analysis Phase ................... 115 Figure 34. Activity Diagram for Application Requirement Negotiation Phase .............. 116 Figure 35. Activity Diagram for Application Requirement Validation Phase ................ 117 Figure 36. Activity Diagram for Application Requirement Elicitation Phase ................. 119 Figure 37. Activity Diagram for Application Requirement Specification Phase ............ 122 Figure 38. Activity Diagram for Application Requirement Analysis Phase ................... 124 Figure 39. Activity Diagram for Application Requirement Negotiation Phase .............. 125 Figure 40. Activity Diagram for Application Requirement Validation Phase ................ 127 Figure 41. Activity Diagram for Application Requirement Elicitation Phase ................. 128 Figure 42. Use Case Model ........................................................................................ 169 Figure 43. KobrA ........................................................................................................ 171 Figure 44. Feature Driven Development ..................................................................... 176 Figure 45. The central elements of the constructive research approach ..................... 178 Figure 46. A Typical Constructive Research Process ................................................. 179 9 List of Tables Table 1. Cost and time overruns................................................................................... 28 Table 2. Project success, challenged, and impaired factors ......................................... 28 Table 3. Comparison between RUP and AUP .............................................................. 48 Table 4. Comparison between RUP and OpenUP ........................................................ 50 Table 5. Questionnaire Reviewed for APLE Development ............................................ 54 Table 6. RUP Tailoring Reviewed for APLE Development ............................................ 55 Table 7. The Eight Steps Recipe to Get Started with RE .............................................. 55 Table 8. Project Characteristics Set Definition .............................................................. 80 Table 9. Scenario Domain Set Definition ...................................................................... 80 Table 10. Answer Set Definition ................................................................................... 80 Table 11. Result Set Definition ..................................................................................... 81 Table 12. Initial Constraint Definition ............................................................................ 81 Table 13. Closet function Definition .............................................................................. 81 Table 14. Search function Definition ............................................................................. 82 Table 15. Formal Description ....................................................................................... 83 Table 16. Single Product RE Process Templates ......................................................... 93 Table 17. Forward Product Line RE Process Templates .............................................. 94 Table 18. Reverse Product Line RE Process Templates .............................................. 94 10 1 Introduction 1.1 Motivation Software engineering is the application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software [65]. It is a complex task that can ensure the product maintainability, dependability, efficiency, usability, etc. Software development is in general divided into four phases which are requirements, design, code, and testing phases [2]. The research focuses on the requirements phase and how it can support software development. The requirements phase has been a part of software development ever since the first software development process was suggested in 1970 [3]. As one of the processes in software engineering, requirement engineering (RE) plays an important role to ensure the success of software projects. More and more researches are put on the RE in the past twenty years. ―A lack of clarity in specification is one of the surest signs of deficiency in the program it describes‖, [62] said by Hoare, the winner of the 1980 ACM Turing Award. Fred Brook, the recipient of the 1999 ACM Turing Award, emphasized that: ―The hardest single part of building a software system is deciding precisely what to build. No other part of the conceptual work is as difficult as establishing the detailed technical requirements…no other part of the work so cripples the resulting system if done wrong. No other part is more difficult to rectify later‖ [26]. However, in practice RE presents many problems and challenges for practitioners even today. Requirements related risks are rated among the biggest risk factors for software projects [74], and RE has been found as a major cause for many software project failures [9].RE faces numerous challenges [69] [16]: There is not one problem in RE, but a tangled web of related problems. Thus, the problem boundary is vague, and yet has to be identified during the RE process. RE intersects with many disciplines, i.e. it involves social, cultural, economic, environmental, organizational, political, and even psychological issues. Many aspects involved in the RE process interact on various levels. For example, the activities, the people, and techniques in the RE process interact with each other. In addition, different business concerns and constraints of the software project interact with each other. Different application domains and different characteristics of specific projects make it impossible to apply the same technique to all different cases, i.e. there is no silver bullet. A wide range of software engineering paradigms have been devised to improve the software development process (e.g., Aspects, Agile Software Development, Experimental software engineering, Model-driven, Software Product Line, etc.). Each successive development either claims to make the engineering process easier or to extend the complexity of applications that can feasibly be built. Although there is some 11 evidence to support these claims, researchers continually strives for more efficient and powerful requirement engineering techniques, especially as solutions for ever more demanding applications are required. Software projects need to reach a balance among several important goals: software functionality and quality, cost, and timely delivery. A software product line is a set of software-intensive systems sharing a common, managed set of features that satisfy the specific needs of a particular market segment or mission and that are developed from a common set of core assets in a prescribed way. [10] The concepts for developing a software product line include have been drawn from established techniques to efficiently produce large quantities of goods or services. The original assembly line developed by Henry Ford has evolved into mass customization techniques as a means to support the large-scale production of goods or services that are tailored to individual customers‘ needs. For example, consider a car manufacturing application, as in [76], where a car manufactory produces a large number of cars in several models, and each model can meet different customers‘ needs; however there is no product line in place. Customers can ask for specific customized orders. The company, according to different customer‘s different requirements, creates relatively higher technological investments to satisfy each customer‘s need. This causes higher prices and investments for each products and lower profit for the company. Under such conditions, many companies, such as car companies, invented a new strategy that by introducing common platforms for different types of cars to reduce the investment after they have planned at the beginning which parts will be different. This strategy has been applied in software product line development to accomplish the same goal: efficiently meet the needs of diverse stakeholders in a common domain by developing a set of core assets, or platform, and customizing it. In the product line context, a platform is a ―set of software subsystems and interfaces that form a common structure from which a set of derivative products can be efficiently developed and produced.‖ [76] The subsystems that are a part of a software platform not only contain code but also requirements, architecture, and other artifacts of the development process. Product lines have been successfully used in a number of domains including cameras [76]], printers [17], and mobiles [68]. The Kodak Company significantly increased profits by a factor of 14 in 6 years and conquered 70% US market after they started to produce various cameras models in a common platform. The Hewlett-Packard Company‘s product line approach for software involves whole products, such as families of printers, and tends to be very effective when it drives products that have multiple simultaneous releases and involves rapid time-to-market schedules. The global leader in mobility, Nokia, provides three main software product families for mobile terminals, Series 40, Series 60 and Maemo. Established SPLE techniques are practices-based, or plan-driven, software development processes in which a set of software-intensive systems that share a common, managed set of features are produced from a set of re-usable core assets in a prescribed way [76] [17]]. A core asset is a software artifact that is re-used in the production of customized products in a software product line (SPL). The assets include the 12 requirements, architecture, components, modeling and analysis, and plans. The core assets are identified in a separate activity, called domain engineering. A SPL product can be quickly assembled from core assets, called application engineering, to achieve manufacturing efficiency. A goal of SPLEs are to support mass customization, which is "producing goods and services to meet individual customer's needs with near mass production efficiency" [18][19]; customers can obtain a unique product by having their requirements assessed with respect to the core assets before production begins [10]. Numerous SPLE approaches for software development are available [31][76] [20][21]; however, guidance on selecting the most appropriate choice is lacking. On the other hand, in the software development discipline, some agile methods such as eXtreme Programming (XP), Scrum, Crystal methods, among others, are generating interest in the industry by the importance of their software development practices, which refer to ―how‖ we can drive the software processes to obtain agility. These agile methods have generated controversy in software engineering context, because they propose foundations, processes, and activities to develop software that are different of plan-driven approaches. Agile methods offer solutions that provide lighter weight, faster, and nimbler software development processes that allow developers to quickly create high quality software in rapidly changing business environments. The Agile Manifesto [86] has been proposed to uncover better ways of developing software. The values presented are prioritized. For example, Individuals and interactions are valued more than processes and tool, working software is valued more than comprehensive documentation, customer collaboration over contract negotiation, and responding to change over following a plan. The agile manifesto also welcomes changing requirements, even late in development. Numerous agile process definitions are available; a survey on SCRUM, XP, DSDM, Crystal, Feature driven development is available in [60]. The relative degree of agility of well known methods is discussed in [20]; guidance on choosing the most appropriate AM for a project is lacking. Boehm place various agile and plan-driven development approaches along a spectrum of increasing emphasis on plans, as Figure 1 shows [22]. In his paper, he argues that agile methods emphasize a fair amount of planning. Their general view, places more value on the planning process than the resulting documentation, so these methods often appear less plan oriented than they really are. Plan-driven methods work best when developers can determine the requirements in advance and when the requirements remain relatively stable, with change rates on the order of one percent per month. In the increasingly frequent situations in which the requirements change at a much higher rate than this, the traditional emphasis on having complete, consistent, precise, testable, and traceable requirements will encounter difficult to insurmountable requirements-update problems. However, in the planning spectrum, Boehm just mentions that in a plan-driven home ground, with a more stable product line of larger, more safety critical systems the major difference between agile methods involves more rework loss from minimal plans. 13 Figure 1. The Planning Spectrum It is interesting to note that although the goals of SPLE and AMs have similarities (rapidly develop high quality, complex software); very limited work to integrate the disciplines is available [34]. In particular, the selection of a requirements engineering (RE) process that is well suited for a project in terms of the degree of agility for SPLE projects has not been addressed. The broad scope of the research included proposing new approach that can assist in defining a well-suited RE process for developing agile, product line applications is needed. The approach should:      propose a product line RE process to a (non-expert ) user with a tailored level of agility for a project that an expert would propose use well recognized, widely available data as input (e.g., estimated size of the project in lines of code) use process standards (e.g., RUP) as the foundation for the process definitions present the recommend process to the user in a visual modeling language (e.g., UML activity diagrams) be automated and embodied in easy to use tool support The solution selected to address this broad problem is to provide an expert system. An expert system is a software application that ―contains knowledge about a particular field to assist human experts or to provide information to people who do not have access to an expert in the particular field‖ [92]; they emulate human cognitive skills such as decision making, language understanding, visual perception, etc. [48][52] [122][123][1][13][125]. For our problem, the challenges in easily finding experts (geographic distribution, mix of academic and practitioners, etc.) lead us to an expert system solution. Expert systems for software engineering problems have been discussed in the literature since the 1980‘s [163][164]. Examples include systems for project and risk management, change control, RE, design, quality and defect prediction, metrics and measurement, and rapid prototyping have been proposed; these have applied a variety of techniques including rule bases (traditional and fuzzy) and BBNs [10] [12][14]. As discussed above, the broad project is related to several areas, including requirements engineering, agile methods, product line practice, BBN and data mining. It can be classified into two categories. Each of 14 them can be a dependent Ph.D study. One is Agile Product Line Requirement Engineering. Also this is what will be discussed in this proposal. Another one is focus on the expert system which includes BBN and data mining. Mr. Yan Tang will focus on these research issues for his Ph.D. thesis. 1.2    Research Problems Addressed in this Dissertation Construct a questionnaire that collects expertise‘ opinions on the definition and use of Agile Product Line Requirement Engineering Process context. Develop an Agile Product Line Requirement Engineering Process Repository Construct an Agile Product Line Requirement Engineering Techniques Repository The three main objectives of the research are to: Using appropriate requirement process models (such as Rational Unified Process, RUP in short) and techniques in a project is becoming the most promising step towards increasing the overall quality of a software product. Requirements define the capabilities, characteristics, performance and quality characteristics of a system. In order to ensure the quality of a software requirement specification, there needs to be a strong emphasis on implementing engineering disciplines into the RE process by using various good practices, techniques and methodologies [43][25][26][38]. As mentioned before, Software Product Line Engineering and Agile Methods are two promising roads to develop qualified projects. However, these two have been considered to be conflicting approaches to develop high quality software in short time with low costs [55][31]. Adoption of the most suitable requirement engineering process and selection of the most appropriate requirement engineering techniques for a given project will assist companies to developing better software. However, process tailoring largely depends on experts' knowledge and might be time-consuming, costly, and error-prone. The research problem is summarized as follows:   Is it possible to tailor existing process with level of agility for a project? Is it possible to develop a tool that support for the development of the most suitable RE process for a product line product using agile methods? There is no universally valid definition of agility; Jim Highsmith defines it as follows [60]: ―Agility is the ability to both create and respond to change in order to profit in a turbulent business environment.‖ In the context of software development processes, it may also mean ―lightweight‖ in the sense of having few work products apart from the actual software [22][142]. In the Product Line context, there has been interest in investigating whether, and if so how, product line and agile can be combined to complement each other. In conjunction with the 2006 Software Product Line Engineering conference a new workshop was arranged; APLE (Agile Product Line Engineering). Tian and Cooper discusses the increasing need for shorter time to market and higher product quality and argues that this combination of practices may lead to this goal. Carbon et al. follows the same motivation and presents preliminary results from a student experiment, yet relevant experience from industry is still needed. 15 The benefits of applying a well suited RE process on a project will increase the productivity of the development teams, reduce products‘ time-to-market and development costs, and improve customer satisfaction. To date, the definition of a RE process that is well suited for a project in terms of the degree of agility for SPLE projects has not been addressed. It is interesting to note that although the goals of product line engineering and agile methods have similarities (rapidly develop high quality, complex software); very limited work to integrate the disciplines is available [34]. These factors lead to the following problems of agility and suitability to product line: 1.2.1 Questionnaire Problem Questionnaire is often used in software engineering and requirements engineering. Collecting a wide range of information from a large number of respondents is important in questionnaire. It needs a large sample size of respondents. In addition, it needs to access geographically distributed respondents from industry and academia. Therefore APLE-RE Questionnaire has been developed as a web based application, which allows for convenient, international access. It follows the guidelines for developing a good questionnaire. More important, few questionnaires can be found in the literatures that cover both requirements processes and techniques. More important, questionnaires in the literatures pay little attention on Agile and Product Line projects. Most of them are focus on traditional single product. For this reason, the APLE-RE questionnaire is designed and implemented in order to obtain the expertise of researchers and practitioners actively involved in software development using agile, product line RE techniques. In summary, the development of questionnaire always faces the following problems:     How to collect a large a number of samples? How to guarantee these samples are geographically distributed from industry and academia? Is there a guideline for developing a questionnaire? Is there any existing questionnaire covering both requirements processes and techniques, and agile methods and product line practices? 1.2.2 Process Repository Problem Tremendous efforts are put into the development of new methodologies for requirement engineering. In addition, tailoring RUP is introduced widely in requirement community. However, these processes are independent, or only for a particular project in a given situation. Another key issue is that selecting an appropriate process models is far behind. There is no guidance to combine agile software development and product line engineering to achieve three basic goals: satisfactory software quality (scope), the right cost and timely delivery. Even worse, there is no existing agile product line requirement engineering process. If one can construct a repository covering a wide range of different projects, this will be a novel contribution in requirements engineering. 16 In summary, the following problems lead to the development of APLE-RE Process Repository:     No existing process model can be placed in wide range of different projects. Selecting an appropriate process models is more difficult than developing a new one. No existing process model combine agile software development and product line engineering. Very limited process repository which containing a set of process models that can suitable for wide range of different projects. In addition, the development of APLE-RE Process Repository will be addressed the following problems:     How many templates should be in the repository? How many templates and which ones should be defined for thesis dissertation? Should they be standards based? Which standard? How to validate the correct and feasibility of these templates. 1.2.3 Technique Repository Problem Glass, in his paper, says that, the industry needs more guidelines on how and when use established software requirements techniques in specific projects for different domains [49]. It is worth mentioning that one of the fundamental assumptions in this research, as well as in the RE community in general, is that appropriate use of RE techniques leads to better-quality requirements specifications, which in turn results in better-quality software products [39][59]. Although all process improvement initiatives are based on the validity of this assumption, its correctness has, to the best of our knowledge, not yet been formally proven. Nevertheless, there is a lot of empirical research which shows the validity of the assertion in numerous situations [26, 25, 37][38] [43]. This research does not focus on invention of new RE techniques but developing an approach which can provide support for the selection or customization of existing RE techniques, and practices for a particular project. In summary, the following problems lead to the development of APLE-RE Process Repository:   No guidelines on how and when use established software requirements techniques in specific projects for different domains. For each technique, there is no evaluation criterion to judge whether it can be placed in the continuum agile, light, and lesser focused methodologies and traditional, more heavyweight methodologies. In addition, the development of APLE-RE Techniques will be addressed the following problems:    How many techniques should be in the repository? What are the criterions to classify these techniques? How to select the most suitable technique for a given situation? 17 1.3 1.3.1 Proposed Solution Introduction This research has three main focuses. The first focus is to collect and analyze the expertise available in the community for choosing an appropriate requirements engineering (RE) process for a product line software project, with specific attention to its degree of agility. In this activity, the stakeholders‘ needs for a software system are elicited, negotiated, specified (documented), analyzed, validated, and managed for change. The second focus is to construct a RE process repository which contains a set of templates. In these templates, the processes will be tailored versions of the RUP and will be presented in UML activity diagrams. The user can tailor the process definition and publish it. The process definitions will be an extensive set of tailored RUP process templates, which range from very agile to plan driven approaches for single product and product line RE. The last focus is to construct a RE technique repository which is a collection of currently identified RE techniques and guidelines on how to use and evaluate these techniques. A new approach that can assist in defining a well-suited RE process for developing agile, product line applications is needed. At a high level, the research has the following steps: Problem analysis and background studies Design and Implement an online questionnaire and scenarios that collect experts‘ opinions on Agile Product Line Requirement Engineering Process context. Develop a Agile Product Line Requirement Engineering Process Repository (APLE-RE) Identify the applicability of RE process models and techniques for specific software projects Validate the proposed framework. The following subsections explain each one of these stages in more detail. 1.3.2 Problem Analysis and Background Studies Problem analysis and background studies are focus on the fundamental requirement engineering topics. Several areas related to the research objective were reviewed with regards to their possible contribution to RE process development. In total, the following disciplines and fields of research were investigated: Requirements Engineering Software Requirement Process Rational Unified Process Software Product Line Engineering Agile Methods 1.3.3 Questionnaire Development Knowledge acquisition is achieved in our research by developing a questionnaire and obtaining the expertise of researchers and practitioners actively involved in software development using agile, product line engineering techniques. Questionnaires are frequently used in quantitative marketing research and 18 social research in general. They are a valuable method of collecting a wide range of information from a large number of respondents. In addition, our questionnaire is web-based, as our (international) respondents are geographically distributed. The questionnaire used in this research is organized into two parts. The purpose of the first part is to collect information about the expert‘s specific area of expertise. For example, some experts may work in embedded software development, web based software development, information systems, and so on. The purpose of the second part of the questionnaire is to present a small set of project scenarios to the expert, which are as closely related to their area of expertise as possible, and obtain the expert‘s opinion about what kind of RE process to use on these projects. 1.3.4 APLE-RE Process Repostitory Development APLE RE Framework is built upon research reported in RE literature and survey results collected from experts in academia and industry. The APLE-RE Process Repository contains a list of process templates. In these templates, the processes will be tailored versions of the RUP and will be presented in UML activity diagrams. The user can tailor the process definition and publish it. In the first phase of the research, the process definitions will be an extensive set of tailored RUP process templates, which range from very agile to plan driven approaches for single product and product line RE. In the second phase of the research, the dynamic composition of process definitions using constraint based techniques will be investigated. 1.3.5 RE Process Models and Techniques Identification The prerequisite to build the Agile Product Line Requirement Engineering Framework is to evaluate the relevant literature. This includes:  RE Techniques: RE techniques is the foundation of the APLE-RE framework. A list of RE techniques will be reviewed and analyzed. In section 5.2, it provides an overview of a selection of requirements engineering techniques based on the revision RE process phases.   Agile Methods and PL principles: In APLE-RE framework, both AMs and SPLE are considered. In section 5.2, existing agile methods and PL principles are reviewed. RUP Foundation: The RE process template are tailored from RUP. In section 2.2, the architecture of RUP is summarized. In section 3.3, several tailored RUP literature are introduced. 1.3.6 APLE-RE Process Templates Validation APLE-RE templates are validated using reverse engineering. Existing case studies are reverse engineered with respect to the RE process used. The closest matching template is identified in the repository. The difference from the template and the actual process used are identified and classified. The difference can be used to indicate the usefulness of the template. 19 1.4 Contributions This interdisciplinary research will make the following novel contributions: The questionnaire will be the largest survey conducted in RE process definition research (ours will have 100 international respondents) and the only one conducted with a specific focus on the adoption of agile methods in product line requirements engineering. The extensive supporting scenario set (over 350) used in the questionnaire allow it to be answered by experts in a wide variety of domains. The results will be freely available for others to re-use. Factors to determine degree of agility in product line RE will be identified. The established criteria proposed by Barry Boehm (size, geographic distribution, etc.) will be extended to rank a rich set of non-functional requirements with respect to their impact on the degree of agility introduced (security, availability, reliability, response time performance, scalability, etc.) A new set of RUP based process templates for single product and product line techniques, with varying degrees of agility, will be proposed. The dynamic definition of RE processes using process element composition techniques will be another contribution to the RE community. Existing RE process knowledge, especially for Product Line process and Agile process, is classified and organized into an Agile Product Line Requirement Process Repository. The repository is built with a clear structure with the intention of helping develop the most suitable APLE process model and selecting techniques for a software project. The case study and the prototype tool developed so far are strong indications that the knowledge base is a valuable asset during process development. 1.5 Structure of the Proposal The structure of this work begins with the introduction and related work of product line and agile methods, which will be present in Chapter 2 and Chapter 3. The overall introduction of the framework will be given in Chapter 4. In Chapter 5, a project process questionnaire is built to collect data from experts in industry and academia. In Chapter 6, a methodology to construct APLE-RE Process Repository is presented. In addition, two templates are introduced, more specific, one for Agile Product Line Requirement Process Model, and one for traditional Product Line Requirement Process Model. Next, in Chapter 7, a common point is suggested between the product line and the agile methods. Afterwards, a methodology for selecting RE techniques for APLE projects is described. This methodology provides step-wise guidelines for the selection of RE techniques based on the characteristics of RE techniques and the project under development. Chapter 9 gives a review and conclusion of the work. Future work is also suggested. 20 2 Background This chapter provides an overview of several topics related to this research project. Firstly, the software engineering models are introduced. Secondly, the requirement engineering activity is described. Following this, agile methods and product line engineering are presented. The conclusion will be given at the end of this chapter. The detailed product line methods and agile methods are presented in Appendix A and Appendix B. 2.1 Software Engineering Software has significantly changed our lives and pervades the world. Over the past 50 years, software has evolved from a specialized problem solving and information analysis tool to an industry itself. 2.1.1 Introduction Software engineering as a discipline was popularized by Fritz Bauer in 1968 [93]. The definition proposed at the NATO Software Engineering Conference serves as a basis: Software engineering is the establishment and use of sound engineering principles in order to obtain economically software that is reliable and works efficiently on real machines. The intent of software engineering is to provide a framework for building higher quality software. It encompasses techniques and procedures, often regulated by a software development process, with the purpose of improving the reliability and maintainability of software systems [43]. However, software engineering is still a young discipline, and is still developing. Software engineering is a layered technology [44]. The foundation for SE is the process layer. Process defines a framework that must be establised for effective delivery using software engineering technology. The functionalities of the software engineering are the following: Manage and control the software projects. Apply proper technical methods. Produce related work products. Establish the milestone Ensure the project quality Manage and control the project change Methods in process layer provide the technical solution for producing the software. It includes a wide range of tasks, such that communication, requirement analysis, designs, implementation, testing and maintenance. Tools provide automated or semi-automated support for the process and the methods. 21 2.1.2 Software Development Process Models One of the goals of this research is to build a requirements process model tailored from RUP. The RE phase of a software project is vital to its success. This was made evident when most of the causes of project failure identified by a Standish Group study in 1995 were related to the RE process Error! Reference source not found.[145]. Furthermore, the cost of repairing requirements-related problems dramatically increases as the software development process progresses [19]. It is therefore evident that the RE process model has important ramifications for the overall success of the project. Several well-known models are discussed in this section, including Waterfall Model [36, 47], Incremental Model [89] and Spiral Model [21]. 2.1.2.1 The Waterfall Model The waterfall model, the oldest paradigm proposed by Royce in 1970 [47], contains distinct development stages that are in strict sequential order, which means an activity begins only after the preceding activity is finished. Additionally, each phase represents a milestone to indicate the end of this phase. The major stages of the model are shown in the following figure. Requirements Design Implementation Testing Maintenance Figure 2. Iterative Waterfall Model In an ideal world, changing back to prerequisite activity is not encouraged in the Waterfall Model, which can reduce the risk of delays due to requirements changes. However, in reality, projects rarely follow the sequential flow: requirement changes always happen. Another con of the Waterfall Model is that it only describes the highest activities throughout the lift cycle. It is a coarse grained process model and does not include details. 2.1.2.2 The Incremental Model The incremental model was designed to increase adaptability of the Waterfall Model and therefore applied in an iterative fashion. The system is partitioned into small increments [90]. Generally, the first increment is developed: basic requirement are addressed and implemented. Developers take advantage of what was being learned during the development of earlier, incremental, deliverable versions of the system. Key steps in the process were to start with a simple implementation of a subset of the software requirements and 22 iteratively enhance the evolving sequence of versions until the full system is implemented. At each iteration, design modifications are made and new functional capabilities are added. Typically, this is coupled with iterative development as proposed in the spiral lifecycle. 2.1.2.3 The Spiral Model The Spiral model, originally developed by Boehm [21], is an evolutionary development process model which explicitly takes risk into consideration when performing software development activities. By iterating through the software development activities, increasingly versions of software are released. Boehm describes the model ―a risk-driven process model‖ and ―is used to guide multi-stakeholder concurrent engineering of software intensive systems‖. It emphasizes two distinguishing features. The model takes the cyclic approach, and each round can connected to a phase within the Waterfall model. The initial round is to analyze the system feasibility; subsequent passes round the spiral is to develop the requirement specification and then progressively more sophisticated versions of the software. Figure 3. Spiral Model 2.2 Rational Unified Process Rational Unified Process (RUP) [49] is a comprehensive software development process framework that has been proved in industry. It provides a disciplined approach to assigning tasks and responsibilities within a development organization. The purpose is to ensure that software development process follows a set of pre-defined workflow and produce the high quality software within a predictable schedule and budget. From a management perspective, the software lifecycle of the Rational Unified Process (RUP) is decomposed over time into four sequential phases. From the software requirement point of view, RUP 23 helps development teams to understand customer needs and build the right software by use cases and other requirement techniques [37]. The RUP process can be decomposed into Phases and Disciplines. Phases represent the temporal aspect of the development process. In traditional RUP, four phases are described. They are Inception Phase, Elaboration Phase, Construction Phase and Transition Phase. Each phase is concluded with a well-defined milestone—a point in time at which certain critical decisions must be made, and therefore key goals must have been achieved [18]. Disciplines are logical groupings of activities. Nice disciplines are presented in RUP. The process can be described in two dimensions [67], or along two axes: The horizontal axis represents time and shows the dynamic aspect of the process as it is enacted, and it is expressed in terms of cycles, phases, iterations, and milestones. The vertical axis represents the static aspect of the process: how it is described in terms of activities, artifacts, workers and workflows Figure 4. The Rational Unified Process RUP defines a Unified Method Architecture (UMA) which is a process engineering meta-model that defines schema and terminology for representing methods consisting of method content and processes. It provides a two dimensional framework: Method Content and Process. Method content describes how development work is being performed is categorized by disciplines. Each discipline is comprised of tasks that provide step-by-step descriptions of how specific development goals are achieved. For a process, tasks have been referenced by the process from the method content and placed into breakdown structures and workflows ready for instantiation by allocating resources to perform the work and having real work products as the inputs and outputs of the tasks. The following diagram [51] shows that Method comprises on method content described with concepts such 24 Work Products, Roles, Task and Categories as well as Processes described with Activities, Capability Patterns, or Delivery Processes. Figure 5. Overview of UMA Disciplines can be further decomposed into Activities, which denote a coarse grained area of activity that is to be addressed within the Discipline. Activities in turn refer to a set of Tasks, whereas a Task can be part of several Activities. A Task describes a certain unit of work that yields a meaningful result. For documentation purposes, RUP also includes a step-by-step description for each of these Tasks. Common to all Tasks is the property that they consume certain Artifacts and, as the work result, yield new or modified Artifacts. Roles define responsibilities of individuals in the process. The individuals are assigned to their roles to perform Activities. The outputs of Activities are work products. Artifacts are also the inputs that drive other Activities and become transformed by an Activity into new work products. The work products are the key pieces of information produced during the project to describe or visualize specific parts of the system or the project. The most important work product for a successful software project is the compiled, executable code. Other work products include requirements, use cases, UML diagrams, test cases, etc. The purpose of other work products, like models, documentation and plans, are for supporting the project progress. In addition to Roles, Activities and work products, the RUP also provides capabilities patterns. It details provide the sequence of when to perform the activities. Steps 1…* 1 Phase 4 9 Disciplines 1…* 1 Activities 1…* 1…* 1…* Performed by Tasks 0…* Input/output 1…* 1 Roles 1…* Responsible for 1…* Work Products Figure 6. “Class Diagram” of RUP 25 2.3 2.3.1 Requirements Engineering Introduction The term requirements engineering process is used to describe a systematic process of developing requirements by identifying stakeholders and their needs, and documenting these in a form that is amenable to analysis, communication, and subsequent implementation. Zave [54] provides one of the clearest definitions of RE: “Requirements engineering is the branch of software engineering concerned with the real-world goals for, functions of, and constraints on software systems. It is also concerned with the relationship of these factors to precise specifications of software behavior, and to their evolution over time and across software families.” The output of a RE process is a requirements specification document (SRS), which defines the system to be developed. Dorfman gives the clear definition for SRS [41]: Softeware requirement specification is a document that clearly and precisely describes each of the essential requirements (functions, performance, design constraints, and quality attributes) of the software and external interfaces. Each requirement is defined in such a way that its achievement can be objectively verified by a prescribed method, for example, inspection, demonstration, analysis, or test. According to IEEE standard [66], a good software requirements specification should address the following: Functionality. What is the software supposed to do? External interfaces. How does the software interact with people, the system抯 hardware, other hardware, and other software? Performance. What is the speed, availability, response time, recovery time of various software functions, etc.? Attributes. What is the portability, correctness, maintainability, security, etc. considerations? Design constraints imposed on an implementation. Are there any required standards in effect, implementation language, policies for database integrity, resource limits, operating environment(s) etc.? Again, from the IEEE standard [66], a good software requirements specification has the following characteristics: Correct: That is for sure. Unambiguous: An SRS is unambiguous if, and only if, every requirement stated therein has only one interpretation. Complete: A simple judge of this is that is should be all that is needed by the software designers to create the software. 26 Consistent: The SRS should be consistent within itself and consistent to its reference documents. Verifiable: All the requirements in the SRS are verifiable against a predefined checklist or international standards. Modifiable: Having the same requirement in more than one place may not be wrong - but tends to make the document not maintainable. Traceable: Often, this is not important in a non-politicized environment. However, in most organizations, it is sometimes useful to connect the requirements in the SRS to a higher level document. 2.3.2 Why Requirement Engineering The reason why researchers put so much effort on requirements engineering traces back to some unpleasant memories in industry. The CHAOS Report [57] is the first paper to really unveil the software project failures. It analyzed over 8,000 projects over the United States and estimated the wasted costs. This report showed that software engineering projects had a success rate of 16 %. Additionally, the studies also suggested project success, challenge and impairing factors. The CHAOS Report divided the projects into three classes: successful, challenged, and impaired ones. The successful projects were completed on time and on budget with all features and functions implemented as initially specified. The challenged projects were also completed and operational but over budget, over the time estimate, and offered fewer features and functions than was originally specified. Finally the impaired projects were ones that were cancelled at some point during the development cycle. The overall success rate for the considered projects was only 16.2%, the challenged projects accounted for 52.7% of the projects, and the rest 31.3% of the projects were cancelled. Considering the challenged projects on average only 61% of the originally specified features and functions were available. One of the key reasons for the time and cost overruns was project restarts which meant that a project was terminated prematurely and started again. In the study there were 94 restarts for every 100 started projects. However, this does not mean that almost every project had been stopped at some point since there were projects that were stopped many times. At the time the survey was conducted there were 3,682 projects running and 431, or 12%, of these were on time and on budget. The original CHAOS Report has been followed by many respective studies. The Standish Group has done many follow-up studies and even published two HAOS Chronicles [191]. Other similar studies include the Cutter Consortium‘s survey on project management with 136 information systems (IS)/IT managers from the North America, Europe, Australia/Pacific region, and Africa. Comparing this and their earlier surveys Cutter Consortium claims that the trend is towards smaller IT projects in terms of cost, size, and duration. Based on the available data it is possible for us to compare the results of The Standish Group and the Cutter Consortium studies to see a general change in the situation. According to the Cutter Consortium study almost all cost and time overruns were limited to 50% while The CHAOS Report had a much more even distribution of over 200% of overruns (see Table 1; table includes only successful and challenged 27 projects from The CHAOS Report). The average cost of an overrun in The CHAOS Report was 180% and the average time of an overrun was 222%. These kinds of project that far exceed the planned time and cost estimates are often called runaway projects. Table 1. Cost and time overruns Percentage overrun 0 1-50 51-100 101-200 >200 Cost overrun (%) Chao‘s 95 16 25 16 5 7 Cutter‘ 01 20 68 8 2 2 Time overrun (%) Chao‘s 95 16 12 11 19 6 Cutter‘ 01 18 73 5 3 0 One of the key results of The CHAOS Report is the suggested project success, challenged, and impaired factors. The three most important factors for each project class are quite similar to each other as can be seen in Table 2. Table 2 also shows that the requirements have an important role when the project outcome is considered. Table 2. Project success, challenged, and impaired factors Success factors 1. User involvement 2. Executive management support 3. Clear statement of requirements Challenged factors 1. Lack of user input 2. Incomplete requirements and specifications 3. Changing requirements and specifications Impaired factors 1. Incomplete requirements 2. Lack of user involvement 3. Lack of resources From the reports, it is obvious that RE plays a key role in software development. Furthermore, the cost of repairing requirements-related problems dramatically increases as the software development process progresses [19]. It is therefore evident that the RE process has important ramifications for the overall success of the project. 2.3.3 Requirements Engineering Process Requirements Engineering process can be defined as a structured set of activities followed to derive, validate and maintain a system‘s requirements [26]. Several RE process models are proposed. IEEE defines the major activities as the following [83]: Elicitation: Requirements are elicited from stakeholders (such as customers and users). Analysis: Requirements are analyzed and modeled. Documentation: Requirements are documented in the Software Requirements Specification. Later, Kontonya proposed a more general RE process model includes the following activities: Requirements elicitation. Requirements are elicited from different stakeholders. Requirements analysis and negotiation. Requirements are analyzed and the problems identified 28 are negotiated with the stakeholders. Requirements documentation. Requirements are documented in appropriate notations. Requirements verification and validation. Requirements are verified and validated to ensure that the requirements are real needs of stakeholders and are well defined. Requirements management. Requirements management is highly related to requirements change management in this model and includes requirements traceability. 2.3.3.1 Requirements elicitation Requirements Elicitation is the process of discovering the requirements for a system by communication with customers, system users and others who have a stake in the system development. The term elicitation is used in books and research to raise the fact that good requirements can not just be collected from the customer, as would be indicated by the name requirements gathering. Requirements elicitation is non-trivial because people can never be sure they can get correct and complete requirements from stakeholders by just asking them what the system should do. The common techniques of requirements acquisition are interviews, questionnaires, consultation with stakeholders, focus group, prototyping, brainstorming and observations. 2.3.3.2 Requirements Analysis and Negotiation Requirements Analysis and Negotiation is to analyze the requirements for their necessity, completeness, consistency and feasibility in the context of cost budget and available schedule. It thus explicitly defines the system requirements, process requirements and requirements outside the scope. Detailed discussions with the stakeholders are held to resolve the conflicts or overlaps between requirements and the requirements are prioritized according to their criticality. Techniques like Joint application Design (JAD) and Software Quality Function Deployment (SQFD) can be used in the process. 2.3.3.3 Requirements Documentation Requirements documentation is the process of documenting the agreed requirements at an appropriate level of detail in the most suitable notation based on a well-defined document structure. This process has a very close relationship with requirements management. The key issues in the process are to select proper notations to document requirements and at the appropriate level of detail. Additionally, the document structure and the labeling hierarchy of requirements are also important since they will directly relate to requirements traceability. The documentation process receives its input from the analysis and negotiation process. The output of the process is a well-structured and defined specification, which, however, still needs to be verified and validated. 29 2.3.3.4 Requirements Verification and Validation The purpose of requirements verification and validation is to certify that the requirements are an acceptable description of the system to be implemented. Inputs for this process are the requirements document, organizational standards, and organizational knowledge. The outputs are a list that contains the reported problems with the requirements document and the actions necessary to cope with the reported problems. Techniques used for requirements validation are requirements reviews and requirements testing. Requirements validation usually results in sing-offs from all project stakeholders. 2.3.3.5 Requirements Management The goal of requirements management is to capture, store, disseminate, and manage information. Requirements management includes all activities concerned with change and version control, requirements tracing, and requirements status tracking. Requirements traceability provides relationships between requirements, design, and implementation of a system in order to manage changes to a system. 2.4 Product Line The process of developing a set of products that share a majority of features is called Software Product Line development practice. Product lines achieve reuse in the functionality and solution space, and thus improve quality, cycle time and cost. They are specifically promising in cases where many variants are produced almost simultaneously, such as in telecommunication systems. Though appealing, the concept is difficult to introduce specifically into an existing development environment. A typical product line practice has two important activities: The Core Asset Development and the Product Development. In the Core Asset Development activity, which is also called Domain Analysis and Engineering (DA&E), product family requirements and potential family members are identified, analyzed and a reusable domain framework is developed. In the Product Development activity the domain framework is instantiated to develop individual applications. However, in the existing product line practices these activities are carried out in several different stages. For example Synthesis and FAST have only two stages: Domain Engineering and Application Engineering. In several other approaches such as FODA, PuLSE, Sherlock and Odyssey-DE they are carried out in more than two stages. In the following sections, we are interested in the requirements engineering processes and practices used in product line practices. In product line development requirements engineering activities are carried out in the early stages of DA&E. Requirement engineering processes and techniques are used to identify and characterize product line requirements and potential member products. They also involve activities such as product line requirements modeling, specification, verification and management. Requirements process and techniques used in some of the product line practices are reviewed below. 30 2.4.1 Overview The software product line engineering paradigm is composed of two main processes: domain engineering and application engineering. The separation into two processes indicates a separation of concerns with respect to variability. Domain engineering is responsible for ensuring that the available variability is appropriate for producing the applications. The platform is defined with the right amount of flexibility in many reusable artefacts. A large part of application engineering consists of reusing the platform and binding the variability as required for the different applications. Three main product line activities are iterative and concurrent Domain Engineering Output Core Assets Management Control Control Application Engineering Output Application Decomposes into activities to engineer a re-usable platform (requirements, designs, code, etc.) Decomposes into activities to manage the development/ interactions of the re-usable assets and each customized application Decomposes into activities to engineer customized applications ( requirements, designs, code, etc.) Figure 7. Activity Diagram for Product Line Engineering The activity diagram above illustrate the software product line process, which has domain engineering, including domain requirements engineering, domain design, domain realisation and domain testing, in parallel with application engineering, including application requirements engineering, application design, application realisation and application testing. And product management involves the whole product life. It controls domain engineering and application. Here, Klaus Pohl brings forward several important definition and conception in product line area. [76] Development Artifact: the output of a sub-process of domain or application engineering. Development artifacts encompass requirements, architecture, components, and tests. Domain Artifacts: reusable development artefacts created in the sub-processes of domain engineering. Application Artifacts: the development artefacts of specific product line applications. 2.4.1.1 Domain Engineering Domain Engineering is the process of software product line engineering in which the commonality and the variability of the product line are defined and realized. It has five key sub-processes: Product management, Domain requirements engineering, Domain design, Domain realization, Domain testing. 31 The domain requirements engineering is responsible for collecting the common and variable requirements of the product line. The domain design sub-process defines the high level design of the product line. The domain realisation encompasses the detailed design and the implementation of reusable software components. The domain testing deals with the validation and verification. The key goals of the domain engineering process are: [76] 1. 2. Define the commonality and the variability of the software product line. Define the set of applications the software product line is planned for, i.e. define the scope of the software product line. 3. Define and construct reusable artifacts that accomplish the desired variability. 2.4.1.2 Application Engineering Application Engineering is the process of the software product line engineering in which the applications of the product line are built by reusing domain artifacts and exploiting the product line variability. It has four key sub-processes: Application requirements engineering, Application design, Application realization, Application testing. The application requirements engineering is responsible for developing the application requirements specification. The application design produces the application architecture. The application realisation creates the applications. The application testing deals with the validation and verification based on the application specification. The key goals of the application engineering process are: [76] Achieve an as high as possible reuse of the domain assets when defining and developing a product line application Exploit the commonality and the variability of the software product line during the development of a product line application Document the application artifacts, i.e. application requirements architecture, components, and tests, and related them to the domain artifacts Bind the variability according to the application needs from requirements over architecture, to components, and the test cases Estimate the impacts of the differences between application and domain requirements on architecture, components, and tests 2.4.1.3 Variability Variability is introduced during the product management sub-process when common and variable features of the software product line applications are identified. We use variability modeling to capture the variability of domain requirements, architecture, components and tests. As domain requirements detail the 32 features defined in product management, variability is carried over to domain requirements. Similarly, this holds for design, realisation, and testing. Variability is defined in terms of four concepts: variability subject, variability object, variation point and variant [76]. The first two terms are widely used in common. The latter two are the central concepts for variability in software line engineering. A variability subject is a variable item of the real world or a variable property of such an item. A variability object is a particular instance of a variability subject. A variation point is a representation of a variability subject within domain artefacts enriched by contextual information. A variant is a representation of a variability object within domain artifacts. For example, consider an on-line payment application as in [76]. Payment method is a variability subject and different specific methods are instances of variability objects, for example, by credit card, by pay pal or by cash. If we want to build an online payment application, then a variation point ―payment method‖ is defined. However, only the variants ―payment by credit card‖ and ―payment by pay pal‖ are defined. But ―payment by cash‖ is not considered as variants for online system does not support this method. Domain Artifacts Application Artifacts Variability Object Payment Method (Variability Subject) Debit Credit Cash Online Payment Application (Variation Point) Pay by Credit Variant PayPal Pay by Pay Pal Figure 8. Example of Variation point and Variant There are three steps to define the variability of a software product line [76]. The first step is to identify the variety in the real world. Then define a variation point within the context of the software product line. Finally, define the variants. We need the standard to define that variability, which is orthogonal variability model. It relates the variability defined to other software development models such as feature models, use case models, design models, component models, and test models. An orthogonal variability model defines the variability of a software product line for feature models, use case models, design models, component models, and test models. The optional variability dependency states that a variant can (but does not need to) be a part of a product line application. The mandatory variability dependency defines that a variant must be selected for an application if and only if the associated variation point is part of the application. [76] The orthogonal variability model also defined the constraint dependency among variants and variation 33 points. A variant to variant constraint dependency describes a relationship between two variants, which may be of one of two types: a) Variant requires variant (requires_V_V): The selection of a variant V1 requires the selection of another variant V2 independent of the variation points the variants are associated with. b) Variant excludes variant (excludess_V_V): The selection of a variant V1 excludes the selection of the related variant V2 independent of the variation points the variants are associated with. A variant to variation point constraint dependency describes a relationship between a variant and a variation point, which may be of one of two types: a) Variant requires variation point (requires_V_VP): The selection of a variant V1 requires the consideration of variation point VP2. b) Variant excludes variation Point (excludes_V_VP): The selection of a variant V1 excludes the consideration of variation point VP2. A variation point to variation point constraint dependency describes a relationship between two variation points, which may be of one of two types: a) Variation point requires variation point (requires_VP_VP): A variation point requires the consideration of another variation point in order to be realized. b) Variation point excludes variation Point (excludes_VP_VP): The consideration of a variation point excludes the consideration of another variation point. Variability modeling is a central technique required to put software product line engineering into practice. The variability of a software product line is specified in a separate model consisting of variation points, variants, and their relationships. 2.4.2 Documenting Variability in Requirement Artifacts As domain requirements detail the features defined in product management, variability is carried over to domain requirements. Similarly, this holds for design, realisation, and testing. Requirements can be captured in informal, semi-formal, or formal notations. An informal requirement specification uses natural languages to describe the requirement. Natural language is very flexible and expressive; however it can also result in ambiguous requirements [76]. By using textual requirement to define variability, variation point and variant need to be explicitly highlighted. We can assume that, when the Kodak Company assembles different camera models, they list the variation point, ―type of lens for Kodak camera‖, and variants, ―regular lens‖, ―wide-angle lens‖ or ―zoom lens‖. XML and XSLT can also be applied to enable the explicit documentation of variability in textual requirement. 34 Some transformations may not preserve semantics in some situations because some of them use a semi-formal UML semantics. A use case is a technique for capturing the potential requirements of a new system or software change; it typically documented using use case description, scenarios or use case diagrams. In his book, Klaus Pohl proposed several methods for different types of documentations. To define variability in template-based use case description could be expressed by each use case slots. It is some kind similar with textual requirement. Using a tabular notation can define variability in use case scenarios. Compared with the variability which can be represented in use case scenarios or use case templates, the variability which can be documented in use case diagrams is on a more abstract level. For example, using include relationship to represent variation point and variant. Tabular Scenario 1. 2. 2. 3. The camera body is ready and on the lens assembly line. Workers choose regular lens to assemble. Workers choose Wide-angle lens to assemble. Lens is integrated. Variability Diagram VP Lens Regular V V Wide-angle Use Case Diagram <> Assemble Regular Lens Assemble Lens Assemble Wide-angle Lens <> Figure 9. Using include relationship to represent variation point and variant A formal notation is used so as to provide a rigorous description of the various elements required to describe the structure and calibration of the time scale in a manner that allows the logical consistency of the model to be evaluated. Model-based requirements have an underlying model, which defines the set of permissible language elements, the set of composition rules, and, if the modeling language is a formal language, the formal semantics. Model-based requirements can express variability by feature models, use case models, and traditional requirements models, i.e. functional models, data models and behavioral models. Feature models describe the functional as well as the quality characteristics of the system under 35 consideration. The feature modeling approach allows a hierarchical decomposition of features which yields a feature tree or feature diagrams. Below is the camera example for feature models. Camera Body Lens Flash Regular Lens Wide-angle Lens Zoom Lens Figure 10. Example of feature models 2.4.2.1 Domain Requirements Engineering The main goals of domain requirements engineering are to develop the common and various domain requirements in addition to their precise documentation. The major difference between traditional requirements engineering and domain requirements engineering lies in analyzing the variability of the product line. [76] In order to analyze, identify and model the variability, domain requirements engineering should be consistent among the different requirements artifacts and their documentations. The following are the two major steps: defining common requirements and defining variable requirements. The previous step will find common requirements to all applications by iteration, and the latter one will model the product line in a variability of models and according to each model, document each requirement respectively. Klaus Pohl proposes several methodologies to analyze the commonality and variability [76]. Along with the elicitation of requirements for the intended software product line applications, the commonality of the applications has to be defined. The application-requirements matrix gives an approximation of the commonality for a give set of product line application requirements. Priority-based commonality analysis is based on set of requirements in which each requirement is rated by different stakeholders according to a certain scheme. Another more general approach is to use checklists, which represent a category of requirements that should be considered as candidates for common requirements. The goal of variability analysis is to identify requirements variability and to define the variation points and their variants related to these requirements. It also can use same techniques as commonality analysis, application-requirements matrix, priority-based commonality analysis and checklists. 36 2.4.2.2 Application Requirements Engineering ―The goal of application requirements engineering is to elicit and to document the requirements artifacts for a particular application and the same time reuse, as much as possible, the domain requirements artifacts.‖ We can assume that the domain requirements are the union of all the application requirements, including commonality and variability and the application requirements extends commonality from domain requirements and also has its own specified requirements. Steve McConnell, in his book Rapid Development, details a number of ways users can inhibit requirements gathering [89]: Users don't understand what they want Users won't commit to a set of written requirements Users insist on new requirements after the cost and schedule have been fixed Communication with users is slow Users often do not participate in reviews or are incapable of doing so. Users are technically unsophisticated Users don't understand the development process These are so called stakeholder issues.Therefore, Klaus Pohl puts forward an opinion about two kinds of requirement [76]: Stakeholder requirements are requirements that stakeholders state for a particular application, i.e. requirements that the stakeholders expect to be fulfilled by the application. Application requirements are requirements that completely specify a particular product line application. For the elicitation and documentation of application requirements, the following three activities are essential: Communicating the commonality and external variability of the product line Evaluating deltas between domain and application requirements Documentation of application requirements To make the stakeholder understanding the capabilities of the product line and to elicit application requirements, communicating the commonality and external variability of the product line can be applied. When stakeholder requirements cannot be completely satisfied by domain requirements artifacts, deltas have to be evaluated with respect to the required realisation effort. Final step is to document these application requirements. 37 2.5 2.5.1 Agile Methods Overview Agile software development is a conceptual framework for undertaking software engineering projects. There are a number of agile software development methods, such as those espoused by The Agile Alliance. [66] Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan Agile methodologies developed as a reaction to these methodologies. For many people the appeal of these agile methodologies is their reaction to the bureaucracy of the engineering methodologies. These new methods attempt a useful compromise between no process and too much process, providing just enough process to gain a reasonable payoff. The result of all of this is that agile methods have some significant changes in emphasis from engineering methods. The most immediate difference is that they are less document-oriented, usually emphasizing a smaller amount of documentation for a given task. In many ways they are rather code-oriented: following a route that says that the key part of documentation is source code. Agile methods are adaptive rather than predictive. Engineering methods tend to try to plan out a large part of the software process in great detail for a long span of time, this works well until things change. So their nature is to resist change. The agile methods, however, welcome change. They try to be processes that adapt and thrive on change, even to the point of changing themselves. Agile methods are people-oriented rather than process-oriented. The goal of engineering methods is to define a process that will work well whoever happens to be using it. Agile methods assert that no process will ever make up the skill of the development team, so the role of a process is to support the development team in their work. Most agile methods attempt to minimize risk by developing software in short time boxes, called iterations, which typically last one to four weeks. Each iteration is like a miniature software project of its own, and includes all of the tasks necessary to release the mini-increment of new functionality: planning, requirements analysis, design, coding, testing, and documentation. While an iteration may not add enough functionality to warrant releasing the product, an agile software project intends to be capable of releasing new software at the end of every iteration. At the end of each iteration, the team reevaluates project priorities. 38 Agile methods emphasize real-time communication, preferably face-to-face, over written documents. Most agile teams are located in a bullpen and include all the people necessary to finish software. At a minimum, this includes programmers and their "customers" (customers are the people who define the product; they may be product managers, business analysts, or actual customers). The bullpen may also include testers, interaction designers, technical writers, and managers. Agile methods also emphasize working software as the primary measure of progress. Combined with the preference for face-to-face communication, agile methods produce very little written documentation relative to other methods. This has resulted in criticism of agile methods as being undisciplined. 2.5.2 The Agile Manifesto Agile methods are a family of development processes, not a single approach to software development. It was developed at 2001, and so called light-weight methodologies. Agile Manifesto is widely regarded as the canonical definition of agile development, and accompanying agile principles. The characteristics of agile methods are elaborately defined in the twelve principles behind the agile manifesto [3]: Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. Business people and developers must work together daily throughout the project. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. Working software is the primary measure of progress. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. Continuous attention to technical excellence and good design enhances agility. Simplicity--the art of maximizing the amount of work not done--is essential. The best architectures, requirements, and designs emerge from self-organizing teams. 39 At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly. First, the agile movement emphasizes the relationship and communality of software developers and the human role reflected in the contracts, as opposed to institutionalized processes and development tools. In the existing agile practices, this manifests itself in close team relationships, close working environment arrangements, and other procedures boosting team spirit. Second, the vital objective of the software team is to continuously turn out tested working software. New releases are produced at frequent intervals, in some approaches even hourly or daily, but more usually monthly or bi-monthly. The developers are urged to keep the code simple, straightforward, and technically as advanced as possible, thus lessening the documentation burden to an appropriate level. 2.6 Conclusion In this chapter, a general introduction to current software engineering and requirements engineering is presented. Numerous software development lifecycle models, techniques and methodologies have been developed to cope with the crisis caused by the complicated, multidisciplinary and multidimensional nature of software engineering. The advantages of applying well-defined software development models and techniques in software projects are that they can bring a clear structure and engineering discipline into the development process; thus, they provide a means to improve the quality of software products. As a key process of software engineering, requirements engineering plays a crucial role throughout the whole software engineering lifecycle. Research has shown that failures of software projects are often related to poor requirements. Well-defined requirements increase the likelihood of the overall success of the software project. However, it will not be possible to develop better quality requirements without a well defined RE process. Since requirements engineering is the starting point of software engineering and later stages of software development rely heavily on the quality of requirements, there is a good reason to pay close attention to the RE process. Proper means have to be studied to provide effective help in developing the most suitable RE process by considering the characteristics of the software project under development. In addition, the framework of product line and several well-known agile methods are introduced. Software product line methods (SPLMs) are practices-based, or plan-driven, software development approaches in which a set of software-intensive systems that share a common, managed set of features are produced from a set of re-usable core assets in a prescribed way. AMs are software processes that share the same values: individuals and interactions over processes and tools, working software over comprehensive documentation, customer collaboration over contract negotiation and responding to changes over following a plan. The Agile Manifesto inspired 12 principles for Agile process. Among these principles, the highest priority is to satisfy the customer through early and continuous delivery of software. These SPLM and AM methods will be evaluated and used in the new approach that can assist in defining a well-suited RE 40 process for developing agile, product line applications. The approach should:    use process standards (e.g., RUP) as the foundation for the process definitions propose a product line RE process to a (non-expert ) user with a tailored level of agility for a project that an expert would propose present the recommend process to the user in a visual modeling language (e.g., UML activity diagrams) These tasks are undertaken by the research described in this proposal and the result of the research will be presented in the later sections. 41 3 Related Work A survey of RE research is presented in this Chapter. The survey includes the following topics: requirements engineering process selection/tailoring; product line RE; agile RE methods; and component based RE. There are many benefits to devising and verifying a software requirements specification. The requirements guide the rest of the software development – so it can be exceedingly costly and/or devastating to the project if the requirements are incorrect or incomplete. Additionally, the requirements can act as a contract between the customer and the software development. The rest of this chapter is organized as follows: the related work of questionnaire is present in Section 3.1. Several tailoring RUP methodologies are introduced in Section 3.2. The comparison to APLE-RE framework is introduced in Section 3.2, also the conclusion is given. 3.1 Questionnaire Related Work Questionnaires are frequently used to collect a wide range of data from a potentially large number of respondents. Questionnaires vary in length, focus, and types of items (e.g., checklists, scaled items, or open-ended questions) and are particularly useful in gathering data from large groups of people about perceptions, attitudes, intended actions or application of learning. Often they are the only feasible way to ensure that the number of respondents is large enough to allow statistical analysis of the results. Questionnaires can be classified into open and close questions. An open-question questionnaire provides more information than a closed one. The complexity for the analysis of the data provided by open questions is higher than those in closed-questions [71]. It has been argued that the use of questionnaire consumes less time, effort and financial resources than other methods of data collection like interviews or document reviews [100]. A well-designed questionnaire can gather information on both the overall performance of the activity as well as information on specific components. Questionnaires have been used in many domains, such as customer services [6] [9], preventative medicine [10], and in software engineering [10][98]. 3.1.1 Questionnaire in Software Engineering Questionnaire is often used in software engineering. Questionnaire can be sent out for process definition, software verification and validation, software maintenance, etc. The purpose of process definition is to establish the acquisition organization's standard software acquisition process and an organizational responsibility for stabilizing and maintaining the standard software acquisition process. Process definition involves understanding the organization's and projects' software acquisition processes, collecting a set of software acquisition process assets, and coordinating 42 efforts to appraise and improve software acquisition processes. The Software Engineering Institute (SEI) developed a process maturity framework in 1986. The purpose of the framework was to improve software process for organizations, and provide the federal government with a method for assessing the capability of their software contractors [100]. Later on, in September 1987, the SEI released a brief description of the process maturity framework and a maturity questionnaire (CMU/SEI-87-TR-23) [101]. The purpose of the maturity questionnaire is to provide a simple tool for identifying areas where an organization's software process needed improvement. However, the questionnaire was too often regarded as "the model" rather than as a vehicle for exploring process maturity issues. After four years of experience with the software process maturity framework and the preliminary version of the maturity questionnaire, the SEI has evolved the software process maturity framework into a fully defined model: Capability Maturity Model for Software [28][81][83]. In 1994, a modified version of the software process maturity questionnaire [105] was published. It has been designed for use in the new CMM-based software process appraisal method: the CMM-based appraisal for internal process improvement (CBA IPI) which is the update of the original software process assessment (SPA) method, CMM-based software capability evaluations (SCEs), and the interim profile method. This questionnaire focuses solely on process issues, specifically those derived from the CMM. It consists of 18 Key Process Areas (KPAs) which contain 54 goals and 316 Key Practices (150 of which are "activities to perform"). Besides the process maturity frame, questionnaire is used in many places. [42] [45]. The purpose of this study is to develop and evaluate the instrument used to collect data - the Software Best Practices Questionnaire (SBPQ). A "best practice" is defined as a management practice that is widely recognized as excellent and is recommended by most practitioners and experts in the field. The SBPQ was designed such that each question addressed a particular best practice. Questionnaire can be applied to verification and validation. Several surveys and questionnaires on V&V were conducted [7] [52] [110] to collect information on the types of testing techniques, metrics and standards that are used by Australian organizations. Questionnaire can be applied to software maintenance. To improve the software development process, Bell Lab conducted a survey to recognize and take advantage of opportunities previous projects. The questionnaire was developed from a subset of the CMM key process areas (KPAs) [78]. 3.1.2 Questionnaire in Requirement Engineering The primary measure of success of a software system is the degree to which it meets the purpose for which it was intended. RE is the process of discovering that purpose, by identifying stakeholders and their needs, and documenting these in a form that is amenable to analysis, communication, and subsequent implementation [11]. It is a key problem area in the development of complex, software-intensive systems. Issues involved in this problem area include, achieving requirements completeness without unnecessarily 43 constraining system design, analysis and validation difficulty, and changing requirements over time. Questionnaire is applied in requirement engineering in different ways. The University of Edinburgh developed a Requirements Engineering Questionnaire [112] in 2001. The questionnaire aims to check up the requirements engineering practice within different organizations pointing out different viewpoints. Several improvement of requirement engineering process were proposed in [63][85]. In [63], one questionnaire which covered all major areas of RE processes was released. The information from the questionnaire and some interviews are consolidated to consistent picture of the overall requirement engineering processes applied in the area of car manufacturing. Although it is failed to develop a consistent picture because of the diversity in the information, the nonexistent of clear process roadmap and obvious gaps between the different activities identified and characterized, it still a good chance to using questionnaire in requirement engineering processes. Another questionnaire was selected in order to collect the large amount of data required to gain a comprehensive understanding of the RE process in [116]. The questionnaire based on a questionnaire developed by the Requirements Engineering Special Interest Group of the German Association for Computer Science customized for use in the Australian context, consists of three sections covering (1) background details of the participant, company and project, (2) the RE process, and (3) RE techniques used. A total of seven interviews have been conducted at two companies, operating in the manufacturing and financial industries. It concluded that the RE processes were frequently examined a project-by-project basis with reference to the contexts of the projects. The differences in size and priority appeared to affect the level of structure in the RE process and therefore the level of progression through a set of RE phases. In addition, questionnaires can be used in many stages in requirement engineering. For example, questionnaire is one technique to gather software requirement in the elicitation stage [11]. Depending on the system being developed, it discovers the requirements in the context of customers‘ needs, application functionality, system boundaries and constraints of the system stakeholders (e.g., clients, developers, users). Requirement can be gathered through interviews directly with customers. Questionnaires are an efficient way of gathering information from different individuals and groups and are normally used in addition to interviews. A questionnaire in the requirements elicitation can be used to gather a significant amount of focused data (attitudes, facts, behavior, etc.) about the software product at the very beginning of the development process. When designing a questionnaire, the research objectives must be articulated clearly. Questionnaire inquires about business objectives of the product and expected product usage, shows scope limitations, proposes success criteria and asks about stakeholders strategic vision of the product. Particularly, in product line requirement engineering, questionnaire can assist other elicitation techniques in determining common and variable features of the family [76]. For example, different stakeholders may have different views on a concept. Diversity in the users‘ responses is a very good way to identify the variations. It can be achieved by collecting different users‘ responses for a questionnaire. 44 Questionnaire can be used in the requirement specification stage. A use case reusing approach is proposed in [117]. It presents reusable patterns appearing in use case based requirements analysis processes. In the processes, analysts have interview and questionnaires to the stakeholders to get information of their problems, and then they compose the requirements specifications that are readable to the stakeholders. Questionnaire can be also used in the requirement management. In order to improve the software process, Requirements Management is raised as a systematic approach to identify, document, organize, and track system's requirements. The purpose of Requirements Management is to establish an agreement between the developer and the customer on requirements [118][119]. A quality Requirements Management process is fundamental for successful software process. A two-stage questionnaire [36] is developed to provide an accurate picture of the organization's Requirements Management process by the use of an assessment methodology. The questionnaire is based on the two practices of the requirements management process area of the CMMI [118][119]. 3.2 Tailoring RUP Related Work Rational Unified Process (RUP) [20] is a comprehensive software development process framework. It provides a disciplined approach to assigning tasks and responsibilities within a development organization. The purpose is to ensure that software development process follows a set of pre-defined workflow, and produce the high quality software within a predictable schedule and budget. From the software requirement point of view, RUP helps development teams to understand customer needs and build the right software by use cases and other requirement techniques [37]. 3.2.1 Introduction RUP contains an extensive library of artifacts, for one project many of which won't be needed. No company or organization requires them all. In fact, one key principle of the RUP is "Adapt the Process". Therefore, one key to take RUP into use is to tailor it to specific different needs and then to introduce it into a development organization [64]. Reviewing the literatures, not too many guidelines are presented [82, 83] [54]. Tailoring a framework, three different approaches may be considered. The first is to reuse the heavy job in each case, for example, applying existing RUP framework into projects. This can be justified for large projects. The second approach is to tailor the framework by an up-front adaptation to produce a subset of the framework. By doing this, process elements need to be added, removed, modified, or merged. The third approach is different with the previous two. The framework is built from scratch. Experienced managers identify and describe a set of project types and characteristics. Then an adaptation is done for each type. In this survey, several tailored RUP configurations will be introduced. These configurations are focus on 45 requirement, including requirement elicitation, specification, analysis, validation and management. Also configuration and change management will be included. These configurations are turning from smaller and more light-weight processes towards large complete and plan based process frameworks. The tailoring will be based on those approaches described above. The tailoring can be classified as three different approaches: tailoring for agility, tailoring for product line and tailoring for re-used. 3.2.2 Tailoring for Agility Since the RUP provides a very comprehensive and detailed framework, many professionals do not consider RUP practical for agile projects, for example, small and fast paced projects. One major challenge to apply RUP into agile projects is to select a proper subset of roles, artifacts, work tasks and work flows, and keep theses very concise and free from unnecessary formalism. 3.2.2.1 dX: A minimal RUP process: Grady Booch presented a very small RUP derived process, dX, in Error! Reference source not found.[47]. The process has been proved in several projects. dX uses the same phases as RUP, Inception, Elaboration, Construction and Transition. The workflow in each phase is much simpler than RUP. In Inception phase, major use cases are written on index cards with simple sentences. High customer involvement is quite needed. Customers and developers are working together and providing feedback. Simple prototypes of the use cases are created as potential throw-aways. By measuring the development velocity and the project size, the project plan can be determined based on the prototypes. The prototypes are also used to explore several potential system architectures. At the Lifecycle Objectives Milestone, which marks the end of inception, the major use cases, the project schedule, and the beginnings of the system architecture are produced. In Elaboration phase, more use cases are written with highly customer involvement. The developers estimate the effort for each use case, and then the customers prioritize them. Iterations are planed by selecting an iteration duration, usually no longer than one week. Once an iteration is completed, a ratio called load factors is calculated. That is the number of use cases implemented different from the number estimated. This ratio is applied to estimate the next iteration. The developers could use any building analysis and design models, such as UML or CRC cards, then produce the code. dX advocates pairing programming, similar to XP. Testing is highly emphasized in dX. Unit test code is written before code. Simplicity is also highly valued by dX. Designs and code begin as simple as possible; and no complexity is added unless mandated by a use case. 46 In dX, the Construction phase is not obvious. Actually, the Construction and Elaborations phases are nearly indistinguishable because the architecture and the project plan evolve together. The difference between them is simply in the stability of the architecture and the stability of the project plan. As the project moves into the Construction phase, the team works out a release schedule. That schedule is created by using the load factor, and summing up the use case cards needed for each release. In dX, once the first release is complete, the Transition phase starts and the system is live. This could happen very early in the project. More and more use cases are elicited and put into the system. Sometimes, they are running in parallel. More and more iterations and releases are planed. During the shorter release cycle, feedback can be gathered quickly and frequently. 3.2.2.2 Agile Unified Process Scott Ambler has written extensively on application of the Unified Process [86], and particularly with respect to agile or lighter-weight modeling with the UML [87]. In 2005, he developed a customization of the Unified Process – Agile Unified Process. Agile Unified Process (AUP) is a simplified version of the Rational Unified Process (RUP). It describes a simple, easy to understand approach to developing business application software using agile techniques and concepts yet still remaining true to the RUP. The AUP applies agile techniques including test driven design (TDD), Agile Modeling, agile change management, and database refactoring to improve productivity. AUP uses the same phases as RUP, Inception, Elaboration, Construction and Transition. However, it modified the disciplines. Disciplines are performed in an iterative manner, defining the activities which development team members perform to build, validate, and deliver working software which meets the needs of their stakeholders. The disciplines are: Model, Implementation, Test, Deployment, Configuration Management, Project Management and Environment. Model discipline replaces and merges RUP‘s Business Modeling, Requirements, and Analysis & Design disciplines. In this discipline, requirements are created, modeled and documented. However, the document is less emphasized. The Configuration and Change Management discipline is now changed to the Configuration Management discipline. The change management activities are typically part of requirements management efforts, which is part of the Model discipline. Disciplines are performed in an iterative manner, defining the activities which development team members perform to build, validate, and deliver working software which meets the needs of their stakeholders. AUP also emphasize frequent delivery. The goal of the model discipline is to understand the business of the organization, the problem domain being addressed by the project, and to identify a viable solution to address the problem domain. It covers the requirement discipline in RUP. However, it uses a lighter process to define and manage the requirement and put more effort on agile principles, higher level of customer involvement, short iteration and frequent delivery. It lands between XP and RUP: XP doesn't explicitly show how to create some of the 47 artifacts and RUP offers too many. AUP adopts many of the agile techniques of XP and other agile processes yet retaining some of the formality of the RUP. The following table presents the comparison between AUP and RUP in software requirement. The left column is the task defined in RUP requirement discipline. The right column is the respondence to AUP. Table 3. Comparison between RUP and AUP RUP Capture a Common Vocabulary: The purpose of this task is to define a common vocabulary that can be used in all textual descriptions of the system, especially the software requirements. Develop Vision: The purpose of this task is to: Gain agreement on what problems need to be solved; Identify stakeholders of the system; Define the boundaries of the system; Describe primary features of the system. AUP In RUP, the task is done by System Analyst. AUP modifies this role to agile modeler or stakeholder. Develop Requirements Management Plan: The purpose of this task is to develop a requirement management plan that specifies the information and control mechanisms which will be collected and used for measuring, reporting, and controlling changes to the product requirements. Elicit Stakeholder Requests: The purpose of this task is to: Understand who are the stakeholders of the project; Collect requests on what needs the system should fulfill; Prioritize stakeholder requests. Find Actors and Activities: The purpose of this task is to: Define the scope of the system; Define who and what will interact with the system; Outline the functionality of the system. In RUP, the task is done by System Analyst. AUP modifies this role to agile modeler or stakeholder. Vision document is not a must in AUP. It can be replaced with Project overview document, and also it should be concise. In enterprise level, vision document are developed. In AUP, this task is moved to project management. Develop Supplementary Specifications: The purpose is to capture requirements that are not readily captured in use cases. Manage Dependencies: The purpose of this task is to use attributes and traceability of project requirements to assist in managing the scope of the project and manage changing requirements. Prioritize Use Cases: The purpose of this activity is to: Define input to the selection of the set of scenarios and use cases that are to be analyzed in the current iteration; Define the set of scenarios and use cases that represent some significant, central functionality; Define the set of scenarios and use cases that have a substantial architectural coverage (that exercise many architectural elements) or that stress or illustrate a specific, delicate point of the architecture. Detail a Use Case: The purpose of this task is to: Describe one or more of the use case's flow of events in sufficient detail to enable software In AUP, requirement elicitation is performed in an iterative manner. For the first release of a system agile modelers need to take several days to identify some high-level requirements as well as the scope of the release. In AUP, the core of the software requirement is the modeling. Several different modeling are suggested when adapting AUP. Usage model is to explore how users will work with your system. Initial domain model is to identify fundamental business entity types and the relationships between them. Initial user interface model is to explore UI and usability issues. In AUP, the core of the software requirement is the modeling. Several different modeling are suggested when adapting AUP. In RUP, the task is done by System Analyst. AUP modifies this role to agile modeler or stakeholder. In AUP, the task is replaced by prioritize requirements. The specification of requirement may not use cases and it could be some model expressions. It is Comprised of a variety of work products, potentially including acceptance tests, automation opportunities, business process model, business rules, domain model, organization model, project glossary, technical requirements, use case model, and a user interface model. In AUP, the core of the software requirement is the modeling. Several different modeling are suggested when adapting AUP. The task – detail a use case – in 48 development to begin on it; Detail the use-case to the understanding and satisfaction of the actor representative or customer. Detail the Software Requirements: The purpose of this task is to collect, detail and organize the set (package) of work products that completely describe the software requirements of the system. Structure the Use-Case Model: The purpose of this task is to: Extract behavior in use cases that need to be considered as abstract use cases; Find new abstract actors that define roles that are shared by several actors. Review Requirements: The purpose of this task is to formally verify that the results of the requirements tasks conform to the customer's view of the system. RUP, can be derived to model business domain, model usage, and model technical requirement. The deliverables for this task is requirements models. Agile modeler or stakeholder is responsible for those tasks. See above. See above. In AUP, agile modeler or stakeholder analyzes the requirement and define acceptance test. Sometimes, a system overview document is prepared. This is a technical documentation for the people responsible for maintaining and evolving the system. 3.2.2.3 Open Unified Process In 2006, IBM donated certain intellectual property, OpenUP [88], to the Eclipse Foundation. OpenUP preserves the essential characteristics of RUP, which include iterative development, use cases and scenarios driving development, risk management, and architecture-centric approach. Most optional parts of RUP have been excluded, and many elements have been merged. The result is a much simpler process that is still true to RUP principles. OpenUP/Basic targets small and collocated teams interested in agile and iterative development. Small projects constitute teams of 3 to 6 people and involve 3 to 6 months of development effort. Similar to AUP, OpenUP emphasizes incremental development, so called, micro-increments. The work products or artifacts are produced in a steady and measurable pace, typically in hours or a few days. OpenUP applies intensive collaboration as the system is incrementally developed by a committed, self-organized team. These micro-increments provide an extremely short feedback loop that drives adaptive decisions within each iteration. OpenUP uses the same phases as RUP: Inception, Elaboration, Construction and Transition. The project lifecycle provides stakeholders and team members with visibility and decision points throughout the project. This enables effective oversight, and allows you to make "go or no-go" decisions at appropriate times. A project plan defines the lifecycle, and the end result is a released application. OpenUP divides the project into iterations: planned, time-boxed intervals typically measured in weeks. Iterations focus the team on delivering incremental value to stakeholders in a predictable manner. The iteration plan defines what should be delivered within the iteration, and the result is a demo-able or shippable build. OpenUP teams self-organize around how to accomplish iteration objectives and commit to delivering the results. They do that by defining and "pulling" fine-grained tasks from a work items list. 49 OpenUP applies an iteration lifecycle that structures how micro-increments are applied to deliver stable, cohesive builds of the system that incrementally progresses towards the iteration objectives. OpenUP describes four major principles: Balance competing priorities to maximize stakeholder value Collaborate to align interests and share understanding Focus on the architecture early to minimize risks and organize development Evolve to continuously obtain feedback and improve Different with RUP, OpenUP covers 6 disciplines, which are Architecture, Configuration and Change Management, Development, Project Management, Requirement and Test. The requirement discipline explains how to elicit, analyze, specify, validate, and manage the requirements for the system to be developed. It has three reference workflows, covering Identify and Refine Requirements, Initiate Project and Ongoing Tasks. A similar table will be presented to show the commonality and difference between RUP and OpenUP. The left column is the task defined in RUP requirement discipline. The right column is the respondence to AUP. Table 4. Comparison between RUP and OpenUP RUP Capture a Common Vocabulary: The purpose of this task is to define a common vocabulary that can be used in all textual descriptions of the system, especially the software requirements. OpenUP In OpenUP, this task is simplified. It becomes one step in the task: Define Vision. Glossary defines important terms used by the project. These terms are the basis for effective collaboration with the stakeholders and other team members. In RUP, the task is done by System Analyst. OpenUP modifies this role to analyst. OpenUP mergers several tasks into Develop Vision. The vision provides a high level, sometimes contractual, basis for the more detailed technical requirements that are visible to the Stakeholders. In OpenUP, project manager plans the project. Plan Project is a collaborative task that outlines an initial agreement on how the project will deliver the product vision. The resulting project plan provides a summary-level overview of the project. In OpenUP, this task is simplifies. It can be achieved in Define Vision. Gather stakeholder requests is one step in Define Vision. Develop Vision: The purpose of this task is to: Gain agreement on what problems need to be solved; Identify stakeholders of the system; Define the boundaries of the system; Describe primary features of the system. Develop Requirements Management Plan: The purpose of this task is to develop a requirement management plan that specifies the information and control mechanisms which will be collected and used for measuring, reporting, and controlling changes to the product requirements. Elicit Stakeholder Requests: The purpose of this task is to: Understand who are the stakeholders of the project; Collect requests on what needs the system should fulfill; Prioritize stakeholder requests. Find Actors and Activities: The purpose of this task is to: Define the scope of the system; Define who and what will interact with the system; Outline the functionality of the system. Develop Supplementary Specifications: The purpose is to capture requirements that are not readily captured in use cases. Manage Dependencies: The purpose of this task is OpenUP simplifies this task. One step in Find and Outline Requirements do the same thing: Identify and capture Use Case and Actors in a Use-Case Model . OpenUP doesn‘t mention this step explicitly. However, Supporting Requirements Specification can capture requirements that are not readily captured in use cases. OpenUP simplifies this task. Requirement can be 50 to use attributes and traceability of project requirements to assist in managing the scope of the project and manage changing requirements. Prioritize Use Cases: The purpose of this activity is to: Define input to the selection of the set of scenarios and use cases that are to be analyzed in the current iteration; Define the set of scenarios and use cases that represent some significant, central functionality; Define the set of scenarios and use cases that have a substantial architectural coverage (that exercise many architectural elements) or that stress or illustrate a specific, delicate point of the architecture. Detail a Use Case: The purpose of this task is to: Describe one or more of the use case's flow of events in sufficient detail to enable software development to begin on it; Detail the use-case to the understanding and satisfaction of the actor representative or customer. Detail the Software Requirements: The purpose of this task is to collect, detail and organize the set (package) of work products that completely describe the software requirements of the system. Structure the Use-Case Model: The purpose of this task is to: Extract behavior in use cases that need to be considered as abstract use cases; Find new abstract actors that define roles that are shared by several actors. Review Requirements: The purpose of this task is to formally verify that the results of the requirements tasks conform to the customer's view of the system. elicited by Find and Outline Requirements and Detail Requirements. OpenUP simplifies this task. Requirement can be elicited by Find and Outline Requirements and Detail Requirements. In OpenUP, this task is changed to Detail Requirement. The primary performer is analyst. However, this task performs the same as RUP. The output is still use case and use case model. See above. See above. In OpenUP, the task: Create Test Case performs the requirement validation. It develops the test cases and test data for the requirements to be tested. Several other researchers raised the similar idea to adopt RUP for agile projects [82]. 3.2.3 Tailoring for Product Line RUP is designed for a single system, but falls short handling multiple similar products or product line products. Software product lines refer to engineering techniques for creating a portfolio of similar software systems from a shared set of software assets using a common means of production. However, not much guidance in literature is presented on tailoring the RUP life-cycle model to product line development. 3.2.3.1 Product Line UML-Based Software Engineering Product Line UML-Based Software Engineering (PLUS) is presented in [53]. It addresses how to develop object-oriented requirements, analysis, and design models of software product lines using the UML notation. It defines the following phases. During Product Line Requirements Modeling phase, requirements model consisting of a use case model and a feature model is developed. During Product Line Analysis Modeling phase, static and dynamic models are developed. Static models define the relationships among kernel, optional, and variant classes. The dynamic model addresses commonality and variability by developing interaction diagrams for each use case from the requirements model and providing an impact analysis approach for analyzing changes to use cases. During Product Line Design Modeling phase, the 51 component-based software architecture for the product line is then developed, in which the system is structured into distributed components. In Incremental Component Implementation phase, the subset of use cases are selected and developed, as well as the components that participate in those use cases. This phase consists of the detailed design, coding, and unit testing of the components in the subset. During Product Line Testing phase, integration testing and the functional testing are executed. Each phase of the PLUS corresponds to a workflow of the RUP, Requirement, Analysis, Design, Implementation and Test. PLUS also discusses the integration of PLUS with RUP step by step. In the Inception phase, feasibility study is to determine the product line scope. Product line managers could decide whether to continue the further development based on those sufficient information which are collected during the first iteration. If the answer is Yes, initial use cases are identified for each potential member of the product line, as well as the features. Moreover, the kernel use cases and initial features are analyzed and developed. In the Elaboration phase, the use case model is detailed reviewed and developed. Three levels of use cases – kernel, optional and alternative use cases – are determined. Variation points are analyzed. The commonality and variability is analyzed for both use cases and features. The relationship between the use case model and the feature model for the product line needs to be clearly analyzed and documented. The common and variable requirements could be initially established based on the feature model. Once the kernel of the product line has been determined, analysis and design models are developed. Two approaches could be applied to determine the analysis and design models, forward evolutionary engineering approach and reverse evolutionary engineering approach. Once the kernel is developer, the optional and alternative use cases and features can be addressed in the further iterations. Furthermore, the details of the variation points are examined. In the Construction iteration, detailed design, coding, and unit testing of the kernel components are carried out. Integration testing of the kernel components is also performed. In the transition iteration, the integration and functional testing of the kernel system, a minimal executable product line system consisting of the kernel components and any default components, is carried out. 3.2.3.2 Enhanced Milestones in Product Line An extension version of several milestones is proposed in [18] to anchor the management of software product lines. Related to RUP, two milestones are Life Cycle Objectives (LCO) and Life Cycle Architecture (LCA). For the LCO milestone, it is important to determine the breadth of the product line domain across which reusable components will be shared. For the LCA milestone, it involves developing domain architecture for the product line, rather than just a life cycle architecture for an individual system. However, the extension is not detailed enough to be useful from a practical project management perspective. 52 3.2.3.3 Unified Process Enhanced with Product Line An enhanced Unified Process, Unified Process Enhanced with Product Line (UPEPL), is proposed in [91]. In UPEPL, the product line related activities are added and could be conducted side by side with other classical RUP activities. It claims that both the advantages of Unified Process and software product lines could co-exist in UPEPL. UPEPL reuses the four phases in UP, that are, Inception, Elaboration, Construction and Transition. In Inception phase, two additional activities are added. Scoping the product line is to explore the degree of the commonality and variability. Analyzing the domain is to decide whether the product line is feasible or not. Like RUP, software requirements are organized in a use-case specification document, and a supplementary requirement document. In addition, an initial domain feature model is produced. In Elaboration phase, product line requirement, feature model and product line architecture will be refined, and also variants and commonalities will be identified during the process of the domain analysis. The product line requirement is developed incrementally. In Construction and Transition phase, meta-components are developed, selected and tested. The purpose of UPEPL is to tailor RUP to product line and map product line development activities to the phases of RUP. However, the disciplines and guidance are not covered. 3.3 Conclusion The literature related work covered 2 major areas, questionnaire and RUP tailoring. Questionnaire is reviewed under software engineering and requirement engineering context. It covers more than 20 publications, including all the major phases in software engineering (process definition, software verification and validation, and software maintenance) and requirement engineering (elicitation, specification, and management). The RUP tailoring literature covers 10 books or articles. The general book [64] discusses the Unified Software Development Process, and the Small Project Roadmap for the Rational Unified Process (RUP) (Rational Software Corporation 2002). The Jacobson et al. book provided a reference point for the other books while the Small Project Roadmap presented an example of a process tailored from RUP. RUP is designed for a single system, but falls short handling multiple similar products or product line products. Software product lines refer to engineering techniques for creating a portfolio of similar software systems from a shared set of software assets using a common means of production. However, not much guidance is presented on tailoring the RUP life-cycle model to product line development. The following twos able summarize the results of the literature survey in six areas of interest which have been derived from preliminary knowledge on questionnaire literature and practices. Table 5 is related to questionnaire. Table 6 is related to RUP tailoring. The first column in the table contains a reference to the reviewed item and the following column indicates which phases are covered in the references. The abbreviation of the symbols is below: Mgmt (Project Management), E (Requirements Elicitation), S (Requirements Specification), A (Requirements Analysis), N (Requirements Negotiation), V (Requirements Validation) and M (Requirements Management) 53 The next four columns focus on processes and techniques for both requirements development and management. The development process should have described how to use the proposed techniques in a systematic way to produce requirements while the requirement management process should have explained how to manage requirements changes. The requirements development techniques consist of the elicitation, analysis, specification, negotiation, and validation techniques. The last two columns present whether the references have the impact to agile or product line. A full treatment of the subject is marked with a ‗●‘ character in the respective cell in the table while a partial treatment is marked with a ‗○‘ character and a lack of treatment is indicated with a dash. Table 5. Questionnaire Reviewed for APLE Development ● indicates a full treatment of subject ○ indicates partial treatment of subject ― indicates lack of treatment of subject Reference Req. Dev. Phases Req. Dev. Process ○ ○ ― Req. Dev. Tech. ― ― Req. Mgmt. Process ● ● ― ― Req. Mgmt. Tech. ― ― ― ― Agile Product Line Questionnaire Related Work CMU/SEI [28] [81] [83] [101, 105] SBPQ [42] [45] Australian [52][110] Bell Lab [78] Edinburgh [112] Klaus Pohl [63] Sacha Martin [116] [7] Mgmt Mgmt V M E, A, S, V, M E, A, S, V, M E, A, S, V, M ○ ○ ― ― ○ ― ― ― ― ― ― ○ ― ○ ○ ○ ● ○ ○ ● ○ ○ ○ ○ ○ ○ ○ ― ○ As can be seen in the Table 5, few questionnaires can be found in the literatures that cover both processes and techniques. CMU/SEI and SBPQ give very comprehensive questionnaires on processes. However, the questionnaire was too often regarded as ―the model‖ rather than as a vehicle for exploring process maturity issues. The questionnaire developed by University of Edinburgh provides some requirement techniques. But it is still very limited. More important, these questionnaires pay little attention on Agile and Product Line projects. Most of them are focus on traditional single product. For this reason, the APLE-RE questionnaire is designed and implemented in order to obtain the expertise of researchers and practitioners actively involved in software development using agile, product line RE techniques. 54 Table 6. RUP Tailoring Reviewed for APLE Development ● indicates a full treatment of subject ○ indicates partial treatment of subject ― indicates lack of treatment of subject Reference Req. Dev. Phases Req. Dev. Process ● ― Req. Dev. Tech. ● ● ● ● ● ● ― ― ― Req. Mgmt. Process ○ ― Req. Mgmt. Tech. ● ― Agile Product Line RUP Tailoring Rational SW Corporation [20] Jacobson [64] Leffingwell [[37] dX Error! Reference source not found.[47] AUP [86,87] OUP [88] PLUS [53] Enhanced Milestones in PL UPEPL [91] E, A, S, V, M E, A, S, V, M E, A, S, V, M E, A, S, V, M E, A, S, V, M E, A, S, V, M E, A, S, V, M E, A, S, V, M E, A, S, V, M ○ ○ ○ ● ● ● ― ― ― ― ○ ○ ― ● ○ ● ● ○ ○ ○ ● ○ ○ ○ ○ ○ ○ ● ○ ● ● ― ― ― ― ― ● ● ● In the RUP tailoring point of view, few RE methods can be found in the literature that covers both requirements development and management. There are only four references [20] [37] [86][88] that cover both requirements development and management aspects of RE. Leffingwell and Widrig‘s book [37] is an introductory book on RE and it provides a good treatment of the topics reviewed. The last chapter of the book suggests a recipe to get started with RE since the authors had often heard the following request in their classrooms: ―Just give us a single generic process what we can start with. We know it‘s not that simple, but we‘ll be happy to modify it as necessary to our project, but we need a more prescriptive starting point, a step-by-step process so that we can better apply what we have learned. Just tell me how to get started!‖ Consequently Leffingwell and Widrig close their book by suggesting an initial process for beginners as a recipe with eight steps (Table 7). Table 7. The Eight Steps Recipe to Get Started with RE Step 1: Understand the Problem Being Solved Step 2: Understand User Needs Step 3: Define the System Step 4: Continuously Manage Scope and Manage Change Step 5: Refine the System Definition Step 6: Build the Right System Step 7: Manage the Requirements Process Step 8: Congratulations! You‘ve Shipped a Product! 55 However, Leffingwell‘s book, as well as dX, AUP and OUP, they tailored RUP to small, single projects. For example, the prescription for the initial process has a number of assumptions limiting its applicability, e.g., the project size is estimated to be 10-30 team members and the application is a single, stand-alone one without contractual requirements for documentation. Each step in the recipe includes four to eight tasks which cover the key techniques presented earlier in the book. However, these approaches does not consider to be applied in product line projects. In another hand, RUP falls short handling multiple similar products or product line products. PLUS [53], Enhanced Milestone in PL [18] and UPEPL [91] provide a high level RUP life cycle model to product line production. PLUS addresses how to develop object-oriented requirements, analysis, and design models of software product line using the UML notation, similar with [91]. In each phase, it defines the activities. In [18], an extension version of RUP milestones is given to anchor the management of software product lines. However, these approaches do not cover the detail activities and any requirements techniques. In addition, these approaches do not take into account that agile methods can be applied to product line projects. Comparing with the above related work, the APLE-RE framework is needed because:    A comprehensive set of requirement techniques is reviewed. Factors to determine degree of agility in product line RE will be identified. The APLE-RE questionnaire will be the largest survey conducted in RE process definition research and the only one conducted with a specific focus on the adoption of agile methods in product line requirements engineering.  A new set of RUP based process templates for single product and product line techniques, with varying degrees of agility, will be proposed. Existing RE process knowledge, especially for Product Line process and Agile process, is classified and organized into an Agile Product Line Requirement Process Repository. 56 4 A Framework for Agile Product Line Requirement Engineering Process Development (APLE-RE) This section describes a general framework for Agile Product Line Requirement Engineering process development (APLE-RE) throughout the research. The framework was developed using a constructive research approach [73][87]. The rest of this chapter is organized as follows: the overall introduction of APLE-RE research is described in Section 4.1. The APLE-RE Questionnaire is present in Section 4.2. Following this, the APLE-RE Process Repository and two of the process templates are introduced in Section 4.3. The conclusion will be given at the end of this chapter. 4.1 Introduction The aim of the overall project approach is to develop an expert system that can assist a requirements engineer in selecting requirements engineering process that is well suited for their project, in particular with respect to the use of agile and product line engineering methods. To the best of our knowledge, this is the first expert system to do this. APLE-RE research is built upon research reported in RE literature and survey results collected from experts in academia and industry. A high-level illustration of the framework can be seen in Figure 15. The APLE-RE framework contains three main parts: Foundations, Methodologies and Repository, and Expert System. Each part can be further decomposed into components which provide different kinds of support for RE process development. This proposal focuses on Foundations and Methodology and Repository. 57 Expert System User Interface BBN Engine Support Present Methodologies and Repository APLE-RE Techniques APLE-RE Techniques APLE-RE Questionnaire APLE-RE Questionnaire GUI APLE-RE Process Repository APLE Process Templates Guide Methodologies for Techniques Evaluations Selecting Scenarios Algorithm Guide Methodologies for APLE-RE development Methodologies for validating APLE-RE APLE-RE Database Foundation Foundations RE Techniques Agile Methods PL Methods RUP Foundation Figure 11. The Components of the APLE-RE Framework The Foundations was developed based on detailed analysis of existing research in RE processes, techniques, and good practices. It includes the following:  RE Techniques: RE techniques is the foundation of the APLE-RE framework. A list of RE techniques will be reviewed and analyzed. In Section 5.2, it provides an overview of a selection of requirements engineering techniques based on the revision RE process phases.   Agile Methods and PL Methods: In APLE-RE framework, both AMs and SPLE are considered. In Section 5.2, existing agile methods and PL principles are reviewed. RUP Foundation: The RE process template are tailored from RUP. In Section 2.2, the architecture of RUP is summarized. In Section 3.3, several tailored RUP literature are introduced. The methodologies and Repository component includes three repositories, or so called work products. They are:  RE Techniques with respect to APLE: This work product provides an overview for existing RE techniques. The Methodology for RE Techniques Selection provides systematic steps and guidance to aid the selection of techniques for a software project. This part will be explained in more detail in Section 5.  APLE-RE Questionnaire: The purpose of the questionnaire is to acquire knowledge from experts 58 actively involved in software development using agile, product line RE techniques. RE Techniques with respect to APLE is the foundation of the APLE-RE Questionnaire. The detailed contents of the questionnaire will be given in Section 6.  APLE Process Templates: the processes will be tailored versions of the RUP and will be presented in UML activity diagrams. The user can tailor the process definition and publish it. In the first phase of the research, the process definitions will be an extensive set of tailored RUP process templates, which range from very agile to plan driven approaches for single product and product line RE. In the second phase of the research, the dynamic composition of process definitions using constraint based techniques will be investigated. Two methodologies guide to build the templates. RE Process Development Methodology provides stepwise guidance for RE process development. The detailed contents of the methodology will be given in Section 6. The methodology for validating the APLE-RE framework will be introduced in Section 7. Since it is not always possible to choose the most suitable techniques in a process template, a comprehensive case study will be presented. The expert system is final output of this research. It contains a user interface and a Bayesian-Belief Network (BBN) Engine. The BBN Engine is automatically created using structured learning techniques and maintained (improved) using data mining techniques. Three categories of structured learning techniques are available: score based, constraint based, and hybrid. However, the construction of BBN is out of the scope of this research. Mr. Yan Tang will focus on these research issues for his Ph.D. thesis. The next steps are to develop the GUI for the expert system and integrate it with the BBN. The expert system GUI will prompt the user with a series of questions about the project, provide the data to the BBN engine layer, and present the most likely process definitions to the user. The processes will be tailored versions of the RUP and will be presented in UML activity diagrams, which comes from the APLE-RE Process Repository. 4.2 Expert System The final goal of this project approach is to develop an expert system that can assist a requirements engineer in defining a RE process that is well suited for their project, in particular with respect to the use of agile and product line engineering methods. The development of the expert system is organized as follows (refer to Figure 2). The first step is to acquire knowledge from experts. This is achieved by developing a questionnaire and obtaining the expertise of researchers and practitioners actively involved in software development using agile, product line RE techniques. 59 Revise questionnaire Acquire Knowledge From Experts (questionnaire)  Create initial prototype(proof of oncept)  Refine, extend as research progresses Iterative Approach Create the BBN (automate in MATLAB) Define the Tailored RUP Processes, GUI (Java) Maintain the BBN Mine the BBN for “Hotspots” Yes Found? No Integrate the GUI and BBN Need revision? No Validate the Expert System No Yes Need revision? Figure 12. Developing the Expert System The step second is to embody, or represent, the knowledge by creating a BBN; the BBN is automatically created using structured learning techniques and maintained (improved) using data mining techniques. However, the BBN is out of scope of this proposal. Mr. Yan Tang will focus on these research issues for his Ph.D. thesis. The next steps are to develop the GUI for the expert system and integrate it with the BBN. The expert system GUI will prompt the user with a series of questions about the project, provide the data to the BBN engine layer, and present the most likely process definitions to the user. The processes will be tailored versions of the RUP and will be presented in UML activity diagrams. The user can tailor the process definition and publish it. Questionnaire is one part of Methodologies and Repository which will be discussed in detail in Section 4.3. Lastly, the expert system is validated. Part of the responses of the questionnaire will be used to train the network; the remaining part will be used for validation. Distance metrics will be used to evaluate the accuracy of the network when compared to another network manually developed by experts. 4.3 Methodologies and Repository Methodologies and Repository are the main focus of this research. It covers three parts, APLE-RE Questionnaire, APLE-RE Process Repository and APLE-RE Techniques. In the following sub-sections, these three parts will be discussed in detail. 4.3.1 APLE-RE Questionnaire To acquire the expertise of researchers and practitioners actively involved in software development using agile, product line RE technique, APLE-RE Questionnaire is designed and developed. Questionnaires are 60 frequently used in quantitative marketing research and social research; they are a valuable method of collecting a wide range of information from a large number of respondents. In addition, our questionnaire is web-based, as our respondents are anticipated to be geographically distributed (North America, Europe, Asia, etc.). It is important to note that the questionnaire allows respondents to provide a mix of closed answers (selection of one or more buttons) and open answers (description in English). The questionnaire development and data collection is planned for the first phase of the research. A version of the questionnaire [4] is currently under beta-testing. The detail of the development of the questionnaire will be presented in Chapter 5. 4.3.2 APLE-RE Repository The APLE-RE Process Repository contains a set of process templates. In the template, the processes will be tailored versions of the RUP and will be presented in UML activity diagrams. As discussed before, RUP provides a disciplined approach to assigning tasks and responsibilities within a development organization. The purpose is to ensure that software development process follows a set of pre-defined workflow and produce the high quality software within a predictable schedule and budget. From the software requirement point of view, RUP helps development teams to understand customer needs and build the right software by use cases and other requirement techniques [37]. The tailored RUP processes are development by considering both SPLE and AMs. The detail of the development of the tailored processes will be presented in Chapter 6 4.3.3 APLE-RE Techniques The APLE-RE Techniques is the foundation for developing the APLE-RE process templates. The overall objective of the methodology for selecting techniques is to provide a set of guidelines to develop the most suitable process model for a software project. A structured, step-by-step approach is adopted in the methodology so that the requirements engineers can easily understand the development process. 4.4 Foundations Foundations covers an overview of several topics related to this research project, including software engineering, requirements engineering, agile methods and product line engineering. The related work of questionnaire and tailoring RUP methodologies will be evaluated and compared to the research project as well. 4.5 Conclusion The development of an RE process model is a challenging task. Making best use of existing RE process knowledge to develop the most suitable process model for a given agile product line project is difficult. The framework developed in this research is one of the efforts made to provide a solution to such a problem. It is acknowledged that the APLE-RE techniques only contains part of the overall RE process knowledge. Additionally, further usages of the framework in real life will likely lead to further refinement. 61 5 APLE-RE Questionnaire 5.1 Introduction To acquire the expertise of researchers and practitioners actively involved in software development using agile, product line RE techniques, the APLE-RE Questionnaire is designed and implemented. Questionnaires are frequently used in quantitative marketing research and social research; they are a valuable method of collecting a wide range of information from a large number of respondents. In addition, our questionnaire is web-based, as our respondents are anticipated to be geographically distributed (North America, Europe, Asia, etc.). It is important to note that the questionnaire allows respondents to provide a mix of closed answers (selection of one or more buttons) and open answers (description in English). The questionnaire development and data collection is planned for the first phase of the research. A version of the questionnaire [4] is currently under beta-testing. Figure 16 presents the components in APLE-RE Questionnaire. RE Techniques, Agile Methods and PL Methods are the foundations of the questionnaire. The purpose of the questions in Part I is to collect information about the respondent to build a profile. This section includes questions in the following areas: project type (new, on-going, legacy), project domain (level of expertise the organization had in the domain before starting the project, characterizing the application domain (e.g., finance, automotive), project size (lines of code, number and geographic distribution of the stakeholders), interaction with stakeholders, project requirements (amount of change, non-functional requirements), agile requirements methods used, re-use and product line methods used. The purpose of the second part of the questionnaire is to present a small set of project scenarios to the expert, which are as closely related to their area of expertise as possible, and obtain the expert‘s opinion about what kind of RE process to use on these projects. In turn, based on the data collected from the second part of the questionnaire, a decision network will be developed to provide various options regarding to specific software product line and agile method techniques for each phase of requirement engineering for a specific project. 62 APLE-RE Questionnaire Questionnaire GUI APLE-RE Questionnaire Part I APLE-RE Questionnaire Part II Selecting Scenarios Algorithm Database APLE-RE Scenarios Expertise Repository Foundations RE Techniques Agile Methods PL Methods Figure 13. The Components of the Questionnaire Figure 16 describes the high level activity diagram in developing the APLE-RE questionnaire. Collect Expert’s Background - specification of the Questionnaire Part I - collect information about the experts‘ specific area of expertise - scenarios repository, which will be presented to experts - present a small set of project scenarios, which are closely related to the area - specification of the Questionnaire Part II Define Project Scenarios Present Scenarios to Expert Collect Data - obtain experts opinion about APLE-RE process Figure 14. Developing the Questionnaire The rest of this chapter is organized as follows: The methodology of building the questionnaire is given in Section 6.2. The methodology of Defining Project Scenarios is described in Section 6.3. The detailed introduction and analysis of Presenting Scenarios to Expert are presented in Section 6.4. The summary and conclusion are given in Section 5.5. The conclusion is given in Section 6.5 5.2 Methodology The questionnaire is systematically developed (refer to Figure 18); the main steps are described below. 63  Create initial questionnaire  Refine, extend as a result of beta testing and data mining for “hotspots” Iterative Approach Prepare Background/ Foundation - Literature Survey - RE relationships to Agile Principles - ―Good‖ Questionnaire Design Specify Questionnaire - Independent Internal Reviews of Specification and Implementation - Revise Specification and Implementation Implement Questionnaire Beta Test Questionnaire - Independent External Reviews of Specification and Implementation - Revise Specification and Implementation Deploy Questionnaire and Collect Data Data for BBN Creation and Maintenance Figure 15. Developing the Questionnaire Prepare Background/Foundation. Several activities are performed to establish a solid foundation for this research. The first activity is to carry out a rigorous literature survey in three key areas: Requirements Engineering (RE) approaches in Agile Methods, RE approaches in Product Line Engineering, and established work in the area of questionnaire design. For the literature survey for RE in agile and product line engineering approaches, 66 articles and books are considered. Two main sources [15][98] are utilized to identify the characteristics of a ―good‖ questionnaire. The second activity involves analyzing the 12 principles of agile methods [86] and ranking them with respect to their impact and relationship to established RE activities (elicitation, specification, analysis, negotiation, validation, and management). The relationship of each principle to the RE activities are ranked using three values: high, medium, and low. This analysis is necessary to focus the questionnaire on the appropriate area and elicit good questions to ask the experts. Specify the Questionnaire. With the background in place, the next step was to specify the questionnaire. The questions and structure of the questionnaire were iteratively defined, reviewed and corrected. Brainstorm/identify possible questions. A collection of possible questions is generated; an initial structure for the questionnaire is proposed. This activity is driven using the analysis of the RE activities with respect to the agile principles and the knowledge from the literature survey in agile methods and product line engineering techniques. The results of the analysis of the RE activities indicate that principles 2, 3, 6 and 10 are the most highly related; in addition 1 and 4 also rate careful attention in our questionnaire development. For example, Principle 6 is ―The most efficient and effective method of conveying information to and within a development team is face-to-face conversation‖; it was ranked as highly related to all RE activities. Based on this, questions about the level of stakeholder interaction, project size, and geographic distribution of the stakeholders were proposed. 64 Propose Questions and Structure. Using ―good‖ questionnaire design principles, questions/possible responses and the overall structure of the questionnaire are defined. Examples of ―good‖ questionnaire design principles include a) begin with a few easy (non-threatening) and interesting questions that introduce the respondents to the questionnaire; b) group the questions into logically coherent sections; and c) organize the questions into a meaningful order and format. The overall structure of the questionnaire into two main parts converged rapidly, by the third iteration. For each main part, however, defining the finer grain structure and the specific questions required numerous iterations. The purpose of the first part is to collect information about the expert‘s specific area of expertise. For example, some experts may work in embedded software development, web based software development, information systems, and so on. The purpose of the second part of the questionnaire is to present a small set of project scenarios to the expert, which are as closely related to their area of expertise as possible, and obtain the expert‘s opinion about what kind of RE process to use on these projects. In turn, based on the data collected from the second part of the questionnaire, a decision network will be developed to provide various options regarding to specific software product line and agile method techniques for each phase of requirement engineering for a specific project. Implement the Questionnaire. The questionnaire has been developed as a web based application, which allows for convenient, international access. It is implemented using C#; data from the responses are stored in a MySQL database. The questionnaire has been implemented in two major iterations. In each iteration a section of the questionnaire was implemented, reviewed (independently reviewed by non-developers on the team), and corrected. The first iteration was for Part I and the second iteration was for Part II. The questionnaire is available at [4]. Beta Test the Questionnaire. The questionnaire is beta tested; a set of 6 experts in the community has been asked to fill in the questionnaire. They are provided with a review form to help identify issues, concerns and problems with the questionnaire. The beta testers have been encouraged to provide frank comments and critiques about the questionnaire. Based on the feedback from the beta testers, the questionnaire is updated. Deploy the Questionnaire. Once the questionnaire is updated, it is disseminated to the experts in the community. Researchers and practitioners involved with program committees and/or participants at related workshops (e.g., APLE 2006, RWASE 2007, SPLC 2007) are invited to respond; in addition general announcements are to be made on related newsgroups. A minimum sample size of 40 respondents is our goal; we anticipate the respondents to be a mix of researchers and practitioners. 5.3 Collect Expert’s Background The focus of this section is on the specification of the Questionnaire Part I. We anticipate the specification of the questionnaire to evolve and plan to release revised versions of this technical report to reflect the 65 changes. A total of 37 questions were defined and organized into seven subsections: project type (1 question), project domain (3 questions), project size (3 questions), project interaction with stakeholders (5 questions), project requirements (8 questions), agile requirements methods used (5 questions), re-use and product line methods used (12 questions). The project type question asked whether the expert‘s opinion was based on a new project, on-going project, or re-engineering a legacy system. Project domain related questions included, for example, identifying the level of expertise the organization had in the domain before starting the project, characterizing the application domain (e.g., finance, automotive), etc. 5.4 Define Project Scenarios A systematic methodology has been used to define the project scenarios for the questionnaire. Currently, there are nine sets of project scenarios defined (one set for an application); each set has 18 specific scenarios that vary is size, duration, complexity, etc. in the scenario collection. The application domains include: home appliance control system, online shopping system, online banking system, accounting system, student registration system, income tax system, medical system, printer system and automotive embedded system. The scenarios have been incorporated into Part II of the questionnaire. The requirements for the project scenarios are captured and presented in this section using a straightforward approach: shall statements. Each requirement is stated, followed by the reason why the requirements have been included (i.e., the rationale). The scenarios shall include applications that are new projects and on-going enhancements. Rationale: Need to include diverse types of projects, as experts may believe this is highly related to the degree of aglity and/or the use of product line engineering techniques that are suitable for a project. The scenarios shall include a wide variety of domains: Online Shopping System, Online Banking System, Accounting System, and Student Registration System, Home Appliance Control System, Automotive Embedded System, Medical System, and Printer System. Rationale: Need to include multiple domains; as product line engineering techniques are being used in diverse domains, as experts may believe that the domain may be highly related to the degree of aglity and/or the use of product line engineering techniques that are suitable for a project. The scenarios shall include web-based information systems, traditional client-server information systems, and embedded systems. 66 Rationale: Need to include diverse kinds of projects as experts may believe that the domain may be highly related to the degree of aglity and/or the use of product line engineering techniques that are suitable for a project. The scenarios shall include applications that are under product-line and single product development. Rationale: Need to include diverse kinds of projects; the single product development can be viewed as the a product line with one family member The scenarios shall include applications that are using agile and planned methodologies. Rationale: Need to include diverse kinds of projects; range of projects from very agile to very planned need to be supported. The scenarios shall include applications that are developed in one or more geographic sites. Rationale: Need to include diverse kinds of projects; geographically distributed projects need to be considered as outsourcing becomes more common. Experts may believe that the geographic distribution may be highly related to the degree of aglity and/or the use of product line engineering techniques that are suitable for a project (e.g., the principles of agile methods promote face-to-face meetings) The scenarios shall include applications that have a range of stakeholder involvement in the requirements engineering process. Rationale: Need to include diverse kinds of projects; range of projects from very high (frequent) level of stakeholder interaction to very low (infrequent) level of interaction. Experts may believe that the level of stakeholder interation may be highly related to the degree of aglity and/or the use of product line engineering techniques that are suitable for a project (e.g., the principles of agile methods promote frequent, stakeholder user interaction). The scenarios shall include applications that range in size (SLOC estimates) from <10 KSLOC to >1000 KSLOC. Rationale: Need to include diverse sizes of projects. Experts may believe that the size of the project may be highly related to the degree of aglity and/or the use of product line engineering techniques that are suitable for a project.The SLOC estimate is a simple way to estimate the size, although other metrics could be used in the future. A systematic methodology has been used to define the project scenarios for the questionnaire (refer to Figure 2). The steps include define project properties, define an initial set of project scenarios, identify additional sets of project scenarios, review and revise the scenarios, organize the scenarios into report form. Each of these steps is described below. 67 Define project properties Define an initial set of project scenarios Identify additional sets of project scenarios Review and Revise the Scenarios Organize the scenarios into report form Figure 16. Developing the Scenarios Step 1: Define project properties. Purpose: Define properties about the projects in each scenario. Role: Senior team member Inputs: Vision Document for a Home Appliance Control System (HACS) example. Outputs: A properties list as a guideline is defined in this step. The properties is abstracted from the HACS example, which are cover most important project profile, including project specific configuration, e.g. developers number, duration, size, etc, product line – sensitive attribute like if the project is a new system or enhanced version of a existent system, and agile method - sensitive attribute like if the project is safety and security critical and how many locations are the developers scattered in. Step 2: Define an initial set of project scenarios. Purpose: Define a set of scenarios that can be used by junior members of the team (Ph.D. students) as an example, to assist them in defining additional sets of scenarios. Role: Senior team member Inputs: Vision Document for a Home Appliance Control System (HACS) example. Outputs: A set of 18 scenarios for a HACS have been defined in this step. 68 Step 3: Identify additional sets of project scenarios to define. Purpose: Create a more complete repository of examples to be used in the questionnaire. Role: Junior team members Inputs: HACS scenario set. Outputs: An additional eight sets of project scenarios have been defined, including Online Shopping System, Online Banking System, Accounting System, Student Registration System, Income Tax System, Medical System, Printer System and Automotive Embedded System. The scenarios are collected from software engineering industry, and they were recorded as much in detail as possible. For each application area in every domain, more than 10 scenarios are gathered. Some of the scenarios are coming from open source website [97], like http://sourceforge.net/. Open source describes the principles and methodologies to promote open access to the production and design process for various goods, products, resources and technical conclusions or advice. The term is most commonly applied to the source code of software that is made available to the general public with either relaxed or non-existent intellectual property restrictions. This allows users to create user-generated software content through either incremental individual effort, or collaboration. The open source model of operation can be extended to open source culture in decision making which allows concurrent input of different agendas, approaches and priorities, in contrast with more centralized models of development such as those typically used in commercial companies. "Open source" as applied to culture defines a culture in which collective decisions or fixations are shared during development and made generally available in the public domain. This collective approach moderates ethical concerns over a "conflict of roles" or conflict of interest. Participants in such a culture are able to modify the collective outcomes and share them with the community. A JAVA tool is developed to calculate the lines of code. For open source projects, we always assume that they are all using agile methodology. In addition, based on the duration and number of developers provided by those open source projects, we estimate the ―real‖ project profile for those projects. Step 4: Review and Revise the Scenarios. Purpose: Thoroughly review the scenarios for completeness and correctness, with respect to the requirements, and clarity of the scenarios. Role: Junior team members Inputs: All scenario sets. 69 Outputs: Revised version for all scenario sets Because most of the project scenarios are coming from open source, the project dureation, the number of locations, demonstration frenquency and some other project profiles need to be adjusted to be more realistic. The following date are estimated in the scenarios. For agile method estimated general productivity is 30 LOC - 200 LOC per day per man, it varies: For Embedded system: 30 - 50 LOC per day per man For information systems : 50 - 100 LOC per day per man For extremely agile product like games: 100 - 200 per day per man For product line, the estimated general productivity is 30 - 80 LOC per day per man And the projects in product line are more rigorous than those in Agile, mostly these project are in areas like embedded system or even military. Step 5: Organize the scenarios into report form. Purpose: Integrate all the scenarios sets into one entity. Make it easier to manage and can be readily extended to consdier additional scenarios. Role: Junior team members Inputs: All scenario set documents. Outputs: Final technical report: Defining Requirements Engineering Processes for Product-line Development: Building Scenarios 5.5 Present Scenarios to Expert In this section, a set of project scenarios that are highly related to the experts‘ area of expertise are presented to the user. The selection is based on answers provided in questions No. 1, 3, 4, 5, 6, 7, 8, 12, and 28 in Part I. The selection algorithm is presented below. For each project scenario that is selected, the expert is asked a set of questions about what RE process they believe is the best suited for the project. A comprehensive set of project scenarios has been defined, which includes 9 sets of project scenarios. An algorithm to select the project scenarios that are the closest match to the experts‘ background is needed. The Narrow-Down Algorithm is proposed in this work to accomplish this. 70 The responses to questions in Part I of the questionnaire are used in this algorithm. For each response, the available scenario set is reduced. The steps in the algorithm are defined below. 5.5.1 Project Scenarios Before running the algorithm, two mapping tables need to be prepared. This step is static because these two tables are set up manually and stored in database in advance. In opposite, the other part of the algorithm is dynamic, and it is executed in running time. The first table is mapping the project characteristics into scenario sets. It uses the response to Part I, Question 3 in the questionnaire. Seven different project characteristics are defined in the questionnaire. The expert is allowed to select one or more of these options. Nine scenario sets are defined in [9]. In each scenario set, eighteen scenarios are presented, which range in characteristics such as from very agile to less agile, single product to product line development, etc. For each project characteristic defined in Questionnaire, one or more scenario sets are mapping to it. Therefore, looking up the table guarantees the return results is the scenario sets which are mostly relevant to experts‘ answers for project characteristics. For example, in the database, if the project characteristic is information system (data intensive), two scenario sets are available. Information system (data intensive) Information system (data intensive) Accounting System Income Tax System There, if the answer of expert is information system (data intensive), then two scenario sets will return, accounting system and income tax system. Another prerequisite table is to map the project characteristics into scenario sets. It is similar with step 1. It uses the response to Part I, Question 4 in the questionnaire. In the questionnaire, 12 domains are defined. Therefore, looking up the table guarantees the return results is the scenario sets which are mostly relevant to experts‘ answers for project domains. For example, in the database, if the project domain is finance system, three scenario sets are available. Finance system Finance system Finance system Online Banking System Accounting System Income Tax System 71 There, if the answer of expert is finance system, then three scenario sets will return, online banking system, accounting system and income tax system. For those domains that cannot find mapping in scenario sets, the notation ―Not available‖ is used. 5.5.2 Narrow Down Algorithm (informal description) The algorithm has 5 main activities (refer to Figure 18). Project Scenarios (defined in database) Answer to Question 3 and 4 (Questionnaire Part I) Identify set of project scenarios exactly matching system type and domain DB schema defined separately for project scenarios Project Scenarios (defined in database) Answer to Questions 1,5-8,12 and 28 (Questionnaire Part I) Identify initial set of project scenarios closely matching additional input constraints n is the desired number of project scenarios to be found k is the current number of project scenarios found [kn scenarios] (too many) [k=n scenarios] (correct no.) Select Superset of Closely Matching Scenarios (relax constraints) Select Subset of n Closely Matching Scenarios All constraints have been released. Present Closely Matching Scenarios to User Figure 17. Narrow Down Algorithm When characteristics table and domain table are prepared, in order to reduce the available scenarios, using intersection to Identify set of project scenarios exactly matching system type and domain is a promising method. The inputs are the project scenarios and the expert answers, and the outputs are available scenario sets matching project type and domain. If no scenario returns, then the algorithm is terminated. The next step is to Identify initial set of project scenarios closely matching additional input constraints, including new/enhanced project, number of developers, project duration, lines of code, project 72 interaction, demo frequency, and Agile/PL project. The output of the step is a set of available scenarios. As described above, the system will present n scenarios to experts. If the number of the available scenarios is less than n, the activity, Select Superset of Closely Matching Scenarios (relax constraints), will be executed. If the number of the available scenarios is larger than n, then Select Subset of n closely Matching Scenarios. If the number of the available scenarios is exact n, then Present Closely Matching Scenarios to User. Figure 20, 21, and 22 are low level activity diagrams for Identify initial set of project scenarios closely matching additional input constraints, Select Superset of Closely Matching Scenarios (relax constraints), and Select Subset of n closely Matching Scenarios. 73 Identify project scenarios in matching new/enhanced project [n10 scenarios] [n1≥n] n1, n1 scenarios Return scenarios [has more constraint] [no more constraints, no scenario] Identify project scenarios in matching no. of developers [n20 scenarios] Return scenarios [has more constraint] [no more constraints, no scenario] Identify project scenarios in matching project duration [n30 scenarios] Return scenarios [has more constraint] [no more constraints, no scenario] Identify project scenarios in matching LOC [n40 scenarios] Return scenarios [has more constraint] [no more constraints, no scenario] Identify project scenarios in matching project interaction [n50 scenarios] Return scenarios [has more constraint] [no more constraints, no scenario] Identify project scenarios in matching demo frequency [n60 scenarios] Return scenarios [has more constraint] [no more constraints, no scenario] Identify project scenarios in matching Agile/PL project [n70 scenarios] Return scenarios [has more constraint] [no more constraints, no scenario] [n7≥n] n7, n7 scenarios [n6≥n] n6, n6 scenarios Identify project scenarios with all constraints [n5≥n] n5, n5 scenarios [n4≥n] n4, n4 scenarios Identify project scenarios in matching demo frequency [n3≥n] n3, n3 scenarios [n2≥n] n2, n2 scenarios 74 Figure 18. Identify initial set of project scenarios closely matching additional input constraints The input of this step is a scenario set mapping to project type and domain. Then several activities are running in parallel to find relevant scenarios by mapping new/enhanced project, number of developers, project duration, lines of code, project interaction, demo frequency, and Agile/PL project. The inputs of these activities are a set of scenarios, which are defined in Identify initial set of project scenarios closely matching additional input constraints, and experts answers for Questions 1, 5-8, 12 and 28 (Questionnaire Part I). Identify project scenarios in matching new/enhanced uses the response to Part I, Question 5 in the questionnaire. Several project types are defined in question 1, which are new project, on-going project and re-engineering project of a legacy system. These options are assumed as constraints. On-going projects and re-engineering projects of a legacy system are regarded as enhancement projects. Initially, using expert answers to find related scenarios, the number of scenarios marked as n1. If less than n scenarios return, then relax the constraint, adding above and below options (if possible) as new condition, re-search from the input until find n or more scenarios, then record these scenario. If when all the constraints are released, that is, all the options are using in finding related scenarios, the number of returned scenarios is still less than n, then forward these scenarios to the next activity, Present Closely Matching Scenarios to User. If after relax all the constraints and no scenario is found, then the algorithm is terminated. Identify project scenarios in matching no. of developers uses the response to Part I, Question 5 in the questionnaire. Currently, most of the scenarios are coming from some small projects. However, the number of developers that are defined in the questionnaire varies, from less than 25 to more than 150. Initially, using expert answers to find related scenarios, the number of scenarios marked as n2. It considers options above and below exact match, in the cases when less than n scenarios return. If when all the constraints are released, and the number of returned scenarios is still less than n, then forward these scenarios to the next activity, Present Closely Matching Scenarios to User. If after relax all the constraints, still no scenario is found, then the algorithm is terminated. Identify project scenarios in matching project duration uses the response to Part I, Question 6 in the questionnaire. Several options of project duration are presented in the question, from less than 6 months to more than 5 years. Initially, using expert answers to find related scenarios, the number of scenarios marked as n3. It considers options above and below exact match, in the cases when less than n scenarios return. If when all the constraints are released, and the number of returned scenarios is still less than n, then forward these scenarios to the next activity, Present Closely Matching Scenarios to User. If after relax all the constraints, and no scenario is found, then the algorithm is terminated. 75 Identify project scenarios in matching LOC uses the response to Part I, Question 7 in the questionnaire. Lines of code (LOC) is another important factor for project size. It varies from the agile respect, which are some small projects with LOC less than 10K, to product line respect, which are larger one with LOC more then 1,000K. Initially, using expert answers to find related scenarios, the number of scenarios marked as n4. It considers options above and below exact match, in the cases when less than n scenarios return. If when all the constraints are released, and the number of returned scenarios is still less than n, then forward these scenarios to the next activity. If after relax all the constraints, still no scenario is found, then the algorithm is terminated. Identify project scenarios in matching project interaction uses the response to Part I, Question 8 in the questionnaire. Three sub-questions are relative to project locations, including total number of locations, number of customer locations and number of developer locations. Only the total number of locations is considered. Initially, using expert answers to find related scenarios, the number of scenarios marked as n5. It considers options above and below exact match, in the cases when less than n scenarios return. If when all the constraints are released, and the number of returned scenarios is still less than n, then forward these scenarios to the next activity, Present Closely Matching Scenarios to User. If after relax all the constraints, still no scenario is found, then the algorithm is terminated. Identify project scenarios in matching demo frequency uses the response to Part I, Question 12 in the questionnaire. Initially, using expert answers to find related scenarios, the number of scenarios marked as n6. It considers options above and below exact match, in the cases when less than n scenarios return. If when all the constraints are released, and the number of returned scenarios is still less than n, then forward these scenarios to the next activity, Present Closely Matching Scenarios to User. If after relax all the constraints, still no scenario is found, then the algorithm is terminated. Identify project scenarios in matching Agile/PL project uses the response to Part I, Question 28 in the questionnaire. In the questionnaire, several project types are defined, which are single product, first product in the product line, second product in the product line and at least the third in the product line. Initially, using expert answers to find related scenarios, the number of scenarios marked as n7. It considers options above and below exact match, in the cases when less than n scenarios return. If when all the constraints are released, and the number of returned scenarios is still less than n, then forward these scenarios to the next activity, Present Closely Matching Scenarios to User. If after relax all the constraints, still no scenario is found, then the algorithm is terminated. When all the scenarios are gathered from these activities, it is reasonable to use intersection relationship to get the final result because the system needs to select the most relative scenarios from all the scenarios. Identify project scenarios with all constraints is proposed in this step to accomplish this and records the scenarios and the number of related scenarios k. By comparing k and the desired number of scenarios n, 76 three different conditions are presented in 2 activity diagrams. Figure 20 shows the condition: if k is less than n, that is too few scenarios are found. Therefore, a relaxing constraints algorithm is proposed. Set N, initially N={ n1, n2, n3, n4, n5, n6, n7} Calculate n‘=min(p), p  N [N is not empty] [ni=n‘] Check constraints n is the desired number of project scenarios to be found k is the current number of project scenarios found N is a set. Each element in this set represents the number of scenarios returned by each activity from Figure 4. [N is empty] [All constraints are released] Remove n‘ from N [Has more constraints] Relax constraints in particular step/steps Return m (mn, will be presented in Step 10; k=n, present Set R to user. Step 9: Select Superset of Closely Matching Scenarios (relax constraints) Input: Available Scenario Sets (Constraint: characteristics): R1, R2, R3, R4, R5, R6, and R7. the desired number of project scenarios to be found: n the current number of project scenarios found: k Output: Updated Available Scenario Sets (Constraint: all constraints): R8 87 Initially, Set N = { n1, n2, n3, n4, n5, n6, n7 } int[] n‘ = min( n1, n2, n3, n4, n5, n6, n7 ); Superset():  ni  n‘ { if ( |Ci| = | Oi |) { N.remove(n‘); if ( N = ø ){ R = R8; GOTO Step 11; } continue; } interation flag = true; int m = k; Cn’ = Closet( Cn’ ); Ri = Search(Attr, Cn’, R0); R8= R1 ∩ R2 ∩ R3 ∩ R4 ∩ R5 ∩ R6 ∩ R7. k = | R8 |; if( kn ) GOTO Step 10; if( k==n ) R = R8; Present Set R to user; } Step 10: Select Subset of n Closely Matching Scenarios Input: Available Scenario Sets (Constraint: all constrains): R8 the current number of project scenarios found: k iteration flag Output: n scenarios Subset (): if ( iteration flag == false ) { R = RandomSelect(R8, n ); } if (iteration flag == true ) { R = m ∪ RandomSelect(R8, (n-m) ); } 5.6 Implementation The questionnaire has been developed as a web-based application, which allows for convenient, international access. It is implemented using C#; data from the responses are stored in a MySQL database. The questionnaire has been implemented in two major iterations. In each iteration a section of the questionnaire was implemented, reviewed (independently reviewed by non-developers on the team), and 88 corrected. The first iteration was for Part I and the second iteration was for Part II. Part II of the questionnaire is currently under development. The questionnaire is composed of a welcome screen (Figure 22), two main parts (Part I and Part II), and a closing screen. The welcome screen provides instructions on how to use the questionnaire; the closing screen provides additional contact information. The purpose of Part I is to collect the background/context for the expert‘s opinion. The purpose of Part II is to collect the expert‘s opinion on the agile and product line engineering requirements engineering techniques they would recommend for a set of project scenarios. Figure 21. APLE-RE Questionnaire Welcome Screen Figure 22. APLE-RE Questionnaire Part I 89 5.7 Conclusions The on-line questionnaire on Agile Product Line Requirement Engineering is used to elicit expert options on the appropriateness about a specific RE activity satisfying an agile product line project configuration. The questionnaire contains two parts. The first is used to elicit project configuration as well as expert background and the second part is used to elicit the expert opinions on Agile Product Line Requirement Engineering activities with respect to their project configurations, i.e., scenarios. It is now available online at [4]. The questionnaire will help to elicit raw data that will later on be manually reviewed for the input into (or configuration for) our expert engine. The expert engine in turn will produce suggested RE activities according to various projects configurations based on the conditional probabilities calculated on the analyzed data. A systematic methodology has been used to define the project scenarios for the questionnaire. Currently, there are nine sets of project scenarios defined (one set for an application); each set has 18 specific scenarios that vary is size, duration, complexity, etc. in the scenario collection. In Part II of the questionnaire, a set of project scenarios that are highly related to the experts‘ area of expertise are presented to the user. The selection algorithm is presented. For each project scenario that is selected, the expert is asked a set of questions about what RE process they believe is the best suited for the project. 90 6 APLE-RE Process Repository 6.1 Introduction The APLE-RE Process Repository contains a set of process templates. A commonly quoted phrase in software process engineering is that ―the software processes are software too‖ [99]. This phrase indicates that the nature of software process development is very similar to software development. In the past decades, numerous software process development approaches have been proposed [2] [46][88]. In the template, the processes will be tailored versions of the RUP and will be presented in UML activity diagrams. The user can tailor the process definition and publish it. The process definitions will be an extensive set of tailored RUP process templates, which range from very agile to plan driven approaches for single product and product line RE. The rest of this chapter is organized as follows: The methodology of constructing APLE-RE Process Repository is given in Section 6.2. Agile Product Line RE Process Template is introduced in Section 6.3. Product Line RE Process Template is described in Section 6.4. The summary and conclusion are given in Section 6.4. 6.2    Methodology When developing an APLE-RE Process Repository, the following fundamental principles are followed: Include all essential process elements into the process model Develop a process model from scratch Develop a process model by tailoring an existing one or a process template The definition of the elements of the RE process model within the framework is based on the foundation work of RUP, which has been introduced in Section 2.2, as well as our research in RE process modeling. Specifically, these elements are:   Roles: Roles are defined as the functions performed by people who carry on certain activities or are involved in certain activities. Activities: An activity can produce externally visible changes of the state in the software product. There are usually many activities defined in an RE process model which are categorized into different phases (see Section 2.3.4 for the five phases of an RE process).   Techniques: The RE techniques are inseparable parts in an RE process model. Many techniques might be included in an RE process model. Artefacts: Artefacts are defined as products of an activity or several activities. In many cases, artefacts in RE processes are documents. Different notations can be used in these documents. RE process development for given software project can contain the following major tasks in this research: 91    Provide the guideline to define the process templates with different levels of agility in single product or product line product context. Define the activities which can best address the RE disciplines, as well as the situation of the given software project in single product or product line product context. Select the most suitable RE techniques for a software project based on the APLE-RE disciplines, as well as the characteristics of the software project. The template can be classified into two categories, one is single product, and another is product line product. Single products represent these products which are separate with others. They are developed individually. In the other hand, product line products are a set of projects which are a set of software-intensive systems that share a common, managed set of features are produced from a set of re-usable core assets. Traditional software development typically involves a great deal of up-front planning and modeling. Apart from very detailed, ―inch-pebble‖ project plans [Boehm 2002], this has also a great impact on the way RE is performed. RE activities in traditional software projects strive at producing complete and unambiguous requirements documents that are intended to facilitate downstream activities and reduce rework as much as possible. This idea is mostly based on the belief that the project will have an exponential cost of change curve where changes to the system will become exponentially more expensive the later in the software lifecycle they occur. Based on the agility, three degree of agility are classified, low, medium and high. There are more or less rigorous ways to apply SPLE practices. For example, product derivation can be implemented using proactive engineering or reactive engineering. In a forward engineering approach, the reusable assets are developed before the product is built. In a reverse engineering approach, the product is built first and subsequently the reusable assets are recovered from the product and integrated back into the platform. 92 Category: Product Type: (Single Product, PL Product) Agility: (Low, Medium, High) Product Line: Degree of Concurrency in PL activities Degree of Concurrency in DE activities Degree of Concurrency in AE activities 00 Single Product RE Process Templates Single Product RE Process with low agility and low degree of concurrency Single Product RE Process with medium agility and low degree of concurrency ………… Single Product RE Process with high agility and high degree of concurrency Forward Product Line RE Process Templates PL RE Process with low agility and low con. in PL activities, low con. in DE and low con. in AE PL RE Process with medium agility and low con. in PL activities, low con. in DE and low con. in AE ………… PL RE Process with medium agility and medium in PL activities, medium con. in DE and medium con. in AE ………… PL RE Process with high agility and high in PL activities, high con. in DE and high con. in AE Reverse Product Line RE Process Templates PL RE Process with low agility and low con. in PL activities, low con. in DE and low con. in AE PL RE Process with medium agility and low con. in PL activities, low con. in DE and low con. in AE ………… PL RE Process with medium agility and medium in PL activities, medium con. in DE and medium con. in AE ………… PL RE Process with high agility and high in PL activities, high con. in DE and high con. in AE Figure 23. APLE-RE Process Repository The pre-defined RE process templates for single product RE are summarized in Table 11; the templates for product line RE are in Table 16 and Table 17. Table 16. Single Product RE Process Templates Template ID SP-1 SP-2 SP-3 SP-4 SP-5 SP-6 SP-7 SP-8 SP-9 Degree of Agility (low, medium, high) Low Medium High Low Medium High Low Medium High Degree of Concurrency in RE sub-activities Low (sequential) Low Low Medium (some overlap) Medium Medium High (concurrent) High High 93 Table 17. Forward Product Line RE Process Templates Template ID Degree of Agility (low, medium, high) // degree of agility is low PL-1 Low PL-2 Low PL-3 Low PL-4 Low PL-5 Low PL-6 Low PL-7 Low PL-8 Low PL-9 Low PL-10 Low Degree of Concurrency in PL activities (domain, application)* Low Low Low Low Low Low Low Low Low Medium Degree of Concurrency within domain engineering activities Degree of Concurrency within application engineering activities Low (sequential) Low Low Medium (some overlap) Medium Medium High (concurrent) High High Low Low (sequential) Medium (some overlap) High (concurrent) Low Medium High Low Medium High Low (sequential) … PL-27 Low High //degree of agility is medium PL-28 Medium Low .. PL-54 Medium High //degree of agility is high PL-55 High Low … PL-81 High high High Low high Low high High Low High Low high Table 18. Reverse Product Line RE Process Templates Template ID PL-82 Degree of Agility (low, medium, high) Low Degree of Concurrency in PL activities (domain, application)* Low Low Low Low Low Low Low Low Low High Degree of Concurrency Degree of Concurrency within domain within application engineering activities engineering activities Low Low Low Medium Medium Medium High High High High Low Medium High Low Medium High Low Medium High High … PL-162 High Figure 24 describes the component in templates. Each template can be decomposed into RE phases. We 94 argue the correctness and completeness of these five phases in Chapter 7. Furthermore, phases can be decomposed into activities. In addition, activities use different techniques. Template Decomposed Elicitation Phase Specification Phase Decomposed Analysis Phase Negotiation Phase Validation Phase Empirical Studies Activity A Activity B Activity C Decomposed Technique A Technique B Empirical Studies Figure 24. Template to Structure of an APLE-RE Process Template 6.3 Product Line RE Process Template A software product line is a set of software-intensive systems sharing a common, managed set of features that satisfy the specific needs of a particular market segment or mission and that are developed from a common set of core assets in a prescribed way. The benefits from product line development include reducing the cost, enhancing the quality, shorting to market, etc. However, there are additional costs associated with a software product line approach. Different from single system engineering, product line engineering share a platform that provides capabilities that are common to the family of products. The common platform is systematically re-used and adapted to develop new products that meet the needs of the stakeholders. Consequently, the platform and the variability required to customize the product are valuable assets that need to be carefully managed. Some additional organizations may be established to focus on each activities or cooperation between individual project teams. A typical product line practice has two important activities: The Core Asset Development and the Product Development. In the Core Asset Development activity, which is also called Domain Analysis and Engineering (DA&E), product family requirements and potential family members are identified, analyzed and a reusable domain framework is developed. In the Product Development activity the domain framework is instantiated to develop individual applications. The software product line engineering paradigm is composed of two main processes: domain engineering and application engineering. The separation into two processes indicates a separation of concerns with respect to variability. Domain engineering is responsible for ensuring that the available variability is appropriate for producing the applications. The platform is defined with the right amount of flexibility in 95 many reusable artefacts. A large part of application engineering consists of reusing the platform and binding the variability as required for the different applications. The following activity diagram illustrates the software product line process. Three main product line activities are iterative and concurrent Domain Engineering Output Core Assets Management Control Control Application Engineering Output Application Decomposes into activities to engineer a re-usable platform (requirements, designs, code, etc.) Decomposes into activities to manage the development/ interactions of the re-usable assets and each customized application Decomposes into activities to engineer customized applications ( requirements, designs, code, etc.) Figure 25. Activity Diagram for Product Line Engineering One can apply product line practices in several ways. For example, products in a product family can be developed using proactive engineering or reactive engineering. In proactive approach, the core assets are developed first, that is, domain engineering is performed followed by application engineering. The common requirement and variable requirement are evaluated in domain engineering. And reuse these core assets to build specific products in application engineering. In a reactive approach, the product is built first and subsequently the reusable assets are recovered from the product and integrated back into the platform. Further, variability models are used to represent variation among the products that the platform should support. Product Line RE process template applies proactive approach, domain requirement engineering followed by application requirement engineering. Both of them follow the six-phase process, which are elicitation, specification, analysis, negotiation, validation and management. 6.3.1 Domain Requirement Engineering The purpose of domain requirement engineering is, first, to define the domain basic goal, its scope and boundaries; second, to develop the common and variable domain requirements and their precise documentation. In the first stages of domain engineering, the product line scope is defined and the products to be included in the product line are identified or defined if they do not already exist. A major difference between software product lines and traditional single product is that the product line needs a very clear vision of 96 which a set of products will be developed. The vision describes what functionality should be supported in a general manner for the whole product line and what functionality should be regarded as specific to a single system. 6.3.1.1 Elicitation Phase Elicitation refers to gathering the requirements of the system from different stakeholders. Boundaries, identification of stakeholders, goals and tasks performed are discovered in this phase. In product line development, elicitation puts more effort on product line‘s scope, explicitly capturing the anticipated variation by the application of domain analysis techniques, the incorporation of existing domain analysis models, and the incorporation of use cases that capture the variations that are expected to occur over the lifetime of the product line. The following figure presents the activities in domain requirement elicitation phase. Domain engineer Collect Domain Information Domain engineer Stakeholder Request Stakeholder Request Understand Relevant Domains Domain Glossary Domain engineer Domain engineer Stakeholder Request, Domain Glossary Analyze Market Market Analysis Stakeholder Request, Domain Glossary Build Business Case Business Model Domain engineer Market Analysis, Business Model Develop Scope and Boundary Scope and Boundary Figure 26. Activity Diagram for Domain Requirement Elicitation Phase At the end of this phase, a draft of Vision document is developed. The vision consists of very high level requirements. It communicates to the team a common understanding of the project and is a gauge against which all future decisions should be validated, it will guide the team during the development cycle. The domain glossary, analyze market report, business case report and scope and boundary report can be part of the Vision document. 97 Collect Domain Information In the scope of a product line, the requirements of every product should be determined, even the requirements of the products that still have not been developed, but are inside the product line scope. Therefore, the very beginning of elicit domain requirement is to gather as much as useful information. Domain engineers are responsible for collecting these information. Related stakeholders (customer, user, marketing person, and so on) are definitely involved as well. The output is the initial stakeholders‘ request. This artifact can contain any type of format, such as meeting minutes, email, informal or formal request from stakeholders, even white board information. It may also contain references to any type of external sources to which the product line must comply. These information may come from stakeholder interviews, workshops, legacy systems, business models, etc.     Mandatory Role: Domain Requirement Engineer Optional Role: Input: Output: Stakeholders Related Knowledge Stakeholders‘ Request Understand Relevant Domains This activity addresses collecting and eliciting information from different stakeholders in the product line in order to understand what their needs really are. It is about systematically capturing and utilizing knowledge of systems similar to the ones that developers are about to build. This knowledge provides an informed world view from which can help product line managers to make specific decisions. The collected Stakeholder Requests can be regarded as a "wish list" [Rzepka 89] that will be used as primary input to defining the high-level features of the product line projects. The ―wish list‖ can be described in domain glossary, which drives the specification of the Software Requirements. The Domain Glossary is a compendium of precise definitions for all significant terminology used by experts for discussing problems and solutions in a domain.     Mandatory Role: Domain Requirement Engineer Optional Role: Input: Output: Stakeholders Stakeholders‘ Request Domain Glossary Analyze Market ―A market analysis is an important ingredient in a decision to shift business strategy from single system engineering to product line engineering.‖ After collecting ―draft ideas‖ from various sources, conducting a marketing analysis market is the first step in knowing the market's needs and how it is currently serviced. This can provide key information that is essential in developing product line products and marketing plan. 98 Domain requirement engineer with stakeholders evaluate the stakeholders‘ requests, and analyze the market situation. The output of this activity is market analysis report.. The marketing analysis process can be broken down into six steps: 1. Defining the problem 2. Analysis of the situation 3. Obtaining data that is specific to the problem 4. Analysis and interpreting the data 5. Fostering ideas and problem solving 6. Designing a plan     Mandatory Role: Domain Requirement Engineer Optional Role: Input: Output: Stakeholders, Decision Maker Stakeholders‘ Request; Domain Glossary Market Analysis Build Business Case This activity is to justify the effort to adopt the product line approach for building systems, and then to decide whether or not to include a particular product as a member of a product line. Domain requirement engineers are involved in building business case. They evaluate the market analysis report and give the decision whether or not to develop the product line, or which should be included or excluded. Finally, a business case report is released. The marketing analysis process can be broken down into seven steps: 1. Describe current business 2. Set business goal 3. Define strategy for business case development 4. Identify business process 5. Identify and involve stakeholders 6. Document the baselines 7. Evaluate the results     Mandatory Role: Domain Requirement Engineer Optional Role: Input: Output: Stakeholders, Decision Maker Stakeholders‘ Request; Domain Glossary; Market Analysis Business Case Develop Scope and Boundary 99 This activity is to bound a set of systems by defining those behaviours or aspects that are ―in‖ and those behaviours or aspects that are ―out‖. The Rational Unified Process includes an inception phase to establish ―the project‘s software scope and boundary conditions, including an operational concept, acceptance criteria, and descriptions of what is and is not intended to be in the product‖. So does in product line requirement engineering process template. The input of this activity could be stakeholders‘ request, domain glossary, market analysis, and business case. The output is the product line scope and boundary report.     Mandatory Role: Domain Requirement Engineer Optional Role: Input: Output: Stakeholders Stakeholders‘ Request; Domain Glossary; Market Analysis, Business Case Scope and Boundary Feasible Techniques in Elicitation:  Interviewing Interviewing stakeholders in the specific companies is one of the popular and reasonable techniques, which involves structured or unstructured discussion between requirements engineers and customers. Interviews alone are not sufficient for requirements elicitation in product lines. There are several stakeholders involved and also the organization has to satisfy its business goals. However, interview techniques can support other requirements elicitation techniques. After analyzing domain concepts with domain experts and market experts, potential customers can be interviewed to capture information about a particular topic. Structured Interviews can be conducted if the requirements engineer already has a fairly good knowledge about a concept and wants to get clear answers from the customers to specific questions. Unstructured Interviews can be used if the requirements engineer wants to have an open-ended discussion with the users. Also interviews can be used to communicate common and variable requirements that are already gathered by the users so that any negotiations can take place. Some major limitations with eliciting requirements primarily or exclusively through interviews result from the tremendous responsibility placed on the requirements analyst, especially in product line development. Interview information is collected from different parties, and the information may affect each other. Therefore, the analyst must integrate these different interpretations, goals, objectives, communication styles, and use of terminology into one core asset. Other techniques can be used in conjunction with interviews to help structure these information and facilitate integration.  Issue-Based Information Systems (IBIS) Other techniques can be used in conjunction with interviews to help structure them and facilitate integration. The Issue-Based Information Systems (IBIS) method, addresses social issues by inhibiting unconstructive rhetorical moves and supporting more constructive communication. However, IBIS makes you think within a particular framework of issues, positions, and arguments, and this can be disruptive 100 during the early phases of a design problem which is ―critical and fragile and must be allowed to proceed in a vague, contradictory, and incomplete form as long as necessary‖.  Team Approach Rather than just structuring interviews, another technique focuses on ensuring that information is gathered from all of the affected parties, and that the resulting requirements meet the approval and understanding of all of these parties, rather than just being the work of the requirements analyst. These team approaches to requirements elicitation make sure that issues of scope are properly addressed by getting the appropriate people involved at the very beginning of requirements elicitation. Likewise, they explicitly recognize that there are issues of understanding dependent upon the variety of disciplines and number of people affected by the development of a proposed system. The team approach to requirements elicitation is characterized by JAD, an acronym for Joint Application Design. JAD focuses on improving the group process and getting the right people involved at the start. This technique has been used successfully by IBM since the late 1970s, and its advantages include the promotion of cooperation, understanding, and teamwork among users, developers, and customers. Developers help users formulate problems and explore solutions, while users share ownership of the requirements and associated documents. Through the use of structured meeting procedures, facilitation protocols, and visual aids, JAD enhances idea generation and evaluation, communication, and consensus generation. Preferred Techniques in Elicitation:  Soft System Methodology Soft System Methodology (SSM) deals with problem situations in which there is a high social, political, and human activity component. The SSM can deal with "soft problems" that are difficult to define, rather than "hard problems" that are more technology oriented. Soft problems are the situations in which we know the system is not performing in the desired manner, and we want to find out why and see if we can do anything about it. SSM was developed by Peter Checkland to deal with soft problems; it is composed of seven stages: 1. Find out the problem situation. 2. Express the problem situation through rich pictures (i.e., representations of organizational structure and processes pertinent to the problem situation). 3. Select how to view the situation and produce root definitions. 4. Build conceptual models of what the system must do for each root definition. 5. Compare the conceptual models with the real world. 6. Identify feasible and desirable changes. 7. Make recommendations to improve the problem situation. 101 The primary benefit of SSM is that it provides structure to soft problem situations and enables their resolution in an organized manner. It compels the developer to discover a solution that goes beyond technology. 6.3.1.2 Specification Phase Elicitation is concerned with gathering information from various stakeholders in order to derive the requirements for a system. This collected information needs to be represented in some way, and ideally the gathered statements are expressed ―in a notation which elucidates their implications, prompts further questions, correlates different aspects, and facilitates detailed analysis‖ [Southwell 87, p. 195]. Documenting requirements for software construction is an activity which results in what has been traditionally termed as requirement specification. According to Razpka and Ohno, a requirements specification represents both a model of what is needed and a statement of the problem under consideration. The explicit documentation of the proper common and variable requirements is essential for enabling the planned reuse of requirements in application engineering. The required variability has to document in some appropriate model. The following figure presents the activities in domain requirement specification phase. Domain engineer Vision Document Describe Guidelines SRS Guidelines Domain engineer Domain engineer Stakeholder Request, SRS Guidelines, Vision Document Stakeholder Request, SRS Guidelines, Vision Document Common Requirement Analyze Variability Variable Requirement Analyze Commonality Domain engineer Variable Requirement Model Variability Variability Model Figure 27. Activity Diagram for Domain Requirement Specification Phase 102 Describe Guidelines: This activity is to describe a guideline to document the product line requirements. The stakeholders are clearly identified, classified and formal documented in the guideline. Different with single product development, several stakeholders may have a set of common and variable requirements; therefore, it has to establish consistency across the different requirements artefacts and their documentations. The incorporation of different views facilitates the communication of the commonality and variability of the product line to different stakeholders. In the guideline, these different request from different stakeholders should clearly been recorded. For example, for different stakeholder, one or more specific requirement modelling(s) should be decided. In addition, there are a variety of sources of constraints to be considered. The input of this activity is the Vision Document. The output is Software Requirement Specification Guidelines.     Mandatory Role: Domain Requirement Engineer Optional Role: Input: Output: Stakeholders Vision Document SRS Guidelines Analyze Commonality: This activity is to identify which requirements are common to all applications of the software product line. Before any requirements can be defined as a commonality of the product line, a commonality analysis has to be performed in order to determine which requirements are actually common to all application. Then these common requirements need to be documented in detail in a representation format. Identifying and documenting requirements are performed iteratively in the course of detailing and revising. Moreover, common and variable requirements are closely related and are therefore typically modelled together within the same artefacts. The inputs of this activity includes stakeholders‘ request, which records useful information collected from different sources; SRS Guidelines and the Vision Document which is built in Elicitation phase. The output is Common Requirement Document.     Mandatory Role: Domain Requirement Engineer Optional Role: Input: Output: Stakeholders Vision Document Common Requirement Document Analyze Variability: This activity is to identify which requirements differ among the applications, and to determine the differences precisely. A set of variation points and variants need to be identified and their dependencies need to be determined. The types of the variability dependencies between a variation point and its variants determine the permissible combinations of variants for each product line application. For some variants the 103 appropriate variability dependency may be clear from the available requirements sources. If such information is not available directly, the requirements engineer has to involve the relevant stakeholders to identify the proper variability dependencies. Similar with analyzing commonality, the inputs of this activity includes stakeholders‘ request, SRS Guidelines and the Vision Document. The output is Variable Requirement Document.     Mandatory Role: Domain Requirement Engineer Optional Role: Input: Output: Stakeholders Vision Document Variable Requirement Document Model Variability: This activity is concerned with modelling variation points, variants, and their relationships. Variability can be defined either as an integral part of development artefacts or in a separate variability model. To choose an appropriate modelling technique is significant important because three key advantages discussed by Klaus Pohl [His book, p.73]. Using this choosing model, domain requirement engineer can develop variable requirements and then document them in detail.     Mandatory Role: Domain Requirement Engineer Optional Role: Input: Output: Stakeholders Variable Requirement Document Variable Model Techniques in Specification: Like techniques in elicitation, some existing approaches can be applied in product line analysis phase. The application requirements matrix gives an approximation of the commonality and variability for a given set of software product line application requirements. A more sophisticated analysis can be obtained by applying the priority based analysis scheme. A more general approach is the use of checklists. Several modelling techniques are also available. Stakeholder view modelling can be used to support the prioritized modelling of the significant stakeholder requirements for the product line. Use case modelling can be used with variation points to capture and describe commonality and variability within product line requirements. Change case modelling can be used to identify and capture anticipated changes in a system explicitly and ultimately to incorporate those changes explicitly in the design to enhance its long-term robustness. In this template, this discipline is based on FORM (Feature-Oriented Reuse Method). Thus, each user 104 requirement is an identifiable functional abstraction, or feature. The purpose of feature modeling is to analyze commonalities and differences among a family of products in terms of application features, and then to organize the analysis results into a feature model, which is used to develop domain components. The features are classified according to the types of information they represent, which fall largely into four categories – application capabilities, operating environments, domain technologies, and implementation techniques. Likewise, in each category the features are organized by a graphical AND/OR hierarchy diagram, i.e. the feature graph or feature diagram, which captures the logical structural relationships between requirements. Also, a feature can be mandatory, optional or alternative according to its existence among applications in a domain. Mandatory features are ones that must exist among applications in a domain, while optional features may not be necessary in some applications of a given domain. Alternative features indicate that no more than one feature can be selected for an application. This classification is also applicable to sub-features, so the restriction is only related to applications with the upper feature. 6.3.1.3 Analysis Phase Requirement analysis is defined as the process to ensure that the software requirement being developed is unambiguously; that inconsistencies, omissions, and errors have been detected and corrected; and that the work products conform to the standards established for the process, the project, and the product. The input of requirement analysis is any requirement model which informally or formally documents the user needs, organizational standards, and organizational knowledge. The output is requirement analysis report and the revised requirement document. Domain engineer Specification, Requirement Model Review the Requirement Requirement Review Report Domain engineer Requirement Revision Document Domain engineer Specification, Requirement Model Requirement Revision Document Provide Formal Proof Specification, Requirement Model, Review Report Revise the Document Figure 28. Activity Diagram for Domain Requirement Analysis Phase Review the Requirement: 105 A software review is an evaluation of a software element to ascertain discrepancies from planned results and to recommend improvements. Three kinds of reviews can be used for software verification, technical review, walkthrough and inspection. The three kinds of reviews are all `formal reviews' in the sense that all have specific objectives and procedures. All kinds of review seek to identify defects and discrepancies of the software against specifications, plans and standards. The primary requirements analysis mechanism is the formal technical review. The review team that analyze requirements includes domain requirement engineers, customers, users, and other stakeholders who examine the specification looking for errors in content or interpretation, areas where clarification may be required, missing information, inconsistencies, conflicting requirements or unrealistic requirements. A structured walkthrough is an organized procedure for a group of peers to review and discuss the requirement specification to detect faults, violations of development standards, and other problems. The term ―walkthrough‖ means that the activity of the product author (requirement engineer) explaining step by step the working of his/her product to other requirement engineers, managers or related stakeholders. However, the basic purpose of a walkthrough is error detection, not error correction. Similar to walkthrough, inspection is a formal evaluation technique in which software products are examined in detail by a group of peers to detect faults, violations of development standards, and other problems. It was introduced in the 1970s by IBM, which pioneered their early adoption and later evolution. Inspections provide value in improving software reliability, availability, and maintainability     Mandatory Role: Domain Requirement Engineer Optional Role: Input: Output: Stakeholders Requirement Specification, Requirement Model Requirement Review Report Revise the Document: When the review report is ready, individual comments and problems are discussed and a set of actions to address the problems is agreed. Domain requirement engineer checks that the agreed actions have been carried out. Finally, the requirements document is revised to reflect the agreed actions. At this stage, it may be accepted or it may be re-reviewed     Mandatory Role: Domain Requirement Engineer Optional Role: Input: Stakeholders Requirement Specification, Requirement Model, Requirement Review Report Output: Requirement Revision Document 106 Provide Formal Proof: Quality Function Deployment (QFD) is another useful technique for requirement analysis. QFD allows the ―Voice of the Customer‖ to be captured, and then the proposed requirements of the system to be validated based on whether or not they reflect these expressed customer needs [Schubert 89]. QFD helps to identify user requirements that have not been addressed by the developer, as well as developer-proposed features that do not support any requirements. In addition to highlighting such omissions, QFD also documents requirements that are highly rated by the user and receive little attention by the developer-proposed features.     Mandatory Role: Domain Requirement Engineer Optional Role: Input: Output: Stakeholders Requirement Specification, Requirement Model Requirement Revision Document 6.3.1.4 Negotiation Phase Domain requirements negotiation is one of the first RE processes that happen early during software product line‘s lifetime. It has great impact on product line family‘s quality and hence largely influences customer satisfaction. The domain RE negotiation phase in this template can be carried out when the product line organization is developing or revising its domain requirement artifacts either at the beginning of or during the product line lifetime. To ensure the quality of domain requirement negotiation by specifying the negotiation phase, we break it down into three sub-processes, namely Grounding Session, Discussion Session and Negotiation Session, which are explained in the following. Domain engineer Specification, Requirement Model Grounding Session Requirement Revision Document Domain engineer Requirement Revision Document Discussion Session Requirement Revision Document Domain engineer Requirement Revision Document Requirement Revision Document Negotiation Session Figure 29. Activity Diagram for Domain Requirement Negotiation Phase 107 Grounding Session The idea behind grounding session is to let product line stokeholds, including both customers and software contractors to set up a common knowledge ground about the identified requirements that they would like to negotiate on. This session enables stakeholders to gain a better understanding of the problems, which latterly facilitates the negotiation activities and also makes the negotiation process efficient by minimizing the efforts spent on building the common knowledge ground early in the negotiation session when both parties would have different comprehensions on the same problems. The grounding session may take place any time and any where during a product line project. Asynchronous communication techniques such as electric mails, paper documents or groupware systems are suggested for this session to facilitate information exchanges between both parties. When each of parties feels that they understand the issues after several rounds of asynchronous information exchanges, they will either decide that they can resolve the problem together in an agreed and consistent manner or they become known of the fact that thy have mutually incompatible views and/or solutions. If the parties reach an agreement on how to resolve the problems, then this session as well as the domain RE negotiation phases ends. Otherwise if they are not willing to compromise, then they go on to the next session. The inputs of this session are domain requirements documents with focuses on identified requirements problems or issues, and they can be either paper-based or electrical. The outputs of this session are either the finalized domain requirements revision documents or the partially revised domain requirements documents if any minor agreements have been made during this session.     Mandatory Role: Domain Requirement Engineer Optional Role: Input: Output: Stakeholders Requirement Specification, Requirement Model Requirement Revision Document Discussion Session In discussion session, the opposing parties interact with each other in a synchronous manner so that they can better understand each other‘s needs and views, which enhance the possibility of them reaching an agreement. If both sides reach an agreement, then this session as well as the domain RE negotiation phases ends. If not, they will go on to the next session. The synchronous communication techniques of face-to-face meetings, video conferencing and groupware supported real time communications are suggested in this session. Business negotiation techniques such as concession tactics analysis and constraint proposal method are also suggested based on each party‘s own preference. 108 The inputs to this session are the outputs of the grounding session. And the outputs of this session are either the finalized domain requirements revision documents or the partially revised domain requirements documents if any minor agreements have been made during this session.     Mandatory Role: Domain Requirement Engineer Optional Role: Input: Output: Stakeholders Requirement Specification, Requirement Model Requirement Revision Document Negotiation Session In the negotiation session, it comes down to employing specialized requirement negotiation-related techniques to resolve the conflicts, as neither of opposing parties is willing to compromise during the previous two sessions. Semi-formal or formal requirement negotiation-related techniques such as Theory-W based WinWin approach, Quality Function Deployment and other requirement prioritization techniques like requirement prioritization framework and analytic hierarchy process are suggested for this session. Not all of the above techniques can be directly applied to this session, and it usually needs tailoring those techniques to make them applicable to this session. For instance, the WinWin approach is a spiral negotiation process that evolves with the spiral software development process. But since in domain requirements negotiation process the focus is on the quality of the domain requirement artifacts, we need to tailor the WinWin approach by making the negation practice independent from the actual software development phases. The WinWin approach in this template is tailored to be an iterative and spiral requirement negotiation process until agreements are reached. The inputs to this session are the outputs generated from the last session.The outputs of this session are the finalized domain requirements revision documents.     Mandatory Role: Domain Requirement Engineer Optional Role: Input: Output: Stakeholders Requirement Specification, Requirement Model Requirement Revision Document 6.3.1.5 Validation Phase Requirement validation is defined as the process to ensure that the software being developed (or changed) will satisfy its stakeholders, more specific, it checks the software requirements specification against stakeholders‘ goals and requirements. 109 Requirements validation in product line development is peculiar since it occurs in stages and because it has a broader pool of because it has a broader pool of reviewers. As requirements are elicited and modelled, maintaining agreement with all stakeholders can be a problem, especially where stakeholders have divergent goals. Recall that validation is the process of establishing that the requirements and models elicited provide an accurate account of stakeholder requirements. Explicitly describing the requirements is a necessary precondition not only for validating requirements, but also for resolving conflicts between stakeholders. The input of requirement validation is any requirement model which informally or formally documents the user needs, organizational standards, and organizational knowledge. The analysts, customers of the intended system and users in the problem domain interact to validate the requirements for completeness and consistency, conformance to standards, requirements conflicts, technical errors and ambiguous requirements [Kontaya and Sommerville]. In a scientific sense, validation is characterized by two principal types of activities: Preparing the settings for an experiment, and Performing the experiment and analysing its results. Validation delivers a requirements model which is consistent and in accordance with the users‘ expectations. Domain engineer Specification, Requirement Model Review the Requirement Requirement Review Report Domain engineer Specification, Requirement Model Domain engineer Prototyping Prototype Specification, Requirement Model, Review Report Test the Requirements Test Case Figure 30. Activity Diagram for Domain Requirement Validation Phase Review the Requirements Requirements reviews (or inspections) involve stakeholders reviewing the requirements specification or parts thereof in order to ensure it is conforming to their actual needs [Rothman 2000]. The degree of formality ranges from ad hoc meetings where developer and customer examine the specification over checklist-driven reviews to inspections based on specific reading and reviewing techniques like perspective-based reading [Schull 2000]. The latter is more a verification technique and is performed by 110 the developers rather than the customer.     Mandatory Role: Domain Requirement Engineer Optional Role: Input: Output: Stakeholders Requirement Specification, Requirement Model Requirement Review Report Prototyping There are two types of prototyping, evolutionary prototyping and exploratory Prototyping. Evolutionary prototyping is actually a lifecycle model that is also a powerful technique to ensure that the system meets the customer‘s needs, because it is possible to evaluate something tangible instead of an abstract system specification. In evolutionary prototyping, the system is developed throughout several iterations, within which parts of the system are added and modified if needed. Thus, the prototype becomes the final system, which means a flexible architecture is needed in order to accommodate the changes that arise throughout the development [Kotonya 1998]. Unlike evolutionary prototyping, the prototype in exploratory prototyping is discarded after its evaluation. It is therefore more suitable for feasibility studies and does not need to be designed with extensibility or most other quality attributes in mind [Kotonya 1998]. Exploratory prototyping may also be used to elicit initial requirements by presenting the potential users a rough sketch of the future system. There are prototypes at varying levels of sophistication, like paper prototypes, ―Wizard of Oz‖ prototypes or software prototypes [Sommerville 1996].     Mandatory Role: Domain Requirement Engineer Optional Role: Input: Output: Stakeholders Requirement Specification, Requirement Model Prototype Test the Requirements Requirements testing is the activity of defining test cases for the requirements as soon as they are written. The purpose of test cases is to ensure that the implementation meets the requirements. Writing test cases during the requirements phase ensures that the analyst has not already forgotten about the purpose of a requirement by the time the project reaches the testing stage [Rosenberg 1998].    Mandatory Role: Domain Requirement Engineer Optional Role: Input: Stakeholders Requirement Specification, Requirement Model 111  Output: Requirement Test Cases 6.3.2 Application Requirement Engineering During the software application requirement engineering, an individual application that is a member of the software product line is developed. Instead of starting from scratch, as is done with single systems, the application developers make full use of all the artifacts developed during the software product line engineering life cycle. Application requirements engineering has the same intention as requirements engineering for single systems. In addition, it has to satisfy the goal of product line engineering, which is to develop applications by reusing predefined artifacts. 6.3.2.1 Elicitation Phase The goal of application requirement elicitation phase is to make the particular stakeholder aware of the capabilities of the product line and to find domain requirements artefacts that satisfy this application. Application requirements can be developed by reusing the requirements artefacts that were defined in domain requirement engineering. If the application stakeholders requirements can only partially fulfilled by the product line, either the existing product line requirements must be adapted, or new application requirements artefacts have to be developed to satisfy the application stakeholders needs. The following figure presents the activities in application requirement specification phase. Application engineer Collect Application Information Application engineer Stakeholder Request Market Analysis, Business Model Develop Scope and Boundary Vision Figure 31. Activity Diagram for Application Requirement Elicitation Phase Collect Application Information Like single traditional product development, application requirement development also needs to collect information from particular stakeholders. The input of this activity is the domain knowledge. The 112 stakeholders need to be very familiar with what they want to develop. The output is the stakeholders‘ request. It can be any kind of format, such as meeting minutes, email or informal document. It may also contain references to any type of external sources to which the system must comply. Define Scope: The scope definition is used during application development to gauge whether an application would be an appropriate member of the product line. Whether or not to develop the application using the product line core assets is decided in the activity. Stakeholders request is the input of defining the application scope. The output is application Vision document. The Vision document provides a complete vision for the software system under development and supports the contract between the funding authority and the development organization. Techniques in Elicitation: Interviews are also used in application requirement elicitation. 6.3.2.2 Specification Phase During specification the stakeholders, requirements, constraints, and existing standards that have influence on the intended system have to be identified and documented to establish a common understanding of the problem domain and the intended application. In forward engineering, the core asserts have already been developed, therefore, the application requirements engineers have to be aware of the existing product line capabilities, and the valid combinations of variants for an application, i.e., which requirements can be selected and combined in one application. During this phase, engineers have to map elicited application stakeholder requirements to existing product line requirements to ensure a high degree of reuse, and also to develop a consistent and traceable application requirements specification of selected product line requirements and application specific requirements. 113 Application engineer Domain Requirement Reuse Domain Requirement Reused Domain Requirement Application engineer Domain Requirement Analyze Requirements Deltas Requirement Delta Application engineer Reused Domain Requirement, Requirement Delta Document Application Requirement Application Requirement Specification Figure 32. Activity Diagram for Application Requirement Specification Phase Reuse Domain Requirement: The goal of this activity is to make the stakeholder aware of the capabilities of the product line and reuse the domain requirements. By considering the commonality and variability of the product line in application requirements engineering, the level of domain artefact reuse can be increased. Analyze Requirements Deltas: The main goal of delta analysis is to support the decision on whether the deltas should be realised for the application or not. After reuse the domain requirements, two types of delta requirements may exist: part of the existing variability has to be modified or an invariant part must be turned into a variable part. In case the stakeholder requires, new functionality or quality with respect to given variation point, a new variant must be included in the application variability model. In case the stakeholder wishes to change the functionality or quality of an existing variant, a new variant representing the changed functionality or qualify is defined. Thus, the two variants are selectable. The stakeholder may also demand modifications of the variability or constraint dependencies. Document Application Requirement: The results of the above two activities have to be documented in the application requirements specification. The application requirements specification should include: reused requirements, application variability model, application variability model deltas and traces to selected variants. 114 6.3.2.3 Analysis Phase Requirements analysis can be conducted in a similar way as they are conducted in single product development. All the analysis techniques used for a single product can also be used for product lines. Application engineer Specification, Requirement Model Review the Requirement Requirement Review Report Application engineer Provide Formal Proof Requirement Revision Document Application engineer Requirement Revision Document Specification, Requirement Model Specification, Requirement Model, Review Report Revise the Document Figure 33. Activity Diagram for Application Requirement Analysis Phase In PLE template, it use frequent review meetings and acceptance tests for requirements analysis. Review meetings show that the project is in target and schedule increasing customer trust and confidence in the team or highlighting problems very early. Agile approaches use different kinds of review meetings to present the new software. Customers can use the software, experience how the system works and determine which functionality has already been implemented. If they have questions, these can be immediately answered by the developers. Customers can also discuss the implementation with developers and ask for changes in design. During the review meetings, they learn about strength and weakness of the design and the technology and in which areas there are advantages and limitations. Customers can also run acceptance test to validate if the system reacts in the expected way and, if not, clarify the issue. The questions and change requests influence future development. Depending on the method and project circumstances, the software is put into production after each review. This fast deployment changes the economics of the software project by providing a faster return on investment. 6.3.2.4 Negotiation Phase The application RE negotiation phase deals with application-level requirement negotiation with customers. Since application-level requirement changes have limited impact, usually on the products currently in development only, agility can be introduce into this phase by eliminating the needs to carry out a full-scale well defined process. To achieve this goal, we borrow agile principles on welcoming requirement changes, reduced documenting activities and frequent delivery by customizing requirement negotiation process in application engineering by making the process as simple as possible. As a result, in this template the 115 application RE negotiation phase consists of only one session, namely the negotiation session, which is explained in the following. Negotiation Session The application RE negotiation session addresses the problem of application requirement negotiation as well as the needs to gain agility. And this session requires highly dedicated participation of on-site customer representatives. That is because the application requirement negotiation process is expected to happen frequently during product development, in contrast the domain requirement negotiation process happens with specific time constraints. Consequently the voice of customer shall always be present when the requirements negotiation takes place. As a result, the customer representatives work with developers on a daily basis to address potential requirement changes in order to make frequent product deliveries in both a timely and stakeholder-satisfied manner. A number of agility oriented negotiation-related techniques are suggested for this session; they are Binary Search Tree Methods, Customer Centric Ad-hoc Discussion, Voting Scheme, Third Party Arbitration, etc. There are no documents input to this session. Whenever a customer would like make a requirement change either the customer or the representative approaches the developers to initiate this session. However a semi-formal or formal report about the application requirements changes made during product development shall be developed when this product is finally delivered as the output of this phase. That is because the evolution of product line requirements artifacts may need to integrate the evolution of application-level requirements. Application engineer Requirement Revision Document Negotiation Session Figure 34. Activity Diagram for Application Requirement Negotiation Phase 6.3.2.5 Validation Phase Similar to requirement analysis, requirements verification can be conducted in a similar way as they are conducted in single product development. All the verification techniques used for a single product can also be used for product lines. 116 Application engineer Specification, Requirement Model Review the Requirement Requirement Review Report Application engineer Specification, Requirement Model Application engineer Specification, Requirement Model, Review Report Prototyping Prototype Test the Requirements Test Case Figure 35. Activity Diagram for Application Requirement Validation Phase Prototyping is one of the application requirement validation techniques. Prototyping of core functionality can be used to develop early executable versions of the requirements model. However, prototyping is not the silver bullet [Dubois 88, p. 394]: ―it may be costly to develop a prototype, which is not the ultimate solution anyway; users are assumed to accept the prototype when they actually only accept its behaviours in the cases they have tried.‖ Quality Function Deployment (QFD) is another useful technique for validation. QFD allows the ―Voice of the Customer‖ to be captured, and then the proposed requirements of the system to be validated based on whether or not they reflect these expressed customer needs [Schubert 89]. QFD helps to identify user requirements that have not been addressed by the developer, as well as developer-proposed features that do not support any requirements. In addition to highlighting such omissions, QFD also documents requirements that are highly rated by the user and receive little attention by the developer-proposed features. 6.4 Agile Product Line RE Process Template Requirement Engineering in Product Line development contains two major activities: Domain Requirement Engineering and Application Requirement Engineering. Both of them follow the six-phase process, which are elicitation, specification, analysis, negotiation, validation and management. 6.4.1 Domain Requirement Engineering The purpose of domain requirement engineering is, first, to define the domain basic goal, its scope and boundaries; second, to develop the common and variable domain requirements and their precise documentation. In the APLE template, these two major tasks are highly involved. Scoping is divided into many small pieces, and some of the pieces are developed first, and then followed by the related features. 117 In the first stages of domain engineering, the product line scope is defined and the products to be included in the product line are identified or defined if they do not already exist. A major difference between software product lines and traditional single product is that the product line needs a very clear vision of which a set of products will be developed. The vision describes what functionality should be supported in a general manner for the whole product line and what functionality should be regarded as specific to a single system. This template is the most agile one, we just assume the following:   Stakeholders are highly involved in the requirement development. Day-to-day‘s operation is recommended. In APLE template, the requirement engineering process consists of the day-to-day activities in connection with the customer‘s use of the products based on the product line. Most suppliers presumably provide two or more releases per year, which surpasses the update frequency of most customers; there will be several versions of the platform in use at any one time. In addition, there are normally many variants based on the product line in use, all of which may be considered advanced applications. In sum, this means that there is great variance in the support requests to the supplier, which usually is handled by a dedicated support department or team. Depending on the situation, support may involve guidance in use of the product of customers‘ use, or issues related to maintenance. Some requests also address errors and flaws in the software, even ideas for future development. Such requests should be recorded used as important input to the strategic process that is aimed at upcoming 6.4.1.1 Elicitation Phase Requirement elicitation focuses on the scope, explicitly capturing the anticipated variation by the application of domain analysis techniques, the incorporation of existing domain analysis models, and the incorporation of use cases that capture the variations that are expected to occur over the lifetime of the product line. Since this is the beginning of projects, all the information collected from stakeholders should be complete and correct. Therefore, the high level activity of the elicitation phase is mostly like the Product Line Requirement Engineering Process Template. The difference will occur in selecting more agile techniques. The following figure presents the activities in domain requirement elicitation phase. 118 Domain engineer Collect Domain Information Domain engineer Stakeholder Request Stakeholder Request Understand Relevant Domains Domain Glossary Domain engineer Domain engineer Stakeholder Request, Domain Glossary Analyze Market Market Analysis Stakeholder Request, Domain Glossary Build Business Case Business Model Domain engineer Market Analysis, Business Model Develop Scope and Boundary Scope and Boundary Figure 36. Activity Diagram for Application Requirement Elicitation Phase Collect Domain Information In the scope of a product line, the requirements of every product should be determined, even the requirements of the products that still have not been developed, but are inside the product line scope. Therefore, the very beginning of elicit domain requirement is to gather as much as useful information. The output is the initial stakeholders‘ request. This artifact contains any type of requests all the stakeholders (customer, user, marketing person, and so on) might have on the system to be developed. It may also contain references to any type of external sources to which the product line must comply. These information may come from stakeholder interviews, workshops, legacy systems, business models, etc. Understand Relevant Domains This activity addresses collecting and eliciting information from different stakeholders in the product line in order to understand what their needs really are. It is about systematically capturing and utilizing knowledge of systems similar to the ones that developers are about to build. This knowledge provides an informed world view from which can help product line managers to make specific decisions. The collected Stakeholder Requests can be regarded as a "wish list" [Rzepka 89] that will be used as primary input to defining the high-level features of the product line projects. The ―wish list‖ can be described in Vision document, which drive the specification of the Software Requirements. Analyze Market A market analysis is an important ingredient in a decision to shift business strategy from single system engineering to product line engineering. The market analysis informs the business case, and together these two documents form the basis of the decision package used by management to justify the shift in strategy. 119 Once a product line engineering organization has been established, a market analysis is conducted on a continuous basis to guide the introduction of new products into the product line, to steer the evolution of the product line as a whole, and to oversee the spin-off related product lines. Build Business Case This activity is to justify the effort to adopt the product line approach for building systems, and then to decide whether or not to include a particular product as a member of a product line. Develop Scope and Boundary This activity is to bound a set of systems by defining those behaviours or aspects that are ―in‖ and those behaviours or aspects that are ―out‖. The Rational Unified Process includes an inception phase to establish ―the project‘s software scope and boundary conditions, including an operational concept, acceptance criteria, and descriptions of what is and is not intended to be in the product‖. Techniques in Elicitation: Lots of techniques are available, varying from agile ones, such as on-site interactive sessions (XP), white boards (Lean), model storming sessions (AMDD), focus group (Scrum), to product line ones, such as PuLSE-ECO (for scoping) and requirements workshops. Interviewing stakeholders in the specific companies is one of the popular and reasonable techniques, which involves structured or unstructured discussion between requirements engineers and customers. Interviews alone are not sufficient for requirements elicitation in product lines. There are several stakeholders involved and also the organization has to satisfy its business goals. However, interview techniques can support other requirements elicitation techniques. After analyzing domain concepts with domain experts and market experts, potential customers can be interviewed to capture information about a particular topic. Structured Interviews can be conducted if the requirements engineer already has a fairly good knowledge about a concept and wants to get clear answers from the customers to specific questions. Unstructured Interviews can be used if the requirements engineer wants to have an open-ended discussion with the users. Also interviews can be used to communicate common and variable requirements that are already gathered by the users so that any negotiations can take place. Some major limitations with eliciting requirements primarily or exclusively through interviews result from the tremendous responsibility placed on the requirements analyst, especially in product line development. Interview information is collected from different parties, and the information may affect each other. Therefore, the analyst must integrate these different interpretations, goals, objectives, communication styles, and use of terminology into one core asset. Other techniques can be used in conjunction with interviews to help structure these information and facilitate integration. Rather than just structuring interviews, another technique focuses on ensuring that information is gathered from all of the affected parties, and that the resulting requirements meet the approval and understanding of 120 all of these parties, rather than just being the work of the requirements analyst. These team approaches to requirements elicitation make sure that issues of scope are properly addressed by getting the appropriate people involved at the very beginning of requirements elicitation. Likewise, they explicitly recognize that there are issues of understanding dependent upon the variety of disciplines and number of people affected by the development of a proposed system. The team approach to requirements elicitation is characterized by JAD, an acronym for Joint Application Design. JAD focuses on improving the group process and getting the right people involved at the start. This technique has been used successfully by IBM since the late 1970s, and its advantages include the promotion of cooperation, understanding, and teamwork among users, developers, and customers. Developers help users formulate problems and explore solutions, while users share ownership of the requirements and associated documents. Through the use of structured meeting procedures, facilitation protocols, and visual aids, JAD enhances idea generation and evaluation, communication, and consensus generation. 6.4.1.2 Specification Phase Elicitation is concerned with gathering information from various stakeholders in order to derive the requirements for a system. This collected information needs to be represented in some way, and ideally the gathered statements are expressed ―in a notation which elucidates their implications, prompts further questions, correlates different aspects, and facilitates detailed analysis‖ [Southwell 87, p. 195]. Documenting requirements for software construction is an activity which results in what has been traditionally termed as requirement specification. According to Razpka and Ohno, a requirements specification represents both a model of what is needed and a statement of the problem under consideration. The explicit documentation of the proper common and variable requirements is essential for enabling the planned reuse of requirements in application engineering. The required variability has to document in some appropriate model. The following figure presents the activities in domain requirement specification phase. 121 Domain engineer Small Iteration Stakeholder Request, SRS Guidelines, Vision Document Small Iteration Domain engineer Stakeholder Request, SRS Guidelines, Vision Document Analyze Variability Variable Requirement Analyze Commonality Common Requirement Domain engineer Small Iteration Variable Requirement Model Variability Variability Model Figure 37. Activity Diagram for Application Requirement Specification Phase Analyze Commonality: This activity is to identify which requirements are common to all applications of the software product line. Before any requirements can be defined as a commonality of the product line, a commonality analysis has to be performed in order to determine which requirements are actually common to all application. Then these common requirements need to be documented in detail in a representation format. Identifying and documenting requirements are performed iteratively in the course of detailing and revising. Moreover, common and variable requirements are closely related and are therefore typically modelled together within the same artefacts. Analyze Variability: This activity is to identify which requirements differ among the applications, and to determine the differences precisely. A set of variation points and variants need to be identified and their dependencies need to be determined. The types of the variability dependencies between a variation point and its variants determine the permissible combinations of variants for each product line application. For some variants the appropriate variability dependency may be clear from the available requirements sources. If such information is not available directly, the requirements engineer has to involve the relevant stakeholders to identify the proper variability dependencies. Model Variability: This activity is concerned with modelling variation points, variants, and their relationships. Variability can be defined either as an integral part of development artefacts or in a separate variability model. To choose an appropriate modelling technique is significant important because three key advantages discussed by Klaus Pohl [His book, p.73]. Using this choosing model, domain requirement engineer can develop variable requirements and then document them in detail. Techniques in Specification: Like techniques in elicitation, some existing approaches can be applied in product line analysis phase. The 122 application requirements matrix gives an approximation of the commonality and variability for a given set of software product line application requirements. A more sophisticated analysis can be obtained by applying the priority based analysis scheme. A more general approach is the use of checklists. Several modelling techniques are also available. Stakeholder view modelling can be used to support the prioritized modelling of the significant stakeholder requirements for the product line. Use case modelling can be used with variation points to capture and describe commonality and variability within product line requirements. Change case modelling can be used to identify and capture anticipated changes in a system explicitly and ultimately to incorporate those changes explicitly in the design to enhance its long-term robustness. In this template, this discipline is based on FORM (Feature-Oriented Reuse Method). Thus, each user requirement is an identifiable functional abstraction, or feature. The purpose of feature modelling is to analyze commonalities and differences among a family of products in terms of application features, and then to organize the analysis results into a feature model, which is used to develop domain components. The features are classified according to the types of information they represent, which fall largely into four categories – application capabilities, operating environments, domain technologies, and implementation techniques. Likewise, in each category the features are organized by a graphical AND/OR hierarchy diagram, i.e. the feature graph or feature diagram, which captures the logical structural relationships between requirements. Also, a feature can be mandatory, optional or alternative according to its existence among applications in a domain. Mandatory features are ones that must exist among applications in a domain, while optional features may not be necessary in some applications of a given domain. Alternative features indicate that no more than one feature can be selected for an application. This classification is also applicable to sub-features, so the restriction is only related to applications with the upper feature. 6.4.1.3 Analysis Phase Requirement analysis is defined as the process to ensure that the software requirement being developed is complete, consistent and unambiguous. The input of requirement validation is any requirement model which informally or formally documents the user needs, organizational standards, and organizational knowledge. In APLE template, this phase are always involved with negotiation and validation phase. Customers rely on the software to help them to implement vital business functions in their own organizations. Thus, it is of great importance that customers are able to sustain a good level of satisfaction with the software in its day-to-day use. 123 Domain engineer Specification, Requirement Model Review the Requirement Requirement Review Report Domain engineer Specification, Requirement Model, Review Report Revise the Document Requirement Revision Document Figure 38. Activity Diagram for Application Requirement Analysis Phase Review the Requirement: A software review is an evaluation of a software element to ascertain discrepancies from planned results and to recommend improvements. Three kinds of reviews can be used for software verification, technical review, walkthrough and inspection. In APLE template, customers are highly involved in reviewing requirements. This activity are always parallel with those activities in negotiation and validation phases. Revise the Document: When the review report is ready, individual comments and problems are discussed and a set of actions to address the problems is agreed. Domain requirement engineer checks that the agreed actions have been carried out. Finally, the requirements document is revised to reflect the agreed actions. At this stage, it may be accepted or it may be re-reviewed Techniques in Specification: In APLE template, it use frequent review meetings and acceptance tests for requirements validation. Review meetings show that the project is in target and schedule increasing customer trust and confidence in the team or highlighting problems very early. Agile approaches use different kinds of review meetings to present the new software. Customers can use the software, experience how the system works and determine which functionality has already been implemented. If they have questions, these can be immediately answered by the developers. Customers can also discuss the implementation with developers and ask for changes in design. During the review meetings, they learn about strength and weakness of the design and the technology and in which areas there are advantages and limitations. Customers can also run acceptance test to validate if the system reacts in the expected way and, if not, clarify the issue. The questions and change requests influence future development. Depending on the method and project circumstances, the software is put into production after each review. This fast deployment changes the economics of the software project by providing a faster return on investment. 124 6.4.1.4 Negotiation Phase Domain requirements negotiation is one of the first RE processes that happen early during software product line‘s lifetime. It has great impact on product line family‘s quality and hence largely influences customer satisfaction. The domain RE negotiation phase in this template can be carried out when the product line organization is developing or revising its domain requirement artifacts either at the beginning of or during the product line lifetime. To ensure the quality of domain requirement negotiation by specifying the negotiation phase, we break it down into three sub-processes, namely Grounding Session, Discussion Session and Negotiation Session, which are explained in the following. Domain engineer Specification, Requirement Model Grounding Session Requirement Revision Document Domain engineer Requirement Revision Document Discussion Session Requirement Revision Document Domain engineer Requirement Revision Document Requirement Revision Document Negotiation Session Figure 39. Activity Diagram for Application Requirement Negotiation Phase Grounding Session The idea behind grounding session is to let product line stokeholds, including both customers and software contractors to set up a common knowledge ground about the identified requirements that they would like to negotiate on. This session enables stakeholders to gain a better understanding of the problems, which latterly facilitates the negotiation activities and also makes the negotiation process efficient by minimizing the efforts spent on building the common knowledge ground early in the negotiation session when both parties would have different comprehensions on the same problems. The grounding session may take place any time and any where during a product line project. Asynchronous communication techniques such as electric mails, paper documents or groupware systems are suggested for this session to facilitate information exchanges between both parties. When each of parties feels that they understand the issues after several rounds of asynchronous information exchanges, they will either decide that they can resolve the problem together in an agreed and consistent manner or they become known of the fact that thy have mutually incompatible views and/or solutions. If the parties reach an agreement on 125 how to resolve the problems, then this session as well as the domain RE negotiation phase ends. Otherwise if they are not willing to compromise, then they go on to the next session. The inputs of this session are domain requirements documents with focuses on identified requirements problems or issues, and they can be either paper-based or electrical. The outputs of this session are either the finalized domain requirements revision documents or the partially revised domain requirements documents if any minor agreements have been made during this session. Discussion Session In discussion session, the opposing parties interact with each other in a synchronous manner so that they can better understand each other‘s needs and views, which enhances the possibility of them reaching an agreement. If both sides reach an agreement, then this session as well as the domain RE negotiation phase ends. If not, they will go on to the next session. The synchronous communication techniques of face-to-face meetings, video conferencing and groupware supported real time communications are suggested in this session. Business negotiation techniques such as concession tactics analysis and constraint proposal method are also suggested based on each party‘s own preference. The inputs to this session are the outputs of the grounding session. And the outputs of this session are either the finalized domain requirements revision documents or the partially revised domain requirements documents if any minor agreements have been made during this session. Negotiation Session In the negotiation session, it comes down to employing specialized requirement negotiation-related techniques to resolve the conflicts, as neither of opposing parties is willing to compromise during the previous two sessions. Semi-formal or formal requirement negotiation-related techniques such as Theory-W based WinWin approach, Quality Function Deployment and other requirement prioritization techniques like requirement prioritization framework and analytic hierarchy process are suggested for this session. Not all of the above techniques can be directly applied to this session, and it usually needs tailoring those techniques to make them applicable to this session. For instance, the WinWin approach is a spiral negotiation process that evolves with the spiral software development process. But since in domain requirements negotiation process the focus is on the quality of the domain requirement artifacts, we need to tailor the WinWin approach by making the negation practice independent from the actual software development phases. The WinWin approach in this template is tailored to be an iterative and spiral requirement negotiation process until agreements are reached. 126 The inputs to this session are the outputs generated from the last session.The outputs of this session are the finalized domain requirements revision documents. 6.4.1.5 Validation Phase Requirement validation is defined as the process to ensure that the software being developed (or changed) will satisfy its stakeholders, more specific, it checks the software requirements specification against stakeholders‘ goals and requirements. The input of requirement validation is any requirement model which informally or formally documents the user needs, organizational standards, and organizational knowledge. The analysts, customers of the intended system and users in the problem domain interact to validate the requirements for completeness and consistency, conformance to standards, requirements conflicts, technical errors and ambiguous requirements [Kontaya and Sommerville]. In a scientific sense, validation is characterized by two principal types of activities: Preparing the settings for an experiment, and Performing the experiment and analysing its results. Validation delivers a requirements model which is consistent and in accordance with the users‘ expectations. Domain engineer Specification, Requirement Model Review the Requirement Requirement Review Report Domain engineer Specification, Requirement Model Prototyping Prototype Figure 40. Activity Diagram for Application Requirement Validation Phase In APLE template, an agile approach of requirement validation is applied: Group Review. Group review is a formal meeting which a group of people read and analyze the requirements, look for problems, meet and discuss the problems and agree on actions to address these problems. First, the review team is selected and a time and place for the review meeting is chosen. Since product line has multiple stakeholders, the team can contain several customers and use video conference or several meetings are established for different stakeholders. Second, the requirements document is distributed to the review team members. Individual reviewers read the requirements to find conflicts, omissions, inconsistencies, deviations from standards and other problems and make sure the requirement is satisfy the customer intend. Then, individual comments and problems are discussed and a set of actions to address the problems is agreed. The chair of the review checks that the agreed actions have been carried out. Finally, the requirements document is revised to reflect the agreed actions. At this stage, it may be accepted or it may be re-reviewed. The whole process can be in several iterations. In each iteration, all or some of the stakeholders attend the video conference 127 and identify a set of problems and take the correspondence actions. The stakeholders should all agree on the requirement until all the problems are clear and fixed. Then a revised requirement specification is generated. 6.4.2 Application Requirement Engineering During the software application requirement engineering, an individual application that is a member of the software product line is developed. Instead of starting from scratch, as is done with single systems, the application developers make full use of all the artifacts developed during the software product line engineering life cycle. Application requirements engineering has the same intention as requirements engineering for single systems. In addition, it has to satisfy the goal of product line engineering, which is to develop applications by reusing predefined artifacts. 6.4.2.1 Elicitation Phase The goal of application requirement elicitation phase is to make the particular stakeholder aware of the capabilities of the product line and to find domain requirements artefacts that satisfy this application. Application requirements can be developed by reusing the requirements artefacts that were defined in domain requirement engineering. If the application stakeholders requirements can only partially fulfilled by the product line, either the existing product line requirements must be adapted, or new application requirements artefacts have to be developed to satisfy the application stakeholders needs. The following figure presents the activities in domain requirement specification phase. Application engineer Collect Application Information Application engineer Stakeholder Request Market Analysis, Business Model Develop Scope and Boundary Vision Figure 41. Activity Diagram for Application Requirement Elicitation Phase Collect Application Information Like single traditional product development, application requirement development also needs to collect information from particular stakeholders. The input of this activity is the domain knowledge. The stakeholders need to be very familiar with what they want to develop. The output is the stakeholders‘ request. It can be any kind of format, such as meeting minutes, email or informal document. It may also contain references to any type of external sources to which the system must comply. 128 Define Scope: The scope definition is used during application development to gauge whether a application would be a appropriate member of the product line. Whether or not to develop the application using the product line core assets is decided in the activity. Stakeholders request is the input of defining the application scope. The output is application Vision document. The Vision document provides a complete vision for the software system under development and supports the contract between the funding authority and the development organization. Techniques in Elicitation: Interviews are also used in application requirement elicitation. 6.4.2.2 Specification Phase During specification the stakeholders, requirements, constraints, and existing standards that have influence on the intended system have to be identified and documented to establish a common understanding of the problem domain and the intended application. In forward engineering, the core asserts have already been developed, therefore, the application requirements engineers have to be aware of the existing product line capabilities, and the valid combinations of variants for an application, i.e., which requirements can be selected and combined in one application. During this phase, engineers have to map elicited application stakeholder requirements to existing product line requirements to ensure a high degree of reuse, and also to develop a consistent and traceable application requirements specification of selected product line requirements and application specific requirements. Reuse Domain Requirement: The goal of this activity is to make the stakeholder aware of the capabilities of the product line and reuse the domain requirements. By considering the commonality and variability of the product line in application requirements engineering, the level of domain artefact reuse can be increased. Analyze Requirements Deltas: The main goal of delta analysis is to support the decision on whether the deltas should be realised for the application or not. After reuse the domain requirements, two types of delta requirements may exist: part of the existing variability has to be modified or an invariant part must be turned into a variable part. In case the stakeholder requires, new functionality or quality with respect to given variation point, a new variant must be included in the application variability model. In case the stakeholder wishes to change the functionality or quality of an existing variant, a new variant representing the changed functionality or qualify is defined. Thus, the two variants are selectable. The stakeholder may also demand modifications of the variability or constraint dependencies. Document Application Requirement: 129 The results of the above two activities have to be documented in the application requirements specification. The application requirements specification should include: reused requirements, application variability model, application variability model deltas and traces to selected variants. 6.4.2.3 Analysis Phase In APLE template, it use frequent review meetings and acceptance tests for requirements validation. Review meetings show that the project is in target and schedule increasing customer trust and confidence in the team or highlighting problems very early. Agile approaches use different kinds of review meetings to present the new software. Customers can use the software, experience how the system works and determine which functionality has already been implemented. If they have questions, these can be immediately answered by the developers. Customers can also discuss the implementation with developers and ask for changes in design. During the review meetings, they learn about strength and weakness of the design and the technology and in which areas there are advantages and limitations. Customers can also run acceptance test to validate if the system reacts in the expected way and, if not, clarify the issue. The questions and change requests influence future development. Depending on the method and project circumstances, the software is put into production after each review. This fast deployment changes the economics of the software project by providing a faster return on investment. 6.4.2.4 Negotiation Phase The application RE negotiation phase deals with application-level requirement negotiation with customers. Since application-level requirement changes have limited impact, usually on the products currently in development only, agility can be introduce into this phase by eliminating the needs to carry out a full-scale well defined process. To achieve this goal, we borrow agile principles on welcoming requirement changes, reduced documenting activities and frequent delivery by customizing requirement negotiation process in application engineering by making the process as simple as possible. As a result, in this template the application RE negotiation phase consists of only one session, namely the negotiation session, which is explained in the following. Negotiation Session The application RE negotiation session addresses the problem of application requirement negotiation as well as the needs to gain agility. And this session requires highly dedicated participation of on-site customer representatives. That is because the application requirement negotiation process is expected to happen frequently during product development, in contrast the domain requirement negotiation process happens with specific time constraints. Consequently the voice of customer shall always be present when the requirements negotiation takes place. As a result, the customer representatives work with developers on a daily basis to address potential requirement changes in order to make frequent product deliveries in both a timely and stakeholder-satisfied manner. A number of agility oriented negotiation-related techniques are 130 suggested for this session; they are Binary Search Tree Methods, Customer Centric Ad-hoc Discussion, Voting Scheme, Third Party Arbitration, etc. There are no documents input to his session. Whenever a customer would like make a requirement change either the customer or the representative approaches the developers to initiate this session. However a semi-formal or formal report about the application requirements changes made during product development shall be developed when this product is finally delivered as the output of this phase. That is because the evolution of product line requirements artifacts may need to integrate the evolution of application-level requirements. 6.4.2.5 Validation Phase Prototyping is one of the application requirement validation techniques. Prototyping of core functionality can be used to develop early executable versions of the requirements model. However, prototyping is not the silver bullet [Dubois 88, p. 394]: ―it may be costly to develop a prototype, which is not the ultimate solution anyway; users are assumed to accept the prototype when they actually only accept its behaviour in the cases they have tried.‖ Quality Function Deployment (QFD) is another useful technique for validation. QFD allows the ―Voice of the Customer‖ to be captured, and then the proposed requirements of the system to be validated based on whether or not they reflect these expressed customer needs [Schubert 89]. QFD helps to identify user requirements that have not been addressed by the developer, as well as developer-proposed features that do not support any requirements. In addition to highlighting such omissions, QFD also documents requirements that are highly rated by the user and receive little attention by the developer-proposed features. In APLE template, it uses prototyping. 6.5 Conclusion The proposed process development methodology is an essential component in the framework for APLE-RE Process Repository development. The overall objective of the methodology is to provide a set of guidelines to develop the most suitable process model for an agile product line project by making use of the APLE-RE Techniques. A structured, step-by-step approach is adopted in the methodology so that the requirements engineers can easily understand the development process. In addition, two of the APLE-RE Process templates are presented. 131 7 APLE-RE Techniques 7.1 Introduction APLE-RE Techniques is the foundation for APLE-RE framework. It is a collection of currently identified RE techniques and guidelines on how to use and evaluate these techniques. The RE techniques are organized according to the following five categories which are presented in Section 7.2. The six phases of the RE process model: requirements elicitation, requirement specification, requirements analysis, requirements negotiation, requirements validation techniques, and requirements management. APLE-RE Techniques is built by evaluating the relevant literature. This includes: A survey of the RE process and the software development lifecycle (which has already been discussed in Section 2.1.2) A tailored Requirement Engineering Process A survey of RE techniques Survey and analysis of agile methodologies An analysis of the continuum among traditional software development, agile methods and product line practice, especially for requirement engineering The rest of this chapter is organized as follows: The tailored of RE process are given in Section 7.2. The methodologies of techniques selection for RE process development are described in Section 7.3. The detailed introduction and analysis of selected RE techniques are presented in Section 7.4. The summary and conclusion are given in Section 7.5. 7.2 Modified RE Process Kotonya proposed a general RE process model includes the following phases [79]: Requirements elicitation. Requirements are elicited from different stakeholders. Requirements analysis and negotiation. Requirements are analyzed and the problems identified are negotiated with the stakeholders. Requirements documentation. Requirements are documented in appropriate notations. Requirements verification and validation. Requirements are verified and validated to ensure that the requirements are real needs of stakeholders and are well defined. Requirements management. Requirements management is highly related to requirements change management in this model and includes requirements traceability. However, it does not mention the detail activities of each phase. 132 7.2.1 Elicitation Phase Modified Elicitation Phase is almost the same the general one. It refers to gathering the requirements of the system from stakeholders. It is a process of ―identifying needs and bridging the disparities among the involved communities for the purpose of defining and distilling requirements to meet the constraints of these communities.‖ [144]. This process requires application domain knowledge, organizational knowledge and technical knowledge, as well as specific problem knowledge. The most common challenges during this phase are to ensure effective communication between various stakeholders and the elicitation of tacit knowledge. The output of the requirement elicitation phase is a collection of elicitation notes or an informal document which describes the elicited requirements. The requirements in this phase are still largely unprocessed, unstructured and may contain many irrelevancies, inconsistencies and omissions. Difference with Kotonya Elicitation Phase:  APLE-RE Elicitation Phase is only focus on gathering the requirements from stakeholders. 7.2.2 Specification Phase Modified Specification Phase is concerned with gathering information from various stakeholders in order to derive the requirements for a system. This collected information needs to be represented in some way, and ideally the gathered statements are expressed ―in a notation which elucidates their implications, prompts further questions, correlates different aspects, and facilitates detailed analysis‖ [145]. Specification Phase is the process of documenting the agreed requirements at an appropriate level of detail in the most suitable notation based on a well-defined document structure. The key issues in the process are to select proper notations to document requirements and at the appropriate level of detail. Additionally, the document structure and the labeling hierarchy of requirements are also important since they will directly relate to requirements traceability. The documentation process receives its input from the elicitation phase. The output of the process is a well-structured and defined specification, which, however, still needs to be verified and validated. Difference with Kotonya Specification Phase:  APLE-RE Specification Phase refers to analysis and documentation phase in Kotonya‘s book. . 7.2.3 Analysis Phase Modified requirement analysis is defined as the process to ensure that the software requirement being developed is unambiguously; that inconsistencies, omissions, and errors have been detected and corrected; 133 and that the work products conform to the standards established for the process, the project, and the product. These activities are performed internally. Requirements analysts and project managers are involved. The input of requirement analysis is any requirement model which informally or formally documents the user needs, organizational standards, and organizational knowledge. The output is requirement analysis report and the revised requirement document. Difference with Kotonya Analysis Phase:  APLE-RE Analysis Phase refers to part of Validation and Verification phase in Kotonya‘s book. It performs the internally validation activity to check whether the requirements specification is unambiguous, consistencies, and completeness. 7.2.4 Negotiation Phase Modified requirements negotiation is defined as the process to resolve the conflicts among the stakeholders. Requirements negotiation is one of the first RE processes that happen early during software development lifetime. Besides it, the process of requirement negotiation has great impact on software products‘ quality and hence on customer satisfaction as well. The inputs of this phase are requirements documents with focuses on identified requirements problems or issues, and they can be either paper-based or electrical. The outputs of this phase are either the finalized domain requirements revision documents. Difference with Kotonya Analysis Phase:  APLE-RE Negotiation Phase refers to negotiation phase in Kotonya‘s book. It defined as the process to resolve the conflicts among the stakeholders. 7.2.5 Validation Phase Requirement validation is defined as the process to ensure that the software being developed (or changed) will satisfy its stakeholders, more specific, it checks the software requirements specification against stakeholders‘ goals and requirements. These activities are performed internally. Requirements analysts, project managers and stakeholders are involved. The input of requirement validation is any requirement model which informally or formally documents the user needs, organizational standards, and organizational knowledge. The analysts, customers of the intended system and users in the problem domain interact to validate the requirements for completeness and consistency, conformance to standards, requirements conflicts, technical errors and ambiguous requirements [79]. In a scientific sense, validation is characterized by two principal types of activities: Preparing the settings for an experiment, and Performing the experiment and analyzing its results. Validation delivers a requirements model which is consistent and in accordance with the users‘ expectations. 134 Difference with Kotonya Analysis Phase:  APLE-RE Analysis Phase refers to part of Validation and Verification phase in Kotonya‘s book. It performs the external validation activity to check whether the requirements specification satisfies the stakeholders‘ needs. 7.3 Methodology for Technique Evaluations To build the Agile Product Line framework, one question needs to be answered: there is a plethora of RE techniques, but where is their place in the continuum agile, lightweight, and less RE focused methodologies and the traditional, more heavyweight methodologies? Which ones are suitable for a product line context? In this subsection, several RE techniques will be ranked with respect to their ―agility‖ based on some criteria. There is no universally valid definition of agility; Jim Highsmith defines it as follows [60]: ―Agility is the ability to both create and respond to change in order to profit in a turbulent business environment.‖ In the context of software development processes, it may also mean ―lightweight‖ in the sense of having few work products apart from the actual software [22][142]. In the Product Line context, there has been interest in investigating whether, and if so how, product line and agile can be combined to complement each other. In conjunction with the 2006 Software Product Line Engineering conference a new workshop was arranged; APLE (Agile Product Line Engineering). Tian and Cooper discusses the increasing need for shorter time to market and higher product quality and argues that this combination of practices may lead to this goal. Carbon et al. follows the same motivation and presents preliminary results from a student experiment, yet relevant experience from industry is still needed. These factors lead to the following aspects of agility and suitability to product line that make up the criteria for evaluating RE techniques: 1. Changeability Since product line projects are always followed a pre-defined schedule, in order to build the APLE framework, several questions need to be considered. Is it easy to respond to change, i.e. are the work products easily modifiable? This also encompasses the effort of re-applying the technique due to a requirements change (e.g. whether it is necessary to re-do the whole technique) and is especially applicable for modeling techniques that feature specific work products or have a specific impact on the requirements specification. 135 2. Creative thinking In product line engineering, requirement gathering involves several different stakeholders. It may need more brainstorming or creative thinking. For each technique, the following question need to be considered. Does the technique foster creative thinking? It is often necessary to not only build exactly what the customer wants, but also to be innovative and reinvent the way people work [Robertson 2002]. This aspect may already cross the line to innovation management, but is also perceived important in agile methodologies [61]. It is mainly valid for techniques with an elicitation component. 3. Modifiability Is the technique itself easily modifiable or is it necessary to apply it exactly as prescribed? This shows whether a technique may be applied in a condensed form if there is very little time. 4. Concurrence How time-consuming is the application of the technique? The evaluation of time exposure for the application of a technique is mainly based on Christopher McPhee‘s work [91] and focuses on the allowance of the technique to perform RE tasks (elicitation, specification, analysis, negotiation and validation) more quickly or concurrently, and to reduce the amount of work to be done. It is not always possible to choose the most suitable set of techniques for a project. Therefore, a numerical agility/product line ranking may provide some guidance as to what may be the best choice. A numerical ranking (1 to 5) for each technique indicates whether a technique is likely to be a burden or a support for an agile project. The final ranking is the average of the single scores. Wherever a criterion was not applicable to a technique, there is no score. The rating is based on the following scale: 1: The technique has a strong negative impact for this criterion. 2: The technique has a moderate negative impact for this criterion. 3: The technique has neither a positive nor a negative impact for this criterion 4: The technique has a moderate positive impact on this criterion 5: The technique has a strong positive impact for this criterion. Although it would be nice to have purely quantitative measurement of agility, it is hardly feasible to judge the agility of a technique on its own without having an agreed upon metric. Therefore, the agility ranking implicitly involves a comparison between techniques that serve similar purposes. It should be noted that these rankings are of course subjective in nature and therefore subject to discussion: For example, depending on an individual‘s educational background, it may be more or less difficult to learn a technique than indicated here. Thus, the ranking should not be seen as an absolute statement but rather as a guideline that gives the reader a general idea about the attributes of a technique. 136 7.4 RE Techniques Review and Analysis The RE Techniques is a collection of currently identified RE techniques and guidelines on how to use and evaluate these techniques. The RE techniques are organized according to the following five categories which are consistent with the five phases of the RE process model which discussed in Section 5.2: requirements elicitation techniques, requirements specification techniques, requirements analysis techniques, requirements negotiation techniques and requirements validation techniques. 7.4.1 Elicitation Phase The common techniques of requirements acquisition are interviews, questionnaires, consultation with stakeholders, focus group, prototyping, brainstorming and observations. 7.4.1.1 Brainstorming Brainstorming is a short group session where everyone is allowed to say whatever they feel is important to the project. Brainstorming means to spend a short amount of time, where everyone in the room is allowed to say whatever they feel is important to the project. After that, a facilitator leads the group in organizing and prioritizing the results. Rules for brainstorming are the following:      Start out by clearly stating the objective of the brainstorming session. Generate as many ideas as possible. Let your imagination soar. Do not allow criticism or debate while you are gathering information. Once information is gathered, mutate and combine ideas. 7.4.1.2 Designer as Apprentice In the technique Designer as Apprentice the analyst takes on the role of an apprentice with the customer as the master [Beyer 1995]. This approach focuses on providing the analyst with hands-on insight into the way that the end user of the system actually works. In contrast to observation and social analysis, there is interaction between the master and the apprentice. Changeability Being primarily an elicitation technique, designer as apprentice yields no characteristic work products. A requirements change does not mean that the entire technique has to be reapplied, it should be sufficient to have a short recap session with the customer. Rating: 3 Creative Thinking 137 The technique is likely to foster creative thinking, as the exposure to the work of the customer forces the analyst to think in a completely different way than he or she is used to. Rating: 4 Modifiability The technique is defined in a very detailed way (e.g. the roles are fixed and there is just one apprentice), but it should be possible to adapt these parameters if necessary. For example, it should be possible to have more than one apprentice per customer expert, because otherwise the information gained would need to be distributed to the team members, which typically causes some degradation in information quality. Rating: 3 Concurrency The way that designer as apprentice is described in, it may take a significant amount of time. Although apprenticing is certainly a great way for the analyst to gain a deep understanding of the problem domain, it is likely that he will have to deal with a lot of insignificant information during the apprenticeship. Rating: 2 Overall Agility Ranking: 3.0 7.4.1.3 Cooperative Requirements Capture (CRC) CRC is a group session approach where the main purpose is to achieve cooperation between stakeholders. The main difference between CRC and other group session approaches is that it requires the participation of stakeholders who are not necessarily included elsewhere, e.g. individuals that have a financial or regulatory stake in the system. The approach is described in detail in [84]. 7.4.1.4 Interviews Interviewing is an effective, direct person-to-person interviewing technique requires that requirement analysts have prepared a list of questions designed to gain an understanding of the real problems and potential solutions. To get as unbiased answers as possible, requirement analysts need to make sure the questions are context-free. The context-free question is a high-level, abstract question that can be posed early in a project to obtain information about global properties of the user's problem and potential solutions. They are more like a discussion and require an experienced analyst in order to provide useful results [Kremer 2002]. A context-free question is: 138    Always appropriate. Formulated so that it helps you understand stakeholder perspectives. Not biased with solutions knowledge or your opinion of what the solution should be. There are two different kinds of interviews: the closed interview, where the requirements engineer has a pre-defined set of questions and is looking for answers and the open interview, without any pre-defined questions the requirements engineer and stakeholders discuss in an open-ended way what they expect from a system. The advantage of interviews is that they help the developer to get a rich collection of information. Their disadvantage is that this amount of qualitative data can be hard to analyze and different stakeholders may provide conflicting information. Changeability It is fairly easy to redo interviews in the course of the project without having to start from scratch. The only specific work product of an interviewing session is the protocol, which is not difficult to extend. Rating: 4 Creative Thinking The amount of creative thoughts an interviewing session yields is highly dependent on the skills of the interviewer. Compared to group sessions, they have the advantage that individuals who tend to be quiet will have more opportunity to voice their opinions. Interviews enable the analyst to collect different viewpoints without the danger of dominant people in the customer‘s organization affecting the opinion of others too much. Rating: 4 Modifiability It is of course not possible to change the very nature of interviews, but they are very adaptable to different constraints. It is possible to change the location and/or communication channel (e.g., video conference, telephone) if needed. Rating: 4 Overall Agility Ranking: 3.7 7.4.1.5 Focus Groups Focus groups are an informal technique where a group of four to nine users from different backgrounds and with different skills discuss in a free form issues and concerns about features of a system prototype. 139 The discussion is supposed to be, from the user perspective, a rather free and unstructured discussion, even though the facilitator keeps up the focus and keeps the discussion to a set of well-defined topics (hence the name focus group) [MacAulay 1996]. Focus groups help to identify user needs and perceptions, what things are important to them and what they want from the system. They often bring out spontaneous reactions and ideas. Since there is often a major difference between what people says and what they do, observations should complement focus groups. Focus groups can support the articulation of visions, design proposals and a product concept. Additionally, they help users in analyzing things that should be changed, and support the development of a ‗shared meaning‘ of the system. The use of focus groups is not restricted to elicitation, they can also be used throughout the development process, e.g. in order to evaluate prototypes for validation and verification purposes [61]. Changeability Focus Group yield a wide variety of work products, such as meeting protocols, business goals or modeling artefacts like use cases and data flow diagrams. Therefore, the change responsiveness depends entirely on the choice of documentation notation. Rating: 3 Creative Thinking When it comes to creative thinking, nothing beats an open discussion in a group meeting. It is of course mandatory to maintain a good communication culture, so that all the different opinions are heard. Rating: 5 Modifiability Although the descriptions of the different approaches are sometimes very precise (e.g., JAD explicitly prescribes the roles of the participants), group sessions are typically not conducted exactly as prescribed. There are several parameters that can be tweaked in order to meet external constraints, e.g. the location of a meeting, the participants, the duration, the level of detail, or the meeting time. Rating: 5 Concurrency Compared to interviewing, one of the main advantages of group sessions is the fact that several individuals can voice their opinion at once. One of the main problems with group sessions is stakeholder availability: If it is not possible to meet due to important participants not being present, time is wasted and decision making is delayed. For facilitated group sessions, the availability of a skilled facilitator is also crucial and 140 often problematic. There is a potential for saving time by making the allowance to perform several RE stages such as elicitation, analysis and negotiation concurrently. Therefore, given that all the participants are available, group sessions have the potential to save time. Rating: 4 Additional Comments Several other techniques are similar to Foucs Groups, such as Joint Application Development (JAD), Cooperative Requirements Capture (CRC), and Future Workshops. Although there are differences between the approaches (e.g., regarding the participants), these should not be significant for our purposes. In practice, few methods are followed to the letter anyway, therefore the joint evaluation of the different approaches. Overall Agility Ranking: 4.0 7.4.1.6 Future Workshops Like focus groups, future workshops are facilitated group sessions, but they are more structured. A Future Workshop is divided into three phases: The Critique phase is designed to draw out specific issues and problems about current work practice. The Fantasy phase allows the participants to imagine "what if" the workplace could be different. The Implementation phase focuses on what changes can be realistically accomplished and what resources would be needed. The facilitator ensures that the scope of the environment is defined and adhered to, and that the participants discuss the desired end-state of the environment [84]. 7.4.1.7 Document Mining As most system development efforts replace or enhance an existing system (software based or not), there is very likely information recorded about this system. Document mining is the activity of searching through any kind of information sources in order to determine context and details for the system to be built. Sources of information may include email notes, existing system specifications, workflow descriptions or change requests for the existing system that have been recorded, to name but a few [91]. Changeability There are no specific work products to document mining. Although redoing it when there are requirements changes in order to find out specific information is likely to be easier than using document mining for elicitation (because the search will be more open-ended then), it will still take a significant amount of time. 141 Rating: 2 Creative Thinking It is likely that document mining is counterproductive for creative thinking due to the characteristic isolated way of conducting it. Rating: 1 Modifiability Document mining does not offer many opportunities for modification. An experienced analyst may know which documents to examine more closely and what to skip, but there is no obvious way of altering the technique. Rating: 2 Concurrency It is typically very time consuming to do document mining, because the analyst will usually encounter a great deal of irrelevant information that needs to be filtered. Rating: 1 Additional Comments Document mining is likely the least agile of all techniques. In addition to its shortcomings mentioned above, the lack of interaction does not foster communication and feedback, which in turn is likely to cause additional rework due to missed or misunderstood requirements. The only aspect that prevents an extremely low rating is the fact that it is easy to learn and apply. Overall Agility Ranking: 2.2 7.4.1.8 Observation and Social Analysis / Ethnography The application of ethnography in RE focuses on observing the users‘ way of doing their work instead of asking them about it, because it is sometimes very difficult to explain how something is done but very easy to demonstrate. This is especially true for routine tasks. Another purpose of this technique is to identify deviations between the task specifications the customer provided and how the users actually perform their work. It is not supposed to be a stand-alone elicitation technique but rather a support for other elicitation techniques. A summary of the activities in ethnography may be found in [79]. Changeability 142 This technique does not yield specific work products except protocols of the observation and has no specific impact on the requirements document. While requirements changes alone are unlikely to have negative effects on the usefulness of the results, an environmental change like a merger could invalidate the results of the ethnographic study, because the organizational culture has changed. In this case, the study would need to be repeated from scratch, which is very time-consuming. Rating: 2 Creative Thinking Since observation and social analysis makes the requirements engineer approach the systems analysis process from a whole different perspective, it is likely to spark novel thoughts, because he does not guide the customer through an elicitation process. Rating: 4 Modifiability As there is no clear prescription of this technique, it is hard to judge its modifiability. There can be room for improvisation, because the technique is very open-ended, but it seems to be very hard to perform a decent ethnographic study if there is very little time to thoroughly study people and their relationships. Rating: 2 Concurrency The application of ethnography can be rather time-consuming. Especially the process of becoming familiar with the individuals being studied takes a significant amount of time. As ethnography itself only makes sense in conjunction with other RE techniques like prototyping or interviewing, it means that its application is always consuming additional time. Rating: 1 Additional Comments Due to its open-ended nature, it is hard to rate this technique. It is, however, safe to say that if time is the primary constraint, ethnography may not be the number one choice. However, if used in conjunction with other elicitation techniques, it may provide valuable insight into the way people actually work. Overall Agility Ranking: 2.3 143 7.4.2 7.4.2.1 Specification Techniques Informal Modeling Informal modeling is a concept encompassing several techniques like rich pictures or natural language text descriptions. There are no strict notation rules, meaning that the representation of the artefact that is modeled can be adjusted to the needs of the audience, e.g. the end user, which enables all stakeholders to communicate about the system. Another advantage is the great flexibility in modeling the system and its interactions [84]. Changeability Due to the lack of rules, it may be problematic to incorporate changes into informal models. On the other hand, they are supposed to be easily understood and therefore should be fairly easy to modify. Rating: 3 Creative Thinking Having a pictorial representation of the system surely helps the analyst to understand the interdependencies of requirements and to get a better overview of the system. Instruments like rich pictures will therefore be helpful in surfacing additional requirements. Rating: 4 Modifiability The lack of rules mentioned above makes informal modeling very easy to modify according to the needs of the customer. Rating: 5 Concurrency It is possible to save some time with this technique, because it allows for some concurrency of the four requirements tasks. The fact that it is not complicated is also likely to speed up the application of the technique. Rating: 4 Overall Agility Ranking: 4.0 7.4.2.2 Semiformal Modeling Semiformal modeling encompasses techniques like data flow diagrams, entity relationship diagrams, or the unified modeling language (UML) [25]. Like informal modeling, semiformal modeling serves the purpose of developing a visualization of the way the system operates, but there are diagrammatic rules that 144 constrain the ways the system may be described [61]. This means that these notations typically are more difficult to read for the untrained reader, but they are also less ambiguous and easier to use across organizational borders. Changeability Compared to informal modeling, the presence of notation rules will facilitate the incorporation of changes into the specification. This will be especially helpful when some time has passed and people who are not familiar with the notation may need to modify it. Rules also enable automated change support. Rating: 4 Creative Thinking Like informal modeling, semiformal notations provide a visualization of the system that helps to get a general overview. However, being constrained by the rules will probably suppress real creativity. Rating: 3 Modifiability Techniques like state charts or data flow diagrams themselves are only modifiable to a limited extent - the only apparent way is to vary their level of detail. But even though the single techniques are difficult to modify, there is often the possibility to choose a favorite technique (e.g., the one the team is mot familiar with) from various semiformal notations that serve similar purposes. This can be counted as moderate modifiability. Rating: 3 Concurrency Time exposure largely depends on system complexity. Semiformal notations allow for performing some analysis and documentation concurrently. They are likely to speed up discussions about the requirements, because most individuals find visual representations more expressive than pure text. Semiformal modeling also allows for some initial design work, which has the advantage that the analyst can consider technical feasibility. However, they also introduce the danger that the requirements are based on preliminary and premature design assumptions. Rating: 4 Overall Agility Ranking: 3.5 145 7.4.2.3 Formal Modeling The term ―formal specification‖ encompasses more than just one technique: It denotes a variety of languages such as temporal logic and algebras [62] that enable the analyst to describe a system in a verifiable way, so that the presence or absence of certain system properties can be proved [50]. This is especially useful for safety-critical systems, where correctness of the specification is mandatory. Van Lamsweerde provides a good general overview of this topic [64]. Changeability Formal specifications may be easier to modify than other representations if there is good tool support. On the other hand, without proper tools, formal notations will take a great deal of effort to modify. Rating: 3 Creative Thinking The focus of formal methods is on correctness and verification. As they are not used for elicitation purposes, they offer no support for creativity. Rating: 1 Modifiability Formal methods have to be mathematically correct, and therefore there is practically no room for modification. There is, of course, the possibility to choose among different notations and pick a lightweight technique that takes less time than other formal methods. Rating: 2 Concurrency Formal notations are very time consuming to apply. Because the fewest customers will be able to comprehend them, they should only be used in conjunction with other notations, which means that defining formal specifications requires additional workload. Rating: 1 Overall Agility Ranking: 2.0 7.4.2.4 Requirements checklists Checklists help ensure that the requirements meet certain quality standards. This can mean that important areas of RE are not missed, e.g. that requirements are not built upon early design assumptions, ensuring 146 requirements testability and avoiding ambiguity. On a more detailed level, checklists may also include syntactical advice like avoiding the use of words like ―should‖ or ―could‖. Requirements checklists are often domain specific. Changeability Checklists do not yield specific work products, and there is no need to adjust the checklist itself when a change occurs. For changed and newly discovered requirements, the checklist can be applied in isolation. Therefore, even though checklists have no positive effect on change responsiveness, there is no negative impact either. Rating: 3 Creative Thinking Checklists are not intended to support creative thinking. Rating: N/A Modifiability Checklists may be modified with respect to their level of detail. The question is, however, whether the efficacy of the checklist will be compromised or not. Rating: 2 Concurrency For a large number of requirements, it takes a significant amount of time to check each and every requirement. On the other hand, checklists provide analysts with guidance for the requirements process, which may save time. Rating: 3 Overall Agility Ranking: 3.4 7.4.2.5 Requirements Reuse Requirements reuse is the reuse of parts of existing specifications that are common among several products [Lam 1997]. An example may be the reuse of the specification of the display for a cell phone, which may be similar across several types. Requirements reuse introduces the need for requirements interaction management, because there may be conflicts between common requirements and system-specific requirements. Reuse may happen at various levels of abstraction, i.e. very general requirements may be reused or in the case of domain-specific reuse, very specific ones. 147 Changeability Requirements reuse introduces the need for requirements interaction management, which has a negative impact on the responsiveness to change, because the interaction mechanisms have to be re-executed for each change. Rating: 2 Creative Thinking Requirements reuse is not intended to support creativity, and so the ranking is not applicable here. Rating: N/A Modifiability It is unlikely that requirements reuse can be substantially modified. It is however, possible to adjust the level of abstraction of the reused components. Regarding the inevitable need for interaction management, it is possible to apply it at different levels of sophistication. However, the analyst needs to be aware that the trade-off will be an increasing likelihood of missing an interaction, the less formality is involved. Rating: 2 Concurrency Writing reusable requirements and actually reusing requirements has to be distinguished: It is fairly difficult and time-consuming to write reusable requirements. Reusing requirements is intended to save time. This is true in most cases, but requirements reuse also introduces the need for requirements interaction management, which in turn costs time. The use of tools should be very helpful here. Rating: 2 Additional Comments If software development is considered in the context of the lifetime of an organization instead of isolated projects, requirements reuse will score much higher than it does here. Without a doubt, requirements reuse saves a significant amount of time, as soon as a platform of common requirements is in place and the personnel are trained. Thus, the ranking here should be taken with caution, as reuse may in fact be a powerful tool in dynamic markets. Overall Agility Ranking: 2.4 148 7.4.3 7.4.3.1 Analysis Phase Joint Application Development (JAD) JAD is a facilitated group session approach where the participants work together to perform a preliminary analysis of the system. It features the following roles: session leader (facilitators), user representative, specialist, analyst, information systems representative, and executive sponsor. It includes a highly structured agenda with detailed objectives and is usually performed as a multiple-day workshop [84]. 7.4.3.2 Goal-Oriented RE Goal-oriented RE is a holistic approach that covers all phases of the RE process. In contrast to most other RE approaches, it is concerned with the rationale behind a requirement and its source, i.e. why it has been suggested and who has proposed the requirement. Goals capture the objectives of the system under consideration at different levels of abstraction: The process can happen both top-down by asking ―how‖-questions in order to refine goals and also bottom up by asking ―why‖-questions, which helps in eliciting additional requirements. Goal-oriented RE is typically coupled with lightweight formal modeling in the goal refinement stage. A concise overview about goal-oriented RE can be found in [64]. Changeability At least in KAOS, changes will require a significant effort to incorporate as part of the specification uses a formal notation (temporal logic), which may not be easy to understand. For a requirement that has changed, it needs to be checked if it is in conflict with the goals or exhibits a new goal. Rating: 2 Creative Thinking Explicitly including the rationale behind a requirement will very likely help elicit additional requirements that will help realize this requirement. Rating: 4 Modifiability It is possible to apply only a fraction of goal-oriented RE, e.g. building hierarchical goal refinement trees, which will be helpful in order to reason about the business goals of the system. The underlying concepts will be helpful for any kind of RE, e.g. asking the ―why‖ question for each requirement. Apart from that, it seems unlikely that the technique can be changed substantially without compromising its value. Rating: 2 149 Concurrency It is not the purpose of goal-oriented RE to speed up development but rather to improve understanding of the requirements and especially their rationale. Reasoning about this takes time. If goal-oriented RE is even coupled with formal notations like in KAOS, it is very time consuming. Rating: 1 Overall Agility Ranking: 2.3 7.4.3.3 Prioritization In a time constrained environment, it is important to realize that it is rarely possible to implement all of the suggested features of a product. If requirements are prioritized well, there is a sound basis for negotiation if budget or time constraints force trade-offs. There are various approaches for prioritization, some of which have been evaluated by Karlsson et al. [72]. Methods employing pair-wise comparisons typically yield the best results, because individuals usually find it easier to assign relative values instead of absolute ones. The most common example for pair-wise prioritization algorithms is the Analytic Hierarchy Process [197]. Karl Wiegers suggests a method that takes the risk associated with a requirement as well as the penalty for not implementing it into account [196]. Changeability If tools are used, it is fairly easy to integrate new requirements, because the only thing that needs to be done is a comparison of the new requirement with the existing ones. Rating: 4 Creative Thinking It is not the purpose of prioritization to foster creative thinking. Rating: N/A Modifiability There are many different ways of prioritizing software requirements that require different amounts of effort. A variety of approaches has been evaluated in [72]. Rating: 4 Concurrency There is a varying need for time depending on the prioritization variant used. There is, however, a trade-off 150 involved, as the most effective forms of prioritization are also the slowest ones [72]. Using tools greatly reduces time consumption and is absolutely mandatory for the analytic hierarchy process. Rating: 3 Overall Agility Ranking: 4.2 7.4.3.4 Quality Function Deployment QFD originated in Japan and is largely attributed to Yoji Akao [5]. Its roots are not in software development but rather in consumer product development, with its first application in the automobile industry. QFD features several instruments like the customer voice table, affinity diagrams, or hierarchy diagrams in order to organize the requirements. The most commonly used technique within QFD is the so-called House of Quality, a multi-purpose matrix that allows for a basic visualization of feature interactions and identifying the relationships between customer requirements (or ―verbatims‖) and technical requirements, which facilitates the transition into the design stage. Changeability Unless there is tool support, it is extremely tedious to apply QFD at all, not to speak of redoing it after requirements have been added or changed. Even then, due to the amount of information and the big number of dependencies that for example the House of Quality contains, it takes considerable effort to re-apply QFD. Rating: 2 Creative Thinking On the one hand, QFD supports creativity in the sense of getting multiple perspectives by examining competitor‘s products, while on the other hand there is no direct support for bringing up really novel ideas. Rating: 3 Modifiability As Blitz QFD shows, QFD is indeed modifiable. It is very common in industry to only use the House of Quality [198], and it is also possible to leave out certain parts thereof if the company does not need a certain kind of information, e.g. the interaction roof. It should be noted, however, that it is not trivial to assess the effects of leaving out a step in QFD. Rating: 3 151 Concurrency Applying all the elements of QFD involves a lot of effort. Especially the effort for the House of Quality is very high, as effort increases quadratically with the number of requirements. Rating: 1 Overall Agility Ranking: 2.5 7.4.3.5 Blitz Quality Function Deployment Blitz QFD is the attempt to remove unnecessary elements from QFD in order to slim the process. Only the tools that are absolutely necessary for a project are used. Judging about their necessity is left up to the analyst. Requirements are prioritized early in the process, and only the ones that provide business value to the customer are used in the QFD matrices and tools. This reduces the number of requirements that have to be dealt with in the House of Quality, if this part of QFD is applied [198]. Changeability In general, the same arguments that are valid for QFD hold for Blitz QFD as well. However, the smaller number of artefacts speeds up redoing the process. That being said, the techniques used build on each other, which means all of them have to be executed again. Rating: 3 Creative Thinking Like in QFD, truly creative thinking is not directly supported. But the measures that QFD advocates (cross-functional teams, investigation of competing products) are likely to widen the horizon of the analysts. Rating: 3 Modifiability Richard Zultner argues that Blitz QFD already is the minimal set of QFD techniques that is still effective [Zultner 1996a]. Therefore, it can be assumed that the method is not very flexible. Rating: 2 Concurrency Compared to QFD, Blitz QFD takes significantly less time. It only uses a very slim set of tools, and is therefore likely to be applied rather quickly. 152 Rating: 4 Overall Agility Ranking: 3.0 7.4.4 Negotiation Techniques Every negotiation is different, but the basic elements do not change. Principled negotiation can be used whether there is one issue or several; two parties or many; whether there is a prescribed ritual, as in collective bargaining, or an impromptu free-for-all, as in talking with hijackers. The method applies whether the other side is more experienced or less, a hard bargainer or a friendly one. 7.4.4.1 Distributive Negotiation The classic distributive bargaining situation is one that everyone has experienced, also call win-lose. The issue is like the buyer and seller. The buyer and seller do not know each other, and do not expect to have any meaningful future relationship. The only issue to be negotiated is price. The goal of the buyer is to minimize the price, and the goal of the seller is to maximize the price. The goal of the buyer is to minimize the price, and the goal of the seller is to maximize the price. In this situation, the requirements analysts and stakeholders are competitors. 7.4.4.2 Integrative Negotiation Integrative bargaining is a cooperative approach to negotiation or conflict resolution. It is often referred to as a win-win or mutual -gains approach. Unfortunately the term win-win today is so popular that has become a cliche and is used to refer to any collaborative process. The integrative approach, like distributive bargaining, involves searching for mutually profitable options and logical trade-offs. It is also called an expanded-pie approach because negotiators search for better proposals than the obvious ones that meet only their own interests. Integrative techniques include a clear understanding of the issues, open sharing of information, and the joint exploration of solutions that benefit both parties. In an integrative bargaining process the parties generally cooperate to achieve maximum total benefit of the final agreement while also competing to divide the value of the package. 7.4.5 7.4.5.1 Validation Techniques Evolutionary Prototyping Evolutionary prototyping is actually a lifecycle model that is also a powerful technique to ensure that the system meets the customer‘s needs, because it is possible to evaluate something tangible instead of an abstract system specification. In evolutionary prototyping, the system is developed throughout several iterations, within which parts of the system are added and modified if needed. Thus, the prototype becomes the final system, which means a flexible architecture is needed in order to accommodate the changes that 153 arise throughout the development [79]. Changeability Responsiveness to change depends on how the prototyping process is executed: Only short iterations allow for a quick response to changes. As evolutionary prototyping is rather a lifecycle model than an RE technique, the aspect of having to re-do the technique does not apply to it. Nevertheless, evolutionary prototyping is all about change incorporation, and therefore receives a high rating. Rating: 5 Creative Thinking Especially for complex issues, it is typically very helpful for human beings to base discussions on tangible results instead of starting from scratch. This is one of the greatest strengths of evolutionary prototyping. However, the same fact may be a burden for really innovative thinking. Rating: 4 Modifiability Evolutionary prototyping may be modified by increasing or decreasing cycle times as needed. The way that the system is presented to the user is very open-ended and allows for a variety of approaches, e.g. focus groups. Rating: 4 Concurrency Building an extensible application architecture and consistently adapting it is time consuming. However, the amount and timeliness of feedback that evolutionary prototyping delivers outweighs this disadvantage, because unnecessary rework is reduced, especially if the iterations are kept short. Rating: 3 Overall Agility Ranking: 4.2 7.4.5.2 Exploratory Prototyping Unlike evolutionary prototyping, the prototype in exploratory prototyping is discarded after its evaluation. It is therefore more suitable for feasibility studies and does not need to be designed with extensibility or most other quality attributes in mind [79]. Exploratory prototyping may also be used to elicit initial requirements by presenting the potential users a rough sketch of the future system. There are prototypes at 154 varying levels of sophistication, like paper prototypes, ―Wizard of Oz‖ prototypes or software prototypes [62]. Changeability Exploratory prototyping does not necessarily need to be reapplied if there are changes to the requirements, because it has no direct impact on the specification. It can however, be a valuable help to quickly assess feasibility of changes. Rating: 4 Creative Thinking Exploratory prototyping has the same advantages and disadvantages as evolutionary prototyping: Users will profit from the possibility to try out a concrete system, but will also probably be limited in their creativity because they base their suggestions on something existing. Rating: 4 Modifiability It is possible to use different tools depending on the kind of prototype needed and build prototypes of varying degrees of sophistication [62], e.g. paper prototypes, ―Wizard-of-Oz‖ prototypes or software prototypes. Rating: 5 Concurrency Time exposure of exploratory prototyping largely depends on the application of tools and the kind of prototype. As quality attributes are negligible here, it is typically not very time consuming. Rating: 4 Overall Agility Ranking: 4.2 7.4.5.3 Requirements Reviews Requirements reviews (or inspections) involve stakeholders reviewing the requirements specification or parts thereof in order to ensure it is conforming to their actual needs [Rothman 2000]. The degree of formality ranges from ad hoc meetings where developer and customer examine the specification over checklist-driven reviews to inspections based on specific reading and reviewing techniques like perspective-based reading. The latter is more a verification technique and is performed by the developers 155 rather than the customer. Changeability The more formal reviews are, the more inconvenient it is to schedule them for each and every change. Therefore, this largely depends on how exactly the reviews are conducted. Rating: 3 Creative Thinking Since requirement reviews deal with artefacts that already exist, there is little opportunity for the generation of really novel thoughts. However, reviews are an opportunity for analysts and customers to discuss the understanding of the requirements, which may lead to solutions that were not considered thus far. Rating: 3 Modifiability The degree of formality of a review may be adjusted in order to accommodate time constraints as well as the frequency of the reviews. Rating: 4 Concurrency Time exposure depends on the degree of formality of the review. There is no need to review requirements that have already been checked for changes, unless they have changed due to the ―ripple effect‖. Rating: 3 Overall Agility Ranking: 3.5 7.4.5.4 Requirements Testing Requirements testing is the activity of defining test cases for the requirements as soon as they are written. The purpose of test cases is to ensure that the implementation meets the requirements. Writing test cases during the requirements phase ensures that the analyst has not already forgotten about the purpose of a requirement by the time the project reaches the testing stage. Changeability For each requirement that has changed, the test cases need to be adapted as well. This requires additional 156 effort that does not directly contribute to project progress. Rating: 2 Creative Thinking Writing test cases does not explicitly support creative thinking, although it forces the analyst reflect on the requirements. On the other hand, it does not impair creativity, either. Rating: 3 Modifiability The definition of test cases is not an ―all-or-nothing‖ activity, i.e. there is room for adjustment with respect to completeness. The analyst may stop writing test cases at varying levels of completeness. Rating: 4 Concurrency Writing test cases for each requirement takes additional time in early phases of the project. On the other hand, test cases may need to be written anyway before delivery of the product. If they are written long after the requirements have been documented, this may take even more time than doing it right away, because the developer/analyst needs to once again become familiar with the requirements. Rating: 3 Overall Agility Ranking: 3.2 7.5 Conclusion The APLE-RE Techniques is the foundation for developing the APLE-RE process templates. The overall objective of the methodology for selecting techniques is to provide a set of guidelines to develop the most suitable process model for a software project. A structured, step-by-step approach is adopted in the methodology so that the requirements engineers can easily understand the development process. 157 8 Conclusion and Future Work The problems experienced in software engineering decades ago still challenge people today. There are tremendous factors contributing to the overall crisis in software engineering. One of the major reasons is related to the bad practices in software engineering in general and in requirements engineering in particular. After examining the failure of the FAA (Federal Aviation Administration) project, which was cancelled after 10 years and after having spent $1.3 billion, Stephen found that one of the major reasons of failure of this project was the unorganized, chaotic, and unplanned RE process [184]. A great many RE methodologies are available and they vary significantly; from strict plan-based approaches to agile approaches. Regardless of the method being used, most software projects strive to reach a balance between three basic goals: satisfactory software quality (scope), the right cost and timely delivery. Attempting to satisfy these requirements causes further complications to arise, particularly with respect to long-term product management issues. In Chapter 2, two popular development approaches are discussed, software product line engineering (SPLE) and agile software development. These two approaches can be placed in each end of a plan-based/agile spectrum. The former is based on planning and preparations for efficient software development based on rapid construction by assembling pre-developed assets, while the latter aims at efficient change response instead of extensive up-front planning. They may correspondingly be categorized as proactive and reactive approaches to software engineering. The principles of SPLE have been in use for a long time and industrial experience shows that the approach has substantial advantages when it comes to cost-efficient development, product quality and the ability to deliver on time. Agile is a more recent trend within the software engineering community and has attracted wide interest in both industry and academia. Initial evidence from the results of ongoing research suggests that using agile is advantageous, given the right context [22][44]. Both approaches have the same overall objective; that of improving software development efficiency. On the other hand, research has shown that the implementation of good RE practices contributes to the overall success of software projects [43] [186][26]. It became clear that every software project requires an RE process and that the only issue is what type of RE process model is most suited for a software project [27] [49]. So the challenge for RE researchers is how to develop the most suitable RE process model and how to select the most suitable techniques for a agile product line project. 8.1 Summary of Research The research presented in this proposal is one of the first efforts toward providing a solution to developing the most suitable RE process models for agile product line projects. In order to achieve this aim, the literatures from various domains were reviewed, such as software engineering, requirements engineering, rational unified process, agile methods and product line methods. The final outcome of the research is the APLE-RE framework. 158 This proposal describes three major parts of the framework.  In Chapter 5, APLE-RE Questionnaire is presented. APLE-RE Questionnaire is used to acquire the expertise of researchers and practitioners actively involved in software development using agile, product line RE techniques. The Questionnaire Version 1.0 are implemented and under beta testing.  In Chapter 6, APLE-RE Process Repository is presented. APLE-RE Process Repository contains a set of process templates. These process templates are tailored versions of RUP and presented in UML, which range from very agile to plan driven approaches for single product and product line RE.  In Chapter 7, APLE-RE Techniques is presented. The APLE-RE Techniques is the foundation for developing the APLE-RE process templates. The overall objective of the methodology for selecting techniques is to provide a set of guidelines to develop the most suitable process model for a software project 8.2    Limitations Given the merits the research has, some general limitations are summarized as follows: In Chapter 5, 342 scenarios are presented, including 18 domains and each domain has 18 scenarios. If the number of scenarios increases, the response from experts may be more accurate. In Chapter 6, two templates are proposed. In Chapter 7, a collection of RE techniques is reviewed. However, this list can not be comprehensive. Including more RE domain knowledge would further increase the help. 8.3 Future Work The limitations will be addressed in the future work. For the APLE-RE Questionnaire, the following needs to be done:     Revise the Questionnaire to include process template options Release the Questionnaire and distribute to experts inside and outside the university. Collect experts‘ options and store them in database. Feed data into BBN (out of scope) In order to complete the APLE-RE Process Repository, the following are required:     Add requirement management for the current two templates. Select and define additional templates. Validation for Agile Product Line RE Process Template. A reverse validation methodology will be presented. In addition, an alternative validation methodology is discussed. That is, given a product line project, apply the template to the project, and evaluate the project. For the APLE-RE Techniques, the following needs to be done: 159  Further enhance APLE-RE Techniques by adding more domain knowledge. This task is a continuous process throughout the whole lifetime of the APLE-RE tool since the RE process knowledge continuously changes.  Further development of the evaluation schema of the APLE-RE Techniques in APLE context. 8.4 Key Issues Validation is an important component of the APLE-RE Framework. The templates need to be complete, accurate and can be applied in specify Agile Product Line situation. In this proposal, a reverse validation methodology is presented. Reverse engineering is the process of discovering the technological principles of a device, object or system through analysis of its structure, function and operation. It often involves taking something (e.g. a mechanical device, electronic component, or software program) apart and analyzing its workings in detail, usually to try to make a new device or program that does the same thing without copying anything from the original. The term "reverse engineering" as applied to software means different things to different people, prompting Chikofsky and Cross to write a paper researching the various uses and defining a taxonomy. From their paper: Reverse engineering is the process of analyzing a subject system to create representations of the system at a higher level of abstraction [30]. It can also be seen as "going backwards through the development cycle" [173]. In this model, the output of the implementation phase (in existing product) is reverse engineered back to the analysis phase, in an inversion of the traditional waterfall model. Reverse engineering is a process of examination only: the software system under consideration is not modified (which would make it reengineering). Software anti-tamper technology is used to deter both reverse engineering and reengineering of proprietary software and software-powered systems. In practice, existing product is already available for the software, but higher level aspects of the program, perhaps poorly documented or documented but no longer valid, are discovered. APLE-RE templates are validated using reverse engineering. Existing case studies are reverse engineered with respect to the RE process used. The closest matching template is identified in the repository. The difference from the template and the actual process used are identified and classified. The difference can be used to indicate the usefulness of the template. In this respect, our work differs from previous accounts of validation. The characteristics of validation are discussed on a very general level in, for example [174], and descriptions are given concerning various techniques and themes such as prototyping [57], validation problems [75] and types of notation used [96]. The growing awareness of the importance of validation has led to several techniques being incorporated in more recent process models [24] and system development environments such as Statemate [56]. However, validation is, in general, regarded as an intuitive ‗black box‘ process. Empirical work has tended to focus 160 on more general aspects of systems development [94][183]. Pekka Abrahamsso presented more than 60 case studies in his paper. We will use these examples as our empirical studies. In addition, the implementation of a web-based version of the questionnaire will be updated and spread out to experts. Several templates need to be built and use one of the validation methodologies to validate. However, more templates building is beyond the Ph.D study. 8.5 Anticipated Contributions of the Completed Research So far, we are not aware of any research that provides similar help for RE process development. Existing research also fails to provide constructive help for the selection of RE techniques for a particular software project. The lack of help and guidance as to which RE process models and techniques fit best to a software project, has resulted in many ad hoc RE processes in industry [9] [184][95]. The first major step in the research of this proposal was to identify existing knowledge about the RE process, agile methods and product line methods, derive characteristics that help classify RE process models as well as software projects. Having defined these characteristics allows developing heuristics that link project characteristics with characteristics of RE process and techniques and therefore enables to develop a tailor-made RE process that best fits the project under development. This interdisciplinary research will make the following novel contributions:  The questionnaire will be the largest survey conducted in RE process definition research (ours will have 100 international respondents) and the only one conducted with a specific focus on the adoption of agile methods in product line requirements engineering. The extensive supporting scenario set (over 350) used in the questionnaire allow it to be answered by experts in a wide variety of domains. The results will be freely available for others to re-use.  Factors to determine degree of agility in product line RE will be identified. The established criteria proposed by Barry Boehm (size, geographic distribution, etc.) will be extended to rank a rich set of non-functional requirements with respect to their impact on the degree of agility introduced (security, availability, reliability, response time performance, scalability, etc.)   A new set of RUP based process templates for single product and product line techniques, with varying degrees of agility, will be proposed. Existing RE process knowledge, especially for Product Line process and Agile process, is classified and organized into an Agile Product Line Requirement Process Repository. The repository is built with a clear structure with the intention of helping develop the most suitable APLE process model and selecting techniques for a software project. The case study and the prototype tool developed so far are strong indications that the knowledge base is a valuable asset during process development. 161 Reference [1] [2] [3] [4] [5] [6] [7] A. Newell and H. Simon, Human Problem Solving, New Jersey: Prentice-Hall, 1972 Acuña, S. T. and Ferré X., Software Process Modeling. ISAS-SCI (1) 2001, pp.237-242, 2001 Agile Manifesto principles, http://www.agilemanifesto.org/principles.html Agile Product Line Engineering Questionnaire, available http://129.110.92.41/Default.aspx Akao, Y. (Ed.), Quality Function Deployment: Integrating Customer Requirements into Product Design. Cambridge, MA: Productivity Press, 1990 Anderson, S. and Felici, M., Requirements Engineering Questionnaire Version 1.0, The University of Edinburgh, 2001. Andersson, C. and Runeson, P., Verification and Validation in Industry - A Qualitative Survey on the State of Practice. In Proceedings of the 2002 International Symposium on Empirical Software Engineering, (2002), 37-47. B Atkinson, C.; Paech, B.; Reinhold, J.; Sander, T., Developing and applying component-based model-driven architectures in KobrA; Enterprise Distributed Object Computing Conference, 2001. EDOC '01. Proceedings. Fifth IEEE International Auvray, V. and Wehenkel, L.,‖On the Construction of the Inclusion Boundary Neighbourhood for Markov Equivalence Classes of Bayesian Network Structures‖, in the Proceeding of the 18th Conference on Uncertainty in Artificial Inteligence (UAI), 2002, pp. 26-35. Avellis, G., "CASE support for software evolution: a dependency approach to control the change process," in Proceedings of Fifth International Workshop onComputer-Aided Software Engineering, 1992, pp. 62-73. B. Nuseibeh & S. Easterbrook, Requirements Engineering: A Roadmap, The future of software engineering, ACM Press, 2000, 37-46. Baisch, E. and Liedtke, T., "Automated Knowledge Acquisition and Application for Software Development Projects," in Proceedings of the 13th IEEE International Conference on Automated Software Engineering, 1998, pp. 306-309. Barry, P. and Laskey, K., "An Application of Uncertain Reasoning to Requirements Engineering," in Proceedings of the 15th Conference on Uncertainty in Artificial Intelligence, Jul 1999, pp.41-48. Beaver, J., Schiavone, G. and Berrios, J., "Predicting Software Suitability Using a Bayesian Belief Network," in Proceedings of the Fourth International Conference on Machine Learning and Applications, vol 0, 2005, pp. 82-88. Berdie, Doug R., Anderson, John F., Niebuhr, Marsha A, Questionnaires: Design and Use, 2nd edition. The Scarecrow Press Inc, 1986. Bill Thomas, Meeting the Challenges of Requirements Engineering, SEI Interactive, http://www.sei.cmu.edu/interactive/Features/1999/March/Spotlight/Spottlight.mar99.htm, 1999 Bill Thomas, ―Product Lines in Practice at Three Major Corporations‖, SEI Interactive, September 1999 Boehm, B. W, Anchoring the Software Process, IEEE Software, 13, 4, July 1996, pp. 73-82. Boehm, B. W and Papaccio, P. N. (1988): Understanding and Controlling Software Costs, IEEE Transactions on Software Engineering, Vol. 14, No. 10, pp. 1462-1477, 1998 Boehm, B. and Turner, R., Balancing Agility and Discipline: A Guide for the Perplexed, Addison-Wesley, 2003. Boehm, B., A Spiral Model of Software Development and Enhancement. IEEE Computer, Vol. 21, No. 5, May, pp 61-72., 1988 Boehm, B., Get Ready for Agile Methods, with Care. IEEE Computer, Vol. 35, No. 1, January, pp. 64-69, 2002 Boehm, B., Software Engineering Economics, Prentice Hall, 1981 Boehm, B.W. (1985) A spiral model of software development and enhancement. in: Proceedings of an International Workshop on the Software Process and Software Environments, Cot0 de Caza, Trabuco Canyon, California, 1985 Booch, G. et al., The Unified Modeling Language User Guide. Addison-Wesley Longman Inc, Reading, Massachusetts, 1998 Brooks F. , No Silver Bullet – Essence and Accident in Software Engineering, IEEE Computer Vol. 20, No.4,pp.10-19, 1987 [8] [9] [10] [11] [12] [13] [14] [15] [16] [17] [18] [19] [20] [21] [22] [23] [24] [25] [26] 162 [27] Buren J. V and Cook D. A., Experiences in the Adoption of Requirements Engineering Technologies, CROSSTALK, The Journal of Defense Software Engineering, 1998 [28] C.V. Weber, M.C. Paulk, C.J. Wise, and J.V. Withey, Key Practices of the Capability Maturity Model, Software Engineering Institute, CMU/SEI-91-TR-25, ADA240604, August 1991 [29] Cauvet, C., Proix, C, and Rolland, C., ―ALECSI: an expert system for requirements engineering,‖ in Proceedings of The Third International Conference on Advanced Information Systems Engineering, 1991, pp. 31-49 [30] Chikofsky, E.J.; J.H. Cross II, Reverse Engineering and Design Recovery: A Taxonomy in IEEE Software. IEEE Computer Society: 13–17. , 1990 [31] Clements, P. and Northrop, L., Software Product Lines: Practices and Patterns, Addison-Wesley Professional, 2001. [32] Cockburn, A., A Methodology Per Project, Technical Report Humans and Technology, TR 99.04, Oct. 1999. [33] Coleman and Verbruggen, A quality software process for rapid application development, Software Quality Journal 7, 1998 [34] Cooper, K., Franch, X. (eds.), Proceedings of the 1st International Workshop on Agile Product Line Engineering, Aug. 21, 2006, Baltimore, Maryland, USA, available at http://www.lsi.upc.edu/events/aple. [35] Crystal Clear, A Human-Powered Methodology for Small Teams, Alistair Cockburn, 2004 [36] Cuevas, G.; Serrano, Al.; Serrano, Ar. Assessment of the requirements management process using a two-stage questionnaire, Quality Software, 2004. QSIC 2004. Proceedings. Fourth International Conference on 2004 Page(s):110 - 116 [37] D. Leffingwell, D. Widrig; Managing Software Requirements: A United Approach; Addison-Wesley, 2000; p.18-21 [38] Damian D., Zowghi D., Vaidyanathasamy L. and Pal Y. An Industrial Case Study of Immediate Benefits Of Requirements Engineering Process Improvement at the Australian Center for Unisys Software, Journal of Empirical Software Engineering, Vol. 9, No. 1-2, pp. 45 – 75, 2003 [39] Davis A. M., Software Requirements, Objects, Functions and States, Prentice Hall, 1993 [40] Don S. Batory, A Tutorial on Feature Oriented Programming and Product-Lines. ICSE 2003 [41] Dorfman M. and Thayer R. H., Standards, Guidelines, and Examples on System and Software Requirements Engineering. IEEE Computer Society Press Tutorial, 1990 [42] Dutta, S.; Lee, M.; Van Wassenhove, L.; Software engineering in Europe: a study of best practices, Software. IEEE Volume 16, Issue 3, May-June 1999 Page(s):82 – 90 [43] Emam K. E. and Birk A. Validating the ISO/IEC 15504 Measure of Software Requirements Analysis Process Capability, IEEE Transactions on Software Engineering, Vol. 26, No. 6, 2000 [44] Erickson, J., L. K., and S. K., Agile Modeling, Agile Software Development, and Extreme Programming: The State of Research. Journal of Database Management, 2005. [45] European Software Institute, 1997 Software Best Practice Questionnaire - Analysis of Results, ESI Technical Report, December 1997. [46] Feiler P. H. and Humphrey W. S., Software Process Development and Enactment: Concepts and Definitions, Software Engineering Institute, Carnegie Mellon University, Pittsburgh, PA, 1991 [47] G. Booch, Object Oriented Analysis and Design with Applications, Addison Wesley Longman, 1998; p.104-106 [48] Giarratano, J. and Riley, G., Expert Systems: Principles and Programming, Third Edition: Principles and Programming. Course Technology, 1998. [49] Glass R. L., Matching Methodology to Problem Domain, Communications Of The ACM, May 2004, Vol. 47, No. 5, pp. 19-21, 2004 [50] Goguen, J.A., Formal Methods: Promises and Problems, IEEE Software, Vol. 7, No. 1, January/February, pp.73-83, 1997 [51] Gomaa, H.; Shin, M.E., Multiple-view meta-modeling of software product lines, Engineering of Complex Computer Systems, 2002. Proceedings. Eighth IEEE International Conference on 2-4 Dec. 2002 Page(s):238 – 246 [52] Groves, L., Nickson, R., Reeve, G., Reeves, S. and Utting, M., A Survey of Software Development Practices in the New Zealand Software Industry. In Proceedings of the 2000 Australian Software Engineering Conference (ASWEC'00), (2000), 189-201. [53] H. Gomaa, Software Product Lines with UML: From Use Cases to Pattern-Based Software Architectures, Addison Wesley, 2004 163 [54] H. Westerheim, G.L. Hanssen, The Introduction and Use of a Tailored Unified Process: A Case Study, Euromicro 2005, Porto, Portugal, 2005 [55] Hanssen, G.K. and T.E. F?gri, Process Fusion - Agile Product Line Engineering: an Industrial Case Study. Journal of Systems and Software, 2007. [56] Harel, D., Lachover, H., Naamad, A. eta, STATEMATE: a working environment for the development of complex reactive systems. In: Proceedings of 10th lnternational Conference on Software Engineering, Singapore, 1988 [57] Harker, S., The use of prototyping and simulation in the development of large-scale applications. The Computer Journal, 31, 420425, 1988 [58] Herlea, D., Jonker, C.M, Treur, J., Wijngaards, N.J.E., A Case Study in RE: a Personal Internet Agent, Technical Report, Vrije Universiteit Amsterdam, Dept. of Artificial Intelligence. [59] Hickey A. M and Davis A. M. Requirements Elicitation and Elicitation Technique Selection: A Model for Two Knowledge-Intensive Software Development Processes, Proceedings of the 36th Annual Hawaii International Conference on System Sciences, 6-9 Jan. 2003, pp.: 96 -105, 2003 [60] Highsmith, J., Agile Software Development Ecosystems‖, Pearson Education, 2002 [61] Highsmith, J.A, A Collaborative Approach to Managing Complex Systems, New York: Dorset House, 2000 [62] Hoare C. A. R. The emperor's old clothes. Communications of the ACM, 24(2):75-83, Feb 1981 [63] Houdek, F.; Pohl, K.; Analyzing requirements engineering processes: a case study, Database and Expert Systems Applications, 2000. Proceedings. 11th International Workshop on 4-8 Sept. 2000 Page(s):983 – 987 [64] I. Jacobson, G. Booch, and J. Rumbaugh, The Unified Software Development Process, ed., A.W. Longman, 1999; p.416 [65] IEEE Standard Glossary of Software Engineering Terminology, IEEE std 610.12-1990, 1990. [66] IEEE Std. 830-1984, IEEE Guide to Requirements Specification, 1984 [67] Ivar Jacobson, Grady Booch, and Jim Rumbaugh, Unified Software Development Process, Addison-Wesley, 1999. [68] Jan Bosch, ―Software Product Families in Nokia‖, SPLC 2005, LNCS 3714, pp.2-6, 2005. [69] Janis A, Bubenko jr, Challenges in requirements engineering, Proceedings of the Second IEEE International Symposium on Requirements Engineering, 1995 [70] Joachim Bayer, Oliver Flege, Peter Knauber, Roland Laqua, Dirk Muthig, Klaus Schmid, and Tanya Widen. PuLSE: A Methodology to Develop Software Product Lines. Fraunhofer Institute for Experimental Software Engineering, Germany and Lucent Technologies Software Product Line Engineering Laboratories, U.S.A. May 1999. [71] K. Yamanishi and H. Li, Mining Open Answers in Questionnaire Data, IEEE Intelligent Systems, vol. 17, 2002, pp. 58 - 63.[92] [72] Karlsson, J. et al., An Evaluation of Methods for Prioritizing Requirements, Information and Software Technology 39 (14-15), pp. 939-947, 1998 [73] Kasanen E., Lukka K. & Siitonen A., The Constructive Approach in Management Accounting Research, Journal of Management Accounting Research, No. 5, pp.243-264, 1993 [74] Keil, M., P. E. Cule, K. Lyytinen and R. C. Schmidt (1998). "A Framework for Identifying Software Project Risks." Communications of the ACM 41(11): 76-83. [75] Kirby, M.A.R., Fowler, C.J.H. & Macaulay, L.A., Overcoming obstacles to the validation of user requirement specifications. In: People and Computers lV, Jones, D.M. and Winder, R. (eds), pp. 111-122, Cambridge University Press, Cambridge, 1988 [76] Klaus Pohl, ―Software product line engineering: foundations, principles, and techniques‖, Springer, 2005 [77] Klaus Schmid, A comprehensive product line scoping approach and its validation, International Conference on Software Engineering archive, Proceedings of the 24th International Conference on Software Engineering, pp. 593-603, 2002 [78] Koskinen, J.; Ahonen, J.J.; Sivula, H.; Tilus, T.; Lintinen, H.; Kankaanpaa, I.; Software Modernization Decision Criteria: An Empirical Study, Software Maintenance and Reengineering, 2005. CSMR 2005. Ninth European Conference on 21-23 March 2005 Page(s):324 – 331 [79] Kotonya, G. and Sommerville, I., Requirements Engineering – Processes and Techniques. John Wiley and Sons, Chichester, West Sussex, UK, 1998 [80] Lukka, K., The Constructive Research Approach. www.metodix.com. March, 2008. 164 [81] M. C. Paulk, B. Curtis, M. B. Chrissis, and C. V. Weber, Capability Maturity Model for Software, Version 1.1, CMU/SEI-93-TR-024, Software Engineering Institute, Carnegie Mellon University, 1993. [82] M. Hirsch, Making RUP Agile, Conference on Object Oriented Programming Systems Languages and Applications, OOPSLA 2002 Practitioners Reports, 2002 [83] M.C. Paulk, B. Curtis, M.B. Chrissis, et al, Capability Maturity Model for Software, Software Engineering Institute, CMU/SEI-91-TR-24, ADA240603, August 1991. [84] Macaulay, L., Requirements Engineering. Springer-Verlag Limited, London, 1996 [85] Mahmood Niazi, Muhammad Ali Babar; Motivators of Software Process Improvement: An Analysis of Vietnamese Practitioners‘ Views, 11th International Conference on Evaluation and Assessment in Software Engineering (EASE), 2007 [86] Manifesto for Agile Software Development, available at: http://www.agilemanifesto.org. [87] March, S. T. and G. F. Smith, "Design and Natural Science Research on Information Technology." Decision Support Systems 15(4): 251-266, 1995 [88] McChesney I. R., Toward a Classification Scheme for Software Process Modeling Approaches, Information and Software Technology, Vol. 37, No. 7, pp.363-374, 1995 [89] McConnell, S., Rapid Development. McConnell, S. Microsoft Press, Redmond, 1996 [90] McDermid, J., and P. Rook, Software Development Process Models, Software Engineer‘s Reference Book, CRC Press, 1993 [91] McPhee, C., Requirements Engineering for Projects with Critical Time-To-Market. M. Sc. thesis, University of Calgary, 2000 [92] Mishkoff, H., Understanding Artificial Intelligence‖, Howard W. Sams and Co., 1988. [93] Naur, P., and B. Randall, Software Engineering: A Report on a Conference Sponsored by the NATO Science Committer, NATO, 1969 [94] Newman, M. & Rosenberg, D., Systems analysts and the politics of organizational control, Omega, 1985 [95] Nikula U., Sajaniemi J. and Kalviainen H., A State-ofthe-Practice: Survey on RE in Small- and Medium-Sized Enterprises, Telecom Business Research Center, Lappeenranta Research Report, 2000 [96] Nosek, J.T. & Schwartz, R.B., User validation of information system requirements: some empirical results. IEEE Transactions on Software Engineering, 1988 [97] Open Source Technology Group, available at: http://sourceforge.net/ [98] Oppenheim, O.N., Questionnaire Design And Attitude Measurement. NewYork : Basic Books Inc, 1966. [99] Osterweil L. J., oftware Processes Are Software Too, International Conference on Software Engineering , Proceedings of the 9th International Conference on Software Engineering, Monterey, California, United States, pp. 2 – 13, 1987 [100] P. Brewerton, Organizational research methods. London: SAGE, 2001. [101] P. Harmon and D. King, Expert Systems. New York: John Wiley and Sons, 1985[122] [102] P. Kroll, P. Kruchten, The Rational Unified Process Made Easy: A Practitioner‘s Guide to the RUP, ed. O.T. Series. Addison Wesley, 2003; p.197-222[83] [103] P. Krutchen, The Rational Unified Process: An Introduction, 2nd ed.; Addison-Wesley, 2000; p.298[49] [104] Palmer, J. and Fields, N., "An Integrated Environment for Requirements Engineering," IEEE Software, vol 9 , issue 3, pp. 80-85, May 1992[131] [105] Palmer, S.R., and Felsing, J.M., A Practical Guide to Feature-Driven Development. Prentice Hall, 2002.[77] [106] Pecht, Michael., Product Reliability, Maintainability, and Supportability Handbook. CRC Press, 1995 [43] [107] Peter Jackson, Introduction to Expert Systems, Third Edition. Addison Wesley, 1998[123] [108] Pfeiffer, S. and Eberlein, A., RE for Dynamic Markets, in the Proceedings of the 6th IASTED International Conference, 2002, pp. 100-105.[158] [109] Pine, B. and Davis, S., Mass Customization: The New Frontier in Business Competition, Harvard Business School Press, April, 1999.[18] [110] Pohl, K., Assenova, P., Doemges, R., Johannesson, P., Maiden, N., Plihon, V. Schmitt, J. and Spanoudakis, G., ―Applying AI Techniques to Requirements Engineering: The NATURE Prototype‖, 165 [111] [112] [113] [114] [115] [116] [117] [118] [119] [120] [121] [122] [123] [124] [125] [126] [127] [128] [129] [130] [131] [132] [133] [134] [135] in Proceedings ICSE-Workshop on Research Issues in the Intersection Between Software Engineering and Artificial Intelligence, May 1994.[139] Pressman, R. S. Software Engineering: A Practitioner's Approach. Boston, McGraw-Hill, 2001 [2] Product Development Team, Capability Maturity Model Integration (CMMI), Version 1.1, Continuous Representation, CMU/SEI-2002-TR-011, Software Engineering Institute, Carnegie Mellon University, 2002.[118] Product Development Team, Capability Maturity Model Integration (CMMI), Version 1.1, Staged Representation, CMU/SEI-2002-TR-012, Software Engineering Institute, Carnegie Mellon University, 2002.[119] RUP,Unified Method Architecture Diagram [51] Ralyté, J. and Rolland, C., ―An Assembly Process Model for Method Engineering,‖ in Proceedings of The Third International Conference on Advanced Information Systems Engineering, 1991, pp. 267-283.[159] Regina, M.M Braga., Claudia,M.L.Werner., and Marta,Mattoso. Odyssey: A Reuse Environment based on Domain Models. Computer Science Department, Federal University of Rio de Janeiro, Brazil. 2001[75] Roger S. Pressman, Software Engineering: A Practitioner‘s Approach, McGraw-Hill, 2005[44] Royce W.W., Managing the Development of large Software Systems: Concepts and Techniques, Proceeding of the IEEE WESTCON, Los Angeles, California, 1970[47] Royce, W. W., Managing the Development of Large Software Systems. IEEE WESCON, IEEE Computer Society. pp. 1-9, 1970 [3] Rzepka, W., Sidoran, J., and White, J., ―Requirements engineering technologies at Rome Laboratory‖, in Proceedings of IEEE International Symposium on Requirements Engineering, 1993, pp. 15-18. [132] S. Bergstrom, L. Raberg, Adopting the Rational Unified Process, Addison-Wesley, 2004; p.165-182[82] S. W. Ambler, L. Constantine, The Unified Process Inception Phase: Best Practices for Implementing the UP, Lawrence, , 1999[86] S. W. Ambler, R. Jeffries, Agile Modeling: Effective Practices for Extreme Programming and the Unified Process, Wiley, 2002[87] Saaty, T., The Analytic Hierarchy Process. McGraw-Hill, New York, 1980[197] Sacha Martin, Aybüke Aurum, Ross Jeffery, Barbara Paech; Requirements Engineering Process Models in Practice, The Seventh Australian Workshop on Requirements Engineering, 2002[116] Saeki, M.; Reusing use case descriptions for requirements specification: towards use case patterns, Software Engineering Conference, 1999. (APSEC '99) Proceedings. Sixth Asia Pacific 7-10 Dec. 1999 Page(s):309 – 316[117] Salaway, G, An organizational learning approach to information systems development, MIS Quarterly, 1987[183] Salaway, G. (1987) An organizational learning approach to information systems development, MIS Quarterly, 1987[181] Schmitt, J., ―Product Modeling for Requirements Engineering Process Modeling‖, in the proceedings of the FIP WG 8.1 Conf. on Information Systems Development Process, Como, Italy, September 1993.[138] Schmitt, J., ―Product Modeling for Requirements Engineering Process Modeling‖, in the proceedings of the FIP WG 8.1 Conf. on Information Systems Development Process, Como, Italy, September 1993.[140] Schwaber, K., Scrum Development Process, OOPSLA‘95 Workshop on Business Object Design and Implementation. Springer-Verlag, 1995.[76] Sidoran, J.L.,"Advanced Requirements Engineering Workstation," in Proceedings of Fourth International Workshop on Rapid System Prototyping, 1993, pp.205-208[133] Software Engineering Institute Requirements Engineering Project, Requirements Engineering and Analysis Workshop Proceedings, Technical Report CMU/SEI-91-TR-30, Software Engineering Institute, Carnegie Mellon University, 1991[144] Sommerville I. and Sawyer P. Requirements Engineering: A Good Practice Guide, New York: Wiley, 1997[26] Sommerville I., Software engineering, Seven Edition, Addison-Wesley Publishers Limited, 2004[36] 166 [136] Sommerville, I., Software Process Models. ACM Computing Surveys, Vol. 28, No. 1, March 1996, pp. 269-271. ACM Press, New York, NY, 1996[62] [137] Southwell, K., James, K., Clarke, B.A., Andrews, B., Ashworth, C., Norris, M., and Patel, V. (Requirements Specification authoring team). Requirements Definition and Design. The STARTS Guide, Second Edition, Volume I. National Computing Centre, 177-313, Chapter 5, 1987.[145] [138] Southwell, K., James, K., Clarke, B.A., Andrews, B., Ashworth, C., Norris, M., and Patel, V. (Requirements Specification authoring team). Requirements Definition and Design. The STARTS Guide, Second Edition, Volume I. National Computing Centre, 1987.[59] [139] Standish Group. The Chaos Report, 1994, http://www.pm2go.com/sample_research/chaos_1994_1.php[57] [140] Stephen B., FAA Shifts Focus to Sealed-Back DSR, IEEE Software, March 1996, pp. 110, 1996[184] [141] Stuart Anderson, Massimo Felici, Requirements Engineering Questionnaire Version 1.0, The University of Edinburgh, 2001[112] [142] Succi,G. SENG609.08 Class notes on Sherlock: An Object Oriented Framework for Domain Analysis and Engineering. The University of Calgary, Canada. 1999.[74] [143] Sutcliffe, A., Galliers, J. and Minocha, S., "Human errors and system requirements," In Proceedings of IEEE International Symposium on Requirements Engineering 1999, June 1999 pp. 23-30[134] [144] Thanasankit, T. and Corbitt, B., Towards Understanding Managing RE- A case study of a Thai Software House, in the proceedings of the 10th Australian Conference on Information Systems.[156] [145] The Standish Group (1995). The CHAOS Report, The Standish Group. www.standishgroup.com. January 31, 2002.[9] [146] The Standish Group, CHAOS Chronicles II, The Standish Group, 2001[191] [147] Tian, K. and K. Cooper, Agile and Software Product Line Methods: Are They So Different?, in 1st International Workshop on Agile Product Line Engineering (APLE'06). 2006, IEEE Computer Society: Baltimore, Maryland, USA.[31] [148] Tsai, W. and Zualkernan, I., ―Expert System for Software Engineering,‖ in Proceedings of Computer Software and Applications Conference, 1988, pp. 496.[163] [149] Tseng, M.M., Jiao, J., Mass Customization in: Handbook of Industrial Engineering, Technology and Operation Management, Wiley, 2001, 3rd. edition.[19] [150] Van Lamsweerde, A. (2000). Formal Specification: A Roadmap. IN: Proceedings of the Conference on the Future of Software Engineering ICSE, June 4-11, Limerick, Ireland. ACM Digital Library, 2000[64] [151] Van der Linden, F., Schmid, K., and Rommes, E., Software Product Lines in Action: The Best Industrial Practice in Product Line Engineering, Springer Verlag, 2007.[20] [152] W. Zhang, T. Kunz, A Product Line Enhanced Unified Process, Proceedings of Workshop on Software Process Simulation and Modeling, Collocated with ICSE 2006, Lecture Notes in Computer Science (LNCS), Vol. 3966, 2006, Springer, p.142-149[91] [153] W.S. Humphrey, Characterizing the Software Process: A Maturity Framework, IEEE Software, vol. 5, 1988, pp. 73 - 79[100] [154] W.S. Humphrey, W.L. Sweet; A Method for Assessing the Software Engineering Capability of Contractors, Software Engineering Institute, Carnegie Mellon University, CMU/SEI-87-TR-23, ADA187320, September 1987.[101] [155] Warden, R., Software Reuse and Reverse Engineering in Practice. London, England: Chapman & Hall, 283–305, 1992[173] [156] Weiss, D. and Lai, C.T.R, Software Product-Line Engineering: A Family-Based Software Development Process, Addison Wesley, 1999.[21] [157] Wiegers, K., Karl Wiegers Describes 10 Requirements Traps to Avoid. Software Testing and Quality Engineering, Vol. 2, No. 1, 2000[196] [158] Wileden, J.C., This is IT, Proceedings of an lnternational Workshop on the Software Process and Software Environments, Cot0 de Caza, Trabuco Canyon, California, March 27-29, Wileden, J.C. and Dowson, M. (eds), 1985[174] [159] Wojcicki M, Strooper P.; A state-of-practice questionnaire on verification and validation for concurrent programs. Proceedings of the 4th International Workshop on Parallel and Distributed Systems: Testing and Debugging (PADTAD), Portland, 17 July 2006, pp 1–10[110] [160] Young R. R. The Requirements Engineering, Boston, Artech House, 2003[25] [161] Young R. R., The Requirements Engineering, Boston, Artech House, 2004[186] 167 [162] Yourdon, E. (1989). Modern Structured Analysis. Prentice Hall/Yourdon Press, Upper Saddle River, New Jersey, 1989[61] [163] Zave, P., Classification of Research Efforts in Requirements Engineering. ACM Computing Surveys, 29(4): 315-321, 1997[54] [164] Zualkernan, I., Tsai, W. and Volovik, D., ―Expert Systems and Software Engineering: Ready for Marriage?‖ IEEE Expert, vol.1, no.4,, pp. 24-31, 1986.[164] [165] Zubrow, Dave; Hayes, Will; Seigel, Jane; Goldenson, Dennis. Maturity Questionnaire. Software Engineering Institute, Carnegie Mellon University, CMU/SEI-94-SR-7, June 1994[105] [166] Zultner, R, Blitz QFD for Software: The Next Generation for Delivering Value. Tutorial held at the 6th International Conference on Software Quality in Ottawa, Ontario, Canada. October 28-30 ,1996[198] [167] http://www.agilealliance.com/[66] [168] http://www.eclipse.org/epf/general/OpenUP.pdf, 2007, The Eclipse Foundation[88] [169] ―Framework for Software Product Line Practice V4.2‖, Software Engineering Institute (SEI), http://www.sei.cmu.edu/, (May.12, 2006)[10] 168 Appendix A: Product Line Methods A.1 Use Case Model Approach Software modeling approaches are now widely used in software development. Hassan Gomaa proposed a multiple-view meta-modeling approach for software product lines using the Unified Modeling Language notation (UML). Using the UML notation, the functional requirements view is represented through a use case model. In contrast with single system that developers prepare all the use cases, product line modeling need to record the kernel use cases which all the family products require and alternative use cases. Kernel case uses represent the use cases which exist in all family products. Optional use cases represent some uses cases in a specify product. Alternative use cases represent those cases that are optional. Variation point can be represented by using extend or include in use case diagram. To describe a variation on behavior in a more controlled form, extend can be applied. The extend relationship models a variation of requirements through alternative paths that a base use case might take if appropriate conditions hold. The include link is to avoid repetition of scenarios in multiple use cases. The include relationship models the variation by reusing a common use case used by several other use cases [51]. In our example, manufactory can choose different lens to assemble a camera. As we discussed in section 1.2.2, different lens are the variation point. <> Assemble Camera Body <> <> Assemble Regular Lens <> Manufactory <> Assemble Lens <> Assemble Wide-angle Lens <> <> Assemble Flash <> Zoom Lens Figure 42. Use Case Model A.2 Feature Model Approach Another approach is to use features to identify requirement of product line. Don Batory proposed the tutorial about the feature models, grammars and propositional formulas [40]. A feature model is a hierarchically arranged set of features. It describes mandatory, alternative and optional features that have the relations between others. Mandatory features are required by all the product line families. Alternative features means only one subfeature can be selected. Optional features represent variability within a family that is optional in products. Feature models define features and their usage constraints in product-lines. Current methodologies organize features into a free, called a feature diagram, which is used to declaratively specify product-line members. Feature Oriented Domain Analysis (FODA) is a domain analysis and engineering technique, which focuses on developing reusable assets. FODA has three phases: Context Analysis, Domain Modeling and Architecture Modeling. In the Context Analysis phase, information required for various activities are gathered from various sources. In the Domain Modeling phase, product line requirements are analyzed using a set of domain models. Common and variable requirements are identified using a technique called Feature Modeling. Feature models consist of feature diagrams that represent features in a hierarchical structure. These requirements are further analyzed using several structured system analysis techniques such as data-flow diagrams, entity-relationship diagrams and functional diagrams. The end users and domain experts review these domain models. In the 169 Architecture Modeling phase, the domain models are used create an architecture model. The architecture model can be instantiated to develop individual applications. A.3 Product Line Scoping Approach Reusability of software has been and is an important goal of product line software engineering. By defining a reusable platform for all members of the family, a professional and planned way of software reuse is possible, based on domain analysis and other technologies. The scoping activity is important in product line planning phase because it is focus on the reusability. The functionality of the produce line that brings an optical return on investment is vital in the step of investment reuse. This is the key issue during the process of deriving value from the reuse chances. Some related work has been done by other researchers. Schmid‘s survey‘s on scoping in PLE [77] classifies three ways of scoping: Domain scoping is bounding the domains which are relevant. The goal of product portfolio scoping is to identify the specific products that should be developed in addition to the features they should provide. Although bad effects are caused by this during the actual reuse opportunities, it is normally considered according to marketing aspects. Thus, it will be more accurate to classify it as a topic of marketing science than as a software engineering topic. The goal of asset scoping is to identify the particular components developed in a reusable way. A.4 Product-Line Requirements Specification (PRS) Product line requirements specification approach focuses on methods and techniques for creating a new kind of work product. Prior work suggests that two kinds of requirements documents are potentially useful in product line engineering: a product line requirements specification (PRS) and a software requirements specification (SRS).Where an SRS describes the requirements for a single family member, the PRS specifies the requirements for a program family Error! Reference source not found.[38]. A.5 KobrA KobrA (Component-based Application Development) [8] is a software process and product- centric engineering approach. KobrA uses a component-based approach in each phase of the development process, it uses UML as the modelization language, and it exploits a product line approach during components development and deployment. A KobrA component (called Komponent) is a software module which provides or requires services to/from other komponents, in a client-server fashion. Komponents are high-level components (not just binary code), modeled using different correlated UML models. Komponents modelization is based on four basic concepts: Uniformity: each entity, with its own behavior, is a komponent. Any komponent is modeled following the same rules, and using the same modeling artifacts. The resulting model is architecture-centric and each element in the architecture is component centric. Encapsulation: komponents are modeled, following a Model Driven Architecture (MDA) approach, making a clear distinction between ―Specification‖ (what a component is supposed to do) and ―Realization‖ (how a component implements the specification). Both specification and realization are modeled through UML diagrams and textual notations. A ―Specification‖ is composed of a structural, behavioral, functional and decision models. A ―Realization‖ contains a structural, activity, interaction and decision models. In the following, we will keep the distinction between Specification and Realization. Locality: KobrA systems are a collection of komponents. Each komponent is modeled through different artifacts. Each artifact models only information local to its komponent. A global view of the system is not provided. Parsimony: Each artifact has to contain no more than ―enough‖ information, providing only necessary information and reducing as much as possible verbosity. Constrains and well-formedness rules are used to enforce this property. KobrA is product-line centric since it implements a product-line philosophy. It identifies commonalities and variability in a specific application domain and creates a reusable software infrastructure (or framework) which may be instantiated to identify the specific products. KobrA implements the PuLSE approach specifying and realizing common and variant features through komponents. A KobrA framework is a collection of komponents 170 organized in a hierarchical three structure. Each artifact, modeling a KobrA variant component, contains a ―decision‖ which allows resolving the component variability. A ―Decision model‖ collects the different decisions related to each komponent. During the ―Application Engineering‖ phase, products are identified by instantiating the product-line framework, making use of the Decision model. During the ―Komponent embodiment‖ phase, UML logical models are elaborated to produce executable code. Figure 43. KobrA A.5 FAST FAST is a systematic process for developing a set of systems, which share a majority of common features. FAST has two major sub-processes: Domain Engineering and Application Engineering. In the Domain Engineering sub-process, requirements for the product family are defined and the reusable assets required for building the family members are developed. In the Application Engineering sub-process, the individual members are developed using the reusable assets according to the specification. In FAST common and variable requirements for the family are defined and analyzed using a process called ―Commonality Analysis‖. This process is a structured group discussion between several domain experts. The main purpose is to elicit product family requirements and to document them. These requirements are then specified using a domain specification language so that a translator can automatically translate these domain specifications into individual products. FAST is well suited to develop applications quickly. It includes several activities that are equivalent to requirements engineering activities. The requirements elicitation and analysis process in FAST is called Commonality Analysis where a group of domain experts gather and analyze family requirements. Commonality Analysis is a good process for gathering information about the domain since it involves a structured discussion between domain experts and requirements engineers. However, it does not recommend any specific technique for capturing, analyzing and characterizing the family. FAST uses certain domain specification languages to represent domain work products. Requirements can also be represented using the same specification language. Since FAST uses a translator, which automatically generates individual applications, there will be a drastic reduction in the time required for development and testing. However, since requirements are specified using custom domain specification languages, other organizations may have difficulties in adopting them. For system specifications to be translated automatically, they must be precisely defined and specified. If there is a change or error in the requirements, specifications have to be modified and the translation needs to be altered. Tool support is provided for several activities. Very little attention is given to requirements management and traceability. If the family requirements are properly identified and characterized through the Commonality Analysis process, FAST can develop applications very quickly. 171 A.6 PuLSE Product Line Software Engineering (PuLSE) is a customizable product line practice [70]. PuLSE can be applied to a variety of enterprise contexts through customizability of components, incremental introduction capability and a maturity scale for structured evolution. A PuLSE process has three basic elements: Deployment Phases, Technical Components and Support Components. Deployment Phases are logical steps in the PuLSE practice that describe the activities needed to define and develop a family of products. These activities are categorized under three stages namely PuLSE Initialization, PuLSE Infrastructure Construction and PuLSE Infrastructure Usage. In the PuLSE Initialization stage a PuLSE process that is suitable for the current domain and organizational context is defined. In the PuLSE Infrastructure Construction stage, the product line characteristics are defined, modeled and a reusable architecture is developed. In the PuLSE Infrastructure Usage, the product line architecture is instantiated to develop individual applications. PuLSE technical components include the technical expertise required to carry out various PuLSE activities. PuLSE support components provide the guidelines required to solve any non-technical issue such as organization issue, project entry points and process evolution. KobrA is an object-oriented customization of PuLSE. However, KobrA focuses more on the design and implementation of a domain framework. Similar to Synthesis, PuLSE provides a framework for product line development. Although it proposes several distinctive stages for product line development, it does not have a systematic process for requirements engineering. It allows the organizations to decide on the tools and techniques required for each activity. However, it uses a technique called Product Map for product line scoping and characterization. A Product Map is a technique that maps the product line features with member products in the form of a matrix. Using the subjective evaluation on the importance and market benefit, certain characteristic and benefit functions are calculated. These functions are then evaluated to choose the product line requirements and member products. Product Maps are a good technique that can be used to identify product line features and potential members. PuLSE provides very little information about requirements specification, verification and traceability. A.7 Sherlock Sherlock is an object-oriented domain analysis and engineering practice [74]. In Sherlock a domain framework is developed using five basic steps. They are Domain Definition, Domain Characterization, Domain Scoping, Domain Modeling and Domain Framework Development. During Domain Definition, Domain Characterization and Domain Scoping information from various sources are gathered, commonalities and variabilities are defined and individual family members are identified. In the Domain Modeling step, requirements for each of the family members and the common requirements are analyzed using various object-oriented models. In the Domain Framework Development stage a domain framework is developed using several process models and architectural models. Sherlock has several activities that are required for product line requirements engineering. The Domain Definition stage is equivalent to requirements capturing where requirements are gathered from domain experts, market analysis and other sources. Market analysis is a very good technique for identifying the current and future market trends because, this will have a great influence on the features and products selection in the family. It does not use any specific technique for identifying common and variable requirements. Product line requirements and potential member products are chosen according to the organizational strategies. Once the products and requirements are identified, they are analyzed using object-oriented analysis techniques. Sherlock provides tool support for managing each activity. There is no specific technique used for requirements specification, verification and traceability. A.8 Odyssey Odyssey domain engineering is an object-oriented domain analysis and engineering technique that uses component-based software development techniques [75]. Odyssey DE has four development phases. They are Domain Viability Analysis, Domain Analysis, Domain Design and Domain Implementation. In the Domain Viability Analysis, the feasibility and the cost-benefit analysis of the current domain is performed. In the Domain Analysis phase, the product family is characterized and the scope is determined. In the Domain Design and Domain Implementation phases, the product family architecture is designed and implemented. An aspect unique to Odyssey DE is that various components in the domain interact through Common Object Request Broker (CORBA) protocol. In this way any legacy domain model or component residing in a distant environment can be easily integrated. Odyssey-DE has several activities that are equivalent to activities in requirements engineering. The feasibility 172 analysis, requirements capturing and requirements analysis are performed in the Domain Viability Analysis and Domain Analysis phases. However, it does not provide any technique for performing the feasibility analysis. It uses FODA‘s feature modeling technique for identifying the common and variable requirements. It does not use any technique for the selection of potential members and their features. Requirements are modeled using object-oriented techniques such as use case diagrams and class diagrams. Odyssey-DE uses certain design patterns (structured templates) to specify domain concepts. It also provides a traceability mechanism between requirements and other work products using tool support. However, the technique used for this is not mentioned. 173 Appendix B: Agile Methods B.1 Extreme Programming Extreme Programming (XP) is a software engineering methodology, the most prominent of several agile software development methodologies. Like other agile methodologies, Extreme Programming differs from traditional methodologies primarily in placing a higher value on adaptability than on predictability. Proponents of XP view requirements change as a constant in software development projects, and believe that being able to adapt to changing requirements at any point during the project life is a more realistic and better approach than attempting to define all requirements at the beginning of a project and then expending effort to control changes to the requirements. XP prescribes a set of day-to-day practices for managers and developers; the practices are meant to embody and encourage particular values. Proponents believe that the exercise of these practices—which are traditional software engineering best practices taken to so-called "extreme" levels—leads to a development process that is more responsive to customer needs ("agile") than traditional methods, while creating software of similar or better quality [3]. Extreme Programming Explained describes Extreme Programming as being: An attempt to reconcile humanity and productivity A mechanism for social change A path to improvement A style of development A software development discipline The main aim of XP is to lower the cost of change. In traditional system development methods (like SSADM) the requirements for the system are determined at the beginning of the development project and often fixed from that point on. This means that the cost of changing the requirements at a later stage (a common feature of software engineering projects) will be high. XP sets out to lower the cost of change by introducing basic values, principles and practices. By applying XP, a system development project should be more flexible with respect to changes. Extreme Programming initially recognized four values. A new value was added in the second edition of Extreme Programming Explained. The five values are: Communication Simplicity Feedback Courage Respect Building software systems requires communicating system requirements to the developers of the system. In formal software development methodologies, this task is accomplished through documentation. Extreme Programming techniques can be viewed as methods for rapidly building and disseminating institutional knowledge among members of a development team. The goal is to give all developers a shared view of the system which matches the view held by the users of the system. To this end, Extreme Programming favors simple designs, common metaphors, collaboration of users and programmers, frequent verbal communication, and feedback. Extreme Programming encourages starting with the simplest solution and refactoring to better ones. The difference between this approach and more conventional system development methods is the focus on designing and coding for the needs of today instead of those of tomorrow, next week, or next month. Proponents of XP acknowledge the disadvantage that this can sometimes entail more effort tomorrow to change the system; their claim is that this is more than compensated for by the advantage of not investing in possible future requirements that might change before they become relevant. Coding and designing for uncertain future requirements implies the risk of spending resources on something that might not be needed. Related to the "communication" value, simplicity in design and coding should improve the (quality of) communication. A simple design with very 174 simple code could be easily understood by most programmers in the team. Within Extreme Programming, feedback relates to different dimensions of the system development: Feedback from the system: by writing unit tests, or running periodic integration tests, the programmers have direct feedback from the state of the system after implementing changes. Feedback from the customer: The functional tests (aka acceptance tests) are written by the customer and the testers. They will get concrete feedback about the current state of their system. This review is planned once in every two or three weeks so the customer can easily steer the development. Feedback from the team: When customers come up with new requirements in the planning game the team directly gives an estimation of the time that it will take to implement. Several practices embody courage. One is the commandment to always design and code for today and not for tomorrow. This is an effort to avoid getting bogged down in design and requiring a lot of effort to implement anything else. Courage enables developers to feel comfortable with refactoring their code when necessary. This means reviewing the existing system and modifying it so that future changes can be implemented more easily. Another example of courage is knowing when to throw code away: courage to remove source code that is obsolete, no matter how much effort was used to create that source code. Also, courage means persistence: A programmer might be stuck on a complex problem for an entire day, then solve the problem quickly the next day, if only he or she is persistent. The respect value manifests in several ways. In Extreme Programming, team members respect each other because programmers should never commit changes that break compilation, that make existing unit-tests fail, or that otherwise delay the work of their peers. Members respect their work by always striving for high quality and seeking for the best design for the solution at hand through refactoring. B.2 Scrum The Scrum is an empirical approach applying the idea of industrial process control theory to software development by reinforcing flexibility, adaptability and productivity [76]. Scrum concentrates how the team members should function in order to produce system flexibility in a constant changing environment. A Scrum project starts with customer vision. As the project goes on, the vision becomes more and more clear. A principle behind Scrum believes that thorough documentation doesn‘t necessarily mean that the documented concept is fully understood. It is the conversation between the user and the developers that guarantee the understanding of the story. Hence, Scrum rather promotes high-level requirement specification and leaves the details to be covered later during the conversation. Consequently, requirement specification in Scrum is done by using Story Cards like in XP, and it can be seen that the requirement elicitation technique in Scrum is done by a group session involving user and developers. Like many other Agile Methods, user acceptance test validated the developed story, in other words, requirement validation is done by using user review. Scrum doesn‘t give out a specific technique for requirement analysis. Since bare-enough requirements are elicited in the beginning of the Scrum project and more others are added during the development, we can think that the possible technique of requirement analysis in Scrum shall be expert review. Scrum also doesn‘t have the concept of requirement traceability. That is because the ideology behind Scrum thinks that the requirements not only change during the development, they also evolve. It doesn‘t matter to the Scrum team if the requirements are complete or not due to the philosophy behind Scrum that the true driver of a project is business value or return of investment, not the completeness of the requirements. The failure to implement some of the requirements may simply reflect their diminishing business values. However, they do keep the requirements information up-to-date (contents, prioritization, etc) by holding a daily Scrum meeting. B.3 Feature Driven Development Feature Driven Development (FDD) [77] is an iterative and incremental software development process. It is one of a number of Agile methods for developing software and forms part of the Agile Alliance. FDD blends a number of industry-recognized best practices into a cohesive whole. These practices are all driven from a client-valued functionality (feature) perspective. Its main purpose is to deliver tangible, working software repeatedly in a timely manner. 175 FDD describes five basic activities that are performed within the software development process. In the figure the meta-process model for these activities is displayed. During the first three sequential activities an overall model shape is established. The final two activities are iterated for each feature. Figure 44. Feature Driven Development 176 B.4 Crystal Clear Crystal Clear [35] is a member of the Crystal family of methodologies as described by Alistair Cockburn and is considered an example of a lightweight methodology. Crystal Clear can be applied to teams of up to 6 or 8 collocated developers working on systems that are not life-critical. The Crystal family of methodologies focuses on efficiency and habitability as components of project safety. Crystal Clear focuses on people, not processes or artifacts. Crystal Clear contains the following properties (the first three are required): Frequent Delivery of Usable Code to Users (required) Reflective Improvement (required) Osmotic Communication Preferably by Being Co-Located (required) Personal Safety Focus Easy Access to Expert Users Automated Tests, Configuration Management, and Frequent Integration B.5 Dynamic Systems Development Method Dynamic Systems Development Method (DSDM) provides a framework for rapid application development [33]. The first two phases of DSDM are the feasibility study and the business study. During these two phases the base requirements are elicited. Further requirements are elicited during the development process. DSDM does not insist on certain techniques. Thus, any RE technique can be used during the development process. In DSDM, testing is integrated throughout the lifecycle. The philosophy of DSDM is ‗test as you go‘ [33]. All sorts of testing (technical, functional) are carried out incrementally by the developer and the users on the team. DSDM explicitly highlights the use of JAD sessions and emphasizes prototyping [33]. B.6 Adaptive Software Development Adaptive Software Development is a software development process that grew out of rapid application development work by Jim Highsmith and Sam Bayer. ASD embodies the principle that continuous adaptation of the process to the work at hand is the normal state of affairs. ASD replaces the traditional waterfall cycle with a repeating series of speculate, collaborate, and learn cycles. This dynamic cycle provides for continuous learning and adaptation to the emergent state of the project. The characteristics of an ASD life cycle are that it is mission focused, feature based, iterative, timeboxed, risk driven, and change tolerant. The word ―speculate‖ refers to the paradox of planning – it is more likely to assume that all stakeholders are comparably wrong for certain aspects of the project‘s mission, while trying to define it. Collaboration refers to the efforts for balancing the work based on predictable parts of the environment (planning and guiding them) and adapting to the uncertain surrounding mix of changes caused by various factors – technology, requirements, stakeholders, software vendors, etc. The learning cycles, challenging all stakeholders, are based on the short iterations with design, build and testing. During these iterations the knowledge is gathered by making small mistakes based on false assumptions and correcting those mistakes, thus leading to greater experience and eventually mastery in the problem domain [80]. 177 Appendix C: Constructive Research Approach This APLE-RE research follows a constructive research approach. The reason for selecting a constructive approach is due to an interest in doing practically relevant research and a constructive approach suits that task well [80]. The desire for practically oriented work, on the other hand, follows from the fact that despite all the research up to date RE still appears problematic for practitioners. A new method addressing the obstacles in introducing RE into practice should help solve this problem. In this section the central elements of constructive research will be presented and it is shown how our case fits to this research setting. Next a look at a typical constructive research process will be done and its relevance to the research of this thesis will be considered. Constructive research is built on both existing theory in the research area and on the practical relevance of the problem and the solution as the ovals on the left in Figure 1 show. In the case of this thesis the prior theory refers to the research results from previous studies (see Sections 2.3 Basic Concepts, 2.4 Related Research Areas, and 2.6 Related Methods). The practical relevance, on the other hand, refers both to the lack of decent RE in software projects (cf. Section 2.2 State of the Practice in Requirements Engineering) and the consequences of it (cf. Section 2.1 Software Projects and Requirements). Figure 45. The central elements of the constructive research approach The expected results of constructive research are shown on the right of Figure 13 and include the practical functioning of the solution and theoretical contribution of the study. This licentiate thesis is targeted only on the theoretical contribution which is to show that it is possible to construct a ready to use method for RE and that the use of such a method should prove beneficial for the adopters. The practical evaluation or value of the method is deferred to the next phase of this study where the case studies are run to test the functioning of the method in practice. That is, constructive research is approached as a design science with building and evaluation phases [87] and the goal for this thesis is to construct the artifact of interest to us – the RE method. Once the method is constructed the evaluation phase will start with industrial case studies to determine its practical value to the practitioners [87]. A typical process for constructive research with seven steps is presented in Figure 14. Notice that this thesis covers only the first four steps in full and the implementation part of the fifth step; testing the solution in practice, pondering the scope of applicability, and identification and analysis of the theoretical contribution are left for the next phase of this study. 178 Figure 46. A Typical Constructive Research Process The first step of finding a practically relevant problem was actually done separately from this project since the problems in RE for this thesis were discovered in the practical work. However, both the existence of the problem and its relevance were verified from literature surveys and a local state-of-the-practice survey was conducted to confirm that the literature findings match the local situation. In APLE-RE research, relevant problem is discussed in Section 1.2. The second step of studying the possibilities for research co-operation covered both academic and industrial partners. On the academic side conferences are attended in order to meet other researchers interested in these issues. However, despite a lot of interest in this area, few real research efforts are active and especially in the relevant interest area no comparable efforts are found. On the industrial side the actual co-operation is postponed to the evaluation phase since the goal was to develop a method that is easy to adopt in different organizations. The third step of obtaining a deep understanding of the topic area has taken most of the time so far. The reason is that the existing body of knowledge in RE is so extensive that the field is not easy to enter as a researcher. And since the goal is to develop a method from existing methods, techniques, tools, and templates obtaining a deep understanding of the topic area is necessary before going any further. The APLE-RE Questionnaire is developed to acquire knowledge from experts actively involved in software development using agile, product line RE techniques. The APLE Techniques review most of the Agile and Product Line requirement techniques, and it can be seemed as the foundation for RE process development. It includes RE process knowledge with the aim to help the RE process developers. The fourth step of innovating a solution idea and developing a problem solving construction has been present during work all the time due to the adoption of the parallel specification and implementation approach. APLE-RE Process Repository is developed. It contains several APLE-RE Process Templates. Each template presents a level of agility applying in a single or product line product. The fifth step of implementing and testing the construct is limited in this case to method construction and documentation. The steps six and seven – pondering the scope of applicability of the solution and identifying and analyzing the theoretical contribution – are already under constant contemplation but the final position can be taken only after the case studies in the evaluation phase. In Chapter 8, two validation approaches are presented, as well as the contribution and future work. 179