A software feature consists of one or more logically related system capabilities that provide value to a user and are described by a set of functional requirements. Many business analysts use features as a way to describe the scope of a project. However, a simple list doesn’t readily show the size and complexity of various features. Nor does quickly skimming a feature list easily reveal the full scope of a project. A feature tree is a visual analysis model that organizes a set of features in a format that makes them easy to understand.
Feature Tree Format
The structure of feature trees is based on fishbone diagrams or Ishikawa diagrams, which are commonly used to organize information into logical groupings based on relationships. Fishbone diagrams are typically used to model cause-and-effect relationships, but feature trees use the same format to organize the planned features of a software solution.
A feature tree can show up to three levels of features, commonly called level 1 (L1), level 2 (L2), and level 3 (L3). L2 features are subfeatures of L1 features, and L3 features are subfeatures of L2 features. Below L3 lie individual requirements, which aren’t shown on the feature tree. A feature tree does not necessarily need to have three levels of features; if the solution and features are simple, you might have just L1 features and their more detailed functional requirements.
As Figure 1 illustrates, the basic building block of the model is a feature with a single line. The feature names are simply shown as words on the tree, and the lines link related features together. Feature names should be concise, typically just two or three words.
Figure 1- Feature tree grouping
Each feature is shown on its own line. Each subfeature also has its own line, which branches off the parent feature's line. In Figure 1, the L1 feature has been decomposed into four subfeatures at the L2 level. The order in which the subfeatures are attached to the line is not important, as long as common subfeatures branch off the same parent feature line. The L1 features can be shown in boxes, to highlight those elements on the tree as being the main features under which subfeatures fall. This enables anyone who skims the model to understand the big picture of the scope of the solution.
A Sample Feature Tree
Figure 2 shows a partial feature tree for a chemical-tracking information system. Note that the main branch or “trunk” of the tree is a straight line with an oval at the end that shows the name of the product being developed. The shaded boxes represent the L1 features, such as Order Chemicals and Inventory Management. Each such feature represents a block of logically related functions that a user might want to perform. The lines coming off an L1 branch are the L2 features: Search and Chemical Request are subfeatures of Order Chemicals. The branches off an L2 branch are the L3 features: Local Lab Search and Catalog Search are subfeatures of Search.
Figure 2 - Partial feature tree for the Chemical Tracking System
Using the Feature Tree
A feature tree is typically created early in a project to define the breadth of work that will be completed, but it is useful throughout the project to communicate changing scope and to help the team members organize and coordinate their work. You can include a feature tree in the project’s vision and scope document or project charter, or it can be stored elsewhere and referenced as needed. A key purpose of visual models like the feature tree is to foster clear and accurate communication among the project stakeholders. That clarity is more important than dogmatically adhering to the rules for a “correct” diagram.
Release Planning
Feature trees can be used during release planning to decide and show which features are allocated to each release or development increment. A feature could be implemented in its entirety in a specific release, or only a portion could be implemented by choosing just certain L2 and L3 subfeatures. Future releases could enrich these rudimentary implementations by adding more L2 and L3 subfeatures until each feature is fully implemented in the final product. The scope of a particular release thus consists of a defined set of L1, L2, and/or L3 features chosen from the feature tree. A feature tree can illustrate these feature allocations across releases by using colors or font variations. For example, in Figure 2, the blue features might represent the first release, the green features are the second release, and the black features are yet to be allocated to a release.
Functional Decomposition
Feature trees show all of the planned product features at once, giving a quick view of the solution's breadth of functionality. Organizing the features in this fashion makes it easy to identify missing and unnecessary features. The feature tree provides a functional decomposition of the solution for use throughout all phases of the project, including organization of the requirements, planning the work around the requirements, and bounding of the scope of work. Feature trees provide a much richer view of features than a simple list can show.
Find Gaps
Because there is no way to guarantee that a feature tree is complete, have your stakeholders review it to make sure it reflects their expectations. The earlier that gaps are identified the better, because finding them late in a project can derail the project (and traumatize the participants). Update the feature tree any time scope is changed to reflect the final planned feature set.
Depict Project Scope
The feature tree should be used to set and communicate the scope of the project. It is a useful model to circulate among executives and lead stakeholders to quickly communicate the scope of the solution. Because you can fit so many features on one page, the feature tree is a good choice when you need a diagram that anyone can look at to understand the gist of the solution quickly. For packaged software, a feature tree provides the features that go in a short bullet list or description of the product's functionality.
When a stakeholder joins a project midstream it can be a challenge for him to get a high-level picture of what an existing system does or what a new system is supposed to do. Feature trees allow all team members to understand and agree on the capabilities of the solution at a high level. They show the breadth of the solution scope at a consistent level of depth.
Organize the Requirements
The divisions in a feature tree provide a convenient way to organize requirements in deliverables so that the information is grouped by feature. In a requirement deliverable, all of the requirements for each L1 feature and its subfeatures can be grouped together. For the example discussed earlier, there could be a full set of models and requirements for Inventory Management and another for Health and Safety.
If your team is frustrated by the limitations of text-only requirements documentation, consider using feature trees to provide an at-a-glance visual representation of project scope.
Authors: Joy Beatty & Karl Wiegers
Joy Beatty is a Vice President at Seilevel and Karl Wiegers is Principal Consultant at Process Impact. Karl and Joy are co-authors of the award-winning book Software Requirements, 3rd Edition. Joy is also a co-author of Visual Models for Software Requirements. This article is adapted from both books. Karl’s most recent book is Successful Business Analysis Consulting: Strategies and Tips for Going It Alone.