43
1 PREFACE T he version of Quest described in the following SRS differs from the current version of Quest with respect to both the front-end appearance and a number of additional functionalities. The changes to the front-end appearance include a restructuring of the page layouts. The Quest described here includes a left navigation menu bar with links to a number of key areas. This menu bar will be present of every page in Quest to help facilitate easier navigation between pages. The specific functional changes are listed below. Academics Functional Improvements In some ways the Academic Section has the largest number of changes designed to streamline the process and to reduce spikes in system usage. Firstly, the pre-enrollment concept has been replaced with a more general and powerful wishlist concept that allows the user to create a list of courses they want to take for all future terms. Quest would then be able to look further ahead and potentially plan more intelligently. Furthermore, Quest would then have the option of picking out courses from a term that may work better instead of trying to fit in four or five specific courses that were pre-enrolled (and not being successful for some of them). A better course selection module is specified that allows simpler search and hides the term numbers (eg 1089) by displaying all offered terms that a course is offered. With the new wishlist structure that allows Quest to more intelligently choose courses for the users, the demand peaks around enrollment periods will be reduced. In addition, Quest is specified to handle more users. These two pieces taken together allow us to eliminate the concept of enrollment appointments. The users will have already inputted into Quest which courses they want as the courses are offered. So when Quest schedules the courses, there should not be many changes needed. Other improvements include: Course Overrides can now be requested in Quest through the wishlist interface. E-mail alerts can now be requested for when new course offerings are added to quest and when grades come out for a course. Official transcripts and enrollment confirmation letters can now be ordered through Quest. Personal Portfolio Functional Improvements The Personal Portfolio has some improvements regarding the user interface. It uses one category called Contact Information to store and display all the contact data of the user. It does not separate the information into Names, Address(es), Email Address(es), Phone Number(s), and Emergency Contact(s) categories. There is no point in doing so since there is only 3 primary functions that can be done with this data, which is add, edit, or delete. It allows the user to retrieve their information faster since all their information is displayed right when the user clicks on “Contact Information”. Financial Functional Improvements With respect to the Fiances Section, there have been a number of improvements. The described Quest is able to accept payment for term fee via PayPal, since PayPal can be linked to any international bank, this will help facilitate easier payment from both Canadian resident and international students. In addition to this, the described Quest allows students to opt-out of optional term fees. On the term fee page, optional term fees will be marked and students can request to opt-out of such fees before paying. This improvement will give students a more convenient way of opting out of term fees and reduce the paper work needed to process refunds. Lastly, the described Quest also allows the user to export their term fees as either a spread sheet or request a paper copy in the mail for a fee.

AcademicsFunctionalImprovementsdberry/HTML.documentation/... · 2 OVERALL DESCRIPTION 6 1.3.7 TermFee A term fee refers to the break down of all the items changed to a full-time or

  • Upload
    others

  • View
    6

  • Download
    0

Embed Size (px)

Citation preview

1

PREFACE

The version of Quest described in the following SRS differs from the current version of Quest withrespect to both the front-end appearance and a number of additional functionalities. The changes to

the front-end appearance include a restructuring of the page layouts. The Quest described here includesa left navigation menu bar with links to a number of key areas. This menu bar will be present of everypage in Quest to help facilitate easier navigation between pages. The specific functional changes are listedbelow.

Academics Functional Improvements

In some ways the Academic Section has the largest number of changes designed to streamline theprocess and to reduce spikes in system usage. Firstly, the pre-enrollment concept has been replaced witha more general and powerful wishlist concept that allows the user to create a list of courses they wantto take for all future terms. Quest would then be able to look further ahead and potentially plan moreintelligently. Furthermore, Quest would then have the option of picking out courses from a term that maywork better instead of trying to fit in four or five specific courses that were pre-enrolled (and not beingsuccessful for some of them). A better course selection module is specified that allows simpler search andhides the term numbers (eg 1089) by displaying all offered terms that a course is offered.

With the new wishlist structure that allows Quest to more intelligently choose courses for the users, thedemand peaks around enrollment periods will be reduced. In addition, Quest is specified to handle moreusers. These two pieces taken together allow us to eliminate the concept of enrollment appointments. Theusers will have already inputted into Quest which courses they want as the courses are offered. So whenQuest schedules the courses, there should not be many changes needed. Other improvements include:

• Course Overrides can now be requested in Quest through the wishlist interface.

• E-mail alerts can now be requested for when new course offerings are added to quest and whengrades come out for a course.

• Official transcripts and enrollment confirmation letters can now be ordered through Quest.

Personal Portfolio Functional Improvements

The Personal Portfolio has some improvements regarding the user interface. It uses one categorycalled Contact Information to store and display all the contact data of the user. It does not separate theinformation into Names, Address(es), Email Address(es), Phone Number(s), and Emergency Contact(s)categories. There is no point in doing so since there is only 3 primary functions that can be done withthis data, which is add, edit, or delete. It allows the user to retrieve their information faster since alltheir information is displayed right when the user clicks on “Contact Information”.

Financial Functional Improvements

With respect to the Fiances Section, there have been a number of improvements. The describedQuest is able to accept payment for term fee via PayPal, since PayPal can be linked to any internationalbank, this will help facilitate easier payment from both Canadian resident and international students. Inaddition to this, the described Quest allows students to opt-out of optional term fees. On the term feepage, optional term fees will be marked and students can request to opt-out of such fees before paying.This improvement will give students a more convenient way of opting out of term fees and reduce thepaper work needed to process refunds. Lastly, the described Quest also allows the user to export theirterm fees as either a spread sheet or request a paper copy in the mail for a fee.

CONTENTS 2

Contents1 Introduction 5

1.1 Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51.2 Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51.3 Definitions, acronyms, and abbreviations . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

1.3.1 Course Override . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51.3.2 Milestone . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51.3.3 OUAC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51.3.4 PayPal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51.3.5 Quest . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51.3.6 Service Hold . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51.3.7 Term Fee . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61.3.8 Transcript . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61.3.9 User . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61.3.10 UWDIR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61.3.11 Wishlist . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

1.4 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61.5 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2 Overall description 62.1 Product perspective . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.1.1 System Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62.1.2 User Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.2 Product functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.3 User characteristics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.4 Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.4.1 Parallel Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.4.2 Audit Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.4.3 Reliability Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.4.4 Safety and Security Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.5 Assumptions and dependencies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

3 Specific requirements 93.1 External interface requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

3.1.1 User interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93.1.2 Software interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93.1.3 Communications interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

3.2 System features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103.2.1 User Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

3.2.1.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103.2.1.2 Response Sequence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103.2.1.3 Associated functional requirements . . . . . . . . . . . . . . . . . . . . . . 10

3.2.2 Academics: Course Selection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103.2.2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103.2.2.2 Stimulus/Response sequence . . . . . . . . . . . . . . . . . . . . . . . . . 113.2.2.3 Associated functional requirements . . . . . . . . . . . . . . . . . . . . . . 13

3.2.3 Academics: Course Enrollment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143.2.3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143.2.3.2 Stimulus/Response sequence . . . . . . . . . . . . . . . . . . . . . . . . . 143.2.3.3 Associated functional requirements . . . . . . . . . . . . . . . . . . . . . . 15

3.2.4 Academics: Course Grades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163.2.4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163.2.4.2 Stimulus/Response sequence . . . . . . . . . . . . . . . . . . . . . . . . . 163.2.4.3 Associated functional requirements . . . . . . . . . . . . . . . . . . . . . . 17

3.2.5 Admissions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

CONTENTS 3

3.2.5.1 Introduction/Purpose of feature . . . . . . . . . . . . . . . . . . . . . . . 173.2.5.2 Stimulus/Response sequence . . . . . . . . . . . . . . . . . . . . . . . . . 173.2.5.3 Associated functional requirements . . . . . . . . . . . . . . . . . . . . . . 19

3.2.6 Student Finances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203.2.6.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203.2.6.2 Stimulus/Response sequence . . . . . . . . . . . . . . . . . . . . . . . . . 203.2.6.3 Associated functional requirements . . . . . . . . . . . . . . . . . . . . . . 23

3.2.7 Personal Portfolio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233.2.7.1 Introduction/Purpose of feature . . . . . . . . . . . . . . . . . . . . . . . 233.2.7.2 Stimulus/Response sequence . . . . . . . . . . . . . . . . . . . . . . . . . 233.2.7.3 Associated functional requirements . . . . . . . . . . . . . . . . . . . . . . 27

