Preliminary SRS

iLMS
Interactive Learning Management System
PRELIMINARY SOFTWARE REQUIREMENT SPECIFICATION

VERSION: 1.1 (REVISION DATE: 14/09/2009)
Documented by: Techno Fusion Committee

Name Appointment
Arnav Singh Team Leader
Lwi Tiong Chai Secretary
Tan Koon Liang Content Manager
Abdul Haleem SRS In-Charge
Liu Wei SRS Vetter
Hu Yuanling UML Diagram In-Charge

Wen ke UML Diagram Vetter
Biju Joseph Jacob Developer In-Charge
Approver Name Title Signature Date

Arnav Singh Preliminary SRS and 28/08/2009
(shadow client) Project Gantt
Arnav Singh Preliminary SRS and 14/09/2009
(shadow client) Project Gantt
i
TEAM 7 (Techno Fusion) Deliver software with precision and passion
SOFTWARE REQUIREMENT SPECIFICATION VERSION 1.1
Table of Contents
Project Quick Overview ....................................................................................................................... 1
1. Product Description ..................................................................................................................... 1
1.1 Product Vision ..................................................................................................................... 1
1.2 Business Requirements ....................................................................................................... 1
1.3 Stakeholders and Users....................................................................................................... 1
1.4 Project Scope ...................................................................................................................... 2
1.5 Assumptions ........................................................................................................................ 2
1.6 Constraints .......................................................................................................................... 3
2. Functional Requirements ............................................................................................................. 4
2.1 Student ................................................................................................................................ 4
2.2 Parent .................................................................................................................................. 4
2.3 Tutor .................................................................................................................................... 4
2.4 Administrator/Manager ...................................................................................................... 5
3 Non-Functional Requirements ..................................................................................................... 6
3.1 Development Requirements ............................................................................................... 6
3.2 Operational Requirements.................................................................................................. 6
4. Use Case Model............................................................................................................................ 7
4.1 Use Case Diagram ............................................................................................................... 7
4.2 Use Case Description .......................................................................................................... 8
4.3 Class Diagram .................................................................................................................... 15
5 Analysis Models.......................................................................................................................... 16
5.1 Sequence Diagram ............................................................................................................ 16
5.1.1 Registration ....................................................................................................................... 16
5.1.2 Create Course .................................................................................................................... 17
5.1.3 Register Course ................................................................................................................. 18
5.1.4 Download Course Material ............................................................................................... 19
5.1.5 Attend Online Course ........................................................................................................ 20
ii
5.1.6 View Progress Report ........................................................................................................ 21
5.1.7 Make Payment .................................................................................................................. 22
5.1.8 Course Schedule ................................................................................................................ 23
5.1.9 Upload Course Materials .................................................................................................. 24
5.1.10 Conduct Online Course Part 1 ....................................................................................... 25
5.1.11 Conduct Online Course Part 2 ....................................................................................... 26
5.1.12 Generate Report ........................................................................................................... 27
5.1.13 Update School Information ........................................................................................... 28
6. Committee Roles and Responsibilities .......................................................................................... 29
7. Enhanced Waterfall Incremental Model ....................................................................................... 34
8. Glossary ...................................................................................................................................... 36
9. References.................................................................................................................................. 36
10. Revision History .................................................................................................................... 36
Customized Project Gantt Chart.......................................................................................................... 1
iii
Project Quick Overview
The client is a tuition consortium which will adjudicate what system is best for individual
tuition agencies collaboration. Instead of relying on the natural course of business to
make decision for them, individual tuition agencies can leverage on the resources of our
client so that they will be accessible to highly efficient streamlined created through
economies of scale with common channels of communication and abundant
opportunities at the organization level. With its mission “Every student deserves the
best” and organizational objective such as developing elite students across the nation.
Our client constantly improves the academically challenged primary school students to
enable them to compete and excel in school.
The Interactive Learning Management System iLMS is a web solution to provide online
tuition service to individual tuition agency, which is designed to improve the
collaboration between tutor and the corresponding students.
1. Product Description
1.1 Product Vision
To provide innovative web solutions for tuition consortium in inducing 3E learning

elements to their primary school-level customers (tutee) - Enriching, Enhancing and
Exhilarating learning.
1.2 Business Requirements
The following are a list of the business requirements of inaugural iLMS implementation
 iLMS must be adopted by at least 60% of the tuition agencies within one year of
introduction.
 iLMS must cut operational cost of running an individual tuition agency by 15%
per year.
 At least 10 % of the total cost incurred developing iLMS should be earned within
