17.12.

2015

Session: 2014 - 2016 | <Department OF COMPUTER SCIENCE & IT>

Project Title

Revision History
Date
<date>

Description
<Version 1>

Author

Comments

<Your Name>

<First Revision>

Document Approval
The following Software Requirements Specification has been accepted and approved by the following:
Signature

Printed Name
Salman Qadri

Title
Supervisor, CSIT 21306

Date
<date>

Project Title

Table of Contents

1.

Introduction
1.1 Purpose
1.2

Scope

1.3 Definitions, Acronyms, and Abbreviations.

1.4 References
1.5 Overview
2. The Overall Description
2.1 Product Perspective
2.1.1Operations
2.1.2 Site Adaptation Requirements
2.2 Product Functions
2.3 User Characteristics
2.4 General Constraints
2.5 Assumptions and Dependencies
3. Specific Requirements
3.1 External Interface Requirements
3.1.1 System Interfaces
3.1.2 Interfaces
3.1.3 Hardware Interfaces
3.1.4 Software Interfaces
3.1.5 Communications Interfaces
3.2 Functional Requirements
3.2.1 <Functional Requirement or Feature #1>
3.2.2 <Functional Requirement or Feature #2>
3.3 Use Cases
3.3.1 Use Case #1
3.3.2 Use Case #2
3.4 Classes / Objects
3.4.1 <Class / Object #1>
3.4.2 <Class / Object #2>
3.5 Non-Functional Requirements
Sr.No.
3.5.1 Performance
3.5.2 Reliability
3.5.3 Availability
3.5.4 Security
3.5.5 Maintainability
3.5.6 Portability
3.6 Inverse Requirements
3.7Logical Database Requirements

Project Title

3.8Design Constraints
3.8.1 Standards Compliance
4. Supporting Information
Appendix A Background Research on:
Appendix B Data Dictionary

Project Title

Chapter 1
1. Introduction
This SRS of Project management system contains all material that provides the whole
description of projects which will helpful for the students to make their projects as best as
they can do. In this SRS coordinator will assign the assignments to the students with
whole detail so that students will make their projects accordingly. For the help and
guidance of the students department is supposed to be assign an internal for the student or
the group of the student to make sure them that they are working correctly.
1.1 Purpose
The purpose to make this SRS to get rid of old fashioned documentation related to their
projects. As per the direction of HEC it is declared that all old fashioned documentation
should be converted to the new versions of the SRS which is necessary for the new era
and computer working.
1.2 Scope
The Project Management System tells about the management of software
projects. It provides a complete software project with defined scope, time and cost
constraints with the management of resources.
The management system provide a tool of decision making and required functionality it
does not go to detail of data storage, change management
This document describes only requirements for the whole- system functionality which is
defined in the use case model. A use case diagram is a graphic depiction of the
interactions among the elements of a system. A use case is a methodology used in system
analysis to identify, clarify, and organize system requirements.
In this SRS documentation:
Provide the project list.
Helpful material.
Internal list (for the students to their guidance).
First deliverable (SRS) submission on due date.
Marks obtained in first deliverable.
SRS Document 1.0

Page 1 of 9

03/17/16

Project Title

Second deliverable (design phase) submission on due date.

Marks obtained in second deliverable.
External viva.
Total marks of project.

1.3 Definitions, Acronyms, and Abbreviations.

Term/Abbreviation

Explanation

PMS
CMS
CVS
VSS
PERT
GUI
LAMP
DBMS

Project Management System

Change Management System (Bug tracking tool)
Concurrent Versions System
Microsoft Visual SourceSafe
Program Evaluation and Review Technique
Graphical User Interface
A server that is running Linux, Apache, My-SQL and PHP
Database Management System

DSS
RBAC

Data Storage System

Role Based Access Control

1.4 References
Reference & Document Title

Applicable Reference and Version

1 Project Description
2 Raw PMS Requirements
3 Use Case diagrams
4 Official Guidelines for Interface Developers and
Designers
5 Review comments

case-study.pdf
Raw requirements.doc
Use Case Diagrams.doc
http://msdn.microsoft.com/library/enus/dnwue/html/welcome.asp
PMS_Requirements_Review.pdf

1.5 Overview
In this SRS documentation:
SRS Document 1.0

Page 2 of 9

03/17/16

Project Title