3.3 Performance requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273.3.1 Static Numerical Requirement: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273.3.2 Dynamic Numerical Requirement: . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

3.4 Design constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273.4.1 Design constraint 1: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273.4.2 Design constraint 2: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273.4.3 Design constraint 3: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

3.5 Software system attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283.5.1 Reliability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283.5.2 Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283.5.3 Usability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

4 Appendices 294.1 Appendix A: Figures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 304.2 Appendix B: Class Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 304.3 Appendix C: Use Case Diagram of the Quest System . . . . . . . . . . . . . . . . . . . . . 314.4 Appendix D: Use Case List . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

LIST OF FIGURES 4

List of Figures1 Home Page . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 342 Admission Page . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 353 Academics Page . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 364 “Academic History” section . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 375 “University Calendar and Scheduled Courses” section . . . . . . . . . . . . . . . . . . . . . 386 Portfolio Page . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 397 Finances Page . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 408 Class Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 419 Use Case Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

1 INTRODUCTION 5

1 IntroductionThis document is a complete product specification of Quest. It contains all the requirements and expec-tations requested by the customer. This is the primary document containing unambiguous informationabout these requirements. The intended audience for this document includes the customer, project man-agers, domain experts, and programmers. Reader are expected to have some basic computer backgroundas well as have experience with the operations and functions of Quest.

1.1 PurposeThe purpose of this document is to provide a detailed outline of the requirements and specifications ofQuest. It also contains the expectations of Quest and how different components of Quest interact withexternal systems.

1.2 ScopeThis document includes the physical components, behavioural qualities, and the functional and non-functional requirements of Quest. Quest is use by students, staff, and administrators from the Universityof Waterloo, however the scope of this document is strictly the student view of Quest. The student is ableto enroll in courses, view unofficial transcripts, grades, course catalog and schedule. The user is also ableto manage their contact information, view service holds, and view account and financial aid in detail.

1.3 Definitions, acronyms, and abbreviations1.3.1 Course Override

A course override is provided when a student is allowed to enroll is a course for which one or more of thefollowing conditions is met: the course has reached the alloted capacity, the student does not have theneeded pre-requsites, the course createds a time conflict with another course the student is enrolled in,or the student does not meet the required pan reserves.

1.3.2 Milestone

A milestone is an academic requirement completed by the student that is not the completion of a course.This may include the completion of a work term report or the successful completion of the EnglishLanguage Proficiency Test.

1.3.3 OUAC

The Ontario Universities’ Application Center. Quest shall interact with OUAC to receive informationabout new applicants.

1.3.4 PayPal

PayPal is a corporation which is used to facilitate secure payment over the Internet. PayPal will be usedas a means of making a payment towards a term free.

1.3.5 Quest

Quest is the computer based system that allows students to preform the tasks outlined in this document.

1.3.6 Service Hold

A service hold is a limitation to a service given to the user so that he/she is unable to perform tasks onQuest. For example, the student may be restricted from enrolling in courses or viewing term grades.

2 OVERALL DESCRIPTION 6

1.3.7 Term Fee

A term fee refers to the break down of all the items changed to a full-time or part-time student for aspecific term for which the student is enrolled at the University of Waterloo. The term fee may include,tuition, endowments, co-op fees, and health and dental insurance. These fees may differ based on whetherthe student is graduate or undergraduate, full-time or part-time, a Canadian resident or internationalstudent, and will depend on the program in which the student is enrolled.

1.3.8 Transcript

A document that outlines the academic record of a student. A transcript will contain a listing of all thecourses which a student has taken with their received grade, any awards or scholarships the student hasreceived, and any milestones which the student has completed.

1.3.9 User

A user is the person or persons, who operate or interact with the product directly. For the purpose ofthis specification, a student, either prospective, full-time or part-time, is the only user of Quest.

1.3.10 UWDIR

The University of Waterloo Directory service. Quest shall use the UWDIR as a means of verifying thecredentials of any user that attempts to sign on to Quest.

1.3.11 Wishlist

A wishlist is a feature that allows students to enter a set of courses for which they would be interestedin enrolling in for a future term.

1.4 ReferencesIEEE Recommended Practice for Software Requirements Specifications: www.ieee.com.Sample SRS: <https://uwangel.uwaterloo.ca/uwangel/section/default.asp?id=UW-MCL-C-080829-134756>.

1.5 OverviewThe rest of the document describes Quest in detail. Section 2 gives a product description of Quest andthe background for each requirement. Section 3 contains all the specific requirements requested by thecustomer. Section 3 contains descriptions of every input and output to and from Quest. AppendixA contains a number of figures illustrating Quest. Appendix B displays the class diagram of Quest.Appendix C displays the use case diagram for Quest. Lastly, Appendix D displays the list of all the usecases found in Quest.

2 Overall description

2.1 Product perspective2.1.1 System Interfaces

Quest shall interface with a number of other systems. Quest shall consult the UWDIR database tovalidate any user that attempts to access Quest. Quest shall also receive information from OUAC togenerate records and accounts for all users that apply to the University of Waterloo, this applies to bothgraduate and undergraduate students. Quest shall interface with the course catalog database to keepa up to date listing of all the courses offered by the University of Waterloo and their respective coursedescriptions. Quest shall interact with PayPal to allow users to pay their term fees using its services.Quest shall send notifications to the Registrars Office’s systems when a user requests an official transcriptand payment has been received.

2 OVERALL DESCRIPTION 7

2.1.2 User Interfaces

Quest shall provide a means of allowing all users to sign on via any Internet connection. Once the Questsite is accessed a user is prompted with a sign on screen. The user can sign on to the Quest system usingthe UWDIR ID provided by the University of Waterloo. Once authenticated, Quest shall provide a meansof allowing the user to sign out from any screen. If the user remains idle for a prolonged period of 20 min-utes the system shall sign the user off automatically. When logged off after a session time out, the user willbe returned to the sign on screen which will be accompanied with a message stating the session time outpolicy. While logged on, a user will have access to four main areas; Admissions, Academics, Finance, andPersonal Portfolio. On the Home Page, each of these areas appear as links in the left menu bar. A briefdescription of their purpose will be also be visible on the Home Page. Quest shall allow the use to returnto this Home Page at any time via a “Home” link. In the event that the user clicks any of the four mainareas or an item from the menu bar the features listed in 3.2 System Features are made available to them.

Each of the features provided by Quest shall follow a consistent format. The features are listed ina menu and grouped in logical categories. The look and feel of all pages is consistent with the HomePage. Users may experience slight differences in look and feel due to their Internet browser. Quest shallsupport Internet Explorer 4.0+, Firefox, Opera, Safari and NetScape and maintain a consistent look andfeel within these restraints.

2.2 Product functionsQuest shall provide functions to its users to facilitate needs related to Admissions, Finance, Personal Port-folio, and Academics. The Admissions Section shall be designed to allow users to view all applicationsand offers related to the University of Waterloo. A user is able to view all data related to the application,this includes the status of the application, the transcripts received by the University of Waterloo, thetransferable credits from other universities, should they apply, and the date on which the application waslast review. Quest shall allow the user to accept and decline offers made to him or her by the Universityof Waterloo via this section.

The Finance Section is designed to facilitate actions related to a users financial account. Quest shalldisplay all term fees charged by the University of Waterloo for the current and previous terms. A termis that in which the user was enrolled at the University of Waterloo as either a full-time or part-timestudent. Each of these term fees will include a break down of all the items charged. The user is able toview the remaining balances on all terms. This section shall post any scholarships or bursaries the userhas received and allow the user to enter the amount of money that they expect to receive from OSAP.All remaining balances shall be computed after considering these values. The Finance Section shall allowusers to pay their fees via PayPal and contain information on how users may otherwise pay their fees.Quest shall allow users to export their term fee summaries in the form of an email and request that apaper copy of their term fees be mailed to them. Quest shall allow users to opt-out of any fees that areoptional, this includes, but is not restricted to the Health and Dental Plan and Math Endowment FundDonation. This list is subject to change on a per term basis.

The Personal Portfolio Section is designed to facilitate the maintenance of the users’ personal infor-mation on record at the University of Waterloo. Quest shall display all the personal data related to theindividual that the University of Waterloo currently holds. This will include data such as full name,address, phone number, email address, and emergency contacts. The user has the ability to edit this datafrom this section.

