A Review on Requirement Engineering for Software Product Lines Danuza F. S. Neiva [email protected].

A Review on Requirement Engineering for Software Product Lines

Danuza F. S. Neiva

[email protected]

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)


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


Sub-processes for Software Product Lines (Pohl et al., 2005)

Core Asset Development

Product Development


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)


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)


Essential Activities Elicitation Analysis and Negotiation Specification Validation Management

(Kotonya & Sommerville, 1998)

How are these activities in SPL?


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)


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)


Specification must document a product-line-wide set of

requirements and product-specific requirements

(Clements & Northrop, 2001; Pohl et al., 2005)


Validation must check the consistency, completeness and

accuracy of the common and variable requirements.

(Clements & Northrop, 2001; Pohl et al., 2005)


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)


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 ApproachesReview - 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; http://www.sei.cmu.edu] 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 ApproachesAnalysis and Negotiation

SPL Approaches

Specification

SPL Approaches

Validation and Management

SPL Approaches

RE essential activities summary

0%

20%

40%

60%

80%

100%

Elicitation Analysis Specification Validation ManagementNo definedDefinedPartially defined

SPL Approaches

Approaches viewpoints

Approaches' Viewpoint

1

10

0

Both

Technology

Socio-organizational

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

RE Methods for SPLViewpoint-based

Viewpoints are an explicit mechanism which takes into account the different system and problem perspectives of different stakeholders.

(Kotonya & Sommerville, 1998)


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)



Viewpoint-Oriented Domain Requirements Definition (VODRD)

(Mannion et al., 1998)


RE Methods for SPLGoal-based

The goal means the direction, purpose, and objective of the organization. (Kim et al., 2006)


Goal-based Variability Acquisition and Analysis

(Liaskos et al., 2006)


Goal-based Variability Acquisition and Analysis


Variability example

RE Methods for SPLScenario and goal-based

Scenarios show the behavior of system.(Kim 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 SPLFeature-orientedFeature-Oriented Domain Analysis (FODA)

(Kang et al., 1990)

RE Methods for SPLFeature-orientedFeature-Oriented Reuse Method (FORM)

(Kang et al., 1990)

RE Methods for SPLUse case-basedProduct 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)

(Gomma, 2005)

RE Methods for SPLUse case-basedProduct Line UML-Based Software Engineering (PLUS)

(Gomma, 2005)

RE Methods for SPLUse case-based

PuLSE CaVE (Commonality and Variability Elicitation)

(Fantechi et al, 2003)

RE Methods for SPLOrthogonal 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

ReferencesClements, 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. 5-19.

Chaos Report 1994. Software Development Report, The Standish Group, West Yarmouth, MA, access in http://www.standishgroup.com.

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 [http://publica.fraunhofer.de/eprints.har] (Germany).

Kitchenham, B., 2004, "Procedures for Performing Systematic Reviews," Joint Technical Report, Keele University TR/SE-0401 and ICTA 0400011T.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. 188.

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. 143-168.

ReferencesBayer, 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. 122-131.

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. 178--194.

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. 152-167.

John, I.; Knodel, J.; Lehner, T. & Muthig., D. (2006),A Practical Guide to Product Line Scoping, in , pp. 3-12

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. 167-180.

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, 2002.

Gomaa, H., Designing Software Product Lines with UML: From Use Cases to Pattern-Based Software Architectures, Addison-Wesley, 2005.

Almeida , E. S. RiDE: The RiSE Process for Domain Engineering, Ph.D. Thesis, Federal University of Pernambuco, Recife, Pernambuco, Brazil, May, 2007.

ReferencesKotonya, 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. 140-151.

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. 871--875.

Mannion, M.; Keepence, B. & Harper, D. (1998),Using Viewpoints to Define Domain Requirements, IEEE Computer Society Press, Los Alamitos, CA, USA, pp. 95--102.

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. 76--85.

Kim, J.; Kim, M. & Park, S. (2006),Goal and scenario based domain requirements analysis environment, Elsevier Science Inc., New York, NY, USA, pp. 926--938.

A Review on Requirement Engineering for Software Product Lines Danuza F. S. Neiva [email protected].

Documents

Transcript of A Review on Requirement Engineering for Software Product Lines Danuza F. S. Neiva [email protected].