€¦ · Web vie

CS 411W Lab III

Prototype Test Plan/ProcedureFor

ELDERS

Prepared by: Robert Matson, Purple Group

Date: 04/29/13

ELDERS Test Plan, Matson-ii

Table of Contents

1 Objectives....................................................................................................................12 References....................................................................................................................23 Test Plan......................................................................................................................3

3.1 Testing Approach.................................................................................................33.2 Identification of Tests..........................................................................................33.3 Test Schedule.......................................................................................................73.4 Fault Reporting and Data Recording...................................................................83.5 Resource Requirements.......................................................................................83.6 Test Environment.................................................................................................83.7 Test Responsibilities............................................................................................8

4 Test Procedures..........................................................................................................104.1 Test Case Names and Identifiers.......................................................................10

5 Traceability to Requirements.....................................................................................39

List of Tables

Table 1. ELDERS prototype identification of test cases....................................................3Table 2. ELDERS prototype test schedule.........................................................................7Table 3. Traceability matrix for the ELDERS prototype.................................................39

ii

ELDERS Test Plan, Matson-1

1 Objectives

ELDERS is a language revitalizing project to help keep endangered languages from dying

out. To make sure the ELDERS project is working functionally, we set up test cases to ensure

every possible test will result in a working output. This documentation will show what the test

cases have been tested for the prototype. We want to have no issues or errors happening when

any user is on it.

(this space intentionally left blank)

1


2 References

Matson, Robert. (2013). Lab I – ELDERS Product Description. Norfolk, VA: Author.

Matson, Robert. (2013). Lab II – Prototype Product Specification for ELDERS. Norfolk, VA:

Author.


2


3 Test Plan

The following sections of the test plan will discuss the types of tests to be performed, the

testing schedule, reporting procedures, resource requirements, the testing environment, and team

member responsibilities.

3.1 Testing ApproachPerformance of the ELDERS prototype will be verified through a variety of different

tests. An example is being able to edit your registered user profile.

3.2 Identification of TestsAs shown below, the group has split up the test cases. Each category ID has been grouped by

a specific description. The test case ID corresponds to the category ID number. The test cases

have different descriptions matching with objective of the test case number.

Category ID Description

Test Case ID

Test Case Description Objective

1 Access Control 1.1

View access tiers and tier permissions

Show that access tiers and permissions are implemented.

1.2 Request higher tier status Show a user may request a higher tier status.

1.3Create new access tier Demonstrate process of

creating a new access tier.

1.4 Change default account tier Verify that the default tier may be changed.

1.5Edit account tiers Show that the

permissions for an access tier may be edited.

3


1.6 Verify Access checks Show that all access checks are in place.

2 User Accounts 2.1 Create new user Prove that an account can be created.

2.2 Alert user if username already exists

Show that username redundancy is prevented

2.3 Verify password requirements Verify that the password restrictions are in place.

2.4Login as existing account Demonstrate that

registered users are able to log in.

2.5 Login with incorrect information Show that invalid logins call an error.

2.6 Reset account password Verify that a password may be reset.

2.7Change notification settings Demonstrate that a user

may change their notification preferences.

3 Voting 3.1 Council to vote on suggested word(s)

To expand the Nottoway Language

3.2Restrict only one vote per council member

Ensure that the Council can only make one vote on a suggested word.

3.3 User change vote Change vote due to common error.

3.4Words that have reached threshold mark as approved

When the majority of votes are in the words favor.

3.5 Able to add new word to dictionary

Expand the dictionary upon “approved” words.

4 Searching 4.1Search Nottoway words in English

To test whether searching by English returns the correct information.

4.2Alert of failed search To notify the user that the

word searched is not in the database.

4.3Suggest and show suggestions of failed search

To suggest alternatives for a returned fail search

4


4.4Edit words that are suggested To give Council an

opportunity to change suggested words

4.5Search Nottoway words in Nottoway

To test whether searching by Nottoway returns the correct information.

4.6

Alert of failed search To test whether users receive a notification when they search for a Nottoway word that doesn’t exist.

4.7 Nottoway filtered by letter To test that the word filter functions correctly.

5 History 5.1 History of the Nottoway viewable To test that the Nottoway history is displayed.

