University of Santo Tomas

Institute of Information and Computing

Sciences

Student Activities Records System

Software Requirements Specifications

Client: Office for Student Affairs, University of Santo Tomas

Client Address: Tan Yan Kee Student Center., University of Santo Tomas, España Blvd.,
Sampaloc, Manila

Adviser: Assistant Professor. Divinagracia Mariano

Members:
1. Allan Gabriel M. Manahan 3. Gavin J. Phelan (Quality Assurance)
(Business Analyst) 4. Rancell Clarke M. Enriquez
2. Kylie Jane O. Chua (System Analyst)
(Project Developer) 5. Kevin Glenn L. Yee
(Project Manager)

2
Table of Contents
Introduction 3
Project Purpose 3
Project Deliverables 3
Project Organization 4
Process Model 4
Organizational Structure 6
External Structure 6
Internal Structure 6
Managerial Process 9
Management Objectives and Priorities 9
Assumptions, Dependencies and Constraints 9
Assumptions 10
Dependencies 10
Constraints 10
Risk Management 10
Monitoring and Controlling Mechanisms 12
Work Packages, Schedule and Budget 12
Work Packages 12
Dependencies 14
Resource Requirements 14
Resource Allocation 15
Schedule 16

1
 Software Requirements Specifications

1. Introduction
This project entitled Student Activities Records System is an application for the Office for Student
Affairs which aims to provide the office a system that will allow them to provide certification to
requesting students and/or alumni for their participations to various seminar and workshops
during their stay in the University of Santo Tomas. The system will be able to track the said events
hosted and attended by the students of University. This will cover the encoding medium of the
end-users, the verification process, and the output certificate that will be issued by the client
office.

1.1. Project Purpose

The system developed will be functional for the Office for Student Affairs to have a database
of activities students had participated. This will be useful to produce a transcript of
participated activities that can be endorsed by the Office in which can be attached to a
resume.

Figure R-1: Fishbone diagram

The fishbone diagram shows the problems that this system can encounter in terms of
Manpower, Methods, Machine, and Materials. These are the factors that needed to be
assessed in creating a system.

1.2. Project Scope

The scope of the project starts from providing a standalone application to be used by the
end-users in encoding data for the Student Organizations, a validation section to be used by

2
 the Student Organizations Coordinating Council, and reference section for the Office for
Student Affairs. This project also aims to provide a data filtering features in which will be
used by the Office for Student Affairs in creating a Certificate of Activities.

2. Overall description
2.1. Project perspective
This project has three primary model namely Office for Student Affairs, Student Organizations
Coordinating Council, and the Student Organizations. The primary administrator will be the
Office for Student Affairs, which can create and remove accounts, and manage database.
Second major user will be the Student Organizations Coordinating Council which will have the
authority to validate the datum and minor data management. The primary end-user will be
the Student Organizations in which will be given individual accounts to be used in inputting
the data needed.

Figure R-3: Use case diagram

2.2. User accounts and characteristics

The following will be the users of the system and interactions provided according to the access
level:

● Student Organizations (User)

3
 The Student Organizations will be the main user of the system. They will be required by the Office
for the Student Affairs to input the necessary details of the event and as well as the attendees
and organizers of their events they spearheaded. The respective account of each organizations
can only be accessed through UST Intranet.

● Student Organizations Coordinating Council (Administrator)

The Student Organizations Coordinating Council (SOCC) is a secondary user in the system. The role
of SOCC is to validate the data input of all the student organizations. The data must undergo
validation process, in care of the SOCC, before moving forward to the data storing by the Office
for Student Affairs.

● Office for Student Affairs (Superuser)

The Office for Student Affairs (OSA) will be the administrator of the system. The office will be the
one to allow the storing of the data in the database of student activities and participants right
after the data validation by the SOCC. As an administrator, the OSA will be the one to have the
administrative system functions such as adding and removing accounts, data management
functions, and account editing.

2.3. Project functions

