Camosun College Capstone Project
Ancestor Project
Software Requirements Specification
Author:
Creation Date:
Last Updated:
Version:
Created for:
Bill Heaton, Matt Donnelly, Jason Michael
March 8, 2011
March 23, 2011
1.1
Stephen Lang
Approvals:
Project Sponsor
Dr. Marla Weston
Signature
Date
Signature
Date
Signature
Date
Signature
Date
Signature
Date
Team
Matt Donnelly
Jason Michael
Bill Heaton
Faculty Supervisor
Dr. Marla Weston
March 23, 2011
Table of Contents
1.0 Introduction ................................................................................................................. 3
1.1 Purpose.......................................................................................................................... 3
1.2 Scope ............................................................................................................................. 3
1.3 References ..................................................................................................................... 4
1.4 Overview of Document ................................................................................................. 4
2.0 System Overview ......................................................................................................... 5
2.1 Project Perspective ........................................................................................................ 5
2.2 System Context ............................................................................................................. 5
2.3 General Constraints ....................................................................................................... 6
2.4 Assumptions and Dependencies ................................................................................... 7
3.0 Throw-Away Prototyping .......................................................................................... 8
4.0 Requirements............................................................................................................... 9
4.1 Use Case Requirements ................................................................................................ 9
4.1.1 Actor List .....................................................................................................9
4.1.2 Use Case Diagrams .......................................................................................10
4.1.3 Use Case Specifications ................................................................................12
4.1.4 Use Case Standard Template ........................................................................21
4.1.5 Activity Diagrams .........................................................................................22
4.2 Business Rules ............................................................................................................ 28
4.3 Non-Functional Requirements .................................................................................... 28
4.3.1 System Requirements....................................................................................28
4.3.2 Usability Requirements .................................................................................29
4.3.3 Performance Requirements ...........................................................................29
4.3.4 Security Requirements ..................................................................................30
4.3.5 Delivery Requirements .................................................................................30
4.3.6 Legal Requirements ......................................................................................30
4.3.7 Interoperability Requirements ......................................................................31
4.3.8 Scalability Requirements ..............................................................................31
4.4 Interface Requirements ............................................................................................... 31
4.4.1 Machine Interfaces ........................................................................................31
4.4.2 External System Interfaces ...........................................................................32
4.4.3 Human-Computer Interface Considerations .................................................32
4.4.4 Input and Output Requirements ....................................................................32
5.0 Project Issues ............................................................................................................. 33
5.1 Projected Development Effort .................................................................................... 33
5.2 Proposed Project Schedule .......................................................................................... 33
5.3 Conversion / Load Requirements................................................................................ 33
5.3.1 Data Conversion Assumptions and Constraints ............................................33
6.0 Appendices ................................................................................................................. 35
Page | 2
Version History
Document Version
Date
Author(s)
Details/Description
1.0
2010-Mar-09
Matt Donnelly
Jason Michael
Bill Heaton
Whole document
1.1
2010-Mar-22
Matt Donnelly
Jason Michael
Bill Heaton
Introduction, Domain Model,
Requirements, Project Issues, Appendix
1.0 Introduction
1.1 Purpose
This document identifies the key functional descriptions and constraints of the Ancestor Project
curriculum and teaching materials to be developed by Team Dzunukwa for the Camosun College
Computer Science Department (CS). The expected audience for this document include members of the
CS department, School of Business and Aboriginal Education & Community Connections Department
(AECC) as well as the project developers.
1.2 Scope
The Ancestor project is a three year project that began in January of 2010. The ultimate goal of the
project is to introduce programming concepts to aboriginal students through a holistic approach to
learning and teaching ways based on traditions and various learning modalities. A review of options
during the initial phase of the project led to the Alice 3D programming environment which was developed
by Carnegie-Mellon University. Alice allows for an easy way to create stories and games using a drag
and drop technique, and introduces the learner to object oriented programming languages such as Java
and C#. In addition to learning computer programming, these students will create stories from their
ancestral heritage to help preserve their culture for the next generation.
Last year a curriculum was developed and a pilot program was launched at the LÁU,WELNEW Tribal
School in Brentwood Bay. After a consultation with the teacher of the pilot program we will use that
feedback to improve upon the lessons created to improve the delivery of the content to the student. We
will be achieving this in three phases.
Page | 3
The first will be a standalone server that will be used to support the delivery of the curriculum to students.
This server must be standalone since not all participants in the Ancestor program will have internet
access. Lab machines can be networked to this server and thus provide a fully independent system.
The second part of this project will be to install a learning management system (LMS). We will use the
open source Moodle (Modular Object-Oriented Dynamic Learning Environment) because it not only
provides the necessary functionality but is free to download and use. Funding is an issue for many project
participants and thus costs must be kept to a minimum.
The third part of this project is to create tutorial videos for the lessons using Alice. These videos will be
created using software called Camtasia which allows us to create screen casts of use demonstrating tasks
in the Alice Environment. These videos will be available to the students via the Moodle system.
1.3 References
●
●
●
●
alice.org/index.php, Carnegie Mellon University - 2008-2011
moodle.org, Open Source Initiative - 2011
Ancestor Project Charter 1.1, Team Dzunukwa - 2011
Ancestor Project Plan 1.1, Team Dzunukwa - 2011
1.4 Overview of Document
This document consists of five sections.

