OOSE File Edited

DELHI TECHNOLOGICAL UNIVERSITY
SHAHBAD DAULATPUR, MAIN BAWANA ROAD

DELHI-110042
Object Oriented Software Engineering

(SE-202)
Submitted By: Submitted To:

RIDHAM, RONIT GOEL Ms. Ruchika Malhotra
Batch-A2 Professor & Head
Roll No- 2K22/SE/136 SE Department
2K22/SE/146
INDEX
S.No Name Of Experiment Date Signature
1 Write a Problem Statement for the University 16/01/2024
Student Registration System.
2 Prepare Initial Requirements Document 24/01/2024
[IRD] for the University Student Registration
System.
3 Design Use Case Diagram of University 01/02/2024
4 Write Use Case Description of University 01/02/2024
5 Write the Software Requirement Specification 08/02/2024
Document of University Student Registration
System.
6 Draw Class Diagram of University Student 29/02/2024
Registration System
7 Draw Sequence Diagram of University 21/03/2024
Student Registration System
8 Generate Test Case Matrix of University 28/03/2024
9 Draw Activity Diagram of University Student 04/04/2024
Registration System
10 Draw State Chart Diagram of University 18/04/2024
Experiment-1
AIM: Write a problem statement of the University Student Registration System.
The University Registration System deals with the maintenance of university data, records, instructions, and
student information within the University. URS is an automation system, which is used to store information
like students' records, and information on Courses. Students will be able to register for various courses made
available by the University. It collects related information from all the departments of an organization and
maintains files, which will be used by the system administrator/staff in various forms to generate absolute
reports.
Limitations Of Existing System:

1. Time-consuming: Manual registration processes can be time-consuming for both students and
administrative staff.
2. Error-prone: Mistakes in recording student information, course selections, or other details can lead to
issues such as incorrect grades, improper credit allocation, and other inaccuracies
3. Limited flexibility: Changing a manual registration system, such as modifying course offerings or adjusting
registration deadlines, can be challenging and time-consuming. This lack of flexibility can hinder the
university's ability to adapt to evolving academic needs.
4. Data security concerns: Paper-based systems may be more susceptible to data breaches, loss, or
unauthorized access.
5. Inefficient resource utilization: Manual registration systems may require a significant number of
administrative staff to handle the paperwork and data entry.
Proposed System:
1. Online Registration Portal:
 Develop a user-friendly and accessible online portal for students to register for courses remotely.
2. Automated Course Selection:
 Integrate an intelligent course selection module that assists students in optimizing their schedules.
3. Real-time Notifications:
 Implement a notification system to inform students and administrators about crucial updates and
deadlines.
4. User Authentication and Security:
 Employ state-of-the-art security measures, including secure user authentication and data encryption
5. Feedback Mechanism:
 Provide a feedback mechanism for students to share their experiences and suggestions, fostering
continuous improvement.
Experiment-2
AIM: Prepare Initial Requirements Document [IRD] for the University Student Registration System.
Title of the Project University Student Registration System
Stakeholders involved in capturing requirements Students, Administrative Staff, Project Leader
Techniques used for requirement capturing Interviewing and Use Case
Name of the person along with a designation Ronit Goel (2K22/SE/146), Ridham (2K22/SE/136)
Date 1st February, 2024
Version 1.0
Consolidated list of initial requirements:

1. The University Student Registration System will be a web-based application that facilitates efficient
and accurate student registration, course management, and related administrative tasks.
1. The system shall be able to generate a login ID and password for the system operator.
2. There are three types of members in the Registration System: Students, faculty, and administrative staff.
3. The administrative staff shall be able to maintain User management.
4. The administrative staff shall be able to maintain System configuration and maintenance.
5. The faculties shall be able to do the Course creation and management.
6. The faculties shall be able to maintain Grade submission and approval.
7. The students shall be able to create accounts and manage profiles.
8. The students shall be able to search and enroll for the course.
9. The system shall be able to provide the notification for important dates and events.
10. The system shall be able to provide the availability for a particular subject.
11. The system shall be able to provide the number of seats available for a particular subject.
12. The system should also be able to generate reports like:
 Details of all students of the University
o Course-Wise
o Subject-Wise
o Batch-Wise
o Department-Wise
 Details of all the courses
 Details of User authentication and authorization
