Software Design Specification

Version No.______ Page 1 of 14 Date of Release__________

Software Design Document
(Version No.2)

for



<Project Title>








Version No. Date:





Prepared by: (Name & Address of the Organisation)





For Department of: (User Department)






Submitted to: _______________________________

Software Design Specification
Version No.______ Page 2 of 14 Date of Release__________

Document Release Notice



Notice No. :

Client :

Project :

Document Details :
Document ID Version No. Description





APPROVED BY :( Approval Authority) DATE:

Software Design Specification
Version No.______ Page 3 of 14 Date of Release__________
DOCUMENTATION VERSION CONTROL


VERSION DATE DESCRIPTION PAGE
No. &
Item No.
PREV.
PAGE
No.
REASON FOR
CHANGE












Software Design Specification
Version No.______ Page 4 of 14 Date of Release__________
Document Outline
1. Introduction
1.1 Background
1.2 Purpose
1.3 Scope
1.4 Audience
1.5 References
1.6 Acronyms/ Abbreviations
1.7 Overview
2. System Description
2.1 Design Objectives
2.2 System Architecture
2.2.X Sub-System Architecture
2.3 Architectural Strategies 2.4 Hardware Environment
2.5 Software Environment
2.6 Network Environment
2.7 Design Constraints
2.8 Goals and guidelines
2.9 Policies and Tactics
3. Database Description
3.1 Design Decisions
3.1.1 Domains
3.1.2 General Validations
3.1.3 Security Role Grants
3.1.4 Others
3.2 Database Design
3.2.X Table Name
3.3 Storage Requirements
4. Data Migration Strategy
5. Input Output Specifications
5.1 Input Descriptions
5.2 Output Descriptions
5.3 Help Facilities
5.4 Error Messages
Software Design Specification
Version No.______ Page 5 of 14 Date of Release__________
5.5 Navigation
5.6 Program specification
6. Detailed System Design
6.x Component Name
7. Operational Controls
7.1 Start-up and shutdown
7.2 Audit and Recovery
7.3 Restart
7.4 Backup Strategy
7.5 Fallback Strategy
8. Security
8.1 Security Strategy
8.1.1 Operating System Level Security
8.1.2 Database Level Security
8.1.3 Application Level Security
8.1.4 Menu Level Security
9 Annexure A Code Structure
10 Annexure B Menu Navigation
11 Annexure C Screen Layouts
12 Annexure D Report Layouts
13 Glossary
14 Bibliography









