Feature-Driven Development¶
An iterative software-development method that builds an overall domain model and feature list, then plans, designs, inspects, builds, and integrates small client-valued features in short cycles.
Core Idea¶
Feature-driven development organizes a project around small, client-valued functions inside a shared domain model. It begins by developing an overall model and deriving a categorized feature list from subject areas, business activities, and activity steps. Features are expressed as concrete functions and are decomposed when too large for a short implementation cycle, conventionally about two weeks.
Scope of Application¶
- Domain-rich software. An overall object model gives many feature teams a common vocabulary and class structure.
- Large development groups. Class ownership and feature teams coordinate parallel work while retaining responsibility.
- Incremental delivery. Small features move through design, inspection, code, test, and integration repeatedly.
- Progress reporting. Named milestones and completed features expose status at finer granularity than component percentages.
Clarity¶
A project should be called FDD only when the five processes and their work products are observable. A two-week timebox does not by itself make an item a feature; it must express client-valued function and be connected to the model. Milestone percentages should summarize completed evidence, not substitute for it. Adaptations can be legitimate, but removing several load-bearing roles should be described as influence rather than full method identity.
Manages Complexity¶
The feature list turns a large domain into small deliverable slices, while the overall model keeps those slices from becoming unrelated patches. Class ownership localizes stewardship, and feature teams reassemble the owners needed for one vertical function. The architecture can become rigid if the initial model is treated as final, so model refinement and refactoring must remain visible as features expose new understanding.
Abstract Reasoning¶
- Walk through the system scope and build reviewed models for the important domain areas.
- Merge them into an overall model and derive a categorized list of small client-valued features.
- Plan feature order and assign class or feature-set ownership according to dependency and capacity.
- Form a feature team, produce a design package, and inspect it before implementation.
- Implement across owned classes, unit-test and inspect the code, and promote the feature to the main build.
Knowledge Transfer¶
FDD transfers among software projects that can express work as small client-valued functions within a coherent domain model. A research prototype or infrastructure program may borrow feature decomposition or inspections without supporting the whole method. Beyond software, planning by small outcomes is analogous, but class ownership, code inspection, and main-build integration are constitutive domain accents.
Relationships to Other Abstractions¶
Current abstraction Feature-Driven Development Domain-specific
Parents (1) — more general patterns this builds on
-
Feature-Driven Development presupposes Iteration Prime
Feature-Driven Development presupposes Iteration because its method repeatedly plans, designs, inspects, builds, and integrates small client-valued features.
Hierarchy path (1) — routes to 1 parentless root
- Feature-Driven Development → Iteration
Neighborhood in Abstraction Space¶
Feature-Driven Development sits in a crowded region of the domain-specific corpus (39th percentile for distinctiveness): several abstractions share nearly its structure, so a description that fits it tends to fit its neighbors too.
Family — Organizational Patterns & Management Concepts (29 abstractions)
Nearest neighbors
- Virtual Design and Construction — 0.89
- Domain analysis — 0.87
- Unified process — 0.87
- Platform-specific model — 0.87
- Executable UML — 0.87
Computed from structural-signature embeddings · 2026-10-08