The first, System Overview, introduces the system context and design, and also discusses the
background of the project.

The second, Throw Away Prototyping explains in detail the designs used to ensure the project
continues as planned and that it is feasible for the proposed technology to be implemented.

The third, Requirements, defines the Functional and Non-Functional Requirements of the
proposed curriculum.

The fourth section, Project Issues, provides a high-level description and estimate of subsequent
project development efforts.

The last section, the Appendixes, provide any additional information or documents that might be
useful during the System Development Life Cycle.
Page | 4
2.0 System Overview
2.1 Project Perspective
Year1 – January to December 2010
The year one objective for the Ancestor project was to create and test a draft educational package. The
educational package included the selected programming environment, an initial cultural image and sound
library, along with preliminary training materials and lesson plans. The draft educational package was
tested with students and teachers from the LÁU,WELNEW Tribal School.
Year 2 – January to December 2011
The Year 2 project extends the result of the first year and will continue to update and test the educational
package. It will be similar to Year 1, but will expand to additional communities. This Year 2 project will
have as one focus, updating the educational package to be on a standalone Moodle server. This server will
include revised curriculum in the form of short screen-cast tutorial videos. Also included will be a library
of relevant characters and objects based on the story of the school with built in methods for manipulating
characters for easy cultural story telling.
The curriculum based on the feedback and surveys from Year 1 will be updated to focus more on basic
elements of using the Alice IDE such as saving a world, loading a saved world, creating an object, making
an object move, and making an object paddle a canoe. The tutorials will accompany a wide variety of skill
levels so that every student remains challenged and engaged.
Year 3 – January to December 2012
The Year 3 objective will be to finalize the educational package and promote the program. The pilot
project faculty team, with the help of yet another computer science project team, will work with
participating communities from Year 1 and Year 2 to finalize the educational package and program
website. Student winners from Year 1 and Year 2 will be brought together to share their submissions and
personal education goals during the provincial Aboriginal youth conference (annual event coordinated by
BC association of Aboriginal Friendship Centres), and possibly the annual First Nations Education
Steering Committee education conference. More than 1000 Aboriginal youth attend the conference and
approximately 400 Aboriginal educators attend the education conference. Community dialogues to
determine lasting effects of the promotional campaign and linkages created with post-secondary
institutions will also be carried out.
2.2 System Context
Reflecting realities and ways of learning is an evolving process within Camosun College as well as other
institutions across Canada. When asked what helped contribute to their success at Camosun College,
Aboriginal learners confirmed that culturally relevant curricula, inclusion activities in and out of the
Page | 5
classroom, and support systems (cultural and academic) created an environment of success. In a recent
discussion the paper from Canadian Council on Learning1, cultural relevancy is lacking in science
education. Within Camosun, student demand is increasing for all technology programs, including
computer science. Over the past three (3) years the enrolment in the Computer Systems Technology
program has increased by 10-15%. The situation is similar for the other technologies. Although student
demand is increasing, the number of Aboriginal learners is negligible. The Ancestor project hopes to
address this imbalance.
The content of the educational package will focus on culturally relevant themes. By combining historic
content with modern teachings it is the hopes of the program to encourage youth to explore their cultural
background as well as prepare for future academic and career opportunities.
Initially, the program was offered at the LÁU,WELNEW Tribal School in association with the
WS'ANEC' School Board. The next iteration will grow to include additional urban and remote sites.
Since approximately 40% of First Nations’ communities in British Columbia lack high speed
connectivity, the inclusion of remote communities is essential to ensure the developed training material
will have broad application.
It is expected that if the program is successful, it could become of value on a National scale.
2.3 General Constraints
Curriculum will be targeted to secondary and post-secondary institutions. No previous programming
experience will be assumed. To ensure the material is accessible to all skill levels, the curriculum must be
concise, simple and clearly presented.
The 3d model gallery and resulting Alice 3d examples must be designed with cultural awareness in mind.
It is the ultimate goal of the project to integrate a modern computer science programming language with
historically significant underpinnings.
Remotely located project participants may have limited or no network and Internet connectivity. The
curriculum must be created with this in mind. Workshops and/or Courses must be able to function with
limited or no network connections.
Hardware at various locations is varied. Course material and the supporting LMS must be designed to
run independent of hardware and operating system specifics.
1
Canadian Council on Learning. Lessons Learned. The Cultural Divide in Science Education for Aboriginal Learners. February 1, 2007.
Retreived from: http://www.ccl-cca.ca/pds/LessonsinLearning/Feb-01-07-The-culteral-divide-in-science.pdf
Page | 6
2.4 Assumptions and Dependencies
The following assumptions have been made for the project:
●
●
●
●
Server hardware will be made available to the development team.
Classrooms will have at minimum, networking capabilities.
Tutorial videos will be able to be stored locally and delivered to classrooms without Internet
connectivity.
Virtual Machine and an online YouTube account will be able to deliver streaming video to
multiple students simultaneously.
This project has the following dependencies:
●
●
Server hardware will meet minimum requirements of at least 1 GB RAM to enable smooth
encoding of the tutorial videos.
Networking capabilities are at least 10/100 Mbit to alleviate the bottle neck of content delivery.
Page | 7
3.0 Throw-Away Prototyping
The Ancestor project will be dealing with a variety of different production environments. The LMS will
have to be deployed in schools with:
● Internet connectivity
● No Internet connectivity
● Labs with Windows machines
● Labs with Macintosh machines
The project will develop a virtual machine that contains the Moodle LMS that can be tested in different
environments. The project will use the Camosun CST laboratories to test the VM on Windows machines
and the LÁU,WELNEW Tribal School to test on Macintosh's to determine the minimum host and virtual
machine requirements to meet performance standards.
Currently at the LÁU,WELNEW Tribal School there is no server environment supporting the student lab.
This means the only place for students to save their work is on the local workstation. A student’s work
becomes unavailable if their computer is in use by another student. It would be ideal for students to store
their projects in a central location and these be made available across all lab machines. A repository to
save work is required. With prototyping the new Moodle environment, the team has discovered a virtual
locker system that will allow students to save their projects into the Moodle system and access it a later
time and from a different workstation.
A YouTube repository has been created and a test video has been posted to prove whether or not it is
possible to embedded videos into the Moodle environment. This has proven to be successful, but will
only benefit those locations where Internet connectivity is available. Locations without connectivity will
have to browse the content off line and therefore must be delivered to the student locally from the Moodle
server.
Page | 8
4.0 Requirements
4.1 Use Case Requirements
Use case requirements for the project have been identified based on participants’ experience in the first
phase of the proof of concept. Students at the LÁU,WELNEW Tribal School have had the opportunity to
use the curriculum designed by the Capstone team last year. The students and instructor have been
interviewed and feedback has been gained to learn where improvements can be made.
It has been brought to our attention that the curriculum designed by last year’s team needs to be broken
down and simplified so that students at varying levels of skill can access content that pertains to their
abilities.
Tutorial videos have been requested to assist with the development of the students participating in the
Ancestor Project. These videos will provide click by click tutorials to guide them through their required
tasks.
4.1.1 Actor List
Project Sponsor - is responsible for the project. Confirms and approves project scope. Acquires and
ensures sufficient program resources. Promotes project. Reviews and approves Change Requests.
Provides direction to project manager and client manager. Resolves issues arising from the project.
Responsible for final sign-off of the project.
Project Supervisor - maintains an overview of the project. Ensures scope stays within reasonable
boundaries. Facilitates issues arising between the project Sponsor and the Project Team.
Project Manager - plans and controls all project activities. Communicates project changes and status to
project stakeholders. Ensure deliverables are completed on time.
Project Team - is responsible for the development of the project.
Subject Experts - provides guidance on specific technology areas of the project. Will provide some
deliverables to aide in the project development.
Learning Management System - a central repository that will contain the majority of the project
deliverables. These will include video tutorials, lesson plans and schemes of work.
Teacher - Recipient of the LMS, will offer feedback to refine future iterations of the project.
Page | 9
Student - Final user of the system. LMS content will be targeted at this user. Feedback will help refine
future iterations of the project.
4.1.2 Use Case Diagrams
Use Case Diagrams identify actors (i.e. user roles) and use cases. They also describe how the actors
interact with the system and the relationships between use cases. They are not meant to show screen
navigation, nor are they meant to show functional decomposition (not applicable to this Software
Requirements Specification).
Page | 10
Content Management System
Use video tutorial
[ap_6]
Prepare Unit [ap_7]
Take Unit [ap_8]
Take Lesson [ap_9]
Student
Teacher
Take Unit [ap_10]
Student Log in
[ap_3]
Teacher Login
[ap_2]
Admin Login [ap_1]
«extends»
Administrator
«extends»
Configure System
[ap_4]
Configure System
[ap_5]
Page | 11
4.1.3 Use Case Specifications
Use Case ID: ap_1
Version: 1.0
Name: Admin Login
Description: Admin logs into the Moodle
Level: Full Use Case
Actors:


Primary Actor: Administrator
Supporting Actor: Moodle
Main Flow:
Preconditions

Moodle is installed on a local or remote server
Post-conditions

Administrator Logged into Moodle
#
1
2
3
4
5
6
7
Actor
Description
Administrator Administrator enters the URL location of the Moodle server in a web
browser
Moodle
Moodle loads the home page in the web browser
Administrator Administrator clicks on the login button
Moodle
Moodle redirects to the login page
Administrator Administrator enters login credentials
Moodle
Moodle authenticates Administrators credentials
Moodle
Moodle loads logged in home page for Administrator privileges
Page | 12
Use Case ID: ap_2
Version: 1.0
Name: Teacher Login
Description: Teacher logs into the Moodle
Level: Full Use Case
Actors:


Primary Actor: Teacher
Supporting Actor: Moodle
Main Flow:
Preconditions

Moodle is installed on a local or remote server
Post-conditions

Teacher Logged into Moodle
#
1
2
3
4
5
6
7
Actor
Teacher
Moodle
Teacher
Moodle
Teacher
Moodle
Moodle
Description
Teacher enters the URL location of the Moodle server in a web browser
Moodle loads the home page in the web browser
Teacher clicks on the login button
Moodle redirects to the login page
Teacher enters login credentials
Moodle authenticates Teacher credentials
Moodle loads logged in home page for Teacher privileges
Page | 13
Use Case ID: ap_3
Version: 1.0
Student Login
Description: Student logs into the Moodle
Name:
Level: Full Use Case
Actors:


Primary Actor: Student
Supporting Actor: Moodle
Main Flow:
Preconditions

Moodle is installed on a local or remote server
Post-conditions

Student Logged into Moodle
#
1
2
3
4
5
6
7
Actor
Student
Moodle
Student
Moodle
Student
Moodle
Moodle
Description
Student enters the URL location of the Moodle server in a web browser
Moodle loads the home page in the web browser
Student clicks on the login button
Moodle redirects to the login page
Student enters login credentials
Moodle authenticates Student credentials
Moodle loads logged in home page for Student privileges
Page | 14
Use Case ID: ap_4
Version: 1.0
Name: Administrator Configure System
Description: Administrator Configures the Moodle System
Level: Full Use Case
Actors:
 Primary Actor: Administrator
 Supporting Actor: Moodle
Main Flow:
Preconditions

Moodle Installed
Post-conditions

All desired configuration changes have been made
#
1
2
3
4
5
Actor
Administrator
Moodle
Administrator
Administrator
Moodle
Description
Administrator selects desired configuration
Available changes are displayed to Administrator
Administrator makes any changes necessary
Administrator saves desired configuration changes
Moodle updates based on new configuration
Alternate Flows:
1a.
Moodle CMS first loads
#
1a 1
Actor
Administrator
Description
See use case Administrator Login, return to step 2 in primary
flow.
Page | 15
Use Case ID: ap_5
Version: 1.0
Name: Administer System
Description: Teacher Modifying content in Moodle
Level: Full Use Case
Actors:
 Primary Actor: Teacher
 Supporting Actor: Moodle