one year of the development project launch.
1.3 Stakeholders and Users
The generic stakeholders of the iLMS are: Management, Developers and Users. The
board of the directors of the tution consortium and the CEO of TechnoFusion are
identified as the management. The eight-member iLMS development team are
identified as the developers, who will develop and market the product. The following
1
are the users of the iLMS: Student, Tutor, Parent and Central Management. Their roles
of the users are listed in Table 1.
Type of User Location Nature of Use

Student Any location that has a The students will use the iLMS to register
PC with internet course, participate in online courses,
connection download course materials and provide
feedback.
Tutor Any location that has a The tutor will publish course schedule,
PC with internet upload course materials and conduct online
connection courses.
Parent Any location that has a With iLMS parents will be able to make
PC with internet payment, view progress report of their child
connection and also provide feedback.
Central Tuition Consortium The staff of the tuition consortium will
Management manage tuition agency,tutor and student
informations
Table 1: Roles of user of the iLMS
1.4 Project Scope
The iLMS is designed for better interaction developed exclusively for simplifying
agencies management procedures between students, tutors, parents and the tuition
agencies. This management software gracefully handles all the requirements for the
agencies. The system being web based can be accessed from anywhere in the world
which enables the students, tutors, parents and the tuition agencies to be in touch with
each other at all times and keeps the lines of communication open.
The iLMS being an online interactive community portal provides state-of-the-art online
interactive portal which will enhance the efficiency of agencies administration and
improve resource optimization, thus raising the standards of tuition agencies nation-wide.
This brings the community together on a common interactive platform thereby fostering
camaraderie among them.
1.5 Assumptions
 All primary school students have basic knowledge on how to use the computer and
internet.
 All students will have an email address.
 All guardians are considered as parent.
 The tuition consortium will handle all the financial transactions.
2
1.6 Constraints
 We have to rely on the bank to handle the financial transaction between the parent and
the tuition consortium.
 For full working the iLMS requires internet connection.
3
2. Functional Requirements
2.1 Student
The following functional requirements have been identified for the students using the
system:
 The user will register with the system by providing personal information such as
email address, password, age, school and etc and this information will be stored
in the database.
 The student will be able to see their own profile page e.g. their personalized
profile page with course registered details, tuition center details and schedule
information, when they login to the system
 Student can add courses to the system provided there is no conflict in timing.
This will be reflected on the student course schedule.
 When the student presses the download link. The student will be able to
download all the relevant course materials.
2.2 Parent
The following functional requirements have been identified for the parents using the
system:
 Upon request from parents, the system must produce the progress report
corresponding to the student.
 Upon a successful payment, the system will send an electronic receipt to the
parent email address.
2.3 Tutor
The following functional requirements have been identified for the tutors using the
system:
 The tutor will upload the relevant course materials to the students whom
registered to the course he/she will be teaching.
 Upon successful assessment, the tutor will submit the progress report through
the system.
 Depending on availability each tutor will upload his/her schedule according to
the courses that they will teach.
4
 Upon successful registration of courses by students, the tutors will conduct the
online course.
2.4 Administrator/Manager
The following functional requirements have been identified for the administrator/
manager using the system:
 Upon request from manager, the system must produce monthly or yearly
academic report such as financial, staffing, and enrollments in HTML format.
 If there any amendments that needs to be made, the administrator will do the
necessary updates to the system.
5
3 Non-Functional Requirements
3.1 Development Requirements
The following are a list of the development requirements that has been identified during
our meet the client session:
 The program should be extensible and scalable so that new features can be
added to the system fairly easily without any large change throughout the
system.
 The website should be executable on Smartphones so that user can conveniently

access the system.
 The user interface should be user friendly to ensure that it is more efficient to
use and easier to learn.
 The database should be backup regularly so that when the database fails another
database can be restored with the latest backup and operations be restored as
quickly as possible.
 Each module in the program should be extensively tested to ensure that the core
functionality of the system is error free, if there is any error it should be rectified
immediately upon detection.
 The software should be compatible with the dozen of web browsers out there in
the market.
3.2 Operational Requirements
The following are a list of the operational requirements that has been identified during
our meet the client session:
 When the user log-in to the system. The system must respond within 8 seconds
with the appropriate webpage for that user and it should display confirmation
message to users within 4 seconds after the user submits information through
the system.
 The system should not lag in performance if the number of students accessing
the database increase dramatically, hence the database should accommodate a
large pool of users for instance – 1000 users concurrently accessing the system.
 Confidential data such as student quiz results should be encrypted or stored in a

