CORDOVA PUBLIC COLLEGE

COLLEGE OF INFORMATION, COMPUTER AND

COMMUNICATION TECHNOLOGY

Software Requirements Specifications

for
Enrollment System

Prepared by: Team Beshie

Leader:
John Carlo Degamo

Members:
Richmone Ligan
Mark Davie Amit
Jephthah Dinoy
Table of Contents

Signature....................................................................................................................................................................................2
Change History..........................................................................................................................................................................3
Preface........................................................................................................................................................................................4
Table of Contents.......................................................................................................................................................................5
List of Figures............................................................................................................................................................................6
List of Tables..............................................................................................................................................................................7
1. Introduction...........................................................................................................................................................................8
1.1. Purpose............................................................................................................................................................................................. 8
1.2. Scope................................................................................................................................................................................................ 8
1.3. Definitions, Acronyms and Abbreviations........................................................................................................................................8
1.4. References........................................................................................................................................................................................ 8
1.5. Overview.......................................................................................................................................................................................... 8
2. Overall Description...............................................................................................................................................................9
2.1. Product perspective.......................................................................................................................................................................... 9
2.2. Product functions.............................................................................................................................................................................. 9
2.3. User characteristics........................................................................................................................................................................... 9
2.4. Constraints....................................................................................................................................................................................... 9
2.5. Assumptions and dependencies....................................................................................................................................................... 9
3. Specific Requirements ........................................................................................................................................................10
3.1. External interface requirements......................................................................................................................................................10
3.1.1. User interfaces...................................................................................................................................................................... 10
3.1.2. Hardware interfaces.............................................................................................................................................................. 10
3.1.3. Software interfaces................................................................................................................................................................ 10
3.1.4. Communications interfaces...................................................................................................................................................10
3.2. Functional requirements................................................................................................................................................................. 10
3.2.1. Use case 1............................................................................................................................................................................. 10
3.2.2. Use case 2............................................................................................................................................................................. 10
3.3. Performance Requirements............................................................................................................................................................. 10
3.4. Design constraints......................................................................................................................................................................... 10
3.5. Software system attributes..............................................................................................................................................................10
3.6. Other requirements......................................................................................................................................................................... 10
4. Appendixes...........................................................................................................................................................................11
5. Index.....................................................................................................................................................................................12
 1. Introduction

Almost everything can be done with technology. Technology for the users provides
good consolation and comfort in everyday life. The technology today plays an important
role in our society because it lessens error of work by using machines. It makes work
easier and faster and reduces cost to an organization from paper work up to automated
working system. Many manual transactions can be computerized by using software
applications or computer system to make work easier. Nowadays, computer based system
is commonly used by every company and institution and one of these is an Online
Enrollment System. Online Enrollment System serves as a vital part of a school for easy
and convenient way of enrolling a student.

Online Enrollment Systems includes features such as Online Registration, Viewing of

Schedules and Online Viewing of Grades that make data available when it is needed.
Almost all aspect of the industry prefers Online System because of its greater offer and
services. The system is now greatly recognized. Furthermore, the demand for better
Online Enrolment System also increases.

1.1. Purpose

The purpose of this document is to present a detailed description of the Online

Enrollment System in terms of enrolment, grading, payment and record keeping
processes. It will explain the purpose and features of the system, the interfaces of the
system, what the system will do, the constraints under which it must operate.

1.2. Scope

This software system will be an Online Enrollment System. This system will be
designed to maximize the deficiency and ineffective in performing job on daily basis in
terms of enrolment, grading, payment and record keeping process, which would otherwise
have to be performed manually. By maximizing the school official’s work efficiency and
meet their needs in the system in terms of usage.

More specifically, this system is designed to allow school officials such as Admission
Officer, Accounting Officer, Registrar, Dean and School Director to manage the enrolment
system process. The software will give vital information to students in terms of current and
history of registrations, payments and grades via account Online in the system. The
system also contains a relational database containing student’s registration, payments and
grades.

Page 3 of 17
1.3. Definitions, Acronyms and Abbreviations

To have a better understanding of the documents, we have provided the following

terms and their description.

