FDD Process 1: Develop an Overall Model

An initial project-wide activity with domain and development members working together under the
guidance of an experienced object modeller 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 modelled.
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 presents its
results for peer review and discussion one of the proposed models or a merge of the models 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.

Tasks

Form the Modelling Team Project Manager Required

The modelling 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
modelling sessions so that everyone gets a chance to participate and to see the process in action.

Conduct a Domain Walkthrough Modelling Team Required

A Domain Expert gives an overview of the domain area to be modelled this should include information
that is related to this domain area but not necessarily a part of its implementation.

Study Documents Modelling 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 Modelling 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 "straw man" 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 Modelling 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 modelling team selects one of
the proposed models or composes a model by merging ideas from the proposed models.

1
Refine the Overall Object Model Chief Architect, Modelling 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 Verification

Verification
Internal and External Assessment Modelling Team, Business Required

Domain Experts actively participating in the process provide internal or self-assessment.

Exit Criteria

To exit the process, the modelling 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.

2
FDD Process 2: Build a Features List
An initial project-wide activity to identify all the features needed to support the requirements.

A team usually comprising just the Chief Programmers from process I is formed to decompose the
domain functionally Based on the partitioning of the domain by the Domain Experts in process I. the
team breaks the domain into a number of areas (major feature sets) Each area is further broken into a
number of activities (feature sets) Each step within an activity is identified as a feature. The result is a
hierarchically categorized features list.

Entry Criteria

• The modelling team has successfully completed FDD process 1, Develop an Overall Model.

Tasks

Form the Features List Team Project Manager, Development Manager Required

The features list team comprises the Chief Programmers from the modelling team in process 1.

Build the Features List Features List Team Required

Using the knowledge obtained from process 1, the features list team identifies features The team may
also use any existing reference or requirements documents, such as object models, functional
requirements (traditional or use-case format): and user guides.

Noting the source document against any features identified in this way this task is a simple functional
decomposition, starting with the partitioning of the domain used by the Domain Experts for their
domain area walkthroughs in process 1.
The domain is decomposed into areas (major feature sets) that comprise activities (feature sets) that
comprise features, each of which represents a step in an activity Features are granular functions
expressed in client-valued terms, using the naming template:

<action> <result><object>

For example, "calculate the total of a sale" and "calculate the total quantity sold by retail outlet
for an item description”.

Features are granular. A feature should take no more than two weeks to complete but not be so
granular as to be at the level of simple getter and setter operations. Two weeks is an upper limit; most
features take less than this amount of time.
When a step looks larger, the team breaks the step into smaller steps that then become features.

Verification

Internal and External Assessment Features List Team, Business Required

Feature List team members participating in the process provide internal or self-assessment.
External assessment is made on an as-needed basis by referring back to the Domain Experts from
the modelling team and business (users) for ratification or clarification or clarification of issues that
affect the features list.

3
Exit Criteria

To exit the process, the features list team must produce the features list to the satisfaction of the
Project Manager and Development Manager The features list consists of:

• A list of major feature sets (areas)

• For each major feature set, a list of feature sets (activities) within that major feature set

• A list of features for each feature set (activity), each representing a step in the activity of that feature
set.

4
FDD Process 3: Plan by Feature
An initial project-wide activity to produce the development plan. The Project Manager, Development
Manager, and Chief Programmers plan the order that the features are to be implemented, based on
feature dependencies, load across the development team, and the complexity of the features to be
implemented.
The main tasks in this process are not a strict sequence like many planning activities.
They are considered together, with refinements made from one or more tasks, then considering the
others again.
A typical scenario is to consider the development sequence, then consider the assignment of feature
sets to Chief Programmers and, in doing so, consider which of the key classes (only) are assigned to
which developers (remembering that a Chief Programmer is also a developer), When this balance is
achieved and the development sequence and assignment of feature sets to Chief Programmers is
essentially completed, the class ownership is completed (beyond the key classes that were already
considered for ownership).