secure location with strict access control and users should be prompted to
change their passwords once every 90 days.
 The users should be able to access their accounts 24 hours per day, 7 days a
week and there should be minimal server downtime as to optimize the
performance for the user.
6
4. Use Case Model

4.1 Use Case Diagram
Figure 1: Use Case Diagram of iLMS
7
4.2 Use Case Description
Use Case ID: 1

Use Case Name: Register As Member
Created By: HU YUANLING Last Updated By: WEN KE
Date Created: 26/08/09 Date Last Updated: 12/09/09
Actors: Student/Parent/Tutor
Description: To allow students, parents and tutors to create membership
account.
Trigger: -
Preconditions: -
Postconditions: System will send an email with the user log-in information to the
student.
Normal Flow: 1. User clicks the “Register Now” button on the main menu.
2. User can choose to register as a Student/Parent/Tutor from
the scroll down bar.
3. System displays a form to prompt the user to key in his
personal information such as id, password, name, email, and
school name.
4. User fills the form by keying in the necessary information.
5. System verifies all the information provided by the student.
6. System adds user information into the database.
Use Case ID: 2

Use Case Name: Register Courses
Actors: Student
Description: To allow student to register for the courses that he/she is
interested in.
Trigger: -
Preconditions: Student must log into the system with valid user name and
password.
Postconditions: System will display a confirmation page for the course registered.
Normal Flow: 1. Student selects “Register by course” or “Register by tutor” on
his own homepage.
2. Student clicks on the “Register by course” button.
3. System displays all the time slots and available tutor names.
4. Student ticks the box in front of the course name with the
most suitable time and select the ideal tutor from the scroll
down bar.
8
5. Student clicks on the Register button on the page.

6. System prompts a message with the course ID, time and tutor
name for student to confirm.
7. Student pressed Confirm button to continue.
8. System prompts a message to show the course has been
successfully registered.
9. Student clicks Ok to go back course info page.
10. System adds the register information to the database.
Alternative Flow 2.1: 1. Student clicks on the “Register by tutor” button
2. System displays all the tutor names with a course name
dropdown list.
3. Student ticks the tutor that he wants to register with and
chooses the courses he like from the scroll down bar.
4. Go back to step5 (Normal Flow).
Alternative Flow 2.2: 1. Do step5 (Normal Flow).
2. System prompts warning message when there is a clash of
time on registered course.
3. Student clicks ok
4. System displays the previous register course page.
Use Case ID: 3

Use Case Name: Download Course Material
Actors: Student
Description: To allow student to download course material before tuition class.
Trigger: -
Preconditions: Student must log into the system with valid user name and
password.
Postconditions: -
Normal Flow: 1. Student clicks “My Courses” button on his login homepage.
2. System displays all the course names that the student has
registered categorized by tuition centre names.
3. Student clicks the corresponding course name.
4. Student clicks the “Download material” button
5. System displays all the documents belongs to the selected
course.
6. Student clicks the document.
7. System prompt the user to choose save or open or cancel.
8. Student clicks save.
9
Use Case ID: 4

Use Case Name: Attend Online Course
Actors: Student
Description: To allow student to participate the online courses so that he/she
can interact with the tutor.
Trigger: -
Preconditions: 1. Student must log into the system with valid user name and
password.
2. Both computers from student and tutor must fulfill system
requirements for online tutoring.
Postconditions: Student attendance will be marked
Normal Flow: 1. Student clicks “My Course” button on his login homepage.
2. Student clicks the course name that he is going to have class.
3. Student clicks “Start Class” button
4. System opens a video window with a request sent to notify
tutor.
5. Wait tutor to accept the request
6. Once accepted, the online class will start.
Use Case ID: 5

Use Case Name: View Progress Report
Actors: Parent
Description: View students’ progress report
Trigger: -
Preconditions: Parent log into the system with student name.
Postconditions: -
Normal Flow: 1. Parent clicks View Progress Report button on his homepage.
2. System displays reports by chronological order.
3. Parent clicks on the date he wants to view.
4. System does the search from the database and displays the
result.
10
Use Case ID: 6

Use Case Name: Make payment
Actors: Parent
Description: Allow parent to make payment online for the student.
Trigger: Student has already selected the course or the package he/she
wants to participate.
Preconditions: Student and parent have registered with the system.
Postconditions: A confirmation email of payment details will be sent to the student
email account.
Normal Flow: 1. Parent logs into the system with his user ID and password.
2. System displays the bill statement with all the courses
registered by the student and total amount followed by
payment method.
3. Parent checks the list and make payment.
4. Once payment received, system will generate a receipt to
parent’s email account.
Use Case ID: 7