Term Definition
Authentication It is a process of verification involving username and
password needed to grant certain access level in the
website. It is a process of confirming if a user is an
existing and registered user in the system.
Authorization It is the process of determining which privileges a user
can have in the website. Permission is granted to
registered users to view certain features in the system
and able to edit his or her account.
Enrollment It simply refers to the body of people who register or
enroll at the same time.
Online It simply refers to an uploaded website.
Online Enrollment System It simply refers to the system developed by the
researcher to be deployed online.
System A set of detailed method, procedures and routines
created to carry out a specific activity perform a duty or
solve a problem.
User interface The elements of the computer screen that users
interact with. This includes visual appearance or
design; content layout; presenting text; images and
colors and navigational control or buttons.
Web based Application It refers to program or system accessed via network
connection using HTTP often run inside a web
browser.

1.4. References

1. https://www.perforce.com/blog/alm/how-write-software-requirements-specification-srs-document
2. https://www.onedesk.com/writing-a-software-requirements-specification-document/
3. https://www.geeksforgeeks.org/how-to-write-a-good-srs-for-your-project/
4. https://www.smartsheet.com/software-requirements-specification-101
5. https://krazytech.com/projects/sample-software-requirements-specificationsrs-report-airline-
database
6. https://hackernoon.com/creating-srs-step-by-step-by-analyzing-requirements-2429d8e3b0ac

Page 4 of 17
 1.5. Intended Audience and Reading Suggestions

The study of Online Enrollment System is entirely significant to the contribution for all
aspects; it would facilitate the school officials, faculty, students and future researchers.

Registrar Personnel - The system will help the school registrar personnel by inputting
and viewing data records of students in efficient and convenient ways. It will also help by
giving them accurate and on time information for decision making purposes.

Admission Personnel - The system will help the school admission personnel in
updating students status, adding and removing of subjects as per requested.

Accounting Personnel - The system will help the school accounting personnel in
updating, adding and clearing payments of the student.

Dean - The system will help the school college of deans by inputting and viewing data
records of a faculty. It will also help to add specific load of works to attend to.

Faculty - The system will help the school faculty in managing the grades easily by
viewing and inputting student’s grades online.

Students - The students will benefit the Online Enrollment System to make request
fast and reliable and eliminate complaints regarding on delayed and inaccurate system used.
It will also serve as a medium to educate the students at ACLC College of Mabalacat with use
of new technology.

Page 5 of 17
 2. Overall Description

This section will give an overview of the whole system. The system will be explained in
its context to show how the system interacts with the users and introduce the basic
functionality of it. It will also describe what type of possible user that will use the system
and what functionality is available for each type.

2.1. Product perspective

This system will show the enrollment, payment, grading and record keeping process. A
system that lessens users work and easy navigation functions for all users.

2.2. Product functions

 User Account Creation
 User Login
 User Logout
 Registrar Portal
o Academic Settings
o Student Records
o Logout
 Faculty Portal
o Dashboard
o Schedule
o Classes and Grade Book
o Logout
 Admission Portal
o Admission
o Reports
o Logout
 Accounting Portal
o Fee Setup
o Payments
o Reports
o Logout
 Dean Portal
o Dashboard
o Schedule Settings
o Faculty
o Students
o Reports
o Grades
o Logout
 Student Portal
o Dashboard
o Schedule
o Curriculum
o Financial Account
o Registration
o Grades
o Logout

Page 6 of 17
 Registrar Admission Accounting
Faculty Dean Student
Function Personnel Personnel Personnel
User Account Creation * * * * * *
User Login * * * * * *
User Logout * * * * * *
Registrar Portal
o Academic Settings *
o Student Records *
o Logout *
Faculty Portal *
o Dashboard *
o Schedule *
o Classes and Grade
*
Book
o Logout *
Admission Portal
o Admission *
o Reports *
o Logout *
Accounting Portal
o Fee Setup *
o Payments *
o Reports *
o Logout *
Dean Portal
o Dashboard *
o Schedule Settings *
o Faculty *
o Students *
o Reports *
o Grades *
o Logout *
Student Portal
o Dashboard *
o Schedule *
o Curriculum *
o Financial Account *
o Registration *
o Grades *
o Logout *