SOFTWARE REQUIREMENTS SPECIFICATION
Version 1.0
April 3rd 2024
UNIVERSITY REGISTRATION SYSTEM
Ridham (2K22/SE/136)
Ronit Goel (2K22/SE/146)
B Tech. Software Engineering
4th Semester
Table of contents:
Revision History
1. Introduction
1.1. Purpose
1.2. Scope
1.3. Definition, Acronym, Abbreviation
1.4. References
1.5. Overview
2. Overall Description
2.1. Product Perspective
2.1.1. System Interfaces
2.1.2. User Interfaces
2.1.3. Hardware Interfaces
2.1.4. Software Interfaces
2.1.5. Communication Interfaces
2.1.6. Memory Constraints
2.1.7. Site Adaptation Requirements
2.2. Product Functions
2.3. Operating Environment
2.4. Design and Implementation Constraints
2.5. User Characteristics
2.6. Assumptions and Dependencies
3. Specific Requirements
3.1 External Interface Requirements
3.2. Functional Requirements
3.3. Performance Requirements
3.4. Logical Database Requirements
3.5. Design Constraints
3.6. Software System attributes
Appendix A: Glossary
Appendix B: Analysis Models
Revision History
Name Date Version
University Registration April 18th 2024 1.0

System
1. INTRODUCTION
 This document describes in detail the features and functions of URS, that provides the access and
management of data of different modules like Student, Admin, Support-staff/Employee
 The URS stores and maintains the student records for different course within the University.The
advantage of the URS is to avoid maintenance in printed copies of documents and it saves the burden
of going through a pile of documents.
 This software system is a web-based application with user friendly GUI. The data repository is
maintained in the university itself for all university data.
 The three users of this System are:
i. Admin (have full access to all modules in URS)
ii. Support staff/Employee (have limited access to manage & use only somefunctionalities of
URS)
iii. Student (have very limited access and can only apply for a course)
1.1. PURPOSE
The purpose of this document is to present a detailed description of the University
Registration System. This document will explain the purpose and features of the software
system, the interfaces provided, what the software will do and the constraints under whichit operate.
This document is intended for users of the system and also potential
developers. The document is subject to change as the project progresses. The given version
of the document is the initial one. Further changes of the project will be recorded to the
document when required.
1.2. SCOPE
 The proposed URS must perform the following tasks-
 Managing students applications, documents verification and classifying students on basis of applied
course.
 Can be used by Students to apply for the course in which they are interested withease.
 Approve or reject the Applications filled by students conferring to their admission criteria.
 Students can check status of their applications whether its Selected/Rejected/Pending from student
login.
 Administration may also issue notice on the university website regarding registration deadlines.
 Maintain separate list of students based on their application status for efficient report generation.
1.3. DEFINITION, ACRONYM, ABBREVIATION

URS: University Registration System
SRS: Software Requirements Specification
Applicant: The student who applies for a course provided by the University
System Administrator/Admin: User with all the privileges in the system.
RAM: Random Access Memory
Web application: Software system that runs on internet
HTML: Hyper Text Markup Language
LAN: Local Area Network with a range of 10-100m
WAN: Wide Area Network like Internet
1.4. REFERENCES
a) Object-Oriented Software Engineering by Yogesh Singh & Ruchika Malhotra,
PHI Learning Pvt. Ltd., 2012.
b) Use Case diagram and relationships with use cases
https://www.ibm.com/docs/en/rsas/7.5.0?topic=diagrams-directed-association relationships/
c) Google Blogspot sample document
http:/ignousupport.blogspot.com/p/Student-management-system-project.html/
1.5. OVERVIEW
 The SRS contains an analysis of the requirements necessary to help easy design process for the
system.
 The overall description provides interface requirements for the University Registration system,