6 Suggestions 6.1 Suggested words by users To test a list of suggested words by users

6.2Prompt to suggest word if no suggested word exists

To notify the suggested word if the word does not exist

6.3 User input of suggested word To test that a suggested word can be inputted

6.4 User submission of suggested word

To test that a suggest word can be submitted

7 Administration 7.1

Edit website settings To test that the settings on the website have been changed by the administrator

7.2 Edit website permissions To test the website's permission level

8 Forum 8.1 Access Forum To test that the Forum is displayed.

8.1

Create access controlled sub forums

To test that a user’s forum account is the same as their ELDERS account.

9 Database 9.1 View the Nottoway database Viewing the database proves that it exists.

9.2 Backup the database Prove that the DB is

5


being backed up.

9.3 Create a MySQL user Users must exist in order to access the DB.

9.4 Assign users sufficient database privileges

Make sure that user’s privileges are set.

9.5View the ALPHABET table schema

Make sure that the ALPHABET table has the expected columns.

9.6View the HISTORICAL_DICTIONARY table schema

Make sure that the table has the right columns.

9.7View the EXPANDED_DICTIONARY table schema


9.8View the NUM_VOTES table schema


9.9Prove password encryption Make sure that the

passwords are encrypted in the DB.

10 Language 10.1 Access syllabary chart To test that the Syllabary is displayed.

10.2Browse grammar Verify the user can

access the Nottoway grammar.

11 Versatility 11.1Can be viewed on mobile devices Confirming the ability for

ELDERS to be viewed on a mobile device.

11.2

Can be functional for all major web browsers

Confirming that ELDERS can be used correctly through different web browsers that are commonly used.

12 Maintenance 12.1Check for software update Show that there is a

means to update software used by ELDERS

Figure 1 ELDERS Identification of cases

6


3.3 Test ScheduleThe test schedule can be viewed below. The first five minutes, missing from the table,

will be used to briefly introduce the Nottoway. It will also describe how our prototype has

fulfilled the tribe’s needs.

Table 2 ELDERS Prototype Test Schedule

3.4 Fault Reporting and Data RecordingA team member will have the role as a test recorder. This member keeps track on which

test case needs to be done. That member will record what test case passes or fails. Each fail will

require a fault report on what test case went wrong while keeping the data of the failed output.

3.5 Resource Requirements

7


The use of a virtual machine is required. We want to be able to access into the backend of

the prototype. The frontend needs access to a pc or laptop with a working network connection.

The user will then be able to see and test the ELDERS prototype.

3.6 Test EnvironmentThe test will be done inside a room with access to a wired or wireless network

connection. The room needs a working projector to be able to display a large screen of the

presentation of the prototype. A computer or laptop will be connected to it so the tester can

display the prototype. Two presenters will be at the front discussing and explaining what is

happening on the displayed prototype. The tester will write down details throughout the inputs

and outputs during the presentation.

3.7 Test ResponsibilitiesIn the ELDERS prototype presentation, there will be two presenters, two test users, a

database monitor, and a test recorder. The primary speakers will be Tatiana Livingston and

George Calhoun, who will work together in presenting the prototype. One of the two presenters

will take the other’s job if he/she is unable to attend. They will also provide an introduction and

narrative of each test case. Ben Cortina and Josh Fetherolf will be test users as well as operating

the computer. Taking turns, each test user will execute the test case, explain what they are doing

as well as show the expected results. Terry Stilwell will be the database monitor, responsible for

displaying and explaining changes to the database when applicable. Robert Matson is the test

recorder. He will keep the testing on track and will record what has been done and the result. He

will also record what needs to be done should any errors occur.

8



4 Test Procedures

Detailed test procedures have been created by ELDERS. This will ensure that the test

cases will meet the requirements needed for the prototype.

4.1 Test Case Names and IdentifiersThe ELDERS group met all the requirements needed for the specific test cases. The test

cases have initialized steps, inputs, procedures, and expected results.

9


Test Category: 1 Description: View access tiers and tier permissions

Test Case: 1.1 Case Name: Access tier viewing

Version: 1.0 Written By: Ben Cortina

Requirements Fulfilled: 3.1.1.1

