SoftwareDesignDocument(SDD)Template

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 preliminarydesigninwhichtheoverallsystemarchitectureanddataarchitecture isdefined.Inthe secondstage, i.e.thedetaileddesignstage, moredetaileddata structuresaredefinedandalgorithmsaredevelopedforthedefinedarchitecture. 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 componentsandprovidingageneral ideaofaprojectdefinitionreport.Foryour 1 own information, please refer to IEEE Std 10161998 for the full IEEE RecommendedPracticeforSoftwareDesignDescriptions.

http://www.cs.concordia.ca/~ormandj/comp354/2003/Project/ieeeSDD.pdf

(TeamName) (ProjectTitle) SoftwareDesignDocument

Name(s): LabSection: Workstation:

Date:(mm/dd/yyyy)

SoftwareDesignDocument

TABLEOFCONTENTS
1. INTRODUCTION 2 2 2 2 2 2 2 2 2 3 3 3 3 3 3 4 4 4 4 4 4

1.1 Purpose 1.2 Scope 1.3 Overview 1.4 ReferenceMaterial 1.5 DefinitionsandAcronyms 2. 3. SYSTEM OVERVIEW SYSTEM ARCHITECTURE

3.1 ArchitecturalDesign 3.2 DecompositionDescription 3.3 DesignRationale 4. DATADESIGN

4.1 DataDescription 4.2 DataDictionary 5. 6. COMPONENTDESIGN HUMANINTERFACEDESIGN

6.1 OverviewofUserInterface 6.2 ScreenImages 6.3 ScreenObjectsandActions 7. 8. REQUIREMENTS MATRIX APPENDICES

SoftwareDesignDocument

1.INTRODUCTION
1.1 Purpose
Identify the purpose of this SDD and its intended audience. (e.g. This software design documentdescribesthearchitectureandsystemdesignofXX..).

1.2 Scope
Provideadescriptionandscopeofthesoftwareandexplainthegoals,objectivesandbenefits ofyourproject.Thiswillprovidethebasisforthebriefdescriptionofyourproduct.

1.3 Overview
Provideanoverviewofthisdocumentanditsorganization.

1.4 ReferenceMaterial
Thissectionisoptional.
Listanydocuments,ifany,whichwereusedassourcesofinformationforthetestplan.

1.5 DefinitionsandAcronyms
Thissectionisoptional. Provide definitions of all terms, acronyms, and abbreviations that might exist to properly interprettheSDD.ThesedefinitionsshouldbeitemsusedintheSDDthataremostlikelynot knowntotheaudience.

2. SYSTEMOVERVIEW
Giveageneraldescriptionofthefunctionality,contextanddesignofyourproject.Provideany backgroundinformationifnecessary.

3.SYSTEMARCHITECTURE
3.1 ArchitecturalDesign
Developa modularprogramstructureandexplaintherelationships betweenthe modulesto achieve the complete functionality of the system. This is a high level overview of how
2

SoftwareDesignDocument

responsibilitiesofthesystemwerepartitionedandthenassignedtosubsystems.Identifyeach high level subsystem and the roles or responsibilities assigned to it. Describe how these subsystemscollaboratewitheachotherinordertoachievethedesiredfunctionality.Dontgo intotoomuchdetailabouttheindividualsubsystems.Themainpurposeistogainageneral understanding of how and why the system was decomposed, and how the individual parts worktogether.Provideadiagram showingthemajorsubsystemsanddatarepositoriesand theirinterconnections.Describethediagramifrequired.

3.2 DecompositionDescription
Provideadecompositionofthesubsystemsinthearchitecturaldesign.Supplementwithtext asneeded.Youmaychoosetogiveafunctionaldescriptionoranobjectorienteddescription. 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), interfacespecifications,andsequencediagramshere.

3.3 DesignRationale
Discusstherationaleforselectingthearchitecturedescribedin3.1includingcritical issues and trade/offs that were considered. You may discuss other architectures that were considered,providedthatyouexplainwhyyoudidntchoosethem.

4.DATADESIGN
4.1 DataDescription
Explainhowtheinformationdomainofyoursystemistransformedintodatastructures. Describehowthemajordataorsystementitiesarestored,processedandorganized.Listany databasesordatastorageitems.

4.2 DataDictionary
Alphabeticallylistthesystementitiesormajordataalongwiththeirtypesanddescriptions.If you provided a functional description in Section 3.2, list all the functions and function parameters.IfyouprovidedanOOdescription,listtheobjectsanditsattributes,methodsand methodparameters.

5.COMPONENTDESIGN
Inthissection,wetakeacloserlookatwhateachcomponentdoesinamoresystematicway.If
3

SoftwareDesignDocument

yougaveafunctionaldescriptioninsection3.2,provideasummaryofyouralgorithmforeach function listed in 3.2 in procedural description language (PDL) or pseudocode.If you gave an OOdescription,summarizeeachobjectmemberfunctionforalltheobjectslistedin3.2inPDL orpseudocode.Describeanylocaldatawhennecessary.

6.HUMANINTERFACEDESIGN
6.1 OverviewofUserInterface
Describe the functionality of the system from the users perspective. Explain how the user will be able to use your system to complete all the expected features and the feedback informationthatwillbedisplayedfortheuser.

6.2 ScreenImages
Display screenshots showing the interface from the users perspective. These can be hand drawnor youcanuseanautomateddrawingtool.Just makethemas accurateaspossible. (Graphpaperworkswell.)

6.3 ScreenObjectsandActions
Adiscussionofscreenobjectsandactionsassociatedwiththoseobjects.

7.REQUIREMENTSM ATRIX
Provideacrossreferencethattracescomponentsanddatastructurestotherequirementsinyour SRSdocument. Use a tabular format to show which system components satisfy each of the functional requirementsfromtheSRS.Refertothefunctionalrequirementsbythenumbers/codesthatyou gavethemintheSRS.

8.APPENDICES
Thissectionisoptional.
4

SoftwareDesignDocument Appendicesmaybeincluded,eitherdirectlyorbyreference,toprovidesupportingdetailsthatcould aidintheunderstandingoftheSoftwareDesignDocument.