To develop a system which notifies students that they can give feedback on their courses and units via a web site and provides them with individualised access to that website. Allow students to give feedback on the courses and units that they are enrolled on from a web site.

The system must adhere (in spirit if not in letter) with the University's policy on student feedback (http://www.port.ac.uk/accesstoinformation/policies/qualityassurance/studentfeedback/).

1.2 Key personnel

Responsible owner

Peter Hicks (ADQ Faculty of Technology)

Design authority

Jim Briggs

Development team

John Newland

Alex Counsell

1.3 Future proofing

Although the Faculty of Technology has commissioned the system, it is possible that the University will wish the system to be available more broadly in the future.

A possible, future, alternative use for SOFA is as a means of delivering research questionnaires to research subjects.

1.4 Rationale for development

A previous implementation of this system exists (see http://www.pums.cam.port.ac.uk/staff/feedback/index.htm). It is implemented in Perl with an Oracle database.

The existing system does not allow the questions presented to a student to be tailored to the student's course or unit(s).

The new system is to be developed using J2EE technologies and Apache Struts for compatibility with other applications being developed in the University.

1.5 Interactions and dependencies

The existing feedback system has a policy statement at http://www.pums.cam.port.ac.uk/feedback/FBpolicy.htm. It is desirable to maintain that policy, where possible.

Data about students, staff, courses and units is likely to be obtained from other systems including HEMIS and TUD.

1.6 Timetable

Optional initial release (M1 mandatory requirements)	January 2005
Intermediate release (M2 mandatory requirements)	April 2005
Second release (M3 mandatory requirements)	December 2005

D (desirable) requirements will be assigned to a particular release as appropriate.

Requirement	Type	Status
2 Data requirements
2.1 Externally sourced data
1. The system must be capable of holding information on:
a) students	M1
b) courses	M1
c) units	M1
d) staff	M2
e) departments	M3
2. The system must maintain relationships between the above; specifically:
a) what course a student is on	M1
b) what units make up a course at a specific level (year)	M1
c) which members of staff are responsible for a particular course	M2
d) which members of staff are responsible for a particular unit	M2
e) which department owns a course	M3
f) which department owns a unit	M3
3. The above data is likely to be imported from other systems, such as HEMIS and TUD.
4. There must be a unique identifier for each student that cannot be related to the student's identity other than through the feedback system. This is known as the anonymiser code.	M1
2.2 Internally sourced data
1. Create a list or lists of questionnaire questions. This needs to hold	M1
a) the core and semi-core questions defined at http://www.port.ac.uk/accesstoinformation/policies/qualityassurance /studentfeedback/filetodownload,21657,en.pdf (for courses)	M1/2
b) and http://www.port.ac.uk/accesstoinformation/policies/qualityassurance /studentfeedback/filetodownload,21656,en.pdf (for units),	M1
c) plus any questions stipulated by Faculty of Technology for common application to the Faculty's students.	M2
2. Create a structure that relates specific questions to specific courses and units. Additional questions may be related to specific courses and units.	M2
3. In a future version, it is likely that faculties, departments, course leaders, unit co-ordinators and the like will want to add questions relating to their area of responsibility. Such questions should not be presented to students outside the area of responsibility.	D
2.3 General
1. All the above information may vary from one academic year to the next. The data for each year needs to be retained to allow for viewing of questions and responses from previous years.	M1
2. The above data should only be modifiable by a system administrator.	M1
3 Notifying students
1. The system must be capable of notifying students that they may provide feedback. It should also provide students with the instructions necessary to access the system.	M1
2. Either:	M1
a) The system should be compatible with the previous version of the feedback system. This sent emails to students containing common instructions plus a unique URL. The URL was unique because it contained the student's anonymiser code as a parameter.
b) Students should be notified via the student portal, and access to SOFA should by a means that identifies the student.
3. Only a system administrator should be able to notify students.	M1
4. The system administrator should be able to restrict notification to:
a) students on particular courses	M1
b) students from a particular department	D
c) students taking a particular unit	D
d) students who have not yet completed their feedback	M1
5. Experience with the previous version shows that a web application that is asked to send hundreds of emails will probably timeout before they are all sent. SOFA must either limit the number of messages that can be sent in one go, or provide some form of queuing mechanism.	D
6. The system administrator should be able to periodically re-notify students who have not completed their feedback.	M2
7. The system administrator should be able to view list of students that have responded or not responded.	M2
4 Collecting feedback
1. SOFA should receive student feedback via one or more web forms.	M1
2. All submissions should identify the student (normally by their anonymiser code)	M1
3. The system should support the following types of question:
a) what course are you on?	M1
b) what level (year) of your course are you in?	M1
c) what unit(s) do you want to provide feedback on	M1
d) Likert scale type questions (from the database) where the answers are "strongly agree", "agree", "neutral", "disagree", "strongly disagree", "no answer".	M1
e) questions (from the database) with free text responses	M1
4. The default response for Likert type questions should be "no answer".	M1
5. Students should be able to provide feedback on any number of units (including zero).	M1
6. Students should be presented with a list of units that are available to them on their stated course at their stated level.	M1
7. Students should also be able to select units that are not normally associated with their course (e.g. level X units, electives, or where HEMIS/TUD data is inconsistent with reality)	M1
8. Once each group/section of questions is complete it should be passed to permanent store (database).	M1
9. That fact that the student has visited the web site should be stored even if they do not answer any questions.
5 Reporting feedback
5.1 View reports on feedback
1. Feedback reports should only be accessible to authorised users.
a) Only members of staff responsible for a course can see course feedback	M3
b) Only members of staff responsible for a unit can see unit feedback	M3
c) Heads of Department can see summarised reports on all courses and units owned by their department.	M3
d) System administrators should be able to produce any report	M2
2. The format of course reports should show:
a) The name of the course and its leader(s)	M2
b) For each student who commented on the course:
i) The scores given for each Likert scale question	M2
ii) The comments given for each free text question	M2
c) A statistical summary showing the distribution of scores for each Likert scale question	M2
d) Satisfaction scores for the course, defined as
i) The arithmetic mean answer (excluding questions not answered) based on a score of 5 for strongly agree down to 1 for strongly disagree	M2
ii) The proportion (excluding questions not answered) of "satisfactory" answers (i.e. 3 or above) expressed as a percentage of the number of questions answered	M2
3. The format of units reports should show:
a) The name of the unit and its co-ordinator(s)	M2
b) For each student who commented on the unit:
i) The scores given for each Likert scale question	M2
ii) The comments given for each free text question	M2
c) A statistical summary showing the distribution of scores for each Likert scale question	M2
d) Satisfaction scores for the unit, defined as
i) The arithmetic mean answer (excluding questions not answered) based on a score of 5 for strongly agree down to 1 for strongly disagree	M2
ii) The proportion (excluding questions not answered) of "satisfactory" answers (i.e. 3 or above) expressed as a percentage of the number of questions answered	M2
4. It should be possible to generate a report that compares the scores for a specific course(s) or unit(s) over a span of years.	D
6 Supplementary functionality
1. In previous years, the Faculty of Technology has awarded prizes as an incentive to students to complete their feedback. The system should be able to generate a list of prizewinners.	D

7 Document control

7.1 Maintenance procedure

Proposed changes to this document MUST be made with change tracking switched on. Once accepted by the Design Authority, the changes will be accepted and a new version of the document issued.

7.2 History

Version	Date	Changer	Change
v1.4	20^th January 2005	Jim Briggs	Changed name of system from STUFF to SOFA
v1.3	21^st December 2004	Jim Briggs	Maintenance procedure added in section 7.1
v1.2	17^th December 2004	John Newland	Change to requirement 4.8. Parts of questionnaires to be stored before questionnaire is complete. Addition of section 4.5. Student visits to feedback site should be recorded.
v1.1	8^th November 2004	Jim Briggs	Lay out as working document. Corrections to first draft. Refinement of requirements.
v1.0	5^th November 2004	John Newland	First draft