(1) It contains the whole description of all material provided for the project.
(2) How much efforts are being made for the documentation.
In this SRS documentation the detail of the project necessarily provided for the project
which understandable for the student. The project description should be in concise and
concrete manners so that everyone can understand the whole project and its detail with
working.
Chapter 2 defines the general product functions, intended application, constraints to be respected and the
assumption made in order to define requirements.
Chapter 3 specifies functional (Section 3.1) and non-functional requirements (all other sections), usability,
reliability, security, performance and maintainability considerations and requirements to a level of detail
sufficient to enable designers to design a system to satisfy these requirements and testers to test that the
system satisfies these requirements.
Chapter 4 contains index, appendices and supporting information.
The document is structured according to the IEEE 830-1998 standard [IEEE-830].

SRS Document 1.0

Page 3 of 9

03/17/16

Project Title

Chapter 2
2. The Overall Description
Describe the general factors that affect the product and its requirements. This section
does not state specific requirements. Instead, it provides a background for those
requirements, which are defined in section 3, and makes them easier to understand. In a
sense, this section tells the requirements in plain English for the consumption of the
customer. Section3 will contain a specification written for the developers.
2.1 Product Perspective
PMS it a standalone system that provides functionality described in the
Product functions section. It includes all subsystems needed to fulfil these
software requirements. In addition, the PMS has interfaces to the external
systems, such Version Control System, Change Management and Bug
Tracking System and Payroll System. These interfaces shall be implemented
according to available industry standards and shall be independent from a
specific external system.
Any detailed definition of an external system is out of scope of this
document.
The figure 1 shows the decomposition of PMS on the functionality areas and
the supported external systems.
We have to distinguish a Data Storage System (DSS) from all other external
systems in that way, that Data Storage System enables normal functioning of
PMS and is therefore essential. PMS stores all its data in the DSS and hence
has to maintain the connection to it. PMS shall access the data storage
system through standard interface (JDBC, ODBS, ADO etc). See Data storage
system section for more information.

SRS Document 1.0

Page 4 of 9

03/17/16

Project Title

2.1.1Operations
Specify the normal and special operations required by the user such as:
(1)
(2)
(3)
(4)

The various modes of operations in the user organization

Periods of interactive operations and periods of unattended operations
Data processing support functions
Backup and recovery operations

(Note: This is sometimes specified as part of the User Interfaces section.) If you separate
this from the UI stuff earlier, then cover business process type stuff that would impact the
design. For instance, if the company brings all their systems down at midnight for data
backup that might impact the design. These are all the work tasks that impact the design
of an application, but which might not be located in software.
2.1.2 Site Adaptation Requirements
In this section:
(1) Define the requirements for any data or initialization sequences that are specific to a
given site, mission, or operational mode
(2) Specify the site or mission-related features that should be modified to adapt the software
to a particular installation

If any modifications to the customers work area would be required by your system, then
document that here. For instance, A 100Kw backup generator and 10000 BTU air
conditioning system must be installed at the user site prior to software installation.
This could also be software-specific like, New data tables created for this system must
be installed on the companys existing DB server and populated prior to system
activation. Any equipment the customer would need to buy or any software setup that
needs to be done so that your system will install and operate correctly should be
documented here.

SRS Document 1.0

Page 5 of 9

03/17/16

Project Title

2.2 Product Functions

Project Management System:
It provides a framework for project management and supports multiple projects. Also
supports distributed development, It allows to define fine-grained project step like tasks
and subtasks. And also allows to create complex dependencies between tasks Or supports
resource management, They provides user and user role management or supports budget
controlling and stores all system data in the centralized data storage. It has an interface to
an external version management and code storage system. And it has an interface to an
external change management and bug tracking system, They can provide data for an
external payroll system. It Can have an interface with enterprise-wide user management
system.

2.3.2Unsupported functions
The Project Management System:
does not provide code management or code storage,
does not provide version control,
does not provide bug tracking and change management,
does not provide employee management,
does not provide work time accounting and payroll.

2.3 User Characteristics

The system is intended to be used by various users. We can divide all users into four profiles, each with
own responsibility and role in the PMS:
User

Functions and Responsibilities

Source

Manager

Responsible for the batch of the projects and

controls overall development flow. Assigns projects
to the project team leader and controls fulfilment of
the project team leaders tasks.

1 Project
Description

Project Team Leader

Responsible for a particular project. Leads a

project team of 2 to 20 developers. Assigns tasks
to project team members and controls their
fulfilment. Reports to the manager.

1 Project
Description

