SRS document on library database, Sample Template is provided

Kazim

SRSsampledocument.pdf

Home >Computer Science homework help >SRS document on library database, Sample Template is provided

Testing TOM Software Requirements Specification

TBBC

Software Requirements Specification

Project name: Testing TOM

Application name: Testing TOM

Customer: Petah Gibbs & Andrew Lewis

Version:0.4

Date:7/11/2014

Status: Draft

Testing TOM Software Requirements Specification

For more information

TBBC contact Customer contact

Ben Barker Petah Gibbs

Project Manager Project Sponsor

bbarker@students.ballarat.edu.au p.gibbs@ballarat.edu.au

Telephone (03) 5327 3461 Telephone (03) 5327 9873

Revision History:

Version Date Author(s) Change Description

0.1 24/04/2007 Cliff Vander Wel First draft.

0.2 14/5/2007 Cliff Vander Wel Second Draft - all sections updated

0.3 08/05/2007 Cliff Vander Wel Third Draft – Use cases added, Requirements updated

0.4 21/05/2007 Tate Lesko Updated diagrams, Section 1 completed & Requirements re-worked

Approvals:

Please See Section 5 for Signed Approvals of this Document.

Testing TOM Software Requirements Specification

Table of Contents

1 Project overview ................................................................................................................. 5 1.1 Definitions & Acronyms ................................................................................................ 5 1.2 Referenced Documents or Notes ................................................................................. 5 1.3 Project name ................................................................................................................. 6 1.4 System Overview .......................................................................................................... 6 1.5 System Objectives ........................................................................................................ 6 1.6 Support ......................................................................................................................... 7 1.7 Stakeholders ................................................................................................................. 7 1.8 System Context ............................................................................................................ 8 1.9 Acceptance Criteria ...................................................................................................... 8 1.10 Evaluating Success .................................................................................................. 9

2 General Description ............................................................................................................ 9 2.1 Product Functions ......................................................................................................... 9 2.2 User Characteristics ................................................................................................... 10 2.3 Assumptions and Dependencies ................................................................................ 10 2.4 Product Outlook .......................................................................................................... 10

2.4.1 User Interfacing .................................................................................................. 10 2.4.2 Memory Constraints ........................................................................................... 15 2.4.3 Operations ......................................................................................................... 16 2.4.4 Adaptation / Compatibility Requirements ........................................................... 16

2.5 User Base ................................................................................................................... 16 2.6 General Design Constraints ....................................................................................... 17 2.7 Project Feasibility........................................................................................................ 17

3 Requirements ................................................................................................................... 18 3.1 Functional Requirements ............................................................................................ 18 3.2 Non-functional Requirements ..................................................................................... 22 3.3 Automatically generated value Rules ......................................................................... 22 3.4 Interface Requirements .............................................................................................. 23

3.4.1 User Interfaces ................................................................................................... 23 3.4.2 Interface Storyboards ......................................................................................... 23 3.4.3 Hardware Interfaces ........................................................................................... 24 3.4.4 Software Interfaces ............................................................................................ 24 3.4.5 Communications Protocols ................................................................................ 24 3.4.6 Site Map ............................................................................................................. 24

3.5 Hardware Requirements ............................................................................................. 25 3.5.1 Client-side .......................................................................................................... 25 3.5.2 Server-side ......................................................................................................... 25

3.6 Software Requirements .............................................................................................. 25 3.6.1 Client-side .......................................................................................................... 26 3.6.2 Server-side ......................................................................................................... 26

3.7 Database Requirements ............................................................................................. 26 3.7.1 Entity-Relationship Diagram .............................................................................. 26 3.7.2 Entity-Relationship Diagram Notes & Assumptions ........................................... 27 3.7.3 Database Schema ............................................................................................. 28

3.8 Extra Quality Requirements ........................................................................................ 29 3.9 Training Requirements ............................................................................................... 29

Testing TOM Software Requirements Specification

4 Appendixes ....................................................................................................................... 29 4.1 Appendix A - Context diagram .................................................................................... 29 4.2 Appendix B – DFD (Level 0) ....................................................................................... 30 4.3 Appendix C - Deployment Diagram ............................................................................ 31 4.4 Appendix D - Use case model .................................................................................... 32 4.5 Appendix E - Activity diagrams ................................................................................... 32 4.6 Appendix F – Testing TOM Survey’s .......................................................................... 36 4.7 Appendix G – Auto Generated Emails ....................................................................... 36 4.8 Appendix H – Level Progress Diagram ...................................................................... 37

5 Sign-off ............................................................................................................................. 41 5.1 Client Sign-off ............................................................................................................. 41 5.2 Team Sign Off ............................................................................................................. 41

Testing TOM Software Requirements Specification

1 Project overview

This section is designed to give an overview of the project.

1.1 Definitions & Acronyms

The following definitions and acronyms are used throughout this Document (Software Project Management Plan) they may refer to terms used by the client or by the development team.

Term Meaning

PM Project Manager

SPMP Software Project Management Plan

SRS Software Requirements Specification

SDD Software Design Document

MTP Master Test Plan

DTP Detailed Test Plan

UD User Documentation

TP Test Plans

TOM Theory of Mind

BSSH Behavioural & Social Sciences & Humanities

ITMS Information Technology and Mathematical Sciences

IEEE Institute of Electrical and Electronics Engineers

WBS Work Breakdown Structure

QAM Quality Assurance Manager

PHP Hypertext Pre-Processor

DFD Data Flow Diagram

Admin Administrator

