3.0 Specific Requirements (George)
The SAGA prototype must implement the functional, performance, and non-functional
requirements. Requirements shall provide the blueprint for creating the SAGA prototype for
specifics it requires. Each requirement listed describes a key implementation of the SAGA
prototype.
3.1 Functional Requirements
The functional requirements describe the functionality present in the SAGA prototype.
The product must satisfy these requirements to achieve the goals and objectives of the project.
3.1.1 Database Requirements (Daniel)
SAGA data is persistent and accessible by all parts of the SAGA application as needed.
The below data models shall be present:
1.
2.
3.
4.
5.
Courses
Course prerequisite structure
Course offerings in a semester
Student course enrollments by semester
Student and Faculty course requests by semester
3.1.1.1 Structure Requirements – Courses (Daniel)
A course is a unique offering provided by a college or department as part of an outlined
curriculum. Courses are the primary resource scheduled by SAGA as student demand for
courses is the driver of all other resources and schedules.
The database shall make available the following attributes for a course:
1.
2.
3.
4.
5.
6.
7.
8.
9.
Course Department
Course Number
Course Name
Minimum Teaching Requirements (e.g. Instructor or above, Doctorate or above)
Required Resources (e.g. Requires laboratory resources, media resources)
Optional Course Qualifiers (e.g. Writing Intensive, Technical)
Number of credit-hours
Graded or pass/fail
Distance offering possible (e.g. a given course may be possible to offer in a distance format; this
does not guarantee that a given course is offered in that format each semester)
The database shall make it impossible for a unique course as identified by department and
course number to be present multiple times. Example: CS 150 is present one time, CS 170 is
present one time, etc.
3.1.1.2 Structure Requirements – Pre-requisite (Daniel)
A given course may have a one or more prerequisites If exists, the information that shall be
available is:
1.
2.
3.
4.
5.
6.
Prerequisite course (or courses) – minimum grade earned
Minimum number of required credit-hours accrued – not enforced – except CS 367/8
Minimum student year (e.g. junior year required) – not enforced – except CS 367/8
Minimum grade earned (e.g. must have grade of C or better)
Co-requisites (e.g. can take A if already taken or simultaneously taking course B)
Academic year of prerequisite (e.g. applies to 2011-2012 year)
A given single prerequisite can have one or more of the above attributes. Example: Course
A can have prerequisites of both B and C. Course D can have prerequisites of either E or F.
Course G can have prerequisites of H or one of either I or J. Each of these criteria shall be
supported.
The database shall make circular prerequisites impossible (e.g. it shall be impossible to
specify that course A is a prerequisite of course B *and* that course B is a prerequisite of course
A).
SAGA makes use of prerequisites in developing course predictions. Regardless of student
desire, a student cannot enroll in a course without satisfying the prerequisites. SAGA will use
this information to prevent students from requesting ineligible coursers and to remove ineligible
students from consideration in the prediction process
3.1.1.3 Course Offering Requirements (Daniel)
A given course is deemed an offering when it is scheduled to be offered in a term. An
offering can be registered for by students, but these are not the same thing (see 3.1.1.4 – Student
Course Enrollments by Semester).
The database shall support the below attributes of an offering:
1. Unique section number
2.
3.
4.
5.
6.
7.
8.
9.
Course
Day of week class meets (e.g. M/W/F, T/Th)
Length of class period (e.g. 50 minutes, 75 minutes)
Start time of class
Instructor
Semester (e.g. Fall 2011)
Distance learning offering (e.g. Is this offering via Distance Learning or Teletechnet)
Assigned Room (as building and room number)
3.1.1.4 Student Course Enrollments by Semester (Daniel)
A course enrollment is when a student registers for a course offering (a given course in a
given semester; see 3.1.1.3). An enrollment has the below supported attributes:
1.
2.
3.
4.
5.
Course offering by course section number
Student
Semester (e.g. Fall 2011)
Date Registered
Final Grade
A student shall not be able to enroll in the same course (either the same or different offering) in
the same semester.
3.1.1.5 Student and Faculty Course Requests by Semester (Daniel)
Student and faculty course requests indicate interest in either enrolling or instructing a
specific course in a given term. Course requests are not compulsory for a course enrollment or
instructor assignment, but do form the basis for the SAGA prediction process. The below
attributes of a course request shall be supported:
1. Course (e.g. CS 410)
2. Student or Faculty
3. Semester (e.g. Fall 2011)
4. Date Requested
5. Person Requesting (e.g. by the student for him/herself; by an adviser on behalf of the
student)
The database shall only allow a student or faculty to request a course one time for a given term.
3.1.1.4 Database User Functionality (GT/Daniel)
The database must store information for verifying users and providing access control
information. The following functional requirements shall be provided:
1. Must store the fake UINs and passwords of all users created for the demonstration of the
prototype
2. Passwords must be stored as salted hash values in accordance with security best practices.
3. Must give the appropriate tools and rights to the user logging in.
4. Must allow an administrator to assess and repair aspects of the system.
3.1.1.5 Student Database Tables (Ronald)
The student entity of the database keeps records of all student related tables, and must provide
the following functional requirements:
1. The database must be able to store all relevant student attributes by containing the following
tables:
a. Student Information
i. Student ID
ii. First name
iii. Last name
iv. Graduation Status
b. List of completed courses
i. Student ID
ii. Course ID
iii. Grade received
c. Course requests
i. Student ID
ii. Course ID
iii. Course Semester
2. Entries in each table must be sort-able by any data field (name, ID, etc.)
3. Student ID must act as a key value for students and their information. Student tables may not
contain a given student ID more than once.
4. Attributes may not contain null values.
3.1.1.6 Faculty Database Tables (Ronald)
The faculty entity of the database keeps records of all faculty related tables, and must provide the
following functional requirements:
1. The database must be able to store all relevant faculty attributes by containing the following
tables:
a. Faculty Information
i. Faculty ID
ii. First name
iii. Last name
b. Faculty Training (ensures teacher is qualified to teach a given course)
i. Faculty ID
ii. Qualification
c. Constraints (time periods unavailable to teach course(s))
i. Faculty ID
ii. Time period
d. Faculty requests
i. Faculty ID
ii. Preference Type (“desire”, “avoid”, or “willing” to teach)
iii. Course ID
2. The information in #1 must be sort-able by any data field (name, ID, etc.)
3. Faculty ID must act as a key value for faculty entities. Faculty tables may not contain a given
faculty ID more than once.
4. Faculty attributes may not contain null values.
3.1.2 GUI Requirements (Aaron)
The GUI requirements shall be described and implemented into the SAGA prototype.
Each GUI must satisfy the requirements associated for each page listed.
Figure 1. GUI sitemap
Figure 1 illustrates the flow of the GUI and the different views that a particular user is able to
navigate to depending on the level of access.
3.1.2.1 Department Schedule Specialist GUI (Aaron)
A specific graphic user interface for the department schedule specialist shall be incorporated in
the prototype. This interface must allow for view and manipulation of the course database.
Additionally the interface must provide a view of output from the predictive engine.
3.1.2.1.1 Home view (Aaron)
Upon login and authentication (3.1.3.4), after the user is verified as being the DSS, the user shall
be taken to an initial view which can navigate to all other views of the GUI. The following
functional requirements shall be provided
1. The ability to view of the department’s course schedule as it currently exists in the
database (section 3.1.1)
2. A way for the user to navigate to the Report View (3.1.3.1.2).
3. A way for the user to navigate to the Master Wish List.
4. A way for the user to navigate to the Course List.
5. A way for the user to activate the course addition dialog.
6. A way for the user to navigate to the Faculty Master Wish List.
3.1.2.1.2 Report View (Aaron)
This view shall display the set of reports generated by the predictive engine. The following
functional requirements shall be provided:
1. List view of the attrition and student interest report that is attached to both the predictive
algorithm and the database. (3.1.1)
2. Report shall append dynamically every time the database is modified.
3. Graphical indication of the importance status of each course in the report. (e.g. If the
course is highlighted in red, there is definite discrepancy between course current capacity
and predicted student interest)
3.1.2.1.3 Master Student Wish List (GT)
After a user has logged in and has been verified as a Department Scheduler, the user will be
provided a button to select the Master Student Wish-List view. This page shall provide the
following functional requirements:
1. Must provide list of all desired courses.
2. Must provide number of students who requested each course.
3. Must allow user to order list, in ascending or descending order, by the modified UINs of
students indicating interest in that course.
4. Must allow user to order list in ascending or descending order by course number.
3.1.2.1.4 Master Faculty Wish List (GT)
After a user has logged in and has been verified as a Department Scheduler, the user will be
provided a button to select the Master Faculty Wish-List view. This page shall provide the
following functional requirements:
1. Must list all faculty members.
2. Must list desired courses.
3. Must list available times for each faculty to teach that course.
4. Must be able to sort desired courses, in ascending or descending order, by modified
faculty UIN.
5. Must be able to sort desired courses, in ascending or descending order, by course number.
3.1.2.1.5 Add Course Dialog Window (Aaron)
The user shall be able to select an option which allows for adding new courses to the database.
The following functional requirements shall be provided:
1. Ability to access this window from the department schedule specialist interface
section.
2. This window must allow for entry/collection of all course entity attributes (unless
a null value is legal).
3. Ability to activate this population.
3.1.2.1.6 Predicted Interest View (Matt)
This process will produce a report of predicted interest in course for the semester
1. Shall base its report off data collected from the master student wish-list as well as data from the
roll-forward. (Requirement 3.1.2.1).
2. Shall examine each course being offered and record the number of students who wish to take that
particular course.
3. Shall display this information on screen for the scheduler to view.
4. Uses requirement 3.1.3.1.2 to display the report on screen.
3.1.2.2 Student GUI (George)
A specific graphic user interface for the students shall be incorporated in the prototype.
This interface must allow for the student to choose courses to take and enter in courses they wish
were available. The list of courses includes all Computer Science courses illustrated in the CS
Course Info Table in the Appendix.
3.1.2.2.1 Student Wish-List view
After a user has logged in and has been verified as a student, the user will be provided the
Student Wish-List view. This page shall provide the following functional requirements:
1.
2.
3.
4.
5.
6.
7.
8.
A list of courses for the department that is available to select.
Ability to select courses they wish/intend to take the following semester
Ability to enter in a course they wish were available to take that is not in provided list.
The course entered in will be checked for key words to log student interest.
Limits selection to a maximum of five courses.
Requires a minimum selection of one course.
A way to submit courses selected and courses entered to the database.
Submission of data updates the database table for Master Student Wish-List (3.1.2.1)
3.1.2.3 Faculty GUI (George)
A specific graphic user interface for the faculty shall be incorporated in the prototype.
This interface must allow for the faculty to submit a wish-list for courses they want to teach and
their teaching schedule.
3.1.2.3.1 Faculty Wish-List view
After successful authentication and access level approval as a valid faculty member, the user
will be provided with the Faculty Wish-List view. This page shall provide the following
functional requirements:
1. Ability to select number of courses they want to teach.
2. Ability to select number of courses they are willing to teach additionally to what they
want.
3. Ability to select courses they are willing to teach in the specified semester from master
list of courses in database.
4. Ability to select day of the week they are willing to teach.
5. Ability to select time of day they are willing to teach.
6. Ability to submit selections to the database.
3.1.2.4 Login GUI (Jeremy)
The GUI login function allows for authentication and access control. The GUI Web-based
login shall allow authentication to specific features of the product based on user access.
1. The protocol of the login must be in the most current C#/ASP.NET Model View
Controller (MVC).
2. Access shall be based upon a secure access control list (ACL) with the following allowed
users:
USER:
Admin
Student
Faculty
Scheduler
Registrar
ACCESS LEVEL:
Level 1
Level 5
Level 4
Level 2
Level 3
1. The login GUI page must be implemented with HTTPS
3.1.3 Prediction Engine Requirements (Michael)
The prediction engine is responsible for computing the expected interest in each course in
a department. Interest is expressed in terms of number of seats that will be filled. For the
prototype the prediction engine will be limited to course interest predictions for the CS
department for the next semester.
3.1.3.1 Prediction Engine Data Requirements (Michael)
In order to facilitate the functionality of the prediction engine, the prediction engine shall be
provided the following data from the SAGA database:
1. Course information
a. Course number
b. Department
c. Previous semesters a course was offered
d. Prerequisites
e. Credit hours
2. Student information
a. Name
b. UID
c. Previously taken courses
d. Wish-list courses (see section 3.1.2.1)
3. Faculty information
a. Name
b. UID
c. Wish-list courses (see section 3.1.2.2)
d. Degree level
e. Qualified courses
3.1.3.2 Data Source Interface (Michael)
The prediction engine shall provide an external interface to the SAGA database to
facilitate communication between the two sub-systems. This interface will allow easy swapping
of data sources when moving between test and production environments. The Interface shall
provide:
1. A connection to a data source (e.g. the SAGA database in the demonstration version of the
prototype)
2. An internal representation of all relevant data within the data source as specified in section 3.1.4.1
3. Getter and setter methods for all internal data
4. A method to update the data source with the predicted course interest
3.1.3.3 Predictor Interface (Michael)
As multiple prediction methods may exist, the prediction engine shall provide an internal
interface for managing those methods, each method being known as a predictor. Each predictor
must provide this interface. The predictor interface shall provide:
1. A run method which returns a data structure containing courses with predicted interest
2. A method to update the courses for which the prediction shall be run
3. A method to update the range of semesters for which the prediction shall be run
a. A semester range of ‘1’ indicates a prediction for only the next semester, a
semester range of ‘2’ indicates a prediction for the next two semesters, etc.
b. The semester range shall be not more than 12 (allowing predictions for 4 years,
with three semesters per year, fall, spring, and summer).
c. For the prototype, the semester range must be 1
4. A method to add students to the predictor
5. A method to add faculty to the predictor
6. A method to add courses to the predictor
3.1.3.4 Prediction Methods (Michael)
Multiple prediction methods will exist for the prototype, allowing for evaluation of
distinct predictive capabilities. The prototype shall provide two forms of predictive analysis:
1. Resource Utilization Optimization Algorithm
2. Historical Trending Analysis Algorithm
3.1.3.4.1 Resource Utilization Optimization Algorithm (Ian)
Utilizing the data sources referenced in section 3.1.4.1, the final product version of this
algorithm will provide optimized suggestions for the efficient utilization and allocation of
institutional resources (teachers, courses, classrooms/seats, and time/availabilities). The
resultant solution (or solutions, as there may be many practical potential arrangements) of this
algorithm will be evaluated in terms of all student and faculty preferences.
From a low level perspective, this algorithm must determine course suggestions tailored
to individual student needs and preferences. From an elevated perspective, assessment of the
results of the algorithm will provide an overall evaluation on what courses should be offered for
a term, attempting to please as many individuals within the system while keeping available
resources and preferences in mind.
This algorithm must be extensible enough to account for a variety of components
identified as being necessary for the final product. These components include:
1. Room based allocation (with maximum available seating, as well as student and
teacher preferences)
2. Time based allocation (when are teachers, students, rooms available and/or
preferred?)
3. Teacher based allocation (matching teachers with rooms and courses based on
their teaching experience and preferences)
4. Independent student course load evaluation (individual students may only desire
to take a certain number of courses within a term, and also have a hard upper limit
imposed on them by the university. We must not suggest more than they can or
want to take; doing so would allocate resources that could be spent/utilized
elsewhere.)
This is an NP-hard problem. The permutations inherent in this problem space quickly
render brute force methods impractical for even a small set of overall constraints. There are a
variety of potential approaches to work around this. Implementation suggestions include the use
of genetic algorithms, simulated annealing, and/or meta-heuristics.
Room, teacher, and time based allocation will not be included in the prototype.
Internally, the prototype optimization analysis will be limited to evaluating suggestions for
student course loads for a semester given their preferences (from the wish lists) and the
constraint of each active student taking the minimum number of courses required to qualify as a
full time student during the term. In the context of the prototype, the only constrained “resource”
will be the number of course suggestion “slots” available to each active student. Also taking into
account the student’s course history, the algorithm must fill these slots with optimal suggestions
tailored to the individual. Results must be biased towards first suggesting core courses over
electives.
Due to considerable reductions in scope, compared to the offerings intended with the
final product, the overall value in the use of the prototype’s optimization analysis (note: not the
final product) is recognized as severely limited. The prototype optimization algorithm is being
offered as proof of concept, and establishes a foundation for the future inclusion of the core
powerful speculative components identified above. Upon inclusion of these components, direct
competition for resources will be at play within the system and much more advanced and useful
analysis can be done.
The final version of this algorithm will ultimately offer an extreme level of granularity to
the scheduling process due to its evaluation of all these factors present within the system. The
final product will allow for in depth evaluation of which courses should be taught by which
teachers at which times in which classrooms with which students to best meet the overall needs
and desires within the system. The prototype, however (again due to reductions in scope), will
not expose this level of granularity. The prototype must assess its resultant suggestions and
present a high level overview of its best scoring evaluation through the interface described in
section 3.1.4.3.
3.1.3.4.2 Historical Trending Analysis Algorithm (Byron)
The Historical Trending Analysis will evaluate data that shows how the student population
has behaved in the past when registering for courses and moving through the required course
progression. The Historical Trending method will implement the Prediction Manager Interface
(see section 3.1.4.3) by providing:
1. A method that determines the wish list attrition rate (i.e. the number of students
requesting a course versus the number that actually enrolled).
2. A method that determines the historical attrition rate (i.e. the number of students that
enrolled in one course and continued to the next course in the progression).
3. Apply the attrition rates to the number of requests for the course and return the result as
the suggested course capacity.
3.1.3.5 Prediction Engine Module (Michael)
The prediction engine module is the public face of the prediction engine to the rest of the
system. The module will take the form of a Dynamic Link Library (DLL) which is instantiated
by a calling object. The prediction module shall provide:
1. A public method for selecting the predictor
2. Creation of the data source interface
3. Creation of the predictor interface
a. Add the courses for which the prediction shall be made to the predictor
b. Add students to the predictor
c. Add faculty to the predictor
4. A public run method which runs the prediction and updates the data source with the
results of the prediction
5. A public method to inform the caller that the last call to run is complete and the data
source has been updated
3.2 Performance Requirements
The SAGA prototype will rely on a set of tools to provide useful reports to the
Department Scheduler.
3.2.1 Database
The Database must maintain the data that is submitted. The database must accurately
depict the current state of university and simulated data.
3.2.2 Reports
The reports generated must accurately capture and arrange the data from the algorithms.
The reports shall be parsed to the specific GUI webpage that it belongs to.
3.2.3 GUI
The GUI’s must allow the user to view and interact with the SAGA webpage. The user
must be able to select and submit the data necessary for SAGA. The GUI’s must also allow the
Department Scheduler to view and manipulate data in the database and build the schedule.
3.2.4 Prediction Engine
The prediction engine shall meet the following performance requirements:
1. If the Predicted_Course_Interest table has not been constructed, build the table, with predictions,
within a maximum of one minute
2. If the Predicted_Course_Interest table has been constructed, respond to any requests to modify
the table within 10 second
3.3 Assumptions and Constraints
Condition
Prediction only occurs one
semester out
Type
Assumption
Prediction applies to only CS
department courses at ODU
Assumption
The prediction engine must
have course information from
the SAGA database
The prediction engine must
have historical course
offerings by semester and year
(in the form of a roll-forward)
Dependency
The prediction engine must
have course prerequisites
Dependency
The prediction engine must
have Student wish-list data
Dependency
The prediction engine must
have faculty wish-list data
Dependency
The prediction engine must
have student course history
Dependency
Dependency
Effect on Requirements
The prediction engine will
only be tested to verify
correctness for one semester
The prediction engine will
only make predictions for
those courses
Without this information the
prediction engine will not be
able to make predictions
Without this information not
all prediction methods will
function. The historical
trending analysis method
depends on this data
Without this information the
prediction engine will not be
able to make predictions
Without this information the
prediction engine will not be
able to make predictions
Without this information the
prediction engine will not be
able to make predictions
Without this information not
all prediction methods will
function. The historical
trending analysis method
depends on this data
3.4 Non-functional Requirements (George, Aaron, GT)
Non-functional requirements identify supporting functions for the SAGA prototype. The
SAGA prototype shall maintain specific non-functional requirements pertaining to security,
maintainability, and reliability.
3.4.1 Security
The security requirements for the SAGA prototype will follow best practice security
standards.
3.4.2 Maintainability
The SAGA prototype shall be maintained through administrator access which shall allow
the administrator to update databases and software updates. Because SAGA is a software
solution it shall require minimum software maintenance and no hardware maintenence.
3.4.3 Reliability
The SAGA prototype shall utilize:
1. A Genetic Algorithm within the Resource Utilization Optimization Algorithm, a wellknown sophisticated method of prediction. The Genetic Algorithm is used by
corporations to minimize inefficiencies and maximize productivity.
2. The reliability of the Historical Trending Analysis Algorithm is based on the utilization
of historical data. The data used relies on collected data of a 10 year span which is a solid
foundation.
3. The input for the GUI will be constrained to disallow garbage values.
NOTE – Will be placed in Section 2
Test Harness Requirements Philosophy (Jeremy)
The purpose of the SAGA test harness is to demonstrate prototype functions and features
by allowing data input which will facilitate the testing of functionality and capability. Traditional
test harness frameworks typically provide a specialized “mode” wherein a user or administrator
can manually modify data to create specific scenarios which demonstrate functionality. The
SAGA test harness utilizes a slightly different methodology, and will test functionality primarily
via the currently built-in functions of the prototype. Test cases will be shown by logging in as the
back-end account most suitable for the desired test, and modifying data via the in place
components. There will be a few specific test harness functionalities implemented for certain
features of the prototype, and they will be appropriately documented. However, for the general
use of this prototype, unless otherwise specified, the test harness framework will consist of
utilizing the already in-place functions.
Appendix
CS Course Info
Course Number
CS 101
CS 102
CS 106
CS 107
CS 108
CS 110
CS 120G
CS 121G
CS 126G
CS 149
CS 150
CS 170
CS 250
CS 252
CS 270
CS 295
CS 300T
CS 312
CS 330
CS 333
CS 334
CS 350
CS 355
CS 361
CS 367
CS 368
CS 381
CS 390
CS 395
CS 410
CS 411W
CS 417
CS 418
CS 450
CS 451
CS 454
CS 455
CS 456
CS 457
CS 458
CS 460
CS 471
CS 472
CS 475
CS 476
CS 480
CS 486
CS 487
CS 488
CS 495
CS 497
Course Name
Computers: An Introduction
Introduction to Networks and the Internet
Intermediate Wordprocessing
Intermediate Spreadsheets
Intermediate Presentation S/W
Introduction to Computer Science
Introduction to Information Literacy and Research
Introduction to Information Literacy and Research for Scientists
Honors, Introduction to Information Literacy and Research
Elements of Computer Science.
Problem Solving and Programming I
Computer Organization and Architecture I
Problem Solving and Programming II
Introduction to Unix for Programmers
Introduction to Computer Architecture II
Topics in Computer Science.
Computers in Society
Internet Concepts
Object Oriented Programming and Design
Programming and Problem Solving in C++
Computer Architecture Fundamentals
Introduction to Software Engineering
Principles of Programming Languages
Advanced Data Structures and Algorithms
Cooperative Education
Computer Science Internship
Introduction to Discrete Structures
Introduction to Theoretical Computer Science
Topics in Programming Languages
Professional Workforce Development I
Professional Workforce Development II
Computational Methods and Software
Web Programming
Database Concepts
Software Engineering Survey
Network Management
Introduction to Networks and Communications
Database Administration I
Database Administration II
Unix System Administration
Computer Graphics
Operating Systems
Network and Systems Security
Introduction to Computer Simulation
Systems Programming
Introduction to Artificial Intelligence
Introduction to Parallel Computing
Applied Parallel Computing
Principles of Compiler Construction
Topics in Computer Science
Independent Study in Computer Science
Include in DB
y
n
y
n
n
y
y
y
y
n
y
y
y
y
y
n
y
y
y
y
y
y
y
y
n
n
y
y
n
y
y
y
y
y
y
y
y
y
y
y
y
y
y
y
y
y
y
y
y
y
y
Incorporate Historical Data
n
n
n
n
n
n
n
n
n
n
y
y
y
y
y
n
n
y
y
n
n
y
y
y
n
n
n
n
n
y
y
n
n
n
n
n
n
n
n
n
n
n
n
n
n
n
n
n
n
n
n
Incorporate Prerequisites
n
n
n
n
n
n
n
n
n
n
y
y
y
y
y
n
n
y
y
n
n
y
y
y
n
n
n
n
n
y
y
n
n
n
n
n
n
n
n
n
n
n
n
n
n
n
n
n
n
n
n