Functional Specifications Document

<Project Title>

Project Code:

Internal Advisor:

External Advisor:

Project Manager:

Project Team:

Submission Date:

_____________________
Project Manager’s Signature
Document
<Project code> Functional Specifications Document

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 Active Server Pages
RS Requirements Specifications

Sept. 15, 2003 Page 2 of

10
<Project code> Functional Specifications Document

Sept. 15, 2003 Page 3 of

10
<Project code> Functional Specifications Document

Table of Contents

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. System Architecture..........................................................................................................5

6. Use Cases............................................................................................................................5
6.1 Use Case Diagrams.............................................................................................................................5
6.2 Use Case Description..........................................................................................................................5

7. Graphical User Interfaces.................................................................................................6

8. High Level Design..............................................................................................................6

8.1 ER Diagram...........................................................................................................................................6
8.2 Data Dictionary.....................................................................................................................................6
8.2.1 Data 1............................................................................................................................................................ 6
8.2.2 Data 2............................................................................................................................................................ 6
8.2.3 Data n............................................................................................................................................................ 6

9. Requirements Traceability Matrix..................................................................................7

10. Risk Analysis......................................................................................................................8

11. Cost Estimation Sheet........................................................................................................8

12. References...........................................................................................................................8

13. Appendices..........................................................................................................................9

Sept. 15, 2003 Page 4 of

10
<Project code> Functional Specifications Document

Section 1

1. Introduction
1.1 Purpose 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.

1.2 Project Overview

State a brief description of the project under study. Describe how the software will be used and identify the
relevant goals and benefits.

1.3 Scope
List down the scope of the project. Describe what the system will and will not do.

2. Functional Requirements
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.

3. Non-functional Requirements
3.1 Performance Requirements
The performance characteristics of the system that are required by the business should be outlined in this
section. Performance characteristics include the speed, precision, capacity, safety, and reliability of the
software. These characteristics define the performance of the project.

3.2 2 Safety Requirements

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 taken, as well as potentially dangerous actions
that must be prevented. Identify any safety certifications, policies, or regulations to which the system must
conform.

3.3 Security Requirements

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 authorization
requirements, if any. Identify any security or privacy policies or certifications the system must satisfy.

3.4 8.5 Business Rules

3.5 List any operating principles about the product, such as which individuals or
roles can perform which functions under specific circumstances. These are
not functional requirements in themselves, but they might imply certain
functional requirements to enforce the rules. Mention all users who will be
accessing the software and describe their respective rights.
3.6
3.7 User Documentation

Sept. 15, 2003 Page 5 of

10
<Project code> Functional Specifications Document

List the user documentation components that will be delivered along with the software, such as user manuals,
online help, and tutorials.

4. Assumptions and Dependencies

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.

Also, identify any dependencies the project has on external factors. For 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.

5. System Architecture
This section should provide the complete architecture of the system with description. Diagrammatic
architecture is compulsory. Also include Data Flow Diagrams in this section.

6. Use Cases
6.1 Use Case Diagrams
In this section provide use case diagrams using UML convention.

6.2 Use Case Description

Each Use Case has a description, which describes the functionality that will be built in the proposed
system. The template for Use Case descriptionn will is given below (template is given on next page):

<Use case Id: name>

Actors: <List of actors (external agents), indicating who initiated the use case>
Feature: <Feature from which the use case wasis driven>
Use case Id: Write use case reference number.
Pre-condition: <List the assumptions required before this Use Case can be
executed. >
Scenarios
Step# Action Software Reaction
1.1 Numbered actions of the actors Numbered description of system responses
2.2
n
Alternate Scenarios: Write additional, optional, branching or iterative steps. Refer to specific
action number to ensure understandability.
1a:

2a:

Post Conditions
SStep Description
#
1 Sequentially list conditions expected at the completion of the use case.

Sept. 15, 2003 Page 6 of

10
<Project code> Functional Specifications Document

2
n
Use Case Cross referenced <Related use cases, which use or are used by this use case>
User Interface reference List user interface(s) that are related to this use case. Use
numbered list in case of more than one user interface
elements.
Concurrency and Response
Give an estimate of the following
 Number of concurrent users
 Expected response time of the use case

7. Graphical User Interfaces

Give a detailed account of user interfaces included in this project.

<User Interface Id: Title>

Interface Id. Write the reference number assigned to this UI.
Use case Reference Refer to the use case invoking this UI.
Snapshot
Include a labeled snapshot of the user interface.

Data dictionary reference

Label Data dictionary identifier
1 Refer to fields in data dictionary
2
...
n

8. High Level Design

8.1 ER Diagram

8.2 Data Dictionary

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

Sept. 15, 2003 Page 7 of

10
<Project code> Functional Specifications Document

8.2.1 Data 1
Description (Refer to Template on next page).

8.2.2 Data 2
Description (Refer to Template next page).
.
.
.
.
8.2.3 Data n
Description (Refer to Template next page).
.

The notation to develop content description is given below.

Data construct Notation Meaning

= is composed of
Sequence + and
Selection [|] either-or
Repetition {}n n repetitions of
() optional data
*…* delimits comments

<9.n Data n>

< Data 1>
Name Give primary name of the data or control item, the data store
or an external entity.

Alias Write 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 external entity)

Notation for representing content.

Content description
Supplementary information Other information about data types, preset values,
restrictions or limitations etc.

Make Similar tables for all the data items.

The notation to develop content description is given below:

Data construct Notation Meaning

= is composed of
Sequence + and
Selection [|] either-or
Repetition {}n n repetitions of
() optional data

Sept. 15, 2003 Page 8 of

10
<Project code> Functional Specifications Document

*…* delimits comments

9. Requirements Traceability Matrix

Sr. Feature Use UI ID Priority Build Number Use Case Cross reference
#Fea case ID (Related Use Cases)
ture
 1    
 2  
.
.

The columns carry the following meaning:

 Feature: Lists system features based on which use cases are built.
 Use Case ID: Write the ID of the use case for easy lookup
 UI ID: Write the user interface ID for this use case.
 Priority: Give an appropriate rating to each use case according to its priority
 Build Number: Write the reference number to which this feature belongs.
 Use Case Cross Ref: Write the related use cases separated with commas.

10. Risk Analysis

(Consult your Project Manager for this section)
Perform an analysis of the constraints and identify the potential problems that may arise in the project due to
the constraints. For this section cover the following:

 Risk Identification
 Risk Drivers
 Percentage Impact of Risk Drivers
 Risk Mitigation Plan

11. Cost Estimation Sheet

(Consult your Project Manager for this section)

1. Software development cost

2. Packaged software
3. Hardware
4. Network
5. Client
6. Misc.

Total cost =

Sept. 15, 2003 Page 9 of

10
<Project code> Functional Specifications Document

12. References
This section should provide a complete list of all documents referenced at specific point in time. Each document
should be identified by title, report number (if applicable), date, and publishing organization. Specify the sources
from which the references can be obtained (This section is like the bibliography in a published book).

Ref. No. Document Title Date of Release/ Publication Document Source

PGBH01- Project Proposal Oct 20, 2003 <Give the path of your
2003- Project repository/Folder>
Proposal

13. Appendices
Include supporting details that would be too distracting to include in the main body of the document.

Sept. 15, 2003 Page 10 of

10