Project Team Member

Responsible for a particular task or part of a task.

Reports to the Project Team Leader.

1 Project
Description

System Administrator

Responsible for the installation, maintenance,

security and troubleshooting of the productive
system. Manage users of the PMS. Reports to the
Manager

1 Project
Description

Table 1. User Profiles

SRS Document 1.0

Page 6 of 9

03/17/16

Project Title

2.4 General Constraints

The document represents a study project, not a real-life SRS, and misses detailed description and
requirement for many areas. It gives only directions and requirement templates for creating project
management system.

2.5 Assumptions and Dependencies

2.6.1Data storage system
The PMS stores all the operational (portfolios, projects, tasks, subtasks, dependencies, resource
assignments) and reference (resources, users, user roles) data in the centralized data storage. There is
no requirement for a specific data storage system. We assume that the PMS shall be able to access and
store data in any Data Base Management System (DBMS) through the standard interface like JDBC,
OBDC, ADO etc. provided by development environment.
The description and requirements for such a DBMS is out-of-scope of this document and is not
considered further.

2.6.2Distributed project management

The PMS shall support distributed project management. Hence PMS shall run on various platforms and
be able to communicate with its subsystems via Internet. We will not discuss further the communication
protocols and Internet platforms.

2.6.3Representation
We assume that the PSM represents the project management data according to the common
representation standards and terminology. It also generates usual graphical representation of project
tasks and their dependencies like PERT, Gantt, AON (Activity on Node) and AOA (Activity on Arrow)
diagrams. The specification of such diagrams is out-of-scope of this document.

SRS Document 1.0

Page 7 of 9

03/17/16

Project Title

Chapter 3
3. Specific Requirements
This will be the largest and most important section of the SRS. The customer
requirements will be embodied within Section 2, but this section will give the Drequirements that are used to guide the projects software design, implementation, and
testing.
Each requirement in this section should be:
Correct
Traceable (both forward and backward to prior/future artifacts)
Unambiguous
Verifiable (i.e., testable)
Prioritized (with respect to importance and/or stability)
Complete
Consistent
Uniquely identifiable (usually via numbering like 3.4.5.6)
Attention should be paid to the carefully organize the requirements presented in this
section so that they may easily accessed and understood. Furthermore, this SRS is not
the software design document, therefore one should avoid the tendency to over-constrain
(and therefore design) the software project within this SRS.

SRS Document 1.0

Page 8 of 9

03/17/16

Project Title

3.1 External Interface Requirements

3.1.1 System Interfaces
List each system interface and identify the functionality of the software to accomplish the
system requirement and the interface description to match the system. These are external
systems that you have to interact with. For instance, if you are building a business
application that interfaces with the existing employee payroll system, what is the API to
that system that designers will need to use?
3.1.2 Interfaces
Specify:
(1) The logical characteristics of each interface between the software product and its users.
(2) All the aspects of optimizing the interface with the person who must use the system

This is a description of how the system will interact with its users. Is there a GUI, a
command line or some other type of interface? Are there special interface requirements?
If you are designing for the general student population for instance, what is the impact of
ADA (American with Disabilities Act) on your interface?
3.1.3 Hardware Interfaces
Specify the logical characteristics of each interface between the software product and the
hardware components of the system. This includes configuration characteristics. It also
covers such matters as what devices are to be supported, how they are to be supported
and protocols. This is not a description of hardware requirements in the sense that This
program must run on a Mac with 64M of RAM. This section is for detailing the actual
hardware devices your application will interact with and control. For instance, if you are
controlling X10 type home devices, what is the interface to those devices? Designers
should be able to look at this and know what hardware they need to worry about in the
design. Many business type applications will have no hardware interfaces. If none, just
state The system has no hardware interface requirements If you just delete sections
that are not applicable, then readers do not know if: a. this does not apply or b. you
forgot to include the section in the first place.
3.1.4 Software Interfaces
Specify the use of other required software products and interfaces with other application
systems. For each required software product, include:
(1)
(2)
(3)
(4)
(5)

Name
Mnemonic
Specification number
Version number
Source

For each interface, provide:

(1) Discussion of the purpose of the interfacing software as related to this software product
(2) Definition of the interface in terms of message content and format
SRS Document 1.0

Page 9 of 9

03/17/16

Project Title

Here we document the APIs, versions of software that we do not have to write, but that
our system has to use. For instance if your customer uses SQL Server 7 and you are
required to use that, then you need to specify i.e.
3.1.4.1 Microsoft SQL Server 7

