Docstoc

sds

Document Sample
sds Powered By Docstoc
					           [ Project ]

Software Design Specification



               Draft X

          October 19, 2011




           [ Team Name ]

   [ Paste Your Team’s Logo Here ]
[Paste your logo here] [ Organization Name ]                      [ Project ] - Software Design Specification


                                               Revisions

 Version        Primary             Description of Version                                    Date
                Author(s)                                                                   Completed
 Draft Type     Full Name           Information about the revision. This table does not        00/00/00
 and                                need to be filled in whenever a document is
 Number                             touched, only when the version is being upgraded.




 The paragraphs written in the “Comment” style are for the benefit of the person writ-
      ing the document and should be removed before the document is finalized.


This template serves as a basis for a Software Design Specification.
Designs for software systems should be customized to the needs project building the system.
This template is only a starting point; most projects should not constrain their system design
to a single document. We do so here for convenience, to show in one place a broad but shal-
low stroke of the type of design information the projects should capture.
Thus although it is organized such that it can be a single stand-alone document, the material
in this template is intended to be repackaged into multiple documents, reorganized, and aug-
mented for the needs of each project.
A formulaic approach to design will seldom yield the best results. 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. Instead this template
provides a basic starting point that will work well in many situations.


For CS3911, this document captures the fundamental design information necessary to pro-
duce a good design and to document your design decisions for future customer use.




                                                                                                      Page i
[Paste your logo here] [ Organization Name ]                                   [ Project ] - Software Design Specification


                                                      Contents

1 INTRODUCTION ...........................................................................................................1
1.1 SYSTEM OVERVIEW ..................................................................................................1
1.2 DESIGN MAP .............................................................................................................1
1.3 SUPPORTING MATERIALS ..........................................................................................1
1.4 DEFINITIONS AND ACRONYMS ..................................................................................1

2 DESIGN CONSIDERATIONS ..........................................................................................2
2.1 ASSUMPTIONS ...........................................................................................................2
2.2 CONSTRAINTS ...........................................................................................................2
2.3 SYSTEM ENVIRONMENT ............................................................................................2
2.4 DESIGN METHODOLOGY ...........................................................................................2
2.5 RISKS AND VOLATILE AREAS ....................................................................................2

3 ARCHITECTURE ..........................................................................................................3
3.1 OVERVIEW ................................................................................................................3
3.2 RATIONALE ...............................................................................................................3
3.3 COMPONENT DETAILS ...............................................................................................3

4 HIGH LEVEL DESIGN ..................................................................................................4
4.1 CONCEPTUAL VIEW...................................................................................................4

5 LOW LEVEL DESIGN ...................................................................................................5
5.1 MODULE 1..N ............................................................................................................5

6 USER INTERFACE DESIGN ..........................................................................................6
6.1 APPLICATION CONTROL ............................................................................................6
6.2 SCREEN 1..N ..............................................................................................................6




                                                                                                                       Page ii
[Paste your logo here] [ Organization Name ]                [ Project ] - Software Design Specification


                                          1 Introduction
This space may be used to provide an introduction for the design and ties to other project
materials.


1.1 System Overview
Brief high-level description of system structure, functionality, interactions with external sys-
tems, system issues, etc. If you wrote a good overview for the project plan and requirements
document, then this is a simple paste job.


1.2 Design Map
Summarize the information contained within this document or the family of design artifacts.
Define all major design artifacts and/or major sections of this document and if appropriate,
provide a brief summary of each. Discuss any significant relationships between design arti-
facts and other project artifacts. For 3911 this is the only design document you are required
to produce.


1.3 Supporting Materials
(Optional) – Note any references or related materials here. For instance, if this design re-
quired interfacing with X10 hardware devices, then you would want a reference the X10 spe-
cification.


1.4 Definitions and Acronyms
(Optional) – List any project definitions and acronyms introduced to the project by this de-
sign.




                                                                                                Page 1
[Paste your logo here] [ Organization Name ]               [ Project ] - Software Design Specification


                                2 Design Considerations
This section describes issues that need to be addressed or resolved prior to or while complet-
ing the design as well as issues that may influence the design process.


2.1 Assumptions
Describe any assumption, background, or dependencies of the software, its use, the opera-
tional environment, or significant project issues. These are things you are assuming to be
true, that directly affect the design.


2.2 Constraints
Describe any constraints on the system that have a significant impact on the design of the
system. (e.g. technology constraints, performance requirements, end user characteristics,
validation requirements, project constraints, etc.) These are things the customer has told you
that directly influence the design (the database must be an open-source freely available
DBMS.)