Use Case Name: Upload Class Schedule
Actors: Tutor
Description: Tutors can publish their own class schedule so that the student can
view and choose a time slot.
Trigger: -
Preconditions: Tutor login the system with valid user name and password.
Postconditions: -
Normal Flow: 1. Tutor clicks Upload class schedule button on his homepage.
2. System displays all possible time slots and a dropdown list to
show all the course index numbers followed by course name.
3. Tutor ticks the box in front of the time and select the course
he’s going to teach from the dropdown list.
4. System prompts tutor for confirmation.
5. Tutor double check the timeslot and click the confirm button.
6. System adds this information into database for student to
register.
11
Use Case ID: 8

Use Case Name: Upload Course Material
Actors: Tutor
Description: To allow to tutors to upload course materials.
Trigger: -
Preconditions: Tutor log into the system with valid user name and password.
Postconditions: Message displays on the student login page to notify them
Normal Flow: 1. Tutor clicks “Upload Course Material”.
2. System displays all the courses that particular tutor teaches.
3. Tutor clicks on a course name.
4. System displays a page with the space for upload and textbox
to key in the document name together with an upload button.
5. Tutor selects document from his computer.
6. Tutor clicks upload button.
7. System adds the document into the server.
Use Case ID: 9

Use Case Name: Conduct Online Course
Created By: WENKE Last Updated By: WEN KE
Actors: Tutor
Description: To allow tutor to start online course.
Trigger:
Preconditions: 1. Tutor must login system with valid user name and password.
2. Both computers from student and tutor must fulfill system
requirements for online tutoring.
Postconditions: Tutor attendance will be marked.
Normal Flow: 1. Tutor clicks “Conduct online Course” button.
2. System displays all the courses he teaches categorized by
tuition centre.
3. Tutor clicks the course name that he is going to have class.
4. Tutor clicks “Start Class” button.
5. System opens a video window with a request sent to notify
student.
6. Wait student to accept the request.
7. Once accepted, the online class will start.
12
Use Case ID: 10

Use Case Name: Submit Students’ Reports
Created By: WENKE Last Updated By: WEN KE
Actors: Tutor
Description: Tutor can summit individual student’s reports to parent for
viewing
Trigger: -
Preconditions: Tutor must log into system with valid user name and password
Postconditions: Message displays on parent and student login page
Normal Flow: 1. Tutor clicks “Submit Report” button.
2. System displays a file format page.
3. Tutor select student’s name from dropdown list and write
comments in the text box.
4. After completing the comments, tutor clicks submit button
below.
5. System deposits report under student and parent database, so
they can view this report when they login.
6. System will display a message on the student and parent
homepage to notify them.
Alternative Flow 10.1: 1. Do step3(Normal flow)
2. After completing the comments, tutor clicks save button to
save this as a draft for future modification.
3. System returns back to submit report page.
4. Go back step2(Normal flow)
Use Case ID: 11

Use Case Name: Update School Information
Created By: WEN KE Last Updated By: WEN KE
Actors: Administrator
Description: Administrators maintain system performance and manage the
system information.
Trigger:
Preconditions: Staff must log into system with valid user name and password.
Postconditions:
Normal Flow: 1. Staff clicks update school information button.
2. System converts the school information into text format.
3. Staff edit the content and click update.
4. System will update and display the edited context on the main
site.
13
Use Case ID: 12

Use Case Name: View Reports
Created By: WEN KE Last Updated By: WEN KE
Actors: Manager
Description: Manager can view different types of school reports
Trigger:
Preconditions: Manager must log into system with valid user name and password
Postconditions:
Normal Flow: 1. Manager chooses the report type he wants to view from the
reports dropdown list, such as financial report, student report,
attendance report.
2. System opens a new page to ask manager to select course
name/tuition centre/tutor if requests student list. If requests
financial report, system can ask the period he wants to view.
3. System generates the report and displays it accordingly.
14
4.3 Class Diagram
Figure 2: Class Diagram of iLMS
15
5 Analysis Models
5.1 Sequence Diagram
5.1.1 Registration
Figure 3: Sequence Diagram: Registration
Figure 3 shows:
1) User submits personal information to Register Controller.

2) RegisterController register user information into the database.
3) The database returns acknowledgment to RegisterController.
4) RegisterController create a student object.
5) Student object will get the information from the database.
6) The database returns student information.
7) RegisterController returns.
16
5.1.2 Create Course
Figure 4: Sequence Diagram: Create Course
Figure 4 illustrates:
1) TuitionCenter creates CourseController object.