1.2 Referenced Documents or Notes

Document Number / Location / URL

Reference Description/Name

/Tender.doc Tender for Testing TOM application

/TOM proposal.doc Original client project proposal

Testing TOM Software Requirements Specification

1.3 Project name Testing TOM (Theory of Mind)

1.4 System Overview

The purpose of this project is to develop an application that displays a series of TOM

tests in an enjoyable manor to the user via an animation/game. The results of these

tests would need to be stored for analysis by the clients. To reach the greatest

amount of users the tests will be delivered to the user via an online website. The

data collected will be used to compare electronic tests to traditional paper tests and

give more information on the growing psychological field of TOM.

A back end MYSQL database will be created to serve as the primary data store for

the testing Tom application. The database will be used to store user, group and test

details used in site operation as long as the results from the TOM tests. Finally all

the results stored in the database will be exported to a statistics package called

SPSS which is currently being used by the client.

1.5 System Objectives � TOM Tests:

The Tests are the most important area of the system. The objectives for the tests can be broken down into three distinct points:

o The tests need to be comparable to the paper based tests so the data between the two methods is comparable.

o Simplicity of the tests is crucial, children aged from 3 to 5 years of age need to be able to complete and comprehend the tests. This will allow the client to examine is “tester bias” has any effect on testing TOM

o Quality of data collected, the system should take all steps possible to ensure that the data collected is of a high quality.

� Manage Tests:

The Administrators of the system need to be able to manage all aspects of the TOM application. This includes being able to create/change/delete tests, users and groups where applicable.

� Export Data:

The data from the TOM tests needs to be exported into the Statistics package SPSS which is currently being used by the clients to analyze data from other studies which they undertake.

� Website:

The Testing Tom system will be delivered to the users via an online website. This is to try and reach the largest audience possible. With this the site must be as

Testing TOM Software Requirements Specification

low-bandwidth possible and still produce the same results over a dial-up connection as with somebody on the university network.

� Security/Privacy:

With the nature of the application and the data that is and could be stored the team must implement a strategy so that personal details are not stored and can not be linked to results.

1.6 Support

Once the Testing TOM application has been deployed and is fully operational, any support or maintenance is out of the scope for this project. If support or maintenance is requested by the client it will be negotiated separately at that point at additional costs.

1.7 Stakeholders

Users:

The end users are a combination of a parent and child which can be aged from

anywhere from 2 years of age to 7 years (Depends on test conditions, and discretion

of the test organiser). The parent will be entering information such as username and

password and answers to a variety of surveys. The parent may also need to read

questions to the child if they are unable to read. In addition to reading the test the

parent may also be required to navigate the tests and select answers for the child if

the child is unable to do so.

Administrators:

An administrator will be a person who is in charge of test/group. They may be the

clients Petah or Andrew but they may also be other staff or PHD/Honours that have

been selected to manage a group within the testing TOM application.

Super Administrator:

The super Administrator for this application will be shared between Petah and

Andrew. The super Administrator will only change if the client decides to deploy the

system on another network (outside of scope for this application and will need to be

arranged with project team).

Development team:

The development team is made up of four members; Ben Barker, Tate Lesko, Brad

Parson and Cliff Vander Wel.

Testing TOM Software Requirements Specification

University:

The University of Ballarat contact for this application is:

Ms Kathleen Keogh

Lecturer

School of Information Technology and Mathematical Sciences

University of Ballarat

P.O. Box 663, Ballarat, Vic. 3353

Phone: 03 5327 9121

Email: k.keogh@ballarat.edu.au

The University has vested stake in the project. If the project is a failure it will reflect

poorly on the university and maybe detour future prospective clients from undertaking

a project with a project team.

1.8 System Context

The Testing TOM application will be installed on the University of Ballarat’s Network,

specifically the “uob-community” server. For a diagram illustrating how the Testing

TOM system will be incorporated into the university network please see Appendix C.

1.9 Acceptance Criteria

The criteria for acceptance of the project are; after system and user acceptance

testing has been completed there is no Severity 1 or Severity 2 (for a definition of

Severity rating see below) issues outstanding, the project will be accepted by the

clients and move into the close-out phase of the project.

Severity 1: A Problem has been identified that makes the continued use of one or

more functions impossible (or severely restricted)

Severity 2: A Problem has been identified that severely affects or restricts major

functionality. The Problem is of a time sensitive nature and important to long-term

productivity but is not causing an immediate work stoppage.

Severity 3: A minor Problem that does not have major affect on business operations

Severity 4: A minor condition or Documentation error that has no significant affect on

the Customer’s operations

Testing TOM Software Requirements Specification

1.10 Evaluating Success

The success of the project will be based off a variety of different sources, they are as

follows:

� Succeeding the acceptance criteria.

� User feedback from UAT

� Feedback from clients

� University feedback

2 General Description

2.1 Product Functions The Testing TOM application will incorporate and consist of many specific functions with the primary aim of reducing the amount of maintenance required. It will reduce the amount of labour involved in undertaking studies related to Theory of Mind and significantly increase the speed and ease in undertaking these studies. It will also provide an alternative way of undertaking the testing of Theory of Mind and provide the capacity to compare between two different types of testing – traditional paper-based and electronic.

These functions will be designed with interfaces that are as user friendly as possible to allow a broad range of end users, both subjects of studies and administrators, to use the application.

The main functions of the system are as follows:

� Display tests

The site should display tests on the screen in an order specified by the client. Users will be provided with a means of selecting an answer of their choosing, with no answers being shown to the user.

