You are on page 1of 4

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_______________________________________________________
Im!lementation S!ecifications_____________________________________________________
Business Rules and Design Specifications________________________________________________________
Phase 1 - Initial Implementation_________________________________________________________
<Major category 1>__________________________________________________________________________
<Major category >__________________________________________________________________________
Minor category___________________________________________________________________________
Phase 2 - Advanced Implementation______________________________________________________
<Major category 1>__________________________________________________________________________
Design !otes_______________________________________________________________________________
Design Specification Template 1 Brian Lawrence • 5/28/98
Software Publishing Corporation
Product Life Cycle version 3.0
OVERVIE
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 afected groups, sponsors, or other management.
Authors
The system as designed !y the "team name# team$
<name 1> <role and organi"ation>
<name 1> <role and organi"ation>
%elated documents
ists related documents, such as re!uirements speci"cations, A#Is, $harters,
#roduct %ision and &ission statements.
"pro&ect# "document title# 'Draft () "author# ) "date#*
INTRO!"CTION
A more detailed e'planation for why the systems is being built. It has a
bullet list of the major re!uirements such a system would ful"ll. (ther items
to be listed could be any major assumptions made, major elements of the
system, special terms with de"nitions..
STATE TRANSITION #O!ELS
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)>
+ , -rror. /o te0t of speci1ed style in document. 23+435664 0+$33$00 P7 )#$ $on"dential
UNIVERSITY OF CALIFORNIA SANTA CRUZ EXTENSION
Software Requirements, Analysis, & Design
EVENT #O!ELS
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>
!ATA FOR#S
All data forms *if any+.
SI$NIFICANT %NE& FEAT"RES
ist new features.
I#PLE#ENTATION SPECIFICATIONS
The folloing sections are lo)level design speci1cations.
8usiness %ules and Design Speci1cations
The design is speci1ed !y to types of items$ !usiness rules9 and design
speci1cations9 each having a tag hich uni:uely identi1es it. 7ost of the
items ere originally design issues9 hich have !een translated into either
!usiness rules9 or design speci1cations. /um!ering is roughly in order of
resolution. The form of these items is$
BR'DD A ,usiness -ule descri!ing some automatic aspect of the system9 here BR
represents 8usiness %ule9 and DD is a uni:ue integer 'to !usiness rules*.
!S'DD A Design )peci"cation descri!ing some element9 data de1nition9 security or
other aspect of the system9 here !S represents Design Speci1cation9 and
DD is a uni:ue integer 'to design specs*.
Speci1cations have implementation status hich is classi1ed as follos$
• Plain te0t ith no annotation means the speci1cation is
implemented as stated.
• Te0t enclosed in a shado !o0 is or has outstanding issues.
Design Specification Template 3 Brian Lawrence • 5/28/98
Software Publishing Corporation
Product Life Cycle version 3.0
• Te0t that has !ac;ground grayed has not !een implemented for
some reason.
Phase ( ' Initial I)ple)entation
.hese are the speci"cations for the "rst phase of implementation.
"7a&or category 5#
BR'*+ "1rst !usiness rule#
!S'+, "design speci1cation#
"7a&or category +#
BR'(- "another !usiness rule#
!S'+, "another design speci1cation#
#INOR CATE$OR.
) "more stu<#
Phase - ' A/0an1e/ I)ple)entation
)peci"cations which may be included in a later version, but which may have
been taken into consideration during phase /..
"7a&or category 5#
!S'-* 0advanced speci"cation1
Design /otes
A list of issues or other considerations concerning the diference between
this and earlier phases.
= , -rror. /o te0t of speci1ed style in document. 23+435664 0+$33$00 P7 )#$ $on"dential