School Management System (SMS)

Software Requirement Specification for School Management System
Session: BS-IT 2020-2024
Project Advisor: Prof. Faraz Shoukat
Submitted By
Ehtisham Nazir 20256
Quonain Ejaz 036635
Shees Muhammad Zahid 20254
DEPARTMENT OF INFORMATION TECHNOLOGY, GOVT M.A.O COLLEGE

LAHORE
1
STATEMENT OF SUBMISSION
This is to certify that Ehtisham Nazir Roll no 20256, Shees Muhammad Zahid Roll no
20254 and Quonain Ejaz Roll no 036635 have successfully completed the final project
named as: School Management System (SMS), at the GOVT M.A.O College Lahore
Affiliated with Punjab University College of Information technology, University of the
Punjab, Lahore, to fulfill the partial requirements of the degree of Bachelors in
Information Technology.
Project Examiner PUCIT, Lahore
Project Office Supervisor Project Primary Advisor

Name: Prof. Faraz Shoukat Name: Prof. Faraz Shoukat
Designation: Lecturer of I.T. Department Designation: Lecturer
GOVT M.A.O College Lahore
GOVT M.A.O College Lahore

LAHORE
2
Proofreading Certificate
It is to certify that I have read the document meticulously and circumspectly. We are
convinced that the resultant project does not contain any spelling, punctuation and
grammatical mistakesas such. All in all, we finalize this document well organized and We are
in no doubt that its objective has been successfully met.
Prof. Faraz Shoukat

Lecturer, GOVT M.A.O College Lahore

LAHORE
3
ACKNOWLEDGEMENT
All praises be to Allah Almighty, the most Beneficent and the most Merciful for giving us the
courage and capability to complete this project. All loves for the Holy Prophet Muhammad
(S.A.A.W).
It is debt of honor for me to express my deep sense of gratitude to respected Prof. Faraz
Shoukat, Lecturer Govt M.A.O College Lahore. He has been a constant source of guidance
throughout the course of this project.
We express our thankfulness to all my respectable teachers especially Prof. Haseeb Azmat
and Prof Irfan Shabbir for their inspiring behavior and patronage.
Finally, we are grateful to our parents, our brothers and our sisters who remembered us in their
prayers. May Allah bless them all with happiness and good health!
We would like to express our sincere gratitude for our parents, for her kind support,
patience and encouragement during our studies. We dedicate our work to our teachers,
parents and friends.

LAHORE
4
ABSTRACT
School management system (SMS) consists of tasks such as registering students, attendance
record keeping to control absentees, producing report cards, producing official transcript,
preparing timetable and producing different reports for teachers.

LAHORE
5
Table of Contents
CHAPTER 1: INTRODUCTION .................................................................................... 8

1.1 Purpose ............................................................................................................................... 8
1.2 Scope ................................................................................................................................... 9
1.3 Definitions ......................................................................................................................... 11
1.4 Overview ........................................................................................................................... 11
CHAPTER 2: GENERAL DESCRIPTION .................................................................. 12
2.1 Product Perspective ......................................................................................................... 12
2.2 User Characteristics......................................................................................................... 13
2.3 Principle Actors................................................................................................................ 13
2.4 General Constraints ......................................................................................................... 13
2.5 Assumptions and Dependencies...................................................................................... 13
CHAPTER 3: FUNCTIONAL & NON-FUNCTIONAL REQUIREMENTS ........... 14
3.1 Functional Requirement.................................................................................................. 14
3.2 Technical Issues................................................................................................................15
3.3 Non-Functional Requirements ...................................................................................... 15
CHAPTER 4: INTERFACE REQUIREMENTS ......................................................... 18
4.1 Interface Requirement .................................................................................................... 18
4.2 GUI .................................................................................................................................... 19
4.3 Hardware Interface ......................................................................................................... 24
4.4 Software Interface............................................................................................................ 24
CHAPTER 5: PERFORMANCE REQUIREMENTS ................................................. 25
5.1 Response Time.................................................................................................................. 25
5.2 Scalability ......................................................................................................................... 25
5.3 Availability ....................................................................................................................... 26
5.4 Error Handling ................................................................................................................ 26
5.5 Caching ............................................................................................................................. 26
5.6 Database Performance .................................................................................................... 27
5.7 Load Testing ..................................................................................................................... 27
5.8 Mobile Responsiveness .................................................................................................... 27
Chapter 6: DESIGN CONSTRAINTS........................................................................... 28
6.1 Technology Stack Constraints ........................................................................................ 28
6.2 Compatibility and Version Constraints ......................................................................... 29