� Record data

Upon selecting an answer, it will be recorded in a back-end database which will also be used as the basis for the downloading of data.

� Surveys

A variety of surveys, dependant on the stage at which the testing concludes, will be presented which are primarily aimed at the parent(s) to complete to obtain more detailed information about the child at that particular time. This will assist in provide additional information as to when a child chooses a particular answer.

� Administration area

An administration area is required to allow the client a variety of functions, these include the ability to create and manage users and create and manage study groups. This will be where administrators will be able to download data collected from their study groups.

Testing TOM Software Requirements Specification

� Download Data

The ability to download data collected from study groups is required, which will be included in the Administrator section. The data available to download will be dependant on whether the administrator is the owner of any study groups and whether these studies have finished as per the specified end time.

2.2 User Characteristics At this stage, it has been determined that the system will comprise of three user types:

� Users

Users of the system are the children that are subjects of studies undertaken and their parents, who are expected to be present whilst children are undertaking the tests.

� Administrators

Initially, the clients will be the only ones with administrative accounts; however, the ability to add and delete administrators is required to increase the use and scalability of the system.

� Super administrators

During installation of the system, a super administrator will be created enabling the ability to add and remove administrators. This user will not have general access permissions associated with Administrators.

2.3 Assumptions and Dependencies

� With a detailed test plan, it is assumed that the client will be able to sufficiently

maintain the system without requiring help from external parties.

� Development, installation and testing of the system are dependant on server space

being made available, set up and provided by Information Services in conjunction

with the client.

� The project team (as students) will be able to access all software required for

development of the system. Where possible, open source or freeware software will be

used.

� Initial testing will be conducted by the client through a prototype.

2.4 Product Outlook

2.4.1 User Interfacing

2.4.1.1 Use Cases

This section demonstrates certain functions of the designed solution using high level use case diagrams (or examples). Each use case is spelt out and the corresponding use case diagram found in Appendix D.

� Use Case 1 – Super Administrator Login

Actors: Super Administrator, being either of the 2 clients.

Procedure:

Testing TOM Software Requirements Specification

1. Client opens the initial Login page of the website

2. The Client then enters the Super Administrator username and password

in the corresponding fields.

3. The system verifies this information and if correct and matches the right

level of access for a Super Administrator, then it takes them to the Super

Administrator main page.

4. Once logged in, the client will have access to perform the main Super

Administrator functions, such as managing Administrator Users.

Exceptions:

1. Client has entered user details which do not match level of access

required for the Super Administrator. If this happens, client will either

have to try again or be taken to the corresponding main page for that

user.

Database requirements:

‘User’ table will be accessed. ‘Username’, ‘password’ and ‘level’ will be read.

Note: Use Case 1 is a pre-requisite of some other use cases. This is noted at the beginning of their individual procedure section.

� Use Case 2 – Manage Administrator Users

Actors: Super Administrator.

Procedure:

1. Use Case 1 must be performed prior to this task.

2. Once the client has logged on as Super Administrator, they will be

presented with a list of options. Included in this list will be Manage

Administrators.

3. Once the Manage Administrators option is selected, the client will be

provided with a page which will display all the current Administrators.

The Client will then be able to add new administrators, or modify or

delete current Administrators.

Exceptions:

1. The client has logged in as an Administrator and not as the Super

Administrator. This will provide them with the normal functionality of the

Administrators and not the Manage Administrators function.

Database requirements:

‘User’ table will be accessed. ‘username’, ‘password’ and ‘level’ will be read.

Testing TOM Software Requirements Specification

� Use Case 3 – Administrator Login

Actors: Administrator, can be either the clients, or possibly PHD students who the clients have set up as Administrators. The clients will have both a Super Administrator account as well as a Administrator account.

Procedure:

1. The user opens the initial Login page of the website

2. The user then enters their Administrator username and password in the

corresponding fields.

3. The system verifies this information and if correct and matches the right

level of access for an Administrator, then it takes them to the

administrator main page.

4. Once logged in, the user will have access to perform the Administrator

functions, such as managing groups, download results data and mange

user details.

Exceptions:

1. User has entered user details which do not match level of access

required for an Administrator. If this happens, the user will have to try

again, and if unsuccessful 3 times, will have to contact a Super

Administrator.

Database requirements:

‘User’ table will be accessed. ‘Username’, ‘password’ and ‘level’ will be read.

� Use Case 4 – Manage Groups

Actors: Administrator.

Procedure:

1. Use Case 3 must be performed prior to this task.

2. Once the user has logged on as Administrator, they will be presented

with a list of options. Included in this list will be Manage Groups.

3. Once the Manage Groups option is selected, the user will be taken to a

page which will display all the current groups. The user will be able to

delete or create groups from this page.

4. If the user selects to create a group, they will have to provide the group

name, select the users to be added to the group and the level’s to be

used for this group.

Exceptions:

1. If an Administrator accidentally creates a group, they can delete it on this

same manage groups screen.

Testing TOM Software Requirements Specification

Database requirements:

‘User’ will be accessed and read. ‘Group’, ‘grouplevel’ and ‘participants’ will be modified.

� Use Case 5 – Download Results Data

Actors: Administrator.

Procedure:

1. Use Case 3 and 7 must be performed prior to this task.

2. Once the user has logged on as Administrator, they will be presented

with a list of options. Included in this list will be Download Results Data.

3. Once the Download Results Data option is selected, the user will be able

to specify which results they want and they will be downloaded from the

