Having concluded that the problem should be configured rather than being an iterative process driven by manual intervention, the configuration should permit expression of a rich set of requirements, but equally avoid the code-bloat which would result from including features for which the demand is dubious, & which might jeopardise the completion of the project & inhibit subsequent maintenance.

  • The requirements are configured for just one arbitrary week, on the assumption that the requirements for other weeks are similar.

  • The number of time-slots per day is configurable, though it is assumed that each day has the same number.

  • Each resource (i.e. each location, student or teacher) must be able to specify the whole days in an arbitrary week, on which they're available. One could go further & permit specification of all the individual timeslots when each resource is available, but this finer grain requirement can be accommodated using the concept of groups (of which more later).

  • Each location in which classes are held, must be able to define its capacity to accommodate students; though weekdaze will assume that there is always room for the teacher & any teaching-assistant required.

    This prevents weekdaze from booking more students into a location than it can accommodate.

  • Each location should be able to advertise an arbitrary set of facilities, & similarly each course must be able to demand an arbitrary set of facilities.

    This prevents weekdaze from booking courses into unsuitable locations.

  • Each teacher must be able to define the maximum ratio of the time they're available, that may be allocated to teaching; it is assumed that a smaller ratio would also be acceptable.

    This requirement prevents teachers from becoming overloaded with teaching, without any time allocated to the associated duties.

  • Each teacher must be able to define a specialty amongst those topics they can teach.

    This requirement will allow weekdaze to selected them in preference to other teachers who are merely able teach that topic.

  • Each teacher may specify a personal location, in which their classes will preferentially be booked.

    This allows a teacher a place to call their own, in which to work between classes, without enduring the inconvenience of frequent unnecessary migration.

  • Each teacher may define approximately where in an arbitrary day, they would prefer any free-periods to be scheduled. Precise specification of the times of free-periods is unlikely to be required, since one doesn't know (at the time of configuration) the times @ which weekdaze is going to book any lessons & before which they may prefer to prepare, nor even how many lessons will be booked for any teacher & therefore how many free-periods that teacher will ultimately have.

    This requirement is intended to allow teachers to use any spare time effectively, by scheduling it where it is likely to be most useful to them. It is a soft criterion which can be traded for improvements elsewhere in the resulting timetable.

  • One must be able to define for each course, the number of lessons per week required for its tuition. This is a soft constraint, since fewer lessons may be booked provided that sufficient improvements in the timetable are achieved according to other criteria. The ability to models courses that require a number of lessons which varies between weeks, is moot since only one week is currently modelled.

  • Any course may be configured so that it can only be scheduled in contiguous sessions of duration no shorter than a minimum number of time-slots. The corresponding requirement that a course can only be taught in contiguous sessions of duration no longer than a maximum number of time-slots, isn't currently considered sufficiently useful.

    This allows one to account for topics which can't be taught effectively in short sessions, either due to the time required in preparation or clean-up, or because the required duration is outside one's control (e.g. a cookery-class).

  • Courses may be grouped into sets, such that the lessons of each member-course must be synchronised with those of all the other members.

    This requirement; allows students to migrate between the member-courses, without significantly impacting the timetable; may be used to ensure that no student is enrolled on more than one member-course.

  • Any course may set an upper limit on the number of students who may be simultaneously taught in a class. This is independent of the capacity of the (currently unknown) location into which the class will ultimately be booked.

    This allows one to model a tutorial, where one-to-one sessions are required.

  • Any course may be configured so that ideally each of the lessons required are booked as near to a specified time-slot as possible, but on an arbitrary day.

    This accounts for the need to teach academically demanding topics when the concentration-level of students may be expected to be sufficient, e.g. the earliest time-slot.

  • Any course may be configured so that some of the required lessons are scheduled @ precisely defined times.

    This may enable the user to satisfy some requirement which either I haven't considered or have decided not to implement.

  • Students may be grouped into bodies, each composed from members with identical requirements.

    This is more about efficiency than the required result, since after this grouping, weekdaze need only concern itself with the smaller number of student-bodies rather than individual students.

  • The set of subjects required by a student-body may be partitioned into core & optional subsets, depending on their (or more realistically a teacher's) personal evaluation of the relative significance of each subject to the achievement of their goals. The assigned priority isn't an attribute of the subject, & may therefore be evaluated differently by student-bodies whose goals differ.

    This allows weekdaze to trade the booking of some subjects in favour of others, when no more complete solution can be found. It might be preferable to assign a more precise numeric priority to each subject, but this would make configuration more difficult, & the consequence of any specific choice unclear.

  • Each student-body may be assigned a Stream-id.

    This requirement is intended to control weekdaze's capability to permanently merge student-bodies with identical knowledge-requirements. In the absence of a Stream-id, weekdaze will infer a student-body's ability from the Level of the individual subjects they've selected to learn, it is occasionally useful to qualify this by defining their ability via a Stream-id, so that weekdaze avoids undesirable mergers.

  • Each student-body may define the maximum ratio of the time they're available, that may be allocated to teaching. weekdaze shouldn't overload a student-body by booking a greater ratio, & should avoid a smaller ratio where possible; cf. the similar specification for a teacher, where a smaller ratio is quite acceptable.

    This requirement is intended to ensure that the time required to study the select subjects fills their week to an acceptable extent.

  • Each student-body (or the teacher performing the configuration) may define approximately where in an arbitrary day, they would prefer any free-periods to be scheduled.

    This requirement is intended to allow student-bodies to use any spare time effectively, by scheduling it where it is likely to be most useful to them. It is a soft criterion which can be traded for improvements elsewhere in the resulting timetable.

  • Groups composed of any number of student-bodies & teachers may be defined, to permit scheduling of extra-curricular activities.

    Whilst one could use groups to model student-clubs, this would significantly reduce the size of student-bodies (the members of which must have identical requirements), reducing the efficiency of weekdaze. As a result, this capability may be better applied to modelling morning-assembly, lunch-time & staff-meetings.

  • Each group may define an arbitrary number of precise meeting-times.

    The point of such meetings is entirely up to the group-members & may only be inferred from the group's name. One could form a group, which meets for the whole of one afternoon, but doesn't require the members to do anything, thus allowing one to model the availability of student-bodies or teachers in fractions of a day.

  • The meetings of any group may be categorised as mandatory, requiring all group-members to attend every meeting. In order to attend the meetings of such a group, the group-members must also be available on that day.

    This requirement is intended to allow one to model the difference between a work-orientated & leisure-orientated groups.