2) CourseController will add the course to the database.
3) The database returns acknowledgment.
4) CourseController will create course object
5) Course object will get all the course information.
6) The database returns the course information.
7) The course object returns.
17
5.1.3 Register Course
Figure 5: Sequence Diagram: Register Course
Figure 5 displays:
1) Student creates the StudentController object.

2) StudentController get account information from the database.
3) The database returns the course payment status.
4) If Payment is successful we will update the course in the database.
5) The database will send an acknowledgment to the StudentController.
6) The StudentController returns.
18
5.1.4 Download Course Material
Figure 6: Sequence Diagram: Download Course Material
Figure 6 shows:
1) Student create CourseController

2) CourseController will retrieve all the document links.
3) The database returns the result
4) CourseController will then download the relevant course materials from the database.
5) The database returns the materials.
6) The CourseController returns.
19
5.1.5 Attend Online Course
Figure 7: Sequence Diagram: Attend Online Course
1) Student create CourseController object

2) Tutor creates another CourseController object.
3) Student CourseController will request to attend online course.
4) Tutor CourseController will accept the request.
5) Student CourseController will return.
20
5.1.6 View Progress Report
Figure 8: Sequence Diagram: View Progress Report
Figure 8 displays:
1) Parent creates ReportController.

2) ReportController create Report object
3) The report object will get all the relevant information from the database.
4) The database returns the results.
5) The report object returns.
6) The ReportController returns.
21
5.1.7 Make Payment
Figure 9: Sequence Diagram: Make Payment
1) Parent create PaymentController.

2) PaymentController will get bill information from the database.
3) The database returns the result
4) The payment details will be reflected to the parent.
5) The parent will make payment and PaymentController will make the necessary
amendments to the database.
6) The database returns acknowledgement.
7) The PaymentController returns.
22
5.1.8 Course Schedule
Figure 10: Sequence Diagram: Courses Schedule
Figure 10 shows:
1) Tutor create Course schedule object.

2) The course schedule object will get the entire course until there is no course left in the
database.
3) If there is no conflict in the time schedule the course schedule object will add the
course.
4) The course schedule object will update the information in the database.
5) The course schedule object returns.
23
5.1.9 Upload Course Materials
Figure 11: Sequence Diagram: Upload Course Materials
Figure 11 displays:
1) Tutor upload course document by create Course Controller.

2) Course Controller will upload Course Document in database.
3) Then Course retrieves all Course documents from database.
24
5.1.10 Conduct Online Course Part 1
Figure 12: Sequence Diagram: Conduct Online Course Part 1
Figure 12 shows:
1) When the Tutor join Online Course through create the Course Controller and attend
Course, Course will set this Tutor as Tutor who conducts this Course.
2) Course Controller will be informed that tutor already be set.
3) Tutor also gets notification from Course.
Alt:
1) When the Tutor leave Online Course through create the Course Controller and leave
Course, Course will set Null as Tutor who conducts this Course.
2) Course Controller will be informed that tutor already remove.
3) Tutor also gets notification from Course.
25
5.1.11 Conduct Online Course Part 2
Figure 13: Sequence Diagram: Conduct Online Course Part 2
Figure 13 shows:
1) When the Tutor join Online Course through create the Course Controller and retrieve all
information from database and active Course,
2) Course Controller will check whether the Course is available and be active and wait for
any request.
3) If there is a request, update course status to be active.
26
5.1.12 Generate Report
Figure 14: Sequence Diagram: Report generated
Figure 14 shows:
1) Manager creates Report Controller.

2) ReportController object gets all relevant information from database.
3) The database returns the result.
4) Report Controller generates the report based on the information returned from the
database.
5) Report Controller also to create Report object.
6) Report object will retrieve all Report information from database.
7) The database returns the result.
27
5.1.13 Update School Information
Figure 15: Sequence Diagram: Update School Information
Figure 15 shows:
1) Administrator updates all data in database.

2) The database returns acknowledgement.
28
6. Committee Roles and Responsibilities
Name/Title Role
He is in-charge of the project and he reports to the
Arnav Singh / Team leader
higher management regarding the status of the project.
He also delegates task to the team members.
Responsibilities
 Set up a detailed development timeline with some flexibility and ensures that the
overall benchmarks must remain fairly consistent in order to finish up the project on
the projected date.
 Help keep the team focused and on track.
 Provide the team with a vision of the project objectives.
 Ensures that if challenges arise with meeting a specific deadline, other deadlines will
