[ Project

Software Design Specification

Draft X April 26, 2014

[ Team Name ] [ Paste Your Team’s Logo Here ]

$or %S&'((. this document captures the fundamental design information necessary to produce a good design and to document your design decisions for future customer use. to show in one place a broad but shallow stro e of the type of design information the projects should capture. most projects should not constrain their system design to a single document.[Paste your logo here] [ Organization Name ] [ Project ] . This template is only a starting point. the material in this template is intended to be repac aged into multiple documents. Page i . #nstead this template provides a basic starting point that will wor well in many situations. We do so here for convenience. Designs for software systems should be customized to the needs project building the system. and augmented for the needs of each project. This template does not imply that a single document should contain all design information or that the approach and structure for a design described here is the best for any given situation.Software Design Specification Revisions Version Draft Type an !um"er Primary Author(s) #ull !ame Description of Version $nformation a"out the re%ision& This ta"le oes not nee to "e fille in whene%er a ocument is touche ' only when the %ersion is "eing upgra e & Date Completed (()(()(( The paragraphs written in the “Comment” style are for the benefit of the person writing the document and should be removed before the document is finalized This template serves as a basis for a Software Design Specification. " formulaic approach to design will seldom yield the best results. Thus although it is organized such that it can be a single stand!alone document. reorganized.

-$*. . +!C-$T"CT(!" .[Paste your logo here] [ Organization Name ] [ Project ] ./"#"/ '"%$*N 0 /O1 /"#"/ '"%$*N 2 (%"! $NT"!3+C" '"%$*N $ $$ & ) .Software Design Specification Contents !"#$%$ON% CONT"NT% & $NT!O'(CT$ON ) '"%$*N CON%$'"!+T$ON% . 0 2 Page ii .

" #ystem $vervie% )rief high!level description of system structure. Page * . provide a brief summary of each.Software Design Specification !ntroduction This space may be used to provide an introduction for the design and ties to other project materials. "* Definitions and Acronyms -.ptional/ 0 4ist any project definitions and acronyms introduced to the project by this design. interactions with e*ternal systems. if this design re+uired interfacing with 2(3 hardware devices.[Paste your logo here] [ Organization Name ] [ Project ] . #f you wrote a good overview for the project plan and re+uirements document. then this is a simple paste job. $or &'(( this is the only design document you are re+uired to produce. ") #upportin' (aterials -. then you would want a reference the 2(3 specification.ptional/ 0 1ote any references or related materials here.or major sections of this document and if appropriate. Discuss any significant relationships between design artifacts and other project artifacts. $or instance. "& Desi'n (ap Summarize the information contained within this document or the family of design artifacts. system issues. Define all major design artifacts and. etc. functionality.

ptional/ ! Describe any notably volatile or ris y areas of the system and not any special strategies ta en to mitigate ris s or prepare for changes. conventions.Software Design Specification & Desi'n Considerations This section describes issues that need to be addressed or resolved prior to or while completing the design as well as issues that may influence the design process. end user characteristics. bac ground. formal specification or other specific methodologies. Ris-s and Volatile Areas -./ &") #ystem +nvironment Describe the hardware and software that the system must operate in and interact with. 5ost people will use some object!oriented techni+ue with 654. &" Assumptions Describe any assumption. This is not a rehash of your project lifecycle or change management. %over any processes. This is ris s specific for the design 7not project management type stuff. $or instance if there is an algorithm that is especially difficult that you must implement. This is for deciding whether you will use structured. performance re+uirements. object!oriented. or dependencies of the software. or significant project issues. policies. &". &"* Desi'n (ethodolo'y -. technology constraints./ These are things the customer has told you that directly influence the design -the database must be an open!source freely available D)5S. -e. that directly affect the design. &"& Constraints Describe any constraints on the system that have a significant impact on the design of the system. validation re+uirements. etc. These are things you are assuming to be true. its use. techni+ues or other issues which will guide design wor .[Paste your logo here] [ Organization Name ] [ Project ] .g. Page + . the operational environment.ptional/ ! Summarize the approach that will be used to create and evolve the designs for this system. project constraints.

)" $vervie% This section provides a high level overview of the structural and functional decomposition of the system.ptional/ #f your team does not need section 8. )"& Rationale This section discusses why you are using the architecture you have decided upon.Software Design Specification ) Architecture The architecture provides the top level design view of a system and provides a basis for more detailed design wor . . $ocus on how and why the system was decomposed in a particular way rather than on details of the particular components. then include here a summary of the operation of each major component and how it interacts with other elements in the architecture.[Paste your logo here] [ Organization Name ] [ Project ] . )") Component Details -. Page . These are the top level components of the system you are building and their relationships. #nclude information on the major responsibilities and roles the system -or portions thereof/ must play.

