The goal of detailed design is to define a blueprint for the development of the project.
The frameworks and tools identified by the system architecture design are incorporated into the "how to" of the detailed design.
The functional specification defines the requirements of the system to be built and is referred to in the design document where specific design decisions relate to a requirement.
The analysis document specifies the functionality of the system and serves as a starting point for the detailed design document. The detailed design document expands and adds to the analysis document.
The detailed design document is used primarily by the development, testing, deployment, and maintenance teams.
| Business specification |
| Functional specification |
| Development plan |
| Analysis document |
| System architecture design document |
| Detailed Design Plan template |
| Detailed Design template |
| Unit Test Plan methodology and/or templates |
| Module Test Plan methodology and/or templates |
| Detailed design plans |
| Detailed design document |
| Refinements to the system architecture design |
| Unit Test Plan |
| Module Test Plan |
A formal review must be performed to ensure that the results of the detailed design phase are consistent with the goals specified in the business and functional specifications and analysis document.
In addition to the formal review, each team involved in detailed
design should perform their own incremental reviews to ensure that they are staying on
track or to determine that the earlier documents may need revision.
Development teams and directors of development.
| The parallel activities of each development team will have been specified in the development plan. Each team is then responsible for planning their time within those parameters. Specifically, each team should set up finer grain milestones for completing portions of their assignments. Iteration should be considered and planned for as well. The team leader in each team will be responsible for ensuring that each team member is on schedule and progressing as planned. |
| The detailed design plans will be approved by the directors of development. |
The detailed design document should contain the following:
| User interface appearance and behavior design - should be a three
phase attack:
|
| User interface implementation design |
| This design plans the implementation of the required behavior of the each interface, report, etc. |
| This design incorporates visual frameworks such as the Smalltalk GUI classes or Visual C++/MFC. |
| System operation design |
This design plans the implementation of the system's response to incoming events, exceptions, and other functionality of the system. It is how the system responds to commands from the user interfaces or from messages coming from network connections.
| Persistence design |
Incorporates the purchased, or built, database frameworks into the design.
Requires additional detail in the design object model and dynamic diagrams (life cycle models, state transition diagrams, etc.).
| Distributed design |
This design breaks out distributed components from the monolithic view of the system and incorporates the distributed frameworks.
| Concurrency and locking design |
In a distributed system, concurrency and locking issues are extremely important. Frameworks, such as CORBA, must be integrated into the design. These types of frameworks will be the responsibility of the system framework team but will be incorporated into the detailed design.
| Test plans for class and module tests. |
| Help system design. |
| Installation design. |
| Administration, user options, and supporting tools design. |
As in Analysis, the development methodology drives the documentation that is produced. The Fusion methodology includes the following types of documentation and notation that can be used to create the detailed design document:
| Object interaction graphs |
| Visibility graphs |
| Class dictionary (must define individual classes, purpose of hierarchies of classes, clusters of classes, and frameworks) |
| Design object model |
Additional diagrams may be borrowed from other methodologies if necessary. In particular, state transition diagrams and data flow diagrams from the OMT methodology and the use case diagrams from OOSE can be of use in adding design detail.
The detailed design is likely to uncover areas in analysis that were not fully covered and may require iteration on that set of documentation.
Iteration and parallel activities will occur during design. For large systems design, work will broken into teams by sub-system and/or by architecture layers. Each team will be iterating through their portion of the project in parallel. This parallel activity requires a great deal of coordination by the team leaders and directors. It also requires reviews by system architects across teams. The system architects of all teams work together to ensure consistency and reuse in the development effort.
Business Specification Analysis Detailed Design Testing Post Study Functional Specification Architecture Design Implementation Deployment and Maintenance HOME