Entry Criteria

• The features list team has successfully completed FDD process 2, Budd a Features List.

Tasks

Form the Planning Team Project Manager Required

The planning team consists of the Project Manager, Development Manager, and Chief Programmers.

Determine the Development Sequence Planning Team Required

The planning team assigns a date (month and year only) for completion of each feature set.
The identification of the feature set and the completion date (and, thus, the development sequence) is
based on:

• Dependencies between features in terms of classes involved

• Balancing of load across class owners

• Complexity of the features to be implemented

• Bringing forward of high-risk or complex feature sets

• Consideration of any external (visible) milestones, such as betas, previews, feedback checkpoints,
and the "whole products" that satisfy such milestones.

Assign Feature Sets to Chief Programmers Planning Team Required

The planning team assigns Chief Programmers as owners of feature sets, the assignment is based
on:

• Development sequence.

• Dependencies between features in terms of classes involved.

• Balancing of load across class owners (remembering that Chief Programmers are also class
owners).

• Complexity of the features to be implemented.

5
Assign Classes to Developers Planning Team Required

The planning team assigns developers as class owners. Developers own multiple classes.

The assignment of classes to developers is based on:

• Balancing of load across developers.

• Complexity of the classes.

• Expected usage (e.g., high use) of the classes.

• Development sequence.

Verification

Self-Assessment Planning Team Required

The planning is a team activity, so self-assessment is achieved by the active participation of the
Project Manager and Development Manager with the Chief Programmers, who use the knowledge
they gained from process I to help make better informed decisions.

Exit Criteria

To exit the process, the planning team must produce the development plan to the satisfaction of the
Project Manager and Development Manager. The development plan consists of:

• Feature sets with completion dates (month and year).

• Major feature sets with completion dates (month and year) derived from the last completion date of
their respective feature sets.

• Chief Programmers assigned to feature sets.

• The list of classes and the developers that own them (the class owner list).

6
FDD Process 4: Design by Feature
A per-feature activity to produce the feature(s) design package.

A number of features are scheduled for development by assigning them to a Chief Programmer. The
Chief Programmer selects features for development from his or her "inbox" of assigned features.
Operationally, it is often the case that the Chief Programmer schedules small groups of features at a
time for development. He or she may choose multiple features that happen to use the same classes
(therefore, developers). Such a group of features forms a Chief Programmer Work Package.

The Chief Programmer then forms a feature team by identifying the owners of the classes
(developers) likely to be involved in the development of the selected feature(s).
This team produces the detailed sequence diagram(s) for the selected feature(s).
The Chief Programmer then refines the object model, based on the content of the sequence
diagrams.

The developers write class and method prologues. A design inspection is held.

Entry Criteria

• The planning team has successfully completed FDD process 3. Plan by Feature.

Tasks

Form a Feature Team Chief Programmer Required

The Chief Programmer identifies the classes likely to be involved in the design of this group of
features.
From the class ownership list, the Chief Programmer identifies the developers needed to form the
feature team. As part of this step, the Chief Programmer starts a new design package for the
feature(s) as part of the work package.

Conduct a Domain Walkthrough Domain Expert Optional.

At the request of the Chief Programmer, a Domain Expert walks the feature team through details of
algorithms, rules, formulas, and data elements needed for the feature to be designed.
This is an optional task, Based on the complexity of the feature and/or its interactions.

Study the Referenced Documents Feature Team Optional.

The feature team studies the documents referenced in the features list for the feature(s) to be
designed and any other pertinent documents, including any confirmation memos, screen designs, and
external system interface specifications.
This is an optional task, based on the complexity of the feature and/or its interactions and the
existence of such documents.

Develop the Sequence Diagram(s) Feature Team Required

The feature team develops the detailed sequence diagram(s) required for each feature being
designed. The team writes up and records any alternative designs, design decisions, assumptions,
requirements clarifications, and notes in the design alternatives or notes section of the design
package.