c. d. The components are typically files or directories. This view shows the logical functional elements of the system. b. 1ormally this section would be split into separate documents for different areas of the design. 9igh!level designs are most effective if they attempt to model groups of system elements from a number of different views. #f you have only a single view.ach component represents a similar grouping of functionality. we use this single document. <rocess: this view is the runtime view of the system.. The components are physical processors that have parts of the system running on them. . $or 654. Security: this view typically focuses on the components that cooperate to provide security features of the system. 5odule: this view is for project management and code organization. it is not necessary to document all these views. $or &'((. $or 654. #t is often a subset of the %onceptual view.[Paste your logo here] [ Organization Name ] [ Project ] . this would be a component diagram or a pac age diagram. %onceptual or 4ogical: this is the view most often used in Section &. The components are threads or processes or distributed applications.i'h /evel Desi'n This section describes in further detail elements discussed in the "rchitecture. <hysical: this view is for distributed systems. $or &'((. Typical viewpoints are: a. $or many smaller applications. and that view is discussed ade+uately in section &. Document those views that will help you design and implement the system. Page - .Software Design Specification * . *" Conceptual Vie% <rovide a description and diagrams of a system element or set of elements that describes a clearly defined view or model of the entire system or a subset of the system. then this entire section can be deleted. e. this would be a process interaction diagram. the conceptual view is all that is necessary. This picture shows how the directory structure of the build and development environment will be designed. this would be a deployment diagram. #n 654.

Page . 1ormally this section would be split into separate documents for different areas of the design. you may have a single 654 class diagram that each module description refers to.( or &/ we should develop a 654 class diagram that represents the static class structure.[Paste your logo here] [ Organization Name ] [ Project ] . $or each component we now need to brea it down into its fundamental units or modules. Then the low level design will ta e each pac age and brea it down into its classes. . implementation in =ava. $or each pac age in the %onceptual >iew -from 8.. $or smaller systems. We should also show 654 state and interaction diagrams to show dynamic interaction between classes. our components would become pac ages. /o% /evel Desi'n This section provides low!level design descriptions that directly support construction of modules. .Software Design Specification . $or an ." (odule ""n <rovide or reference a detailed description and diagrams of this software module.

" screen transition diagram or table can optionally be created to illustrate the flow of control through the various screens. status bar. title bars. popup menus. %ommon loo and feel details such as menus.[Paste your logo here] [ Organization Name ] [ Project ] .Software Design Specification 0 1ser !nterface Desi'n This section provides user interface design descriptions that directly support construction of user interface screens. Page / . 0"& #creen ""n #llustrate all major user interface screens and describe the behavior and state changes that the user will e*perience. This does not have to be actual screenshots. drag and drop mouse behavior should be described here. 0" Application Control Detail the common behavior that all screens will have. toolbars. after all you haven?t actually implemented the application yet right@ They can be powerpoint drawings or moc ups created in >isual )asic or some other rapid A6#!building tool.

Sign up to vote on this title
UsefulNot useful