The system must use SQL Server as its database component. Communication with the
DB is through ODBC connections. The system must provide SQL data table definitions
to be provided to the company DBA for setup.
A key point to remember is that you do NOT want to specify software here that you think
would be good to use. This is only for customer-specified systems that you have to
interact with. Choosing SQL Server 7 as a DB without a customer requirement is a
Design choice, not a requirement. This is a subtle but important point to writing good
requirements and not over-constraining the design.
3.1.5 Communications Interfaces
Specify the various interfaces to communications such as local network protocols, etc.
These are protocols you will need to directly interact with. If you happen to use web
services transparently to your application then do not list it here. If you are using a
custom protocol to communicate between systems, then document that protocol here so
designers know what to design. If it is a standard protocol, you can reference an existing
document or RFC.
3.2 Functional Requirements
Sr. No.

Description

SRS-01

System should be able to provide login facility

SRS-02

System should be able to add User Types.

SRS-03

System should be able to load User Types.

SRS-04

System should be able to update User Types.

SRs-05

System should be able to delete User Types.

SRS-06

System should be able to add Users.

SRS-7

System should be able to load Users.

SRS-8

System should be able to update Users.

SRS-9

System should be able to delete Users.

SRS-10

System should be able to add Programs.

SRS-11

System should be able to load Programs.

SRS Document 1.0

Page 10 of 9

03/17/16

Project Title

SRS-12

System should be able to update Programs.

SRS-13

System should be able to delete Programs.

SRS-14

System should be able to add Sessions.

SRS-15

System should be able to load Sessions.

SRS-16

System should be able to update Sessions.

SRS-17

System should be able to delete Sessions.

SRS-18

System should be able to add Timings.

SRS-19

System should be able to load Timings.

SRS-20

System should be able to update Timings.

SRS-21

System should be able to delete Timings.

SRS-22

System should be able to add Departments.

SRS-23

System should be able to load Departments.

SRS-24

System should be able to update Departments.

SRS-25

System should be able to delete Departments.

SRS-26

System should be able to add Classes.

SRS-27

System should be able to load Classes.

SRS-28

System should be able to update Classes.

SRS-29

System should be able to delete Classes.

SRS-30

System should be able to add Statuses

SRS-31

System should be able to load Statuses.

SRS-32

System should be able to update Statuses.

SRS-33

System should be able to delete Statuses.

SRS-34

System should be able to add Categories.

SRS-35

System should be able to load Categories.

SRS-36

System should be able to update Categories.

SRS-37

System should be able to delete Categories.

SRS-38

System should be able to add Designations.

SRS-39

System should be able to load Designations.

SRS Document 1.0

Page 11 of 9

03/17/16

Project Title

SRS-40

System should be able to update Designations.

SRS-41

System should be able to delete Designations.

SRS-42

System should be able to add Students.

SRS-43

System should be able to load Students.

SRS-44

System should be able to update Students.

SRS-45

System should be able to delete Students.

SRS-46

System should be able to add Projects.

SRS-47

System should be able to load Projects.

SRS-48

System should be able to update Projects.

SRS-49

System should be able to delete Projects.

SRS-50

System should be able to add Internals.

SRS-51

System should be able to load Internals.

SRS-52

System should be able to update Internals.

SRS-53

System should be able to delete Internals.

SRS-54

System should be able to add Externals.

SRS-55

System should be able to load Externals.

SRS-56

System should be able to update Externals.

SRs-57

System should be able to delete Externals.

SRS-58

System should be able to add Phases.

SRS-59

System should be able to load Phases.

SRS-60

System should be able to Update Phases.

SRS-61

System should be able to Delete Phases.

SRS-62

System Should be able to add Enrollments.

SRS-63

System should be able to load Enrollments.

SRS-64

System should be able to Delete Enrollments.

SRS-65

System should be able to update Enrollments.

SRS-66

System should be able to addProject Proposals.

SRS-67

System should be able to load Project Proposals.

SRS Document 1.0

Page 12 of 9

03/17/16

Project Title

SRS-68

System should be able to delete Project Proposals.

SRS-69

System should be able to update Project Proposals.

SRS-70

System should be able to add ProjectProposalMembers.

SRS-71

System should be able to load ProjectProposalMembers...

SRS-72

System should be able to delete ProjectProposalMembers.

SRS-73

