What’s in a Feature: A Requirements Engineering Perspective

Classen, Andreas; Heymans, Patrick; Schobbens, Pierre‐Yves

doi:10.1007/978-3-540-78743-3_2

Cited by 99 publications

(73 citation statements)

References 22 publications

Supporting

Mentioning

Contrasting

Unclassified

Order By: Relevance

“…Some surveys on particular variability modeling/management approaches exist, most notably on feature-oriented variability modeling [30,51,204] and on decision-oriented variability modeling [202]. Some more general surveys discuss a particular selection of approaches, e.g., [48,206].…”

Section: Variability Modeling Of Diverse Systemsmentioning

confidence: 99%

Software diversity: state of the art and perspectives

Schaefer

Rabiser²,

Clarke

et al. 2012

Int J Softw Tools Technol Transfer

136

View full text Add to dashboard Cite

Abstract. Diversity is prevalent in modern software systems to facilitate adapting the software to customer requirements or the execution environment. Diversity has an impact on all phases of the software development process. Appropriate means and organizational structures are required to deal with the additional complexity introduced by software variability. This introductory article to the special section "Software Diversity -Modeling, Analysis and Evolution" provides an overview of the current state of the art in diverse systems development and discusses challenges and potential solutions. The article covers requirements analysis, design, implementation, verification and validation, maintenance and evolution as well as organizational aspects. It also provides an overview of the articles which are part of this special section and address particular issues of diverse systems development.

show abstract

Section: Variability Modeling Of Diverse Systemsmentioning

confidence: 99%

Software diversity: state of the art and perspectives

Schaefer

Rabiser²,

Clarke

et al. 2012

Int J Softw Tools Technol Transfer

136

View full text Add to dashboard Cite

show abstract

“…the Sales feature in Figure 1 refers to six such requirements. To enable acceptable implementation of the feature, the feature's requirements are elicited [25] and refined until they comply with the solution's environment and design [26].…”

Section: Feature Trees For Release Planningmentioning

confidence: 99%

“…Bugs and future requirements were placeholders for documenting maintenance and future enhancement needs. Formal feature specification in the context of software product lines expects specification of requirements, domain assumptions, and solution [26]. This specification practice was calibrated to increase work efficiency and flexibility and to support depending activities, while accepting dependency on the involved practitioners for interpreting the documentation.…”

Section: Media Archive Of the Arts Feature Treementioning

confidence: 99%

Release Planning with Feature Trees: Industrial Case

Fricker

Schumacher

2012

Requirements Engineering: Foundation for Software Quality

View full text Add to dashboard Cite

Abstract. [Context and motivation] Requirements catalogues for software release planning are often not complete and homogeneous. Current release planning approaches, however, assume such commitment to detail -at least implicitly. [Question/problem] We evaluate how to relax these expectations, while at the same time reducing release planning effort and increasing decisionmaking flexibility. [Principal ideas/results] Feature trees capture AND, OR, and REQUIRES relationships between requirements. Such requirements structuring can be used to hide incompleteness and to support abstraction. [Contribution] The paper describes how to utilize feature trees for planning the releases of an evolving software solution and evaluates the effects of the approach on effort, decision-making, and trust with an industrial case.Keywords: features, abstraction, release planning, roadmapping, case study. IntroductionSoftware releases are planned by allocating requirements to development projects [1]. A strategic release plan aligns the development of an evolving software solution with market and stakeholder needs, company objectives, and constraints such as time and resources. Release planning is a central concern in iterative development, where multiple iterations, rather than a single project, are defined [2]. Release planning involves the following steps [3]. Requirements are elicited and specified. Criteria [4] are defined to evaluate and prioritize requirements [5]. Releases are then scoped by allocating the prioritized requirements to development projects. The resulting release plans are implemented, delivered, and analyzed with post-release reflections [6].Requirements that enter release planning are often of low quality [7]. Their homogeneity [8], completeness, and understanding [9] are hard to ensure due to the limited effort invested before a development project is funded. This situation contradicts with the assumptions of release planning approaches that scope projects simply by prioritizing and allocating available requirements. Consequently, the results are not trusted and not used for guiding ensuing development steps [10].Release Planning with Feature Trees: Industrial Case 289 This paper describes in detail how to hide the requirements-related problems by structuring the release planning inputs. The approach, whose initial ideas were introduced in an earlier position paper [11], is based on variability modeling [12] that allows abstracting from requirements with AND, OR, and REQUIRES relationships [13]. Variability is here used to structure decision options [14] for product evolution. This paper then introduces an industrial case [15] to understand how to use variability modeling in a real-world context of continuous agile product management [16]. Evaluated were feasibility of the approach and its effects on effort, decision-making, and trust were evaluated.The paper is structured as follows. Section 2 describes background and motivation. Section 3 introduces variability-based release planning. Section 4 describe...

show abstract

“…In previous work [3], we proposed a conceptual solution to the problem of safe composition. Unfortunately, the solution, as many other solutions, is not efficient because of the exponential number of combinations it explicitly considers.…”

Section: Introductionmentioning

confidence: 99%

“…In this paper, we identify synergies between these methods (Section 2) and propose a combined approach, free from most existing drawbacks (Section 3). This comes, however, at the expense of the generality of our previous work [3] since we restrict the approach to behavioural properties expressed with linear or modal transition systems (Section 4).…”

Section: Introductionmentioning

confidence: 99%

Towards safer composition

Classen

Heymans

Tuny

et al. 2009

2009 31st International Conference on Software Engineering - Companion Volume

Self Cite

View full text Add to dashboard Cite

Determining whether a set of features can be composed, or safe composition, is a hard problem in software product line engineering because the number of feature combinations can be exponential. We argue that synergies between current approaches to safe composition should be exploited and propose a combined approach. At the heart of our proposal is a merge operation that creates a behavioural description for the entire product family from a feature diagram and descriptions of individual feature behaviour. As a result, we intend to verify more efficiently safe composition for an exponential number of feature combinations.

show abstract

What’s in a Feature: A Requirements Engineering Perspective

Cited by 99 publications

References 22 publications

Software diversity: state of the art and perspectives

Software diversity: state of the art and perspectives

Release Planning with Feature Trees: Industrial Case

Towards safer composition

Contact Info

Product

Resources

About