1 INTRODUCTION
1.1 Purpose
Identify the purpose of this SDD and its intended audience. (e.g. "This software designdocument describes the architecture and system design of XX. ....").
1.2 Scope
Provide a description and scope of the software and explain the goals, objectives and benefitsof your project. This will provide the basis for the brief description of your product.
1.3 Overview
Provide an overview of this document and its organization.
1.4 Reference Material
This section is optional.
List any documents, if any, which were used as sources of information for the test plan.
1.5 Definitions and Acronyms
This section is optional.
Provide definitions of all terms, acronyms, and abbreviations that might exist to properlyinterpret the SDD. These definitions should be items used in the SDD that are most likely notknown to the audience.
2 SYSTEM OVERVIEW
Give a general description of the functionality, context and design of your project. Provide anybackground information if necessary.
3 SYSTEM ARCHITECTURE
3.1 Architectural Design
Develop a modular program structure and explain the relationships between the modules toachieve the complete functionality of the system. This is a high level overview of howresponsibilities of the system were partitioned and then assigned to subsystems. Identify eachhigh level subsystem and the roles or responsibilities assigned to it. Describe how thesesubsystems collaborate with each other in order to achieve the desired functionality. Don't gointo too much detail about the individual subsystems. The main purpose is to gain a generalunderstanding of how and why the system was decomposed, and how the individual partswork together. Provide a diagram showing the major subsystems and data repositories andtheir interconnections. Describe the diagram if required.
3.2 Decomposition Description
Provide a decomposition of the subsystems in the architectural design. Supplement with text as needed. You may choose to give a functional description or an objectoriented description. For a functional description, put toplevel data flow diagram (DFD) and structural decomposition diagrams. For an OO description, put subsystem model, object diagrams, generalization hierarchy diagram(s) (if any), aggregation hierarchy diagram(s) (if any), interface specifications, and sequence diagrams here.
3.3 Design Rationale
Discuss the rationale for selecting the architecture described in 3.1 including critical issuesand trade/offs that were considered. You may discuss other architectures that wereconsidered, provided that you explain why you didn't choose them.
4 DATA DESIGN
4.1 Data Description
Explain how the information domain of your system is transformed into data structures.Describe how the major data or system entities are stored, processed and organized. List anydatabases or data storage items.
4.2 Data Dictionary
Alphabetically list the system entities or major data along with their types and descriptions. Ifyou provided a functional description in Section 3.2, list all the functions and functionparameters. If you provided an OO description, list the objects and its attributes, methods andmethod parameters.
5 COMPONENT DESIGN
In this section, we take a closer look at what each component does in a more systematic way. Ifyou gave a functional description in section 3.2, provide a summary of your algorithm for eachfunction listed in 3.2 in procedural description language (PDL) or pseudocode. If you gave anOO description, summarize each object member function for all the objects listed in 3.2 in PDLor pseudocode. Describe any local data when necessary.
6 HUMAN INTERFACE DESIGN
6.1 Overview of User Interface
Describe the functionality of the system from the user's perspective. Explain how the userwill be able to use your system to complete all the expected features and the feedbackinformation that will be displayed for the user.
6.2 Screen Images
Display screenshots showing the interface from the user's perspective. These can be handdrawnor you can use an automated drawing tool. Just make them as accurate as possible.
(Graph paper works well.)
6.3 Screen Objects and Actions
A discussion of screen objects and actions associated with those objects.
7 REQUIREMENTS MATRIX
Provide a crossreferencethat traces components and data structures to the requirements in yourSRS document.Use a tabular format to show which system components satisfy each of the functionalrequirements from the SRS. Refer to the functional requirements by the numbers/codes that yougave them in the SRS.
8 APPENDICES
This section is optional.
Appendices may be included, either directly or by reference, to provide supporting details that could aid in the understanding of the Software Design Document.