be shifted to accommodate the change, as long as there are ample time and
resources to make the change.
 Strive for team consensus and win-win agreements.
 Helping the group focus on its own process of working together so that it may
become more effective rather than being trapped by faulty ways of problem solving
and decision making.
 Ensure discussions and decisions lead toward closure.
 Helping the group decide on its purposes and goals.
 Coordinate the review, presentation and release of design layouts, drawings,
analysis and other documentation.
 Approve the documents and work done by team members.
 Facilitate problem solving and collaboration.
Name/Title Role
Prepare for meeting and integrating all the essential
Lwi Tiong Chai / Secretary
documents for submission as well as coordinating and
delegating task to team members. He also maintains the
minutes after every group meetings and also undertakes
the sub-role of a SRS facilitator.
Responsibilities
 Responsible for informing the team about upcoming meetings to discuss project
impediments and/or distributing information (e.g., agendas, minutes, etc.) to
members ahead of time and providing materials in accessible formats.
 Support team leaders and members in understanding their roles and responsibilities
before any meetings begin.
29
 Responsible for moving the team efficiently through the process of the team
meeting to make sure that the work allocation is done effectively.
 Participate in regular meetings to discuss team development progress, establish
timelines, and responsibilities assigned to various team member and plan agenda for
future meetings.
Sub-Roles
 Research and analyze the information regarding the Software Requirement

Specification.
 Will assist and collaborate with the SRS In-charge team member.
Name/Title Role
Maintain the developer blog and also ensure that the
Tan Koon Liang / Content
Manager content in the blog is updated regularly and up-to-date.
He maintains the blog and also undertakes the sub-role
of a web designer.
Responsibilities
 Familiarize the team with the specifications, design targets, the development
process, design standards, techniques and tools to support task performance.
 Create, revise, and share team information, with the advice and consultation of
team leader in accordance with the deadlines in hand.
 Review the materials on the blog, set up discussion forum topics and post any
necessary team announcements online.
Sub-Roles
 Design the iLMS website, including team banner, logo, style sheet, and other design-
related components and also advise on technical and visual elements.
 Ensures that the design of the graphical user interface of the website fulfills the
client requirements.
30
Name/Title Role
He is the main person in-charge of the Software
Abdul Haleem / SRS In-
Charge Requirement Specification (SRS) and also undertakes the
role of a facilitator to ensure that the team vision and
objectives is met.
Responsibilities
 Ensures that the Software Requirement Specification (SRS) are developed in a timely
fashion.
 Work with secretary to revise design, structure activities and/or other assessments
in the SRS to make improvements for subsequent delivery.
 Documenting the efforts of the group, including summaries of decisions, action
items (or assigned tasks), and deadlines.
 Co-ordinate and collaborate with other team member to ensure information
regarding the SRS are relevant to the project.
 Research and analyze the information regarding the project.
 Take note of the needs and desires of the stakeholders.
Name/Title Role
He will vet and verify the Software Requirement
Liu Wei / SRS Vetter
Specification (SRS) and also undertakes the sub-role of a
UML diagram developer.
Responsibilities
 Design and develop learning objects in collaboration with the development team.
 Ensures the Design goals – Performance, Modularity, Reliability, Maintainability,
Reusability, Internationalization and Accessibility – are met.
 Solve problems and eliminate barriers that may arise from the technical perspective.
 Coordinate formative and summative evaluations of the development process
during and after its first delivery.
 Regularly review the SRS and make sure that the information is relevant.
 Provide feedback to the SRS IC.
Sub-Roles
 Assists the UML Diagram in-charge team member for the development of UML
diagrams for the SRS.
31
Name/Title Role
She is the main person in-charge of the UML models,
Hu Yuanling / UML Diagram
diagrams and descriptions.
In-Charge
Responsibilities
 Facilitates technical decision; incorporates feedback and emergent patterns from
the team back in to the overall design.
 Informing the group of the beginning time and ending time, allowing enough time
for the members to begin and come to an end to the discussion.
 Indicating when the group is using more time than available on one issue and
remind them of the number of tasks and time remaining.
 Helping the team use its time on issues on which the whole team is needed.
 Produce and ensure the diagrams for the SRS such as UML activity, use case, class,
object and package diagrams and their corresponding descriptions.
 To produce the Software Design Document.
Name/Title Role
She will vet the UML models, diagrams and descriptions.
Wen ke / UML Diagram
Vetter
Responsibilities
 Responsible for end-to-end cross functional system design and communication.
 Actively clarifying the group’s progress by using strategies such as summarizing and