The Academic Section is designed to facilitate all the users needs with regards to their academiccareers. Quest shall provide a means of accessing a user’s transcript, both graduate and undergraduate.In addition to this, before marks become official, Quest shall report the tentative grades for each term tothe user. This report shall also contain the users term average and cumulative GPA. In the event that anew tentative grade is posted, Quest shall send the affected users an email alert notification. This sectionalso facilitates all the enrollment needs of the user. From this section Quest shall provide a listing, whichmay be queried, of all the courses offered in the current and known future terms. Users will be able toquery this listing by subject area, description, and course code. Each course offering will be associated

2 OVERALL DESCRIPTION 8

with a class number that uniquely identifies it within the given term. Users may chose to add, drop, orswap classes as described in Section 3. The Academic Section shall provide access to information relatedto final examination schedules and distance education courses. The user can access information regardingthe course materials and assignments related to any distance education classes that they are enrolled in.Lastly the Academic Section will provide access to information about advisors to Graduate Students.

2.3 User characteristicsThe users of Quest are current students of the University of Waterloo and students that have pendingapplications at the University of Waterloo. These students will belong to different faculties at the Uni-versity of Waterloo and current students may be enrolled in either graduate or undergraduate studies.The users of Quest have at least a high school education level and moderate technical expertise. Questshall be designed to emphasize ease of use to accommodate users of different skill levels. All features aredeveloped to be as self explanatory as possible. Quest shall provide a help system which will be availableto users from all pages within Quest and when accesses shows a tutorial of how to use the current page.

2.4 Constraints2.4.1 Parallel Operation

Quest has a number of constraints. One is that Quest must be able to support a number of userssimultaneously, each of whom is connecting remotely via the Internet. Quest shall ensure that multipleusers are able to connect but that no one user is able to open more than one session to Quest. Questshall service request from all users with no priorities.

2.4.2 Audit Functions

Quest shall keep records of all dates, times, and administrative users, who post any changes to fees. Thiswill include the authorization of scholarships, bursaries, and the reversal of all fees. Quest shall collectaudit data when any administrative user posts that term fees have been received. Quest shall collectauditing data on any transaction whereby a user opt-out of a term fee or makes a payment towards aterm fee. In addition to this, Quest shall collect auditing data on all changes to a user’s application. Achange to a user’s application includes, but is not limited to, changes in their transcript, application form,references, application status, and offers. Quest shall collect auditing data on all changes made to a user’spersonal portfolio. This includes, changes made to any data field in the personal portfolio profile. Lastly,Quest shall collect auditing data for all transactions made to users enrollment that result in overrideprivileges of any sort. This may include, exceptions from pre-requisites or anti-requisites, overriding thelimit of the course capacity, overriding time conflicts, and overriding course blocks for certain studentcategories.

2.4.3 Reliability Requirements

Quest is crucial to facilitating many of the the academic and financial needs of students at the Universityof Waterloo. Quest shall not experience below 98 percent up time apart of scheduled maintenance.

2.4.4 Safety and Security Considerations

Due to the nature of the data stored within Quest, privacy is a major consideration. Quest shall requirethat all users are authenticated prior to accessing any data. Each user will be given one, and only one,sign on ID and password. This ID and associated password will be administered by the UWDIR system.Quest shall automatically sign off any user that has been idle as specified in 3.2.1.3.2.

Quest shall use an https connection as well as a means of encryption to communicate with the userover the Internet.

3 SPECIFIC REQUIREMENTS 9

2.5 Assumptions and dependenciesQuest shall assume that a user that wishes to access the system will be equipped with an Internet browserlisted in 2.1.2. Quest shall make no assumptions about the other components of a user’s computer. Thissuggests that Quest will not assume that the user has JavaScript or cookies enabled.

Quest is dependent on the systems it interfaces with. The specifications will need to be altered asa result of OUAC, UWDIR, PayPal, or course catalog systems. This includes, but is not limited to,changes in the format of stored data and the protocol needed to connect to the external systems.

3 Specific requirements

3.1 External interface requirements3.1.1 User interfaces

The user interfaces shall be user friendly. The pages shall have four links at the top: “Home”, “NewWindow”, “Help”, “Sign Out”. The pages shall look as displayed below.

Home Page The Home Page shall contain links to the four sections: Admissions, Academics, PersonalPortfolio and Finances, and contain a menu bar on the left with commonly used functionalities.This Home Page shall look like figure 1.

Admission The Admission Page shall look like figure 2.

Academics The Academics Page shall contain four main sections: “University Calendar and ScheduledCourses”, “Course Wishlist”, “Enrolled Courses”, and “Academic History”. The “University Calendarand Scheduled Courses” section provides information on the academic plans listed in the universitycalendar and on future course offerings. The “Course wishlist” section allows the user to createa wishlist of courses they intend to take. Both these two sections are described in 3.2.2 CourseSelection. The “Enrolled Courses” section allows the user to examine, schedule, finalize, and trackdetails on the courses they are taking in the current or upcoming term. Finally, the “AcademicHistory” section gives the user information about their course grades, transcripts and academicstanding. The Academics Page shall look like figure 3. The “Academic History” section shall looklike figure 4. The “University Calendar and Scheduled Courses” section shall look like figure 5.

Personal Portfolio The Personal Portfolio Page shall look like figure 6.

If the user chooses one of the links, a new page will appear, displaying actual information and givingthe user the possibility to change it.

Finances The Finances Page shall give the user access to different links grouped by subject. Thesesubjects are Account and Financial Aid. The part Account contains the links “Account Sumary”and “Fee Payment Instruction”. The part Financial Aid contains the links “View my FinancialAid”, “View my earnings”, “Financial Aid Home Page”, “OSAP Home Page” and “Graduate StudentAward Regulations”. This page shall look like figure 7.

3.1.2 Software interfaces

The Software interface is described in Section 2, please refer to it.

3.1.3 Communications interfaces

Since Quest is a Web-based software, it shall support TCP/IP and HTTPS network interface for com-municating.

3 SPECIFIC REQUIREMENTS 10

3.2 System features3.2.1 User Authentication

3.2.1.1 Introduction

The user authentication feature provides security by controlling access to Quest. Both sign on and signoff facilities are provided.

3.2.1.2 Response Sequence

3.2.1.3.1 Login

User Action Quest Response1.User enters UWDIR ID and passwordat sign in page.

2.Quest validates cridentials and signsthe user in or returns them to the signon page with an error.

3.2.1.3.1 Logout

User Action Quest Response1.User clicks “Sign Out”. 2.Quest ends the user’s session and re-

turns them to the sign in page

3.2.1.3 Associated functional requirements

3.2.1.3.1 Quest shall provide a sign on screen for the user to sign in by providing credentials in the formof a user ID and password. The provided credentials shall then be checked against the UWDIRdirectory to ensure that they are valid. If the credentials are valid, Quest shall sign the user on andprovide the user a new active session, if not, an error message shall be displayed to the user.

3.2.1.3.2 Quest shall end a user’s session automatically whenever the user has not requested a pagewithin the previous 20 minutes.

3.2.1.3.3 When a user is logged into Quest, Quest shall end the user’s session whenever the user selectsthe “logoff” link.

3.2.1.3.4 Quest shall allow a user without an active session to access the sign on screen for the purposesof logging in.

3.2.1.3.5 Except as described in 3.2.1.3.4, Quest shall prevent access to Quest unless a user has an activesession. An attempt to access Quest without an active session as indicated shall generate an errormessage and return the user to the sign on screen.

3.2.2 Academics: Course Selection

3.2.2.1 Introduction

The course selection component of Quest provides the user information about their program as shown inthe university calendar and shows the courses planned to be offered in the upcoming terms. The user isable to search for courses and add them to their course wishlist.

Quest shall provide a term profiling facility where the user may indicate preferred course load andpreferred school days/hours for each term. This information is not binding, it provides the University ofWaterloo with guidance for course scheduling.

Quest shall also provide the user a way to view their academic advisors and their advisor’s contactinformation, or supervising professor if they are a graduate student. Finally, Quest shall provide e-mailalerts that can be configured to send updates when new courses are added to a department’s calendar orschedule.

3 SPECIFIC REQUIREMENTS 11

This component of Quest is primarily designed to allow the user to plan their academic career and toprovide the university some insight into future demand for courses.

NOTE: This specification does away with the “pre-enrollment” concept and instead specifies a moregeneral and forward looking wishlist feature that acts similarly to a todo list. It encourages the user tothink further ahead, and thus is likely to smooth out demand peaks. To further address the peaks indemand, the e-mail feature helps to change the workflow from a deadline driven workflow to a workflowwhere the user acts on new information when it becomes available instead of at the last minute. Inaddition, Section 3.3 specifies performance requirements sufficient that a enrollment appointment shouldnot be necessary.