LAHORE
6
6.3 Security and Authentication Constraints ...................................................................... 29
6.4 Resource Constraints ....................................................................................................... 29
6.5 Third-Party Integrations................................................................................................. 30
6.6 Mobile Responsiveness .................................................................................................... 30
Chapter 7: OPERATIONAL SCENERIO .................................................................... 31
7.1 User Actions ...................................................................................................................... 31
7.2 Behind The Scenes ........................................................................................................... 32
7.3 Staying Safe ...................................................................................................................... 33
Chapter 8: MODELING ................................................................................................. 34
8.1 Use Case Diagram ............................................................................................................ 34
8.2 Activity Diagram .............................................................................................................. 35
8.3 Class Diagram .................................................................................................................. 36
8.4 Sequence Diagram and Collaboration Diagrams ......................................................... 37
8.5 State Chart Diagram for Title Class .............................................................................. 55
8.6 Component Diagram ....................................................................................................... 56
8.7 Deployment Diagram....................................................................................................... 57
SUMMARY.................................................................................................................... 58

LAHORE
7
CHAPTER 1
INTRODUCTION
1 .1 Purpose:
▪ Computerization – All the details regarding school, whether it is small or big, will be
computerized.
▪ No Redundant Data – As this management system will be centralized, the chances of
duplicate data in the system are close to nil.
▪ Automation – The automation feature of this management system will mitigate the task of
writing the papers. E.g., there is no need to write the report card of the students on paper with a
pen. It is simply can be done online on the system, and can be forwarded to the students and
their parents.
▪ Easy Interaction – In today’s rush hour of life, it is difficult for a parent to go to the school of
his / her child every time a teacher call. With this management system, it will easier for a
parent and a teacher to be in touch every day. As a matter of fact, it will be easier for each
individual person who is associated with the system to be in touch as needed.

LAHORE
8
▪ Security: Ensure the security of student data, payment information.
1.2 Scope:
1. Student Registration:
- Creation and management of student accounts.
2. Payment:
- Safe transactions of charges and teacher’s payments.
3. Examination management:
Mange student’s results and examination or test held during the study perio

LAHORE
9
1.3 Definition:
• SMS- School Management System
• SRS- Software Requirement Specification
• GUI- Graphical User Interface
• Stakeholder- The person who will participate in system Ex. Students, Administrator,
Teacheretc.
1.4 Overview:
This system is designed to automate a range of processes such as student enrollment,
courses scheduling, fee management, attendance tracking etc. This proposed system can be
used by any naïve users and it does not require any educational level, experience or technical
expertise in the computer field but it will be of good use if the user has the good knowledge of
how to operate a computer.

LAHORE
10
CHAPTER 2
GENERAL DESCRIPTION
General Description:
The school management system (SMS) application is a platform that simplifies and automates
the day-b-day academic and administrative tasks. It enhances digitization process for schools
and benefits students, parents, teachers and administrators.
2.1 Product Perspective:
This product is aimed toward parents who doesn't want to visit the school as he might not get
time for that.

LAHORE
11
2.2 User Characteristics:
Users should be familiar with the terms like login, register etc.
2.3 Principle Actors:
Principle Actors are Student, Teacher, Parent, and Administrator.
2.4 General Constraints:
A full internet connection is required for SMS.
2.5 Assumptions and Dependencies:
Working of SMS need Internet Connection.

LAHORE
12
CHAPTER 3
FUNCTIONAL & NON-FUNCTIONAL REQUIREMENTS
3.1 Functional Requirements:
This section provides a requirement overview of the system. Various functional modules
that can be implemented by the system will be –
3.1.1 Registration:
If Teacher, Parent or Student wants any information from the website he must be registered.
3.1.2 Login:
Students and teachers login to the system by entering valid user id and password.
3.1.3 Results checking:
Results can be monitored after login to the system.
3.1.4 Payment:
In this system we are dealing with the mode of payment by credit card, debit card etc.
3.1.5 Logout:
After getting the desired information, the user has to logout.

