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