Main Flow:
Preconditions
Post-conditions
#
1
2
3
4
5
Actor
Teacher
Moodle
Teacher
Teacher
Moodle

Moodle Installed


All desired content changes have been made
Changes have been saved
Description
Teacher selects desired content to modify
Moodle display all available content to modify
Teacher makes changes to the content
Teacher saves all desired content changes
Moodle updates based on newly modified content
Alternate Flows:
1a.
Moodle CMS first loads
#
1a 1
Actor
Teacher
Description
See use case Teacher Login, return to step 2 in primary flow.
Page | 16
Use Case ID: ap_6
Version: 1.0
Name: Use Video Tutorial
Description: Teacher using a video tutorial from Moodle
Level: Full Use Case
Actors:
 Primary Actor: Teacher, Student
 Supporting Actor: Moodle
Main Flow:
Preconditions

Moodle Installed
Post-conditions

Video will be viewed by either teacher and student
#
1
2
3
4
5
Actor
Teacher/Student
Moodle
Teacher/Student
Moodle
Teacher/Student
Description
Teacher/Student selects to use video tutorial
Moodle displays all available video tutorials
Teacher/Student chooses desired video tutorial to view
Moodle loads the selected tutorial video
Teacher/Student watches the video tutorial that was chosen
Alternate Flows:
1a.
Moodle CMS first loads
#
1a 1
Actor
Teacher
Description
See use case Teacher Login, return to step 2 in primary flow.
Page | 17
Use Case ID: ap_7
Version: 1.0
Name: Prepare Unit
Description: Teacher preparing a new unit in Moodle
Level: Full Use Case
Actors:
 Primary Actor: Teacher
 Supporting Actor: Moodle
Main Flow:
Preconditions
Post-conditions
#
1
2
3
4
5
6
7
Actor
Teacher
Moodle
Teacher
Teacher
Teacher
Moodle

Moodle Installed


Newly prepared unit created
Changes have been saved
Description
Teacher selects to create a new unit
Moodle displays available options for preparing a unit
Teacher chooses any options desired
Teacher adds all necessary material to the unit
Teacher selects which students can view unit
Moodle displays the newly prepared unit
Alternate Flows:
1a.
Moodle CMS first loads
#
1a 1
Actor
Teacher
Description
See use case Teacher Login, return to step 2 in primary flow.
Page | 18
Use Case ID: ap_8
Version: 1.0
Name: Take Course
Description: Student takes prepared course
Level: Full Use Case
Actors:
 Primary Actor: Student
 Supporting Actor: Moodle
Main Flow:
Preconditions
Post-conditions
#
1
2
3
Actor
Student
Moodle
Student


Moodle Installed
Student Logged into Moodle

Student has successfully completed the course
Description
Student selects the course in which they want to take
Moodle loads the lessons available for selected course
Student proceeds to take a lesson in selected course see use case
ap_26
Alternate Flows:
1a.
Moodle CMS first loads
#
1a 1
Actor
Student
Description
See use case Student Login, return to step 2 in primary flow.
Page | 19
Use Case ID: ap_9
Version: 1.0
Name: Take Lesson
Description: Student takes prepared lesson
Level: Full Use Case
Actors:
 Primary Actor: Student
 Supporting Actor: Moodle
Main Flow:
Preconditions
Post-conditions
#
1
2
3
Actor
Student
Moodle
Student




Moodle Installed
Student Logged into Moodle
Student selected desired course first
Student successfully completes selected lesson
Description
Student selects the desired lesson to take
Moodle loads available content for
Student selects video tutorial to watch see use case ap_23
Alternate Flows:
1a.
Moodle CMS first loads
#
1a 1
Actor
Teacher
Description
See use case Teacher Login, return to step 2 in primary flow.
Page | 20
4.1.4 Use Case Standard Template
Use Case ID: <Enter value of Id here>
Version: 1.0
Name: <Enter Use Case name here>
Description: <Enter description here>
Level: <Enter Use Case Goal Level here>
Actors:
 Primary Actor: <List the Primary actor here>

