Functional Specifications Document

<Project Title>
Project Code:

Internal Advisor:

External Advisor:

Project Manager: Project Team:

Submission Date:

_____________________
Project Managers Signature

<Project code>

Functional Specifications Document

Document

Sept. 15, 2003 of 11

Page 2

<Project code>

Functional Specifications Document

Document Information
Category Customer Project Document Document Version !"entifier Status Aut(or)s* Appro+er)s* !ssue Date Document /ocation Distri0ution Information FAST-NU <Project Title> Functional Specifications 1. P#$% 1-& '-FS Draft <Names of all t(e aut(ors of t(is "ocument> P, Sept. 1-. & ' 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 ASP 3S

Description Acti+e Ser+er Pa2es 3e4uirements Specifications

Sept. 15, 2003 of 11

Page 3

<Project code>

Functional Specifications Document

Sept. 15, 2003 of 11

Page

<Project code>

Functional Specifications Document

Table of ontents

1.Introduction.................................................................................................................................6
Purpose of Document ...........................................................................................................................................6 Project Overview...................................................................................................................................................6 Scope 6

2.Functional Requirements...........................................................................................................6 3.Non-functional Requirements....................................................................................................6

3.1Performance Requirements..............................................................................................................................6 3.22 Safety Requirements.....................................................................................................................................6 3.3Security Requirements.....................................................................................................................................6 3.48. !usiness Ru"es............................................................................................................................................6 3. #ist any operatin$ princip"es a%out t&e pro'uct( suc& as w&ic& in'ivi'ua"s or ro"es can perform w&ic& functions un'er specific circumstances. )&ese are not functiona" requirements in t&emse"ves( %ut t&ey mi$&t imp"y certain functiona" requirements to enforce t&e ru"es. *ention a"" users w&o wi"" %e accessin$ t&e software an' 'escri%e t&eir respective ri$&ts..............................................................................................6 3.+,ser Documentation.........................................................................................................................................+

4.Assumptions and Dependencies.................................................................................................7 .!"stem Arc#itecture....................................................................................................................7 6.$se %ases......................................................................................................................................7

6.1,se -ase Dia$rams..........................................................................................................................................+ + 6.2,se -ase Description.......................................................................................................................................+

7.&rap#ical $ser Interfaces..........................................................................................................' '.(i)# *e+el Desi)n.......................................................................................................................'

8.1.R Dia$ram......................................................................................................................................................8 8.2Data Dictionary................................................................................................................................................/ 8.2.1Data 1 / 8.2.2Data 2 / 8.2.3Data n /

,.Requirements -racea.ilit" /atri0..........................................................................................11 11.Ris2 Anal"sis ..........................................................................................................................11 11.%ost 3stimation !#eet ............................................................................................................11 12.References................................................................................................................................11
Sept. 15, 2003 of 11 Page 5

<Project code>

Functional Specifications Document

13.Appendices...............................................................................................................................11 !ection 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 textual 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.

*"& & 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"
Sept. 15, 2003 of 11 Page !

<Project code>

Functional Specifications Document

*"3 *"4 5ser Documentation

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 external factors. &or example, if you expect 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 next page,-

4$se case Id5 name6

Actors5 .List of actors +external agents,, indicating who initiated the use case/ Feature5 .&eature from which the use case wasis driven/ $se case Id5 0rite use case reference number. 7re-condition5 .List the assumptions required before this 'se *ase can be executed. /

!cenarios
!tep8 1.1 2.2 n Action 1umbered actions of the actors !oft9are Reaction 1umbered description of system responses

Alternate !cenarios5 0rite additional, optional, branching or iterative steps. 2efer to specific action number to ensure understandability. 1a5 2a5

7ost %onditions
Sept. 15, 2003 of 11 Page "

<Project code>

Functional Specifications Document

!!tep 8 1 2 n

Description Sequentially list conditions expected at the completion of the use case.

$se %ase %ross referenced $ser Interface reference

.2elated use cases, which use or are used by this use case/ 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 3ive an estimate of the following 1umber of concurrent users )xpected response time of the use case

4" 6ra#2ical 5ser Interfaces

3ive a detailed account of user interfaces included in this project.

4$ser Interface Id5 -itle6

Interface Id. 0rite the reference number assigned to this '#. $se case Reference 2efer to the use case invo"ing this '#. !naps#ot #nclude a labeled snapshot of the user interface.

Data dictionar" reference

*a.el 1 2 ... n Data dictionar" identifier 2efer to fields in data dictionary

." 7ig2 1evel Design

."! 8( Diagram

Sept. 15, 2003 of 11

Page #

<Project code>

Functional Specifications Document

."& Data Dictionary

The convention recommended for writing the data dictionary is as follows.

."&"! ."&"&
. . . .

Data ! Data &

Description +2efer to Template on next page,.

Description +2efer to Template next page,.

."&"*
.

Data n

Description +2efer to Template next page,. The notation to develop content description is given below. Data construct Sequence Selection 2epetition Notation 0 1 234 56n 78 9:9 /eanin) is composed of and either4or n repetitions of optional data delimits comments

<9.n Data n>

4 Data 16
Name Alias Where-used/how-used 3ive primary name of the data or control item, the data store or an external entity. 0rite other names used for the first entry. 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 external entity, 1otation for representing content. Content description Supplementary information 5ther 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 0
Sept. 15, 2003 of 11

/eanin) is composed of
Page $

<Project code>

Functional Specifications Document

Sequence Selection 2epetition

1 234 56n 78 9:9

and either4or n repetitions of optional data delimits comments

9" (e)uirements Traceability Matri:

Sr. #Fea ture 1 & . . Feature Use case ID UI ID Priority Build Number Use Case Cross reference !elated Use Cases"

The columns carry the following meaning &eature'se *ase #D'# #D!riority6uild 1umber'se *ase *ross 2efLists system features based on which use cases are built. 0rite the #D of the use case for easy loo"up 0rite the user interface #D for this use case. 3ive an appropriate rating to each use case according to its priority 0rite the reference number to which this feature belongs. 0rite 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 2is" #dentification 2is" Drivers !ercentage #mpact of 2is" Drivers 2is" (itigation !lan

!!"
#. &. (. *. +.

ost 8stimation S2eet

Soft$are de%elopment cost Pac'aged soft$are )ard$are Net$or' Client Page

:%onsult "our 7ro;ect /ana)er for t#is section<

Sept. 15, 2003 10 of 11

<Project code>

Functional Specifications Document

,.

-isc.

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. P#$% 1& 'Proposal Document Title Project Proposal Date of !elease/ Publication 1ct & . & ' Document Source <#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 11 of 11

Page