The primary function of the project is to create a standalone application that will be used by
the student organizations to input the participants in the events they have accomplished. It
will then be used by the Student Organizations Coordinating Council to validate data placed
by the student organizations and to be endorsed to the Office for Student Affairs. The Office
for Student Affairs then will authorize the approval of the data to be saved in the database of
activities.

4
 Figure R-5: Activity diagram

2.4. Operating environment

Requirements Description

Login Administrators and users will be able to login

in their designated account created by OSA to
access their respective dashboards and do
their duties.

When the users, aside from the Superuser,

forgets their login credentials, they may
proceed to the designated administrator by
OSA to reset their passwords and regain
access.

5
 Add Event (SO) The users (SO) will be able to submit requests
● Fill / Edit Event Details to add their concluded events in the database,
● Fill / Edit Students Participants including details vital for certification and the
list of student participants.

The request will be handled and assessed in

the user-end of SOCC.

Once submitted, details cannot be edited by

the SO user, unless required by the SOCC.

Endorse Event (SOCC) The administrator (SOCC) will be able to

● Endorse endorse events that have successfully filled
● Deny and passed the requirements (hard copy), and
● Suggest Edit submitted details that corroborate with both
the hard copy and inputted details in the
system (e.g. number of participants).

In the case of failing the requirements, SOCC

can deny the endorsement of the event and
return it to the SO user, appended with the
requirements they are lacking for compliance.

Approve Event (OSA) The Superuser (OSA) will be able to approve

● Approve endorsed events by the SOCC. Approving an
● Deny endorsed event will insert the said activity into
● Suggest Edit the database and will appear as searchable for
certifications.

In the case of OSA denying an event, the

endorsed event will be sent back to SOCC
administrator for review, appended with the
reason of its denial.

View All users may be able to view event details, but

with limitations depending on the account’s
permissions.

- SO users may be able to view the event details

of their own organizations only.

- OSA Superuser and SOCC administrators may

be able to view all event details of all
organizations.

6
 Edit
● Event Details
● Participants Details
● Organization Details
Editing of submitted information are limited
depending on the user permissions of an
account.
SOCC users can suggest edits to event and
participant details to SO users, appended after
denying their event request.

SO users can edit event and participant details

that are yet to be submitted, but locked out of
the feature once submitted to SOCC to
endorsement, unlocking again if ever denied
and edits were suggested by SOCC.

Delete In the unlikely case of needing to delete an

event from the database, the Superuser can
utilize this function.

Accounts Management Only the Superuser has the permission to

● Add Account create, delete, edit accounts to accommodate
● Delete Account the needs of the management.
● Edit Account Settings
● Edit Account Permissions
● Edit Account Details

Search Users, Administrator and Superuser will be

able to use the search function to
accommodate their management needs.

- SO can only search the events of their own

organization.

- SOCC is limited to requesting the list of event

details of specific organizations as a parameter
and cannot access the individual students’ list
of events participated.

- Superuser can do everything stated above.

Print Only the Superuser can print an individual’s

certification / list of participated events as to
protect the privacy of the subject and the
authentication of the document.
2.5.
2.5.
Table R-1: Functional requirements

7
 Category Nonfunctional Requirements

Compatibility System should be compatible to operate with most machines

or devices.

Efficiency System should be able to show information and perform tasks

with the least amount of process time possible.

Maintainability The users should be able to maintain the database with ease.
Functions for manipulating the data (depending on the
account’s permission) should be available to the user.

Reliability The system should be able to meet the needs of the users and
can handle different kinds of scenarios and minimize
downtimes.

Security The system should be able to eliminate or minimize the risks

of having the data inside stolen, breached, or manipulated by
third parties other than authorized personnel (Superuser) as
to protect the database’s integrity.

Usability The system should be easy to learn and understand as to ease

the learning curve of the users and function as soon as
possible.

Table R-2: Non-functional requirements

2.5. Design and implementation constraints

