Software Requirements Specification
An Online Project Marking System for the University of Portsmouth
Version 1.1
Documented by: Steven J Powell
First Published: 8th May 2005
Change History
|
Version |
Date of Release |
Comments |
|
1.0 |
8th May 2005 |
This is the first version of the document |
|
1.1 |
29th June 2005 |
Changes as agreed in the meeting held with Dr Jim Briggs on 27th June 2005. |
Preface
|
This document contains the Software Requirements Specification (SRS) of an Online Project Marking System for the departments of ISCA and CSSE at the University of Portsmouth. The main aim of this application is to add functionality to the existing system in order to provide an online facility for managing the marking and moderation of student projects. This document has been prepared in accordance with the IEEE Std 830-1998, IEEE Recommended Practice for Software Requirements Specifications [IEEE 830-1998 (1998)]. |
This section of the document provides an overview of the SRS.
This document provides a detailed technical description of the software requirements of OPMS. If defines the product’s functionality and also provides details of the various constraints, assumptions and dependencies of the system.
This specification has been prepared with the purpose of clearly documenting the requirements of the system which have been established and agreed with the client, Dr Jim Briggs.
OPMS is to be used by the Departments of ISCA and CSSE at the University of Portsmouth (soon to become the School of Computing).
In recent years, the procedures used by the University for marking student projects [Briggs, Hart (2005)] have become increasingly complex. As the amount of paperwork associated with the marking process continues to grow, there is an increasing demand for a computer-based system to manage the process. In addition to reducing the amount of administration, a computer-based system is highly desirable for ensuring that the correct procedures are followed. The figure overleaf represents the project marking process which the system will need to implement.
A major goal of the departments is to provide feedback to students. Paper-based means of doing this are infeasible to implement, so an electronic mechanism needs to be developed.
In October 2004, two student projects were launched with the aim of implementing a web-based solution for project marking. Although some progress was made from a design perspective, the students were largely unsuccessful in achieving their goal. With increasing pressure for a system to be introduced, one of the lecturers at the UOP, Dr Jim Briggs, continued to work on the project. The system has now been partially implemented, providing facilities for the capture of project marks and their electronic distribution to an administrator. In its present state, the system provides some relief in terms of administration, but to be fully effective it still requires the incorporation of the project marking processes.
The primary aim of OPMS is to build upon the existing web-based project marking system in order to implement the project marking process. Once this goal has been achieved, a number of associated issues such as the publication of marks to students and audit trails of the marking process will be investigated.
A.1.3. Definitions, Acronyms and Abbreviations
IEEE – The Institute of Electrical and Electronics Engineers, Inc.
OPMS – Online Project Marking System
OS – Operating System
PUMS – Project Units Management System
SRS – Software Requirements Specification
SUMS – Student and Units Management System
UOP – University of Portsmouth
UP Link – UOP Student Portal Facility
IEEE 830-1998 (1998)
IEEE. (1998). IEEE Std 830-1998, IEEE Recommended Practice for Software Requirements Specifications. ISBN 0-7381-0332-2.
Briggs, J., Hart, P. (2005)
Briggs, J., Hart, P. (2005). How to mark a project. Retrieved May 20, 2005, from University of Portsmouth, Project Unit Management System Web Site: http://www.pums.cam.port.ac.uk/projects/docs/projmark.htm.
This document has been prepared in accordance with the IEEE Std 830-1998, IEEE Recommended Practice for Software Requirements Specifications [IEEE 830-1998 (1998)].
Section E.2 provides a description of OPMS and defines the various functions which are required. It also provides details of the system users, constraints, assumptions and dependencies.
Section E.3 of this document defines the specific requirements of the system, it has been organised in accordance with the IEEE Std 830-1998, Annex A, Template A.3 [IEEE 830-1998 (1998)]; this template organises functional requirements by the various classes of user. In addition, this section identifies the performance requirements, design constrains and software system attributes.
This section of the document provides background information relating to the specific requirements which have been defined in section E.3.
The UOP currently hosts a number of web applications providing facilities relating to the administration of student projects. The PUMS facility and the newer SUMS application, which is slowly replacing the functionality of PUMS, are both used to manage the directory of project suggestions. They are also used to manage the allocation of projects, supervisors and moderators and are used to track the ongoing progress of student projects. UP Link provides students with many functions, including the ability to check assessment results.
The data managed by PUMS & SUMS will be required by OPMS in order to retrieve project allocation data, this will be used to determine which projects should be displayed when a user logs in to the system. It would also be desirable to display a project’s marking status as part of the PUMS data. PUMS has been developed using Perl, with the data being stored in flat files. SUMS is based on J2EE technologies and the underlying data is stored in Oracle database. The ability to integrate these systems will need to be investigated.
The method for releasing project feedback to students has not yet been decided, one possibility is for the information to be made accessible via the UP Link system. If this option is selected, integration between UP Link and OPMS would need to be established. This would require some collaboration with the team who operate the UP Link system.
All pages of the system must follow a consistent theme and be optimised for usability. The occurrence of errors should be minimised through the use of checkboxes and radio buttons in order to reduce the amount of text input required. Error messages should be located next to the relevant form elements in order to clearly highlight where errors have been made. The use of tool tips or similar JavaScript components is recommended to provide the user with guidance on how to correctly complete the marking form.
The interface should clearly reflect the various stages of the project marking pipeline. Users should also be able to easily identify the current state of a project within the marking process.
The ability to view and amend project marks/feedback will be determined by the level of access and the user’s relationship to the project (e.g. a member of the academic staff must either be a supervisor, moderator or the cohort coordinator to be able to view/amend the data).
Client Side
Since the application is web-based, a client will require a hardware configuration sufficient to support the use of a modern web browser. The PC must be connected to the internet in order to be able to access the system.
Server Side
The web application will be hosted on one of the department’s Linux servers.
Client Side
An OS capable of running a modern web browser which supports HTML version 3.2 or higher.
Server Side
The UOP already has the required software to host a Java web application. An Apache web server will accept all requests from the client and forward OPMS specific requests to the Tomcat 5 Servlet Container hosting OPMS. The Unix ISO Sunflower Server will be used to host the underlying Oracle database.
The HTTP protocol will be used to facilitate communications between the client and server.
The UOP already hosts a number of Java web applications, it is not anticipated that OPMS will require any additional memory storage.
Procedures are already in place as part of the UOP’s IT policies for data security and backup.
As has already been mentioned, the UOP already runs a number of Java web application, as such there are no site adaptation requirements.
This section outlines the main features of OPMS.
Following a successful login, the user should be presented with a clear view of all the projects which s/he is responsible for either in the role of a supervisor or moderator. The status of each project should be clear to enable users to manage their workload. A different view will be available for the Project Cohort Coordinator who will need to see the status of all projects to ensure they are being marked on schedule. Summary data such as the number of projects outstanding and the number of projects requiring reconciliation should also be provided.
Authorised users should be able to submit project marks and feedback in accordance with the project marking scheme. The system should calculate the overall mark and provide the user with the opportunity to apply positive/negative weightings to the mark.
Following the submission of a supervisor and moderator mark, the system should calculate an overall average and determine if the project requires further reconciliation.
A number of stages in the marking process will generate email notifications.
- Supervisors and moderators will receive an email notification when a project is ready for marking. Also, a warning email if the project has not been marked within a certain time period could also be considered.
- Confirmation emails will be sent to markers once they have submitted their project mark/feedback.
- Supervisors and moderators will receive a notification once a project has received both sets of marks and confirmation of the final mark. The email will also advise if any further reconciliation is needed.
- In the event of a project reaching the second phase of reconciliation, an email will be sent to the Project Cohort Coordinator so that a 3rd marker can be assigned. The 3rd marker will also receive an email advising that s/he has been assigned to re-mark the project.
- A notification email will be sent to the supervisor, moderator and Project Cohort Coordinator once a project mark has been finalised.
Each project will have an associated record of history. This will provide information on various events such as marking, moderation, reconciliation amendments to feedback etc. This will facilitate quality assurance in the project marking process.
Release of Project Marks & Feedback
The Project Cohort Coordinator must have the ability to publish and unpublish project marks/feedback to students.
Moderation of Feedback
The system will combine the feedback of the supervisor and moderator, the supervisor and Project Cohort Coordinator must have the ability to moderate this data to ensure that inconsistent comments are not issued to students.
Although the system is currently only used to mark a subset of the department’s student projects, in the future it might be used more widely throughout the University. As different projects have different marking schemes and criteria the system should be easily configurable to enable flexibility for the types of project which can be marked using the system.
It would be desirable to have an administration area for OPMS to allow the maintenance of project marking schemes.
All users of OPMS are members of the UOP’s School of Computing, as such it can be assumed that they will all have good computing and internet experience. Since they are all familiar with the current process of marking projects, the transition to a web-based system should be relatively smooth.
The system should be designed with accessibility in mind in the event of some users having physical disabilities such as blindness or motor dysfunction.
The main constraints of this system are as follows:
- Technologies – the system has already been partially implemented using J2EE and the Jakarta Struts Framework, as such further development will use these technologies.
- Time - the system needs to be in place by September 2005.
- Previous development – a number of components have been developed by the client, Jim Briggs, as standard plug-ins for all of the web applications he manages. These components will need to be integrated in to OPMS and therefore will place some constraints on how the system will be implemented.
A.2.5. Assumptions and Dependencies
Although basic password authentication and role based security mechanisms will be used to protect OPMS from unauthorised access; functionality such as email notifications are assumed to be sufficiently protected under the existing security policies applied by the University network team.
The correct functioning of OPMS will partly be dependant on the correctness of the data stored and managed as part of the PUMS system. Also, the application will be hosted by the UOP as one of many applications; the event of the server failing due to an error with one of these applications might result in OPMS becoming temporarily unavailable.
A.2.6. Apportioning of Requirements
If the time frame for development does not allow for the implementation of an administration facility for OPMS (for managing projects and their marking schemes), this should be considered at a later stage to provide easier maintenance of the system.
This section identifies the specific functional requirements of OPMS, it has been organised in accordance with the IEEE Std 830-1998, Annex A, Template A.3 [IEEE 830-1998 (1998)]. This template separates the various requirements by user category.
This section identifies the functional requirements of student users.
Outline
Students should be able to view the marks assigned to their projects and the associated feedback.
User Input
Students must provide credentials to enable authentication, only authenticated students should be able view their project marks. This system should also restrict students to only being able to view their project marks and not those of other students.
System Processing
Once the user has been authenticated, the mark data and moderated comments associated with the student’s project should be retrieved from the database. The availability of this information will depend on if it has been published by the Cohort Co-ordinator.
System Output
The project marks and associated comments will be returned to the user.
A.3.2. User Super Group – Academic Staff
This section identifies the functional requirements of the academic staff super group which includes supervisors, moderators, 3rd markers and the unit cohort co-ordinator.
View All Projects Supervised
Outline
Academic staff should be able to clearly see a list of all projects they supervise and their current status.
Input
Retrieval of projects is based on the User’s ID.
Processing
A database query will retrieve details of all current projects supervised by the member of the academic staff.
Output
A list of hyperlinked projects will be displayed on the lecturer’s homepage.
Outline
Academic staff should be able to clearly see a list of all projects they moderate and their current status.
Input
Retrieval of projects is based on the User’s ID.
Processing
A database query will retrieve details of all current projects moderated by the lecturer.
Output
A list of hyperlinked projects will be displayed on the lecturer’s homepage.
Outline
In addition to selecting projects from a list, academic staff should be able to search for projects based on key data such as supervisor, student and project title. This will be especially useful for academic staff members with a large amount of allocations or for the Unit Cohort Co-ordinator when managing all projects.
Input
Search criteria based on:
- Project title
- Student name
- Supervisor/moderator
- Project mark status
Processing
Database query constructed based on criteria.
Output
A list of hyperlinked projects which match the search criteria.
Outline
Authorised member of academic staff should be able to select a project from their list of allocations and submit marks and comments.
Input
The project ID will be submitted via a value in the query string of a hyperlink. Marks and comments will be entered and submitted via an HTML form.
Processing
When a project is selected, mark categories and associated potential weightings will be retrieved from the database and a HTML form dynamically generated to capture the information from the user. When completed, an overall mark will be generated and the marking data stored in the database.
Output
The overall mark is displayed to the user, email notifications will be sent to both to the supervisor and moderator confirming that the project has been marked. The actual mark will not be made visible to both parties until such time as the project has been marked twice and a final average mark have been calculated.
Outline
Prior to confirmation of the project mark, authorised lecturers should be able to change the marks/comments which they have previously assigned.
Input
The project ID will be submitted via a value in the query string of a hyperlink. Marks and comments will be updated and submitted via an HTML form.
Processing
When a project is selected, mark categories, associated potential weightings and previous mark data will be retrieved from the database and a HTML form dynamically generated to capture the information from the user. When completed, a new overall mark will be generated and the marking data stored in the database.
Output
The new overall mark is displayed to the user, email notifications will be sent to both the supervisor and moderator confirming that the project mark has been updated.
Outline
Once both the supervisor and moderator has marked a project, notifications will be sent to both lecturers confirming the final average mark. This mark must be confirmed before the project can be released.
Input
The project ID will be submitted via a value in the query string of a hyperlink. The lecturer will complete a form to confirm the project mark.
Processing
Once the confirmation form has been completed, the project will be flagged as marked and confirmed in the database.
Output
Email notifications to the supervisor, moderator and Unit Cohort Co-ordinator will advise that the project mark has been calculated and confirmed.
Outline
Audit trails should be made visible through the provision of a “history” section for each project.
Input
The project ID will be submitted via a value in the query string of a hyperlink.
Processing
A database query will retrieve all history associated with the project.
Output
A chronologically ordered list of activities carried out during the project marking process.
A.3.3. User Group – Supervisor
This section defines the functional requirements of project supervisors.
Moderate Project Comments
Outline
When both project marks have been issued, the comments made by both the supervisor and moderator will be automatically combined. The supervisor must be able to change the comments prior to release to the student to ensure consistency between the two viewpoints.
NB: Presently this feature is to be available only to project supervisors and the Cohort Coordinator; however, the system should be configurable to allow moderators to also perform this function at a later date.
Input
The project ID will be submitted via a value in the query string of a hyperlink.
Processing
The amalgamated comments will be retrieved from the database. Once modified, the changes will be reflected in the database and the project flagged as ready for publishing.
Output
Email confirmation to the Unit Cohort Co-ordinator that the project is ready to be published.
A.3.4. User Group – Unit Cohort Co-ordinator
This section defines the functional requirements of the unit cohort co-ordinator.
Outline
The Unit Cohort Co-ordinator must be able to see a list of all student projects and their associated status.
Input
Retrieval of projects is based on the User’s ID.
Processing
A database query based on the user’s ID will retrieve details of all projects completed for the co-ordinator’s unit.
Output
List of hyperlinked projects and their associated status.
Assign 3rd Marker
Outline
In the event of reconciliation reaching the stage of requiring a 3rd mark, the Unit Cohort Co-ordinator must be able to assign the 3rd marker.
Input
The Unit Cohort Co-ordinator will select a member of the academic staff from a drop-down list to assign to a project as a 3rd marker.
Processing
The database will be updated with details of the 3rd marker.
Output
Email notifications will be send to the supervisor, moderator and 3rd marker advising of the allocation.
Outline
The Unit Cohort Co-ordinator must have the option to release the project marks to students.
Input
The Unit Cohort Co-ordinator will select a project group and select the option to publish the marks.
Processing
The system will verify that all projects within the selected group are ready for publishing. All projects are flagged as published.
Output
Email notifications are sent to markers and students advising that the project marks are available. The email will explain to student how to gain access to this information.
Outline
On occasion it may be deemed necessary to restrict the access of a member of academic staff to a particular project for ethical reasons. An example might be where a student is related to a member of staff. The Cohort Coordinator should be able to “black list” a member of staff so that they are unable to view details relating to the project marks.
Input
The Cohort Coordinator should select a member of staff and a project to black list the person against.
Processing
A table in the SUMS database will be updated to show that the staff member should not be able to view the project.
Output
Confirmation that the staff member has been successfully black listed for the particular project.
A.3.5. User Group – System Administrator
The functional requirements of this user group have yet to be decided. Possible operations will include the configuration of:
- Cohorts
- Staff
- User privileges
A.3.6. User Group – Administration Staff
The functional requirements of this user group have yet to be decided. It is likely that members of Admin Staff will use the system to register projects for marking at the point of submission by the student.