Finalized Requirements Refinements, Due 11:59PM Monday 23 January

The following requirements refinements were identified during the discussion of Tuesday, Week 3:

Section	Refinements Needed	Assigned To
impacts.html	note that steep learning curve is a potentially negative impact, mitigated by good documentation and tutorial materials	Jordan
matrix.html	still needs to clearly identify which features will be implemented in Winter Phase 1 and Phase 2	Kaylene
userInterface.html	(1) needs to be updated per the latest agreed-upon top-level UI, in particular what goes in the File and Settings menus; (2) needs clarification on admin and instructor authentication, with indication that only admin users are supported in the Phase 1 implementation
basic_schedule_generation.html	all of the figure that still have two courses columns need to be changed to have only on column	Tyler Y
resource-management.html	(1) still need complete clarification at top about where resources are stored within a schedule, and how schedule resource templates can be created and used, referring to file section for complete details on saving to named files; (2) need to change the pencil/check icon to make it clearer when editing and data validation can and do take place, with consideration given to using explicit 'Save' button at the bottom off each of the three resource editing pages	Kaylene
instructor-preferences.html	In subsection 2.5.4, say that details are left to future work, and site the appropriate future work subsection.	Jake
fileMenu.html	needs to have a clear description of when data validation and saving take place during resource data editing; specifically: (1) data validation is performed when	Adam, Tyler H
futureWork.html	(1) remove 2.8.1 on Master list; (2) determine all items that should be considered future work, move them here	Salome

Implementation Issues to Be Addressed, Due 11:59PM Friday 27 January

The following functional issues were identified during the discussion of Tuesday, Week 3. They need to be fully addressed by having an implementation that functions properly, per the description of each issue below.

Issue	Definition of Proper Functionality	Assigned To
Multiple users share the same database.	The known issue with GreetingServiceImpl needs to be fixed, as well as any other functional problems that impose data sharing between any two or more program users. That is, all users have fully independent data spaces, such that changes to one user's data space never affects any other user.	Tyler Y, Matt
Schedule generation takes too long to complete, sometimes on the order of 30 seconds or longer	The time it takes to generate a schedule should never be greater than the amount of time it takes the algorithm to run. In particular., any delays due to database size restrictions should be eliminated.	Matt, Tyler Y
All classes are scheduled at the same time	Instructor preferences need to be taken into account during schedule generation, such that courses are scheduled within the ranges specified in the instructor preferences. The problem may relate to invalid course instructor preference data being sent from the UI to the model, in particular, the preference for all courses being set to 'Not acceptable'.	Adam, Salome, Jake
Labs are not associated with courses	(1) The course resource page needs to include the means to associate labs with courses, and display this information to the user; (2) the generation algorithm needs to schedule labs immediately following associated courses, or as independent scheduled items if not associated.	Kaylene, ?
Missing SEM, IND, ACT, DIS course types	(1) The course resource page needs to allow the following types of course: LEC, SEM, IND, LAB (associated), LAB (unassociated), ACT (associated), ACT (unassociated), DIS (associated), DIS (unassociated). (2) The generation algorithm treats SEM and IND as it currently treats LEC. The algorithm treats ACT and DIS as it currently treats (will treat) LABs.	James
Variable-unit courses	(1) The course resource page needs to allow unit range to be given for any course; (2) the generation algorithm will use the upper value in the range for the purposes of instructor WTU calculation.	Evan, ?
Navigating away from a page with edits in progress sometimes looses unsaved changes	When navigating away from any page with in-progress edits, the state of that page is cached (without saving), such that returning to the page has the state exactly as it was when the user navigated away	?
A course cannot be scheduled with an unassigned time	(1) The course resource page needs to provide an option that allows a course time to be "TBA" in the generated schedule. (2) The course data model has a corresponding TBA attribute, and the generation algorithm puts such courses in the schedule without a time. (3) The calendar view UI shows courses TBA times in a course-number sorted list, immediately below the calendar. Courses from this list can be dragged onto the schedule if the user decides to schedule a time for the course.	?
WTU and SCU values must be integers	The UI and model need to allow decimal and fractional values for WTUs and SCUs. When the user enters a fractional value as a rational number, e.g., 1/3, it is recorded in this form before it is parsed into a double. When the value is re-displayed to the user, it is shown in the form originally entered, i.e., "1/3". If the user enters a value as decimal fraction, e.g., .5, it is displayed in that entered form, i.e., not converted to "1/2".	?
Course numbers can only be integers	In the UI and model, course numbers need to be strings.	Evan
Lecture/lab time proximity is not dealt with satisfactorily	Kaylene is going go sketch out some details of this in the requirements.	Kaylene

Perform the second round of department-specific acceptance testing on the prototype released to scheduler.csc.calpoly.edu/test. Use the revised report format for the week 5 round of acceptance testing, available in this repository file:

testing/acceptance/templates/week5-report.html

Commit the testing reports to testing/acceptance/X/week-report.html, for the appropriate department subdirectory X.

Deliverables

1. 11:59PM Monday 23 January: Requirements refinements committed to repository, in appropriate files in requirements directory.

2. 11:10AM Monday 30 January: Implementation with all issues addressed, with code checked into repo and prototype executable released to scheduler.csc.calpoly.edu/X, for X = each department being tested

3. 11:10AM - 1:00PM Monday 30 January: Second round of acceptance testing completed during class, with reports committed to repository in testing/acceptance/X/second-report.html, for each department X.