The first 'process' in the five FDD process descriptions.

An initial project-wide activity with domain and development members working together under the guidance of an experienced object modeler in the role of Chief Architect.

Domain Experts perform a high-level walkthrough of the scope of the system and its context. They then perform detailed domain walkthroughs for each area of the domain that is to be modeled. After each domain walkthrough, small groups are formed with a mix of domain and development staff. Each small group composes its own model in support of the domain walkthrough and pre-sents its results for peer review and discussion. One of the proposed models or a merge of the mod-els is selected by consensus and becomes the model for that domain area. The domain area model is merged into the overall model, adjusting model shape as required.

The object model is then updated iteratively with content by process 4, Design by Feature.

Entry Criteria

  • Domain Experts, Chief Programmers, and the Chief Architect have been selected for the project.


Form the Modeling Team Project Manager Required
The modeling team consists of permanent members from the domain and development areas, specifically, the Domain Experts and the Chief Programmers. Rotate other project staff through the modeling sessions so that everyone gets a chance to participate and to see the process in action.

Conduct a Domain Walkthrough  Modeling Team Required
A Domain Expert gives an overview of the domain area to be modeled. This should include information that is related to this domain area but not necessarily a part of its implementation.

Study Documents Modeling Team Optional
The team studies available reference or requirements documents, such as object models, functional requirements (traditional or use-case format), and user guides.

Develop Small Group Models Modeling Team in Small Groups Required
Forming groups of no more than three, each small group composes a model in support of the domain area. The Chief Architect may propose a "strawman" model to facilitate the progress of the teams. Occasionally, the groups may also sketch one or more informal sequence diagrams to test the model shape.

Develop a Team Model Modeling Team Required
A member from each small group presents that group's proposed model for the domain area. The Chief Architect may also propose further model alternatives. The modeling team selects one of the proposed models or composes a model by merging ideas from the proposed models.

Refine the Overall Object Model Chief Architect, Modeling Team Required
Every so often, the team updates the overall object model with the new model shapes produced by iterations of the previous two tasks.

Write Model Notes Chief Architect, Chief Programmers Required
Notes on detailed or complex model shapes and on significant model alternatives are made for future reference by the project.


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

Exit Criteria

To exit the process, the modeling team must produce an object model to the satisfaction of the Chief Architect. The object model consists of:

  • Class diagrams focusing on model shape, the classes in the domain, how are they connected to one another and under what constraints, plus any operations and attributes identified.
  • Sequence diagram(s),if any.
  • Notes capturing why a particular model shape was chosen and/or what alternatives were considered.

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...