2.3. User characteristics

Page 7 of 17
2.4. Constraints

o The system cannot perform an online payment;

o The system cannot perform an automated scheduling;
o The Internet connection is also a constraint for the application. Since the application fetches
data from the database over the Internet, it is crucial that there is an Internet connection for the
application to function.

2.5. Assumptions and dependencies

One assumption about the product is that it will always be used on Personal Computers,
Laptop and even mobile phones that have enough performance. If these devices do not have enough
hardware resources available for the application, there may be scenarios where the application does
not work as intended.

Page 8 of 17
 3. Specific Requirements

This section contains all of the functional and quality requirements of the system. It
gives a detailed description of the system and all its features.

3.1. External interface requirements

This section provides a detailed description of all inputs into and outputs from the
system. It also gives a description of the hardware, software and communication
interfaces and provides basic prototypes of the user interface.

3.1.1. User interfaces

This part of the document will present the features of each modules of the system, which were
identified based from the requirements of the users.

 Registrar Portal
o The administrator portal page, it contains dashboard, academic settings, student
records, reports and logout.
 Dean’s Portal
o The dean’s portal page, it contains dashboard, schedule settings, faculty, students,
reports, grades and logout.
 Admission Portal
o The admission portal page, it contains dashboard, admission, registration,reports and
logout.
 Accounting Portal
o The accounting’s portal page, it contains dashboard, fee setup, payments, reports and
logout.
 Faculty Portal
o The administrator portal page, it contains dashboard, schedule, classes and grade
book and logout.
 Student Portal
o The student’s portal page, it contains dashboard, registration, schedule, curriculum,
financial account, clearance, grades and logout.
o
3.1.2. Hardware interfaces
The Enrollment System is dependent from the physical hardware meaning it manages on
different hardware platforms that is put in place. The hardware platform this software requires to
have internet connection as this is what is needed for gathering data.

3.1.3. Software interfaces

The provided information will transmit to both the Database and Enrollment System sub portals
by sending a parameterized command. The system may receive results generated by the Database
and Enrollment System sub portals. It will start from user login then followed by what type of user is
logging in. The provided information will be transferred to admin that will automatically identify the type
of user. The different portals send information to each other that will keep the system from running.

Page 9 of 17
3.1.4. Communications interfaces
The methodology for implementing the system sub portals are Database and JavaScript. This
technology uses client-side JavaScript, cascading style sheets (CSS), and HTML for the actual user
interface with a server-side scripted back-end. The combination of the front-end and back-end allows
for a near seamless user interface experience. The overall goal is to present a more standard
application feel versus the typical page loading of traditional web applications.

3.2. Functional requirement s

This part of the study will present the features of each modules of the system, which
were identified based from the requirements of the users.

3.2.1. Use Case for Faculty

Page 10 of 17
3.2.2. Use Case for Admission

3.2.3. Use Case for Dean

Page 11 of 17
3.2.4. Use Case for Registrar

3.2.5. Use Case for Accounting

Page 12 of 17
3.2.6 Use Case for Student

3.4. Performance Requirements

The performance of the whole system is directly dependant upon the mechanisms that are
used to automatically update the Database. Current conceptual design is for the Enrollment System to
autonomously poll for the different portals and update the Database and for the system to
autonomously “refresh” its portal listing by routinely polling the Database. Both of these automatic
updates must work flawlessly to make sure that the User is supplied with most current data listing.

The software is to be designed in ASP.NET MVC 5, both the front End, i.e. the forms and the
back End, the database, so that performance level is not affected while trying to connect front end and
back end together as it would be in 2 different software.

Page 13 of 17
3.4. Design constraints
Commercial Constraints – In creating this system we’ll need more time and budget.
Requirements - As this system is still open for suggestions and still in the progress of upgrading.
Sensory Design – There may be some design colors in this system that is not pleasing in the eyes of
some users.

3.5. Software system attributes

To further elaborate the performance characteristics of the system designed for the Enrollment
System, the following metrics will be used.

3.5.1. Functionality - Is the essential purpose of any product or service? It has the following
sub-characteristics:
 Suitability - This is the essential Functionality characteristic and refers to the