Purpose: Show that access tiers and permissions are implemented.

Setup Conditions: Logged in as user with permission to view access tiers

Test Case Activity Pass/Fail Comments Expected Result

1 Access administration page

2 Access access tiers

3 Click on a access tier to view permissions

Access tiers are displayed. Permissions for each tier are visible.

Test Category: 1 Description: Request higher tier status

Test Case: 1.2 Case Name: Requesting tier status


Requirements Fulfilled: 3.1.1.1.2

Purpose: Show a user may request a higher tier status.

Setup Conditions: Logged in as existing user


1 Request higher tier status

2 Log in as user with

Access tier request is noted.

10


permissions to set access tiers

3 VIew pending tier promotion requests.

4 Note the request is listed

Test Category: 1 Description: Create new access tier and prove its creation

Test Case: 1.3 Case Name: Create new access tier


Requirements Fulfilled: 3.1.1.2.1, 3.1.1.2.3, 3.1.1.2

Purpose: Demonstrate process of creating a new access tier.

Setup Conditions: Logged in as user with permissions to create access tiers




3 Create new tier

4 Set existing user to newly created tier

Access tier is created and user is assigned to the new tier.

Test Category: 1 Description: Change the default account tier

Test Case: 1.4 Case Name: Change default account tier


11


Requirements Fulfilled: 3.1.1.1.1, 3.1.1.2.2, 3.1.1.2

Purpose: Verify that the default tier may be changed.

Setup Conditions: Logged in as user with permissions change access tiers settings




3 Change default access tier.

4 Create a new account.

5 Show that new account is in the new default tier

User account should be in the default tier.

Test Category: 1 Description: Change a access tier’s permissions

Test Case: 1.5 Case Name: Edit account tiers


Requirements Fulfilled: 3.1.1.2, 3.1.1.2.4, 3.1.1.2.5, 3.1.1.2.5.*

Purpose: Show that the permissions for an access tier may be edited.

Setup Conditions: Logged in as user with permission to edit access tiers



Permission change is reflected in accounts from that tier.

12


2 Access access tiers.

3 Click on a access tier to edit permissions

4 Show every permission from 3.1.1.2.5 is listed

5 Edit at least one permission.

6 Prove that the permission is changed for an account in that access tier

Test Category: 1 Description: Verify Access checks

Test Case: 1.6 Case Name: Access Checks

Version: 1 Written By: Ben Cortina


Purpose: Show that all access checks are in place.

Setup Conditions:● Component source code accessible● Logged in as user with permission to edit access tiers


For each permission,1 Access the

user tiers.2 Show that the

permission is assignable

3 In the relevant source code, show the section that prevents access

The access is prevented for the tested feature and every feature uses a similar system to block access.

13


Once,4 Attempt to

access with an account that does not have the permission

Test Category: 2 Description: The method of creating an account

Test Case: 2.1 Case Name: Account Creation

Version: 1.0 Written By: George Calhoun

Requirements Fulfilled: 3.1.1.3, 3.1.1.3.1, 3.1.1.3.3, 3.1.1.3.4

Purpose: Prove that an account can be created.

Setup Conditions: At website home page


1 Click the Create an Account Link

2 Fill in Account Details

3 Click Register

account is created





Purpose: Show that username redundancy is prevented

14


Setup Conditions:● At website home page● An already created account



2 Fill in Account Details with an already used username

3 Click Register

receive notification that username is already in use




Requirements Fulfilled: 3.1.1.3.3.*

Purpose: Verify that the password restrictions are in place.

Setup Conditions:At website home page



2 Fill in Account Details with an improper username

3 Click Register

Receive alert that the password does not fulfill the requirements

15


Test Category: 2 Description: Making sure registered users are able to log into ELDERS

Test Case: 2.4 Case Name: log in Version: 1.0 Written By: George Calhoun

Requirements Fulfilled: 3.1.1.4, 3.1.1.4.1, 3.1.1.4.2

Purpose: Demonstrate that registered users are able to log in.

Setup Conditions:● At website home page● Account created


1 Fill out User name

2 Fill out password correctly

3 click log in

be logged into your account

Test Category: 2 Description: Making sure only registered users are able to log into ELDERS

