Software Requirements Specification
Middleshire University Moodle
Customization Project
Dennis, Wong Ho Yin
3/28/2013
COMPANY NAME : SOSA
Content
1
2
3
4
5
6
Introduction .................................................................................................................................. 3
1.1
Purpose ............................................................................................................................. 3
1.2
Project Scope.................................................................................................................... 3
1.3
References ........................................................................................................................ 3
Overall Description ...................................................................................................................... 3
Functional Requirements ............................................................................................................. 5
External Interface Requirements ................................................................................................ 12
4.1
User Interface ................................................................................................................. 12
4.2
Hardware Interface ......................................................................................................... 12
4.3
Software Interface .......................................................................................................... 12
Technical Requirements (Non-functional) ................................................................................. 13
5.1
Performance ................................................................................................................... 13
5.2
Availability ..................................................................................................................... 13
5.3
Capacity Requirements .................................................................................................. 13
5.4
Security Requirements ................................................................................................... 13
SPONSOR ACCEPTANCE ....................................................................................................... 13
2
1 Introduction
1.1 Purpose
The Software Requirements Specification document is providing the all of the necessary
requirements base on the client for this project. The user and tester can use this document to
testing the software and ensuring the requirements is expected form client.
1.2 Project Scope
The scope of this project is customization Moodle function as the below items and deliver the
customization Moodle to Middleshire University:







Management of online module content in all available formats. The content covers general
module information, learning materials, and assessment.
Automatic plagiarism check of all submitted texts with a similarity index and a detailed report.
The plagiarism check can be ignored, but not switched off.
Grading of assignments with a variety of grading methods including direct grading, rubrics and
written feedback.
Communication among module participants in the form of email, blogging, commenting and
feedback.
A system of user accounts with an advanced access level system
A knowledge base about the module content.
A diary and a calendar
1.3 References
For detail of project scope, please refer to Request for Proposal from Middleshire University and
scope project planning from SOSA
2 Overall Description
2.1 Product Perspective
Moodle is open source virtual learning system for education industry. It provides the course
management include course content, learning tools in different formats. The course content includes
course material, discussion boards, quizzes, assignments, grading forms and more plug-in for
different education feature.
3
2.2 Product Features
The main customization features are listed as below.







Management of online module content in all available formats. The content covers general
module information, learning materials, and assessment.
Automatic plagiarism check of all submitted texts with a similarity index and a detailed report.
The plagiarism check can be ignored, but not switched off.
Grading of assignments with a variety of grading methods including direct grading, rubrics and
written feedback.
Communication among module participants in the form of email, blogging, commenting and
feedback.
A system of user accounts with an advanced access level system
A knowledge base about the module content.
A diary and a calendar
2.3 User Characteristics
There are six types for the system as below:
 Administrator
Administrator is responsible for system user administration and maintaining system.
 Programme manager
Programme manager is responsible for delivery education activities and develop the
programme.
 Module creator
Module creator is responsible for create and develop new module for student.
 Teacher
The Teacher divided into two roles. One is module leader, another one is academics.
The module leader is responsible for manage the Module and the academics teacher
is responsible for manage course.
 Moderator
The Moderator is responsible for support administrative work with module leader
only.
 Students
