INDEX

S.No. Experiment Name Date Page Remark

No.

1. Problem Statement

2. Initial Requirements Document

3. Software Requirement
Specification

1
 Experiment 1
Problem Statement
Registration is a process of taking fresh admission in a university in graduate
and post graduate courses. There are many steps involved in it starting from
registration to the final the admission.
Now a days every university is going for online registration process to make
registration process fast and easy. There are many limitations in the existing
system like
• It is time consuming
• Prone to manual error
• Difficulty in last minute changes
• Less responsive in peek time
• It does not provide information on time due which student can miss the
deadlines.
• Less secure
• Does not have all information at one place
• Lack of real time support
To overcome from all these limitation, we are proposing here this University
Registration
System (URS). The proposed university registration system will be having
following features
• The process will be completely online
• It will be smooth, easy to operate
• Fast with negligible error percentage
• It will provide all the department information
• Course information
• Faculty information
• The user can be view sessional/practical/assignment etc marks.
• It will save time, money and travel
• One place -all information-just one click away
• Provides real time support

The system will focus on three users (Student / Faculty /Administration) who
will have their own different roles. Student can do Registration, he can view

2
his Registration card, courses opted and also the detailed information on
subjects per semester of the selected Program. Faculty of the university will be
able to view the Information of registered students with their corresponding
program and the complete Program details too. The third user that is
Administration, he can view the Program details, Faculty details, Registered
student details, Department details, Fees details etc.

3
 Experiment 2
Initial Requirement Document

Title of the project University registration system

Stakeholder involved in capturing requirement Student , Faculty , Administration, Sub admin

Techniques used for requirement capturing Interviewing , Brainstorming

Name of the person along with designation Suraj Prasad Kalauni , Ritik

Date 2024

Version 1.0

Consolidate list of initial requirements:

1. This system is to be implemented which can run on university LAN.
2. There are three types of members in the university: students, faculty and administrator.
3. The system shall be able to generate login ID and password to the system operator.
4. The administrator shall be able to maintain details of all the students.
5. The administrator shall be able to maintain details of all the faculties.
6. The administrator shall be able to maintain details of all the courses offered by the
university.
7. The administrator shall be able to maintain details of all the departments.
8. The student/admin/faculties/sub admin should be able to login.
9. The student should be able to register for the courses.
10. The student/faculty should be able to view courses and seat details.
11. The student/faculty/sub admin should be able to view/update his profile.
12. The faculty/sub admin should be able to view student details of their respective
departments. Sub admin shall be able to
• Add/update/delete course details
• Add/update/delete faculty details
• Add/update/delete student details
• Add/update/delete department details
13. The student/faculty shall access URS on the university’s LAN to search the availability
of all the courses.
14. The system should be able to generate
• Student Information
• Faculty Information
• Course Information
• Seats Information

4
 Experiment 3
Software Requirement Specification
1. Introduction
1.1 Purpose
The University Registration System (URS) is designed to simplify the process of student
registration in universities, allowing seamless enrollment in undergraduate and
postgraduate courses. The system eliminates inefficiencies in the existing manual
processes, such as high error rates, lack of security, and delays during peak registration
periods. By providing a comprehensive online platform, URS ensures secure, fast, and
user-friendly registration, accessible through the university's Local Area Network (LAN).
1.2 Scope
URS is intended for three primary user groups: students, faculty, and administration. Each
user group has unique access and functionalities:
• Students: Register for courses, view selected courses, and access information about
their program, department, and faculty.
• Faculty: Manage and review details of registered students, course assignments, and
departmental information.
• Administrators: Maintain a centralized system to manage student records, faculty
data, departmental details, and generate analytical reports.
Key features include real-time course registration, validation of prerequisites,
payment integration, and access to comprehensive academic data.
1.3 Definitions, Acronyms, and Abbreviations
• URS: University Registration System
• Admin: University Administrator
• Sub Admin: Departmental Administrator
• LAN: Local Area Network
1.4 References
1. IEEE Recommended Practice for Software Requirements Specifications (IEEE Std.
830-1998).
2. Provided University Registration System document (2024, v1.0).
1.5 Overview
The subsequent sections of this document provide a detailed description of the system,
including its features, interactions with users, operational constraints, and performance
metrics. Detailed use case descriptions and diagrams are included to illustrate system
functionality.