Test Case: 2.5 Case Name: Incorrect log in


Requirements Fulfilled: 3.1.1.5, 3.1.1.5.1, 3.1.1.5.2

Purpose: Show that invalid logins call an error.



1 Fill out User name

2 Fill out password

Does not allow the user to sign in and presents them with an error

16


incorrectly3 click log in4 Repeat steps

1-3 with incorrect username

Test Category: 2 Description: Regaining access to an account when the password is forgotten

Test Case: 2.6 Case Name: password reset


Requirements Fulfilled: 3.1.1.6.*

Purpose: Verify that a password may be reset.



1 Click forgot password link

2 fill out box with an incorrect email address for account

3 repeat step 2 with correct email

4 use information in email to reset password

Error message after step 2email sent to the email address after step 3

Test Category: 2 Description: Changing why and how often you receive notifications

17


Test Case: 2.7 Case Name: change notification settings



Purpose: Demonstrate that a user may change their notification preferences.

Setup Conditions:● At website home page● Account created● Account logged in


1 go to account setting

2 change notifications

notifications changed.

Test Category: 3 Description: Voting

Test Case: 3.1 Case Name: Suggested Word Vote

Version: 1 Written By: Josh


Purpose: To expand the Nottoway Language

Setup Conditions: User logon tab in voting section.


1 User accesses administration page

2 User searches for word

3 User prompted of non-existing

User has the opportunity to expand the Nottoway language by voting.

18


word4 Selects either

search or vote5 User changes

their vote


Test Case: 3.2 Case Name: Voting Restrictions to One.



Purpose: Ensure that the Council can only make one vote on a suggested word.

Setup Conditions: User logon and each vote only is obtained only once.


1 User access administration page

2 User votes on word

3 Restricted to one vote per user

A user has one vote.


Test Case: 3.3 Case Name: Able to Change Vote.



Purpose: Change vote due to common error.

Setup Conditions: User logon tab in voting section.

19



1 User accesses administration page

2 User accesses past votes

3 User changes vote

Users are able to change vote at a later time. This updates in the database as still counting only one vote per member.


Test Case: 3.4 Case Name: Threshold Stamp of Approval.


Requirements Fulfilled: 3.1.2.1.3*

Purpose: When the majority of votes are in the words favor.

Setup Conditions: Database will have a count on each word.


1 Enough user votes have been received

2 Words that have reached threshold of votes are marked as approved

Total number of user votes have reached the majority so the suggested word is now added.


Test Case: 3.5 Case Name: Adding New Word to Dictionary



Purpose: Expand the dictionary upon “approved” words.

20


Setup Conditions: Database sees a majority vote and prompts the admin to add to dictionary


1 Administrator notified that word has reached threshold

2 Administrator access administration panel

3 Administrator adds new word to dictionary

Administrator adds suggested word that has reached threshold of user votes to the dictionary.

Test Category: 4 Description: Searching the database for an English word

Test Case: 4.1 Case Name: Successful English Search

Version: 1 Written By: Tatiana

Requirements Fulfilled: 3.1.2.6, 3.1.2.6.2.*, 3.1.2.6.2

Purpose: To test whether searching by English returns the correct information.

Setup Conditions: At dictionary search page


1 Set search to English to Nottoway

2 Enter an English word that is in the database

3 Search

The searched word and all of the data stored for it are displayed.

21


Test Category: 4 Description:

Test Case: 4.2 Case Name: Search Fail

Version: 1 Written By: Terry Stilwell


Purpose: To test what the search will return if it fails to find a word




2 Enter an English word that isn’t in the database

3 Search

User is alerted of failed search


Test Case: 4.3 Case Name: Search Fail Suggestions

Version: 1

Written By: Terry Stilwell

Requirements Fulfilled: 3.1.2.6.1.a-3.1.2.6.1.c

Purpose: To suggest alternatives for a failed search


Test Case Activity Pass/Fail Comments

Expected Result


2 Enter an English word that

Should see suggested

22


isn’t in the database3 Search

words, and votes for suggested words


Test Case: 4.4 Case Name: Edit words that are suggested

Version: 1 Written By: Terry Stilwell

Requirements Fulfilled: 3.1.2.6.1.d

