1. Introduction

Feature modelling was originally proposed as part of FODA approach. Currently, it is part of feature-oriented software development approaches, which propose handling features as modular, first-class entities though the entire development cycle.

In short, a feature model documents a product line’s variability. It specifies the set of valid products. Besides introducing the graphical language of feature diagrams, we also connect the graphical representation to a formal representation that is the basis of engineering tools.

Feature modeling play a central role in product-line development, for example, for requirements analysis and product derivation, and are widely used in research and practice. However, no standardized modeling format has been accepted, so far. Thus, different notations and file formats are omnipresent.

Additionally, research literature on feature models usually provides only small examples. Although researchers have attempted
to collect a corpus of example feature models, feature models of industrial product lines are rarely publicly available.

 Information provided in this guideline is strongly based on Feature Oriented Software Product Lines Reference.

2. Feature Diagram Notation
A Feature Diagram is a graphical notation to specify a feature model. It is a tree whose nodes are labeled with feature names. Different notations convey various parent–child relationships between features and their constraints. If a feature f is a child of another feature p, f can be selected only when p is also selected.
Typically, a feature diagram includes mutual relations between features. For example, the parent feature denotes a more general concept and the child a specialization.
Mandatory and optional features are distinguished by a small circle on the child node—a filled bullet denotes a mandatory feature, whereas an empty bullet denotes an optional feature. Specific graphical elements define additional constraints, if the child features of a common parent cannot be selected independently.

Graphical Notation for  Mandatory (filled-bullet)  and Optional  (empty-bullet) Features

Graphical notation for a some-out-of-many choice, also called at least one or one-or-more choice.

3. Feature Notation Variations and Examples

In the literature, there are many variations of feature diagrams including:

1. Some cross-tree constraints can be modeled graphically. Arrows can denote implications or mutual exclusion, as exemplified below.

2. Some notations distinguish abstract from concrete features. Abstract features are used for structuring and documentation purposes only and are not bound to implementation artifacts. These abstract features help structuring a tree-diagram but do not reflect actual variability in the domain, as denoted below by gray boxes. It should be observe that abstract features are not mapped to any source code.