LAHORE
13
3.2 Technical Issues:
This system will work on client-server architecture. It will require an internet server and which
will be able to run Node.js application. The system should support some commonly used
browser such as IE, Mozilla Firefox, chrome etc.
3.3 Non-Functional requirement:
3.3.1 Security:
The system uses SSL (secured socket layer) in all transactions that include any confidential
customer information. The system must automatically log out all customers after a period
of inactivity. The system should not leave any cookies on the customer’s computer
containing the user’s password. The system’s back-end servers shall only be accessible to
authenticated administrators. Sensitive data will be encrypted before being sent over
insecure connections like the internet.
3.3.2 Reliability:
The system provides storage of all databases on redundant computers with automatic
switchover. The reliability of the overall program depends on the reliability of the separate
components. The main pillar of reliability of the system is the backup of the database which
is continuously maintained and updated to reflect the most recent changes.
Thus, the overall stability of the system depends on the stability of the container and its
underlying operating system.

LAHORE
14
3.3.3 Availability:
The system should be available at all times, meaning the user can access it using a web
browser, only restricted by the down time of the server on which the system runs. In case of a
hardware failure or database corruption, a replacement page will be shown. Also, in case of a
hardware failure or database corruption, backups of the database should be retrieved from the
server and saved by the administrator. Then the service will be restarted. It means 24/7
availability.
3.4 Maintainability:
A commercial database is used for maintaining the database and the application server takes
care of the site. In case of a failure, a re-initialization of the program will be done. Also the
software design is being done with modularity in mind so that maintainability can be done
efficiently.
3.5 Portability:
The application is HTML and scripting language based. So, the end-user part is fully
portableand any system using any web browser should be able to use the features of the
system, including any hardware platform that is available or will be available in the future.
An end-user uses this system on any OS; either it is Windows or Linux. The system shall run
on PC, Laptops, and PDA etc.

LAHORE
15
CHAPTER 4
INTERFACE REQUIREMENTS
4.1 Interface Requirement:
Various interfaces for the product could be:
1). Sign in Page
2). Sign Up Form
3). Admission page
4). Attendance page
5). Results
6). Forget the password

LAHORE
16
4.2 GUI:
1: Sign In

LAHORE
17
2: Sign Up Form

LAHORE
18
3: Admission Form

LAHORE
19
4: Results Page
5: Attendance Page

LAHORE
20
5. Forget Password

LAHORE
21
4.3 Hardware Interface:
The System must run over the internet, all the hardware required to connect to the internet will
be hardware interface for the system. As for e.g. Modem, WAN – LAN, Ethernet Cross-Cable.
4.4 Software Interface:
The system is on server so it requires any scripting language like Node.js, JavaScript etc. The
system requires a Data database also for the store the any transaction of the system like Mongo
DB etc. system also require DNS (domain name space) for the naming on the internet. At the
last user need a web browser to interact with the system.

LAHORE
22
CHAPTER 5
PERFORMANCE REQUIREMENTS
5 Performance Requirements:
The performance of the school website is critical to provide a responsive and reliable user
experience. This section outlines the key performance requirements and criteria that the website
must meet.
5.1 Response Time
5.1.1 Page Load Time: The website shall have an average page load time of [specify
themaximum acceptable time, e.g., 3 seconds] for standard web pages.
5.1.2 Checkout Process: The time required to complete the checkout process, from cart
reviewto order confirmation, shall not exceed [specify the maximum acceptable time, e.g.5
seconds].
5.1.3 Search Functionality: Search queries shall return results within [specify the
maximumacceptable time, e.g., 1 second].
5.2 Scalability

LAHORE
23
5.2.1 User Scalability: The website must accommodate concurrent user sessions of up to
[specify the number of concurrent users] while maintaining acceptable performance.
5.2.2 Product Scalability: The system should handle a catalog of up to [specify thenumber of
products] without significant performance degradation.
5.3 Availability
5.3.1 Uptime: The website shall maintain an uptime of at least [specify the required
uptimepercentage, e.g., 99.9%] during standard operating hours.
5.3.2 Downtime Maintenance: Scheduled maintenance resulting in website unavailability
shall be communicated to users in advance, and it shall be performed during low-traffic
periods.
5.4 Error Handling
5.4.1 Error Pages: The website shall provide user-friendly error messages and pages for
common errors, ensuring clarity and guidance for users.
5.5 Caching
5.5.1 Content Caching: Implement content caching mechanisms to minimize server load
and reduce page load times.

LAHORE
24
5.6 Database Performance
5.6.1 Database Queries: Database queries should execute efficiently and, where applicable,
beoptimized for quick retrieval of product information and user data.
5.7 Load Testing
5.7.1 Load Testing: The website shall undergo load testing to verify its performance under
peak load conditions. It should be capable of handling [specify the number of concurrent users
or requests] without significant performance degradation.
5.8 Mobile Responsiveness
5.8.1 Mobile Responsiveness: Ensure that the website is responsive and performs well
onmobile devices, meeting the specified response time requirements.

