What is Feature driven development?

Feature Driven Development (FDD) is an iterative agile software development model. More specifically, FDD organizes workflow based on which features need to be developed next. An Agile methodology for developing software, Feature-Driven Development (FDD) is customer-centric, iterative, and incremental, with the goal of delivering tangible software results often and efficiently. FDD in Agile encourages status reporting at all levels, which helps to track progress and results.

Features in the FDD context, though, are not necessarily product features in the commonly understood sense. They are, rather, more akin to user stories in Scrum. In other words, “complete the login process” might be considered a feature in the Feature Driven Development (FDD) methodology. As the name implies, features are an important aspect of FDD. A feature is a small, client-valued function expressed in the form. For example, “Calculate the total of a sale”, “Validate the password of a user”, and “Authorize the sales transaction of a customer”. Features are to FDD as use cases are to the Rational Unified Process (RUP) and user stories are to Scrum – they’re a primary source of requirements and the primary input into your planning efforts.

Feature-driven development methodology

The first two phases of an FDD project focus on the overall project, the final three steps are repeated for each feature defined in the model. Feature Driven Development (FDD) is an agile framework that, as its name suggests, organizes software development around making progress on features.

Develop an overall model: One of the core principles of feature-driven development is to use domain object modeling. Domain object modeling is a way to represent connected concepts and the relationships between them. During the first step, an outline of the domain model is created. This object model will be the blueprint for the project. The domain expert shares what business or user problem needs to be solved with the feature. The chief architect provides guidance to the team. The proposed models are reviewed and either one model or a merge of models is approved. At the end of the phase, the team has a clear understanding and picture of the project.

Build a feature list:  The list of features identifies the elements necessary expressed as actions, results, or objects. Each feature should be built in less than two weeks. Features taking longer than two weeks to develop should be broken down into smaller features. For example, if the feature you are building is “pay on-line bill”, some of the features on the list may include “validate account number” and “retrieve account balance”.

Plan by feature: Once the feature list is created, you need to determine the order in which they need to be developed and implemented and which team member is responsible for each feature. All team members should take place in this process to identify potential risks, dependencies, workload constraints, and other obstacles. At the end of this phase, each feature should be assigned to a developer and feature team.

Design by feature: A design package is created for each feature. The chief programmer identifies which features will be included in each two-week iteration, as well as identify the class owners and feature priorities. The design phase ends with a design review by the entire team. And the domain expert ensures what was built addresses the customer problem being solved.

Build by feature: After the design is approved, now it’s time to start writing code. All the items necessary to support the feature design are implemented. These elements can include front-end and back-end elements like user interfaces or database queries. Once everything is completed by individual team members the feature moves onto testing and the process begins again for the next feature on the list.