3.2.2.2 Stimulus/Response sequence

(All the following Stimulus/Response Sequences assume that the user has an active Quest session andbegins on the Academics Home).

3.2.2.2.1 View Calendar & Planned courses

User Action Quest Response1.User selects “University Calendar andScheduled Courses”.

2.Quest displays the university calendarfor the user’s enrolment year, startingat the user’s department’s section. Allsections are suplemented with plannedcurrent and future courses.

3.2.2.2.2 Search Calendar & Planned courses

User Action Quest Response1.User selects “University Calendar andScheduled Courses”.2.User selects “Search”.

3.Quest displays a search window thatallows the courses to be searched

3.2.2.2.3 Configure e-mail alerts

User Action Quest Response1.User selects “University Calendar andScheduled Courses”.2.User selects “e-mail alerts”

3.Quest displays a list of departmentsthat the user can enable e-mail alertsfor new courses.

4.The user enables or disables alerts 5.Quest saves desired alerts, and willsend out alerts when information for se-lected department courses change.

3.2.2.2.4 Add course to wishlist

User Action Quest Response1.From either the “University Calen-dar and Scheduled Courses” view orthe search courses view, User selects an“add to wishlist” link beside a displayedcourse.

2.Quest adds the course to the user’swishlist.3.If the user does not meet any ofthe course’s pre-requisites and thesemissing pre-requisites would not bemet by another course in the wish-list, Quest shall suggest adding pre-requsites courses to the wishlist or re-questing a pre-requsite override.

3.2.2.2.5 Enroll in course

3 SPECIFIC REQUIREMENTS 12

User Action Quest Response1.From either the “University Calendarand Scheduled Courses” view or thesearch courses view, User selects an “en-roll” link beside a displayed course.

2.Quest verifies that enrollment is openfor the selected term, if not, an errormessage is displayed with a suggestionto add the course to the user’s wishlist.3.If enrollment is open, Quest verifiesthat the user has all the pre-requisites,and if not, provides the opportunity forthe student to enter an override code.4.If enrollment is open and the pre-requisites are met or a valid overridecode is given, Quest enrolls the user inthe course.5.Otherwise, an error message is dis-played suggesting adding the course tothe user’s wishlist and requesting acourse override there.

3.2.2.2.6 Swap course

User Action Quest Response1.From either the “University Calen-dar and Scheduled Courses“ view orthe search courses view, User selects an“swap course with...” link beside a dis-played course.

2. Quest verifies that enrollment isopen for the selected term, if not, anerror message is displayed with a sug-gestion to add the course to the user’swishlist.3.If enrollment is open, Quest verifiesthat the user has all the pre-requisites,and if not, provides the opportunity forthe student to enter an override code.4.If enrollment is open and the pre-requisites are met or a valid overridecode is given, Quest displays a list of en-rolled courses and asks the user whichcourse to swap with this new course.5.Otherwise, an error message is dis-played suggesting adding the course tothe user’s wishlist and requesting acourse override there.

6.The user selects the course they wishto drop to complete the swap

7.Quest adds the course selected in step1 and drops the course selected in step6.

3.2.2.2.7 View Planned Terms

User Action Quest Response1.From either the “University Calendarand Scheduled Courses” view or thesearch courses view, User selects the“View planned course terms”.

2.Quest displays the planned coursesthat are not in the calendar and are notalready scheduled. (special cases)

3.2.2.2.8 View Course Wishlist

User Action Quest Response1.User selects “Course Wishlist”. 2.Quest displays the courses the user

has added to their wishlist.

3.2.2.2.9 Request Course override

3 SPECIFIC REQUIREMENTS 13

User Action Quest Response1.From the “Course Wishlist” view, theuser selects a “request course override”link beside any course.

2.If the course requires an override,Quest records that an override was re-quested (for some other part of Questto handle).

3.2.2.2.10 Remove Course from Wishlist

User Action Quest Response1.From the “Course Wishlist” view, theuser selects a “remove” link beside anycourse.

2.Quest removes the course from theuser’s wishlist.

3.2.2.2.11 Future terms scheduling and unit load preferences

User Action Quest Response1.From the “Course Wishlist” view, theuser selects the “Future terms schedul-ing and unit load preferences”.

2. Quest displays the user’s upcom-ing terms with the course load and pre-ferred scheduling times for each term.

3. The user may change the course loador preferred course times for any termand choose submit.

4. Quest verifies that the course load ispermitted for the particular term, andif not, an error message is displayed.5. If there was no error message, Questsaves the entered information.

3.2.2.2.12 View Advisors

User Action Quest Response1.From the “Course Wishlist” view, theuser selects the “View Advisors” link.

2.Quest displays the user’s academicadvisor(s) and their contact informa-tion. If the user is a graduate student,the user’s supervisor and the supervi-sor’s contact information is shown.

3.2.2.3 Associated functional requirements

3.2.2.3.1 Quest shall present the user with the university calendar for the year they enrolled in university.The view of the calendar shall be defaulted to the user’s department’s page. The user shall be ableto search the university calendar based on course code and/or description.

3.2.2.3.2 Quest shall provide an additional list of courses that are currently being offered or planed tobe offered but are not in the currently displayed calendar. Each of the courses in this list shallinclude a course description. The user shall be able to search this list based on course code and/ordescription.

3.2.2.3.3 Quest shall supplement the information shown in the calendar and the additional list of courseswith a list of terms when the course is being offered or being planned.

3.2.2.3.4 Quest shall provide a wishlist that the user may add courses from the calendar or the additionallist of courses.

3.2.2.3.5 The user may add or remove courses from their wishlist.

3.2.2.3.6 If a course pre-requisite is not met, Quest shall indicate the missing pre-requisite in the wishlist,but shall not prevent the student from adding such a course to their wishlist.

3.2.2.3.7 Quest shall allow the user to indicate their desired course loads for upcoming terms and theirdesired school hours for upcoming terms. This information is advisory in nature and may or maynot be followed.

3 SPECIFIC REQUIREMENTS 14

3.2.2.3.8 Quest shall provide a page where the user’s Academic Advisers contact information is displayed.In the case where a user is a graduate student, the user shall be shown their supervising professorand the professor’s contact information.

3.2.2.3.9 Quest shall provide an optional service to e-mail the user any changes to a department’scourse offerings. The user must select the department’s course offerings they wish to receive e-mailnotifications about to receive any of these course notifications.

3.2.2.3.10 If the user has a pre-requisite override code, they may enter it for a course in their wish list.

3.2.2.3.11 If a course in the user’s wishlist needs an override, the user may request an override for thecourse through Quest.

3.2.3 Academics: Course Enrollment

3.2.3.1 Introduction

The course enrollment feature provides automatic enrollment in courses based on the course selectioncriteria or enrollment entered manually. This section is designed to allow the user to see the courses theyare enrolled in and make final changes to course enrollments.

Quest shall provide the user with a list of their enrolled courses that includes course schedule, in-structor and room information. The user shall be allowed to add, drop or swap courses. Quest shall alsoprovide a calendar displaying the schedule in a graphical format.

To assist with adding, dropping and swapping courses, the calendar and course list described in sec-tion 3.2.2 shall be made available to the user in this, the course enrollment section, as well.

If the course is a Distance Education course, the course’s material, assignment, and exam scheduledetails may be viewed and the exam schedule details may be modified.

3.2.3.2 Stimulus/Response sequence

Sometime before the term starts Quest will take all the course selections of all users and combine themwith the university course schedule to determine a schedule for the students and the courses. Quest shallenroll each user in a set of courses from their wishlist such that the user has a conflict free schedule. Thespecific algorithm for this matching is not specified in this specification and is left for the designers toimplement. After the user is enrolled in these courses, Quest shall send the user a notification e-mailindicating the courses and schedule they have been enrolled in.

(All the following Stimulus/Response Sequences assume that the user has an active Quest session andbegins on the Academics Home Page.)

3.2.3.2.1 View Enrolled Courses

User Action Quest Response1.User selects “View Enrolled Courses”. 2.Quest displays a list of the courses the

user is enrolled in.

A link is provided to search and add courses that links to the functionality described in sections3.2.2.2.1 through 3.2.2.2.6

3.2.3.2.2 View Class Schedule

User Action Quest Response1.From the “View Enrolled Courses”view, the user selects the “view classschedule” link.

2.Quest diplays a calendar type displaywith the enrolled courses displayed onthe calendar.

3.2.3.2.3 Drop a Course

3 SPECIFIC REQUIREMENTS 15