seeking.
 Helping the group evaluate its progress and development.
 Verify and validate preliminary and final design.
 Provide feedback to Diagram IC.
Name/Title Role
He is the main person in-charge of the implementation of
Biju Joseph Jacob / Developer
IC the design of the software.
Responsibilities
 Provide technical expertise and spearhead the development of the software.
 Consolidation and integration of all the source code.
 Produce and regularly update the technical documentation.
 Ensures technical cohesion and helps write the technical contract in interface other
abstract objects and data entities.
32
 Leads design review & provides feedback.
Sub-Roles
 Assists the UML Diagram in-charge team member for the development of UML
diagrams for the SRS.
33
7. Enhanced Waterfall Incremental Model

(Customized model component for team productivity, quality and efficient process flow)
Gantt chart
Iterative
Process
Blog
Iterative
Documentation Process
Prototype and software delivery
Customised Project Gantt– A customised project gantt chart is drafted to illustrate the
project schedule for our team – Techno Fusion, delivering software with precision and
passion. The Gantt chart consist of the work breakdown structure of the project based on
the software model adopted, client meeting date so that we will be to check our progress
and be in due course in completing our project. The management will progressively
update the schedule to meet the demand of the client.
Content Management @ Blog – Techno Fusion blog is setup as a platform for team
members to synchronise information, updating each other of progress and milestones.
Techno Fusion management has devised a strategy to effectively organise contents in the
blog.
1) Deliverables Folder (contains deliverables documents for clients and team

members)
2) Source Folder (contain all documents to produce deliverables)
We will also using the platform as a communication tool to collaborate and make
announcements for instance - leader broadcasting milestones. The URL for the blog is as
follows: http://ilmsystem.blogspot.com/
34
Documentation – We believe the importance of documentation - describe the progress of

software development and as we adopted SDLC and Gantt chart closely. It serves as a
tool to also inform and guide team members on the project current status ensure that the
progress is smooth throughout the software development phase.
35
8. Glossary
Term Definition
Administrator Consists of staff at the consortium that manages the iLMS.
Course They are subjects offered by the tuition centers.
Course Schedule The timing information of the course offered.
Feedback Information provided by the user to the system.
Manager These are the management at the tuition consortium.
Parent Parent of the student that interacts with the iLMS.
Report Consolidated information that needs to be presented to parents and
managers.
Student Student that uses the iLMS to fulfill their tuition needs.
Tutor Tutors are an agency staff member that teaches the students.
Tuition Consortium A consortium that manages a list or a group of tuition agencies.
Tuition Center A agency that provides resources to tutor academically challenge
students.
9. References
Document No. Document Title Date Author

1. Introduction to Software Engineering 20/08/2009 Christoper Fox
Design Processes,Principles, and Patterns
with UML2
2. UML Distilled Third Edition 20/08/2009 Martin Fowler
10. Revision History
Version Date Name Description

1.0 28/08/2009 Preliminary SRS Requirement analysis from client
1.1 14/09/2009 Preliminary SRS Requirement analysis from client
36
Customized Project Gantt Chart v1.1
A S O
U E C
G Week 3 P Week 4 Week 5 Week 6 Week 7 Week 8 T Week 9 Week 10 Week 11 Week 12
PROJECT Team SEVEN - GANTT CHART M T W T F . . M T W T F . . M T W T F . . M T W T F . . M T W T F . . M T W T F . . M T W T F . . M T W T F . . M T W T F . . M T W T
Updated: 26 Aug 09 2 2 2 2 2 2 3 3 0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2
Project Lead/CEO Arnav Singh 4 5 6 7 8 9 0 1 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9
Version 1.1
SOFTWARE DEVELOPMENT
INCEPTION PHASE C1 C4 C3 C5 C4 C4 C5 C5 C5 C5 C5 C5 C5 C5
CLIENT / TEAM INTERACTION
C1 - Team Establishment and Proposal C1 website setup website update website update website update website update website update
C2 - Client Requirement Handoff C2
C3 - Client Approval (Signoff Contract) C3 C3
C4 - Team Discussion with Client C4 C4 C4 C4 C4 C4 C4 C4 C4 C4
C5- Team Leader task Allocation and Debrief C5 C5 C5 C5 C5 C5 C5 C5 C5 C5 C5
C6 - Team Project Schedule (refining project schedule)
ELABORATION PHASE E1 E2 E1
(DETAILS ACQUIRING)
E1 - Use Case Diagram E1 E1
E2 - Use case System Specifications E2 E2
CONSTRUCTION PHASE
(BETA-VERSION DEVELOPMENT)
REQUIREMENT ANALYSIS R1 R2 R3 R4 R5
R1 - Understanding user needs / problems R1
R2 - Adopting System Model Approach R2
R3 - Software Requirements Specifications R3
R4 - Class Diagrams R4
R5 - Sequence Diagrams (optional) R5
DESIGN D1 D2 D3 D4
(Preliminary Design Stage)
D1 - Data Design D1
D2 - Architectural Design D2
D3 - GUI (Human Computer Interaction) D3
(Detailed Design Stage)
D4 - Refine Preliminary Design D4
D5 - Procedural Design D5
IMPLEMENTATION
I1 - Converts Design Model to source I 1 AND 1 2 IMPLEMENTATION
l2 - Converts source to compilation
TESTING T1
T1 - Unit Testing and Integration
TRANSITION PHASE TR1 and TR2

