[School Account

System]
SOFTWARE REQUIREMENTS SPECIFICATION DOCUMENT

[Team Members Names]

SESSION: 2018 - 2020 | <MCS COMPUTER SCIENCE/ALLAMA IQBAL>
 Project Title

Revision History
Date Description Author Comments
<date> <Version 1> <Your Name> <First Revision>

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

Signature Printed Name Title Date

Dr. Supervisor, CSIT 21306 <date>

ii
 Project Title

Table of Contents

1. Introduction 1
1.1 Purpose 1
1.2 Scope 1
1.3 Definitions, Acronyms, and Abbreviations. 1
1.4 References 1
1.5 Overview 2

2. The Overall Description 2

2.1 Product Perspective 2
2.1.1 Operations 3
2.1.2 Site Adaptation Requirements 3
2.2 Product Functions 3
2.3 User Characteristics 4
2.4 General Constraints 4
2.5 Assumptions and Dependencies 4

3. Specific Requirements 5
3.1 External Interface Requirements 5
3.1.1 System Interfaces 5
3.1.2 Interfaces 5
3.1.3 Hardware Interfaces 5
3.1.4 Software Interfaces 5
3.1.5 Communications Interfaces 6
3.2 Functional Requirements 6
3.2.1 <Functional Requirement or Feature #1> 6
3.2.2 <Functional Requirement or Feature #2> 7
3.3 Use Cases 7
3.3.1 Use Case #1 7
3.3.2 Use Case #2 7
3.4 Classes / Objects Error! Bookmark not defined.
3.4.1 <Class / Object #1> Error! Bookmark not defined.
3.4.2 <Class / Object #2> Error! Bookmark not defined.
3.5 Non-Functional Requirements Error! Bookmark not defined.
3.5.1 Performance Error! Bookmark not defined.
3.5.2 Reliability Error! Bookmark not defined.
3.5.3 Availability Error! Bookmark not defined.
3.5.4 Security Error! Bookmark not defined.
3.5.5 Maintainability Error! Bookmark not defined.
3.5.6 Portability Error! Bookmark not defined.
3.6 Inverse Requirements Error! Bookmark not defined.
3.7 Logical Database Requirements Error! Bookmark not defined.
3.8 Design Constraints Error! Bookmark not defined.

iii
 Project Title

3.8.1 Standards Compliance Error! Bookmark not defined.

4. Analysis Models Error! Bookmark not defined.

4.1 Sequence Diagrams Error! Bookmark not defined.
4.2 Data Flow Diagrams (DFD) Error! Bookmark not defined.
4.3 State-Transition Diagrams (STD) Error! Bookmark not defined.

5. Supporting Information Error! Bookmark not defined.

Appendix A – Background Research on: Error! Bookmark not defined.
Appendix B – Data Dictionary Error! Bookmark not defined.

iv
 Project Title

1. Introduction
The Software Requirement Specification (SRS) is a manual document of
project provided. It is prepared before you start a project. The software requirements specification
includes purpose, scope, functional, and non-functional requirements, software and hardware
requirement, and other environmental information about the project. SRS is a documentation that helps
to prevent Software project failure. The student management system can handle all the details about a
student. The details includes personal details, course details, academic details etc. The SRS includes
purpose , scope, functional, non-functional requirements, software and hardware requirements and
other environmental information about the project.

1.1 Purpose
This project will handle whole the activity of the school. It provides the facilities to
keep the records of students, fees, teaching and non-teaching staff with their required details. The main
purpose is that to convert manual system into computerized. This is also generate different reports like
student fee slip, staff pay slip and Business sheet of profit and maintenance of the system. We can
convert this into computerized because the reason of manual work problems for maintenance of
account system specially.

1.2 Scope
Web Based Student Information Management System(WBSIMS) is developing
For general purpose and used to replace old paper work system and PUMS. Due to computerized of this
system, this increase the efficiency of result making, provide result to parents, give students result. It
provides a mechanism to edit the student information form which makes the system flexible

