Course Builder
Requirements Definition
Version:
0.1
Date: 2006-11-14
Course Builder
Requirements Definition
Version 0.1
Page 1
Doc. No.:
Course Builder
Requirements Definition
Version:
0.1
Date: 2006-11-14
Revision History
Date
2006-11-14
Version
0.1
Description
Initial Draft
Author
Svebor Prstačić
Page 2
Course Builder
Requirements Definition
Version:
0.1
Date: 2006-11-14
Table of Contents
1.
2.
Introduction
4
1.1
1.2
1.3
1.4
Purpose of this document
Intended Audience
Scope
Definitions and acronyms
1.4.1 Definitions
1.4.2 Acronyms and abbreviations
1.5 References
4
4
4
4
4
4
5
Requirements Description
6
2.1
2.2
2.3
2.4
2.5
3.
Introduction
General requirements
Specific requirements 1
Specific requirements 2
Others
Use Case Models
3.1
Use case model 1
3.1.1 Use case “xy” (example: delete user)
3.1.2 Other use cases
3.2 Use case model 2
4.
5.
6
6
6
Error! Bookmark not defined.
Error! Bookmark not defined.
7
Error! Bookmark not defined.
Error! Bookmark not defined.
Error! Bookmark not defined.
Error! Bookmark not defined.
Requirements Definition
10
4.1
4.2
4.3
10
10
10
11
Requirement Group Definitions
Requirement Sources
Requirements definitions
4.3.1 Change Log
Future Development
5.1
5.2
5.3
General Overview
Specific group 1
Specific group 2
11
11
11
Error! Bookmark not defined.
Page 3
Course Builder
Requirements Definition
Version:
0.1
Date: 2006-11-14
1.
Introduction
1.1
Purpose of this document
In this document, all the planned features and options of the application that this project will yield will
be described to details.
1.2
Intended Audience
Intended audience is:
 customers – who want to know what they ordered will be what they get;
 supervisors – who need to know the scope and plan of the project;
 developers – who will have a document that lists the work to be done.
1.3
Scope
This document will give a detailed description of scenarios which occur when using wanted
functionalities of the project.
1.4
Definitions and acronyms
1.4.1
Definitions
Keyword
Course designer
Definitions
A user role for the application A user with that role is able to use
all the functionalities of the application, except user and system
management. Course designer can be a teacher.
Administrator
A super user. Can add, remove users; design, delete, edit courses;
change application settings.
Course participant
Can view reports for the courses, cannot change any data. This
user can be a teacher assistant.
Course type: Online A course that involves only online activities and resources: online
course
lectures; online tests; online discussions (forum…) etc
Course type: Mixed- A course that involves human contact activities and material
mode course
resources, but also has online features and resources available
(something like DSD)
Course type: Offline Offline only activities: lectures; laboratory; tests; no activities and
course
no resources online
Objective types
- Knowledge; comprehension; application; analysis; synthesis;
evaluation – extensive definition of each one available :
http://www.coun.uvic.ca/learn/program/hndouts/bloom.html
1.4.2
Acronyms and abbreviations
Acronym or
Abbreviation
Definitions
Page 4
Course Builder
Requirements Definition
1.5
Version:
0.1
Date: 2006-11-14
References
Page 5
Course Builder
Requirements Definition
Version:
0.1
Date: 2006-11-14
2.
Requirements Description
2.1
Introduction
The customer has ordered an application that enables and helps design courses. In general, it should be
an application that facilitates making decisions in course design. Given it’s purpose, it will probably be
of most use to teachers.
2.2
General requirements
Generally, the customer has ordered a web application that enables users to design as many courses as
they want.
The application should have three (3) user roles available: Administrator, Course designer and Course
participant. User roles define what options are available for the user when she/he logs in. Administrator
user has all the options available, Course designer less, and Course participant least.
When designing a single course, the application should allow it to be done by multiple users at once.
The application should implement an old-style web page design (user interface) and option to use the
Web 2.0 style that is more graphical.
The application should warn the user of crucial mistakes like prerequisites in a loop, no activity
workload defined etc.
2.3
Specific requirements 1
When creating a new course, the user is presented with a “Wizard” that guides him through entering
some initial course data. That is:
 Course title;
 Course type;
 Course description;
 Optionally enter some workload specification like overall workload for himself, the assistants
or students, which is used internally by the application to warn the user if he crosses the
desired value during design;
 Select objectives’ types and enter their titles and notes on those objectives.
2.4
Specific requirements 2
After the wizard completes, the user has the base of the course made, and is taken to the “Edit course”
page. That page enables the user to add topics, connect those topics to objectives, and add general
resources to the course, without specifying their use for any particular activity.
2.5
Specific requirements 3
For each topic the user creates, he is offered an option “Edit activities”. Choosing this option takes the
user to the “Edit activities” page. On that page, the user is able to add activities for the selected topic.
Activities that can be added, that the application offers are offered depending upon the course type and
objective type. Custom activities can also be added, but for those, the user has to select which objective
type that kind of activity can achieve, and which type of activity it is online or offline.
Also, he can connect resources to activities he makes:
 from a built-in predefined list that is generated by the application depending upon the course
