CertAnon Product Specificationcpi/old/411/purpls13/files/Lab2… · Web viewThese are...

Running Head: LAB 2 – ELDERS PROTOTYPE PRODUCT SPECIFICATION 1

Lab 2 – ELDERS Prototype Product Specification

Team Purple

Josh Fetherolf

CS411w

Janet Brunelle

April 8, 2013

Version 1

LAB 2 – ELDERS Prototype Product Specification 2

Table of Contents

1 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

2 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


3.3.1 Database Requirements.............................................................................................19

3.3.2 Security......................................................................................................................21

3.3.3 Maintainability...........................................................................................................21

3.3.4 Reliability..................................................................................................................22

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.)


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


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

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.


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,

2012, from www.nottowayindians.org.

Parramore, T.C. (1978). In Southampton County, Virginia (pp. 1-5). Charlottesville, VA: UP of

http://www.nottowayindians.org/


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

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

http://theweek.com/article/index/229695/googles-next-mission-save-dying-languages


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

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.


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.

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.

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.

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.



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 non-functional requirements of the ELDERS project.


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 system1 Must have new accounts put into a default tier2 Must allow new users to request higher tier status

2 Must provide user access levels1 Must allow for creation of access levels2 Must allow the changing of the new user default access level3 Must allow the changing of an account’s access level4 Must allow editing of access levels5 Must allow editing of require access level for:

a receiving notificationsb accessing the dictionary sectionc adding words to the dictionaryd editing a word in the expanded dictionarye viewing words that have been suggestedf voting on suggested wordsg suggesting new wordsh suggesting a new wordi editing suggested wordsj accessing the games sectionk adding a game to the game sectionl accessing the grammar sectionm accessing the forumn changing forum permissionso editing access level for accessing the history sectionp editing access level for editing the history sectionq editing access level for adding to the history section


r editing access level for accessing the website settingss editing access level for changing an account's access levelt editing access level for setting the voting threshold

3 Must allow users to register for an account1 Must allow user to choose username2 Must alert user of existing username conflict3 Must allow user to choose password

a Must be at least 8 characters longb Must have a numberc Must have an uppercase characterd Must have a special character

4 Must prompt user for an email address4 Must allow user to login

1 Must allow user to type usernamea Must notify the user if the username does not exist

2 Must allow user to type passworda Must notify the user if the password is incorrect

3 Must allow user to reset passworda Must provide user with a temporary passwordb Must require user to change password

5 Must allow user to customize account1 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 words1 Must restrict number of votes to one2 Must allow for user to change vote

a Must be capable of adding the suggested word to the expanded dictionary3 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” words2 Must allow user to add words to the Expanded Dictionary3 Must provide means to view the alphabet4 Must be able to filter Nottoway words by letter5 Must be able to search for Nottoway words in English


1 Must alert user if search failsa Must suggest synonymsb Must show suggested wordsc Must prompt to vote on wordsd Must prompt to suggest worde Must allow for editing suggested wordsf Must prompt to suggest word if no suggested words exist

2 Must alert user of successful searcha Must display whether word is historic or expandedb Must display word in Nottowayc Must display Nottoway pronunciationd Must display word in Englishe Must display word’s part of speechf Must be capable of displaying a sample sentence of the wordg Must be capable of displaying common phrases that include the word

6 Must be able to search for Nottoway words using the Nottoway alphabet1 Must alert user if search fails2 Must alert user of successful search

a Must display whether word is historic or expandedb Must display word in Nottowayc Must display Nottoway pronunciationd Must display word in Englishe Must display word’s part of speechf Must be capable of displaying a sample sentence of the wordg Must be capable of displaying common phrases that include the word

7 Must provide a means to view the history of the Nottoway1 Must provide a means to add to history2 Must provide a means to edit history

8 Must provide a means to access onsite games1 Must provide means to add a game

9 Must provide a means to suggest a word1 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 permissions11 Must provide a forum

1 The forum must the ability to create access controlled sub forums2 The forum must be able to use the same accounts as the rest of the website


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 job3 Must have user accounts created to access the database 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 fieldsa 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 fieldsa 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_WORDi data_type: varchar(50)

b VOTESi int


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 encryption2 Must have authorization checks on the following actions:

1 receiving notifications2 accessing the dictionary section3 adding words to the dictionary4 editing a word in the expanded dictionary5 viewing words that have been suggested6 voting on suggested words7 suggesting new words8 suggesting a new word9 editing suggested words10 accessing the games section11 adding a game to the game section12 accessing the grammar section13 accessing the forum14 changing forum permissions15 accessing the history section16 editing the history section17 adding to the history section18 accessing the website settings19 changing an account's access level20 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:


1 Must be able to make backups regularly on hosting servers2 Website must be viewable from mobile devices

Website must be functional for all major web browsers.


Date post:	17-Apr-2020
Category:	Documents
Upload:	others
View:	4 times
Download:	0 times

CertAnon Product Specificationcpi/old/411/purpls13/files/Lab2… · Web viewThese are...

Documents