Functional Specifications Document

<Project Title> <Project Title>

Project Code:
Internal Advisor:
External Advisor:
Project Manager:
Project Team:
Submission Date:

_____________________
Project Managers Signature
Document Document
<Project code> Functional Specifcations Document
Document Information
Category Information
Customer FAST-NU
Project <Project Title>
Document Functional Specifications
Document Version 1.
!"entifier P#$%1-&'-FS
Status Draft
Aut(or)s* <Names of all t(e aut(ors of t(is "ocument>
Appro+er)s* P,
!ssue Date Sept. 1-. &'
Document /ocation
Distri0ution
1. A"+isor
&. P,
'. Project 1ffice
Definition of Terms, Acronyms and Abbreviations
This section should provide the definitions of all terms, acronyms, and abbreviations required to interpret the terms
used in the document properly.
Term Description
ASP Acti+e Ser+er Pa2es
3S 3e4uirements Specifications
Sept. 15, 2003 Page 2
o 10
<Project code> Functional Specifcations Document
Sept. 15, 2003 Page 3
o 10
<Project code> Functional Specifcations Document
Table of ontents
1. Introduction........................................................................................................................4
1.1 Purpose of Document..........................................................................................................................4
1.2 Project Overview..................................................................................................................................4
1.3 Scope.....................................................................................................................................................4
2. Functional Requirements..................................................................................................4
3. Non-functional Requirements...........................................................................................4
3.1 Performance Requirements................................................................................................................4
3.2 Safety Requirements...........................................................................................................................4
3.3 Security Requirements........................................................................................................................4
3.4 User Documentation............................................................................................................................4
4. Assumptions and Dependencies........................................................................................4
5. Sstem Arc!itecture...........................................................................................................5
". #se $ases............................................................................................................................5
.1 Use !ase Dia"rams.............................................................................................................................5
.2 Use !ase Description..........................................................................................................................5
%. &rap!ical #ser Interfaces................................................................................................."
'. (i)! *e+el Desi)n.............................................................................................................."
#.1 $R Dia"ram...........................................................................................................................................6
#.2 Data Dictionary.....................................................................................................................................6
8.2.1 Data 1............................................................................................................................................................ 6
8.2.2 Data 2............................................................................................................................................................ 6
8.2.3 Data n............................................................................................................................................................ 6
,. Requirements -racea.ilit /atri0...................................................................................%
11. Ris2 Analsis......................................................................................................................'
11. $ost 3stimation S!eet........................................................................................................'
12. References...........................................................................................................................'
13. Appendices..........................................................................................................................,
Sept. 15, 2003 Page !
o 10
<Project code> Functional Specifcations Document
Section 1
!" Introduction
Pur#ose of Document
Describe the purpose of this document and provide a description of the intended audience i.e., the personnel
who will be reading this document.
Project $vervie%
State a brief description of the project under study. Describe how the software will be used and identify the
relevant goals and benefits.
Sco#e
List down the scope of the project. Describe what the system will and will not do.
&" 'unctional (e)uirements
This section should contain a tetual description of the requirements related to the customer!s business. This
should contain a list of all the business events related to the business process.
*" +on,functional (e)uirements
*"! Performance (e)uirements
The performance characteristics of the system that are required by the business should be outlined in this
section. "erformance characteristics include the speed, precision, capacity, safety, and reliability of the
software. These characteristics define the performance of the project.
3.2& Safety (e)uirements
Specify the requirements that are concerned with possible loss, damage, or harm that could result from the use
of the system. Define any safeguards or actions that must be ta#en, as well as potentially dangerous actions
that must be prevented. $dentify any safety certifications, policies, or regulations to which the system must
conform.
*"* Security (e)uirements
Specify any requirements regarding security, integrity, or privacy issues that affect the use of the system and
protection of the data used or created by the system. Define all user authentication or authori%ation
requirements, if any. $dentify any security or privacy policies or certifications the system must satisfy.
*"- ."/ 0usiness (ules
*"/ 1ist any o#erating #rinci#les about t2e #roduct, suc2 as %2ic2 individuals or
roles can #erform %2ic2 functions under s#ecific circumstances" T2ese are
not functional re)uirements in t2emselves, but t2ey mig2t im#ly certain
functional re)uirements to enforce t2e rules" Mention all users %2o %ill be
accessing t2e soft%are and describe t2eir res#ective rig2ts"
*"3
*"4 5ser Documentation
Sept. 15, 2003 Page 5
o 10
<Project code> Functional Specifcations Document
List the user documentation components that will be delivered along with the software, such as user manuals,
online help, and tutorials.
-" Assum#tions and De#endencies
List any assumed factors that could affect the stated requirements. These factors are not system constraints, but
areas where future changes might drive changes in the requirements. The project could be affected if these
assumptions are incorrect, are not shared, or changed.
&lso, identify any dependencies the project has on eternal factors. 'or eample, if you epect to integrate into
the system some components that are being developed by another project, you are dependent upon that project
to supply the correctly operating components on schedule.
/" System Arc2itecture
This section should provide the complete architecture of the system with description. Diagrammatic
architecture is compulsory. &lso include Data 'low Diagrams in this section.
3" 5se ases
3"! 5se ase Diagrams
$n this section provide use case diagrams using ()L convention.

3"& 5se ase Descri#tion
*ach (se +ase has a description, which describes the functionality that will be built in the proposed
system. The template for (se +ase descriptionn will is given below ,template is given on net page-.
4#se case Id5 name6
Actors5 /List of actors ,eternal agents-, indicating who initiated the use case0
Feature5 /'eature from which the use case wasis driven0
#se case Id5 1rite use case reference number.
7re-condition5 /List the assumptions required before this (se +ase can be
eecuted. 0
Scenarios
Step8 Action Soft9are Reaction
1.1 2umbered actions of the actors 2umbered description of system responses
2.2
n
Alternate Scenarios5 1rite additional, optional, branching or iterative steps. 3efer to specific
action number to ensure understandability.
1a5
2a5
7ost $onditions
SStep
8
Description
1 Sequentially list conditions epected at the completion of the use case.
Sept. 15, 2003 Page "
o 10
<Project code> Functional Specifcations Document
2
n
#se $ase $ross referenced /3elated use cases, which use or are used by this use case0
#ser Interface reference List user interface,s- that are related to this use case. (se
numbered list in case of more than one user interface
elements.
$oncurrenc and Response
4ive an estimate of the following
2umber of concurrent users
*pected response time of the use case
4" 6ra#2ical 5ser Interfaces
4ive a detailed account of user interfaces included in this project.
4#ser Interface Id5 -itle6
Interface Id. 1rite the reference number assigned to this ($.
#se case Reference 3efer to the use case invo#ing this ($.
Snaps!ot
$nclude a labeled snapshot of the user interface.
Data dictionar reference
*a.el Data dictionar identifier
1 3efer to fields in data dictionary
2
...
n
." 7ig2 1evel Design
."! 8( Diagram
."& Data Dictionary
The convention recommended for writing the data dictionary is as follows.
Sept. 15, 2003 Page #
o 10
<Project code> Functional Specifcations Document
."&"! Data !
Description ,3efer to Template on net page-.
."&"& Data &
Description ,3efer to Template net page-.
.
.
.
.
."&"* Data n
Description ,3efer to Template net page-.
.
The notation to develop content description is given below.
Data construct Notation /eanin)
= is composed of
Sequence + and
Selection [|] either5or
3epetition {}
n
n repetitions of
( ) optional data
* * delimits comments
<9.n Data n>
4 Data 16
Name 4ive primary name of the data or control item, the data store
or an eternal entity.
Alias 1rite other names used for the first entry.
Where-used/how-used List all processes that use the data or control item and how it
is used ,e.g., input to process, output from the process, as a
store, as n eternal entity-
Content description
2otation for representing content.
Supplementary information 6ther information about data types, preset values, restrictions
or limitations etc.
)a#e Similar tables for all the data items.
he notation to de!elop content description is "i!en #elow$
Data construct Notation /eanin)
= is composed of
Sequence + and
Selection [|] either5or
3epetition {}
n
n repetitions of
Sept. 15, 2003 Page $
o 10
<Project code> Functional Specifcations Document
( ) optional data
* * delimits comments
9" (e)uirements Traceability Matri:
Sr.
#Fea
ture
Feature Use
case ID
UI ID Priority Build Number Use Case Cross reference
!elated Use Cases"
1
&
.
.
The columns carry the following meaning.
'eature. Lists system features based on which use cases are built.
(se +ase $D. 1rite the $D of the use case for easy loo#up
($ $D. 1rite the user interface $D for this use case.
"riority. 4ive an appropriate rating to each use case according to its priority
7uild 2umber. 1rite the reference number to which this feature belongs.
(se +ase +ross 3ef. 1rite the related use cases separated with commas.
!;" (is< Analysis
:$onsult our 7ro;ect /ana)er for t!is section<
"erform an analysis of the constraints and identify the potential problems that may arise in the project due to
the constraints. 'or this section cover the following.
3is# $dentification
3is# Drivers
"ercentage $mpact of 3is# Drivers
3is# )itigation "lan
!!" ost 8stimation S2eet
:$onsult our 7ro;ect /ana)er for t!is section<
#. Soft$are de%elopment cost
&. Pac'aged soft$are
(. )ard$are
*. Net$or'
+. Client
,. -isc.

Sept. 15, 2003 Page %
o 10
<Project code> Functional Specifcations Document
Total cost .
!&" (eferences
This section should provide a complete list of all documents referenced at specific point in time. *ach document
should be identified by title, report number ,if applicable-, date, and publishing organi%ation. Specify the sources
from which the references can be obtained ,This section is li#e the bibliography in a published boo#-.
!ef. No. Document Title Date of !elease/ Publication Document Source
P#$%1-
&'-
Proposal
Project Proposal 1ct &. &' <#i+e t(e pat( of 5our
Project repositor56Fol"er>
!*" A##endices
$nclude supporting details that would be too distracting to include in the main body of the document.
Sept. 15, 2003 Page
10 o 10