SOFTWARE

REQUIREMENTS
SPECIFICATION
FOR
STUDENT
INFORMATION
MANAGEMENT
SYSTEM

1
Contents
SOFTWARE REQUIREMENTS SPECIFICATION FOR.................1
STUDENT INFORMATION MANAGEMENT................................................................................1
SYSTEM.............................................................................................................................................1
1. INTRODUCTION............................................................................................................................3
1.1 PURPOSE.....................................................................................................................................3
1.2 SCOPE..........................................................................................................................................3
1.3 DEFINITIONS, ACRONYMS, AND ABBREVIATIONS............................................................4
1.4 REFERENCES..............................................................................................................................4
2. Overall Description......................................................................................................................5
2.1. Product Perspective......................................................................................................................5
2.1.1. System Interfaces.......................................................................................................................5
2.1.2. User Interfaces...........................................................................................................................5
2.1.3. Hardware Interfaces...................................................................................................................6
2.1.4. Software Interfaces....................................................................................................................6
2.1.5. Communication Interfaces.........................................................................................................7
2.1.6. Memory Constraints..................................................................................................................7
2.1.7. Operations..................................................................................................................................7
2.1.8. Site Adaptation Requirements....................................................................................................7
2.2. Product Functions.........................................................................................................................7
2.3. User Characteristics......................................................................................................................8
2.4. Constraints....................................................................................................................................8
2.5 Assumptions and Dependencies...............................................................................................9
2.6 Apportioning of Requirements.................................................................................................9
3.1.1 Hardware Interfaces.............................................................................................................9
3.1.2 Software Interfaces..............................................................................................................9
3.1.3 Communication Interfaces.................................................................................................10
3.2Functional Requirements..............................................................................................................10
3.2.1 LOGIN......................................................................................................................................10

2
1. INTRODUCTION

The Student Management System Can Handle All The Details About A
Student. The Details Include College Details , Course Details , Student
Personal Details , Academic Details Etc., The Student Management System Is
An Automated Version Of Manual Student Management System.

1.1 PURPOSE
This SRS Document Contains The Complete Software Requirements For The
Online Studentinformation Management System (OS I MS) And Describes
The Design Decisions, Architecturaldesign And The Detailed Design Needed
To Implement The System. It Provides The Visibility In Thedesign And
Provides Information Needed For Software Support.New Reliable And Fast
Schoolmanagement Software With The Great Customers Support. It'll Help
You With Your Daily Schoolmanagement Routines And Deliver You From
Your Paperwork.

1.2 SCOPE
Online Student Information Management System Is Developing For General
Purpose And Used To Replace Old Paper Work System And PUMS. OSIMS Is
To Build Upon Theexisting Information System PUMS In Order To Efficiently
Provide Student Information To Teachersand School Administration .This
Increase In Efficiency Of Result Making, Provide Result To Parents,Give
Feedback To Student, Finally, Publication And Email Student Result. It
Provides A Mechanism Toedit The Student Information Form Which Makes
The System Flexible.

1.3 DEFINITIONS, ACRONYMS, AND ABBREVIATIONS

IEEE - The Institute of Electrical and Electronics Engineers, Inc.

OSIMS - Online Student Information Management System

PUMS - Project Units Management System

J2EE - Java 2 Platform Enterprise Edition

3
JSP - Java Server Page

SRS - Software Requirements Specification

OS - Operating System

1.4 REFERENCES

(A)Https://Www.Scribd.Com/Doc/48111565/Software-Requirements-
Specification-For-Online-Student-Management-System.

(B)‘Software Engineering’ By K.K. Aggarwal & Yogesh Singh, New Age

Publishing House, 2nd Ed.

(C)IEEE Recommended Practice For Software Requirements Specifications –

IEEE Std 830-1998.

(D)IEEE Standard For Software Test Documentation – IEEE Std. 829-1998.

2. Overall Description

The Student Management System Allows Authorized Members To Access The

Recors Of Academicallyb Registered Students. It Can Be Used In Various
Educational Institutes Across The Globe 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 Visual Basic 6.0 and backend will be
developed using MS SQL Server 2000.

4
2.1.1. System Interfaces

None

2.1.2. User Interfaces

The ONSMS will have following user-friendly and menu driven interfaces

a) Login: to allow the entry of only authorized users through valid login Id
and password.

b) School Details: to maintain school details.

c) Programme Details: to maintain programme details.

d) Scheme Details : to maintain scheme details of a programme.

Paper Details: to maintain paper details of a scheme for a particular

programme

g) Faculty Details : to maintain the faculty details.

2.1.3. Hardware Interfaces

a) Screen resolution of at least 640 x 480 or above.

b) Support for printer (dot matrix, deskjet, laserjet)

c) Computer systems will be in the networked environment as it is a multi-

user system.

5
2.1.4. Software Interfaces

a) MS-Windows Operating System

b) Microsoft Visual Basic 6.0 for designing front-end

c) MS SQL Server 2000 for backend

d) PLATEFORM : JAVA LANGUAGE

e) INTEGRATED DEVELOPMENT ENVIRONMENT(IDE):ECLIPSE

2.1.5. Communication Interfaces

None

2.1.6. Memory Constraints

At least 512 MB RAM and 500 MB space of hard disk will be required to run the
software.

2.1.7. Operations

None

2.1.8. Site Adaptation Requirements

6
The terminal at client site will have to support the hardware and software
interfaces specified in the section 2.1.3 and 2.1.4 respectively.

2.2. Product Functions

The ONSMS will allow access only to authorized users with specific roles
(System administrator, Faculty and Student). Depending upon the user’s role,
he/she will be able to access only specific modules of the system.

A summary of major functions that the URS will perform

·A login facility for enabling only authorized access to the system.

·System administrator will be able to add, modify or delete programme,

school, scheme, paper and login information.

·Students will be able to add/modify his/her details and register for papers to
be studied in the current semester.

·System administrator/Faculty will be able to generate reports.

2.3. User Characteristics

· Qualification: At least matriculation and comfortable with English.

· Experience: Should be well versed/informed about the registration

process of the university.

· Technical Experience: Elementary knowledge of computers

2.4. Constraints

7
· There will only be one administrator.

· The delete operation is available only to the administrator. To reduce

the complexity of the system, there is no check on 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.

· It is assumed that a student registering for the subsequent semester has

been promoted to that semester by the university as per rules and has paid
desired university fee.

· Registration process will be open only for specific duration.

2.6 Apportioning of Requirements

Not Required

3.1.1 Hardware Interfaces

As stated in Section 2.1.3

8
3.1.2 Software Interfaces

As stated in Section 2.1.4

3.1.3 Communication Interfaces

None

3.2Functional Requirements

3.2.1 LOGIN

A. Use Case Description

1 Introduction

This use case documents the steps that must be followed in order to log into
the

University Registration System.

2 Actors

9
Administrator

Student

Faculty

3 Pre-Condition

The user must have valid login Id and password.

4 Post Condition

If the use case is successful, the actor is logged into the system. if not, the
system

state remains unchanged.

5 Basic Flow

Starts when actor wishes to login onto the URS

i. The system requests that the actor specify the function he/she would like
to perform (either Login, Change Password)

ii. Once the actor provides the requested information, one of the sub flows
is executed.

· If the actor selects “Login”, the Login sub flow is executed.

10
· If the actor selects “Change Password”, the Change Password sub flow
is executed.

11