TR1 - Minor Code Improvement TR1
TR2 - Fix Bug and Refining Functionality TR2
Lab Schedule / Consultation with Prof Malcolm

(Invite Prof Malcolm to website) S3
TEAM Presentation and Report Submission 1

fixups client requests after submission?

Preliminary SRS

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Preliminary SRS

Uploaded by

Copyright:

Available Formats

iLMS

Interactive Learning Management System

PRELIMINARY SOFTWARE REQUIREMENT SPECIFICATION

Documented by: Techno Fusion Committee

Tan Koon Liang Content Manager

Abdul Haleem SRS In-Charge

Liu Wei SRS Vetter

Hu Yuanling UML Diagram In-Charge

Biju Joseph Jacob Developer In-Charge

Approver Name Title Signature Date

1. Product Description ..................................................................................................................... 1

1.1 Product Vision ..................................................................................................................... 1

1.2 Business Requirements ....................................................................................................... 1

1.3 Stakeholders and Users....................................................................................................... 1

1.4 Project Scope ...................................................................................................................... 2

1.5 Assumptions ........................................................................................................................ 2

1.6 Constraints .......................................................................................................................... 3

2. Functional Requirements ............................................................................................................. 4

2.1 Student ................................................................................................................................ 4

2.2 Parent .................................................................................................................................. 4

2.3 Tutor .................................................................................................................................... 4

2.4 Administrator/Manager ...................................................................................................... 5

3 Non-Functional Requirements ..................................................................................................... 6

3.1 Development Requirements ............................................................................................... 6

3.2 Operational Requirements.................................................................................................. 6

4. Use Case Model............................................................................................................................ 7

4.1 Use Case Diagram ............................................................................................................... 7

4.2 Use Case Description .......................................................................................................... 8

4.3 Class Diagram .................................................................................................................... 15

5.1 Sequence Diagram ............................................................................................................ 16

5.1.1 Registration ....................................................................................................................... 16

5.1.2 Create Course .................................................................................................................... 17

5.1.3 Register Course ................................................................................................................. 18

5.1.4 Download Course Material ............................................................................................... 19

5.1.5 Attend Online Course ........................................................................................................ 20

5.1.6 View Progress Report ........................................................................................................ 21

5.1.7 Make Payment .................................................................................................................. 22

5.1.8 Course Schedule ................................................................................................................ 23

5.1.9 Upload Course Materials .................................................................................................. 24

5.1.10 Conduct Online Course Part 1 ....................................................................................... 25

5.1.11 Conduct Online Course Part 2 ....................................................................................... 26

5.1.12 Generate Report ........................................................................................................... 27

5.1.13 Update School Information ........................................................................................... 28

6. Committee Roles and Responsibilities .......................................................................................... 29

7. Enhanced Waterfall Incremental Model ....................................................................................... 34

10. Revision History .................................................................................................................... 36

Customized Project Gantt Chart.......................................................................................................... 1

To provide innovative web solutions for tuition consortium in inducing 3E learning

1.2 Business Requirements

Type of User Location Nature of Use

Table 1: Roles of user of the iLMS

1.4 Project Scope

 The website should be executable on Smartphones so that user can conveniently

3.2 Operational Requirements

 Confidential data such as student quiz results should be encrypted or stored in a

4. Use Case Model

Figure 1: Use Case Diagram of iLMS

4.2 Use Case Description

Use Case ID: 1

Use Case ID: 2

5. Student clicks on the Register button on the page.

Use Case ID: 3

Use Case ID: 4

Use Case ID: 5