database into the statistics package SPSS.

Exceptions:

1. None

Database requirements:

‘Testresult’ will be accessed and read.

� Use Case 6 – User Login

Actors: End User. This will be the Child and Parent participating in the tests.

Procedure:

1. The user opens the initial Login page of the website

2. The user then enters their username and password that they have been

provided by the Client.

3. The system verifies this information and if correct, it takes them to the

user’s main page.

4. Once logged in, the user will have access to perform the user functions,

such as take test and mange user details.

Exceptions:

1. User forgets password. There will be a button on the login page for

people who forget their username or password. If the user forgets their

password they can reset their own password (back to the original

password provided to them on their form).

2. User forgets username. If the user has forgotten their username as well,

they will be directed to a page that will show them the contact details of

Testing TOM Software Requirements Specification

the Super Administrator as they will need to check the paper work to find

out which user to reset.

Database requirements:

‘User’ table will be accessed. ‘Username’, ‘password’ and ‘level’ will be read.

� Use Case 7 – Take Tests

Actors: End User.

Procedure:

1. Use Case 6 must be performed prior to this task

2. Once the user has logged on, they will be presented with a list of options.

Included in this list will be Take Test.

3. Once the Take Test option is selected, the parent will be shown a page

with information on the tests and how to complete them.

4. Then the parent will be asked to complete a small survey on the child.

5. After this survey, the child goes through the first level of tests.

6. Provided the child passes the first level, they then continue on to

complete the rest of the tests to be completed by this study group, which

is defined by the Administrator when setting the group up.

7. Upon completion of the test, the parent will be asked to complete another

short survey.

Exceptions:

1. Child fails the first level of tests. If this happens, the parent will have

another different survey to complete but ultimately this will show that the

child is not able to understand the system yet.

2. The child takes longer than allowed to complete the test (longer than 60

mins to complete the test). If this happens, all the data collected so far

will be disregarded. When the user next logs in, there will be a message

to advise that the user will have to complete the test again from the start.

3. User stops test willingly. If this happens the parent will again be asked to

complete a survey, and told to do the tests again form the start.

Database requirements:

‘Test’ table will be accessed and read. ‘Testresult’ will be read and modified.

� Use Case 8 – Manage Users

Actors: Administrator and End User.

Procedure:

Testing TOM Software Requirements Specification

1. Use Case 6 or 3 must be performed prior to this task

2. Once either an administrator or end user has logged on, they will be

presented with a list of options. Included in both these lists will be

Manage User Details.

3. If a end user selects this option, they will be able to change their own

password by entering their old password, a new password and

confirming the new password.

4. If an administrator selects this option, they can reset the password of any

end user.

Exceptions:

1. None

Database requirements:

‘User’ table will be accessed. ‘Username’, ‘password’ and ‘level’ will be read.

2.4.1.2 Activity Diagrams

The activity diagrams show the basic flow of the main processes. They are located in Appendix E of this document.

2.4.2 Memory Constraints

The system, in general, will not require a large amount of memory or processing capacity. The maximum number of simultaneous connections / users is not expected to be any more than five. Although unforeseen and outside of the scope of this project, should the use of the system expand significantly by the University of Ballarat or other organisations, it is possible that the capacity may be breached and future upgrades to memory, processor or bandwidth may be required.

The hard disk space the application takes up should be no more than 100MB, as it will primarily consist of text files such as HTML, PHP, CSS and JS. The largest files in the system will be the images and animations used to display the Theory of Mind tests. It is expected that the application will not take up any more than fifty megabytes (50MB) of hard disk space. Should more storage space be required, this will need to be arranged between the client and Information Services through the appropriate protocols.

There should be no issues with database space available. Should the storage space reach a critical point, the client will need to discuss with Information Services, through the necessary protocols, to increase the amount of space available. It is estimated that the database will take up no more than fifty megabytes (50MB).

An empty table is expected to take approximately one kilobyte (1KB); subsequently, the database is estimated to take up no more than 10KB at the time of installation. A further estimate has been conducted of the space the database will require when fully populated. This has been done on a per table basis, inclusive of the 1KB required to store the table schema, and is outlined below:

Testing TOM Software Requirements Specification

Table Maximum size per record

Maximum number of records

Total Size Estimate

User 0.145 1000 146

Participants 0.14 1000 141

Group 0.65 50 37.5

GroupLevel 0.04 500 20

Level 0.3 10 4

Test 0.07 40 4

TestResult 0.07 12000 841

Logging Estimation of this table has not been completed. If we should have this table, it probably should be limited to a certain size. Could get massive otherwise.

TOTAL: 0.28 4365 10MB

The figures outlined above are estimates and provide only an indication of the size the database may potentially reach.

Visits to the application will be by a targeted focus group. Subsequently, it is unforseen that any more than one or two users will be accessing the application simultaneously. The application should, however, allow for X users to be using it simultaneously with no noticeable affects on overall performance, such as load times and data retrieval and storage.

2.4.3 Operations

Development of the Testing TOM application will be undertaken with the view that the final product requires as little software maintenance as possible. The only maintenance requirements will be the addition/removal of administrators and users that become subjects of studies set up. The system will contain this functionality through an administrative area; which will be designed in a way to allow point-write-click so that little technical knowledge and user interaction is required. This will also allow the application to be passed onto new users and be able to be used with minimal training.

2.4.4 Adaptation / Compatibility Requirements

At this stage, it is possible that the system will require further adaptation; however, this falls outside the scope of this project. There is the potential that the system may be provided to other Universities and research organizations; however, there has been no indication that the ability to do this is required for the purposes of this project.

