Blue italics are guideline for description.
Executive summary is an introduction to the document. Do not dig deep into the technical details, but provide a comprehensive overview.
Revision | Date | Author | Description |
---|---|---|---|
Tag | Document name | Location of documents |
---|---|---|
Term | Mean |
---|---|
This section gives the reader's context regarding the design documentation.
This chapter describes the intended behavior of the software architecture and/or component under design by describing a certain usage of the component.
Use cases provide an initial view on the feature and they should set the scope of the design.
The description includes;
Use cases should describe the essential behavior instead of every detail.
Use cases may be layered in the description. ( e.g., you can decompose a feature and break it down into detailed use cases.)
Below table is a sample for use case description.
Use case ID {Add anchor} | |
Use Case | Use case name |
---|---|
Use Case Description | |
Actors | |
Pre-Condition | |
Post-Condition | |
Main Scenarios | |
Basic Path | |
Alternative Path | |
Exception Path |
This chapter shows functional and Non-functional requirements to be designed.
If there are any constraints to design, please describe them as well.
Describe the key design decisions and the reason.
Design decisions are usually carried out in order to fulfill quality attributes, that are might be described as non-functional requirements in previous chapter, that are appropriate for architecture and/or component.
Component under design should be seen as a black-box in diagram. Logical and process views should explain how the component is interacting with the rest of the system.
Interface, that includes data and function/method, provided by this component to be used by other components is described here.
If there are some restriction to use (e.g. order of use), they should be described with some diagrams.
Configuration parameter and/or configuration files also should be described here, if needed.
Describe the components that are related to the components under design.
It is recommended that the relevant components be described alogn with the interfaces used by the component under design to make the impact analysis more efficient.
the component under design is seen as white-box.
If there are multiple components to be designed, please repeat from section 8.2.1 to 8.2.3 for the number of designed components.
This section shows functional and Non-functional requirements to be designed in component level.
If there are any constraints to design, please describe them as well.
Please refer Section 6.2
Please refer Section 6.2
Component may have sub-parts and these sub-parts are packaged as different distributable units. Explain them here.