Running Head: LAB 2 – ELDERS PROTOTYPE PRODUCT SPECIFICATION
Lab 2 – ELDERS Prototype Product Specification
Team Purple
Josh Fetherolf
CS411w
Janet Brunelle
April 8, 2013
Version 1
1
LAB 2 – ELDERS Prototype Product Specification
2
Table of Contents
1
2
INTRODUCTION .................................................................................................................. 4
1.1
Purpose............................................................................................................................ 4
1.2
Scope ............................................................................................................................... 5
1.3
Definitions, Acronyms, and Abbreviations .................................................................... 7
1.4
References ....................................................................................................................... 7
1.5
Overview ......................................................................................................................... 8
GENERAL DESCRIPTION ................................................................................................... 8
2.1
Prototype Architecture Description ................................................................................ 9
2.2
Prototype Functional Description ................................................................................. 11
2.3
External Interfaces ........................................................................................................ 12
2.3.1 Hardware Interfaces .................................................................................................. 12
2.3.2 Software Interfaces ................................................................................................... 12
2.3.3 User Interfaces .......................................................................................................... 13
2.3.4 Communication Protocols and Interfaces ................................................................. 15
3
Specific Requirements .......................................................................................................... 15
3.1
Functional requirements................................................................................................ 16
3.1.1 User Account Requirements ..................................................................................... 16
3.1.2 User Interface Requirements..................................................................................... 17
3.2
Assumptions and Constraints ........................................................................................ 19
3.3
Non-Functional Requirements ...................................................................................... 19
LAB 2 – ELDERS Prototype Product Specification
3
3.3.1 Database Requirements ............................................................................................. 19
3.3.2 Security ..................................................................................................................... 21
3.3.3 Maintainability .......................................................................................................... 21
3.3.4 Reliability.................................................................................................................. 21
List of Figures
Figure 1. Major Functional Component Diagram........................................................................... 5
Figure 2. Major Functioanl Component Diagram........................................................................... 9
Figure 3. Voting Algorithm Diagram. .......................................................................................... 13
Figure 4. Searching Algorithm Diagram. ..................................................................................... 14
Figure 5. Prototype Site Map. ....................................................................................................... 15
(This space intentionally left blank.)
LAB 2 – ELDERS Prototype Product Specification
4
1 INTRODUCTION
An endangered language is one that is at risk of being lost as speakers either die or adapt
to a new language. There are thousands of languages around the world and experts speculate
that half of them are in danger of becoming extinct within the next century (The Week Staff,
2012). Language is critical to the speaker’s culture and in losing one, that culture is also being
lost.
There are a few language revival systems existing in the market today, such as Rosetta
Stone, FieldWorks Language Explorer, and First Voices. The intention of these programs is to
encourage the use of languages that may be not as commonly spoken, or to teach commonly
spoken languages to new learners. These are instrumental in reviving languages to prevent them
from going out of use. As long as these documentation programs exist, the language will not
become endangered.
1.1 Purpose
Endangered Languages Documentation Extension and Revival System (ELDERS) is a
product being developed by the Old Dominion University (ODU) CS411 Purple Group. The
purpose is to assist in restoring the Nottoway language. ELDERS is a web application that users
can access to learn about the Nottoway tribe history, language, games, and access a dictionary of
words belonging to the Nottoway. ELDERS has been designed using the Nottoway as a
prototype but the concept can be used for any language. When a language becomes extinct, it
LAB 2 – ELDERS Prototype Product Specification
can have a devastating effect on the culture. Any society can use the ELDERS web application
to restore their language just as the Nottoway is restoring theirs.
Figure 1. Major Functional Component Diagram.
1.2 Scope
The prototype of the ELDERS project uses the Nottoway Tribe of Virginia, local to the
Tidewater area. They have a language that is currently classified as endangered. In 1650, early
documentation of the tribe notes that there were only four to five hundred Nottoway people.
This is a comparably small number of Nottoway speakers to begin with. The tribe was further
challenged by forced relocation due to hostile tribes. Additionally, early in the 19th century, it
was dangerous to identify as Native American. This caused many individuals to hide their
ancestry for personal safety and is possibly when the language started to disintegrate (Nottoway
5
LAB 2 – ELDERS Prototype Product Specification
6
Indian Tribe of Virginia, 2011). Today, there are many tribal members cooperating and
assisting with the project to help build the database of words.
Revival systems are commonly made up of a database that includes all the words and
definitions that are known and documented, including pronunciations, syllables, sentence
structure, and other grammatical tips associated with the words. There are several problem
characteristics that revival systems encounter. Lack of documentation can occur when a
language is endangered due to a low number of speakers or an elderly population. Additionally,
older languages may not be written down or recorded in a manner that revival systems can use.
Endangered languages can eventually die off if the tools are not accessible, or in other words, a
lack of professional assistance to help record the words. Some endangered languages do not
have an alphabet, which makes recording the words impossible. The best solution for this is to
use a similar language that has an existing alphabet that can be shared. Another problem that
arises with endangered languages is when ambiguous words are used. There may be multiple
and interpretive meanings, or a difficulty in translating to English or the accepted language.
There are a few key solution characteristics for a revival system to be accepted and used.
The system should be versatile and able to be used anywhere the user requires it. It should be
educational in its execution so that the user is learning the language correctly. It would be
helpful if the system is free and available to anyone who wants to utilize it. The system should
be efficient in attaining the maximum desired effect without overwhelming the user with
information. Finally, the system needs to be well documented in its sources to provide a useful
database. The community of the language should be involved to assist with documentation.
LAB 2 – ELDERS Prototype Product Specification
1.3 Definitions, Acronyms, and Abbreviations
Apache HTTP Server: commonly referred to as Apache, a web server software.
IP: Internet Protocol.
LAMP: a platform consisting of Linux, Apache, MySQL, and Perl/PHP/Python.
LDAP: Lightweight Directory Access Protocol; an application protocol for accessing and
maintaining distributed directory information services over an IP network.
Linux: an open source computer operating system.
LTS: Long Term Support; a software release with longer support length than other releases.
MySQL: an open source multi-user database management system
ODU: Old Dominion University, Norfolk Virginia.
PHP: a server-side programming language designed for building dynamic Web pages.
Python: a general-purpose, high-level programming language.
Ubuntu: an open source computer operating system with a user interface.
Virtual machine: a simulation of a machine (abstract or real) that is usually different from the
target machine.
1.4 References
Fetherolf, Josh (2013) Lab 1 – ELDERS Product Description. Yorktown, VA: Author.
Lewis, J. D. (2007). Carolana Explorers – Edward Bland. Carolana. Retrieved on November
13, 2012, from http://www.carolana.com/Carolina/Explorers/edwardbland.html
Nottoway Indian Tribe of Virginia (2011). History. Nottoway Indians. Retrieved October 8,
7
LAB 2 – ELDERS Prototype Product Specification
8
2012, from www.nottowayindians.org.
Parramore, T.C. (1978). In Southampton County, Virginia (pp. 1-5). Charlottesville, VA: UP of
Virginia.
Peterson, M.D. (1986). In Thomas Jefferson: A Reference Biography (pp. 69, 168). United
States: Charles Scribner’s Sons.
The Week Staff (2012, June 22). Google’s next mission: Save dying languages – The Week.
The Week Magazine: Political News and Cartoons, Current Events and Entertainment
Online. Retrieved October 8, 2012, from
http://theweek.com/article/index/229695/googles-next-mission-save-dying-languages
1.5 Overview
This product specification details how the ELDERS prototype will be able to expand and
teach the Nottoway language. The following sections provide in depth information about the
database architecture, hardware source, and software configurations. There is also a detailed
description of the web application and how the administrators will create, manage, and control
the web application; and the requirements needed to ensure a completed prototype.
2 GENERAL DESCRIPTION
The main focus of ELDERS will be storing, expanding, and assisting in teaching the
language. The product is designed to provide the tools needed to teach the language as well as
the history of the community who speak it. A website will be used as the main interface to help
with navigating ELDERS, with the intention that this will enable easier access. The same
LAB 2 – ELDERS Prototype Product Specification
9
information can be conveyed through physical documents, but the website will be more versatile
and efficient. The product is reliant on input from the community, as they will be encouraging
the use of the product as well as facilitating the expansion of the language. This suggested words
by the community will be stored in an online database.
2.1 Prototype Architecture Description
Figure 2. Major Functioanl Component Diagram.
ELDERS uses several open source software components that are collectively known as a
LAMP stack: Linux, Apache HTTP Server, MySQL, and PHP, Perl, or Python. Ubuntu, the
Linux Operating System, will be used to access the ELDERS server. The Ubuntu 12.04
distribution will be used because it is the latest stable release. Maintenance will be guaranteed
for at least five years. The web server will be Apache, which will easily support language
interfaces such as PHP, Perl, and Python. PHP is used as a worldwide scripting language, but
ELDERS will be using Python because this will be unique and suitable for the development of
LAB 2 – ELDERS Prototype Product Specification
10
the website. MySQL will be the database management system. A database contains two tables,
one for the original language dictionary and the other for the secondary, modifiable dictionary.
The database will also store the language’s alphabet. Each of these components is provided as
up-to-date packages within Ubuntu and offer user-friendly interfaces.
Any community will be able to take their endangered language and enter it into
ELDERS. In doing so, a record of the original language will be created. It is then stored in
dictionary format, preserving the language for future generations. In addition to this original
language dictionary, a second one will be created. The purpose of the secondary dictionary is to
help the community expand and grow their endangered language. The secondary dictionary will
be a duplicate of the original but with the added feature of being modifiable. A committee,
selected by the community, will be able to modify the secondary dictionary. The elected council
as a whole will vote on new additions. The product has also been designed with a feature to
remove words from the secondary dictionary should the need ever arise. In addition to storing
and expanding the endangered language, ELDERS is an educational tool. For those trying to
learn the endangered language, there will be a section containing educational games, history
lessons, and standard language lessons all designed to help maximize learning of the language.
Communication is another key feature of the product. There is no expectation of growing
and expanding an endangered language without communication between the speakers. ELDERS
will provide members of the community with a forum to communicate with each other, which
will help to promote usage of the language. Users will have access to a message board essential
to providing a venue for use of the language and to give value to the words by using them in
conversation. Through communication on the message board or in forums, discussion should
promote new words that can eventually be added to the dictionary.
LAB 2 – ELDERS Prototype Product Specification
11
2.2 Prototype Functional Description
The product is made up of two major functional hardware components: a client and a
server, as shown in Figure 2. The client hardware can be any device with a web browser. For
the mobile devices, an application will be developed. However, as long as a device has a web
browser, the content will still be accessible. The server hardware will be outsourced to a hosting
service. It is currently being hosted on an ODU Computer Science departmental machine. In the
future, it may move to a different host. The minimal projected specifications are two to four
gigabytes of RAM and at least 20 gigabytes of hard drive space.
To access ELDERS, one must become a registered user to varying levels of information
based on the registration type. Once registered, the users are entered into the appropriate
permissions group based on their relationship to the community. These groups are established to
control access and limit the roles of certain users. The website administrators have full back-end
access. Other groups will be established for modifying the secondary dictionary or simply
viewing the website with no modification rights. Lightweight Directory Access Protocol
(LDAP) can be used if the community prefers privacy rather than having their site open to the
public. LDAP can be used not only for authentication but also allow for user provisioning, such
as splitting into different groups.
The web application is the revival system of ELDERS. The user will be able to view the
alphabet and both dictionaries belonging to the community. The user will also be able to view
historical background of the language speakers so as to educate themselves on the community.
LAB 2 – ELDERS Prototype Product Specification
12
There will be simple games and videos as educational tools. For example, a game being
developed is a matching game where the player builds words by lining up the correct word
fragments. Users may also participate in message boards and forums to introduce words to the
language which will then be voted on for addition to the secondary dictionary. If any changes
are made, registered users are notified via email.
2.3 External Interfaces
External interfaces used with ELDERS prototype will be limited to the standard PC and
free software packages. The custom interfaces will be the web application built for the prototype.
2.3.1 Hardware Interfaces
There will be no hardware interfaces used/built for the ELDERS prototype. The
web application and it’s database servers will be hosted at ODU. The web application will be
accessible through any computer that utilizes the Internet. As of now, the Nottoway asks that the
prototype only to be accessible to them. Software will be able to process this request.
2.3.2 Software Interfaces
The prototype architecture is a virtual machine, which is a software implementation of a
computer that executes programs as if a physical machine. The prototype virtual machine hosts
the Apache server and MySQL database. This works by the administrators logging into the
virtual machine by opening a remote desktop client and entering the IP address. From there, our
user interface for the virtual machine is accessible for database management.
LAB 2 – ELDERS Prototype Product Specification
13
The LAMP stack (Linux, Apache HTTP Server, MySQL, and Python) will be required
because the components are still necessary for the interface. Linux is the operating system,
Apache is the web server, MySQL is the database management system, and Python is the
scripting language. All of these features are necessary to create a user-friendly web application.
2.3.3 User Interfaces
The two algorithms in use will be for voting and searching. A new word that gets
submitted will first be searched through the database to see if it already exists. The voting
algorithm is initiated by a word being submitted by either a Tribal or Council member user.
Figure 3. Voting Algorithm Diagram.
LAB 2 – ELDERS Prototype Product Specification
14
Figure 4. Searching Algorithm Diagram.
Once the word has made it to the suggested word list, the Council members must approve
the word. If the suggested word gets the majority of votes and is accepted, it is then submitted
on the web application into the new dictionary table on the Nottoway database. Then, once a
new instance of a word is in the table, a notification is sent to the website’s registered users. If
the word does not get accepted, the word is dropped from the suggested voting pool. The site
map for the website viewable by the Nottoway is shown in Figure 5.
(This space intentionally left blank.)
LAB 2 – ELDERS Prototype Product Specification
15
Figure 5. Prototype Site Map.
2.3.4 Communication Protocols and Interfaces
The only protocols and interfaces the will be used will be over a standard Ethernet
connection or wireless, where accessible.
3 Specific Requirements
The following section describes the specific functional, assumption, constraints, and nonfunctional requirements of the ELDERS project.
LAB 2 – ELDERS Prototype Product Specification
16
3.1 Functional requirements
The ELDERS prototype is capable of expanding and teaching the Nottoway language. The
prototype will display the language and its dictionaries, activities for learning the language, history of the
tribe, and a forum to keep in touch with the new word submissions and words that have been voted into
the new dictionary.
3.1.1 User Account Requirements
The User Account Requirements are the functions, capabilities, and restrictions which must be
included in the various user access levels.
The following functional requirements must be met:
1 Must have a tiered user permission system
1 Must have new accounts put into a default tier
2 Must allow new users to request higher tier status
2 Must provide user access levels
1 Must allow for creation of access levels
2 Must allow the changing of the new user default access level
3 Must allow the changing of an account’s access level
4 Must allow editing of access levels
5 Must allow editing of require access level for:
a receiving notifications
b accessing the dictionary section
c adding words to the dictionary
d editing a word in the expanded dictionary
e viewing words that have been suggested
f voting on suggested words
g suggesting new words
h suggesting a new word
i editing suggested words
j accessing the games section
k adding a game to the game section
l accessing the grammar section
m accessing the forum
n changing forum permissions
o editing access level for accessing the history section
LAB 2 – ELDERS Prototype Product Specification
17
p editing access level for editing the history section
q editing access level for adding to the history section
r editing access level for accessing the website settings
s editing access level for changing an account's access level
t editing access level for setting the voting threshold
3 Must allow users to register for an account
1 Must allow user to choose username
2 Must alert user of existing username conflict
3 Must allow user to choose password
a Must be at least 8 characters long
b Must have a number
c Must have an uppercase character
d Must have a special character
4 Must prompt user for an email address
4 Must allow user to login
1 Must allow user to type username
a Must notify the user if the username does not exist
2 Must allow user to type password
a Must notify the user if the password is incorrect
3 Must allow user to reset password
a Must provide user with a temporary password
b Must require user to change password
5 Must allow user to customize account
1 Must allow user to turn notifications on/off
3.1.2 User Interface Requirements
The User Interface Requirements detail everything the website is capable of doing.
The following functional requirements must be met:
1 Must provide a means to vote on suggested Nottoway words
1 Must restrict number of votes to one
2 Must allow for user to change vote
a Must be capable of adding the suggested word to the expanded dictionary
3 Must provide a threshold for votes on a word suggestion
a Suggested words that have reached the threshold must be marked as
“approved”
4 Council must have a similar voting system for “approved” words
2 Must allow user to add words to the Expanded Dictionary
3 Must provide means to view the alphabet
LAB 2 – ELDERS Prototype Product Specification
4 Must be able to filter Nottoway words by letter
5 Must be able to search for Nottoway words in English
1 Must alert user if search fails
a Must suggest synonyms
b Must show suggested words
c Must prompt to vote on words
d Must prompt to suggest word
e Must allow for editing suggested words
f Must prompt to suggest word if no suggested words exist
2 Must alert user of successful search
a Must display whether word is historic or expanded
b Must display word in Nottoway
c Must display Nottoway pronunciation
d Must display word in English
e Must display word’s part of speech
f Must be capable of displaying a sample sentence of the word
g Must be capable of displaying common phrases that include the word
6 Must be able to search for Nottoway words using the Nottoway alphabet
1 Must alert user if search fails
2 Must alert user of successful search
a Must display whether word is historic or expanded
b Must display word in Nottoway
c Must display Nottoway pronunciation
d Must display word in English
e Must display word’s part of speech
f Must be capable of displaying a sample sentence of the word
g Must be capable of displaying common phrases that include the word
7 Must provide a means to view the history of the Nottoway
1 Must provide a means to add to history
2 Must provide a means to edit history
8 Must provide a means to access onsite games
1 Must provide means to add a game
9 Must provide a means to suggest a word
1 Must require user input of a Nottoway word
2 Must allow user to submit new Nottoway word
10 Must provide a means to edit website settings and permissions
11 Must provide a forum
1 The forum must the ability to create access controlled sub forums
2 The forum must be able to use the same accounts as the rest of the website
18
LAB 2 – ELDERS Prototype Product Specification
19
3.2 Assumptions and Constraints
Table <table #> contains a complete list of assumptions on requirements.
Condition
Type
Effect on Requirements
All new words follow the old
grammar rules.
Assumption
Capability of defining custom
grammar rules for new words
is not included
Example sentences for new
words are entered accurately
Assumption
There will be no check on
new entries to ensure they are
correct
Table <table #> Effects of Assumptions on Requirements.
3.3 Non-Functional Requirements
ELDERS must satisfy requirements not immediately known to the user. These will be
responsible for covering the background or back-end processes of the project. The topics in this
area include the database as well as security, maintainability, and reliability.
3.3.1 Database Requirements
The database is a major component of the ELDERS project. It is responsible for storing the
components of the Nottoway language. Also, it interacts with the front-end events, such as the
GUI, and the associated algorithms.
The following non-functional requirements must be met:
1 Must create a database called Nottoway
2 Must backup the database every day at midnight by running a cron job
3 Must have user accounts created to access the database
LAB 2 – ELDERS Prototype Product Specification
20
4 Must have database privileges limited depending on the user
5 Must contain a table named ALPHABET that stores the following information as fields
a LETTERS
i data_type: varchar(15)
b PRONUNCIATION
i data_type: varchar(50)
6 Must contain a table named HISTORICAL_DICTIONARY that stores the following
information as fields
a ENGLISH_WORD
i data_type: varchar(25)
b NOTTOWAY_WORD
i data_type: varchar(50)
c PRONUNCIATION
i data_type: varchar(50)
d DEFINITIONS
i data_type: varchar(100)
e PART OF SPEECH
i data_type: varchar(25)
7 Must contain a table named EXPANDED_DICTIONARY that stores the following
information as fields
a ENGLISH_WORD
i data_type: varchar(25)
b NOTTOWAY_WORD
i data_type: varchar(50)
c PRONUNCIATION
i data_type: varchar(50)
d DEFINITIONS
i data_type: varchar(100)
e PART OF SPEECH
i data_type: varchar(25)
8 TO DO: Must contain a table named NUM_VOTES which has a foreign key pointing to
NOTTOWAY_WORD in the NEW_DICTIONARY table which stores the following
information as fields
a NOTTOWAY_WORD
i data_type: varchar(50)
b VOTES
i int
LAB 2 – ELDERS Prototype Product Specification
21
3.3.2 Security
ELDERS must provide adequate security for its consumers. This includes securely storing user
data and providing permission checks to various features of the product. Therefore, the following
non-functional requirements must be met:
1 Must store user passwords in database with encryption
2 Must have authorization checks on the following actions:
1 receiving notifications
2 accessing the dictionary section
3 adding words to the dictionary
4 editing a word in the expanded dictionary
5 viewing words that have been suggested
6 voting on suggested words
7 suggesting new words
8 suggesting a new word
9 editing suggested words
10 accessing the games section
11 adding a game to the game section
12 accessing the grammar section
13 accessing the forum
14 changing forum permissions
15 accessing the history section
16 editing the history section
17 adding to the history section
18 accessing the website settings
19 changing an account's access level
20 setting the voting threshold
3.3.3 Maintainability
The product should provide features that allow it to be fixed or changed at anytime. These
features will ensure the product can support continued development after being released. To
ensure maintainability, the following non-functional requirements must be met:
1 Must check for software/package updates
a Must check compatibility of current code with new software versions in test
environment before updating server
3.3.4 Reliability
ELDERS should be designed to provide a reliable service that will work through multiple
circumstances. Therefore, the following non-functional requirements must be met:
LAB 2 – ELDERS Prototype Product Specification
1 Must be able to make backups regularly on hosting servers
2 Website must be viewable from mobile devices
Website must be functional for all major web browsers.
(This space intentionally left blank.)
22