Supporting Actor: <List supporting actors here>
Main Flow:
Preconditions

<List Pre-Conditions here>
Post-conditions

<List Post-Conditions here>
#
1
2
3
Actor
<Actor>
<Actor>
<Actor>
Description
<Enter steps here>
<Enter steps here>
<Enter steps here>
Alternate Flows:
1a. <Alternate step>
#
1a 1
Actor
<Actor>
Description
<Enter steps here>
Page | 21
4.1.5 Activity Diagrams
Activity diagrams are graphical representations of workflows. They show the choices and linear flow of
control through a system of activities.

Diagram 1 – Installation of server when Internet Connectivity available

Diagram 2 – Installation of server when no Internet Connectivity available.

Diagram 3 – Teacher instructing student through all lessons.

Diagram 4 – Teacher instructing student through one lesson with video tutorials

Diagram 5 – Student attempting to use a video tutorial within a lesson.
Page | 22
Activity diagram 1 shows the installation of a server in a school that has internet connectivity available to
steam videos.
Activity Diagram 1
Page | 23
Activity diagram 2 shows the installation of a server in a school that has no internet connectivity and must
stream video direct from the server itself.
Activity Diagram 2
Page | 24
Activity diagram 3 shows a teacher instructing a student through all the lessons of a unit of work.
TEACHER INSTRUCTS UNIT
TEACHER
CMS
STUDENT
Introduce Unit
Begins Unit
Loads Unit
Start lesson
[Completes
Lesson]
Lesson in Progress
See Activity
Diagram 1
Grades Unit
[Unable to
complete
current
lesson]
[Completes
all lessons
in Unit]
Unit Completed
Receives feedback
LOOP
Completed all Units
Activity Diagram 3
Page | 25
Activity diagram 4 shows a teacher instructing a student through an individual lesson within a unit. The
student will use the video tutorials within each of the lessons.
TEACHER INSTRUCTS LESSON
TEACHER
Turns on Alice
ALICE
CMS
STUDENT
Loads Alice World
Introduces Lesson
Loads Lesson
Explains Lesson
Start lesson
Lesson in Progress
Gives Help
[Unable to
complete
current
lesson]
[Asks for help from teacher]
[Finishes lesson]
Grades Lesson
Lesson Completed
Receives feedback
Progresses to next lesson
Activity Diagram 4
Page | 26
Activity diagram 5 shows a student attempting a lesson within a unit of work. The student will use the
video tutorials while attempting the lessons.
STUDENT ATTEMPTS A LESSON
STUDENT
ALICE
Turns on Alice
CMS
TEACHER
Loads Alice World
Selects Lesson
Loads Lesson
LOOP
[Starts
different
lesson]
Begins Lesson
[Does not
complete
lesson]
[Finishes lesson]
Completes Lesson
Receives feedback
Grades work
[Finishes
session]
[Finishes
all
lessons]
Closes Alice World
Completes Unit
Grades Work
Next unit
Activity Diagram 5
Page | 27
4.2 Business Rules






Complete set of beginner lessons and a scheme of work. The lessons must address the needs of a
range of abilities, ages and interest.
Complementary set of video tutorials to be paired with the lessons.
Configured Learning Management System to contain and manage curriculum material.
Updated website at http://www.ancestorproject.org
Documentation to illicit how to manage and maintain the LMS as well as some best practices
using the lessons and schemes of work.
If possible, extend the project scope to begin work on the intermediate and advanced sets of
tutorials and lessons.
4.3 Non-Functional Requirements
Identified Non-Functional Requirements:
●
●
Proposed system must run exclusive of external network and/or Internet connections.
Hardware will be diverse. Proposed system must function efficiently on varying levels of
computer hardware and operating systems.
4.3.1 System Requirements
Classrooms will need Carnegie Mellon Hall’s Alice 3d IDE 2.2 installed as well as a version 1.5 or greater
of the Java runtime environment. Alice 3d has the following requirements:
Operating System requirements:
 Windows 7, Vista, XP or 2000
 Macintosh OS X 10.3 or higher
 Linux
Recommended PC hardware requirements:
 Intel Pentium II or equivalent processor
 A VGA graphics card capable of high (16 bit) color and 1024x768 resolution (3D video card
recommended)
 512MB of RAM (1GB recommended)
 A sound card