5
2. Overall Description
The URS maintains records of student registrations, faculty information, department details,
and course data for the university. It is assumed that students are pre-enrolled in specific
programs and their admission data is available in the system. Similarly, faculty and
department details are pre-recorded in the system by the administration.
The URS enables students to register for courses within their academic programs while
ensuring real-time validation of prerequisites and seat availability. Faculty can access
information about the students registered in their courses, along with program and
departmental details. Administrators are responsible for managing the entire system,
including creating, updating, or deleting student, faculty, and department records.
The system operates on the university’s secure LAN, providing real-time support and
updates. Students, faculty, and administrators can access the system through role-based
authentication. The system generates essential reports for administrative use, including
registration statistics, departmental summaries, and fee payment records.
The administrator will need to maintain the following information:
• Student registration details
• Faculty details
• Department information
• Course information
The URS facilitates the following functions for the users:
• Students:
o Register for courses
o View registration card and program details
o Access sessional, practical, and assignment marks
• Faculty:
o View registered students for their respective courses
o Access detailed program and course information
• Administrators:
o Maintain student, faculty, and course records
o Manage department details
o Generate and review reports
The URS provides the following information to users:
• Students:
o Detailed registration and course information
o Seat availability for selected courses

6
 • Faculty:
o Registered student details
o Course and department data
• Administrators:
o Comprehensive reports on student registration and fee payments
o Details of faculty, departments, and available seats

2.1 Product Perspective

URS is a standalone application designed to operate within the university’s LAN. It serves
as an enhancement over manual registration systems, offering secure, real-time, and efficient
functionality.
2.1.1 System Interfaces
The URS interacts with payment gateways, student information systems, and academic
databases for managing courses, departments, and user records.
2.1.2 User Interfaces
• Login: Fields for username and password with role-specific redirection.
• Registration Dashboard: Drop-down menus for course selection, real-time seat
updates, and prerequisites validation.
• Profile Management: Editable fields for user details and academic history.
2.1.3 Hardware Interfaces
• Devices: Computers and laptops connected to the university's LAN.
• Network: Stable LAN connectivity to ensure uninterrupted operation.
2.1.4 Software Interfaces
The system integrates with:
• Relational databases for storing student, faculty, and course data.
• Payment gateways for processing fees securely.
2.1.5 Communication Interfaces
• Operates on the university’s LAN to ensure secure and efficient data transfer.
2.1.6 Memory Constraints
The system is optimized for efficient memory usage and can handle concurrent operations
from up to 1,000 users without performance degradation.
2.1.7 Operations
URS performs several key operations:

7
 • Course registration and fee processing.
• Real-time updates on seat availability and prerequisites.
• Report generation for academic and administrative purposes.
2.1.8 Site Adaptation Requirements
The system requires installation on university servers, accessible through authorized devices
within the LAN.
2.2 Product Functions
Key features of the URS include:
• Login and user authentication
• Course registration and updates
• Maintenance of student, faculty, and department details
• Fee payment and receipt generation
• Reporting tools for administration

2.3 User Characteristics

• Students: Require basic computer skills to access the system for registration.
• Faculty: Responsible for viewing student and course details.
• Administrators: Advanced users who manage system configurations and user data.

2.4 Constraints
• Accessible only via the university LAN.
• Data validation for every action (e.g., unique user IDs, accurate payment details).
• Integration with university-approved payment gateways.

2.5 Assumptions and Dependencies

• Students and faculty are pre-registered in the system.
• System assumes functional network infrastructure and updated course data.

3. Specific Requirements
3.1 External Interface Requirements
• User Interfaces:
o Login: Input fields for User ID and Password.

8
o Course Registration: Drop-down menus and checkboxes for course selection.

9
o Home Page: The Home Page serves as the central hub for the RUET Online
Registration system. It provides users with access to core functionalities such
as navigating to registration-related pages, signing in, and logging out.

o Enter Details: The enter details page allows new users to create an account
by entering their personal, academic, and login information. The interface is
designed to be simple, user-friendly, and visually appealing.

o Registration Successful Page: The Registration Successful Page confirms

that the user has successfully registered and provides further navigation
options. It is designed to give the user a sense of completion and guide them
to the next steps.

10
 o Logout Successful: The Logout Successful Page informs users that they
have successfully logged out of the RUET Online Registration system. It
provides a simple and clean design with options to navigate back to other
parts of the platform.

• Hardware Interfaces:
o Compatible with devices supporting LAN connections and standard display
resolutions.
• Software Interfaces:

o Database management for storing user, course, and transaction data.

• Communication Interfaces:
o Operates over a secure LAN environment.

11
3.2 Functional Requirements
1. LOGIN USE CASE DISCRIPTION
LOGIN USE CASE DISCRIPTION

Introduction: This use case describes all the steps followed in order to login into UMS

Actors: Students/Admin/Employee

Pre-condition: The Students admin and faculty must have a valid user id and password

Post Condition: If the username and password is valid, the actor is successfully logged into the
system else an error massage will be displayed.

Flow of Events:
Basic flow:
1) The system will request the actor to enter their login details for the system. The actor
fills
o User id
o Password
o Click on login button
2. If login details are valid the actor successfully logged into the system.

Alternative flow
1. Invalid Entry: If username and password filled by actor are invalid then error massage
appears and return to basic flow
2. User Exit: actor can exit at any time and use case ends

Specification: NIL

Associated use case: NIL (For admin , faculty , staff )

Student-registration use case

2.REGISTRATION CASE DISCRIPTION

REGISTRATION CASE DISCRIPTION

Introduction: This use case describes all the steps followed in order to registration.

Actors: Student

Pre-condition: NIL

Post Condition: If the use case is successful the database updated else system will remain
unchanged.
Flow of Events:
Basic flow

12
 The system will request the actor to enter following details
o Id of the student
o Name
o DOB
o Qualifying Degree
o Year of Passing of Qualifying Degree
o University Passed Qualifying Degree
o Course Applying for

2. After successful insertion the actor is asked to pay the registration fee and student
registered successfully

Alternate flow
2. Invalid Entry: If any field is wrong then error massage appears and system return
to basic flow
3. User Exit: actor can exit at any time and use case ends

Specification: NIL

Associated use case: NIL

3.LOGOUT : USE CASE DISCRIPTION

LOGOUT USE CASE DISCRIPTION

Introduction: This use case describes all the steps followed in order to logout from UMS

Actors: Students/Admin/Employee

Pre-condition: The Students admin and faculty must be logged in with valid user id and
password

Post Condition: The actor is successfully logged out of the system

Flow of Events:
Basic flow:
1) The system will request the actor to click on the log out button
2) The actor will log out and system will return to the login page.
Alternate flow
1) User Exit: actor can exit at any time and use case ends

Specification: NIL

Associated use case: LOGIN

13
4.MAINTAIN STUDENT DETAIL: USE CASE DISCRIPTION
MAINTAIN STUDENT DETAILS USE CASE DESCRIPTION

Introduction: This use case outlines the steps and interactions required to create, update, and
manage student details within the University Management System.

Actors: Admin/Employee

Pre-condition:
1) The University Management System is operational.
2) The University Admin/faculty is logged into the system with appropriate permissions.
Post Condition:
1) Student details are maintained and up-to-date in the University Management System.
2) Accurate records of student information are available for academic, administrative, and
communication purposes.
3) Any updates to academic records are reflected in relevant systems.
4) Data validation ensures the accuracy of information.

Flow of Events:
Basic flow:
1) The faculty logs into the University Management System.

2) The faculty selects the "Maintain Student Details" option.

3) The system provides options to:

• Add New Student: The faculty enters the new student's details, including
personal information (e.g., name, contact details) and academic information
(e.g., program, courses).
• Update Student Details: The faculty searches for a specific student by name,
student ID, or other identifying information. Once found, the Administrator can
modify and update the student's information.
• Delete Student Record: If required, the faculty can remove a student's record
from the system (e.g., for withdrawal or graduation).

4) After adding or updating student details, the system performs data validation to ensure
accuracy and consistency.

5) The system updates the student database with the new or modified information.
Alternate flow
1) If the student's record is not found during a search, the Administrator may choose to
recheck the search criteria or contact the Registrar's Office for assistance.
2) If there are technical issues during data entry or modification, the system informs the
Administrator and may prompt a retry or contact system support.

Specification: NIL

Associated use case: LOGIN

14
5.MAINTAIN FACULTY DETAIL: USE CASE DISCRIPTION
MAINTAIN FACULTY DETAILS USE CASE DESCRIPTION

Introduction: This use case outlines the steps and interactions required to create, update, and
manage faculty member details within the University Management System

Actors: Admin/Employee