LAHORE
25
CHAPTER 6
DESIGN CONSTRAINTS
6. Design Constraints:
The design and development of the school website, built using the MERN (MongoDB,
Express.js, React, Node.js) technology stack, are subject to various constraints that must be
considered throughout the project. These constraints influence the overall design,
architecture,and implementation of the system.
6.1 Technology Stack Constraints
6.1.1 MERN Stack: The website is built on the MERN stack and must adhere to the
principles and best practices of this stack.
6.1.2 React as Frontend Framework: The frontend of the website is developed using
React,and the design and user interface must follow React development patterns.
6.1.3 Node.js and Express.js as Backend: The backend is implemented using Node.js
and Express.js, and the architecture must adhere to these technologies.
6.1.4 MongoDB as Database: MongoDB is the chosen database system, and the design
mustconsider MongoDB's NoSQL data model.

LAHORE
26
6.2 Compatibility and Version Constraints
6.2.1 Node.js and Express.js Versions: The project must utilize specific versions of
Node.js and Express.js to ensure compatibility and stability.
6.2.2 React Version: The website shall use a specific version of React to ensure
compatibility with React components and libraries.
6.2.3 Database Drivers and Modules: MongoDB drivers and modules must be
compatible with the selected versions of MongoDB.
6.3 Security and Authentication Constraints
6.3.1 Authentication Framework: The website shall implement a secure authentication
framework using technologies such as Passport.js or JSON Web Tokens (JWT) for user
authentication.
6.3.2 Secure API Endpoints: All API endpoints must be secured to prevent
unauthorized access and data breaches.
6.3.3 Client-Side Security: Implement security best practices in React to mitigate client-side
vulnerabilities, such as Cross-Site Scripting (XSS).
6.4 Resource Constraints

LAHORE
27
6.4.1 Server Resources: The performance of the website may be constrained by the available
server resources (CPU, RAM, storage). Resource constraints should be monitored and
addressed as needed.
6.4.2 Bandwidth Constraints: Limited network bandwidth may affect data transfer
between the server and clients. Efficient data transfer mechanisms should be implemented.
6.5 Third-Party Integrations
6.5.1 Third-Party Libraries and Components: The project may rely on third-party React
libraries, Node.js packages, and MongoDB drivers. Compatibility and dependencies must be
managed.
6.5.2 Payment Gateways and APIs: Integration with third-party payment gateways and
otherexternal APIs should follow their specific integration guidelines.
6.6 Mobile Responsiveness
6.6.1 Mobile Device Compatibility: The website must be designed to be responsive and
perform well on various mobile devices and screen sizes. Mobile constraints should be
addressed during the design phase.

LAHORE
28
CHAPTER 7
OPERATIONAL SCENERIO
7. Operational Scenario:
If the user login as a student he can check his results, notes or course outlines, Parents can pay
the charges and teachers can upload the results of the students.
7.1 Student Actions:
1. Student registration: A new student comes to website and decides to create an account.
They click on "Sign Up," fill in their personal information and create a password, and
thenconfirm their registration via email.
2. Class and Course Selection: The student logs in and starts searching for courses. They can
type in what they want to admission.

LAHORE
29
3. Daily progress Monitor: When they see something they like, they click on it to see the
price, details, customer reviews, and other options like colors or sizes. If they want it, they can
put it in their shopping cart.
4. Daily Diary Checking: The user checks their cart to make sure they have everything they
need. They can change how many they want, remove things, and then move to the checkout.
5. Fee Payment: At checkout, the user enters their address and payment info.
The website tells them how much it will cost, including tax and shipping.
6. Get Notes: Once they confirm the order, they get an email confirming what they bought.
7.2 Behind the Scenes:
1. Database: The website keeps a database with info about the students, teachers, and
administration.
2. Inventory: It always knows how much students and staff member are there. When someone
leave or register, it updates the numbers.
3. Paying Safely: Payments are done securely using a special service. It makes sure the
payment goes through.

LAHORE
30
4. Emails: The website automatically sends emails to users to confirm they've signed up.
5. Helping Users: If users have questions or run into problems, they can chat, email, or call
thewebsite for help.
7.3 Staying Safe:
1. Protecting Information: All the info, especially payment details, is kept safe with
strong locks.
2. Blocking Bad People: There's a virtual wall around the website to stop bad people
from trying to break in.
3. Staying Up to Date: The website is always getting updates to stay safe from problems.
4. Privacy: The website keeps all the personal info safe and follows the rules about privacy.

