05-11-2012, 03:38 PM
System Requirement Specifications (SRS)
SRS.pdf (Size: 191.18 KB / Downloads: 292)
The university student registration system is unable to cope with the high volume of telephone calls received at
registration time. Among others, busy signals and long distance charges are inherent problems of the telephone
registration system. An online student registration system needs to be developed. In addition, students on campus, off
campus, in-state, out of state, and out of country can easily and inexpensively take advantage of many of the services
provided by the Office of the Registrar, which today require users to be on campus during business hours.
Overview
Background
As the student population of RGP University grows over time, the volume of student registration and manual process of
recording, retrieving and updating each record is getting to be tremendously tedious. Routine student and faculty
inquiries cannot be readily answered over the phone using the existing Voice Registration Unit (VRU) system. Conflicts
in student registration records and schedule have to be manually attended by registration office personnel when the VRU
system is down. During peak transaction times for each new semester, registration lines are getting longer as well as each
student’s waiting and processing time.
With the current process involved and the mounting frustrations and complaints from students, faculty and university
personnel alike, there is an urgent need to develop the university’s online registration system.
Overall Description
In essence the VRU system provides the interface to the main registration database system. Though the back-end database
can reliably accommodate concurrent transactional demands, the VRU system is limited in functioning as such.
The main registration system is mainframe based DB2 version 7, which has nightly tape back-ups and fail-over system in
place. Among others, other systems of the RGP University like Student Grading System, Financial Aid, and Bursar
Systems are on the same DB2 platform.
Investigation & Analysis Methodology
System Investigation
The VRU registration system processes telephone registration transaction by matching the entered telephone numeric keys
to stored transaction equivalents. The telephone numeric key to transaction mapping information is stored in a flat file in
the VRU server’s file system. Recorded transaction values are stored in transaction flat files that are created by the VRU
system for each transaction. The transactions are then transmitted to the main registration system in mainframe DB2 for
database updates after which a transaction indicator is sent back to VRU to indicate the transaction status (success or
failure). Subsequently, an appropriate feedback is then sent back to the caller through a corresponding pre-recorded voice
message.
Feasibility study and requirements elicitation
Organize a development and implementation team composed of people knowledgeable about the current registration
processes with which regular meetings will be held. A series of interviews with the managers and the developers of the
current telephone registration system will be arranged. Interview and feedback from the personnel and staff working
directly with the telephone system is needed to define the current environment and future system requirements. A
Feasibility and Risk Assessment study will be conducted to determine which solution(s) are most appropriate based upon
the results of the interviews.
Object-oriented design using UML
A detailed object-oriented design for the registration system will be developed. UML will be used again for the graphical
representation and documentation of the design. The system will primarily concern itself with the registration process. At
its core, a student will fill out or answer a web based form that will be processed in near real time by the host DB2 backend
system. In addition, the system will allow students to check waiting lists, and course capacities, and provide feedback
regarding current enrollments. The system will be secured with a student’s ID and password/PIN.
SRS.pdf (Size: 191.18 KB / Downloads: 292)
The university student registration system is unable to cope with the high volume of telephone calls received at
registration time. Among others, busy signals and long distance charges are inherent problems of the telephone
registration system. An online student registration system needs to be developed. In addition, students on campus, off
campus, in-state, out of state, and out of country can easily and inexpensively take advantage of many of the services
provided by the Office of the Registrar, which today require users to be on campus during business hours.
Overview
Background
As the student population of RGP University grows over time, the volume of student registration and manual process of
recording, retrieving and updating each record is getting to be tremendously tedious. Routine student and faculty
inquiries cannot be readily answered over the phone using the existing Voice Registration Unit (VRU) system. Conflicts
in student registration records and schedule have to be manually attended by registration office personnel when the VRU
system is down. During peak transaction times for each new semester, registration lines are getting longer as well as each
student’s waiting and processing time.
With the current process involved and the mounting frustrations and complaints from students, faculty and university
personnel alike, there is an urgent need to develop the university’s online registration system.
Overall Description
In essence the VRU system provides the interface to the main registration database system. Though the back-end database
can reliably accommodate concurrent transactional demands, the VRU system is limited in functioning as such.
The main registration system is mainframe based DB2 version 7, which has nightly tape back-ups and fail-over system in
place. Among others, other systems of the RGP University like Student Grading System, Financial Aid, and Bursar
Systems are on the same DB2 platform.
Investigation & Analysis Methodology
System Investigation
The VRU registration system processes telephone registration transaction by matching the entered telephone numeric keys
to stored transaction equivalents. The telephone numeric key to transaction mapping information is stored in a flat file in
the VRU server’s file system. Recorded transaction values are stored in transaction flat files that are created by the VRU
system for each transaction. The transactions are then transmitted to the main registration system in mainframe DB2 for
database updates after which a transaction indicator is sent back to VRU to indicate the transaction status (success or
failure). Subsequently, an appropriate feedback is then sent back to the caller through a corresponding pre-recorded voice
message.
Feasibility study and requirements elicitation
Organize a development and implementation team composed of people knowledgeable about the current registration
processes with which regular meetings will be held. A series of interviews with the managers and the developers of the
current telephone registration system will be arranged. Interview and feedback from the personnel and staff working
directly with the telephone system is needed to define the current environment and future system requirements. A
Feasibility and Risk Assessment study will be conducted to determine which solution(s) are most appropriate based upon
the results of the interviews.
Object-oriented design using UML
A detailed object-oriented design for the registration system will be developed. UML will be used again for the graphical
representation and documentation of the design. The system will primarily concern itself with the registration process. At
its core, a student will fill out or answer a web based form that will be processed in near real time by the host DB2 backend
system. In addition, the system will allow students to check waiting lists, and course capacities, and provide feedback
regarding current enrollments. The system will be secured with a student’s ID and password/PIN.