A Review on Requirement Engineering for Software Product Lines Danuza F. S. Neiva

Agenda Software Product Line Requirement Engineering SPL Approaches RE Methods for SPL Conclusion

Software Product Line (SPL)‏ A SPL is a set of software-intensive systems that share a common, managed set of features satisfying 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. (Clements & Northrop, 2001)‏

Software Product Line (SPL)‏ Essential Activities for Software Product Lines (Clements & Northrop, 2001)‏

Software Product Line (SPL)‏ Sub-processes for Software Product Lines (Pohl et al., 2005)‏ Core Asset Development Product Development

Software Product Line (SPL)‏ Motivation Reduction of Costs Enhancement of Quality Reduction of Time to Market (Pohl et al., 2005)‏

Requirement Engineering (RE)‏ It requires significant effort in a project. “Software requirements have been repeatedly recognized during the past 25 years to be a real problem.” (Lamsweerde, 2000)‏ “Incomplete and inconsistent requirements are some of the great factors for deficiency and cancellation of software projects.” (Chaos Report, 1994)‏

Requirement Engineering (RE)‏ In SPL is more complex: several stakeholders more products requiring attentions to variability and reuse platform Practices Risks scope includes the wrong products essential stakeholders don't participate. wrong or inappropriate requirements inadequate domain undestanding (Clements & Northrop, 2001; Birk et al., 2003 )‏

Requirement Engineering (RE)‏ Essential Activities Elicitation Analysis and Negotiation Specification Validation Management (Kotonya & Sommerville, 1998)‏ How are these activities in SPL?

Requirement Engineering (RE)‏ Elicitation focus in scoping; must capture anticipated variations explicitly over the foreseeable lifetime of the SPL; involve more stakeholders. (Clements & Northrop, 2001; Durán et al., 2003; Pohl et al., 2005)‏

Requirement Engineering (RE)‏ Analysis and Negotiation find variations and commonalities; analyze impact of new requirements in product line architecture; identify opportunity for reuse; conflicts must be solved not only from a logical view point, but also taking into consideration economical and market issues. (Clements & Northrop, 2001; Durán et al., 2003; Pohl et al., 2005)‏

Requirement Engineering (RE)‏ Specification must document a product-line-wide set of requirements and product-specific requirements (Clements & Northrop, 2001; Pohl et al., 2005)‏

Requirement Engineering (RE)‏ Validation must check the consistency, completeness and accuracy of the common and variable requirements. (Clements & Northrop, 2001; Pohl et al., 2005)‏

Requirement Engineering (RE)‏ Management support the systematic assessment of how the proposed changes will impact the product line; traceability links between requirements and their associated core assets. (Clements & Northrop, 2001)‏

Requirement Engineering (RE)‏ Different SPL situations that influence the RE: Starting situations Market orientation Product type Domain maturity Domain stability SPL Architecture Organizational size (Birk et al, 2003)‏

SPL Approaches Review - Research questions Q1.What activities, techniques and methods of requirement engineering are adopted in each software product line approach? Q2. Does the approach have a technology and/or socio-organizational viewpoint?

