Software Requirements Specification

An Online Project Marking System for the University of Portsmouth

 

Version 1.1

Documented by:

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 [1].

 


 

Table of Contents

1. Introduction.. 5

1.1. Purpose. 5

1.2. Scope. 5

1.3. Definitions, Acronyms and Abbreviations. 7

1.4. References. 7

1.5. Overview.. 7

2. Overall Description.. 8

2.1. Product Perspective. 8

2.1.1. System Interfaces. 8

2.1.2. User Interfaces. 8

2.1.3. Hardware Interfaces. 9

2.1.4. Software Interfaces. 9

2.1.5. Communications Interfaces. 9

2.1.6. Memory Constraints. 9

2.1.7. Operations. 9

2.1.8. Site Adaptation Requirements. 10

2.2. Product Functions. 10

2.2.1. Workload Management 10

2.2.2. Project Marking. 10

2.2.3. Mark Aggregation. 10

2.2.4. Email Notifications. 10

2.2.5. Audit Trailing. 11

2.2.6. Release of Project Marks & Feedback. 11

2.2.7. Moderation of Feedback. 11

2.2.8. Configuration. 11

2.2.9. Administration Area. 11

2.3. User Characteristics. 11

2.4. Constraints. 12

2.5. Assumptions and Dependencies. 12

2.6. Apportioning of Requirements. 12

3. Specific Requirements. 13

3.1. User Group – Student 13

3.1.1. View Project Marks. 13

3.2. User Super Group – Academic Staff 13

3.2.1. View All Projects Supervised.. 13

3.2.2. View All Projects Moderated.. 14

3.2.3. Project Search. 14

3.2.4. Mark Project 15

3.2.5. Modify Project Mark. 15

3.2.6. Confirm Project Mark. 16

3.2.7. View Marking History. 16

3.3. User Group – Supervisor. 17

3.3.1. Moderate Project Comments. 17

3.4. User Group – Unit Cohort Co-ordinator. 18

3.4.1. View All Projects. 18

3.4.2. Assign 3rd Marker. 18

3.4.3. Publish Project Marks. 19

3.4.4. Academic Staff Black Listing. 19

3.5. User Group – System Administrator. 20

3.6. User Group – Administration Staff 20

 


1. Introduction

This section of the document provides an overview of the SRS.

1.1. Purpose

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.

1.2. Scope

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 [2] 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.  Figure 1 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.

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

1.4. References

[1] IEEE. (1998). IEEE Std 830-1998, IEEE Recommended Practice for Software Requirements Specifications. ISBN 0-7381-0332-2.

[2] 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.

1.5. Overview

This document has been prepared in accordance with the IEEE Std 830-1998, IEEE Recommended Practice for Software Requirements Specifications [1].

Section 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 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 [1]; 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.


2. Overall Description

This section of the document provides background information relating to the specific requirements which have been defined in Section 3.

2.1. Product Perspective

2.1.1. System Interfaces

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.

2.1.2. User Interfaces

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). 

2.1.3. Hardware Interfaces

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.

2.1.4. Software Interfaces

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.

2.1.5. Communications Interfaces

The HTTP protocol will be used to facilitate communications between the client and server.

2.1.6. Memory Constraints

The UOP already hosts a number of Java web applications, it is not anticipated that OPMS will require any additional memory storage.

2.1.7. Operations

Procedures are already in place as part of the UOP’s IT policies for data security and backup.

2.1.8. Site Adaptation Requirements

As has already been mentioned, the UOP already runs a number of Java web application, as such there are no site adaptation requirements.

2.2. Product Functions

This section outlines the main features of OPMS.

2.2.1. Workload Management

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.

2.2.2. Project Marking

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.

2.2.3. Mark Aggregation

Following the submission of a supervisor and moderator mark, the system should calculate an overall average and determine if the project requires further reconciliation.

2.2.4. Email Notifications

A number of stages in the marking process will generate email notifications.

2.2.5. Audit Trailing

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.

2.2.6. Release of Project Marks & Feedback

The Project Cohort Coordinator must have the ability to publish and unpublish project marks/feedback to students.

2.2.7. 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.

2.2.8. Configuration

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.

2.2.9. Administration Area

It would be desirable to have an administration area for OPMS to allow the maintenance of project marking schemes.

2.3. User Characteristics

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.

2.4. Constraints

The main constraints of this system are as follows:

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.

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.

 


3. Specific Requirements

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 [1].  This template separates the various requirements by user category.

3.1. User Group – Student

This section identifies the functional requirements of student users.

3.1.1. View Project Marks

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.

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.

3.2.1. 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.

3.2.2. View All Projects Moderated

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.

3.2.3. Project Search

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:

Processing

Database query constructed based on criteria.

Output

A list of hyperlinked projects which match the search criteria.

3.2.4. Mark Project

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.

3.2.5. Modify Project Mark

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.

3.2.6. Confirm Project Mark

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.

3.2.7. View Marking History

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.

3.3. User Group – Supervisor

This section defines the functional requirements of project supervisors.

3.3.1. 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.

3.4. User Group – Unit Cohort Co-ordinator

This section defines the functional requirements of the unit cohort co-ordinator.

3.4.1. View All Projects

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.

3.4.2. 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.

3.4.3. Publish Project Marks

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.

3.4.4. Academic Staff Black Listing

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.

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:

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.