7
Refine the Object Model Chief Programmer Required

The Chief Programmer creates a feature team area for the feature(s). This area is either a directory
on a file server, a directory on his or her personal computer (backed up by the Chief Programmer, as
required), or utilizes work area support in the project's version control system The feature team uses
the feature team area to share work in progress and make it visible among the feature team but not to
the rest of the project.
The Chief Programmer refines the model to add additional classes, operations, and attributes and/or
to make changes to existing classes, operations, or attributes, based on the sequence diagram(s)
defined for the feature(s). The associated implementation language source files are updated (either
manually or automatically by some tool) in the feature team area The Chief Programmer creates
model diagrams in a publishable format.

Write Class and Method Prologue Feature Team Required

Using the updated implementation language source files from the "Refine the Object Model" task in
the feature team area, each class owner writes the class and method prologues for each item defined
by the feature and sequence diagram(s). This includes parameter types, return types, exceptions, and
messages.

Design Inspection Feature Team Required

The feature team conducts a design inspection, either before or after the unit test task other project
members may participate; the Chief Programmer makes the decision to inspect within the feature
team or with other project team members.
On acceptance, a to-do list is created per affected class, and each team member adds his or her
tasks to their to-do list.

Verification

Design Inspection Feature Team Required

A successful design inspection is the verification of the output of this process. The design inspection
task is described above.

Exit Criteria

To exit the process, the feature team must produce a successfully inspected design package.
The design package comprises:

• A covering memo, or paper, that integrates and describes the design package so that it stands on its
own for reviewers.

• The referenced requirements (if any) in the form of documents and all related confirmation memos
and supporting documentation.

• The sequence diagrams(s).

• Design alternatives (if any).

• The object model with new/updated classes, methods, and attributes.

• The <your tools-generated output for the class and method prologues created or modified by this
design.

• The to-do task-list entries for action items on affected classes for each team member.

8
FDD Process 5: Build by Feature
A per-feature activity to produce a completed client-valued function (feature) Working from the design
package produced during the Design by Feature process, the class owners implement the items
necessary for their classes to support the design for the feature(s) In the work package.

The code developed is then unit-tested and code inspected, the order of which is determined by the
Chief Programmer After a successful code inspection, the code is promoted to the build.

Entry Criteria

• The feature team' has successfully completed FDD process 4, Design by Feature, for the selected
feature(s) That is, the design package from process 4 has been successfully inspected

Tasks

Implement Classes and Methods Feature Team Required

The class owners implement the items necessary to satisfy the requirements on their classes for the
feature(s) in the work package This includes the development of any unit testing code needed.

Conduct a Code Inception Feature Team Required

The feature team conducts a code inspection, either before or after the unit test task The Chief
Programmer decides whether to inspect within the feature team or with other project team members.
The decision to inspect before or after unit test is also that of the Chief Programmer.

Unit Test Feature Team Required

Each class owner tests their code to ensure that all requirements on their classes for the feature(s) in
the work package are satisfied The Chief Programmer determines what. If any, feature team-level unit
testing is required-in other words, what testing across the classes developed for the feature(s) is
required

Promote to the Build Chief Programmer, Feature Team Required

Classes can be promoted to the build only after a successful code inspection and unit test The Chief
Programmer is the integration point for the entire feature(s) and responsible for tracking the promotion
of the classes involved (either by promoting them personally or through feedback from the developers
in the feature team).

Verification

Code Inspection and Unit Test Chief Programmer, Feature Team Required

A successful code inspection plus the successful completion of unit test is the verification of the output
of this process. The code inspection and unit test tasks are described above.

Exit Criteria

To exit the process, the feature team must complete the development of one or more whole features
(client-valued functions) To do this, it must have promoted to the build the set of new and enhanced
classes that support those features, and those classes must have been successfully code-inspected
and unit-tested.