Feature

I define a feature as a distinguishing characteristic of a system that delivers value to stakeholders. For example, a search function or a weather forecast counts as a feature. In addition, I view it as a grouping of related requirements. Furthermore, I use features to talk with stakeholders at a higher level of abstraction. Thus, I avoid technical detail when stakeholders need an overview.

First, I explain how features relate to requirements. I treat features as containers for several requirements. Second, I show that features can express optional or variable characteristics. Third, I note that agile teams sometimes use the term feature for medium-grained requirements. Therefore, features bridge coarse product goals and fine-grained requirements.

I model features in feature models for product lines. For example, I draw feature diagrams to show common and variable capabilities. Also, I document them in tables or models. Moreover, I include dependencies in the model. Consequently, I can configure specific products from the model.

I organize features in parent-child relationships. For instance, I mark child features as mandatory when they must appear in a product. Alternatively, I mark them as optional when stakeholders may choose them. In addition, I use “or” groups to require at least one child feature in a group. Likewise, I use “alternative” groups to require exactly one child feature. Thus, I control which combinations form valid products.

Furthermore, I define advanced dependencies between features. For example, I use requires to state that selecting option A implies selecting option B. Also, I use excludes to prevent two capabilities from appearing together. Therefore, I ensure consistent product configurations. In addition, I apply cardinality-based elements when I need quantitative constraints. Consequently, I can express how many instances of a feature may appear.

I create feature metamodels to capture refinement and dependency relationships. For example, I show parent-to-child refinement and cross-feature dependencies. Moreover, I separate basic elements from advanced ones. Finally, I include cardinality elements when necessary.

For example, I model a “GPS hiking watch” as a parent capability. Then, I add “Distance measurement” and “Altitude measurement” as mandatory child features. Next, I add “Weather forecast” as an optional child feature. In addition, I refine “Altitude measurement” into two child features: “Barometric altitude measurement” and “GPS-based altitude measurement.” Because these two cannot co-exist for one configuration, I mark them as alternative. Thus, I demonstrate how a feature model guides product configuration.

I consider several quality concerns when I choose a feature representation. First, I check expandability to see how easily I can add new products. Second, I assess migratability to see how much existing documentation I can reuse. Third, I test verifiability to detect incorrect configurations automatically. Fourth, I evaluate comparability to compare requirements across products. Finally, I examine changeability to measure how easily I can change requirements for one product without affecting others.

In summary, I treat a feature as a user-visible or stakeholder-valued characteristic that groups requirements and supports variability. Therefore, I use feature models, diagrams, and metamodels to document and manage features. Moreover, I apply basic and advanced elements to express structure and dependencies. Consequently, I make product configuration and stakeholder communication clearer and more reliable.