LAHORE
31
CHAPTER 8
MODELING
8.1 Use Case Diagram:

LAHORE
32
8.2 Activity Diagram

LAHORE
33
8.3 Class Diagram

LAHORE
34
8.4 Sequence Diagram and Collaboration Diagram
8.4.1 Sequence Diagram for login Use-case

LAHORE
35
8.4.2 Collaboration Diagram for Login Use-case

LAHORE
36
8.5 Component Diagram

LAHORE
37
8.6 Deployment Diagram

LAHORE
38
Summary:
You can get in touch with the parent and guardian of the student with the educational system.
You can also communicate with them regarding the performance of the student. Digital
software is also a beneficial source when you want to talk with the student.
You can reduce your workload. By utilizing these digital resources, you can save time
andefforts.

LAHORE
39

School Management System (SMS)

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

School Management System (SMS)

Uploaded by

Copyright:

Available Formats

Software Requirement Specification for School Management System

Session: BS-IT 2020-2024

Project Advisor: Prof. Faraz Shoukat

DEPARTMENT OF INFORMATION TECHNOLOGY, GOVT M.A.O COLLEGE

Affiliated with Punjab University College of Information technology, University of the

Punjab, Lahore, to fulfill the partial requirements of the degree of Bachelors in

Project Examiner PUCIT, Lahore

Project Office Supervisor Project Primary Advisor

DEPARTMENT OF INFORMATION TECHNOLOGY, GOVT M.A.O COLLEGE

in no doubt that its objective has been successfully met.

Prof. Faraz Shoukat

DEPARTMENT OF INFORMATION TECHNOLOGY, GOVT M.A.O COLLEGE

DEPARTMENT OF INFORMATION TECHNOLOGY, GOVT M.A.O COLLEGE

preparing timetable and producing different reports for teachers.

DEPARTMENT OF INFORMATION TECHNOLOGY, GOVT M.A.O COLLEGE

CHAPTER 1: INTRODUCTION .................................................................................... 8

DEPARTMENT OF INFORMATION TECHNOLOGY, GOVT M.A.O COLLEGE

DEPARTMENT OF INFORMATION TECHNOLOGY, GOVT M.A.O COLLEGE

▪ No Redundant Data – As this management system will be centralized, the chances of

duplicate data in the system are close to nil.

individual person who is associated with the system to be in touch as needed.

DEPARTMENT OF INFORMATION TECHNOLOGY, GOVT M.A.O COLLEGE

- Creation and management of student accounts.

- Safe transactions of charges and teacher’s payments.

DEPARTMENT OF INFORMATION TECHNOLOGY, GOVT M.A.O COLLEGE

• SMS- School Management System

• SRS- Software Requirement Specification

• GUI- Graphical User Interface

This system is designed to automate a range of processes such as student enrollment,

how to operate a computer.

DEPARTMENT OF INFORMATION TECHNOLOGY, GOVT M.A.O COLLEGE

and benefits students, parents, teachers and administrators.

2.1 Product Perspective:

time for that.

DEPARTMENT OF INFORMATION TECHNOLOGY, GOVT M.A.O COLLEGE

2.3 Principle Actors:

Principle Actors are Student, Teacher, Parent, and Administrator.

2.4 General Constraints:

A full internet connection is required for SMS.

2.5 Assumptions and Dependencies:

Working of SMS need Internet Connection.

DEPARTMENT OF INFORMATION TECHNOLOGY, GOVT M.A.O COLLEGE

FUNCTIONAL & NON-FUNCTIONAL REQUIREMENTS

3.1 Functional Requirements:

that can be implemented by the system will be –

3.1.3 Results checking:

Results can be monitored after login to the system.

After getting the desired information, the user has to logout.

DEPARTMENT OF INFORMATION TECHNOLOGY, GOVT M.A.O COLLEGE

browser such as IE, Mozilla Firefox, chrome etc.

3.3 Non-Functional requirement:

insecure connections like the internet.

is continuously maintained and updated to reflect the most recent changes.

underlying operating system.

on PC, Laptops, and PDA etc.

DEPARTMENT OF INFORMATION TECHNOLOGY, GOVT M.A.O COLLEGE

4.1 Interface Requirement:

Various interfaces for the product could be:

1). Sign in Page

2). Sign Up Form

3). Admission page

4). Attendance page

6). Forget the password

DEPARTMENT OF INFORMATION TECHNOLOGY, GOVT M.A.O COLLEGE