2.3 System Environment
Describe the hardware and software that the system must operate in and interact with.


2.4 Design Methodology
(Optional) - Summarize the approach that will be used to create and evolve the designs for
this system. Cover any processes, conventions, policies, techniques or other issues which will
guide design work. This is not a rehash of your project lifecycle or change management. This
is for deciding whether you will use structured, object-oriented, formal specification or other
specific methodologies. Most people will use some object-oriented technique with UML.


2.5 Risks and Volatile Areas
(Optional) - Describe any notably volatile or risky areas of the system and not any special
strategies taken to mitigate risks or prepare for changes. This is risks specific for the de-
sign—not project management type stuff. For instance if there is an algorithm that is espe-
cially difficult that you must implement.




                                                                                               Page 2
[Paste your logo here] [ Organization Name ]              [ Project ] - Software Design Specification


                                         3 Architecture
The architecture provides the top level design view of a system and provides a basis for more
detailed design work. These are the top level components of the system you are building and
their relationships.


3.1 Overview
This section provides a high level overview of the structural and functional decomposition of
the system. Focus on how and why the system was decomposed in a particular way rather
than on details of the particular components. Include information on the major responsibili-
ties and roles the system (or portions thereof) must play.


3.2 Rationale
This section discusses why you are using the architecture you have decided upon.


3.3 Component Details
(Optional) If your team does not need section 4, then include here a summary of the opera-
tion of each major component and how it interacts with other elements in the architecture.




                                                                                              Page 3
[Paste your logo here] [ Organization Name ]               [ Project ] - Software Design Specification


                                    4 High Level Design
This section describes in further detail elements discussed in the Architecture. Normally this
section would be split into separate documents for different areas of the design. For 3911, we
use this single document.
High-level designs are most effective if they attempt to model groups of system elements from
a number of different views. Typical viewpoints are:
 a. Conceptual or Logical: this is the view most often used in Section 3. This view shows the
logical functional elements of the system. Each component represents a similar grouping of
functionality. For UML, this would be a component diagram or a package diagram..
b. Process: this view is the runtime view of the system. The components are threads or
processes or distributed applications. In UML, this would be a process interaction diagram.
c. Physical: this view is for distributed systems. The components are physical processors
that have parts of the system running on them. For UML, this would be a deployment dia-
gram.
d. Module: this view is for project management and code organization. The components are
typically files or directories. This picture shows how the directory structure of the build and
development environment will be designed.
e. Security: this view typically focuses on the components that cooperate to provide security
features of the system. It is often a subset of the Conceptual view.


For 3911, it is not necessary to document all these views. For many smaller applications, the
conceptual view is all that is necessary. Document those views that will help you design and
implement the system. If you have only a single view, and that view is discussed adequately
in section 3, then this entire section can be deleted.


4.1 Conceptual View
Provide 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.




                                                                                               Page 4
[Paste your logo here] [ Organization Name ]               [ Project ] - Software Design Specification


                                     5 Low Level Design
This section provides low-level design descriptions that directly support construction of mod-
ules. Normally this section would be split into separate documents for different areas of the
design. For each component we now need to break it down into its fundamental units or
modules. For an OO implementation in Java, our components would become packages.
Then the low level design will take each package and break it down into its classes. For
smaller systems, you may have a single UML class diagram that each module description
refers to.


5.1 Module 1..n
Provide or reference a detailed description and diagrams of this software module. For each
package in the Conceptual View (from 4.1 or 3) we should develop a UML class diagram that
represents the static class structure. We should also show UML state and interaction dia-
grams to show dynamic interaction between classes.




                                                                                               Page 5
[Paste your logo here] [ Organization Name ]                [ Project ] - Software Design Specification


                                 6 User Interface Design
This section provides user interface design descriptions that directly support construction of
user interface screens.


6.1 Application Control
Detail the common behavior that all screens will have. Common look and feel details such as
menus, popup menus, toolbars, status bar, title bars, drag and drop mouse behavior should
be described here.


6.2 Screen 1..n
Illustrate all major user interface screens and describe the behavior and state changes that
the user will experience.
A screen transition diagram or table can optionally be created to illustrate the flow of control
through the various screens.
This does not have to be actual screenshots, after all you haven’t actually implemented the
application yet right? They can be powerpoint drawings or mockups created in Visual Basic
or some other rapid GUI-building tool.




                                                                                                Page 6

				
DOCUMENT INFO
Shared By:
Categories:
Tags:
Stats:
views:2
posted:10/20/2011
language:English
pages:9