Pre-condition:
1) The University Management System is operational.
2) The University Administrator is logged into the system with appropriate permissions.
Post Condition:
1) Faculty details are maintained and up-to-date in the University Management System.
2) Accurate records of faculty information are available for academic, administrative, and
communication purposes.
3) Any updates to academic records are reflected in relevant systems.
Flow of Events:
Basic flow:
1) The University Admin logs into the University Management System.
2)
3) The Admin selects the "Maintain Faculty Details" option.
4)
5) The system provides options to:
• Add New Faculty Member: The Administrator enters the new faculty member's
details, including personal information (e.g., name, contact details) and academic
information (e.g., department, courses, research interests).
• Update Faculty Details: The Administrator searches for a specific faculty member by
name, faculty ID, or other identifying information. Once found, the Administrator can
modify and update the faculty member's information.
• Delete Faculty Member Record: If required, the Administrator can remove a faculty
member's record from the system (e.g., for retirement or resignation).

6) After adding or updating faculty details, the system performs data validation to ensure
accuracy and consistency.
7)
8) The system updates the faculty database with the new or modified information.
Alternate flow
1) If the faculty member's record is not found during a search, the Administrator may
choose to recheck the search criteria or contact the relevant academic department
for assistance.
2) If there are technical issues during data entry or modification, the system informs
the Administrator and may prompt a retry or contact system support.
3) If any updates or modifications affect academic records, the system may trigger
notifications or updates in related systems (e.g., course assignments, departmental
resources).
Specification: NIL

Associated use case: LOGIN

15
6.MAINTAIN DEPARTMENT DETAIL: USE CASE DISCRIPTION
MAINTAIN DEPARTMENT DETAILS USE CASE DESCRIPTION

Introduction: This use case outlines the steps and interactions required to create, update, and
manage department details within the University Management System

Actors: Admin/Employee

Pre-condition:
1) The University Management System is operational.
2) The University Admin logged into the system with appropriate permissions.
Post Condition:
1) Department details are maintained and up-to-date in the University Management
System.
2) Accurate records of department information are available for academic, administrative,
and communication purposes.
3) Any updates to academic records or faculty assignments are reflected in relevant
systems.
Flow of Events:
Basic flow:
1) The University Admin logs into the University Management System using
their credentials.
2) After successful login, the Admin is presented with the main system
dashboard.
3) The Admin navigates to the "Department Management" section,
specifically choosing the "Maintain Department Details" option.
4) The system displays a list of existing departments, including their names,
department codes, descriptions, and contact information, in a tabular format.
The Admin can also choose to add a new department, update existing
department details, or delete a department record.

5) To Add New Department:

a. The Admin selects the "Add New Department" option.
b. The system presents a data entry form, allowing the Admin to input the
following department details:
. Department Name: The official name of the department.
. Department Code: A unique identifier for the department, often used for
internal reference.
. Description: A brief description of the department's purpose and focus.
. Contact Information: Details like phone numbers, email addresses, and
physical location.
c. The Admin completes the form, ensuring data accuracy and completeness,
and clicks the "Submit" button.
d. The system validates the entered data, checking for duplicate department
codes and ensuring the required fields are filled.
e. If the data is validated successfully, the system adds the new department to
the database, assigns a unique department code, and updates the department
list.

6) To Update Department Details:

a. The Admin selects the "Update Department Details" option.
b. The system provides a search feature, allowing the Admin to search for a
specific department by name or department code.

16
 c. Once the desired department is located, the Admin clicks on it to access its
details for modification.
d. The system presents a department detail form, pre-filled with the existing
information.
e. The Admin can make changes to any of the department's details, including
contact information or department head.
f. After making the necessary updates, the Admin clicks the "Save" button.
g. The system validates the changes, ensuring data accuracy and consistency.
h. If the data is validated successfully, the system updates the department's
information in the database and reflects the changes in the department list.

7) To Delete Department Record:

a. The Admin selects the "Delete Department Record" option.
b. The system provides a search feature, allowing the Admin to search for a
specific department by name or department code.
c. Once the target department is found, the Admin selects it.
d. The system prompts the Admin for confirmation to delete the department
record, emphasizing the irreversible nature of this action.
e. If the Admin confirms the deletion, the system removes the department's
record from the database and updates the department list accordingly.

8) After any of these actions (adding, updating, or deleting a department), the