product perspective, hardware interfaces, software interfaces, communication interface, memory
constraints, product functions, user characteristics and other constraints.
2. OVERALL DESCRIPTION
2.1. PRODUCT PERSPECTIVE
The software system URS is a web application and the front end of the system will be
developed using HTML, CSS, JavaScript and Bootstrap. The back end will be
developed using MySQL in PhpMyAdmin.
2.1.1. System Interfaces
None
The URS will have the following user-friendly and menu driven interfaces:
a) Registration: for the students to register on web portal, to apply for university.
b) Login: to allow the entry of only authorized users through valid login ID and password.
c) Apply for course: to allow the student to fill the university form for intended course.
d) Search Applicant: to allow the admin/staff to search for an applicant by its
name, email or contact number.
e) View application: intended for the university staff or admin to see a list of
applications which are approved/rejected/pending.
f) Approve/Reject application: to allow the admin to verify and make decision
regarding the application.
g) Upload documents: for the students to upload the documents for verification once their application is
approved by the administration.
Since the application must run over the internet, all the hardware required to connect to
internet will be the hardware interface for the system. As for e.g., Modem, WAN, LAN,
Ethernet Cross-Cable. A CPU with
Any operating system with a latest web browser can be used to access the system.
The URS shall use the HTTP protocol for communication over the internet using
LAN or WAN and for the intranet communication will be through TCP/IP protocol
suite if required.
2.1.6. Memory constraints
None
2.1.7 Site Adaptation Requirements
The client end will have to support the hardware and software interfaces specified in
sections 2.1.3 and 2.1.4 respectively.
2.2 PRODUCT FUNCTIONS
The URS will allow access only to authorized users with specific roles (system
administrator, support staff 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 is given as follows:
 A login facility for enabling only authorized access to the system.
 The system should provide users option to change password from profile.
 The system should not give access to students to change email or contact no. once
registered.
 The system should have an option to reset password if forgotten.
 The system will provide administrator access to student records and documents for
verification.
 The system administrator should be able to add/modify student details in case.
 Student/Applicant will be able to apply for admission only after primary login.
 The administrator will be able to approve/reject applications from admin panel.
 The system should provide an option to search application from student name/email.
 The administrator can also add/modify course details in the system.
2.3 OPERATING ENVIRONMENT
 The actors of the URS will be interacting through web-based software system.
Server-side components of the system will operate within a Linux based system.
The client-side of URS will be accessible from device with minimum requirements
mentioned in 3.3 with a common web browser using SSL.
 Any operating system with following versions of compatible web browser can be used to access the
system:
1) Apple Safari 7+
2) Google Chrome 44+
3) Microsoft Internet Explorer 10+
4) Mozilla Firefox 40+
2.4. DESIGN AND IMPLEMENTATION CONSTRAINTS
 Administrator will be needed to monitor the applications and ensure no student is applying for
multiple disciplines (Courses) to avoid data inconsistency.
 Student cannot edit any data in the admission form after final submission of the form.
 Once admission application is selected user can upload their documents only once. Multiple
submissions of same document are not allowed.
 This system does not support distributed database facility. It’ll have a centralized database repository
maintained in the university.
 System is limited to HTTP/HTTPS Protocols (web).
2.5. USER CHARACTERISTICS
1) The end user is expected to be Internet literate and comfortable with English.
2) URS have a user friendly and interactive interface so applicants do’nt need to have any special
working knowledge of the system.
3) System Administrator should have elementary knowledge of computers and Internet, to interact with
the system efficiently.
2.6. ASSUMPTIONS AND DEPENDENCIES
1. System will be up and running 24X7, and will have a dedicated IT team for the maintenance of the
system.
2. It is assumed that only intended students will apply for the University.
3. Itis also assumed that the course is not removed from the list after the students have
already applied for the same. It can lead to data inconsistency.
4. URS will need an administrator to verify the documents and Approve/Reject the
applications based on certain criteria pertaining to university guidelines.
5. Users of the system will use their own Email-ID if in case they forget their
credentials to be able to recover password.
3. SPECIFIC REQUIREMENTS
3.1 EXTERNAL INTERFACE REQUIREMENTS
3.1.1 User Interfaces
1. Login
2. Change Password Interface
3. Apply For Course Interface

4. Admin Dashboard Interface
5. Manage Course Interface
6. Add Course Interface .

Since the application must run over the internet, all the hardware required to connect to
internet will be the hardware interface for the system. As for e.g., Modem, WAN, LAN,
Ethernet Cross-Cable. A CPU with
Any operating system with a latest web browser can be used to access the system.
The URS shall use the HTTP protocol for communication over the internet using
LAN or WAN and for the intranet communication will be through TCP/IP protocol
suite if required.
3.2 FUNCTIONAL REQUIREMENTS
3.2.1 Login:
Introduction:
This use case describes the steps followed to Log into the URS.
Actors:
Admin, User, Support Staff
Precondition:
The user must have a valid Login ID in the form of an Email or contact number and a password to log in
successfully.
Postcondition:
If the use case is successful, the actor is successfully logged into the system. If not, the system state remains
unchanged.
Event Flow:
Basic Flow:
 The system requests the actor to enter the Email/Contact no and password combination.
 The actor enters his Login ID and password.
 The actor is successfully logged into the system.