Purpose: To give the user an opportunity to change suggested words




2 Enter an English word that isn’t in the database

3 Search4 Get a list of

suggested words

Should be able to edit the word or words that are suggested

Test Category: 4 Description: Searching the database for a Nottoway word

Test Case: 4.5 Case Name: Successful Nottoway Search


Requirements Fulfilled: 3.1.2.7, 3.1.2.7.2.*, 3.1.2.7.2

Purpose: To test whether searching by Nottoway returns the correct information.

Setup Conditions:

23


At dictionary search page


1 Set search to Nottoway

2 Enter a Nottoway word that is in the database

3 Search

The searched word and all of the data stored for it are displayed.

Test Category: 4 Description: Failed search notification

Test Case: 4.6 Case Name: Search Fail



Purpose: To test whether users receive a notification when they search for a Nottoway word that doesn’t exist.



1 Set search to Nottoway

2 Enter a Nottoway word that isn’t in the database

3 Search

Notify user word doesn’t exist

Test Category: 4 Description: Filter by word

Test Case: 4.7 Case Name: Filter Version: 1 Written By: Tatiana


Purpose: To test that the word filter functions correctly.

24


Setup Conditions: On the syllabary chart page


1 Click on a letter in the chart

All the words that begin with that letter are displayed

Test Category: 5 Description: Displaying the Nottoway history

Test Case: 5.1 Case Name: History Version: 1 Written By: Tatiana


Purpose: To test that the Nottoway history is displayed.

Setup Conditions: On ELDERS Website


1 Click link to the Nottoway history

The Nottoway History is displayed

Test Category: 6 Description: Suggested words by users

Test Case: 6.1 Case Name: Suggestions

Version: 1 Written By: Robert


Purpose: To show what words have been already suggested by current users



25


1 Show suggested words by user

Suggested words are displayed

Test Category: 6 Description: Prompt to suggest words




Purpose: To let the users know about suggested word



1 Prompt to suggested word if no word exists

No words have been suggested, it notifies users of a suggested word from the user

Test Category: 6 Description: Input suggested word




Purpose: To be able to input a suggested word



1 User inputs a suggested word

The suggested word can be inputted

26


Test Category: 6 Description: Submit suggested words




Purpose: To be able to submit a suggested word



1 User submits a suggested word

The suggested word will be submitted to a list of suggested words

Test Category: 7 Description: Website settings

Test Case: 7.1 Case Name: Administration



Purpose: To changes settings on the website

Setup Conditions: On ELDERS database


1 Edit website settings

The edit in the settings has changed for the website

Test Category: 7 Description: Website permissions

Test Case: 7.2 Case Name: Administrations


27



Purpose: To change permissions for administrators and users

Setup Conditions: On ELDERS database


1 Edit website permissions

Permissions have changed for who can and cannot access areas

Test Category: 8 Description: Displaying the Forum

Test Case: 8.1 Case Name: Forum Version: 1 Written By: Tatiana


Purpose: To test that the Forum is displayed.



1 Click link to the Forum page

The Forum is displayed

Test Category: 8 Description: Corresponding forum account and ELDERS account

Test Case: 8.2 Case Name: Forum Account



Purpose: To test that a user’s forum account is the same as their ELDERS account.

28


Setup Conditions: On ELDERS Website, User is logged in


1 Click link to the Forum page

The Forum is displayed and the User is logged in to the forum with an account that corresponds with their ELDERS account.

Test Category: 9 Description: Database

Test Case: 9.1 Case Name: View DB

Version: 1 Written By: Terry


Purpose: Viewing the database proves that it exists.

Setup Conditions: MySQL installed and Nottoway database created


1 SSH into server and then connect to MySQL

2 Type “show databases;”

You will see the database listed.


Test Case: 9.2 Case Name: DB Backup


29


Requirements Fulfilled: 3.3.1.2, 3.3.4.1

Purpose: Prove that the DB is being backed up.

Setup Conditions: Cron job in place with mysqldump that specified date in the file name


1 Write a script that includes the mysqldump command

2 Make sure the script creates a file with the date of the dump

3 Manually run the cron job or wait until the time set (midnight)

You will see the backed up file in the specified directory of the script.


Test Case: 9.3 Case Name: MySQL user