The client has indicated that, for the purposes of this project, the system will only be hosted on one server within the University of Ballarat. The compatibility requirements will be provided by the client and development will occur being mindful of these requirements.

2.5 User Base

The user base of the system will be quite restricted and limited. It will be, primarily, children between the ages of two and four years and their parent(s). It is expected that, generally, the parents will be in their mid-to-late twenties and early thirties, although not confined to this age group. Other users of the system are administrators, which may be academic staff or students. These administrative users will contribute to the growth of the user base as research is conducted. It is not expected that the user base will grow outside of these authorised users.

Testing TOM Software Requirements Specification

2.6 General Design Constraints

The following constraints may affect the way in which the solution is designed and developed:

� Scope

The scope is bound by the requirements and needs outlined by the client and is also the skills and abilities of the project team. Due to the project team’s lack of knowledge and skills with Macromedia Flash, this restricts one facet of the project that the project team can undertake, however, through managed outsourcing, this becomes possible.

� Time

Time is the major constraint on this project. Time will be restricted to one university year, divided into two teaching periods. During the first teaching period, initial documentation, planning and client contact shall occur along with the development of a prototype. This prototype will be provided to the client so that any obvious issues can be brought up before commencement of the main development phase. In the second teaching period the development, testing and implementation will be undertaken.

� Cost

It is not expected cost will constrain the project in any way. As it is a student project and the clients belong to a University, the required infrastructure is already in place and graphic/animation can be done within the project team or outsourced to an external party without fee, the application will cost nothing to produce

� External Constraints

The system is restricted to the supplied format of stock sheets and must be capable of reading this format. Stock sheets will vary between suppliers and may change over time. The stock sheets are created and distributed by the supplier and their format cannot be controlled.

2.7 Project Feasibility � Economic

The project is economically feasible as the system will be incorporated within existing infrastructure. There will be no costs associated with web hosting and domain name purchasing as the University of Ballarat already owns infrastructure capable of hosting and a domain name.

� Operational

This document has been written with the prior establishment that the project is operationally feasible. The idea behind it is to make conducting studies more self- sufficient and less labour intensive. The ability to download data collected is designed with the aim of eliminating the practice of manually entering data into the tool that allows analysis of that data. The system will allow the client to broaden the scope of studies undertaken.

� Technical

The technical feasibility of the project is under the control of the project team and client. All factors including project team skills and abilities and the capacity and

Testing TOM Software Requirements Specification

capability of the hosting infrastructure will be taken into consideration when designing the solution to ensure that the project is technically feasible.

� Legal / Political

There are no political issues that are likely to affect the feasibility of the system.

There are two legal issues that may affect the feasibility of the system.

− If either party was to sell the product with the intention of making a profit and

issue could arise as to royalty entitlements. The probability of this situation

occurring is low; however, could occur as there is the possibility of other

Universities and research organisations using the system.

− There may also be a legal issue with the use of the tests in this system. This

issue will be minimised as the tests will be created specifically for and be

unique to this system, with the only similarity being the concept behind the

tests.

� Ethical

There are no ethical issues that affect the feasibility of the design and build of the system. Some ethical issues affect the use of the system; however, this is the full responsibility of the client, and eventual users, and does not fall within the scope of the project.

3 Requirements This section outlines all the requirements for the testing TOM application. The term “user” in this section refers to the end user, the child and parent stakeholders as outlined in section 1.7 under user and not all three types of user accounts.

3.1 Functional Requirements This section details all the functional requirements for the testing application.

Functional Requirement ID

Requirement Title Requirement detail

Priority

Essential / Conditional / Optional

FR001 Authentication The system will provide functionality to allow the users; admin’s and super admin’s to log in to the system with the username and password previously created. On successful entry of username and password they will be guided to the appropriate page depending on the account type defined on creation. If the details provided are for a “user” they will be directed to the main/user details page. If the details entered match an admin or super admin account, they will be directed to the main admin page.

Essential

FR002 Unable to Login If the user enters either a wrong username or password they we be denied access to

Essential

Testing TOM Software Requirements Specification

the system. On five incorrect tries the user will locked out from using that username for an hour. The system will inform the user that they have been locked out and can try again in an hour’s time. If the user retains the original invitation they will be asked to contact the person listed on their invitation. As a last resort option the user will be shown an email and phone address to contact if they have forgotten their password and or username and there original invitation. At this point the admin must lookup the details manually.

FR003 Enforce Change When a user has logged into the system for the first time they will be forced to change their password before they can proceed. Admin and super admin accounts will not be required to change their passwords. All user passwords will be required to be at least six characters.

Essential

FR004 Log out As the super admin account cant perform admin functions and vice-versa all three types of accounts need the ability to log out from the system and login with a different username and password if need be.

FR005 Super admin The super admin account will be created upon installation of the testing TOM application. The Super Admin account will be a shared between the clients Petah Gibbs and Andrew Lewis. The super admin account will be designed not be used for day-to-day administrative functions, therefore Petah and Andrew will need to create normal admin accounts for themselves. The only functions a super admin can use are create/disable/reset password/delete admin users.

Essential

FR006 Admin When an admin user has successfully logged in they will be presented with the following functions; manage group, manage user and export data. These functions will allow the admin’s to manage all areas of the tests.

Essential

FR007 Manage Group The Manage group screen will provide an admin links to create a new group, add users to a group and to delete a group.

Essential