Alternate Flow:
1. Alternative Flow 1: Invalid Login ID/Password
If the actor enters an invalid set of credentials or leaves any of the fields empty, the system displays
an error message. The actor returns to the beginning of the basic flow.
2. Alternative Flow 2: User forgets the password
If the actor remembers the Email, he/she used to sign up in the system, the actor selects the forgot
password option
3. Alternative Flow 3: User Exits
This allows the user to exit during the use case. The use case ends
Special Requirements: None
Associated Use Case: None
3.2.2 User Registration:
Introduction:
This use case describes the steps followed to sign up for an account in URS.
Actors:
Precondition:
The user must have their email and contact no for the preliminary registration.
Postcondition:
If the use case is successful, the actor has successfully registered an account into the system. If not, the
system state remains unchanged.
Event Flow:
Basic Flow:
 The system requests the actor to enter the Email and password combination along with necessary
data like first name, last name and contact number.
 The actor enters the data into the corresponding fields in the registration form.
 The actor is successfully signed up into the system.
Alternate Flow:
1. Alternative Flow 1: Name contains a number, special characters
If in the actor enters any number or special characters by mistake, the form will display an error
message. The actor returns to the beginning of the basic flow.
2. Alternative Flow 2: The contact number is not 10 digits
If the actor enters anything but numbers or the total digits in contact is not equal to ten, the system
will display an error. The actor returns to the beginning of the basic flow.
3. Alternative Flow 3: Confirm password doesn't match with password
The value entered in the password field doesn't match the confirm password field
value, the system will display an error. The actor returns to the beginning of the basic flow.
3.2.3 Apply For Course:
Introduction:
This use case describes the steps needed to follow to apply for an intended course in university.
Actors:
Admin, User
Precondition:
The user must be logged into the system before the use case begins.
Postcondition:
If the use case is successful, the user will successfully post an application for a university course.
Otherwise, the system state remains unchanged.
Event Flow:
Basic Flow:
 The system requests the actor to enter all the essential academic details, personal details and the
course for which the student intends to apply.
 The actor enters the required data into the corresponding fields in the application form.
 The application form gets submitted successfully for further processing.
Alternate Flow:
1. Alternative Flow 1: Any of the mandatory fields is left empty
If the user does not fill in any of the mandatory fields, the system displays a warning message to fill
the corresponding field to submit the form.
2. Alternative Flow 2: Data entered is not valid
If the actor enters anything but numbers in a field where only numbers are allowed or anything other
than alphabets where only literals are allowed the system will display an error on submit. The actor
returns to the beginning of the basic flow.
This allows the user to exit anytime during the use case. The use case ends.
Associated Use Case: Login
3.2.4 Maintain Course Details:
Introduction:
This use case describes all the steps followed to maintain the course details and add, update, Delete, view
course from the University Registration System.
Actors:
Administrator
Precondition:
The administrator must be logged in before this use case begins.
Postcondition:
If the use case is successful, the course will be successfully added, update, delete, view to the curriculum
or else the system state will remain unchanged.
Event Flow:
Basic Flow: This use case starts when the administrator wishes to add/update/delete/view course details.
1. The system requests that the administrator specify the function he/she would like to perform (either add
a course, update a course, delete a course, or view a course).
2. Once the administrator provides the requested information, one of the subflows is executed.
 If the administrator selects "Add a Course", the Add a Course subflow is executed.
 If the administrator selects "Update a Course ", the Update a Course subflow is executed.
 If the administrator selects "Delete a Course ", the Delete a Course subflow is executed.
 If the administrator selects "View a Course ", the View a Course subflow is executed.
Basic Flow 1: Add a Course
The system requests that the administrator enter the Course information. This includes:
 Course Code
 Subject Descriptor
 Total seats
 Language
 Duration
 Credits
