.: Functional Design
Once the external design is accepted by stakeholders, the next step is to specify how functionality is to be implemented and how the external elements and business logic relate to each other, to databases, and to external systems.
Here it is important to remember the “rule of necessity”, and to provide sufficient specification, but not more than is needed. It’s crucial to realize that “sufficient” in this case refers to “which information” is provided, not “how much.”
A good example of this distinction is often seen when designing reports. Many reports provide users with interpretations of data. These interpretations transform “raw” data into meaningful values corresponding to domain terminology. It is essential to specify this transformation with complete precision—not in terms of how it is done, but in terms of what is done. This is “sufficient.” It may also be appropriate to state how the transformation is to occur, but the designer must distinguish between the necessity of “what” and the possible convenience of “how.”
Discovery / Requirements
Problem Domain
Risks
Architecture
External Design
Functional Design
Implementation
Quality Assurance
|