SPL Approaches Review - Selected approaches: FODA (1990) [Kang et al., 1990] FAST (1997) [Gupta et al., 1997; Weiss, 1997] FORM (1998) [Kang et al., 1998] PULSE (1999) [Bayer et al., 1999; Bayer et al., 2000; John et al., 2006] SEI’s Framework (1999) [Clements & Northrop, 2001; ODYSSEY (1999) [Braga et al., 1999] COPAM (2000) [America et al., 2000] Kobra (2002) [Atkinson et al., 2000] PLUS (2005) [Gomma, 2005] SPLE Framework (2005) [Pohl et al., 2005] RiDE (2007) [Almeida, 2007]

SPL Approaches Elicitation

SPL Approaches Analysis and Negotiation

SPL Approaches Specification

SPL Approaches Validation and Management

SPL Approaches RE essential activities summary

SPL Approaches Approaches viewpoints

RE Methods for SPL Viewpoint-based Goal-based Scenario and goal-based Feature-oriented Use case-based Orthogonal variability

RE Methods for SPL Viewpoint-based Viewpoints are an explicit mechanism which takes into account the different system and problem perspectives of different stakeholders. (Kotonya & Sommerville, 1998)‏

RE Methods for SPL Viewpoint-based Product Line Stakeholder Viewpoint Approach Stakeholders views Management View Reuse Team View Products developers View Viewpoints' Development Process Viewpoint Identtfication Viewpoint Structuring Viewpoints Documentation (Jaber et al., 2000)‏

RE Methods for SPL Viewpoint-based Viewpoint-Oriented Domain Requirements Definition (VODRD)‏ (Mannion et al., 1998)‏ (Jaber et al., 2000)‏

RE Methods for SPL Goal-based The goal means the direction, purpose, and objective of the organization. (Kim et al., 2006)‏

RE Methods for SPL Goal-based Goal-based Variability Acquisition and Analysis (Liaskos et al., 2006)‏

RE Methods for SPL Goal-based Goal-based Variability Acquisition and Analysis (Liaskos et al., 2006)‏ Variability example

RE Methods for SPL Scenario and goal-based Scenarios show the behavior of system. (Kim et al., 2006)‏ (Liaskos et al., 2006)‏

RE Methods for SPL Goal and Scenario Modeling (Kim et al., 2006)‏ Scenario and goal-based

RE Methods for SPL Goal and Scenario Modeling (Kim et al., 2006)‏ The relationship between goal, scenario and use case. Scenario and goal-based The structure of goal and scenario modeling process.

RE Methods for SPL Features are the attributes of a system that directly affect end-users. (Kang et al., 1990)‏ Feature-oriented

RE Methods for SPL Feature-oriented Feature-Oriented Domain Analysis (FODA) (Kang et al., 1990)‏

RE Methods for SPL Feature-oriented Feature-Oriented Reuse Method (FORM) (Kang et al., 1990)‏

RE Methods for SPL Use case-based Product Line UML-Based Software Engineering (PLUS)‏ Reuse Category: optional, mandatory (kernel), alternative Variation point (small variation)‏ Name Type of functionality (optional, mandatory alternative, optional alternative)‏ Line number(s) Description of functionality. Extend and Include Relationship (several variability)‏ (Gomma, 2005)‏

RE Methods for SPL Use case-based Product Line UML-Based Software Engineering (PLUS)‏ (Gomma, 2005)‏

RE Methods for SPL Use case-based PuLSE CaVE (Commonality and Variability Elicitation)‏ (Fantechi et al, 2003)‏

RE Methods for SPL Use case-based PuLSE CaVE (Commonality and Variability Elicitation)‏ (Fantechi et al, 2003)‏

RE Methods for SPL Orthogonal variability (Pohl et al., 2005)‏

RE Methods for SPL Orthogonal variability (Pohl et al., 2005)‏

Conclusion The RE process is not well defined in the found approaches Requirements analysis was the activity best defined in these studies. Several gaps in definition of guidelines for capturing of requirements. Requirement management is the more critical. Multiple viewpoints is, in general, overlooked. Due to the complex and evolutionary nature of SPL development, it is essential to have a systematic requirements engineering process.

Conclusion Methods with abstraction high-level feature-oriented and goal-based Integration of methods to represent different viewpoints. Selection of methods depends of the SPL context

References Clements, P. & Northrop, L., 2001, Software Product Lines: Practices and Patterns, Addison-Wesley. Pohl, K.; Böckle, G. & van der Linden, 2005, Software Product Line Engineering: Foundations, Principles, and Techniques, Springer. van Lamsweerde, A., 2000, Requirements engineering in the year 00: a research perspective, in 'International Conference on Software Engineering', pp Chaos Report Software Development Report, The Standish Group, West Yarmouth, MA, access in Birk, A.; Heller, G.; John, I.; Joos, S.; Müller, K.; Schmid, K. & Maßen, T. v. d., 2003,'Report of the GI Work Group "Requirements Engineering for Product Lines"', Technical report, Fraunhofer EPrints [ (Germany). Kitchenham, B., 2004, "Procedures for Performing Systematic Reviews," Joint Technical Report, Keele University TR/SE-0401 and ICTA T.1. Kang, K. C.; Cohen, S. G.; Hess, J. A.; Novak, W. E. & Peterson, A. S. (1990),'Feature-Oriented Domain Analysis (FODA) Feasibility Study', Technical report, Carnegie-Mellon University Software Engineering Institute. Gupta, N. K.; Jagadeesan, L. J.; Koutsofios, E. E. & Weiss, D. M. (1997),Auditdraw: Generating Audits the FAST Way, in 'RE '97: Proceedings of the 3rd IEEE International Symposium on Requirements Engineering (RE'97)', IEEE Computer Society, Washington, DC, USA, pp Weiss, D. (1997),'Defining Families: The Commonality Analysis', submitted to IEEE Transactions on Software Engineering. Kang, K. C.; Kim, S.; Lee, J.; Kim, K.; Shin, E. & Huh, M. (1998),FORM: A feature-oriented reuse method with domain-specific reference architectures, in, J. C. Baltzer AG, Science Publishers, Red Bank, NJ, USA, pp

References Bayer, J.; Flege, O.; Knauber, P.; Laqua, R.; Muthig, D.; Schmid, K.; Widen, T. & DeBaud, J. (1999),PuLSE: A Methodology to Develop Software Product Lines, in 'ACM SIGSOFT Symposium o Software Reusability (SSR'99)', pp Bayer, J.; Muthig, D. & Widen, T. (2000),Customizable Domain Analysis, in 'Proceedings of the First International Symposium on Generative and Component-Based Software Engineering (GCSE '99)', Springer-Verlag, London, UK, pp Fantechi, A.; Gnesi, S.; John, I.; Lami, G. & Dörr, J. (2003),Elicitation of Use Cases for Product Lines, in 'Software Product-Family Engineering, 5th International Workshop, PFE 2003, Siena, Italy', pp John, I.; Knodel, J.; Lehner, T. & Muthig., D. (2006),A Practical Guide to Product Line Scoping, in, pp Braga, R. M. M.; Werner, C. M. L. & Mattoso, M. (1999),Odyssey: A Reuse Environment based on Domain Models, in 'ASSET '99: Proceedings of the 1999 IEEE Symposium on Application - Specific Systems and Software Engineering and Technology', IEEE Computer Society, Washington, DC, USA, pp. 50. America, P.; Obbink, J. H.; van Ommering, R. C. & van der Linden, F. (2000),CoPAM: A component- oriented platform architecting method family for product family engineering, in 'SPLC', pp Atkinson, C.; Bayer, J.; Bunse, C.; Kamsties, E.; Laitenberger, O.; Laqua, R.; Muthig, D.; Paech, B.; Wüst, J. & Zettel, J., Component-based product line engineering with UML, Addison-Wesley, Boston, MA, USA, Gomaa, H., Designing Software Product Lines with UML: From Use Cases to Pattern-Based Software Architectures, Addison-Wesley, Almeida, E. S. RiDE: The RiSE Process for Domain Engineering, Ph.D. Thesis, Federal University of Pernambuco, Recife, Pernambuco, Brazil, May, 2007.

References Kotonya, G. & Sommerville, I. (1998), Requirements Engineering: Processes and Techniques, John Wiley & Sons, Inc. New York, NY, USA. Durán, A.; Benavides, D. & Bermejo, J. (2003), Applying System Families Concepts to Requirements Engineering Process Definition, in 'PFE', pp Jaber, K.; Nada, N. & Rine, D. (2000), Product line stakeholder viewpoint approach and validation model, in 'SAC '00: Proceedings of the 2000 ACM symposium on Applied computing', ACM, New York, NY, USA, pp Mannion, M.; Keepence, B. & Harper, D. (1998),Using Viewpoints to Define Domain Requirements, IEEE Computer Society Press, Los Alamitos, CA, USA, pp Liaskos, S.; Lapouchnian, A.; Yu, Y.; Yu, E. & Mylopoulos, J. (2006),On Goal-based Variability Acquisition and Analysis, in 'RE '06: Proceedings of the 14th IEEE International Requirements Engineering Conference (RE'06)', IEEE Computer Society, Washington, DC, USA, pp Kim, J.; Kim, M. & Park, S. (2006),Goal and scenario based domain requirements analysis environment, Elsevier Science Inc., New York, NY, USA, pp