UNIVERSITY OF CALIFORNIA SANTA CRUZ EXTENSION

Software Requirements, Analysis, & Design

System Design Template

TABLE OF CONTENTS
Table of Contents________________________________________________________________
Overview_______________________________________________________________________
Intended Audience__________________________________________________________________________
Authors___________________________________________________________________________________
Related documents__________________________________________________________________________

Introduction____________________________________________________________________
State Transition Models___________________________________________________________
Event Models___________________________________________________________________
Data Forms_____________________________________________________________________
Significant New Features_______________________________________________________
Implementation Specifications_____________________________________________________
Business Rules and Design Specifications________________________________________________________

Phase 1 - Initial Implementation_________________________________________________________

<Major category 1>__________________________________________________________________________
<Major category 2>__________________________________________________________________________
Minor category___________________________________________________________________________

Phase 2 - Advanced Implementation______________________________________________________

<Major category 1>__________________________________________________________________________
Design Notes_______________________________________________________________________________

Design Specification Template

Brian Lawrence 5/28/98

UNIVERSITY OF CALIFORNIA SANTA CRUZ EXTENSION

Software Requirements, Analysis, & Design

OVERVIEW
A brief summary of the system to be designed. It might specify data and
control models, entity-relationship diagrams, event models, state models, or
other architectural models which make up the major aspects of the system.

Intended Audience
Describes the intended audience for this document, possibly including
designers, users, other affected groups, sponsors, or other management.

Authors
The system was designed by the <team name> team:
<name 1>

<role and organization>

<name 1>

<role and organization>

Related documents
Lists related documents, such as requirements specifications, APIs, Charters,
Product Vision and Mission statements.
<project> <document title> (Draft #- <author> - <date>)

INTRODUCTION
A more detailed explanation for why the systems is being built. It has a
bullet list of the major requirements such a system would fulfill. Other items
to be listed could be any major assumptions made, major elements of the
system, special terms with definitions..

STATE TRANSITION MODELS

Description of state transition models, including diagrams and state tables.
Start State

Next State

Events

Actions by the System

Data
Involved

Users

<start state>

<next state>

<events>

<Actions>

<data>

<user(s)>

Design Specification Template

Brian Lawrence 5/28/98

UNIVERSITY OF CALIFORNIA SANTA CRUZ EXTENSION

Software Requirements, Analysis, & Design

EVENT MODELS
Description of event models, including diagrams and event tables.
Key Event

Stimulus

Frequency of
Occurrence

Response

Memory

Mode

<event >

<stimulus >

<frequency>

<actions>

<data>

<data or
control>

DATA FORMS
All data forms (if any).

SIGNIFICANT NEW FEATURES

List new features.

IMPLEMENTATION SPECIFICATIONS
The following sections are low-level design specifications.

Business Rules and Design Specifications

The design is specified by two types of items: business rules, and design
specifications, each having a tag which uniquely identifies it. Most of the
items were originally design issues, which have been translated into either
business rules, or design specifications. Numbering is roughly in order of
resolution. The form of these items is:
BR-DD

A Business Rule describing some automatic aspect of the system, where BR

represents Business Rule, and DD is a unique integer (to business rules).

DS-DD

A Design Specification describing some element, data definition, security or

other aspect of the system, where DS represents Design Specification, and
DD is a unique integer (to design specs).
Specifications have implementation status which is classified as follows:

Plain text with no annotation means the specification is

implemented as stated.

Text enclosed in a shadow box is or has outstanding issues.

Design Specification Template

Brian Lawrence 5/28/98

UNIVERSITY OF CALIFORNIA SANTA CRUZ EXTENSION

Software Requirements, Analysis, & Design

Text that has background grayed has not been implemented for
some reason.

Phase 1 - Initial Implementation

These are the specifications for the first phase of implementation.

<Major category 1>

BR-05

<first business rule>

DS-59 <design

specification>

<Major category 2>

BR-12

<another business rule>

DS-59 <another

MINOR

design specification>

CATEGORY

<more stuff>

Phase 2 - Advanced Implementation

Specifications which may be included in a later version, but which may have
been taken into consideration during phase 1..

<Major category 1>

DS-20 <advanced

specification>

Design Notes
A list of issues or other considerations concerning the difference between
this and earlier phases.

Design Specification Template

Brian Lawrence 5/28/98