1.3 Definitions, Acronyms, and Abbreviations.

IEEE: The Institute of Electrical and Electronics Engineers.
PUMS: Project units Management System
SRS: Software Requirements System.
OS: Operating System
1.4 References
a) https://www.Scribd.com>doc>SRS-for
b) Search Videos
c) Visit to Schools.(The Pens School And Affaq System of Education)

SRS Document 1.0 Page 1 of 9 04/17/19 f

 Project Title

1.4 Overview
The school account management system allows authorized members to
access the records of students. The accountant easily access the pay slip of teachers and non-teaching
staff. First chapter of the SRS describes a little introduction about SRS/project scope reference definition
acronyms references and the overview of the whole documentation.

The rest of SRS examines the specifications of the school system in detail. Section 2 of the SRS presents
the general factors, that affect the account system and its requirements such as user characteristics,
specific functional performance , general constraints etc. Section 3 outlines the detailed specific
functional performance , system and other related requirements of the school system. Supporting
information about appendices is provide in section 3.

2. The Overall Description

The school account management system allows authorized members to access the records of students.
The accountant easily access the pay slip of teachers and non-teaching staff. Whenever you want to
admit a student you just enter the new student data it will automatically saved in the record. It can be
used in various educational Institutes and simplifies working of institutes.

2.1 Product Perspective

The proposed system shall be developed using client/server
architecture and be compatible with Microsoft windows operating system. The front end of the system
will be developed using web and backend will be developed using MSQL server.

2.1.1: User Interface:

The system will have following user-friendly and menu driven interface.

a) Login: to allow the entry of only authorized user through valid login ID and Password.
b) School details: to maintain the school details.
c) Program details: to maintain the program details.
d) Paper details: to maintain the paper details of a scheme for a particular program.
e) Faculty details: to maintain the faculty details.
2.1.3: Software Interface:

a) MS- window operating system

b) Microsoft visual Basic 6.0 for designing front-end

SRS Document 1.0 Page 2 of 9 04/17/19 f

 Project Title

c) MS SQL server for backend

d) platform

2.1.1 Operations
Specify the normal and special operations required by the user such as:
(1) The various modes of operations in the user organization
(2) Periods of interactive operations and periods of unattended operations
(3) Data processing support functions
(4) 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 customer’s 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 company’s 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.

2.2 Product Functions

This project will allows only authorized users with specifies rules (System
administrator, faculty and student). Depending upon the user’s role ,he/she will be able to access only
specific modules of the system.

System administrator will able to add , modify or delete program school student record account.

A login facility for enabling only admin.

System faculty will be able to generate reports.

SRS Document 1.0 Page 3 of 9 04/17/19 f

 Project Title

2.3 User Characteristics

User must be qualified, experienced and also technical experience, know about the
knowledge of computer technology.

Qualification: At least matriculation and comfortable with English.

Experience: Should be well versed/informed about the registration process of the school

2.4 General Constraints

 There will only be one administrator.
 The delete operations is available only to the administrator. To reduce the complexity of
the system. There is no check or delete operation. Hence administrator should be very
careful before deletion of any record and he/she will be responsible for data consistency.

2.5 Assumptions and Dependencies

The login id and password must be created by system administrator and communicated to the
concerned user confidentially to avoid unauthorized access to the system.

Registration process will be open only for specific duration.

SRS Document 1.0 Page 4 of 9 04/17/19 f

 Project Title

3. Specific Requirements
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 designer’s 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) Name

SRS Document 1.0 Page 5 of 9 04/17/19 f

 Project Title

(2) Mnemonic
(3) Specification number
(4) Version number
(5) 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
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

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

SRS Document 1.0 Page 6 of 9 04/17/19 f

 Project Title

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

…

SRS Document 1.0 Page 7 of 9 04/17/19 f