appropriateness (to specification) of the functions of the software.
 Interoperability - A given software component or system does not typically function in
isolation. This sub characteristic concerns the ability of a software component to
interact with other components or systems.
 Security - This sub characteristic relates to unauthorized access to the software
functions.

3.5.2 Reliability - A set of attributes that bear on the capability of software to maintain its
level of performance under stated conditions for a stated period of time.
 Fault tolerance - The ability of software to withstand (and recover) from component, or
environmental, failure.
 Maturity - This sub-characteristic concerns frequency of failure of the software.
 Recoverability - Ability to bring back a failed system to full operation, including data and
network connections.

3.5.3 Usability - A set of attributes that bear on the effort needed for use, and on the
individual assessment of such use, by a stated or implied set of users.
 Learnability - Learning effort for different users, i.e. novice, expert, casual etc.
 Understandability - Determines the ease of which the systems functions can be
understood, relates to user mental models in Human Computer Interaction methods.
 Operability - Ability of the software to be easily operated by a given user in a given
environment.

3.5.4 Efficiency - A set of attributes that bear on the relationship between the level of
performance of the software and the amount of resources used, under stated conditions.
 Resource behavior - Characterizes resources used, i.e. memory, cpu, disk and network
usage.
 Time behavior - Characterizes response times for a given thru put, i.e. transaction rate.

3.5.5 Maintainability - A set of attributes that bear on the effort needed to make specified
modifications.
 Changeability - Characterizes the amount of effort to change a system.
 Testability - Characterizes the effort needed to verify (test) a system change.
Page 14 of 17
  Analyzability - Characterizes the ability to identify the root cause of a failure within the
software.
 Stability - Characterizes the sensitivity to change of a given system that is the negative
impact that may be caused by system changes.

3.5.6 Portability - A set of attributes that bear on the ability of software to be transferred
from one environment to another.
 Install ability - Characterizes the effort required to install the software.
 Conformance - Similar to compliance for functionality, but this characteristic relates to
portability. One example would be Open MS SQL conformance which relates to
portability of database used.
 Adaptability - Characterizes the ability of the system to change to new specifications or
operating environments.
 Replaceability - Characterizes the plug and play aspect of software components, that is
how easy is it to exchange a given software component within a specified environment.

3.5. Other requirements

3.5.1. Safety Requirements

Safety is another key factor in the design and development of the system.

 The product must be safe to use without resulting in any injury of any kind to the user.
 The software must provide safety measures so as to recover any data loss.
 Loss of data of any kind should not result in the use of the software.

3.5.2. Security Requirements

Security is an important aspect to take into considerations while designing and implementing
software.

 The software must have security features so as to protect itself and the system on which it is
going to be operated.
 Physical mechanisms as well as logical mechanisms should be implemented.
 Software must provide means for verification and authorization of users, for e.g. use of IDs
and passwords.
 Sensitive data should be accessed only by users with top priorities.

Page 15 of 17
4. Appendixes

JavaScript - JavaScript is the Programming Language for the Web

Enrollment System – the overall system that is designed to maximize the deficiency and ineffective
in performing job on daily basis in terms of enrolment, grading, payment and record keeping
process, which would otherwise have to be performed manually. By maximizing the school official’s
work efficiency and meet their needs in the system in terms of usage.

Database – a centralized collection of data. In this System, the Database holds all of the data for
each node represented in the managed cluster.

User – any individual who is registered in the Database and is granted access to the Cluster
Management System.

ASP.NET MVC - is a web application framework developed by Microsoft, which implements the
model–view–controller (MVC) pattern. It is open-source software, apart from the ASP.NET Web
Forms component which is proprietary.

CSS - CSS is the language for describing the presentation of Web pages, including colors, layout,
and fonts. It allows one to adapt the presentation to different types of devices, such as large
screens, small screens, or printers. CSS is independent of HTML and can be used with any XML-
based markup language.

HTML - Hypertext Markup Language, a standardized system for tagging text files to achieve font,
color, graphic, and hyperlink effects on World Wide Web pages.

Use Case - a specific situation in which a product or service could potentially be used.

Page 16 of 17
5. Index

Page 17 of 17