User Action Quest Response1.From the “View Enrolled Courses”view, the user selects “Drop course” be-side an enrolled course.

2.Quest verifies that the university per-mits the course to be dropped at thistime, and if so, the course is dropped.3. If the course can not be dropped, anerror message is displayed.

3.2.3.2.4 View Course Material Information (Distance Education)

User Action Quest Response1.From the “View Enrolled Courses”view, the user selects a “View CourseMaterial” link beside an enrolled course.

2.Quest displays the status of anycourse material beign shipped to thestudent.

3.2.3.2.5 View Assignment Information (Distance Education)

User Action Quest Response1.From the “View Enrolled Courses”view, the user selects a “View Assign-ment Information” link beside an en-rolled course.

Quest displays any assignment informa-tion provided for the course.

3.2.3.2.6 Exam Schedule

User Action Quest Response1.From the “View Enrolled Courses”view, the user selects a “Exam Sched-ule” link beside an enrolled course.

2.Quest displays the exam schedule andlocation for the course.3. If the course is a DE course, the userwill be allowed to change the exam de-tails.

4.If the course is a DE course, the userchanges the exam time, date, proctor,or location.

5. The changes are accepted (assumesomeone will check these).

3.2.3.3 Associated functional requirements

3.2.3.3.1 Quest shall provide the information described in sections 3.2.2.3.1 and 3.2.2.3.2.

3.2.3.3.2 Quest shall automatically enroll a user in courses such that the user has a conflict free scheduleat a date determined by the administrator.

3.2.3.3.3 Quest shall not enroll the user in more courses than the student is permitted to enroll in perterm

3.2.3.3.4 Quest shall attempt to enroll the student in the number of desired courses indicated in section3.2.2.3.7.

3.2.3.3.5 Quest shall permit the user to add, drop, or swap courses unless there is a hold on this functionor unless pre-requisites have not been met and a override code has not been provided

3.2.3.3.6 Quest shall e-mail the user when the user is automatically enrolled in a set of courses

3.2.3.3.7 Quest shall provide a list of currently enrolled courses along with course schedules, times,locations and professors

3.2.3.3.8 Quest shall provide a calendar type schedule with the information contained in 3.2.3.3.7

3.2.3.3.9 If the course is a Distance Education course, Quest shall provide material, assignment, andexam schedule details. The exam schedule details may be modified by the user.

3 SPECIFIC REQUIREMENTS 16

3.2.3.3.10 The user shall be prevented from adding or swapping a course in a term before the automaticenrollment procedure has not been run for that term. Once the automatic enrollment procedurehas been run, the user may then add or swap courses for that term.

3.2.3.3.11 The user shall be prevented from adding, dropping, or swapping courses for a term after adate set by the administrators as the last day to add, drop, or swap courses. These dates may bethe same or different.

3.2.3.3.12 If a course on the user’s waiting list has a course override approved, Quest will attempt toenroll the user in that course.

3.2.4 Academics: Course Grades

3.2.4.1 Introduction

The academic history feature provides details on the user’s course outcomes (both past and pending).The user may opt to receive notification of new grades by e-mail. Quest shall also allow the user to viewtheir unofficial transcript or place an order for a official transcript to be sent to an address of their choicefor an additional fee. The user may also ask for a letter confirming their enrollment in the university ofwaterloo, also for a fee.

3.2.4.2 Stimulus/Response sequence

(All the following Stimulus/Response Sequences assume that the user has an active Quest session andbegins on the Academics Home.)

3.2.4.2.1 View Academic History

User Action Quest Response1.User selects “Academic History” 2.Quest displays a summary of the stu-

dents grades and milestones.

3.2.4.2.2 View Term Grades

User Action Quest Response1.From the “Academic History” view,the user selects “View Term grades”

2.Quest displays a list of the termgrades with term summaries and termGPA.

3.2.4.2.3 Configure New Grade E-mail Alert

User Action Quest Response1.From the “Academic History” view,the user selects “Configure New GradeE-mail Alert”

2.Quest displays whether e-mailsshould be sent to the user to notifythem of new grades. The user is ableto enable or disable this notification.

3.The user may enable or disable thise-mail notification.

4. Quest saves the user’s setting.

3.2.4.2.4 View Unofficial Transcript

User Action Quest Response1.From the “Academic History” view,the user selects “View Unofficial Tran-script”

2.Quest generates an unofficial tran-script as a PDF file and presents thisto the user.

3.2.4.2.5 Order Official Transcript

3 SPECIFIC REQUIREMENTS 17

User Action Quest Response1.From the “Academic History” view,the user selects “Order Official Tran-script”

2.Quest provides a form where the usercan specify the address to which thetranscript should be sent. Quest willindicate that this service has an extrafee.

3.The user enters the address they wantthe transcript sent to and submits theorder

4.Quest saves the order for processing.

3.2.4.2.6 Order Official Transcript

User Action Quest Response1.From the “Academic History” view,the user selects “Order Enrollment Con-firmation”

2.Quest provides a form where the usercan specify the address to which the en-rollment confirmation letter should besent. Quest will indicate that this ser-vice has an extra fee.

3.The user enters the address they wantthe confirmation letter sent to and sub-mits the order.

4.Quest saves the order for processing.

3.2.4.3 Associated functional requirements

3.2.4.3.1 Quest shall provide a list of the user’s past enrolled courses along with grades, course creditweights, and course outcome.

3.2.4.3.2 Quest shall provide the user’s academic standing, class rank, and term average for each term.In addition, Quest shall provide an overall average.

3.2.4.3.3 Quest shall provide a way for the user to indicate they wish to have new grades sent to themvia e-mail. This e-mail functionality must be explicitly enabled by the user.

3.2.4.3.4 Quest shall send out e-mail notifications of new grades available for the user if the user hasindicated they wish to receive such notifications.

3.2.4.3.5 Quest shall make available the user’s unofficial transcript as a PDF.

3.2.4.3.6 Quest shall accept requests for an official transcript to be sent to an address the user specifies.This request will incur a charge for the user.

3.2.4.3.7 Quest shall accept requests for a letter confirming enrollment in the university. This requestwill incur a charge for the user.

3.2.5 Admissions

3.2.5.1 Introduction/Purpose of feature

The main purpose of the admission section is to give applicants information on the status of their ap-plication to the University of Waterloo. If they are offered admission, they are given the possibility toaccept or to deny the admission offer. This area also contains information about their academic path(such as their school transcripts and test results) and overall information about the applicant.

3.2.5.2 Stimulus/Response sequence

From the menu bar, the user can click “Admissions“. This will display the Admissions page. This pagegives the user the possibility to choose between two links: Undergraduate Studies Applicants or GraduateStudies Applicants.

3.2.5.2.1 Consult personal information about admission

3 SPECIFIC REQUIREMENTS 18

User Action Quest Response1.User clicks on “My application” but-ton

2.A new browser window is openeddisplaying information concerning theuser’s application. This information isthe term he applied for, the program heapplied to, the campus, the course loadand his application status.

3.2.7.2.2 Accept/Deny an offer of admission

User Action Quest Response1.User clicks on “Accept/Deny my offer”button.

2.Quest displays a new page with twobuttons: “accept my offer” and “denymy offer”. If the user has already ac-cepted or denied an offer, Quest shalldisplay this message: “You have alreadyaccepted an Offer of Admission to theUniversity of Waterloo. If you need tochange your decision, please contact theappropriate office listed below.Undergraduate Admissions [email protected] Admissions [email protected]”.

3.User clicks on “accept my offer” but-ton

4.Quest displays a save confirmationpage

5.User clicks on “deny my offer” 6.Quest displays a save confirmationpage

3.2.7.2.3 Consult Status Details

User Action Quest Response1.User clicks on “My Status Details”button.

2.A new browser window is openeddisplaying information concerning theuser’s application status details. thisinformation is the user’s applicationstatus, course load, and term.

3.User clicks on “Registrar’s Office” but-ton.

4.If the user is admitted and currentlystudies in Ontario, Quest displays himthe standard conditions the user mustspecify before attending the Universityof Waterloo.

3.2.7.2.4 Consult Test Results

User Action Quest Response1.User clicks on “Tests Results” button. 2.A new browser window is opened

displaying information concerning theuser’s application tests details. This in-formation is the user’s courses, grades,and dates of the tests.If the user has not done any test, heshall read this message: “The Univer-sity of Waterloo has not received anytest results for your application.”

3.2.7.2.5 Consult transfer CreditsAn applicant who has attended a post-secondary institution must have an official transcript sent (withfinal grades) so that the University of Waterloo can consider the possibility of transfer credits.