FR008 New Group An admin user has the ability to create a new group. The group name will be automatically created by the system in the following format; group##, where ## is an auto-incrementing number starting at 01. The admin will have the choice of either a cross sectional or longitudinal study when creating a group. When creating a group the admin will be presented with a choice of levels to select for this group to take. A new group will also require the username of the admin for that group to be entered.

Essential

FR009 Cross sectional A cross sectional group requires that the admin only enters a start and end date for the tests that will be completed.

Essential

Testing TOM Software Requirements Specification

FR010 Longitudinal Longitudinal groups require a start date, an end date, test window and the length of time between tests.

Essential

FR011 Add users to group An admin will have the ability to add any users which are not already entered into a group into a previously created group.

Essential

FR012 Delete Group An admin will be able to delete the group that they are assigned to them after they have exported the data for that group into a SPSS file.

Essential

FR013 Manage User The Manage user screen will provide links for an admin to create a new user, reset a user password, disable a user and delete a user from the system.

Essential

FR014 Create User An admin will have the ability to create new users for the system. The username and password are automatically generated by the system see section 3.4 for details. The admin will also have the ability to put the user straight into a previously created group, by selecting them from a list.

Essential

FR015 Delete User If a admin decides that a user no longer needs to be entered into the system they can select users assigned to them and delete them.

Essential

FR016 Reset password If an admin has received an email or phone call asking for a password reset from a user they will open the control user screen. Under reset password, the admin will be required to enter the username of the user to be reset. The system will then reset the password to original password. If the user still has the invitation they will be told to use that password. If they do not have the invitation they will be told the password by the admin.

Essential

FR017 Disable user On the control user screen the admin will be able to enter a username to be disabled. If a user is disabled they will no longer be able to complete tests and their already recorded data will be removed from the database. When a disabled user logs in they well displayed a message stating that they have been disabled and they can no longer use the testing TOM system.

Essential

FR018 Auto-Disabled In addition to the ability to disable a user the testing TOM system will automatically disable users which have failed to complete tests in time.

Essential

FR019 Track Usage Via the control user screen the admin will be able to enter a username and the system will display the usage of this user. The system will need to display dates logged in and tests completed.

Essential

FR020 Emails The testing TOM system will create auto- generated emails and send them to the designated admin when important dates for there group have been reached. For cross sectional groups these dates are the start and end date. For longitudinal it will be start date and end date for each round of tests

Essential

Testing TOM Software Requirements Specification

that need to be completed. The content and structure of these emails is defined in appendix G.

FR021 Export Data When a group’s end date has been succeeded or all the users have completed all the designed tests an admin can export the data into a SPSS file. The saving of files (including naming and location) will be handled by the Web browser of the user.

Essential

FR022 User After a user has successfully logged in to the system they will be directed to a page displaying information about the tests that they will take. From this screen they will have a link which will start the tests.

Essential

FR023 Introduction The first time the user attempts to take a test they will presented with an introductory page which will tell the user about the purpose of the tests and how to use the system effectively.

Essential

FR024 Commencing survey

When a user has clicked to take the tests they will be presented with a survey that the parent will complete in regards to the child’s current mood and other factors which will impact on the results. For preliminary survey structure and content please see appendix F.

Essential

FR025 New window The actual tests for the testing TOM application (including level 1) will appear in a new window to remove distraction.

Essential

FR026 Level 1 The first level of tests that the user will complete are not related to TOM and are just to tests that the user can operate the mouse and follow basic instructions. If the user is unable to complete level 1 then they will not move onto the remaining TOM tests.

Essential

FR027 Failed Level 1 Survey

If the user has failed the first level of tests they will not complete the TOM tests. At this point the user will be presented with the survey as listed in appendix F.

Essential

FR028 Tests When the user has successfully completed level 1 they are then presented with the TOM tests. The TOM tests will follow the process as outlined in appendix H. The system needs to store the answer chosen by the user and accurately measure the time it took for the user to make that selection.

Essential

FR029 Time out If the user takes more then sixty minutes to complete the whole series of tests (all levels selected by the admin for that group) the system will time out. The time out will inform the user that they have taken too long to complete the tests and need to try again later.

Essential

FR030 Exit strategy The user will always need the ability to exit the TOM tests other then resorting to closing the window.

Essential

FR031 Early exit survey If the user had begun taking the TOM tests but has chosen to exit before completing all the tests the user will be presented with an early exit survey as listed in appendix F.

Essential

Testing TOM Software Requirements Specification

FR032 Success Survey If the user has completed all the tests allocated for them the application will ask the user to complete a survey. For details of this survey see appendix F.

Essential

FR033 Testing completed After the final survey has been completed the user will be directed to a page confirming their results have been saved. This page will also display the next time the user can complete the tests depending on the group type and settings. After reading this screen the user will be told they can now leave the system.

Essential

3.2 Non-functional Requirements This section outlines the non-functional requirements for the testing TOM application.

Non- Functional Requirement ID

Non-Requirement Title

Non-Requirement detail

Priority

Essential / Conditional / Optional

NFR001 Usability Due to the young nature of the users, the system needs to be as simply as information technology system can be

Essential

NFR002 Aescethetics The look of the site should be simple and use highly contrasting colors for text. The site should be roughly modeled of the universities in regards to looks.

Essential

NFR003 Load time As this application is trying to reach the widest audience possible the system needs to be as bandwidth friendly as possible.

Essential

NFR004 Security The testing TOM application needs to meet all the security requirements of the university so that it can be hosted within the university.

Essential

