You are on page 1of 11

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

<Version x>

Document

Sept. 15, 2003 11

Page 2 of

<Project code>

Functional Specifications Document

<Version x>

Document Information
Category Customer Project Document Document Version Identifier Status Author(s) Approver(s) Issue Date Document Location Distribution Information FAST-NU <Project Title> Functional Specifications 1.0 PGBH01-2003-FS Draft <Names of all the authors of this document> PM Sept. 15, 2003 1. 2. 3. Advisor PM Project Office

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 RS

Description Active Server Pages Requirements Specifications

Sept. 15, 2003 11

Page 3 of

<Project code>

Functional Specifications Document

<Version x>

Sept. 15, 2003 11

Page 4 of

<Project code>

Functional Specifications Document

<Version x>

Table of Contents

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.5 Business Rules............................................................................................................................................6 3.5List 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..............................................................................................6 3.7User Documentation.........................................................................................................................................7

4.Assumptions and Dependencies.................................................................................................7 5.System Architecture....................................................................................................................7 6.Use Cases......................................................................................................................................7


6.1Use Case Diagrams..........................................................................................................................................7 7 6.2Use Case Description.......................................................................................................................................7

7.Graphical User Interfaces..........................................................................................................8 8.High Level Design.......................................................................................................................8


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

9.Requirements Traceability Matrix..........................................................................................10 10.Risk Analysis ..........................................................................................................................10 11.Cost Estimation Sheet ............................................................................................................10 12.References................................................................................................................................11
Sept. 15, 2003 11 Page 5 of

<Project code>

Functional Specifications Document

<Version x>

13.Appendices...............................................................................................................................11 Section 1

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

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.

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 customers 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.
Sept. 15, 2003 11 Page 6 of

<Project code>

Functional Specifications Document

<Version x>

3.6 3.7 User Documentation


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# 1.1 2.2 n Action Numbered actions of the actors Software Reaction Numbered description of system responses

Alternate Scenarios: Write additional, optional, branching or iterative steps. Refer to specific action number to ensure understandability. 1a: 2a:

Post Conditions
Sept. 15, 2003 11 Page 7 of

<Project code>

Functional Specifications Document

<Version x>

SStep # 1 2 n

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

Use Case Cross referenced User Interface reference

<Related use cases, which use or are used by this use case> 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 1 2 ... n Data dictionary identifier Refer to fields in data dictionary

8. High Level Design


8.1 ER Diagram

Sept. 15, 2003 11

Page 8 of

<Project code>

Functional Specifications Document

<Version x>

8.2 Data Dictionary


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

8.2.1 8.2.2
. . . .

Data 1 Data 2

Description (Refer to Template on next page).

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 Sequence Selection Repetition Notation = + [|] {}n () ** Meaning is composed of and either-or n repetitions of optional data delimits comments

<9.n Data n>

< Data 1>


Name Alias Where-used/how-used Give primary name of the data or control item, the data store or an external entity. Write 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) 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 =
Sept. 15, 2003 11

Meaning is composed of
Page 9 of

<Project code>

Functional Specifications Document

<Version x>

Sequence Selection Repetition

+ [|] {}n () **

and either-or n repetitions of optional data delimits comments

9. Requirements Traceability Matrix


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

The columns carry the following meaning:

Feature: Use Case ID: UI ID: Priority: Build Number: Use Case Cross Ref:

Lists system features based on which use cases are built. Write the ID of the use case for easy lookup Write the user interface ID for this use case. Give an appropriate rating to each use case according to its priority Write the reference number to which this feature belongs. 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. 2. 3. 4. Software development cost Packaged software Hardware Network

Sept. 15, 2003 11

Page 10 of

<Project code>

Functional Specifications Document

<Version x>

5. 6.

Client Misc.

Total cost =

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. PGBH012003Proposal Document Title Project Proposal Date of Release/ Publication Oct 20, 2003 Document Source <Give the path of your Project repository/Folder>

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

Sept. 15, 2003 11

Page 11 of

You might also like