3 SPECIFIC REQUIREMENTS 19

User Action Quest Response1.User clicks on “Transfer Credits” but-ton.

2.A new browser window is openeddisplaying information concerning theuser’s transfer credits. This informa-tion is the user’s courses, grades, cred-its, and dates of the credits.If the user does not have any transfercredits, he shall read this message: “NoTransfer Credits”.

3.2.7.2.6 Consult School transcripts

User Action Quest Response1.User clicks on “Transcripts” button. 2.A new browser window is opened

displaying information concerning theuser’s school transcripts.

3.2.7.2.7 General Help

User Action Quest Response1.User clicks on “General Help” button. 2.A new browser window is opened dis-

playing links to specific WebPages ofthe University of Waterloo Website.Theses WebPages are: “General Admis-sion Requirements”, “English LanguageRequirements for Admissions”, “Offi-cial Documents Policy”, “Application”,“Transcript and Document Deadlines”,“Admission Information Form(s)”.

3.2.5.3 Associated functional requirements

3.2.5.3.1 Functional requirement 1 Quest shall be able to collect high school marks of applicantsfrom Ontario interested in studying at the University of Waterloo.

3.2.5.3.2 Functional requirement 2 Quest shall allow the applicant to see the status of his applica-tion (tab My application). The different admission status are listed below, with their meanings:

• Application: No decision has yet been made.

• Conditional Admit: An Offer of Admission with specific conditions has been issued to the user.

• Admit: An offer of Admissions has been issued to the user.

• Deny: the user has been denied admission.

• Intention to Matriculate: The University of Waterloo has received the acceptance/confirmationof the user’s offer of admission from the OUAC.

• Matriculation: The user file has been moved to student records.

• Defer Decision: The user admission file has been reviewed, but there is insufficient informationto make an admission decision.

• Defer Enrollment: The user has accepted/confirmed his Offer of Admission, but plans to beginstudies in a future term.

• Reconsideration: the user has not received an admission decision, and he has either acceptedan offer from another university or accepted an offer to another UW program.

• Applicant Withdrawal: The current status of the user indicates has have withdrawn his appli-cation, accepted an offer from another university, accepted an offer to another UW program,or declined an offer of admission.

• Administrative Withdrawal: The university has closed the application file.

3 SPECIFIC REQUIREMENTS 20

• Admission Revocation: The user has withdrawn his confirmation, or did not successfullycomplete his Offer of Admission conditions.

3.2.5.3.3 Functional requirement 3 A non-Ontario user applying to the University of Waterloo gothrough paper work submission of his marks. Therefore Quest does not collect his marks, but allowshim to see the status of his admission. A Non-Ontario user is either a user studying outside Ontarioin Canada or an international user.

3.2.6 Student Finances

3.2.6.1 Introduction

The Student Finance sections is designed to facilitate all a user’s needs with respect to their financesat the University of Waterloo. This includes activities such as viewing a fee statement of the current aprevious terms, sending a copy of a fee statement to a specific email address, viewing any scholarships orbursaries that the user has received, and the reporting of expected OSAP.

3.2.6.2 Stimulus/Response sequence

(All the following Stimulus/Response Sequences assume that the user has an active Quest session andbegins on the Finances Page.)

3.2.6.2.1 View Term Fees

User Action Quest Response1.User clicks “Account” on the menubar.

2.Quest displayed a list of term forwhich the user was enrolled at the Uni-versity of Waterloo as either a full-timeor part-time student.

3. User clicks a term. 4.Quest displays a break down of theterm fees.

3.2.6.2.2 Opt-Out of a Term Fee

User Action Quest Response1.User clicks “Account” on the menubar.

2.Quest displayed a list of term forwhich the user was enrolled at the Uni-versity of Waterloo as either a full-timeor part-time student.

3.User clicks a term for which term feeshave yet to be paid.

4.Quest displays a break down of theterm fees; all fees that are optional havean “Opt-Out” to their right.

5.User clicks an “Opt-Out” link. 6.Quest displays a dailog box explain-ing the effects of opting out of the cur-rent fee and containing a “Confirm” and“Decline” button.

7.User clicks “Confirm”. 8.The dialog box is closed. Quest dis-plays the term fees with the updatedtotal; the fee that the user selected toopt-out of is now accompanied by anopt-in link.

Alternative 17.User clicks “Decline”. 8.The dialog box is closed. Quest

displays the term fees without anychanges.

3.2.6.2.3 View Term Financial Aid

3 SPECIFIC REQUIREMENTS 21

User Action Quest Response1.User clicks “Financial Aid” on themenu bar.

2.Quest displays a list of years for whichthe user has received aid.

3.User clicks a year. 4.Quest displays a list of scholarshipsand bursaries awarded to the studentfor the selected year with their corre-sponding amounts and a year total.

3.2.6.2.4 Make a PayPal Payment to a Term Fee

User Action Quest Response1.User clicks “Account” on the menubar.

2.Quest displayed a list of term forwhich the user was enrolled at the Uni-versity of Waterloo as either a full-timeor part-time student.

3.User clicks a term for which term feeshave yet to be paid.

4.Quest displays a break down of theterm fees

5.User clicks “Pay Term Fees”. 6.Quest displays a list of payment op-tions.

7.User clicks “Make PayPal Payment” 8.Quest displays a PayPal page whichcan be used to make payment.

Alternative 13.User clicks “Pay Term Fees” next to aterm with an outstanding balance.

4.Skip to 6 above.

3.2.6.2.5 Request a Paper Term Fee Statement

User Action Quest Response1. User clicks “Account” on the menubar.

2.Quest displayed a list of term forwhich the user was enrolled at the Uni-versity of Waterloo as either a full-timeor part-time student.

3.User clicks a term. 4.Quest displays a break down of theterm fees.

5.User clicks “Request Paper State-ment”.

6.Quest displays a page requestingcredit card and address information.

7.User enters credit card and addressinformation and clicks “Continue”.

8.Quest sends a request is sent to theRegistrars Office to mail a paper state-ment to the provided address.

Alternative 17.User clicks “Cancel”. 8.Quest returns to the break down of

term fees.

3.2.6.2.6 Export a Term Fee Statement

3 SPECIFIC REQUIREMENTS 22

User Action Quest Response1.User clicks “Account” on the menu bar 2.Quest displayed a list of term for

which the user was enrolled at the Uni-versity of Waterloo as either a full-timeor part-time student

3.User clicks a term. 4.Quest displays a break down of theterm fees.

5.User clicks “Export Term Fees”. 6.Quest displays a list of export meth-ods.

7.User clicks “Send as Email”. 8.Quest displays text box for email ad-dress to be entered.

9.User enters an email address andslicks “Send”.

10.Quest sends a copy of the term feesto the specified email address.

Alternative 17.User clicks “Save as Spreadsheet” 8.Quest displays text box for file name

to be entered9.User enters a file name and clicks“Save”

10. Quest saves a copy of the term feestatement to the specified file name

3.2.6.2.7 Navigate to “My Earnings”

User Action Quest Response1.User clicks “My Earnings” on themenu bar.

2.A new browser windowis opened with the address<http://www.hr.uwaterloo.ca/myhrinfo/myhrinfo.html>.3.The new window is given focus.

3.2.6.2.8 Navigate to “Fee Payment Instructions”

User Action Quest Response1.User clicks “Fee Payment Instruc-tions” on the menu bar.

2.A new browser windowis opened with the address<http://www.adm.uwaterloo.ca/infofin/students/Payment.html>.3.The new window is given focus.

3.2.6.2.9 Navigate to “OSAP Home”

User Action Quest Response1.User clicks “OSAP Home” on themenu bar.

2.A new browser windowis opened with the address<https://osap.gov.on.ca/eng/eng_osap_main.html>.3.The new window is given focus.

3.2.6.2.10 Navigate to “Financial Aid Home”

User Action Quest Response1.User clicks “Financial Aid Home” onthe menu bar.

2.A new browser windowis opened with the address<http://safa.uwaterloo.ca/>3.The new window is given focus.

3.2.6.2.11 Navigate to “Graduate Student Award Regulations”

User Action Quest Response1.User clicks “Graduate Student AwardRegulations” on the menu bar.

2.A new browser windowis opened with the address<http://www.grad.uwaterloo.ca/scholarships/award_payments.html>3.The new window is given focus.

3 SPECIFIC REQUIREMENTS 23

3.2.6.3 Associated functional requirements