Recommended Mac hardware requirements:
 PowerPC or Intel processor
 A VGA graphics card capable of high (16 bit) color and 1024x768 resolution (3D video card
recommended)
Page | 28


512MB of RAM (1GB recommended)
A sound card
The updated curriculum and tutorial videos will be delivered to students through Moodle which will be
installed into a Virtual Machine (VM). Each classroom will have a server installed with the following
minimum requirements:
Operating system requirements:
 CentOS 5.5
Software Requirements:
 VirtualBox 4.0.4
Hardware Requirements:
 Intel Pentium 4 or equivalent processor
 1 GB RAM (2GB recommended)
 40 GB Hard drive or larger
 10/100 Mb Network Adapter (likely integrated with Motherboard)
4.3.2 Usability Requirements
It is expected that the content of the project will be suitable for both secondary and post-secondary
learners.
Content must support local instructors/teachers with limited knowledge of Alice or object oriented
programming.
The modular design and presentation of the course material should also support students at different skill
levels within the same course. Learners should be allowed to proceed at their own pace if that meets the
learning outcomes of the course.
4.3.3 Performance Requirements
Performance requirements will vary in performance widely depending on location of implementation.
The hardware that is provided must meet the minimum system requirements to be able to run the Alice
IDE. Ultimately, system performance will be dictated by hardware and available connectivity.
Page | 29
4.3.4 Security Requirements
The updated curriculum will be delivered from a locally installed CentOS server that requires
authentication through the use of a strong password. In addition to a password, administrators must
possess a private key, used for encryption/decryption of their passwords. Even with knowledge of their
password, without the key, access to the server will be prohibited.
Learners accessing the curriculum through Moodle will require a strong password. The password will be
given to the students by their teacher or administrator. The curriculum itself will only be accessible by
authenticating into the Moodle system. Only the teacher or the administrator possesses the ability to reset
the student’s passwords.
In the case where the installation has no Internet connectivity, the server will be unavailable for potential
security breaches from outside the facility.
4.3.5 Delivery Requirements
An AGILE methodology of Rapid Application Design (RAD) will be used to develop the project. Small
iterative steps will be completed and reviewed by the project steering committee ensuring the project
maintains its desired focus. This form of development will allow changes in design to take place with
minimal impact to the project timeframe.
The final deliverable will consist of a standalone Learning Management System with a selection of
tutorials designed to help students and instructors become familiar with Alice. These tutorials will be
based initially on updated curriculum from Year 1 of the Ancestor Project. The LMS will be tested by
LÁU,WELNEW tribal school in Brentwood Bay, Victoria BC and the Sooke tribal school in Sooke BC.
The project team will be required to update the project website by adding and updating course content.
4.3.6 Legal Requirements
Tl'isalagilakw remains with the Kwakwaka'wakw tribes through the educational lens of the Vancouver
Island Consortium of Indigenous Arts Society. This Society has a professional relationship with the
U'Mista Cultural Centre on language revitalization using new technologies and methods. Use,
recognition and acknowledgement of the story, images, sounds, and language remain the traditional
knowledge of the Nation as recognized by the United Nations Declaration on Rights of Indigenous
Peoples - Articles 11, 13, 15, 16, and 31 respectively.
Intellectual property rights for the animated game remain with AECC as a promotional and educational
tool for computer science career possibilities. Use of the sample will remain with AECC in partnership
with computer science department - ensuring that the context of the sample is not jeopardized since it is a
representation of many tribal resource management stories into one scenario and is our responsibility as
citizens to ensure the integrity of the adaptation.
Page | 30
4.3.7 Interoperability Requirements
In the case of Internet connectivity the proposed Moodle system will deliver content to the students and
the Tutorial videos will stream directly from YouTube. Providing YouTube isn’t experiencing any
technical difficulties and the schools Internet Service Provider is peered with a reliable network
connection there will be no disruption of service.
Where no Internet is available, the videos will be served locally from the Moodle server. While there will
be guaranteed content available it may quickly become out-dated as each offline location will have to
have the new content manually transported and uploaded.
4.3.8 Scalability Requirements
The proposed curriculum is required to be designed in a scalable manner. It is expected the scope of the
project will grow during each successive phase. Each phase must be designed with future scalability in
mind.
In order to deploy the Ancestor Project curriculum to additional schools, servers will be required to
interface with the existing local area network so students may access their content. Since Alice is open
source there is no additional expense to deploy the software across all lab machines.
The OS for the VM and the Moodle LMS is open sourced there is no licensing expense to use as many
copies as needed.
4.4 Interface Requirements
4.4.1 Machine Interfaces
The CentOS server will be running Sun’s Virtual Box that will run an image of our preconfigured Moodle
LMS. This server must be networked via a category 5 Ethernet cable. In addition to the server being
connected to the LAN, all lab machines in use by the students must be attached to the same network. In
the case where a router exists, configuration of the primary Domain Name Server (DNS) must deliver the
network setting to the lab machines in order for the student’s web browser to reach the Moodle server.
In the case where no router exists, the server and the lab machines must be statically assigned network
addresses in order to communicate with each other.
Page | 31
4.4.2 External System Interfaces
In order to reach the tutorial videos delivered via YouTube, there must be an active Internet connection
provided by the school’s Internet Service Provider. The advantage of delivering this content from the
external repository is the ability to upload new content to one location and have all Moodle systems
participating in the project access the content as needed. Without Internet connectivity, tutorial videos
must be sent to each individual school and uploaded on to each server separately.
4.4.3 Human-Computer Interface Considerations
The project focuses on utilizing the existing Alice 3d integrated development environment. As such the
HCI will be that of the existing Alice look and feel. The Moodle HCI will depend on built in templates
provided, minimal changes are to be expected regarding the layout. Subsequent phases may be required
to change or modify the existing Moodle interface. Also the Moodle interface can be changed to match
the design associated with an academic institution or community. While these changes are possible, they
are outside the scope of the Ancestor project.
4.4.4 Input and Output Requirements
Custom models, to be imported into the cultural image gallery with built in functionality for basic
movements. Models must be created as .ase ASCII standard 3d files. The models will be imported into
the Alice IDE and converted to their XML equivalent by the Alice import engine.
Any Aboriginal language and ambient sounds that will be created must be imported into the Alice IDE.
Files must be created in the mp3 format.
Alice worlds created by any students must be persistent between sessions. As such worlds must be saved
to the Moodle LMS for accessibility whenever required.
Page | 32
5.0 Project Issues
5.1 Projected Development Effort
It is expected that the project team, which consists of three members, will be required to spend upwards of
30 hours a week individually, over a five month span, to complete the project as detailed in the Workplan
shown in Appendix A.
Phase
Analysis
Design
Development
Testing
Deliverables
Project Charter, Project Plan,
SRS Document
Curriculum Design Document,
User Acceptance Test Document
LMS with Video Tutorials,
Training Materials
Hours
200 total
Test Video Tutorials and LMS,
Test LMS in Alternate Environment
N/A
450 total
An open house will be held at Camosun College on May 5th. Two public sessions will be held and
attendants will be given the opportunity to use Alice, using the LMS as an instructional tool. The LMS
will also be installed at the LÁU,WELNEW Tribal School’s Macintosh labs and tested for performance.
Results from each test will be analysed and appropriate modifications will be made based on user
recommendations.
5.2 Proposed Project Schedule
The second phase of Ancestor project was initiated January 4th, 2011. It is scheduled to end the week of
June 17th, 2011. The analysis and design phases will run concurrently. See appendix A for detailed
information on deliverable dates.
5.3 Conversion / Load Requirements
5.3.1 Data Conversion Assumptions and Constraints
Assumptions include:

Sounds will be successfully converted to .mp3 format using third party software.

Model complexity must be limited to fewer than 1300 polygons per model. Higher model poly
counts strain the Alice engine resulting in unpredictable behaviour within the Alice world.
Page | 33

Audio files should be constrained to be as small as possible. Larger audio files cause unstable
results within the Alice IDE.
Page | 34
6.0 Appendices
Figure 1 - This Gantt chart illustrated the project schedule for the Ancestor Project. It shows the start and
finish dates for each of the elements.
Page | 35
Sign-Off
Name
Signature
Date
Vendor Project Manager
Name
Signature
Date
Ministry Project Manager
Name
Signature
Date
Business Analyst, IMB
Name
Signature
Date
Architecture Group, IMB
Name
Signature
Date
Data Architecture Group, IMB
Name
Signature
Date
Database Administration Group, IMB
Page | 36