Feature Trees

What is it?

A Feature Tree (sometimes also known as a Feature Model or Feature Diagram) is a hierarchical diagram that visually depicts the features of a solution in groups of increasing levels of detail. In the Feature Tree, some features may be flagged as mandatory, some optional, and some as mutually exclusive. Features may be further flagged for development cycles (1st iteration, 2nd iteration, etc.), business priority, dependencies, or other relevant information.

It is important to note that there are a lot of different definitions for what a feature is, depending on where you look.^[8] In general, the features in a feature tree could include functional features (hardware, software), non-functional features (performance or other criteria), or even parameters (the same feature at varying levels of capability or cost for example).^[5] In most cases however, the features of Feature Tree are mostly kept at a summary level.

Feature Trees were introduced in 1990 as part of the FODA (feature-oriented domain analysis) method for software product lines.^[6] Since then, there have been a number of different variations and notations used for Feature Trees. However, many Business Analyst's are likely to come across the version of Feature Tree's promoted by Seilevel via their web site or blog ^[1,2,3,4], as Seilevel uses a version of the Feature Tree in their Requirements Modeling Language (RML)©.

Feature Trees can bear significant resemblance to Functional Decomposition Diagrams, depending on the approaches taken to creating them.

Why do it?

Feature Trees are great ways to summarize the features that will be included in a solution and how they are related in a simple visual manner.

They are most commonly used for planning the overall feature set of a single solution (scope) or product that will be evolved over time (say through multiple iterations of development, or multiple releases to the marketplace) or for defining the differing features that will be included in a product line (for example, to define the differences between Windows 7 Home, Pro, and Ultimate or for different trim levels in a range of automobiles).

They can also be used to help identify missing requirements (by showing the model to clients and asking them to note missing features).

How do I do it?

Like many Business Analysis techniques, creating a Feature Tree is relatively straight forward. It's the analysis involved that adds complexity.

Step 1

The first step is decide what visual model you are going to use to create the Feature Tree. Seilevel seems to prefer the fishbone diagram structure (see the links below), but I prefer to use the mind-map as I find it bit more intuitive both for myself and my clients. But you can just as easily use an Organization Chart type structure if that comes easy to you. Or if you don't have any modeling / diagramming tools at all, you can get much of the same effect with an outline structure in a word processor (although the outline really does seem to lose a lot visual intuitiveness that makes the diagram so useful).

Step 2

Name your central point (the back-bone in a fishbone diagram, the central concept in a mind map, or the top element in an org chart type structure) after the solution or product (line) that you will be building.

Step 3

From the central point, create branches for the main feature groups that your solution will have. If your solution was a shopping web site for example, you might main feature sets for Registration, Account Management, Product Search, Product Display, and Ordering.

Step 4

For each of those main branches, create sub-branches for the main features (or feature alternatives) within those areas. For example, within Account Management there might be sections for Update Shipping Address, Update Email Address, Update Email Preferences, Update Payment Information, and similar sub-groups of features related to Account Management.

Step 5

Repeat Step 4 by further breaking down each sub-branch as appropriate. In general, you don't want to go into so much detail that you are listing actual requirements. Seilevel generally recommends going no further than 3 levels, but it really depends on how complex your solution is. Especially for complex product lines, you go much deeper than 3 levels. Continue iterating Step 4 until you are comfortable with the results.

Step 6

Review the resulting diagram with your stakeholders. Make sure they agree that all the features are captured. If there are alternative features or those with dependencies, make sure those are captured as well. Hopefully, the Feature Tree is so easy to comprehend that you could share it with a large number of potential users in order to get feedback via email or some other method that does not require significant interaction.

What Should the Results be?

The result of your efforts should be a tree diagram that can range from relatively small to quite large. The larger and more complex, the more difficult it can be to understand.

The image below is a partial Feature Tree where just some of the Account Management features have been diagrammed. It was created in about 15 seconds using a mind-mapping application. Use whatever tool makes the most sense for your clients and yourself (be it Visio, a mind-mapping program, or whatever works for you).

Advantages

The Feature Tree is a very simple concept for stakeholders to understand (both business and technical).
It can be a very good way to define the scope of work for a project.
Features don't have to be software features, you can use Feature Trees with physical products or even service options.

Disadvantages

Like many diagrams or models, noticing what is missing is often much harder than reviewing what is already included because viewers tend to get locked into what is present instead of what is missing.
Reviewers may have different ideas of exactly what is meant by a feature, so you may need to supplement the diagram with additional information where there may be points of misunderstanding.

Tips

Add color or other elements to your diagram to help with understanding. If you are planning multiple phases of development, then color code or otherwise flag features by release. If you are using the feature diagram to confirm scope, use colors to show what is in scope and what isn't. Or if your diagram includes different feature types (physical, software, parameters) you can again use colors or similar changes to indicate what type of feature each item in the diagram is. Many mind-mapping or diagramming applications will let you combine colors, icons, pictures, and other elements to add more visual detail.
In Visio you can create a Feature Tree using the Cause and Effect diagram template, or the Organization Chart template.

References

Web Page: Feature Trees. On Seilevel.com. Accessed on December 1, 2013.
Blog Post: Find Missing Requirements with the Feature Tree. Seilevel.com Blog. November 6, 2013.
Blog Post: Adding More Dimensions to Your Feature Trees. Seilevel.com Blog. May 23, 2013.
Blog Post: Business Analyst Tip for Visual Requirements Models - Using Feature Trees. Seilevel.com Blog.
Article: Developing Software Lines: Why Bother?. By Hassan Gomaa. informIT. November 24, 2004.
Research Paper: On the Structure of Problem Variability - From Feature Diagrams to Problem Frames. By Andreas Classen, Patrick Heymans, Robin Laney, Bashar Nuseibeh, and Thein Than Tun. The Open University. 2007
Research Paper: What's in a Feature: A Requirements Engineering Perspective. By Andreas Classen, Patrick Heymans, and Pierre-Yves Schobbens. 2008

Related Resources

Article: Using Feature Trees to Depict Scope. By Karl Wiegers and Joy Beatty. Business Analyst Times. October 6, 2014.
YouTube Video: Feature Tree. From Seilevel Requirements channel. Published April 4, 2013.
Web Page: Microsoft has a quick reference page on creating a Cause and Effect (fishbone) diagram in Visio that you can use as a starting point for a Seilevel-type Feature Tree.