October 13, 1999
Version 1.2

Introduction

This document outlines the template for software design specifications (SDS) produced by Clemson University in the CPSC372 Introduction to Software Development course.

Template

This section contains the template for an SDS. The numbers corresponding to subsections in this document specify the numbers that should appear in the SDS. Also included are brief descriptions of the contents of the sections. An SDS must contain a table of contents, including section titles, numbers and page numbers.

1. Introduction

1.1 Purpose

This section should outline the purpose of the SDS as well as the intended audience.

1.2 Scope

This section must specify the extent and the boundary of the design, i.e., what it includes and what it does not include.

1.3 Definitions and Acronyms

Defines any terms used.

1.4 References

Lists any references, e.g. Pfleeger.

2. Subsystem description

2.1 Actors

This section describes in detail the Actors for the software system. In particular, the definition of the Actor interfaces in the form of UML class diagrams should go here.

2.2 Software architecture

This section will contain the architecture for the system, in terms of subsystems, their operations and their interrelations. If the diagrams become too cluttered, they may be split into several diagrams with different levels of detail.

2.3 Key abstractions

This section contains the key abstractions, including class diagrams describing their attributes and operations.

3. Use Cases

This section is organized according to subsystem, and contains the specifications of the use cases associated with each subsystem. These will be embellishments of the use cases from the SRS, and will additionally contain class diagrams and sequence diagrams.

3.1.x Subsystem 1

3.1.x.1 Use case diagram

This section should contain a use case diagram describing the relationship between use cases in the subsystem being described.

3.1.x.y Use case 1

3.1.x.y.1 Characteristic Information

Goal in Context: This should serve as an introduction to the use case, stating its purpose and the goal that will it will achieve.
Scope: One of:

• Strategic - this use case  is a strategic goal with respect to the system. These goals are goals of value to the organization. The use case shows how the system is used to benefit the organization. These strategic use cases will eventually use some of the same lower level (subordinate) use cases. An exmple of a strategic use cases included monitoring customers - it is a collection of specific functions, all related to a general, strategic goal.
• System - Use cases at system scope are bounded by the system under development. The goals represent  specific functionality required of the system. The majority of the use cases are at system scope. These use cases are often steps in strategic level use cases

Level: One of:

• Primary task - a goal that a primary actor is trying to achieve.
• Summary - a collection of primary tasks to get a larger task done.
• Subfunction - a subgoal or step in some Primary task use case.

Preconditions: This should contain a list of what is expected to be the state of the world for this use case to succeed.
Success End Condition: This should contain the state of the world upon successful completion.
Failed End Condition: This should contain the state of the world if goal abandoned.
Primary Actor: This should contain a role name for or a description of the primary actor.
Trigger: The action upon the system that starts the use case, may be time event
Inputs: The data required for this use case, including sources, quantities, units of measure, timing
Outputs: The data produced by this use case, including targets, quantities, units of measure, timing

3.1.x.y.2 Scenarios

3.1.x.y.2.1 Main Success Scenario

This section contains the steps of the scenario, from trigger to goal delivery, and any cleanup activities. Each step should be numbered and described. All information used in each step must be listed in the Inputs subsection of 3.1.x.1.

3.1.x.y.2.2 Extensions

This section contains any variations of the main success scenario, each referring to a step in the main success scenario. For example, this section may contain variations that lead to failure of this scenario, such as if errors occur, or appropriate information is not given. Each different extension should be named.

3.1.x.y.3 Related information

Priority: How critical to your system / organization.
Performance Target: The amount of time this use case should take.
Frequency: How often it is expected to happen.
Superordinate Use Case: optional, name of use case that includes this one.
Subordinate Use Cases: optional, depending on tools, links to sub.use cases.
Secondary Actors: List of other systems needed to accomplish use case.

3.1.x.y.3.1 Sequence diagrams

For each scenario, a sequence diagram should be developed, outlining the events and orders in which they occur according to the key abstractions.

3.1.x.y.3.2 User Interfaces

This section should contain a description of the required screen formats, page layouts of any reports generated as a result of this use case. In particular, if the origin/destination of inputs/ouputs is the user (or actor), then a description of how this information is attained/presented to the user should be presented. All figures should be explained; how user interface events map to input and output should also be described.

3.1.x.y.3.3 Other external interfaces

This section describes interfaces to other systems, such as software, hardware or networks. This section should describe (or refer to) interfaces to these other systems, in particular relating them to the inputs and outputs for this use case in a manner similar to 3.1.x.y.3.2

3.1.x.y.4 Open issues

This section contains a list of issues that need to be decided. In the final version of the SRS, this section should contain the word "None." However, this section is useful in preliminary versions to record issues that require discussion.

3.2 Use case and architectures

This section contains a table that relates use cases to subsystems through classes. The table should follow this format:

The first column names each scenario from every use case (and uses section numbers indicating where they are defined). The other columns represent the classes defined for particular subsystems (out of section 2), categorized by subsystem. A checkmark in a cell indicates that that scenario uses that particular class.