3.2.6.3.1 Quest shall post a separate fee bill for each term that the user was enrolled in one or morecourses at the University of Waterloo.

3.2.6.3.2 Quest shall automatically calculate the term fees for each user based on the number of coursesthey are enrolled in, what faculty the belong to, and any financial aid provided by the Universityof Waterloo.

3.2.6.3.3 Quest shall provide links to major banks and PayPal to help facilitate easier payment of fees.

3.2.6.3.4 Quest shall open all external links in new browser windows and bring the newly opened windowsinto focus.

3.2.6.3.5 Quest shall provide the user with a means of exporting their term fee statement in the formon an email, spreadsheet and paper copy, if a paper copy is chosen the mailing request will not besent until payment has been received.

3.2.6.3.6 Quest shall listing all the financial aid awarded to the user, organized by academic year.

3.2.6.3.7 Quest shall keep an auditing record of all changes made to any user’s financial statement orfinancial aid records.

3.2.6.3.8 Quest shall provide users the ability to opt-out of any optional term fees.

3.2.7 Personal Portfolio

3.2.7.1 Introduction/Purpose of feature

The purpose of the personal portfolio is to hold the personal information and service holds of the student.The user is able to view and change their current contact information which include, name, address, phonenumber, email address, and emergency contacts.

3.2.7.2 Stimulus/Response sequence

(All the following Stimulus/Response Sequences assume that the user has an active Quest session andbegins on the links under the Personal Portfolio category.)

3.2.7.2.1 Change Primary Name

User Action Quest Response1.User clicks on Name Change Form inContact Information.

2.A new browser windowis opened with the address<http://www.registrar.uwaterloo.ca/forms/ChangeOfName.pdf>.3. The new window is given focus.

3.2.7.2.2 Add a New Address

User Action Quest Response1.User clicks on “Add New Address” inContact Information.

2.Quest displays a new page with a formthat has blank editable textboxes foraddress name, city, province, countryand postal code.

3.User enters the address name, city,province, country and postal code.User chooses the type of address: mail-ing, home or both4.User clicks on the “Save” button. 5.Quest displays a save confirmation

page.6.User clicks on the “OK” button. 7.Returns back to the Contact Informa-

tion page.

3 SPECIFIC REQUIREMENTS 24

3.2.7.2.3 Change Home/Mailing Address

User Action Quest Response1.User clicks on “Change Home, Mailingaddress(es)” in Contact Information.

2.Quest displays a new page with a formthat has editable textboxes displayingthe user’s current address.

3.User edits the address name, city,province, country or postal code4.User clicks on the “Save” button. 5.Quest display a save confirmation

page.6.User clicks on the “OK” button. 7.Returns back to the Contact Informa-

tion page.

3.2.7.2.4 Delete Home/Mailing Address

User Action Quest Response1.User clicks on “Delete Home/MailingAddress” in Contact Information.

2.Quest displays a new page that listsout all the user’s mailing address(es).

3.User selects the address he/she wishesto delete.4.User clicks on the “Delete” button. 5.Quest displays a save confirmation

page.6.User clicks on the “OK” button. 7.Returns back to the Contact Informa-

tion page.

3.2.7.2.5 Add a New Phone Number

User Action Quest Response1.User clicks on “Add Phone Number”in Contact Information.

2.Quest displays a new page with blankeditable textboxes for phone type, tele-phone, extension, and preferred option.

3.User enters the phone type, tele-phone, extension, and preferred option.4.User clicks the “Save” button. 5.Quest displays a save confirmation

page.6.User clicks the “OK” button. 7.Returns back to the Contact Informa-

tion page.

3.2.7.2.6 Change Phone Number

User Action Quest Response1.User clicks on “Change Phone Num-ber” in Contact Information.

2.Quest displays a new page withthe user’s phone numbers in editabletextboxes for phone type, telephone,extension and preferred option.

3.User edits the phone number informa-tion: phone type, telephone, extensionand preferred option.4.User clicks the “Save” button. 5.Quest displays a save confirmation

page.6.User clicks the “OK” button. 7.Returns back to the Contact Informa-

tion page.

3.2.7.2.7 Delete Phone Number

3 SPECIFIC REQUIREMENTS 25

User Action Quest Response1.User clicks on “Delete Phone Number”in Contact Information.

2.Quest displays a new page with a listof all the user’s phone number(s) .

3.User selects the phone number he/shewishes to delete.4.User clicks the “Delete” button. 5.Quest displays a save confirmation

page.6.User clicks the “OK” button. 7.Returns back to the Contact Informa-

tion page.

3.2.7.2.8 Add a New Email Address

User Action Quest Response1.User clicks on “Add a New Email Ad-dress” in Contact Information.

2.Quest displays a new page with blankeditable textboxes for email address.

3.User edits the email address.4.User clicks the “Save” button. 5.Quest displays a save confirmation

page.6.User clicks the “OK” button. 7.Returns back to the Contact Informa-

tion page.

3.2.7.2.9 Change New Email Address(es)

User Action Quest Response1.User clicks on “Update preferredemail via UWDir” in Contact Informa-tion.

2.Quest displays prompt for user nameand password to UWDIR.

3.User enters Quest username and pass-word.

4.A new window is open with the ad-dress <https://ego.uwaterloo.ca/uwdir/Update>.5.The new window is given focus.

6.User edits the email address informa-tion.7.User clicks the “Submit” button. 8.The new page displays a confirmation

page.9.User clicks the “OK” button. 10.Returns back to the Contact Infor-

mation page.

3.2.7.2.10 Delete Email Address(es)

User Action Quest Response1.User clicks on “Delete Email Ad-dress(es)” in Contact Information.

2.Quest displays a new page with a listof all the user’s email address(es).

3.User selects the email adresses he/shewishes to delete.4.User clicks the “Delete” button. 5.Quest displays a save confirmation

page.6.User clicks the “OK” button. 7.Returns back to the Contact Informa-

tion page.

3.2.7.2.11 Add Emergency Contact

3 SPECIFIC REQUIREMENTS 26

User Action Quest Response1.User clicks on “Add Emergency Con-tact” in Contact Information.

2.Quest displays a new page with blankeditable textboxes for contact name, re-lationship, address of the emergencycontact (if the address is not the sameas the student), phone number of theemergency contact.

3.User edits the contact name, relation-ship, address of the emergency contact,and phone number of the emergencycontact.4.User clicks the “Save” button. 5.Quest displays a save confirmation

page.6.User clicks the “OK” button. 7.Returns back to the Contact Informa-

tion page.

3.2.7.2.12 Change Emergency Contact

User Action Quest Response1.User clicks on “Edit Emergency Con-tact” in Contact Information.

2.Quest displays a new page with blankeditable textboxes for contact name, re-lationship, address of the emergencycontact (if the address is not the sameas the student), phone number of theemergency contact.

3.User edits the contact name, relation-ship, address of the emergency contact,and phone number of the emergencycontact.4.User clicks the “Save” button. 5.Quest displays a save confirmation

page.6.User clicks the “OK” button. 7.Returns back to the Contact Informa-

tion page.

3.2.7.2.13 Delete Emergency Contact

User Action Quest Response1.User clicks on “Delete EmergencyContact” in Contact Information.

2.Quest displays a new page with a listof all the user’s emergency contact(s)

3.User selects the emergency contacthe/she wishes to delete.4.User clicks the “Delete” button. 5.Quest displays a save confirmation

page.6.User clicks the “OK” button. 7.Returns back to the Contact Informa-

tion page.

3.2.7.2.14 Delete Emergency Contact

User Action Quest Response1.User clicks on “View Service Holds” inService Holds.

2.Quest displays a new page with a listof all the service that the user currentlyhas.

3.2.7.2.15 View Demographic Summary

3 SPECIFIC REQUIREMENTS 27

User Action Quest Response1.User clicks on “View DemographicSummary” in Personal Portfolio.

2.Quest displays a new page with allthe demographic information includingStudent ID number, Gender, Date ofBirth, Martial Status, National Identi-fication Number, Citizenship Informa-tion.

3.2.7.2.16 Return to Personal Portfolio

User Action Quest Response1.User clicks on “Return to PersonalPortfolio”.

2.The Personal Portfolio page displays.

3.2.7.3 Associated functional requirements

3.2.7.3.1 Quest shall give the option of storing credit card information or PayPal account informationto pay for tuition bills.

3.2.7.3.2 When the user updates the preferred name, phone number, email address, Quest shall alsoupdate the name, phone number, email address displaying on UW-DIR.