Software Design Specification
Version No.______ Page 6 of 14 Date of Release__________
1. Introduction
1.1 Background Provide a background of the System to be
computerised.
1.2 Purpose Describe the purpose of this document
1.3 Scope Describe the scope of this document
1.4 Audience Describe this document's intended audience
1.5 References Provide references for any other pertinent documents
such as:
Related and/or companion documents
Prerequisite documents
Documents which provide background and/or context for this
document
Documents that result from this document (e.g. a test plan or a
development plan)
1.6 Acronyms/ Abbreviations Define any important terms, acronyms, or
abbreviations
1.7 Overview Summarise (or give an abstract for) the contents of this
document.
Note: For the remaining sections of this document, it is desirable that
one or more of the section topics are discussed in a separate design
document within the project. For each section where such a document
exists, a reference to the appropriate design document is all that is
necessary. All such external design documents should probably be
provided with this document at any design reviews.
2. System Description
Provide a general description of the software system including with its
functionality and matters related to the overall system and its design (a
discussion of the basic design approach or organisation may be
included). This discussion may be splited into subsections and sub
subsections. This section should contain:
2.1 Objectives List the objectives of this design document.
2.2 System Architecture This section should provide a high-level
overview of how the functionality and responsibilities of the system
were partitioned and then assigned to subsystems or components.
Don't go into too much detail about the individual components
themselves (there is a subsequent section for detailed component
descriptions). The main purpose here is to gain a general
understanding of how and why the system was decomposed, and
how the individual parts work together to provide the desired
functionality.
Software Design Specification
Version No.______ Page 7 of 14 Date of Release__________
At the top-most level, describe the major responsibilities that the
software must undertake and the various roles that the system (or
portions of the system) must play. Describe how the system was
broken down into its components/subsystems (identifying each top-
level component/subsystem and the roles/responsibilities assigned
to it). Describe how the higher-level components collaborate with
each other in order to achieve the required results. Don't forget to
provide some sort of rationale for choosing this particular
decomposition of the system (perhaps discussing other proposed
decompositions and why they were rejected).
If there are any diagrams, models, flowcharts, documented
scenarios or use-cases of the system behavior and/or structure, they
may be included here (unless you feel they are complex enough to
merit being placed in the Detailed System Design section). Diagrams
that describe a particular component or subsystem should be
included within the particular subsection that describes that
component or subsystem.
Note: This section (and its subsections) applies only to newly
developed (or yet-to-be developed) portions of the system. If there
are parts of the system that already existed before this development
effort began, then you only need to describe the pre-existing parts
that the new parts of the system depend upon, and only in enough
detail sufficient to describe the relationships and interactions
between the old parts and the new parts. Pre-existing parts that are
modified or enhanced need to be described only to the extent that is
necessary for the reader to gain a sufficient understanding of the
nature of the changes that were made.
2.2.1 Subsystem Architecture
If a particular component is one which merits a more detailed
discussion than what was presented in the System
Architecture section, provide that more detailed discussion in
a subsection of the System Architecture section (or it may
even be more appropriate to describe the component in its
own design document). If necessary, describe how the
component was further divided into subcomponents, and the
relationships and interactions between the subcomponents
(similar to what was done for top-level components in the
System Architecture section).
If any subcomponents are also deemed to merit further
discussion, then describe them in a separate subsection of
this section (and in a similar fashion). Proceed to go into as
many levels/subsections of discussion as needed in order for
the reader to gain a high-level understanding of the entire
system or subsystem (but remember to leave the details for
the Detailed System Design section).
Software Design Specification
Version No.______ Page 8 of 14 Date of Release__________
If this component is very large and/or complex, you may want
to consider documenting its design in a separate document
and simply including a reference to it in this section. If this is
the option you choose, the design document for this
component should have an organizational format that is very
similar (if not identical to) this document.
2.3 Architectural Strategies Describe any design decisions and/or
strategies that affect the overall organisation of the system and its
higher-level structures. These strategies should provide insight into
the key abstractions and mechanisms used in the system
architecture. Describe the reasoning employed for each decision
and/or strategy (possibly referring to previously stated design goals
and principles) and how any design goals or priorities were balanced
or traded-off. Such decisions might concern (but are not limited to)
things like the following:
Use of a particular type of product (programming language,
database, library, etc....)
Reuse of existing software components to implement various
parts/features of the system
Future plans for extending or enhancing the software
User interface paradigms (or system input and output models)
Hardware and/or software interface paradigms
Error detection and recovery
Memory management policies
External databases and/or data storage management and
persistence
Distributed data or control over a network
Generalised approaches to control
Concurrency and synchronisation
Communication mechanisms
Management of other resources
Each significant strategy employed should probably be discussed in
its own subsection, or (if it is complex enough) in a separate design
document (with an appropriate reference). Make sure that when
describing a design decision that you also discuss any other
significant alternatives that were considered, and your reasons for
rejecting them (as well as your reasons for accepting the alternative
you finally chose). Sometimes it will be most effective to employ the
"pattern format" for describing a strategy.