system triggers data validation to ensure the accuracy and integrity of the
department data.
9) The system updates the department database with the new or modified
information or removes the department record in the case of deletion.
10) Any changes that affect academic records, faculty assignments, or other
related systems are reflected and propagated to those systems.
11) The system provides feedback to the Administrator, confirming the
successful execution of the requested action and the current status of the
department details.
Alternate flow
1) If the department's record is not found during a search, the Admin may choose
to recheck the search criteria or contact the relevant department head for
assistance.
2) If there are technical issues during data entry or modification, the system
informs the Admin and may prompt a retry or contact system support.
Specification: NIL

Associated use case: LOGIN

7.MAKE PAYMENT: USE CASE DISCRIPTION

MAKE PAYMENT USE CASE DISCRIPTION

Introduction: This use case describes all the steps followed in order to make payment in UMS

Actors: Students/Admin

Pre-condition: 1.The Students must be logged in with valid user id and password

17
 2. The Student must have provided valid payment information, which may
include valid credit card details, bank account information and other payment method accepted
by the university.
3. Bare minimum network connection.
Post Condition: The actor can successfully make payment to the system the system

Flow of Events:
Basic flow:
3) The actor will be logged in
4) The actor will navigate to the make payment option.
5) The system will present various payment options
6) The system will display the fees summary
7) The actor will payment details
8) The system will provide review and confirm
9) The system will give confirmation message
10) The system will generate receipt
Alternate flow
1) If the payment processing fails for any reason the system redirects user to an error
message. Providing details about the failure.

Specification: NIL

Associated use case: LOGIN

8.GENERATE RECEIPT: USE CASE DISCRIPTION

GENERATE RECEIPT USE CASE DISCRIPTION

Introduction: This use case describes all the steps followed in order to collect receipt from
UMS

Actors: Admin/Student

Pre-condition:
1. The Students admin and faculty must be logged in with valid user id and password.
2. The user must have initiated a payment transaction for university charges.
3. The universities payment gateway must be operational.

Post Condition:
1. A formal receipt is generated and stored in the system's database.
2. The student can access and download/print the receipt from their account.
3. The payment transaction is marked as "receipt generated" in the system.
4. Financial records are updated to reflect the payment and issuance of the receipt.

Flow of Events:
Basic flow:

18
 1. The student logs into the University Management System and initiates a payment
transaction.
2. The system verifies the student's account and the payment details to ensure they are
accurate and complete.
3. The system enters the necessary information for generating the receipt, which typically
includes the following:
• Student's name and identification details.
• Payment amount and breakdown (e.g., tuition, library fees, etc.).
• Date of payment.
• Payment method (e.g., credit card, bank transfer).
• Transaction ID or reference.
4. The system generates the receipt using the provided information and assigns a unique
receipt number.
5. The generated receipt is stored in the system's database for future reference and can be
accessed by both the student and the university.
6. The system notifies the student that the receipt is ready for download or print. The
student can access the receipt through their user account.
2) Alternate flow
1) If the payment transaction cannot be verified, the system informs who may need to
contact the student to resolve the issue.
2) If there are technical issues during receipt generation (e.g., system downtime), the
system informs the student of the delay and ensures the receipt is generated as soon as
the issue is resolved.
3) User Exit: actor can exit at any time and use case ends

Specification:
1) The University Management System should have the necessary security measures in
place to protect financial data.
2) Integration with payment gateways for payment verification is required.

Associated use case:

1) Login
2) Payment Gateway

3.3 Performance Requirements

• Average response time < 2 seconds.
• Capable of handling concurrent access by up to 1,000 users.

3.4 Design Constraints

• Developed for Windows-based systems.
• Data must comply with university privacy policies.

3.5 Software System Attributes

19
 • Security: Password protection and encrypted database communication.
• Reliability: High availability with minimal downtime.
• Usability: User-friendly interface and comprehensive user guides.

3.6 Logical Database Requirements

• Tables for users (students, faculty, admins), courses, departments, and transactions.
• Relationships between student records and course registrations.

20
 Appendix

Use Case Diagram

21
CLASS DIAGRAM

22
SEQUENCE DIAGRAM
LOGIN

23
Alternate Login

24
Registration

25
Add Student

26
Update student

27
View Student

28
Delete Student

29
Alternate Delete Student

30
Add Faculty

31
Update Faculty

32
View faculty

33
Update faculty

34
Delete Faculty

35
Alternate Delete Faculty

36
Add Course

37
View Course

38
Update Course

39
Delete Course

40
Alternate Delete Course

41
Add department

42
Update Department

43
View Department

44
Delete Department

45
Alternate Delete Department

46
Logout

47
Alternate Logout

48