Once the administrator provides the requested information, the Course is added to the system.
Basic Flow 2: Update a Course
1. The system requests that the administrator enter the Course Code.
2. The administrator enters the Course Code.
3. The system retrieves and displays the Course information
4. The administrator makes the desired changes to the Course information. This includes any of the
information specified in the Add a Course subflow.
5. Once the administrator updates the necessary information, the system updates the Course
information with the updated information.
Basic Flow 3: Delete a Course
1. The system requests that the administrator specify the Course Code.
2. The administrator enters the Course Code. The system retrieves and displays the required information
3. The system prompts the administrator to confirm the deletion of the Course record.
4. The administrator verifies the deletion.
5. The system deletes the Course.
Basic Flow 4: View a Course
1. The system requests that the administrator specify the Course Code.
2. The system retrieves and displays the Course information.
Alternate Flow:
1. Alternative Flow 1: The actor does not fill all mandatory fields.
If the actor leaves any of the fields empty, the system displays a warning message to fill in the
corresponding details. The actor returns to the beginning of the basic flow.
2. Alternative Flow 2: Course Already Exists
If in the Add a Course flow, a Course with a specified Course Code already exists, the system displays
an error message. The administrator returns to the basic flow and may reenter the Course Code.
3. Alternative Flow 3: Course Not Found
If in the Update a Course or Delete a Course or View a Course flow, the Course information with the
specified Course Code does not exist, the system displays an error message. The administrator returns
to the basic flow and may reenter the Course Code.
4. Alternative Flow 4: The duration of the program is invalid.
If the actor enters the time duration of the course as less than 6 months or more than 5 years, the system
displays an error message.
5. Alternative Flow 5: Delete Cancelled
If in the Delete a Course flow, the administrator decides not to delete the Course, the delete is cancelled
and the Basic Flow is restarted at the beginning.

3.2.5 Maintain User Details:
Introduction:
This use case describes all the steps followed to maintain the User details and add, update, Delete, view
User from the University Registration System.
Actors: Administrator
Precondition:
The administrator must be logged in before this use case begins.
Postcondition:
If the use case is successful, the User will be successfully added, update, delete, view to the User details or
else the system state will remain unchanged.
Event Flow:
Basic Flow: This use case starts when the administrator wishes to add/update/delete/view User details.
1. The system requests that the administrator specify the function he/she would like to perform (either
add a User, update a User, delete a User, or view a User).
2. Once the administrator provides the requested information, one of the subflows is executed.
 If the administrator selects "Add a User ", the Add a User subflow is executed.
 If the administrator selects "Update a User ", the Update a User subflow is executed.
 If the administrator selects "Delete a User ", the Delete a User subflow is executed.
 If the administrator selects "View a User ", the View a User subflow is executed.
Basic Flow 1: Add a User
The system requests that the administrator enter the User information. This includes:
 Membership number
 Photograph
 Roll No.
 Name
 Date of Birth
 Address
 Email
 Password
Once the administrator provides the requested information, the User is added to the system.
Basic Flow 2: Update a User
The system requests that the administrator enter the Membership number
1. The administrator enters the Membership number.
2. The system retrieves and displays the User information
3. The administrator makes the desired changes to the User information. This includes any of the
information specified in the Add a User subflow.
4. Once the administrator updates the necessary information, the system updates the User information
with the updated information.
Basic Flow 3: Delete a User
1. The system requests that the administrator specify the Membership number.
2. The administrator enters the Membership number. The system retrieves and displays the required
information
3. The system prompts the administrator to confirm the deletion of the User record.
4. The administrator verifies the deletion.
5. The system deletes the User.
Basic Flow 4: View a User
1. The system requests that the administrator specify the Membership number.
2. The system retrieves and displays the User information.
Alternate Flow:
1. Alternative Flow 1: The actor does not fill all mandatory fields.
If the actor leaves any of the fields empty, the system displays a warning message to fill in the
corresponding details. The actor returns to the beginning of the basic flow.
2. Alternative Flow 2: User Already Exists
If in the Add a User flow, a User with a specified Membership number already exists, the system
displays an error message. The administrator returns to the basic flow and may reenter the Membership
number.
3. Alternative Flow 3: User Not Found
If in the Update a User or Delete a User or View a User flow, the User information with the specified
Membership number does not exist, the system displays an error message. The administrator returns
to the basic flow and may reenter the Membership number.
4. Alternative Flow 4: The duration of the program is invalid.
If the actor enters the time duration of the User as less than 6 months or more than 5 years, the system
displays an error message.
5. Alternative Flow 5: Delete Cancelled
If in the Delete a user flow, the administrator decides not to delete the User, the delete is cancelled and
the Basic Flow is restarted at the beginning.
3.2.6 Logout:
Introduction:
This use case describes all the steps followed to logout from the University Registration System.
Actors:
Precondition:
The actor must be logged into the system before the use case begins.
Postcondition:
If the use case is successful, the actor is successfully logged out of the system.
Event Flow:
Basic Flow:
 The system requests the actor to click on the logout icon on top corner of user profile.
 The actor clicks the logout icon.
 The actor is successfully logged out of the system and return to the login page.