Software Design Specification
Version No.______ Page 9 of 14 Date of Release__________
2.4 Hardware Environment List the hardware configuration for
the Server and the Client machines.
2.5 Software Environment List the software configuration for
the Server and the Client machines, which may include the OS, DBMS
or any other utility software.
2.6 Network Environment If applicable, discuss the
networking strategy and its requirements.
2.7 Design Constraints Describe any global limitations or
constraints that have a significant impact on the design of the
system's software (and describe the associated impact). Such
constraints may be imposed by any of the following (the list is not
exhaustive):
Hardware or software environment
End-user environment
Availability or volatility of resources
Standards compliance
Interoperability requirements
Interface/protocol requirements
Data repository and distribution requirements
Security requirements (or other such regulations)
Memory and other capacity limitations
Performance requirements
Network communications
Verification and validation requirements (testing)
Other means of addressing quality goals
Other requirements described in the requirements specification
2.8 Goals and Guidelines
Describe any goals, guidelines, principles, or priorities, which dominate
or embody the design of the system's software. Such goals might be:
Simple Design
Emphasis on speed versus memory use
Working or looking like an existing product
For each such goal or guideline, unless it is implicitly obvious,
describe the reason for its desirability.
2.9 Policies and Tactics
Describe any design policies and/or tactics that do not have
sweeping architectural implications (meaning they would not
significantly affect the overall organisation of the system and its high-
Software Design Specification
Version No.______ Page 10 of 14 Date of Release__________
level structures), but which nonetheless affect the details of the
interface and/or implementation of various aspects of the system.
Such decisions might concern (but are not limited to) things like the
following:
Choice of which specific product to use (compiler, interpreter,
database, library, etc.)
Engineering trade-offs
Coding guidelines and conventions
The protocol of one or more subsystems, modules, or subroutines
The choice of a particular algorithm or programming idiom (design
pattern) to implement portions of the system's functionality
Plans for ensuring requirements traceability
Plans for testing the software
Plans for maintaining the software
Interfaces for end-users, software, hardware, and communications
Hierarchical organization of the source code into its physical
components (files and directories).
How to build and/or generate the system's deliverables (how to
compile, link, load, etc. ...)
Make sure that when describing a design decision that you also
discuss any other significant alternatives that were considered, and
your reasons for rejecting them (as well as your reasons for
accepting the alternative you finally chose). For this reason, it may
frequently be convenient to use one of the more popular "pattern
formats" to describe a given tactic.
For this particular section, it may become difficult to decide
whether a particular policy or set of tactics should be discussed in
this section, or in the System Architecture section, or in the Detailed
System Design section for the appropriate component. You will have
to use your own "best" judgment to decide this. There will usually be
some global policies and tactics that should be discussed here, but
decisions about interfaces, algorithms, and/or data structures might
be more appropriately discussed in the same (sub) section as its
corresponding software component in one of these other sections.
3. Database Description
3.1 Design Decision Describe the design decisions vis--vis to
the following
3.1.1 Domains List the domain to be used for individual table
columns (similar fields that are repeated number of times in various
tables) to ensure consistency and avoid redundancy as per format:
(any other attributes may be added if applicable)
Software Design Specification
Version No.______ Page 11 of 14 Date of Release__________
Sr.
No.
Common
Field
Name
Data
Type &
Length
Default
Value
Not
Null
Primary
Key & Sr.
No. (if
Composite)
Foreign
Key
Unique Constraint
if any
Remarks




3.1.2 General Validations List all applicable database validation
rules.
3.1.3 Security Role Grants List all the role grants that should be
available on tables/ columns. Detailed description of these role grants will be
mentioned in the security section.

3.1.4 Others List any other database design decisions to be
implemented for better product interface and maintainability.

3.2 Database Design Describe the database design as per format below.

3.2.x Table Name
Table Alias
Table Description
Remarks (if any)
(Any other attributes may be added if applicable)
Interfaces list the interface between any table fields.
Table level Checks and Triggers (if any)

3.3 Storage Requirements Describe the storage requirement
for the system. It is based on volume, growth rate, record size etc.
Provide any references if available.
Sr.
No.
Field
Name
Data
Type
&
Length
Default
Value
Not
Null
Primary
Key & Sr.
No. (if
Composite)
Foreign
Key
Unique Constraint
if any
Remarks