Purpose: Users must exist in order to access the DB.

Setup Conditions: MySQL installed with a root mysql account with highest privileges


1 Log into mysql with the root account

You will see a list of users that includes the newly created one.

30


2 Create a mysql user using the appropriate syntax

3 Set privileges for that mysql user

4 Flush the database

5 Query the DB for a list of users


Test Case: 9.4 Case Name: MySQL User Privileges



Purpose: Make sure that user’s privileges are set.

Setup Conditions: MySQL user already created


1 Once logged into mysql, create a user, a new table, set privileges for the new user to write to that table, and flush privileges

2 Using the new user, insert information into the new table

3 Query the new

The new user will be able to write to the new table and the change can be seen.

31


table to see the inserted row


Test Case: 9.5 Case Name: ALPHABET Table


Requirements Fulfilled: 3.3.1.5*

Purpose: Make sure that the ALPHABET table has the expected columns.

Setup Conditions: The ALPHABET table is already created with the proper columns.


1 Log into mysql using a user with privileges to read the ALPHABET table

2 Change to the Nottoway DB

3 Type describe ALPHABET

You will see the table with the proper columns


Test Case: 9.6 Case Name: HISTORICAL_DICTIONARY Table



Purpose: Make sure that the table has the right columns.

32


Setup Conditions: HISTORICAL_DICTIONARY is created with proper columns.


1 Log into mysql using a user with privileges to read the HISTORICAL_DICTIONARY table


3 Type describe HISTORICAL_DICTIONARY



Test Case: 9.7 Case Name: EXPANDED_DICTIONARY Table




Setup Conditions: EXPANDED_DICTIONARY table is created and has right columns


1 Log into mysql using a user with privileges to read the EXPANDED_DICTIONARY table


33



3 Type describe EXPANDED_DICTIONARY


Test Case: 9.8 Case Name: NUM_VOTES Table




Setup Conditions: At website login page


1 Log into mysql using a user with privileges to read the NUM_VOTES table


3 Type describe NUM_VOTES



Test Case: 9.9 Case Name: Password


34


Encryption


Purpose: Make sure that the passwords are encrypted in the DB.

Setup Conditions: A user is created and the password is encrypted in the DB


1 Log into mysql with the root account.

2 Query the database with the user and password columns from the mysql.user table

You will see the users and their encrypted passwords

Test Category: 10 Description: Displaying the Syllabary

Test Case: 10.1 Case Name: Syllabary



Purpose: To test that the Syllabary is displayed.



1 Click link to language section

Syllabary chart displayed

Test Category: 10 Description: Browse the Grammar

35


Test Case: 10.3 Case Name: Grammar



Purpose: Verify the user can access the Nottoway grammar.

Setup Conditions: On a page in the language section


1 Click on the Grammar link

Display the basic grammar rules of the Nottoway language

Test Category: 11 Description: Viewing ELDERS on a mobile device

Test Case: 11.1 Case Name: Mobility

Version: 1 Written By: George


Purpose: Confirming the ability for ELDERS to be viewed on a mobile device.

Setup Conditions: Using a mobile device


1 Navigate to the ELDERS web page using the device

The ELDERS web page looks the same as when viewing it through a computer.

Test Category: 11 Description: Viewing ELDERS through multiple web browsers

Test Case: 11.2 Case Name: Versatility

Version: 1 Written By: George

Requirements Purpose: Confirming that ELDERS can be used correctly

36


Fulfilled: 3.3.4.3 through different web browsers that are commonly used.

Setup Conditions: On a computer with multiple Internet Browsers


1 Open Internet Explorer

2 Navigate to ELDERS web page

3 Repeat steps 1 and 2 with Firefox

4 Repeat steps 1 and 2 with Chrome

5 Repeat steps 1 and 2 with Safari

All 4 browsers should load ELDERS without error, and should all look approximately the same

Test Category: 12 Description: Check for software update

Test Case: 12.1 Case Name: Software Update

Version: 1 Written By: Ben Cortina


Purpose: Show that there is a means to update software used by ELDERS

Setup Conditions: On a computer with multiple Internet Browsers


1. Open Joomla administration page

2. Navigate to the Extension Manager

