REHA System Documents

8/2/2019 REHA System Documents

1/12

UPV REHA Dormitory

SystemGladys Blanco Lichael Juris Sibal Era Jane Tumaob Earl Francis Valdehuesa


2/12

1 SYSTEM CONTEXT AND SCOPE

1.1Scope of the SystemThis project would be done in one programming language which is PHP. It would have

specific functions for the UPV dormitory heads and staff such as student informationverification. It would allow the students to apply for a specific dormitory and check his

acceptance online. Dormitory heads and staff would also be able to view the list of

applicants and their application forms online. When it is not yet time for submitting an

application for the next semester students would be able to apply for transient at a specific

dorm and check the availability of rooms.

1.2 Workflow PartitioningThe project team will consist of four members and workflow will be divided as we see fit.

One member will serve as the Project Manager who will manage the entire project andmakes sure that the project is completed or finished within the given time.

1.3Product BoundaryThe product will be written in PHP and will be compatible with any browser.


3/12

1.4Use Case

2 FUNCTIONAL AND DATA REQUIREMENTS2.1Functional Requirements

The system shall provide a form which will serve as the online application form of Dormapplicants

The system shall provide a login form before access of the functions can be made The system shall provide an option for the Admin to accept, decline or cancel submitted

application forms

Admin

Student

Application Management

Submitting of Application

Accountability Management

Guest

Viewing of Dorms


4/12

2.2Data Flow Diagram*Please refer to DFD for Admin.pdf

3 LOOK, FEEL AND USE REQUIREMENTS3.1User Interface Requirements

Must offer option to login Must show UPV dormitories if not logged in Must show application form only at the time of accepting applicants Must recover properly from unexpected interruptions.

3.2Ease of Use RequirementsThis product is intended for students of the University of the Philippines Visayas who are ininterested in applying for the dormitories. The product will be quite easy to use given that

college students already have enough knowledge in using the internet.

4 SECURITY REQUIREMENTS4.1System Confidentiality Requirements

The system shall protect itself and its sensitive data and communications from accidental,

malicious, or unauthorized access, use, modification, destruction, or disclosure. Access to

the information regarding the applicants should not be available to any other applicants.

5 CONSTRAINTS AND ASSUMPTIONS5.1Solution Constraints

Time5.2External Factors

Additional work from other classes Team meeting scheduling Availability of Resources


5/12

5.3AssumptionsWe assume that the system would work on any browser. Since the language that we will be

using is PHP which is familiar to us, we also assume that we will not be encountering any

serious problems and that the system will be finished on or before the deadline.

INTERFACE

FUNCTION DESCRIPTION USER

LoginA login is required to be able to use functions that are

specific to every type of user.Admin, Student

Apply as a dormer

Every end of the semester, the dorm is open to

application. This function will enable students who wish

to apply as a resident to a specific dorm.

Student

View dorm/s

This will enable the user to view the 5 dorms that are

available in UPV so as to see its facilities and newsabout applications.

Admin, Student,

Guest

Check availabilityThis will check available slots that are open to a dorm

that a student can apply to.Admin, Student

Check accountabilityEnables the user to check the existing accountability of

the dormer currently residing in the dorm.Admin, Student

Update accountability

This will update the current accountability of the

dormer, example the dormer already paid for his/her

lodging.

Admin

DormersList of accepted residents of the specific dorms with the

room, locker letter, and other information.Admin, Student

Post announcement Post announcements regarding application dates,payment reminders, etc. from the dorms. Admin

Open applicationThis will enable acceptance of applications from

students who wish to apply for the specific dorm.Admin

Transient application This will enable guests/students to apply for transient 3

days before the transient date

Student, Guest


6/12

ENTITY-RELATIONSHIP DIAGRAM


7/12

STRUCTURE CHART

Dormitory ApplicationSystem

Enter new applicants

data

Validated applicants data Validated applicants data

Add applicant to

database

Select Dormitory

Selected Dormitory Selected Dormitory

Viewing of Dorm Information

System

Display information of

selected dorm


8/12

Enter transient person

info, date of transient and

no. of nights

Validated transient person info,

date of transient and no. of nights

Room Reservation (Transient)

System

Validated transient person info,

date of transient and no. of nights

Add transient person info,

date of transient and no.

of nights to database

Enter subject, admin, and

date posted

Validated subject, admin,

and date posted

Announcement Posting

System

Add new announcement

to database

Validated subject, admin,

and date posted


9/12

Select student/dormer

Selected dormer

Updating Accountabilities

System

Update database

Selected dormer


10/12

Fully Developed Description of Events

Use Case Name: End Application

Scenario: Maximum number of applicants reached

Triggering Event:Applicant submitted application form numbered as the maximum number of

applicants for the specific dorm

Brief Description:

When the applicant submits the application form, the system would count the

number of applicants for that dorm being applied for, if the number of

applicants reached the maximum limit it automatically closes the application

Actors: Applicant

Related Use Cases: Includes: Check Number of Applicants

Stakeholders:

Precondition:

Applicant must exit

Application must still be ongoing

Maximum limit for specific dorm havent been reached

Postconditions:Maximum number of applicants reached

Application forced to end

Flow of Activities:

Actor System

1. Applicant Submits theApplication Form

1.1 Check number of applicants

Exception Conditions:

Use Case Name: Check Number of ApplicantsScenario: System checks the number of applicants for a specific dorm

Triggering Event: Applicant submitted an application form

Brief Description:When the applicant submits the application form, system counts all applicants

with listed dorm the same as the newly submitted application form

Actors: Applicant

Related Use Cases:

Stakeholders:

Precondition:Applicant must exit

Application must still be ongoing

Postconditions: Application is still ongoing

Flow of Activities:

Actor System1. Applicant Submits the

Application Form

1.1 Check number of applicants

Exception Conditions:1.1 If number of applicants reached the limit then application must be forced to

end


11/12

Use Case Name: Calculate Fees/Accountabilities

Scenario: System calculates dormers fees and accountabilities

Triggering Event: Applicants application is approved; Dormers accountabilities updated

Brief Description:

When the applicants application is approved, the system automatically

calculates the dorm fees and when the dormers accountability is updated by

the staff, the system calculates dormers remaining accountabilitiesActors: Dorm Staff

Related Use Cases:

Stakeholders: Dorm Staff: to provide information on fees

Precondition: Applicants application must have been approved

Postconditions: Dormers fees/accountabilities must be calculated and updated

Flow of Activities:

Actor System

1. Dorm staff approves theapplicants application form

2. Dormer pays the fees3. Dorm staff updates dormers

accountabilities

1.1Calculate fees/accountabilities

3.1 Update fees/accountabilities

Exception Conditions:

Use Case Name: Open application

Scenario: Dormitories are ready to accept applicants.

Triggering Event: Scheduled date for application is the same to the current date.

Brief Description:

The administration will schedule the date for opening of application. When the

administration is ready to accept dormers, applicants can submit application

form, applicant is verified if the student/applicant exists and information

supplied is validated.Actors: Administration

Related Use Case:

Stakeholders:

Precondition: Current date must be the scheduled date for the opening of application.

Postcondition: System must accept dorm application from valid students.

Flow of Activities:

Actor

System

1. Admin schedules opening of

accepting application. 2. The system accepts all the

validated applications until scheduled

deadline.3. Applications are stored in the

database.

Exception

Conditions:

3. Invalid applications are disregarded unless applicant makes necessary

corrections.


12/12

REHA System Documents

Documents

Transcript of REHA System Documents