Software Design Specification
Version No.______ Page 12 of 14 Date of Release__________
4. Data Migration Strategy
Describe the data Migration Strategy if any data is available on soft media
for migration to this application. Mention if any data is to be entered in this
application.
5. Input Output Specifications
5.1 Input Descriptions Include an annexure of all the input
formats.
5.2 Output descriptions Include a separate annexure for all the
output formats.
5.3 Help Facilities Describe the different type of help to be made
available to the user at various levels.
5.4 Error Messages Describe the different types of error messages
and their formats to be shown to the user.
5.5 Navigation Provide separate annexure for menu navigation
giving a pictorial representation.
6. Detailed System Design
6.x Component Name
Most components described in the System Architecture section will
require a more detailed discussion. Other lower-level components and
subcomponents may need to be described as well. Each subsection of
this section will refer to or contain a detailed description of a system
software component. The discussion provided should cover the
following software component attributes:
SRS Process Reference
Provide a reference of this software component to the SRS Document.
Classification
The kind of component, such as a subsystem, module, class, package,
function, file, etc.
Definition
The specific purpose and semantic meaning of the component. This
may need to refer back to the requirements specification.
Responsibilities
The primary responsibilities and/or behavior of this component. What
does this component accomplish? What roles does it play? What kinds
of services does it provide to its clients? For some components, this
may need to refer back to the requirements specification.
Constraints
Any relevant assumptions, limitations, or constraints for this component.
This should include constraints on timing, storage, or component state,
and might include rules for interacting with this component
Software Design Specification
Version No.______ Page 13 of 14 Date of Release__________
(encompassing preconditions, post conditions, invariants, other
constraints on input or output values and local or global values, data
formats and data access, synchronization, exceptions, etc.)
Composition
A description of the use and meaning of the subcomponents that are a
part of this component.
Uses/Interactions
A description of these components collaborates with other components.
What other components is this entity used by? What other components
do this entity use (this would include any side-effects this entity might
have on other parts of the system)? This concerns the method of
interaction as well as the interaction itself. Object-oriented designs
should include a description of any known or anticipated subclasses,
super-classes, and meta-classes.
Resources
A description of any and all resources that are managed, affected, or
needed by this entity. Resources are entities external to the design such
as memory, processors, printers, databases, or a software library. This
should include a discussion of any possible race conditions and/or
deadlock situations, and how they might be resolved.
Processing
A description of how precisely this component goes about performing
the duties necessary to fulfill its responsibilities. This should encompass
a description of any algorithms used; changes of state; relevant time or
space complexity; concurrency; methods of creation, initialization, and
cleanup; and handling of exceptional conditions.
Interface/Exports
The set of services (resources, data, types, constants, subroutines, and
exceptions) that are provided by this component. The precise definition
or declaration of each such element should be present, along with
comments or annotations describing the meanings of values,
parameters, etc. For each service element described, include (or
provide a reference) in its discussion a description of its important
software component attributes (Classification, Definition,
Responsibilities, Constraints, Composition, Uses, Resources,
Processing, and Interface).
Any referenced diagrams like E-R diagrams, Data Flow diagrams, Entity
Attributes, State Charts, and Object oriented Analysis, Stimulus
Response Sequences etc. or source code excerpts should be provided.
7 Operational Controls
7.1 Start-up and shutdown
Software Design Specification
Version No.______ Page 14 of 14 Date of Release__________
Describe the start-up and shutdown procedure for the application
software and DBMS if applicable. Explain the role of DBA and other
staff.
7.2 Audit and Recovery
Describe the audit and recovery features to be used.
7.3 Restart
Describe the restart requirements after abnormal shutdown. If
required, restart requirements for individual processes may be
stated.
7.4 Backup Strategy
Describe the backup features/ strategy to be used.
7.5 Fallback Strategy
Explain the strategy to be followed in case of non-availability of
system.
8. Security
8.1 Security Strategy
Describe the security strategy for different users/ user groups under
the following headings.
8.1.1 Operating System Level Security
8.1.2 Database Level Security
8.1.3 Application Level Security
8.1.4 Menu Level Security
9 Annexure A Code Structure
Discuss the data elements for each module and list their code structure.
10 Annexure B Menu Navigation
Provide a pictorial representation of different menu navigation to be
made available to the user.
11 Annexure C Screen Layouts
Provide copies of all screen layouts.
12 Annexure D Report Layouts
Provide copies of all report layouts.
13 Glossary
An ordered list of defined terms and concepts used throughout the
document.
14 Bibliography
A list of referenced and/or related publications.