This documents the limitations, dependencies and possible consequences on the system’s
design, development and implementation (palagay dito kailangan mainstall mysql sa laptop
ng client (OSA )

2.5.1. Risk assessment

Potential Risk Impa Likeliho Action / Risk Mitigation

ct od Level
Level

8
1. Failure to Medi Medium Schedule weekly conference
communicate um and updates to the client as
and consult to keep the flow of
with the client information between the two
during the parties’ fluid and updated.
developmental
stage of the
project.

2. System High Low Ensure that the user machine

requirements have completed the
are not met by installation of various
the machine; requirements (e.g. web
thus, rendering browser).
unusable.

3. The High Medium By following the Crystal Clear

system may methodology, the system will
not be ready be built both iteratively and
before the incrementally; thus, having
scheduled time the system modules ready bit
of delivery. by bit, allowing delivery of
the project even in an
unfinished state to be
completely usable.

4. The High Low Through constant

system fails to communication and updates,
meet the this risk can be negated in its
demands and early stages.
expectations of
the client.

5. The Low High Through the Agile

system source development cycle, the code
code may not will be reviewed repeatedly;
be streamlined thus, be able to enhance it
for efficiency. from time to time for better
efficiency.

9
 6. The system High Mediu The client needs to install
will not m MySQL on their device.
function as
needed
because
MySQL is not
present.

Table R-3 shows and describes the plausible risks throughout the development of the proposed project.

2.5.2. Assumptions and dependencies

The team assumes that the following situations are to be true:

● The client will agree to deploy and implement the system in their organization
in phases as to minimize possible long-term problems.
● The client will be in constant communication with the team as to have a fluid
exchange of information between the two parties.
● The system development will proceed smoothly with complications addressed
early in the phases as to be able to release a functional system as proposed.
● The system will run in the specified operating system and machine.
● The system will be managed and operated by trained personnel with basic
knowledge on the system’s requirements and capabilities.
● The system and its database will run in the University’s Intranet.

The following are the dependencies that the project team and the proposed system
will adhere to:

● The client will have to agree and acknowledge any changes during the
developmental stage of the system.
● The client will have to rely for the early parts of the implementation to the
project team until enough personnel are trained for the maintenance of the
system.
● The deployment of the proposed system as a university-wide standalone
application is dependent to the technical administrators of the University.
● The system, as a standalone application, is dependent to a web browser to be
installed to the user machine in order to be utilized.

2.6. User documentation

A user manual will be provided together with the software as a technical guide for the client
/ user on the system’s functionalities and uses. The manual would be written with non-
technical users in mind, minimizing the use of technical terminologies as to allow the reader

10
 to easily understand the instructions written. The scope and purpose of the system will be
covered in the user manual, together with usage instructions, common errors
troubleshooting, and glossary of terms that the users may refer to.

3. External Interface Requirements

3.1. User interfaces (kailangan dito screenshots ng prototype kunin mo na lang sa SDD ko)
The base of the system will be a standalone application, in which will be the basis of the User
Interface. It will be composed of the Login Page in which will be required to access the account
of the Student Organization, the SOCC, as well as the Administrator or the Office for Student
Affairs. The primary interface for each user will be different according to the user level and to
its function. The Student Organizations will have the primary UI of adding events and
participants. The Student Organizations Coordinating Council will have the primary UI of a
validation page in which will have the access to the data inputted by the student
organizations. And the Office for Student Affairs will have the primary UI for creating,
removing, and editing users’ profile, data management, as well as the database access in
which can be filtered and can create a templated output.

11
12
13
14
15
16
17
18
3.2. Hardware interfaces
The hardware interface of the system will only be the same for the desktop browser and for
the mobile browser. The only restriction of the standalone application is it can only be
accessed through the intranet within the University of Santo Tomas, regardless if it is a Wi-Fi
or a LAN access.

19
 3.3. Software interfaces (read docu kung ano need idownload ng user blah blah)
The software that we will be using for the system will be HTML, CSS and Javascript for the
Front-End interface, and MySQL, PHP Laravel, and XAMMP for the data management,
security, and other features.
Front End:
HTML
CSS
Javascript
Back End:
MySQL
PHP, Laravel Framework
XAMMP

3.4. Communication interfaces

The system is designed as a standalone application that can be used through internet browser.
Hence, the connection needed to access the standalone application is not the internet, but
rather the intranet inside the University. The intranet can be accessed through the WiFi from
the Laboratories or offices of different buildings, the Veritas WiFi, or through the LAN cables
which can be accessed from the computer laboratories and different offices. Internet outside
the University will not be able to connect to the server housing the system.

4. Functional Requirements
4.1. Stimulus/Response Sequences
4.1.1 Input of Event and participant data by Student Organizations
Stimulus from the User Response from the Standalone application

Step 1: The user will login using the The application will redirect the user to the
account designated to the student index page where add event tab can be
organization respectively. interacted.

Step 2: The user will fill up the fields The application will store the data inputted by
for event details and the matrix of the user and will make a prompt of pending
participants. for verification.

4.1.2 Data Validation by the Student Organizations Coordinating Council

Stimulus from the User Response from the Standalone application

20
 Step 1: The user will login using the
account designated to the Student
Organizations Coordinating Council.
The application will redirect the user to the
index page containing the list of events
interacted recently and a notification bar for
new submissions made by the student
organizations.

Step 2: The user will click a pending The application will show the details of the
activity needed to be event inputted by student organization.
evaluated/validated.

Step 3: The user will click the “next” The application will proceed to the next page
button after reviewing the student providing a checklist of the requirements for
organizations inputs. the organization.

Step 4.1: The user will check the
necessary checkboxes and provide
remarks according to the compliance
of hard copy of requirements and
will hit deny.
The application will prompt a pop-up box
listing the deficiencies listed in the
checkboxes and the revisions done in the
data list.

Step 4.2: The user will click enter The application will deliver the status to the
submit upon confirming the list system and providing the notification of the
provided in the pop-up box. deficiencies to the respective student
organization user.

Step 5: Provided the application
lacks certain requirements /
inconsistent data, the user can click
the remark text field in the validation
page.
The application will enable the user to enter
recommendations in the remarks text field
for the Student Organization to comply and /
or revise.

Step 6: The user can type the data The application will accept the data inputted
that needs revisions. by the user and save it for viewing of the
recipient.

Step 7: The user will click the “deny” The application will return the application
button. back to the Student Organization for
completion of requirements / revisions.

Step 8: The user will check all the The application will deliver the status to the
checkbox provided the requirements system and passing the data to the Office for
for completion have been met and Student Affairs.
will click the “Endorse” button.

4.1.3 Approval of storing the data into the database by the Office for Student Affairs
Stimulus from the User Response from the Standalone application

21
 Step 1: The user will login using the The application will redirect the user to the
account designated to the Office for index page containing the live list of events,
Student Affairs. having the events with the status of
“Endorsed” on the topmost.

Step 2: The user will click a pending The application will show the details of the
endorsed activity. event.

Step 3: The user will click the The application will store the event data into
approve button. the database.

5. Business Rules
● Student Organizations - The student organizations users must completely comply to the
requirements imposed by the Office for Student Affairs. This include the legitimacy of
every data encoded into the system. The user has the access to submit and revise only
the data that is not having the status of “Approved”.
● Student Organizations Coordinating Council - The Student Organizations Coordinating
Council must accomplish the pending activities with honesty and must not tamper the
data with personal agenda. The accomplishment period for each pending activity must be
based on the imposed deadline of the Office for Student Affairs. The user will only have
one account and has the authority to impose revisions on the data submitted by the
student organizations. Suggestions for editing can be done by the user and will provide
highlights on all the changes must be done by the student organizations.
● Office for Student Affairs - The OSA is the Superuser in which have extra functional tools
that can be used only by the account designated to the office. The Superuser is the only
account that has the authority to use data management and lesser user management
functions.

22
23