Motorola. It is described more in-depth recently in books such as A Practical Guide to Feature-Driven Development and parts of Agile Management for Software Engineering. The five processes of FDD are:
• Develop an overall model
• Build a features list
• Plan by feature
• Design by feature
• Build by feature
These processes are described using traditional entry task verify exit-based process descriptions. FDD can be done by itself for substantial projects with modest-sized teams. For much larger projects and many teams, the overall FDD method fits quite nicely inside larger systems development models where market-level and system-level technical requirements have already been produced, and where some kind of independent V&V/QA activity takes place after development releases a production-candidate version of the software.
FDD can begin with high-level system requirements in place or with the domain modeling to build the initial shared understanding of what the overall system is and must accomplish. In either event, FDD has other roles that are more formally defined than many of the other agile methods, employing a chief architect, chief programmers, project managers (along with domain experts, developers (who serve as class-owners). It also has several other supporting roles such as build and release managers, to create an overall domain model, partition the system up into features, feature-teams and objects, and also develop, build and deliver the results in an incremental and iterative manner.