There are some doubts about the abstraction level of features modeling. Some questions are often identified, such as “To what extent it is worth refine a feature which has many specific sub-features?”. Thus, this work presents the following guidelines to help to identify features and avoid those doubts.

• In feature model must be represented features that reflect value and competitively for organizations launch product quicker. Thus, it is necessary representing features more relevant and that present a differential among products. Some variations are irrelevant to represent in feature model, since they do not represent decisions with differential. For example, it does not represent variations in level attributes with low technical impact. Other situations of irrelevance must be observed by the analyst. A typical situation is when can be necessary represent several reports in a SPL. However, the reports amount can become the feature model in a complex model with many non-relevant features. In this case, the solution can be creating categories that group reports more relevant and that add a differential among products (e.g. quality reports, managerial reports and financier reports).
• Features can be refined into sub features. It must be performed to represent relevant variantions in a level more detailed. The sub features are identified during the feature model representation, which will be seen in the next section.
• It does not identify all implementation details that do not distinguish products in a domain. A skillful developer tends to enumerate all the implementation details and identify them as features, even though there are no variations among them. It is necessary remember that a feature model is not a requirement model, which expresses the details of internal functions. The modeling focus should be on identifying properties, factors, assumptions that can differentiate one product from other in the same domain, not on finding all implementation details that are necessary to implement the products in a domain Lee et al. (2002).
• Attached features that always exist together can be group in a single feature. For example, the User feature always exists in presence of the Login/Logout feature, so it can be yet grouped into Authentication feature. However, some constraints must be observed for the features grouping: 
  • Whether there are dependency constraints (e.g. implication or exclusion) in a part of a grouped feature, it is necessary ungroup the feature part with distinct constraints.
  • Whether there are distinct variabilities types among grouped features (i.e. a part is optional and another is feature) it is necessary ungroup the features.
  • Optional features that are always used together can be packaged into optional feature.
  • Related features that are required by all members of the SPL are packaged into mandatory features.
  • A grouped feature must define in its description the other grouped features. 

Another way to identify news features is by feature model representation.

Features are modeled in terms of the following relationships:

• Composed-of. This relationship is used if there is a whole-part relationship between a feature and its sub-features (parent-role: whole, child-role: part);
• Generalization/specialization. In cases where features are generalization of sub-features, they are organized using the generalization/ specialization relationship (parent-role: general-entity, child-role: specialized-entity). Two or more features with similar functionalities can be generalized into one feature by abstracting the differences into variability through feature generalization. It is possible to define feature in more general fashion which helps to identify a common functionality among products;
• Implemented-by. The implemented-by relationship is used when a feature (i.e. a feature of an implementation technique) is necessary to implement the other feature;

• Dependency. This relationship represents dependency constraints of implication (require) or exclusion. It is used to constrain the selection from variant features. That is, it is possible to specify which features should be selected along with a designated one and which features should not. In this relationship, a mandatory feature does not can depend of another, but a variant feature can depend of a mandatory feature.

The features model does not must represent functional dependencies, like a function call hierarchy, but organize features to capture and represent commonalities and differences Lee et al. (2002). Feature model must represent relationships between features that impact in decision making in the products scope.

In the feature model, there are concrete and conceptual features. A concrete feature represents a real feature in the SPL scope. The conceptual feature is used only to help in the model organization. It really is not represented in the SPL scope. For example, the feature at the root of the tree is called root feature and it is usually a conceptual feature that represents the whole system. Another example is in the generalization relationship, in which the general-entity is normally a conceptual feature. For composed-of relationship, the parent and child features are usually concrete.

A key feature in the feature model is the Variation Point (VP). VP represents a variability subject and it is composed by variability objects (options of the VP) Pohl et al. (2005). An example of the VP is shown in following  Figure. This VP is part of a SPL example in the home automation domain used in Pohl et al. (2005). It represents that the “Door Lock” VP has the options “Fingerprint scanner” and “Keypad”.

The commonality and variability representation is defined by the feature types and are given as follows:

• Mandatory. Common feature among all products, i.e. it always should be selected by the products of the SPL.
• Optional. One feature may or may not be selected for a product.
• Alternative. This feature type is applicable only for features that are options of a VP. It signifies that at least one variant should be selected for the VP. The variations are mutually exclusive. It corresponds to cardinality (1:1), i.e. in the minimum and in the maximum one variant can be selected, when VP is a mandatory feature. Whether VP is an optional feature, the cardinality is (0:1).

• OR. This feature type is applicable only for features that are options of a VP. It signifies that one or more variants may be selected for the VP. It correspond to cardinality (1:n). For representing of the cardinality (0:n), i.e. zero or more variants may be selected, is necessary represent variation point as a optional feature.

All variability objects of a VP, i.e. its variants, must have same type (Alternative or OR). An example with all those types is presented in the following Figure.

Next Figure shows the legend of the presented feature model.

Each feature should be specified with the following attributes: Id, Name, Description, Type, Binding time, Rationale. The feature type defines the commonality and variability representation. It can be a) Mandatory, when the feature is common for all products; b) Optional, when the feature may or may not be selected for a product; c) Alternative, when the feature is a variant of a VP and at least one variant should be selected for it; and d) OR, when the feature is a variant of a VP and one or more variants may be selected for it.

Links must be established to model explicitly interrelationships among information in the different work products that are directly linked with features (see Traceability Guideline).