TEAM Zarate Tarrani Notes From the Field

A new book titled A Practical Guide to Feature-Driven Development proposes a method that I think is on the right track.

What is proposed and described in this book is elegant in that it combines simplicity and power, and effective because it will deliver applications that support business requirements.

Although the approach is based on object-oriented development, and the book is focused on that approach, it can be refactored into function- and procedure-oriented programming environments. Moreover, while the book is written to fit within agile methods, it be fit to any development life cycle approach. This is because the focus is on features, which translate into what the business needs from an application. This is where elegance and simplicity comes in. By focusing on the features needed applications are less apt to be gold-plated with unnecessary features that developers may think is nice, but add little business value. In this respect the time to deliver is shortened and what is delivered is going to reflect genuine business requirements.

The power of FDD comes from the highly structured approach based on the ETVX (entry-task-validation-exit) framework. Entry criteria is typical: requirements, authority to proceed and other quality gates that must be passed before a development project is initiated. The tasks follow a five-step process as follows:

1. Develop the model, including scope, validation in the form of walkthroughs, and peer reviews. The approach described in the book assumes an object model, but in a non-OO setting this can be realigned to first cut system diagramming in the form of block- and data flow-diagrams,and first-cut design.
2. Build the features list. The OO approach is domain partitioning based on the model; in a non-OO setting this is where the team maps functional requirements to features.
3. Plan by feature. This step, in my opinion, shows FDD to be a legitimate software engineering method. Feature prioritization, dependency analysis and effort estimation occur here. Done properly this step will make the difference between success or failure. I do have one issue with the book at this point: the prioritization is done by the technical team - it should be done with the business stakeholders.
4. Design by feature. This is an iterative step that feeds back into step 1 (build the model) wherein class ownership is determined and the original model is refined based on the design approach. In non-OO environments this would loop back into the first-cut design and trigger trade-off analysis and design refinement.
5. Build by feature. This is where the application is actually developed on a feature-by-feature basis within the context of the defined architecture (model).

Verification is accomplished using traditional methods. The authors introduce what they call feature-based testing which is no different than product test (also called functional qualification testing, and in some circles, acceptance testing). Verification procedures are thoroughly covered in the book, further adding to the software engineering approach that is incorporated into FDD. Exit criteria is when the sponsors accept the system.

What makes this book important is that is gives a straightforward approach that is based on deliverables (features) within a process context (ETVX). This approach is consistent with best practices in software project management and has the additional benefit of assuring that what gets designed and built is what the customer needs. Bolt FDD onto your favorite methodology and you'll probably see quality increase, and costs and time to deliver decrease.

See the collection of Feature-Driven Development articles for more detail.