Experiment-I: Software Requirements Specification

(School management system)

1. Problem Statement: To collect software requirements and create software requirement

specification.

SOFTWARE REQUIREMENTS: Ms Word.

1. Introduction

1.1 Purpose Basic Description of Problem

The school management system is an important part in education institution. There are many
classes of people working together to maintain school management system.

1.2 Scope

The purpose of this specification is to document requirements for a system to manage the
Student and Staff information. The specification identifies what such a system is required to do.
The specification is written in a format conforming to the IEEE Standard 830- 1984. Subject to
approval, the specification will complete the Requirements phase and will be followed by
detailed design, implementation, and testing.

1.3 Definitions, Acronyms, and Abbreviations

SMS School Management System

GUI Graphical User Interface
SID Student Identification Number
STID Staff Identification Number

1.4 References

School Management System Fedena, is a complete School management software

and system with features like: timetable, attendance, parent-teacher-student communication and a
lot more.

1.5 Overview

This specification includes a brief product perspective and a summary of the functions the
software will provide. User characteristics are discussed and any general constraints or
assumptions and dependencies are listed.

Requirement statements are categorized as functional requirements, performance requirements,

non-functional requirements, or design constraints. Functional requirements are further
categorized in terms of student enrolment, staff enrolment, data updation of students and staff.
Non-functional requirements are further categorized in terms of security, maintainability, and
scalability.

2. General Description

2.1 Product Perspective

The SMS is designed to help the school administrator to handle student and staff information.
The current design goal is to build an internal system to achieve the functionality outlined in this
specification.

2.2 Product Functions

The SMS will allow the user to manage information about Student and staff. Student enrolments
provide students sign up procedure. Same is for the staff. Data updation here means the timetable
or the student report or any achievements. The SMS will also support the automatic backup and
protection of data.

2.3 User Characteristics

There are three different types of users for the SMS system:

Type 1. The Principal, who is most familiar with the problem domain. He holds some
knowledge of basic computer operations and applications such as Microsoft
Word, Excel, and PowerPoint. He has some education in computer science, which
allows him to adapt to new systems quickly. The Principal is the only person who
will have the authority.

Type 2. Administrative Clerks, who handle data entry for the SMS system. They have data
entry training from college. Administrative Clerks are familiar with basic
computer operations.

Type 3. Staffs, who are in charge of taking classes. Of the three user types, the Staffs have
least computer knowledge. There is a requirement for staff to perform some data
entry. Staff will need to make regular scheduling changes, and so the interface
should be easy to use.

Type 4. Students, who use this whole system but cannot modify any information.

Based on the above categorizations, in order to meet user's needs the following precautions
should be taken:

 the interface should be designed with the computer novice in mind

 data entry masks should recognize and correct improperly entered data
 for deleting or revising a record the system should ask the users for confirmation
  error messages should be provided.
 the interface should be easy to understand.

2.4 General Constraints

The following constraints will limit the developer's options for designing the system:

 the budget for this project is twenty lakhs.

 implementation is required within 10 weeks.

3. Specific Requirements

3.1 Functional Requirements

R l. Student enrolment Subsystem

The student management subsystem requirements are concerned with the management of student
information.

R 1.1 The SMS shall allow the user type 1 and 2 to update student personal information
(name, address, phone number, email, parent or guardian details, date of birth,
…).

R 1.2 The SMS shall store all student history information from starting to end of the
school studies.

R 1.3 The SMS shall allow the user type 1 and 2 to add new Students into the system.

R 1.3.1 The SMS shall assign a unique ID and passwords to new students.

R l .4 The SMS shall allow all user types to retrieve student personal information by
student ID.

R l.4.1 The SMS shall allow all user types to retrieve student personal
information.

R l.4.2 The SMS shall allow user type 1 and 3 (only if staff assigned to the
particular student) to retrieve student history information.

R1.5 Student account deletion

R1.5.1 The SMS shall allow user types 1 and 2 to delete student account by
entering the student id and password.

R1.5.2 Ask for confirmation on deletion.

R2. Staff Management Subsystem

The staff management subsystem requirements are concerned with the management of staff
information. They specify how staff information can be managed and manipulated.

R 2.1 The SMS shall allow the user type 1 or 2 to add new staffs to the system.

R2.1.1 Staff details are added by taking the following information like name, address,
phone number, email, date of birth, …).

R2.1.2 On submission, a unique staff id and password is generated to the new staff.

R 2.2 The SMS shall allow the user type 1 or 2 to remove staffs from the system.

R2.2.1 Staff id and password is required.

R2.2.2 Confirm again before submission

R 2.3 The SMS shall allow the user type 1 or 2 to update staff information.

R 2.3.1 To update staff personal information (name, address, phone number, email, date
of birth, …).

R 2.3.2 The SMS shall allow the user type 1 or 2 to update staff information (area of
expertise, experience).

R 2.4 The SMS shall update staff available information when a staff is assigned to a class
student.

R3 Data Updation for students

R3.1 Student information management

R3.1.1 Update Student mark sheet.

R3.1.2 Update Student attendance sheet

R3.1.3 Update Student achievements.

R3.1.4 Display fee dues if any.

R3.2 Class Information updation

R3.2.1 Update the time table of a class.

 R3.2.2 Update the examination schedule.

R3.2.3 Display notification if any.

3.2 Performance Requirements

R4 The SMS shall respond to user's retrieving information quickly. The waiting time for any
retrieve operation must be under 2 seconds.

3.2 Non-functional Requirements

R5. Security.

The security requirements are concerned with security and privacy issues. All student
information is required by law to be kept private

R 5.1 The SMS shall support different user access privileges.

R 5.2 The SMS shall protect student information.

R6. Maintainability

The maintainability requirements are concerned with the maintenance issues of the system.
R 6.1 The maintenance time of SMS shall be done regularly.
R 6.2 System down time for maintenance should be less than 6 hours per quarter of a year.

R7. Scalability

The scalability requirements are concerned with the scalable issues of the system.
R 7.1 The SMS shall be able to scale up to support more workstations. System performance shall
not degrade if up to twenty percent (20%) more workstations are added.

3.4 Design Constraints

R 8. The SMS shall have a graphical user interface.

R 9. The SMS must run in the 3rd year computing labs.

R 10. The SMS must be written in Java.