System should be able to update ProjectProposalMembers.

SRS-74

System should be able loadProjectProposalPhases.

SRS-75

System should be able to load ProjectProposalphases.

SRS-76

System should be able to delete ProjectProposalPhases.

SRS-77

System should be able to update ProjectProposalPhases.

SRS-78

System should be able to add ProjectStatuses.

SRS-79

System should be able to delete ProjectStatuses.

SRS-80

System should be able to load ProjectStatuses.

SRS-81

System should be able to update ProjectStatuses.

SRS-82

System should be able to add Campuses.

SRS-83

System should be able to load Campuses.

SRS-84

System should be able to delete Campuses.

SRS-85

System should be able to update Campuses

SRS-86

System should be able to add YearlyEvaluationClasses.

SRS-87

System should be able to load YearlyEvaluationClasses.

SRS-88

System should be able to delete YearlyEvaluationClasses.

SRS-89

System should be able to update YearlyEvaluationClasses.

SRS-90

System should be able to add YearlyEvaluationNotices.

SRS-91

System should be able to load YearlyEvaluationNotices.

SRS-92

System should be able to delete YearlyEvaluationNotices.

SRS-93

System should be able to update YearlyEvaluationNotices.

SRS-94

System should be able to add YearlyEvaluationResults.

SRS-95

System should be able to load YearlyEvaluationResults.

SRS Document 1.0

Page 13 of 9

03/17/16

Project Title

SRS-96

System should be able to delete YearlyEvaluationResults.

SRS-97

System should be able to update YearlyEvaluationResults.

This section describes specific features of the software project. If desired, some
requirements may be specified in the use-case format and listed in the Use Cases Section.
3.2.1 <Functional Requirement or Feature #1>
3.2.1.1 Introduction
3.2.1.2 Inputs
3.2.1.3 Processing
3.2.1.4 Outputs
3.2.1.5 Error Handling

3.2.2 <Functional Requirement or Feature #2>

3.3 Use Cases

This section contains use cases of the ------------------------ system.
3.3.1 Use Case #1
3.3.2 Use Case #2

3.4 Classes / Objects

This section contains major classes of the ------------------------ system.
3.4.1 <Class / Object #1>
3.4.1.1 Attributes
3.4.1.2 Functions

<Reference to functional requirements and/or use cases>

3.4.2 <Class / Object #2>

SRS Document 1.0

Page 14 of 9

03/17/16

Project Title

3.5 Non-Functional Requirements

Descriptions

Sr.No.
01

It necessary for run the project to install the Asp.net

02
At least the window server pack 2 or 3 are must to install Asp.net
tool
03
It necessary to run the project to install the SQL server 2008.
04 System Developed for only two members.

Non-functional requirements may exist for the following attributes. Often these
requirements must be achieved at a system-wide level rather than at a unit level. State
the requirements in the following sections in measurable terms (e.g., 95% of transaction
shall be processed in less than a second, system downtime may not exceed 1 minute per
day, > 30 day MTBF value, etc.).
3.5.1 Performance
3.5.2 Reliability
3.5.3 Availability
3.5.4 Security
3.5.5 Maintainability
3.5.6 Portability
3.6 Inverse Requirements
State any *useful* inverse requirements.
3.7Logical Database Requirements
This section specifies the logical requirements for any information that is to be placed
into a database. This may include:

Types of information used by various functions

SRS Document 1.0

Page 15 of 9

03/17/16

Project Title

Frequency of use
Accessing capabilities
Data entities and their relationships
Integrity constraints
Data retention requirements

If the customer provided you with data models, those can be presented here. ER
diagrams (or static class diagrams) can be useful here to show complex data relationships.
Remember a diagram is worth a thousand words of confusing text.
3.8Design Constraints
Specify design constraints that can be imposed by other standards, hardware limitations,
etc.
3.8.1 Standards Compliance
Specify the requirements derived from existing standards or regulations. They might
include:
(1) Report format
(2) Data naming
(3) Accounting procedures
(4) Audit Tracing
For example, this could specify the requirement for software to trace processing activity.
Such traces are needed for some applications to meet minimum regulatory or financial
standards. An audit trace requirement may, for example, state that all changes to a
payroll database must be recorded in a trace file with before and after values.

4. Supporting Information
Appendix A Background Research on:
Topic 1
Topic 2
Topic 3

Topic n
Appendix B Data Dictionary

SRS Document 1.0

Page 16 of 9

03/17/16