3. Click Update

Any updates for outdated Extensions should be listed.

37


4. Click purge cache

6 Click FInd Updates

5 Traceability to Requirements

Each test will provide a requirement that has been met. The table provides a matrix with a

requirement ID labeling each row and a test case ID on each column. In the resulting grid, an X

means that the requirement on that row is fulfilled by the test case on that column.

Test Case ID

Component Requirement ID 1.1 1.2 1.3 1.4 1.51.6 2.1 2.2 2.3 2.4 2.5 2.6

Create Tiered Account System 3.1.1.1 X

3.1.1.1.1 X

3.1.1.1.2 X

Manage Tier System 3.1.1.2 X X X

3.1.1.2.1 X

3.1.1.2.2 X

3.1.1.2.3 X

3.1.1.2.4 X

3.1.1.2.5 X

3.1.1.2.5.a X

3.1.1.2.5.b X

3.1.1.2.5.c X

3.1.1.2.5.d X

3.1.1.2.5.e X

3.1.1.2.5.f X

38


3.1.1.2.5.g X

3.1.1.2.5.h X

3.1.1.2.5.i X

3.1.1.2.5.j X

3.1.1.2.5.k X

3.1.1.2.5.l X

3.1.1.2.5.m X

3.1.1.2.5.n X

3.1.1.2.5.o X

3.1.1.2.5.p X

3.1.1.2.5.q X

3.1.1.2.5.r X

3.1.1.2.5.s X

3.1.1.2.5.t X

User Registration 3.1.1.3 X

3.1.1.3.1 X

3.1.1.3.2 X

3.1.1.3.3 X

3.1.1.3.3.a X

3.1.1.3.3.b X

3.1.1.3.3.c X

3.1.1.3.3.d X

3.1.1.3.4 X

User Login 3.1.1.4 X

3.1.1.4.1 X

3.1.1.4.2 X

3.1.1.5 X

3.1.1.5.1 X

3.1.1.5.2 X

User Account Management 3.1.1.6

3.1.1.6.1 X

3.1.1.6.2 X

3.1.1.7

3.1.1.8

Voting 3.1.2.1

3.1.2.1.1

39


3.1.2.1.2

3.1.2.1.2.a

3.1.2.1.3

3.1.2.1.3.a

Grammar 3.1.2.3

3.1.2.5

Dictionary 3.1.2.2

3.1.2.4

3.1.2.6

3.1.2.6.1

3.1.2.6.1.a

3.1.2.6.1.b

3.1.2.6.1.c

3.1.2.6.1.d

3.1.2.6.2

3.1.2.6.2.a

3.1.2.6.2.b

3.1.2.6.2.c

3.1.2.6.2.d

3.1.2.6.2.e

3.1.2.6.2.f

3.1.2.7

3.1.2.7.1

3.1.2.7.2

3.1.2.7.2.a

3.1.2.7.2.b

3.1.2.7.2.c

3.1.2.7.2.d

3.1.2.7.2.e

3.1.2.7.2.f

3.1.2.7.2.g

Website 3.1.2.8

3.1.2.9

3.1.2.9.1

3.1.2.9.2

3.1.2.10

40


Suggestion 3.1.2.11

3.1.2.11.1

3.1.2.11.2

Database Creation 3.3.1.1

Database Backup 3.3.1.2

Database Users 3.3.1.3

3.3.1.4

Database Tables 3.3.1.5

3.3.1.5.a

3.3.1.5.b

3.3.1.6

3.3.1.6.a

3.3.1.6.b

3.3.1.6.c

3.3.1.6.d

3.3.1.6.e

3.3.1.7

3.3.1.7.a

3.3.1.7.b

3.3.1.7.c

3.3.1.7.d

3.3.1.7.e

3.3.1.8

3.3.1.8.a

3.3.1.8.b

Encryption 3.3.2.1

Authentication 3.3.2.2 X

Update 3.3.3.1

Reliability 3.3.4.1

3.3.4.2

3.3.4.3

Table 3. Traceability Matrix for the ELDERS prototype

41

Date post:	24-Aug-2019
Category:	Documents
Upload:	trinhanh
View:	213 times
Download:	0 times

€¦ · Web vie

Documents