Student is a person studies in a Middleshire University
4
3 Functional Requirements
This section is outline of the each requirement.
1. Management of online module content in all available formats. The content covers
general module information, learning materials, and assessment.
Use case:
Functional Requirement Description
Before initial this case, the users has already login to the Moodle
1. Teacher, Programme manager and Module creator have related access right can add / update
/ delete course module information
2. Teacher and Module creator have related access right can add / update / delete course
categories
3. Student, Teacher and Module Creator have related access right can upload and download
learning materials
4. Teacher and Module Creator have related access right can add / update / delete quiz, exam,
assessment
5
2. Automatic plagiarism check of all submitted texts with a similarity index and a
detailed report. The plagiarism check can be ignored, but not switched off.
User Case:
Functional Requirement Description
Before initial this case, the user has already login to the Moodle
1.
Automatic plagiarism check for all submitted documents
2.
Support MS Word, WordPerfect, RTF, PDF, PostScript, HTML, plain text (.txt), ODT
3.
Shown % of similarity index.
4.
Display the detail report of plagiarism check
5.
Student can be ignored the plagiarism check, But can’t switched off.
6
3. Grading of assignments with a variety of grading methods including direct grading,
rubrics and written feedback.
User Case:
Functional Requirement Description
Before initial this case, the user has already login to the Moodle
1. Student, Teacher and Module creator have related access right can check the grading of
assignments
2. Using rubrics to assess student’s work.
3. Using Mean of grades for direct grading
4. Student, Teacher and Module creator have related access right written feedback on grade
book.
7
4. Communication among module participants in the form of email, blogging,
commenting and feedback.
User Case:
Functional Requirement Description
Before initial this case, the user has already login to the Moodle
1. The Moodle have email function for Student and Teacher
2. The Moodle have blog function for Student and Teacher
3. Student, Teacher, can leave comment and feedback via email or blog
8
5. A system of user accounts with an advanced access level system
Functional Requirement Description
Moodle must have the below user account and advanced access level right.
Administrator
Access Right:
1. Customisation of the Moodle
2. Instance, the editing of standard roles, the adding and removal of additional features and
plug-ins, the creation, management and deletion of user accounts
3. Imports student and staff lists to create user accounts for them and assign them to the
modules they are registered for
4. Updates user accounts on the basis of the Moodle function.
Programme manager
Access Right:
1.
Create, edit, manage, view and remove modules, and module content
2.
Assign roles up to and including module creators
3.
Create and edit reports
4.
Create and use SCORM data
5.
All rights the module creator has.
Module creator
Access Right:
1.
Creates and configures modules.(includes the creation and editing of assignments and
grading methods such as rubrics)
2.
Upload and configure content.
3.
Assign the roles ‘teacher with editing rights’, ‘teacher without editing rights’,
‘moderator’ and ‘student’.
4.
Assign students to modules.
9
Teacher with editing rights (module leader)
Access Right:
1.
Cannot create modules
2.
Configure and manage modules and their features,
3.
Create and manage content, assignments, general module information and the
plagiarism check.
4.
Editing rights can create grading methods including rubrics and other grading related
rights such as creation and management of reports.
5.
Hide and unhide (show) content and module features as well as publish grades across
the module.
Teachers without editing rights (Academics teaching on a module)
Access Right:
1.
View existing module content, upload and remove their own additional learning
resources, grade assignments, use existing rubrics
2.
Communicate with students in a variety of forms such as feedback, commentary,
annotations, emails and blogs.
3.
Publish the grades of the assignments he or she graded.
Moderator (based on a guest role)
Access Right:
1.
View all module resources, assignments, graded submissions, reports and
communications.
2.
Cannot edit anything and
3.
Cannot see hidden items.
4.
Cannot communicate with students.
5.
Leave comments for the module leader, which cannot be seen by students or other
teachers.
10
Students
Access Right:
1. View the module content, annotate it (for themselves) and comment on it (publically
for other students of the module).
2. Upload and re-upload assignments and participate in tests and quizzes.
3. See their own grades and test results, once they are published.
4. Communicate with other students, editing and non-editing teachers, programme
managers and Moodle administrators, but not with module creators and moderators.
5. Email cannot be switched off, but all other communication feature can be hidden by
the module leader.
6. Students can share files and documents with other students.
6. A knowledge base about the module content.
User Case:
Functional Requirement Description
Before initial this case, the tester has already login to the Moodle:
1. Student can use Wiki search function to search the online encyclopaedia resource.
11
7. A diary and a calendar
User Case:
Functional Requirement Description
Before initial this case, the tester has already login to the Moodle
1. Student and Teacher can use calendar with diary function to record the daily activity.
2. Student and Teacher can add / edit /delete activity.
4 External Interface Requirements
4.1 User Interface
In Moodle system there is one interface that users can interact. The user must register into
Moodle system and assign the user access right to define the user functionalities. The first page of
Moodle must be display the login page and ask the user to enter his/her username and password.
After login, it must display the course or subject he/she undertakes and all useable function.
4.2 Hardware Interface
There is no hardware interface requirement.
4.3 Software Interface
Moodle system is version 2.4. It should compatible browsers with Firefox 4, Internet Explorer 8 /
10, Safari 5 and Google Chrome 11. The server operation system is Ubuntu 12.1 and install
Apache2 web server. with PHP version 5.3.2. The system should use the database MySQL 5.1.33 to
connect Moodle server as database.
12
5 Technical Requirements (Non-functional)
5.1 Performance
Performance is very important for Moodle system. The system must be able to access and provide
all services and functions anytime. The system must be able to connect to MySQL database to query
the system data.
5.2 Availability
The Moodle system must be 24/7 availability. The application and database have a daily centralized
backup. All backup can be restored, once on system failure.
5.3 Capacity Requirements
The capacity of the system must be defined as the total number of users in concurrent system. It’s
including Student, Teacher, and University Staff who related the Moodle System. The system
software and hardware can be support 30% capacity expands in the future.
5.4 Security Requirements
All user personal data (e.g. personal information, assignment results….etc) is a confidential issue.
The Moodle system must be allowed authorized users login only. Therefore, the user account in the
system must be unique. All users must be registered and activated by the user account first. The
MySQL database is only permit the connection form Moodle System.
6 SPONSOR ACCEPTANCE
Approved by the Project Sponsor:
_________________________________________
Benson Kwong
<Project Sponsor Title>
13
Date: ___________________