NFR005 Privacy The privacy of all the users of the site should be paramount. The results of the tests should be no way traceable to a user’s identity within the application.

Essential

NFR006 Ethics The testing TOM application needs to meet all the ethical requirements of the university and psychological research so that it can be hosted within the university.

Essential

3.3 Automatically generated value Rules

This section lists the rules that will be used for creating fields within the testing TOM application.

Generation Rule ID

Generation Rule Title

Generation Rule detail

Priority

Essential / Conditional /

Testing TOM Software Requirements Specification

Optional

GR001 Username The username will be created in the following format: user###

Where ### is an auto-incrementing number starting at 0001.

*this implies that the maximum number of users stored by the system at one time is 9999.

Essential

GR002 Password The password created on user creation will be a random string of six characters.

Essential

GR003 Group Name The group name will be automatically created in the following format: group## Where ### is an auto-incrementing number starting at 01.

Essential

3.4 Interface Requirements

3.4.1 User Interfaces

All users will require a standard graphical web-browser (including, but not limited to Mozilla Fire fox or Microsoft Internet Explorer) to interact with the developed solution. As at the date of release of this document, it is intended that this will be the only way to interact with the system, although consideration will be given to ensuring that the system will be expandable in the future to support emerging technologies such as testing systems.

3.4.2 Interface Storyboards

Testing TOM Software Requirements Specification

3.4.3 Hardware Interfaces

As this solution is exclusively web-based, no direct connections to hardware interfaces will be required (note that indirect connections to devices such as printers may be possible, however are the responsibility of the web browser and underlying Operating System and fall outside the scope of this system).

3.4.4 Software Interfaces

The following Software Interfaces are required by the system:

Web Browser – Interprets HTML and CSS code and enables the web pages to be displayed

on the end-user’s computer system.

PHP – Responsible for providing necessary text and formatting/layout commands for the web

pages to be displayed in the user’s browser,

Apache – This will interface with the web browser in order to provide the PHP page and

interrupt it.

MySQL – A relational database management system that will be used to store details of

available product lines, prices, quantities available etc. This will interface with the PHP.

3.4.5 Communications Protocols

The principal communications protocols required for the correct operation of this system include the following:

TCP/IP – Will be used to facilitate the communication between the client web-browser and the

server. It will also be used for communication with other servers.

HTTP – Will be implemented for transfer of generated PHP data and HTML get/post requests

across the TCP/IP connection.

SQL – The testing TOM application will use SQL to enable the backend MySQL database to

be queried and updated as required.

3.4.6 Site Map

Below is hierarchy of pages that will be created for the testing TOM application. Please note that the help and introduction page will be available from all pages except the tests as the tests will appear in a new window. The create group, delete group and add users under manage as well as control user and create user under manage user will be able to accessed from the admin page as well as their parent page as illustrated.

Testing TOM Software Requirements Specification

3.5 Hardware Requirements

3.5.1 Client-side

The following requirements are the recommended minimum requirements for client users of the system. Satisfactory performance cannot be guaranteed if these specifications are not met:

CPU: Pentium II/Celeron (or equivalent)

RAM: 128MB

Display/Graphics card: 24-bit colour display, operating at least 800x600.

The user also is required to have a Mouse (or other pointing device), a keyboard and an

Internet Connection.

3.5.2 Server-side

The following requirements are the recommended minimum requirements for the server component of the system. Satisfactory performance cannot be guaranteed if these specifications are not met:

UOB-community (or equivalent environment)

3.6 Software Requirements

Super admin Admin Admin

Create Admin Manage Admin Manage Group Manage User Export Data Introduction /

Help

Unable to Login

Create Group

Delete Group

Add User(s)

Create User

User Control Survey

Tests

Survey

Completed Tests

Testing TOM Software Requirements Specification

3.6.1 Client-side

� Adobe/Macromedia Flash plug-in may be needed to display the TOM tests.

� An Operating System capable of communicating using TCP/IP (Microsoft windows is recommended 95 or higher).

� Any Web Browser capable of supporting common web standards, e.g. CSS. This includes, but is not limited to: Mozilla Firefox, Microsoft Internet Explorer, Safari, Netscape and Opera.

3.6.2 Server-side

As the Server environment is already determined the software requirements listed are for versions of programs already being used by the hosting environment.

� PHP v4.3.1 is needed to process all PHP script for the application

� MySQL is needed to store all the application data

� APACHE v 2.0.44 (Unix) is used as the sites web server.

� Firewall To protect the application from illegal activities.

� UNIX is used as the UOB-community operating system.

3.7 Database Requirements The diagram and schema below have been designed having undertaken careful consideration of all aspects of the data collection and storage needs of the application to ensure that they reflects the final database design as accurately as possible to minimise changes in future phases. The diagram and schema provided are indicative only and may be subject to change, particularly during the design phase.

3.7.1 Entity-Relationship Diagram

The Entity-Relationship (ER) diagram for the database component of the solution is shown below. This diagram should be interpreted based on the assumptions and rules that have been outlined in Section 4.2.2. This diagram may change during the design, build and testing phases to suit the final design of the application.

Testing TOM Software Requirements Specification

3.7.2 Entity-Relationship Diagram Notes & Assumptions

The following notes and assumptions outline and define how the ER diagram in Section 4.2.1 should be interpreted.

3.7.2.1 Notes

� Attributes shown in bold are required.

� Attributes shown with an underline make up the primary key for the entity in which

they are shown.

� Attributes shown in italics are indicative of a relationship with another entity, thus