type and objective type of the topic;
 from a list of unconnected resources he added while editing topics
 add a new custom resource (exp: he needs to hire a bus to go to excursion)
 enter the workload for the activity ( three (3) values: for the teacher; for the assistant and for
the students(workload per student) )
Page 6
Course Builder
Requirements Definition

Version:
0.1
Date: 2006-11-14
enter the grading priority for the activity
3.
Use Case Models
3.1
Course Designer
3.1.1
Manage Courses
Initiator:
Course Designer
Goal:
Manage Courses (Create courses, Design course)
Main Scenario:
1. User selects the manage courses from the menu
2. User selects create or design course
3. System opens the page for create or design course as selected by the user
3.1.2
Manage Activities
Initiator:
Course Designer
Goal:
Manage Activities (Add Activity, Delete Activity, Edit Activity, etc.)
Page 7
Course Builder
Requirements Definition
Version:
0.1
Date: 2006-11-14
Main Scenario:
1. User selects the manage Activities from the menu
2. User selects Add Activity, Delete Activity and Edit Activity
3. System opens the page for Add Activity, Delete Activity and Edit Activity
3.1.3
Manage Topics
Initiator:
Course Designer
Goal:
Manage Topics (Add Topic, Delete Topic, Edit Topic, etc.)
Main Scenario:
1. User selects the manage Activities from the menu
2. User selects Add Topic, Delete Topic and Edit Topic
3. System opens the page for Add Topic, Delete Topic and Edit Topic
3.1.4
Manage Version
Initiator:
Course Designer
Goal:
Manage Version (Freeze Topic, Freeze Course, etc.)
Main Scenario:
1. User selects the manage version from the menu
2. User selects Freeze Topic, Freeze Course
3. System opens the page for Freeze Topic, Freeze Course
3.1.5
Manage Workload
Initiator:
Course Designer
Goal:
Manage Workload (Freeze Topic, Freeze Course, etc.)
Main Scenario:
1. User selects the manage version from the menu
2. User selects Freeze Topic, Freeze Course
3. System opens the page for Freeze Topic, Freeze Course
Page 8
Course Builder
Requirements Definition
Version:
0.1
Date: 2006-11-14
// Use case description to be completed
3.2
Administrator
Add Users
<<include>>
Delete
Delete User
User
<<include>>
Login
Administrator
<<include>>
Edit user info
(roles, name, …)
Page 9
Course Builder
Requirements Definition
Version:
0.1
Date: 2006-11-14
4.
Requirements Definition
4.1
Requirement Group Definitions
Identification
CC
DC
VM
UM
WM
RT
UA
AC
RM
4.2
Requirement Group
Create the Course
Designing the Course
Version Management
User Management
Workload Management
Report
Users Administration
Application Core
Resources Management
Requirement Sources
Source
Description
Rem.
Ivana Bosnić
Required as a consequence of system design (contractor’s
requirement)
Developers’ suggestion
Ctm
Sys
DS
4.3
Rem.
Requirements definitions
Identity
Sta
tus
Prio
Rity
CC-1
CC-2
I
I
1
1
DC-1
I
1
DC-2
I
1
VM-1
VM-2
I
I
1
2
UM-1
UM-2
I
I
3
1
WM-1
I
2
Description
Creating the Course
Defining type management (Each Course can have one type)
Objective Management (Each course have multiple objective)
Designing the Course
Topics Management (Adding Topics, Deleting topics, Editing
Topics, etc.)
Activities Management (Adding Activities, Deleting Activities,
Editing Activities, etc.)
Version Management
Freezing Course
Freezing Topics
User Management
Choose Language (Change Language according to user priority)
Adding User, Deleting User, Modifying User Information
Workload Management
Workload analysis based on (number of students in course,
number of teacher staff, etc)
Source
Sys
Sys
Sys
Sys
Sys
Sys
Sys
Sys
Sys
Page 10
Course Builder
Requirements Definition
RT-1
I
1
UA-1
UA-2
I
I
2
1
AC-1
AC-2
AC-3
AC-4
I
I
I
I
1
1
2
2
RM-1
I
1
Version:
0.1
Date: 2006-11-14
Report
Creating customized reports (select optional rows and columns)
Users Administration
Add / Delete / Enable / Disable users
User roles (Course designer, Course assistant, Administrator)
Application Core
Database Abstraction
Modularity Support
Handling errors
Multi-language support
Resources Management
Provide overview of resources and their modification / removal
Sys
Ctm
Ctm
Sys
Sys
Sys
Ctm
Requirement status:
I = initial (this requirement has been identified at the beginning of the project),
D = dropped (this requirement has been deleted from the requirement definitions),
H = on hold (decision to be implemented or dropped will be made later),
A = additional (this requirement was introduced during the project course).
4.3.1
Change Log
Identity
Acti
on
Date
Comments
Requirement status:
D = dropped (this requirement has been deleted from the requirement definitions),
H = on hold (decision to be implemented or dropped will be made later),
A = added (this requirement was introduced during the project course).
R = resurrected (dropped or on hold requirement was reactivated)
5.
Future Development
5.1
General Overview
It is possible that some requirements might be changed or expanded to greater detail.
5.2
Specific group 1
The GUI might be more intensely modernized
- through more frequent employment of AJAX.
Page 11