Running head: LAB 2 – PROTOTYPE PRODUCT SPECIFICATION FOR ELDERS ... Lab 2 – Prototype Product Specification for ELDERS
Running head: LAB 2 – PROTOTYPE PRODUCT SPECIFICATION FOR ELDERS 1
Lab 2 – Prototype Product Specification for ELDERS
Ben Cortina
CS 411W
Janet Brunelle
April 8, 2013
Version 1Table of Contents
1 INTRODUCTION ................................................................................................................... 1
1.1 Purpose ............................................................................................................................. 1
1.2 Scope ................................................................................................................................ 1
1.4 References ........................................................................................................................ 1
1.5 Overview .......................................................................................................................... 1
2 GENERAL DESCRIPTION .................................................................................................... 1
2.1 Prototype Architecture Description ................................................................................. 1
2.2 Prototype Functional Description .................................................................................... 1
Lab 2 – Prototype Product Specification for ELDERS 2
2.3 External Interfaces ........................................................................................................... 2
2.3.1 Hardware Interfaces ................................................................................................ 2
2.3.2 Software Interfaces ................................................................................................. 2
2.3.3 User Interfaces ......................................................................................................... 2
2.3.4 Communications Protocols and Interfaces .............................................................. 2
3 SPECIFIC REQUIREMENTS.................................................................................................. 2
3.1 Functional requirements................................................................................................... 2
3.1.1 User Account Requirements ................................................................................... 2
3.1.2 User Interface Requirements ................................................................................... 2
3.2 Assumptions and Constraints ........................................................................................... 2
3.3 Non-Functional Requirements ......................................................................................... 2
3.3.1 Database Requirements ........................................................................................... 2
3.3.2 Security ................................................................................................................... 2
3.3.3 Maintainability ........................................................................................................ 2
3.3.4 Reliability ................................................................................................................ 2
List of Figures
Lab 1 – ELDERS Description 3
Figure 4.
Voting Algorithm .......................................................................................................... 17
Table 2. Effects of Assumptions on Requirements 25
1 INTRODUCTION
There are up to 7,000 different spoken languages around the world. Each one defines a culture. UNESCO (The United Nations Educational, Scientific and Cultural Organization) estimates that, by the end of this century, nearly half of these languages will die off if no further efforts at preservation are made ("Endangered Languages"). Out of a concern over the possible extinction of these languages and loss of the valuable cultural heritage, numerous programs are dedicated to saving endangered languages. Some of the most notable efforts include UNESCO,
First Voices, Rosetta Stone, and FLEx (FieldWorks Language Explorer). The majority of these programs focus on documenting and retaining the language in its current state. Unfortunately, this approach does not help the language grow in its user base or vocabulary. As the user base of a language shrinks, parts of it are steadily forgotten. With ninety percent of current languages having less than 100,000 users, it is uncertain how much of each language may have already been forgotten (“Languages of the World“). Some languages are so close to extinction that only a minute portion of the language remains, leaving only a stark framework without potential for complex cultural images and metaphors.
To save these languages, documentation is the key. However, it is not always enough in some cases. In order for a language to remain relevant in a constantly changing world, it must continue to develop alongside a society. For languages that have lost so much, aid is desperately needed to help the language develop. This development implies the expansion the user base and
Lab 2 – Prototype Product Specification for ELDERS 4 continuation of linguistic evolution and growth through ever expanding vocabulary, complexity, and imagery.
1.1 Purpose
Sadly, of all the language revival projects out there, none of them focus on the Nottoway language. That is why this project’s focus is on the Nottoway dialect; a language so severely antiquated it was declared extinct around 1958 (Paul Lewis, 2009). All that remains is around
300 words recorded almost two hundred years ago. Additionally, the original Nottoway alphabet was not documented.
In order to help such an endangered language, a tool must be designed to provide the users with a means to teach and expand the language. This tool must be versatile enough to accommodate any change to the language, otherwise it could hinder the language’s continued development. It must be educational enough to allow for people to learn the language. The tool should be accessible to all in the community who wish to aid in the development of their language; as such, it should be free. Reliable and valid documentation of a language is necessary to provide a foundation on which the language can grow. Therefore, the tool must excel at documenting grammar, vocabulary, and alphabets. A language must be supported, and ultimately nurtured by the community for it to continue to thrive and evolve. Most importantly, the language must be defined by its community; as such, the tool must be community managed and driven. The Endangered Language Documentation, Extension, and Revival System (ELDERS) will be designed to be this tool.
ELDERS will be designed to ensure the language will thrive by focusing on the three most important elements of language revival: documentation, expansion, and education. While the language must expand, without a well-documented origin, the language would have no root
Lab 1 – ELDERS Description 5 from which to grow. Therefore, ELDERS will offer services that allow communities to store the alphabet of their language, words and their appropriate attributes, and grammar structure.
Development of the language should be entirely community driven. This is why ELDERS will offer language expansion tools in the form of a suggestion and voting system for new words. For a language to thrive, there must be a growing user base. To support and enable expansion,
ELDERS will provide educational material such as history, grammar tutorials, and word games.
ELDERS will encourage community involvement by providing a means for the users to directly aid in the expansion of the language via the word suggestion and voting system.
Additionally, each community will be provided with a forum on which they can communicate with other members.
The ELDERS database will feature two separate tables: one to preserve the language in the state is was in upon joining ELDERS (Historical Dictionary), and another table for storing any additions during the use of ELDERS (Expanded Dictionary). ELDERS will be able to read both tables but, after initial setup, the Historical Dictionary table will not be modifiable through
ELDERS. This feature is to ensure the language is remembered exactly as it was before contact with ELDERS. Users, with the proper authority, will have the means to remove, modify, and add new words or rules.
The Education section of ELDERS will provide tools to learn the language and the culture of the community. There will be lessons designed to teach users proper sentence structure, conjugation, and other grammatical attributes of the language. Additionally, a variety of educational games will be available to offer a more interactive learning experience. The
ELDERS prototype will only have one game, but the option for users to submit new games will be available. Finally, ELDERS will provide an option for the community to document the history
Lab 2 – Prototype Product Specification for ELDERS 6 of its culture. This gives the community a secure place to store their history, and it provides new users with the means to understand the nature of the community’s culture.
Community interaction and communication are both key to the language growing through
ELDERS. This is why a forum to interact with the rest of the community in hopes to drive up user engagement will be provided. Additionally, notifications will be sent out informing users of new additions or changes to the language. Finally, as ELDERS is designed to a be a tool for the community, they are directly in charge of the language growth. Users are provided with means to suggested new words and vote on the preferred version if a word has already been suggested.
These features are designed to encourage users to take part in ELDERS and help their language expand.
(This space is intentionally left blank.)Figure 1 illustrates the major functional components of ELDERS. In the “Client” box, the website features are depicted. In the “Server” cylinder, the back-end setup is defined. The entire project will be free and open source software.
This means that there will be no licensing fee for anyone who wants to use ELDERS or its code.
Additionally, this allows the community to give full control to whomever they decide should have it.
Lab 1 – ELDERS Description 7
Figure 1. Major Functional Component Diagram
The client side of ELDERS holds the features a user will be able to access via the website. This side is designed to be accessible for people at home as well as those who do not have immediate access to a computer. The website will be viewable on a computer with Internet access and a web browser. The ELDERS website will also support mobile devices with a specially designed view.
The website will feature different layouts for each section. There will be a section where users may view the alphabet. The words in the dictionaries of the Historical and Expanded
Dictionary will have a section that allows for listing a selection of words and searching for a specific word. The history of the host community will receive its own section designed to allow users to easily learn about a specific time period or event. Finally, there will be a forum on the
ELDERS’s website that allows users to communicate with each other.
Access control and user authentication will be a key part of ELDERS’s functionality. The website administration account will be allowed to decide which users are able to view certain
Lab 2 – Prototype Product Specification for ELDERS 8 sections of the website. This allows for the community to prevent all but a small group from suggesting new words or opening all features of the website. This will be accomplished using a tiered account system. After a user creates an account, it can be promoted to one of the administrator designated tiers. The rank the account has will determine the features available to that user.
The server software of ELDERS can be hosted wherever the community decides. The host will need to be able to provide at least two to four gigabytes of RAM and at least twenty gigabytes of storage space. Additional space will be required as the language expands.
ELDERS is aimed at revitalizing the Nottoway language. This project is being worked on by a group of students at ODU (Old Dominion University). This group of students has been working with Professor Jay Morris and the Nottoway Indian Tribe of Virginia. The final product will be designed for initial use by the Nottoway Indian Tribe of Virginia. Over the last few years,
Professor Morris has become close with the leaders of the tribe, allowing us to have an understanding of their desires and expectations for the product. It was through this relationship and by learning of the tragic past and threatened loss of this culture that the idea for this project was borne.
The first record of the Nottoway Indians in American history occurred when Edward
Bland, an explorer, first encountered them in 1650 and recorded their status in his journal. At that time, the Nottoway was a relatively small tribe, with a population of only four to five hundred (D. Lewis, 2007). In 1681, the tribe was located in today’s Sussex County, but they were forced to relocate after being threatened by hostile tribes. The majority of the tribe moved to Surry County, but it is believed that some moved north and established a tribe in New Jersey
(Parramore, 1978). Much later, in 1820, Thomas Jefferson requested documentation of the
Lab 1 – ELDERS Description 9
Nottoway language. John Wood was sent to talk with the tribe’s chief at the time, Chief ‘Queen’
Edie Turner. During this meeting, two hundred and fifty words were recorded. It was also noted that at that time only three Nottoway speakers remained, and all of them were elderly. The language was declared extinct by the end of the 19th century. Today, there are two Nottoway tribes recognized by the state of Virginia: the Nottoway Indian Tribe of Virginia and the
Cheroenhaka (Nottoway) Indian Tribe.
The Nottoway Indian Tribe of Virginia is located in Surry County and the Cheroenhaka
(Nottoway) Indian Tribe is located in Southampton County. The tribe the ODU students are working with, the Nottoway Indian Tribe of Virginia, has only around 200 members remaining, none of which are able to speak their own language. Our mentor, Jay Morris, learned about the story of the Nottoway and their language while he was studying Cherokee over the past eight years. He then took it upon himself to help the Nottoway restore their ancient language.
Jay Morris graduated from University of Missouri in 1983 with a Bachelor of Arts. He then proceeded to get two Masters Degrees at Yale in 1996 and 1994 in Philosophy and
Mechanical Engineering, respectively. Professor Morris now teaches Computer Science at Old
Dominion University. His interest in American Indians sprouted from his Cherokee ancestry. As mentioned previously, he has been studying the Cherokee over the past eight years. Over the last two years he has been honored with the title of “State Plan Chief.”
It has taken Morris a long time to gain the trust of the Nottoway Indian Tribe of Virginia.
Now, he is in regular contact with the tribe chief. The idea for this project and the specifications of the product have been relayed and discussed with the Nottoway.
1.2 Scope
Lab 2 – Prototype Product Specification for ELDERS 10
ELDERS will be developed with the objective of providing, metaphorically, a platform on which a endangered language may find secure ground upon which to grow. Where secure ground represents the thorough documentation of the language which prevents further deterioration. The growth represents the expansion of the language through adding words and teaching the language using the features provided by ELDERS.
The ELDERS prototype will be designed to show off the most important features of
ELDERS. It will implement several key features: documentation, culture, access control, word approval process, and notifications. The prototype will come will full support for documenting the Historical Dictionary and archiving the changes to the language while being developed through ELDERS. The history section of the website will be fully functional to allow the culture to be well defined. The prototype will contain a system that allows user to suggest, vote on, and approve new words. The notification system will also be implemented in the ELDERS prototype.
1.3 Definitions, Acronyms, and Abbreviations
CMS: Content Management System.
Council: Users with permission to edit the language.
ELDERS : Endangered Language Documentation, Extension, and Revival System.
Historical Dictionary: The vocabulary and grammar of the language before contact with
ELDERS. This will be stored in a table separate from the table that stores the Expanded
Dictionary
Expanded Dictionary: This term refers to the changes and additions to the vocabulary and grammar of the language during the use of ELDERS.
Joomla: A PHP based CMS.
ODU: Old Dominion University.
Lab 1 – ELDERS Description 11
LAMP: Linux, Apache, MySQL, and PHP, Python, or Perl.
1.4 References
Cortina, Ben. (2007). Lab 1 – ELDERS Description. Norfolk, VA: Author.
Endangered Languages. United Nations Educational, Scientific and Cultural Organization . N.p., n.d. Web. 14 Feb. 2013.
Figure 2. Muthevel, Arturo. (1947). LAMPP Architecture . [Image]. Retrieved April 1, 2013 from http://en.wikipedia.org/wiki/LAMP_(software_bundle )
Languages of the World - Interesting Facts about Languages. BBC News . BBC, n.d. Web. 14
Feb. 2013.
Lewis, J. D. Carolana Explorers - Edward Bland. Carolana Explorers . N.p., 2007. Web. 13 Nov.
2012.
Lewis, M. Paul (ed.), 2009. Ethnologue: Languages of the World, Sixteenth edition. Dallas, Tex.:
SIL International. Online version: http://www.ethnologue.com/.
Parramore, Thomas C. Southampton County, Virginia. Charlottesville: Published for the
Southampton County Historical Society by the UP of Virginia, 1978. Print.
1.5 Overview
This product specification provides the hardware and software configuration, external interfaces, capabilities and features of the ELDERS prototype. The information provided in the remaining sections of this document includes a detailed description of the hardware, software, and external interface architecture of the ELDERS prototype; the key features of the prototype; the parameters that will be used to control, manage, or establish that feature; and the performance characteristics of that feature in terms of outputs, displays, and user interaction.
2 GENERAL DESCRIPTION
Lab 2 – Prototype Product Specification for ELDERS 12
The ELDERS prototype will attempt to demonstrate the main features of the final product. Namely, it will focus on documentation, access control, language expansion, and community involvement. Most of the features implemented in the prototype will not be fully fleshed out due to time constraints.
(This space is intentionally left blank.)2.1 Prototype Architecture Description
The prototype for ELDERS will be run on a virtual machine at ODU. This virtual machine will be running a LAMP stack. The Linux operating system will be Ubuntu and the programming language will be PHP. ELDERS will run on a LAMP stack because every component is free and open source. This provides the most versatility in the development of
ELDERS. Figure 2 illustrates the architecture of LAMP.
Lab 1 – ELDERS Description 13
Figure 2. LAMP Architecture
The virtual machine will be running Ubuntu as its operating system. This machine will hold the components which make up the website. ELDERS will use Joomla to aid in the creation of the website and interfacing with the database. Joomla is a content management system (CMS) based on PHP. A CMS provides a more object oriented approach to making a website. The client will be able to view the website from any popular web browser.
A key focus of the prototype will be on the documentation aspects of ELDERS. As such, the MySQL database will be fully functional. The prototype database will be capable of storing the words in the dictionaries as well as each word’s attributes. Language lessons and mobile accessibility will not be included initially.
2.2 Prototype Functional Description
Lab 2 – Prototype Product Specification for ELDERS 14
Figure 3 illustrates the major functional components of the prototype. The differences between this and Figure 1 are the lack of language lessons and mobile accessibility. Language lessons will not be in the prototype due to time constraints. Mobile accessibility represents a more mobile friendly view, which is not a high priority. The tiered user account system will be functional, including user registration and access control.
Figure 3. Prototype Major Functional Component Diagram
The educational aspects of the ELDERS prototype will include games, history, a dictionary, and an alphabet. The games section in the final product will hold various educational word games to help teach the language to new users. It is low priority and there will only be on game, at most, in the prototype. The history section will provide a location to store the history of the community and their language. The Historical and Expanded Dictionaries will be implemented in the prototype. They will each be entirely independent. The Historical Dictionary table will be non-modifiable via ELDERS after it is initially setup. The Expanded Dictionary table will be modifiable and will house new additions to the language as a result of the outcomes
Lab 1 – ELDERS Description 15 of the voting system. The ELDERS website will provide a means to view the words of both dictionaries. The search feature on the website will draw from both tables and compile the results seamlessly. A means to store and view an alphabet will also be provided in the prototype.
The language management aspects, namely the word proposal system, will be included in the prototype. Users with the proper access privileges will be able to suggest new words for the language. These suggestions will be available to be voted on by other users. When a suggestion has reached an established number of votes, designated users referred to as Council in Figure 4, will have the final decision on whether or not the suggested word is added to the language. If a word is approved, notifications of the addition will be sent out to all users who have designated they wish to receive notice.
(This space is intentionally left blank.)
The council view represents the view of users with permission to manage the language.
This tier allows for editing the words in the Expanded Dictionary. Users in this tier also have the final say on which of the suggested words get added into the dictionary. The full word approval process is detailed in Figure 4.
Lab 2 – Prototype Product Specification for ELDERS 16
Figure 4. Voting Algorithm
Many features will be included in the prototype but, due to time constraints, not every feature will be completed. Table 1 details the differences in the features of the ELDERS prototype and real world product.
Feature
Games
Language Lessons
Mobile Accessibility
Server
Word Conjugation
Dictionary Parsing
Real World Product
Multiple games
Prototype
A single, simple game
A suite of lessons to teach users how to speak, write, and read the language
Foundation for adding lessons
A separate website view designed for use with mobile devices
Mobile users will see the same design as desktop users
Website is hosted on an independent web server
Words are automatically conjugated using a defined system
Website is hosted on a computer on the Old
Dominion University network
Words need to be manually conjugated
Automatic parsing and storing of multiple dictionaries
Automatically parsers a text document of a specific format
Lab 1 – ELDERS Description 17
Table 1. Prototype and Product Feature Comparison
2.3 External Interfaces
The ELDERS prototype will be run on a machine at ODU. The website will be reachable from any machine capable of accessing and viewing the internet. As mentioned in Section 2.1
ELDERS will be designed using the Joomla CMS.
2.3.1 Hardware Interfaces
Because ELDERS is a website based system, there are little hardware interfaces involved with its design. A device capable of accessing and displaying a webpage will be needed to access the ELDERS website. The system will be run on a machine with a connection to the internet.
2.3.2 Software Interfaces
ELDERS will be entirely open source, and therefore will use all open source interfaces in development. phpMyAdmin is a software tool the developers will use to manage and interface with the MySQL database. Joomla will be used to create the website. ELDERS will be accessible using any popular browsers, including Safari, Internet Explorer, Mozilla Firefox, and Google
Chrome.
2.3.3 User Interfaces
The user interface for ELDERS will be the website. It will be accessible from any machine with internet access and a means to view webpages. The available features of the website will be different for each user depending on their access level. Figure 5 illustrates the site map excluding language and user management.
Lab 2 – Prototype Product Specification for ELDERS 18
Figure 5. General User Site Map
The home page will act as a place to provide important news about the language. The dictionary page provides a means to search and view the dictionaries. In the prototype, the community page will only house a forum. The education page will house the games, and later the language lessons. Lastly, the history section will allow access to the history of the community and their language. Users will have access to important sections through a website wide navigation bar. The language and user management features will likely not be available to most users. The language management elements include suggesting, voting on, and approving words.
The user management section allows changing of user tiers and permissions.
2.3.4 Communications Protocols and Interfaces
ELDERS will be hosted on a single machine and access over the internet through a web browser. Therefore, the only protocol that will be used is TCP/IP.
Lab 1 – ELDERS Description 19
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 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
Lab 2 – Prototype Product Specification for ELDERS 20 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 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
Lab 1 – ELDERS Description 21 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
Lab 2 – Prototype Product Specification for ELDERS 22
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
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
Lab 1 – ELDERS Description 23
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
3.2 Assumptions and Constraints
Lab 2 – Prototype Product Specification for ELDERS 24
Table 2 contains a complete list of assumptions on requirements.
Condition
All new words follow the old grammar rules.
Type Effect on Requirements
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 2. 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
4.
Must have database privileges limited depending on the user
5.
Must contain a table named ALPHABET that stores the following information as fields
1.
LETTERS a.
data_type: varchar(15)
Lab 1 – ELDERS Description 25
2.
PRONUNCIATION a.
data_type: varchar(50)
6.
Must contain a table named HISTORICAL_DICTIONARY that stores the following information as fields
1.
ENGLISH_WORD a.
data_type: varchar(25)
2.
NOTTOWAY_WORD a.
data_type: varchar(50)
3.
PRONUNCIATION a.
data_type: varchar(50)
4.
DEFINITIONS a.
data_type: varchar(100)
5.
PART OF SPEECH a.
data_type: varchar(25)
7.
Must contain a table named EXPANDED_DICTIONARY that stores the following information as fields:
1.
ENGLISH_WORD a.
data_type: varchar(25)
2.
NOTTOWAY_WORD a.
data_type: varchar(50)
3.
PRONUNCIATION a.
data_type: varchar(50)
4.
DEFINITIONS
Lab 2 – Prototype Product Specification for ELDERS 26 a.
data_type: varchar(100)
5.
PART OF SPEECH a.
data_type: varchar(25)
8.
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:
1.
NOTTOWAY_WORD a.
data_type: varchar(50)
2.
VOTES a.
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 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
Lab 1 – ELDERS Description 27
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
1.
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 – Prototype Product Specification for ELDERS 28
1.
Must be able to make backups regularly on hosting servers
2.
Website must be viewable from mobile devices
3.
Website must be be functional for all major web browsers.