3.2.7.3.3 When the user updates his/her demographic information, Quest shall secure this informationand not display it in any public view.

3.2.7.3.4 When the user is changing their preferred email address, Quest shall request for his/her user-name and password and shall confirm that they are matched to allow the modification.

3.2.7.3.5 When any information is updated, Quest shall display the modification immediately.

3.3 Performance requirements3.3.1 Static Numerical Requirement:

Quest shall be able to cope with 10,000 simultaneous users.

3.3.2 Dynamic Numerical Requirement:

90% of transactions shall be processed in less than 1 second.During normal workload conditions, i.e. when the number of users is less than 5,000 the system shall beable to deal with 1,000 transactions at the same time.During peak workload conditions i.e. when the number of users is more than 5,000 the system shall beable to deal with 2,000 transactions at the same time.

3.4 Design constraints3.4.1 Design constraint 1:

The Quest system does not have complete information about the user and the machine in which he/sheis using to access the Quest system, for example, the operating system or the hardware specifications.The Quest system cannot perform optimally due to the fact that it has limited knowledge.

3.4.2 Design constraint 2:

The Quest system does not know the connection speed that the user has while running Quest. This canaffect the speed of how fast the Quest system is running. Ie. The speed of Quest will differ if on a Dial-upspeed or a Broadband connection.

3 SPECIFIC REQUIREMENTS 28

3.4.3 Design constraint 3:

The Quest system does not use the browser navigation buttons to navigate through Quest, thus if abrowser navigation button is clicked to navigate through Quest, Quest will return an error page. TheQuest system has its own navigation links such as “Return back to Academics“.

3.5 Software system attributes3.5.1 Reliability

The Quest system shall allow users to use the system if they have the correct Waterloo ID and password.

3.5.2 Security

In order to login into the Quest system, the user must have a Waterloo ID and password assigned tothem.

3.5.3 Usability

The user will need information described in Section 3.2 to operate the Quest system.

4 APPENDICES 29

4 Appendices

4 APPENDICES 30

4.1 Appendix A: Figures

4 APPENDICES 31

4.2 Appendix B: Class DiagramThe Use Case Diagram of the Quest System is represented on figure 8.

There are many classes used in the Quest system.

Application: Represents how the student can apply to the University of Waterloo. The student canget his/her application, get the status of his/her application, and accept/decline the offer when itis made.

ApplicantRecord: Represents the information about the student who is applying to the University ofWaterloo.

TestResults: Represents the information about any tests the student has taken in order to apply to theUniversity of Waterloo.

SchoolTranscript: Represents transcripts that the student has, including high school and post-secondarytranscripts from other universities.

Transfer Credits: Represents any courses/credits that the student has taken in other universities, andthat can be credits for University of Waterloo.

FinancialAidAccount: Represents the total amount of financial aid the student has received through-out his/her education span in the University of Waterloo.

TermAidAccount: Represents the amount of financial aid that student has received in one term.

TermAidItems: Represents the different items found in the TermAidAccount. It contains the differentamount and type of financial aid the student has received.

User: Represents the user of the Quest system.

StudentRecord: Contains all the personal information and demographic summary about the student.

EmergencyContact: Represents all the information about the emergency contact that the student hasadded.

PhoneNumber: Represents the information about the student’s phone number(s).

Address: Represents the address(es) of the student.

Email Address: Represents the email address(es) of the student.

Visa: Represents the information of a Visa that a student may have.

ServiceHold: Represents the information of service holds that a student can have.

StudentAccount: Represents the total balance that the student owes to the University of Waterloo. Itcalculates the total amount that the student owes after the deduction from his/her financial aid.

TermFee: Represents the total fees that the student owes for one term.

TermFeeItems: Represents the different items round in the TermFee. It contains the amount and typeof different fee that the student owes.

Transcript: Represents the University of Waterloo transcript for the student. It contains all the courseinformation that the student has taken and the associated mark for all terms. It calculates theGPA and the overall standing of the student.

Milestone: Represents the extra course(s) or work that the student has to do.

TermCard: Represents the courses that the student is taken during the term and the associated marks.It calculates the TPA and the standing of the student for that particular term. The student canuse this to add, drop, swap courses and pre-enroll into their future courses.

4 APPENDICES 32

CourseRecord: The course record is a record of a user taking a course. It contains the specific detailsrelated to that specific user, such as the grades the student received in the course.

Term: Represents the information of a term. It contains, the start date, end date, exam period, andholidays.

Calendar: Represents the course calendar for the year. It can add/remove courses in the calendar, andcan search through these courses.

Course: Represents the information about a course.

CourseOffering: Represents the information of a course offering.

CourseOfferingSection: Represents a section of a course that is being offered during a specific term.

CourseWishlist: Contains a list of courses the student wishes to take.

DEMaterials: Represents the materials needed for a Distance Education course. It calculuates thedeposit for the material and as well as if the student has paid for the material.

DEAssignment: Represents the assignment information for a Distance Education course.

Exam: Represents the exam date for the Distance Education course. The user is able to set the locationof where the exam is taken place.

4.3 Appendix C: Use Case Diagram of the Quest SystemThe Use Case Diagram of the Quest System is represented on figure 9.

4.4 Appendix D: Use Case List• Login

• Logout

• Timeout

• Help

• View University Calendar and Scheduled Courses

– Add course to wishlist

– Enroll in course

– Swap course with ...

– View planned course terms

– Configure new course e-mail alerts

– Search University Calendar and Scheduled Courses

∗ «search extended by the same use cases as “View University Calendar and ScheduledCourses”»

• View course wishlist

– View Academic Advisers

– Search for course to add «links to “Search University Calendar and Scheduled Courses”»

– Request Course Override

– Remove course from wishlist

– View future term scheduling and unit load preferences

∗ Modify future term scheduling and unit load preferences

4 APPENDICES 33

• View Enrolled Courses

– View Class Schedule (Calendar)– Drop course– Search for course to add «links to “Search University Calendar and Scheduled Courses”»– View Assignment Information– View Exam Schedule Details

∗ Change Exam Schedule Details– View Course Material Information

• View Academic History

– View Term Grades– Configure New Grade e-mail Alert– View Unofficial Transcripts– Order Official Transcript– Order Confirmation Letter

• Accept/Decline Offer

• View Term Fees

– Opt-Out of a Term Fee– Make a PayPal Payment to a Term Fee– Request a Paper Term Fee Statement– Export a Term Fee Statement

• View Term Financial Aid

• Navigate to External Links

– Navigate to “My Earnings”– Navigate to “Fee Payment Instructions”– Navigate to “OSAP Home”– Navigate to “Financial Aid Home”– Navigate to “Graduate Student Award Regulations”

• Access Personal Portfolio

– Change Name∗ Add New Name∗ Delete Name

– Change Address∗ Add New Address∗ Delete Address

– Change Phone Number∗ Add Phone Number∗ Delete Phone Number

– Change Email Address∗ Add Email Address∗ Delete Email Address

– Change Emergency Contact∗ Add Emergency Contact∗ Delete Emergency Contact

– Change Demographic Summary– View Service Holds

4 APPENDICES 34

Figure 1: Home Page

4 APPENDICES 35

Figure 2: Admission Page

4 APPENDICES 36

Figure 3: Academics Page

4 APPENDICES 37

Figure 4: “Academic History” section

4 APPENDICES 38

Figure 5: “University Calendar and Scheduled Courses” section

4 APPENDICES 39

Figure 6: Portfolio Page

4 APPENDICES 40

Figure 7: Finances Page

4 APPENDICES 41

Figure 8: Class Diagram

4 APPENDICES 42

Figure 9: Use Case Diagram

IndexAdmissions, 17Award Regulations, 22

Calendar, 11Class Diagram, 28Course Enrollment, 14Course Override, 5

Design constraints, 27

e-mail alert, 11External interface requirements, 9

Finances, 20Financial Aid, 22

Introduction, 5

Milestone, 5

Opt-Out, 20OSAP, 22OUAC, 5Overview, 6

PayPal, 5, 21Performance requirements, 27Personal Portfolio, 23Preface, 1Product functions, 7Product perspective, 6Purpose, 5

Quest, 5

References, 6Reliability Requirements, 8

Safety and Security Considerations, 8Scope, 5Service Hold, 5Software system attributes, 28Specific requirements, 9

TCP/IP, 9Term Fee, 6, 21Transcript, 6

Unofficial Transcript, 16Use Case List, 30User, 6User Authentication, 10User Interfaces, 7UWDIR, 6

Wishlist, 6

43