IEEE STANDARD 1016: Software Design Specification

The Software Design Specification (SDS) sections provide you with guidelines
related to the structure and the contents of SDS document. The Software Design
Specification document includes at least these sections.
For the project, your team may have good reasons for wanting to deviate from this
proposed outline. If a section is not applicale in your case, do not delete it! instead,
give the topic heading and write "#ot applicale".

$ou will note that there is some overlap in the content etween different documents
(i.e. the %ser &e'uirements Specification Document and the Software Design
Specification Document.) This redundancy allows each document to stand on its own.
The Software Design Specification Outline
1. Introuction
1.1 !urpose of this ocu"ent
Full description of the main ojectives of the SDS document.
1.# Scope of the e$elop"ent pro%ect
This will e similar to what was written in the S&S.
1.& Definitions' acron("s' an a))re$iations
(e sure to alphaeti)e*
1.* References
This section will include technical oo+s and documents related to design
issues. (e certain that the references you give are complete and in
the appropriate format.
1.+ O$er$iew of ocu"ent
, short description of how the rest of the SDS is organi)ed and what can e
found in the rest of the document. This is not simply a tale of contents.
-otivate and riefly descrie the various parts*
#. S(ste" architecture escription
#.1 O$er$iew of "oules , co"ponents
This susection will introduce the various components and susystems.
#.# Structure an relationships
-a+e clear the interrelationships and dependencies among the various components.
Structure charts can e useful here. , simple finite state machine can e useful in
demonstrating the operation of the product. Include e.planatory te.t to help the reader
understand any charts.
#.& -ser interface issues
This section will present the main principles of the product/s user interface. %se the
personas defined in section 0.1 of your S&S to ma+e specific e.amples. This section
should not touch on technical details. $ou may want to include s+etches and specific
te.t messages.
&. Detaile escription of co"ponents
&.1 .o"ponent te"plate escription
This section is not part of your design. It is the pattern you will use to descrie the
components given in susections 2.0 3 2.n. 4ach part of the template will e identified
y a lael. 5ere in 2.1, you must riefly e.plain the purpose of each point. To ma+e
the presentation clear, use a tale or ullet list. $ou may adapt the template suggested
elow to your particular needs (although deviations from the suggested template
should e minimal and well motivated).
&.# / .o"ponent 0or .lass or 1unction ...2
%se e.actly the template you define in 2.0. If a part of the template is not applicale,
then mar+ it #6, rather than omitting it.
&.& 3 .o"ponent 0or .lass or 1unction ...2
...
&.n 4 .o"ponent 0or .lass or 1unction ...2
*.0 Reuse an relationships to other proucts
For teams doing enhancement wor+, reuse is an important issue. -ost enhancement
wor+ should focus on e.tending, rather than replacing, the design and product
development from earlier semesters. For teams doing new development, reuse can
also e an important strategy. In some cases, there is freeware that could e
incorporated. In other cases, there are e.isting modules or classes that could e
adapted. ,nother possiility is the use of special tools that produce open source
results and thus permissile under the terms of this course.
This section should include the following susections as appropriate7
how reuse is playing a role in your product design
how reuse is playing a role in your product implementation (and the
motivation for changes)
if you are not reusing material that is availale, then give motivation for why it
is eing thrown out.
+.0 Design ecisions an traeoffs
%se this section to motivate any decisions that will help the reader understand
the design that your team is using. This section can also capture good ideas
that were aandoned and the reasons for leaving them out of the design.
6.0 !seuocoe for co"ponents
5.0 Appenices 0if an(2
SDS co"ponent te"plate
The template given elow suggests a reasonale structure for giving a thorough
description of each component descried in 8art 2 of the SDS. The specific
information depends in part on the design approach. $our team must adapt this
template to your needs and descrie it in section 2.1 of your SDS.
Identification The uni'ue name for the component and the location of the
component in the system.
Type , module, a suprogram, a data file, a control procedure, a class,
etc
8urpose Function and performance re'uirements implemented y the
design component, including derived re'uirements. Derived
re'uirements are not e.plicitly stated in the S&S, ut are implied
or adjunct to formally stated SDS re'uirements.
Function 9hat the component does, the transformation process, the specific
inputs that are processed, the algorithms that are used, the outputs
that are produced, where the data items are stored, and which data
items are modified.
Suordinates The internal structure of the component, the constituents of the
component, and the functional re'uirements satisfied y each part.
Dependencies 5ow the component/s function and performance relate to other
components. 5ow this component is used y other components.
The other components that use this component. Interaction details
such as timing, interaction conditions (such as order of e.ecution
and data sharing), and responsiility for creation, duplication, use,
storage, and elimination of components.
Interfaces Detailed descriptions of all e.ternal and internal interfaces as well
as of any mechanisms for communicating through messages,
parameters, or common data areas. ,ll error messages and error
codes should e identified. ,ll screen formats, interactive
messages, and other user interface components (originally defined
in the S&S) should e given here.
&esources , complete description of all resources (hardware or software)
e.ternal to the component ut re'uired to carry out its functions.
Some e.amples are :8% e.ecution time, memory (primary,
secondary, or archival), uffers, I6; channels, plotters, printers,
math liraries, hardware registers, interrupt structures, and system
services.
8rocessing The full description of the functions presented in the Function
susection. 8seudocode can e used to document algorithms,
e'uations, and logic.
Data For the data internal to the component, descries the
representation method, initial values, use, semantics, and format.
This information will proaly e recorded in the data dictionary.