A Software Design Specification

Only available on StudyMode
  • Download(s) : 205
  • Published : April 14, 2013
Open Document
Text Preview
A Software Design Specification Template

by Brad Appleton
http://www.bradapp.net

Adapted for LAFS by Elliott McCrory, 0/0/0000 00:00:00

Copyright © 1994-1997 by Bradford D. Appleton

Permission is hereby granted to make and distribute verbatim copies of this document provided the copyright notice and this permission notice are preserved on all copies.

Table of Contents

1.Introduction1

1.1.Document Outline2
1.2.Document Description4
1.2.1.Introduction4
1.2.2.System Overview5

2.Design Considerations5

2.1.Assumptions and Dependencies5
2.2.General Constraints5
2.3.Goals and Guidelines6
2.4.Development Methods6

3.Architectural Strategies6

4.System Architecture7

4.1.Subsystem Architecture8

5.Policies and Tactics8

6.Detailed System Design9

6.1.Classification9
6.2.Definition9
6.3.Responsibilities10
6.4.Constraints10
6.5.Composition10
6.6.Uses/Interactions10
6.7.Resources10
6.8.Processing10
6.9.Interface/Exports11
6.10.Detailed Subsystem Design11

7.Glossary11

8.Bibliography11

Introduction

The following is an attempt to put together a complete, yet reasonably flexible template for the specification of software designs. Wherever possible, I have tried to provide guidelines (instead of prescribing requirements) for the contents of various sections and subsections of the document. Some may prefer to require more detailed subsections of a particular section, choosing one or more of the subsection topics from the list of guidelines provided. In this sense, this document is really a template for a template.

In devising this template, I have gleaned information from many sources, including various texts on Software Engineering (Pressman, Sommerville, and Van Vliet), Object-Oriented Development (Booch, Rumbaugh, Berard, and Wirfs-Brock), various SEI reports, DoD-Std and Mil-Std documentation requirements (2167/2167A), and IEEE documentation standards (particularly IEEE-1016 for software designs, and IEEE-830 for software requirements). I have made every effort not to assume or impose a particular software development methodology or paradigm, and to place more emphasis on content than on format.

It is my desire that a completed software design specification meet the following criteria:

• It should be able to adequately serve as training material for new project members, imparting to them enough information and understanding about the project implementation, so that they are able to understand what is being said in design meetings, and won't feel as if they are drowning when they are first asked to create or modify source code.

• It should serve as "objective evidence" that the designers and/or implementers are following through on their commitment to implement the functionality described in the requirements specification.

• It needs to be as detailed as possible, while at the same time not imposing too much of a burden on the designers and/or implementers that it becomes overly difficult to create or maintain.

Please note that there are no sections in this document for describing administrative or business duties, or for proposing plans or schedules for testing or development. The sections in this document are concerned solely with the design of the software. While there are places in this document where it is appropriate to discuss the effects of such plans on the software design, it is this author's opinion that most of the details concerning such plans belong in one or more separate documents.

1 Document Outline

Here is the outline of the proposed template for software design specifications. Please note that many parts of the document may be extracted automatically from other sources and/or may be contained in other, smaller documents. What...
tracking img