Alternate Flow:
3.2.7 Forgot Password:
Introduction:
This use case describes all the steps followed to Reset the password if the actor has forgotten its password.
Actors:
Admin, Support Staff, User
Precondition:
1) The actor must be registered in the system.
2) The actor must have access to the contact details used while doing registration in the system.
Postcondition:
If the use case is successful, the user password will be successfully updated.
Event Flow:
Basic Flow:
 The System requests the actor to enter a valid Email ID or contact number he/she used while signing
up on the system.
 After filling in the details, the actor must click on the Send reset link button.
 The system sends a reset password link to the registered email of the user.
 The actor clicks on the reset password link from its webmail.
 The link will take the user to the Password reset page on the University website.
 The system will request the actor to enter the new password and confirm the password.
 On submitting the password reset form, the password is successfully changed.
 The system will redirect the actor to the homepage of the university.
Alternate Flow:
1. Alternative Flow 1: If both fields are left empty
If the actor leaves both the Email and contact fields empty, the system displays an error message.
The actor returns to the beginning of the basic flow.
2. Alternative Flow 2: Invalid Email/Contact details
If the actor enters incomplete details, the system will display an error message. The actor will return
to the beginning of the basic flow.
3. Alternative Flow 3: User not found
If the entered information does not match with any of the records in the system, then the system
returns an error message regarding same. The user is asked to register in the system.
This allows the user to exit
3.2.8 Maintain Department Details:
Introduction:
This use case describes the steps to maintain the department details ensuring accurate and up-to-date
information.
Actors:
Admin, Support Staff
Precondition:
The admin must have their email and contact no.
Postcondition:
If the use case is successful, the admin has successfully updated the department details.
Event Flow:
Basic Flow:
 The administrator accesses the system and navigates to the "Department Management" section.
 The system presents a list of existing departments, displaying their current details.
 The administrator chooses a specific department to update or adds a new department.
 The administrator modifies the necessary details like department name or contact information.
 The administrator confirms the changes and saves the updated information.
 The system validates the input and updates the department details in the database.
Alternate Flow:
1. Alternative Flow 1: Name contains a number, special characters
If the admin enters any number or special characters by mistake, the form will display an error
message. The actor returns to the beginning of the basic flow.
2. Alternative Flow 2: The contact number is not 10 digits
If the actor enters anything but numbers or the total digits in contact is not equal to ten, the system
will display an error. The actor returns to the beginning of the basic flow.

3.2.9 Maintain Circular Details:
Introduction:
This use case describes the steps to maintain the circular details.
Actors:
Admin, Support Staff
Precondition:
The admin must have their email and contact no for the preliminary registration.
Postcondition:
If the use case is successful, the admin has successfully updated the circular details.
Event Flow:
Basic Flow:
 The Administrator or Faculty Member accesses the system using their credentials.
 The admin selects the "Maintain Circulars" option from the main menu.
 The admin has the option to either create a new circular or update an existing one.
 For a new circular, the admin provides details such as title, content, target audience, and expiration
date.
 For an existing circular, the admin can modify content, extend the expiration date, or mark it as
expired.
 The admin identifies the specific groups of students for whom the circular is intended.
 The admin saves the circular, making it available to the designated audience.
 The system sends notifications to the relevant students, informing them of the new or updated