becoming a foreign key for that entity.

3.7.2.2 Database Assumptions

� An administrator can own many groups; however, this is not compulsory.

� A group must have an owner.

Testing TOM Software Requirements Specification

� A group can contain many levels but must contain at least one.

� A level can belong to many groups, however, does not have to belong to any groups.

� A group must have at least one level.

� A group can have many participants (users) but can exist with no participants.

� A participant can only belong to one ‘active’ group.

� A group does not have to have any participants.

� A user can take a test many times and, subsequently, have many results.

3.7.3 Database Schema

A draft of the schema for the backend database of the Testing TOM application has been provided below. This schema may change during the design, build and testing phases to suit the final design of the product.

In this table, Primary Keys are underlined, required fields are in bold and Foreign Keys are in italics.

Table Name Fields Type Description

USER username VARCHAR(20) PK

password VARCHAR(50)

level CHAR(1)

GROUP id VARCHAR(10) PK

description VARCHAR(200)

start_dt DATETIME

end_dt DATETIME

status CHAR(1)

owner VARCHAR(20) FK - references USER(username)

PARTICIPANTS userID VARCHAR(20) PK, FK – references USER(username)

groupID VARCHAR(10) PK, FK – references GROUP(id)

LEVEL id VARCHAR(3) PK

description VARCHAR(200)

GROUPLEVEL groupID VARCHAR(10) PK, FK – references GROUP(id)

levelID VARCHAR(3) PK, FK – references LEVEL(id)

TEST id VARCHAR(3) PK

levelID VARCHAR(3) PK, FK – references LEVEL(id)

name VARCHAR(50)

Testing TOM Software Requirements Specification

answer VARCHAR(5)

RESULTS userID VARCHAR(20) PK, FK – references USER(username)

testID VARCHAR(3) PK, FK – references TEST(id)

tmstamp DATETIME PK

answer

LOGGING userID VARCHAR FK – references USER(username)

tmstamp

ip VARCHAR(15)

3.8 Extra Quality Requirements This system must be useable by children of ages 3 to 8 with the aid of parents it must be possible for at least 1 out of two test subject to complete the tests.

3.9 Training Requirements Training documentation will be provided as part of the project. The end user will be expect to understand basic web knowledge with only the aid of the site content

4 Appendixes

4.1 Appendix A - Context diagram

• The context diagram highlights several important characteristics of the system:

− The people organizations, or systems, with which the system communicates. These are known as external entities.

− The data that the system receives from the outside world and that must be processed in some way.

− The data produced by the system and sent to the outside world.

− The data stores that are shared between the system and the external entities. These data stores are either created outside the system and used by the system, or created by the system and used outside the system.

Testing TOM Software Requirements Specification

4.2 Appendix B – DFD (Level 0) Below is DFD level 0 which expands on the context diagram as listed above in appendix B. Due to the nature of the application the need to further break down DFD level 0 into a Level 1 or Level 2 diagram was not necessary.

Testing TOM Software Requirements Specification

4.3 Appendix C - Deployment Diagram

� These are virtual servers hosted on the one physical server. Gauge

Testing TOM Software Requirements Specification

4.4 Appendix D - Use case model

4.5 Appendix E - Activity diagrams

Add User

This activity diagram demonstrates the process required for Administrators to add users to the system.

Testing TOM Software Requirements Specification

Download Data

This activity diagram demonstrates the process required for Administrators to download data collected by the system.

Testing TOM Software Requirements Specification

Take Test

This activity diagram demonstrates the process required for Users (both parents and children) to take tests.

Testing TOM Software Requirements Specification

4.6 Appendix F – Testing TOM Survey’s Below is sample Survey that will be used through out the testing procedure.

Commencing Survey:

* Awaiting survey from Client

Successful survey:

* Awaiting survey from Client

Early Exit Survey:

* Awaiting survey from Client

Failed level 1:

* Awaiting survey from Client

4.7 Appendix G – Auto Generated Emails

* Italics indicate a dynamic value from the testing TOM system.

Cross sectional test:

Hi admin email,

Your testing TOM group: group## has commenced/ended today your attention maybe needed.

*This is a system generated email; please do not reply to this message.

Longitudinal test (start):

Hi admin email,

Your testing TOM group: group## has commenced today and ends on end date your attention maybe needed.

*This is a system generated email; please do not reply to this message.

Longitudinal test 1 (end):

Hi admin email,

Your testing TOM group: group## has ended today the next scheduled open period starts on start date, your attention maybe needed.

*This is a system generated email; please do not reply to this message.

Testing TOM Software Requirements Specification

4.8 Appendix H – Level Progress Diagram

This flow from test-to-test illustrated in this diagram demonstrates how a user will proceed through the different levels if all the levels are selected for the group. If the admin does not select all the levels then the process will change. *Note that area of TOM being tested may change during development.

Testing TOM Software Requirements Specification

5 Sign-off

5.1 Client Sign-off

By signing this document I hereby accept and acknowledge that the design solution offered in this Software Requirements Specification will meet the goals of the testing TOM Project.

Client Name: …………………………………

Signature: …………………………………

Date: …………………………………

5.2 Team Sign Off We, the project team, will agree to plan, analyse, create and test, the above application and provide it on the date specified to the best of our ability.

We accept that the final application will have all of the requirements specified in the above documentation and will have appropriate documentation.

Ben Barker: Date: / /

Tate Lesko: Date: / /

Brad Parson: Date: / /

Cliff Vander Wel: Date: / /