You are on page 1of 13

Software Design Document (SDD

)
Software design is a process by which the software requirements are translated into a representation of software components, interfaces, and data necessary for the implementation phase. The SDD shows how the software system will be structured to satisfy the requirements. It is the primary reference for code development and, therefore, it must contain all the information required by a programmer to write code. The SDD is performed in two stages. The first is a preliminary design in which the overall system architecture and data architecture is defined. In the second stage, i.e. the detailed design stage, more detailed data structures aredefined and algorithms are developed for the defined architecture. This template is an annotated outline for a software design document adapted from the IEEE Recommended Practice for Software Design Descriptions. The IEEE Recommended Practice for Software Design Descriptions have been reduced in order to simplify this assignment while still retaining the main components and providing a general idea of a project definition 1 report. For your own information, please refer to IEEE Std 10161998 for the full IEEE Recommended

3 DesignRationale 3 4.1 OverviewofUser Interface 4 6. COMPONENT DESIGN 3 6. SYSTEM OVERVIEW 2 3.1 ArchitecturalDesign 2 3.TABLE OF CONTEN*TS 1.3 ScreenObjectsand Actions 4 7. SYSTEM ARCHITECTURE 2 3. INTRODUCTION 2 1.2 Scope 2 1.1 Purpose 2 1.3 Overview 2 1.1 Data Description 3 4.2 Data Dictionary 3 5. APPENDICES 4 . HUMAN INTERFACE DESIGN 4 6.4 Reference Material 2 1. DATA DESIGN 3 4.2 DecompositionDescription 3 3.5 Definitions and Acronyms 2 2. REQUIREMENTS MATRIX 4 8.2 ScreenImages 4 6.

Provide any background information if necessary. This is a high level overview of how responsibilities of the systemwere partitioned and thenassigned to subsystems.4 Reference Material This section is optional. Teacher and administrator a student can access his/her result whereas a teacher can enter the marks of a student . an administrator can change the data of student or teacher 1. There are three kind of users in this software Student.1.3 Overview This Software is designed for school / colleges for result management. Provide definitions of all terms. 3. SYSTEM OVERVIEW Give a general description of the functionality. which were used as sources of information for the test plan. 1. SYSTEM ARCHITECTURE 3. List any documents. . if any.1 Architectural Design Develop a modular program structure and explain the relationships between the modules to achieve the complete functionality of the system. 2.2 Scope The scope of this software for is to further upgrade for university or any public school management siftware 1. and abbreviations that might exist to properly interpret the SDD. acronyms. context and design of your project. These definitions should be items used in the SDD that are most likely not knownto the audience. Identifyeach high level subsystem and the roles or responsibilities assigned to it. INTRODUCTION 1.5 Definitions and Acronyms This section is optional.1 Purpose The Prime purpose of this software is to give school/colleges a automatic result management system which will automatically calculate the grading system 1.

Describe how these subsystems collaborate witheachother inorder to achieve the desired functionality. and how the individual parts work together. Describe the diagram if required. The main purpose is to gain a general understanding of how and why the system was decomposed. . Provide a diagram showing the major subsystems and data repositories and their interconnections. Don’t go into too much detail about the individual subsystems.

3. Student Registrat ion Student Detail Admin Registrat ion Teacher details Teacher Registration User Result management login Activate / Deactivate Enter result/ view result result .2 Decomposition Description DFD shows the entire system under Investigation.

3 Design Rationale Not required 4. DATA DESIGN .3.

User New user Admin Home Pages New user address admin Creates new Teacher/Student creates new View Student result .

5.1 Standards Compliance Report is of student marks obtain and grade Data naming is listed below Table 6: login Data Type Field Name U_name U_pass U_type Table 12: Student Data Type Nvarchar Nvarchar Nvarchar Field Name St_id st_name st_fname st_add st_cno st_qual st_pass st_dttm Number Nvarchar Nvarchar Nvarchar Nvarchar Nvarchar Nvarchar Nvarchar .5 Design Constraints Not aplicable 3.3.

Table 13: Teacher Data Type Field Name t_id t_name t_fname t_add t_cno t_qual t_pass t_dttm Number Nvarchar Nvarchar Nvarchar Nvarchar Nvarchar Nvarchar Nvarchar 5. COMPONENT DESIGN Not required .

2 Screen Images . HUMAN INTERFACE DESIGN 6.6.1 Overview of User Interface There are three type of home pages for teacher. for student and for administration other menu comes under these pages 6.

.

3 Screen Objects and Actions Not required. . REQUIREMENTS MATRIX Not required 8.6. APPENDICES This section is optional. 7.

.Appendices may be included. to provide supporting details that could aid in the understanding of the Software Design Document. either directly or by reference.