An initial project-wide activity to identify all the features needed to support the requirements.

An initial project-wide activity to identify all the features needed to support the requirements.

A team usually comprising just the chief programmers from process 1 is formed to decompose the domain functionally. Based on the partitioning of the domain by the domain experts in process 1, the team breaks the domain into a number of areas (major feature sets). Each area is further broken into a number of activities (feature sets). Each step within an activity is identified as a feature. The result is a hierarchically categorized features list.

Entry Criteria


Form the Features List Team Project Manager, Development Manager Required
The features list team comprises the chief programmers from the modeling team in process 1.

Build the Features List  Features List Team Required
Using the knowledge obtained from process 1, the features list team identifies features. The team may also use any existing reference or requirements documents, such as object models, functional requirements (traditional or use-case format), and user guides, noting the source document against any features identified in this way.

This task is a simple functional decomposition, starting with the partitioning of the domain used by the domain experts for their domain area walkthroughs in process 1. The domain is decomposed into areas (major feature sets) that comprise activities (feature sets) that comprise features, each of which represents a step in an activity.

Features are granular functions expressed in client-valued terms, using the naming template:
<action> <result><object>
For example, “calculate the total of a sale” and “calculate the total quantity sold by a retail outlet for an item description.”

Features are granular. A feature should take no more than two weeks to complete but not be so granular as to be at the level of simple getter and setter operations. Two weeks is an upper limit; most features take less than this amount of time. When a step looks larger, the team breaks the step into smaller steps that then become features


Internal and External Assessment Features List Team, Business Required
Modeling team members actively participating in the process provide internal or self-assessment. External assessment is made on an as-needed basis by referring back to the Domain Experts from the modeling team or the business (users) for ratification or clarification of issues that affect the features list.

Exit Criteria

To exit the process, the features list team must produce the features list to the satisfaction of the Project Manager and Development Manager. The features list consists of

  • A list of major feature sets (areas)
  • For each major feature set, a list of feature sets (activities) within that major feature set.
  • A list of features for each feature set (activity), each representing a step in the activity of that feature set

This version of FDD Process #1 is taken from the book, Palmer, Felsing, 'A Practical Guide to Feature-Driven Development' ,  Prentice Hall, 2002.
Follow me on Twitter...