circular.
Alternate Flow:
3.3. PERFORMANCE REQUIREMENTS:
1. It should run effectively on machines with minimum 1.2 GHZ, 1GB RAM and 1 GB free disk space.
2. The system response time should be minimal (3sec).
3. The web server of URS should run effectively on Linux based machine.
3.4. LOGICAL DATABASE REQUIREMENTS:
Details required in database:
Organization Details: ID, Login, Name, Email, Password.
Course Details: ID, Student ID, No of Courses, Duration.
Student Details: Name, Email, Contact No, Course Applied.
3.5. DESIGN CONSTRAINTS:
The portal layout will be produced with HTML/CSS.
The source code must follow the coding conventions of PHP.
System administration must have access to comprehensive documentation.
3.6. SOFTWARE SYSTEM ATTRIBUTES:
3.6.1. Usability:
The web application will be user friendly and-easy to use and the functions of the
System.
Will be easily understandable by end users.
3.6.2. Reliability:
The web application will be available to the students throughout the registration
Period and should have a high degree of fault tolerance. The system will be scalable
In case the load matrix increases on the servers.
3.6.3. Security:
The system will be password protected hence only authorized users will be able to
Access it. Users of the system will have to enter valid combination of User ID and
Password to access the system.
3.6.4. Portability:
The software system is a web based system and hence is scalable according to the need.
Appendix A: Glossary
SRS - Software Requirements Specification
URS - University Register System
LAN - Local Area Network
WAN - Wide Area Network
IEEE - Institute of Electrical and Electronics Engineers
CPU - Central Processing Unit
RAM - Random Access Memory
Appendix B: ANALYSIS MODELS
1. USE CASE DIAGRAM
2. CLASS DIAGRAM
3 SEQUENCE DIAGRAM
3.1 LOGIN
3.1.1 BASIC FLOW
3.1.2 ALTERNATIVE FLOW

3.2 USER REGISTRATION
3.2.1 BASIC FLOW
3.2.2 ALTERNATIVE FLOW

3.3 APPLY FOR A COURSE/ COURSE REGISTRATION
3.3.1 BASIC FLOW
3.3.2 ALTERNATVE FLOW

3.4 FORGOT PASSWORD
3.4.1 BASIC FLOW
3.5 LOG OUT

3.5.1 BASIC FLOW
4. TEST CASE MATRIX
4.1 LOGIN TEST CASE
4.2 MAINTAIN COURSE DETAILS TEST CASE
4.2 MAINTAIN COURSE DETAILS TEST CASE (CONT..)
4.3 MAINTAIN USER DETAILS TEST CASE
4.3 MAINTAIN USER DETAILS TEST CASE (CONT..)
4.4 MAINTAIN REGISTERATION DETAILS TEST CASE
4.5 MAINTAIN DEPARTMENT DETAILS TEST CASE
4.6 LOGOUT TEST CASE
4.7 MAINTAIN APPLY FOR A COURSES TEST CASE

5. ACTIVITY DIAGRAM
5.1 LOGIN:
5.2 RESET PASSWORD:
5.3 COURSE REGISTRATION:
5.4 COURSE APPROVAL:
6. STATE CHART DIAGRAM
6.1 USER REGISTRATION

6.2 MAINTAIN USER DETAILS
6.3 MAINTAIN COURSE DETAILS

OOSE File Edited

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

OOSE File Edited

Uploaded by

Copyright:

Available Formats

DELHI TECHNOLOGICAL UNIVERSITY

SHAHBAD DAULATPUR, MAIN BAWANA ROAD

Object Oriented Software Engineering

Submitted By: Submitted To:

Limitations Of Existing System:

Title of the Project University Student Registration System

Stakeholders involved in capturing requirements Students, Administrative Staff, Project Leader

Techniques used for requirement capturing Interviewing and Use Case

Date 1st February, 2024

Consolidated list of initial requirements:

April 3rd 2024

UNIVERSITY REGISTRATION SYSTEM

B Tech. Software Engineering

Name Date Version

University Registration April 18th 2024 1.0

1.3. DEFINITION, ACRONYM, ABBREVIATION

3. Apply For Course Interface

5. Manage Course Interface

6. Add Course Interface .

3.1.2. Hardware Interfaces

Special Requirements: None

Special Requirements: None

3.1.2 ALTERNATIVE FLOW

3.2.2 ALTERNATIVE FLOW

3.3.2 ALTERNATVE FLOW

3.5 LOG OUT

4.7 MAINTAIN APPLY FOR A COURSES TEST CASE

6.1 USER REGISTRATION

You might also like