Sam Rasmussen, Ben Leonforte, Sam Pike, Kylie White, Jarrod Michell SPEECH RATING TEAM

Project Handbook

SPEECH RATING WEB/MOBILE TRACKER (GECKO)

This template is loosely based on the following standards:

• Australian Standard AS4071-1992(R2014) - Software project management plans

• AS/NZS ISO/IEC/IEEE 42010:2013 – Systems and software engineering –

Architecture description

Note that following this template is not enough to claim conformance to either of the

above standards! For Project courses, some sections have been excluded completely, and

some are optional. These are noted, and may be skipped

1 | P a g e

Revision

Version Number Date

approved

Approved by Description

1.1 2019-04-10 Ben

Leonforte

Modified Assumptions,

dependencies and constraints,

Modified legal and standards

1.2 2019-04-24 Ben

Leonforte

Updated Assumption,

Dependencies and constraints

1.3 2019-02-25 Ben

Leonforte

Updated High Level Architecture

1.4 2019-04-28 Sam

Rasmussen

Added Preface, Introduction, Non-

Functional Requirements 5.1 & 5.2,

Sections 6.6 & 6.7

1.5 2019-05-01 Jarrod

Michell

Added Non-Functional

Requirements section 5.5 & 5.6

1.6 2019-05-02 Jarrod

Michell

Added sections 3.1 & 6.3, modified

5.5

1.7 2019-05-03 Kylie White Updated Process Model,

Organisational Structure, User

Interface / Interaction Design

1.8 2019-05-03 Sam Pike Added Sections 2.3, 2.4, 4.1, 5.7,

5.8

1.9 2019-05-04 Ben

Leonforte

Added Logo

1.10 2019-05-04 Kylie White Updated User Interface/Interaction

Design.

Added Non-Functional

Requirements sections 5.3 & 5.4

Added Data Model and Software

Design

1.11 2019-05-05 Sam

Rasmussen

Fixed formatting issues, edited

minor grammatical errors, general

proof-reading

Preface

The purpose of the Project Handbook is to show the processes we will follow in order to

create the speech rating app in the form of a model. The document will discuss roles involved

in the project and the responsibilities for each type of activity. The management processes

will also be highlighted. There are a variety of non-functional requirements which will be

discussed in the document in order to clarify what’s required of the project. The system

architecture and design will be emphasised in the document so there is a clear demonstration

of how the speech app will look and function. Mock-ups of the user interface will help to

demonstrate this. The audience of the document includes the client (who we do the work for),

2 | P a g e

but also the people who will use and be affected by the app such as the admin of the app, the

therapist and the user themselves.

3 | P a g e

Table of Contents

Revision ................................................................................................................................ 1

Preface .................................................................................................................................. 1

Table of Contents .................................................................................................................. 3

List of Figures ....................................................................................................................... 5

List of Tables ........................................................................................................................ 5

1. Introduction ................................................................................................................... 6

1.5 Definitions and Acronyms ........................................................................................... 6

2. Organization...................................................................................................................... 6

2.2 Organizational Structure ............................................................................................ 10

2.3 Organization Boundaries and Interfaces ..................................................................... 10

2.4 Project Responsibilities ............................................................................................. 11

3. Managerial Process ......................................................................................................... 11

3.1 Management Objectives and Priorities ....................................................................... 11

3.2 Assumptions, Dependencies, and Constraints ............................................................ 12

Assumptions ................................................................................................................ 12

Dependencies .............................................................................................................. 12

Constraints .................................................................................................................. 12

4. Technical Process ............................................................................................................ 12

4.1 Methods, Tools, and Techniques................................................................................ 12

5 Non-functional Requirements ........................................................................................... 13

5.1 Platform .................................................................................................................... 13

5.2 Communication ......................................................................................................... 13

5.3 Performance .............................................................................................................. 13

5.4 Security and Privacy .................................................................................................. 14

5.5 Audience, Usability and Accessibility........................................................................ 14

5.6 Reliability .................................................................................................................. 15

5.7 Modifiability ............................................................................................................. 15

5.8 Economic .................................................................................................................. 15

5.9 Legal ......................................................................................................................... 15

IP rights ....................................................................................................................... 15

Privacy Policy ............................................................................................................. 15

Production Requirements............................................................................................. 16

Publishing to Apple App store ..................................................................................... 16

4 | P a g e

Publishing to Google play store ................................................................................... 16

5.10 Standards ................................................................................................................. 16

Data Transfer............................................................................................................... 16

Code standards ............................................................................................................ 16

6 Software and Systems Architecture .................................................................................. 17

6.1 Architecture objectives .............................................................................................. 17

6.2 High-level architecture .............................................................................................. 17

6.3 System context .......................................................................................................... 18

6.4 User Interface / Interaction Design ............................................................................ 19

6.5 Data model and software design ................................................................................ 26

6.6 Assumptions .............................................................................................................. 30

6.7 External Dependencies .............................................................................................. 30

5 | P a g e

List of Figures

Fig 1. High-level Architecture

Fig 2. Sitemap of Web Interface

Fig 3. First Screen Wireframe

Fig 4. Log In Screen Wireframe

Fig 5. Home Page Wireframe

Fig 6. Record Stutter Severity Wireframe

Fig 7.View History Wireframe

Fig 8. Login Page Wireframe

Fig 9. Administrator Home Page Wireframe

Fig 10.Therapist Home Page Wireframes

Fig 11. Client List Wireframe

Fig 12. Add Client Wireframe

Fig 13. Add Therapist Wireframe

Fig 14. Client Profile

Fig 15. Therapist List

Fig 16. Change Password

Fig 17. Context Diagrams

Fig 18. Level 1 Data Flow Diagram

List of Tables

Table 1. High-Level Breakdown of Activities

Table 2. Project Responsibilities

Table 3. Client Data Dictionary

Table 4. Therapist Data Dictionary

Table 5. Administration Data Dictionary

Table 6. Severity Rating Record Data Dictionary

6 | P a g e

1. Introduction

This project involved creating an app which rates speech based on two different rating

programs. These systems are to be used for people with a stutter in their speech. There is the

Lidcombe Program which is used for children and there is the Camperdown Program which

is used for adults. These programs will be included in the functionality and design of the app.

The app will be simple to use and should be able to store values entered by a user in a

database so that the results can be viewed and retrieved from the database at a later stage. The

Severity Rating should be stored with ease and the UI should be able to represent these

numerical values with a graph. The app will be created with inspiration from a website that

the project is currently represented on.

1.5 Definitions and Acronyms

Term Definition

Severity Rating (SR) This is a rating that is assigned by a therapist to a patient based on

their stuttering and ability to speak clearly

Lidcombe Program Behavioural treatment for children who stutter

Camperdown

Program

Behavioural treatment for people over the age of 12 with a stutter

2. Organization

Tasks to Complete (Project Functions)

Development of mobile application for client users. The goal is to develop the mobile

application to use used on Android and iOS operating systems. At minimum the mobile is to

be functional on the Android operating system.

Development of Web Interface, which would designed for the use on desktop. This is

compared to the current website which has been developed with mobile accessible

functionality. The Web Interface is to be used for Therapist and Administration users.

Development of further functionality of the Graph as requested by the client. This is to be

implemented in both the mobile application and web interface.

Develop modelling of the system using the modelling tool DFD.

Inclusion of two stuttering programs: Lidcombe and Camperdown for recording SR.

Development of notification system. The system will be set by Client users on the mobile

application.

High-Level Breakdown of Activities

7 | P a g e

Sprint Activities Time Line Impact to Project

Sprint 1 Create Product Handbook

Basic GUI design for Mobile

Application and Web Interface

Exploration of Current

Website

Exploration for an IDE for

mobile application for

development.

Exploration for repository to

store code.

Create documentation for

Sprint 1

After the

completion of the

sprint at

5/5/2019, the

client will be

delivered the

Product

Handbook.

Project Handbook will one of the

major documents for this project.

The Project Handbook will be the

guide for the project team to

complete the project.

By using wire frames to show

basic GUI design for the mobile

application and the web interface.

Currently there is no mobile

application in place and the

website has mobile accessibility. In

the design aspect with the website

being view via desktop it currently

views as mobile application on a

full screen of a monitor.

At the start of the project the team

was given the current website with

mobile accessibility implemented,

from this we have been able to

determine the current functionality.

From this we have been able to

develop the product backlog.

Exploring options for IDE to build

the mobile application.

Considerations have been made to

have the mobile application to

possibly run on Android and iOS

operation systems, with the

minimum goal to develop the

mobile application to run on

Android.

Exploring options for a repository

for the project team to be able to

store code for this project but also

keep track of all of the changes

made throughout the development.

The creation of documentation for

Sprint 1 will be enable the project

team to keep track of what has

been completed throughout the

sprint.

8 | P a g e

Sprint 2 Basic Prototype for both

mobile application and web

interface

Visual Development

Create documentation for

Sprint 2

The project team at the end of this

sprint wish to have a basic

functional prototype of both

mobile application and web

interface. This will be with hard

coded information at the back end

of the system. This is to show the

progress of the project and ensure

that the basic functionality and

visual style is within expectations

of the client.

From the wire frames developed

from the previous sprint, the

project team will further develop

the visual style of both mobile

application and web interface. This

is to be implemented in

conjunction of the development of

the prototype.

The creation of documentation for

Sprint 2 will be enable the project

team to keep track of what has

been completed throughout the

sprint.

Sprint 3 Database Development

Back End Development

Graph Development

Create documentation for

Sprint 3

Develop the Database to be used

for the mobile application and web

interface.

Develop the back end of the

system.

Development of the functionality

of the graphs as requested by the

client. This will include the

development of graphs for the use

for both the Lidcombe and

Camperdown programs. The

graphs will be designed for

interaction within both the mobile

application and web interface.

9 | P a g e

The creation of documentation for

Sprint 3 will be enable the project

team to keep track of what has

been completed throughout the

sprint.

Sprint 4 Development of partial offline

and online functionality for the

mobile application.

Development of a notification

system

Create documentation for

Sprint 4

Develop the mobile application to

be able to function without

continuous internet connectivity.

Develop the functionality to

upload data which was collected

while the mobile application was

offline.

Develop the notification system to

be implemented in the mobile

application. This is to include

notification settings which will be

able to be modified by the client

within the mobile application.

The creation of documentation for

Sprint 4 will be enable the project

team to keep track of what has

been completed throughout the

sprint.

Sprint 5 Non-functional requirements

testing

Usability/Accessibility Testing

Create documentation for

Sprint 5

Test the mobile application and

web interface to ensure that the

non-functional requirements have

been met. Testing allows for

modifications to be made if they

are required.

Test the usability and accessibility

of the mobile application and web

interface to ensure that it meets the

expectations of the client.

The creation of documentation for

Sprint 5 will be enable the project

team to keep track of what has

been completed throughout the

sprint.

10 | P a g e

2.2 Organizational Structure

The project team consists of the following members:

• Kylie White

• Sam Rasmussen

• Ben Leonforte

• Jarrod Michell

• Sam Pike

Roles and Responsibilities

Product Owner: Kylie White

As Product Owner, it comes with the responsibility of selecting user stories from the Product

Backlog with the Project Team. This includes creating Product Backlog Items to meet the

completion of the user stories (Functional Requirements).

Scrum Master: Sam Rasmussen

As Scrum Master, it comes with the responsibility of organising and running meetings within

the Project Team. This includes using the group chat functionality in Facebook Messenger to

notify project team members when there are schedule meetings. Also ensuring that there is a

record of meetings.

Client Liaison: Kylie White

As Client Liaison, it comes with the responsibility of organising and running meeting with

the project client and project supervisor. This includes using web application of Doodle to set

up meetings. Also ensuring that there is a record of meetings.

Software Manager: Ben Leonforte

As Software Manager, it comes with the responsibility of setting up required software/web

applications for the use of the project. This includes sending requests to the Project Team to

sign up for the use required software. Also ensuring that the software/web application options

can be used by the project team.

Team members: Kylie White, Sam Rasmussen, Jarrod Michell, Ben Leonforte and Sam Pike

As a Team Member, it comes with the responsibility of being a part of the development of the

project. It is the responsibility of Team Members to select tasks to from the available work

and complete the work.

2.3 Organization Boundaries and Interfaces

The team is responsible for their own administration and management of tasks and processes,

under supervision from Leigh Achterbosch. The role of supervisor is to provide guidance and

expertise when required but otherwise acts infrequently to ensure the team is on track and

progressing the project.

11 | P a g e

Kylie White is the designated client liaison and is the primary contact for communications

between the client and team. Team members are welcome to attend client meetings in

addition to Kylie but are not required to attend.

Grant Meredith is our primary client contact and can respond to enquiries regarding the

project and various decisions relating to it.

Elizabeth Harrison is another client contact and can answer enquiries relating to the Clinical

aspects of the project.

2.4 Project Responsibilities

All team members are willing to work on various areas of the project and may switch

between roles over the course of the project depending on assigned tasks.

Team Member Ben

Leonforte

Jarrod

Michell

Kylie

White

Sam

Pike

Sam Rasmussen

Web Design x x x x x

Mobile Design x x x x x

Database

Design

x x x x x

Web Frontend

Programming

x x x x

Web Backend

Programming

x x x x

Database x x x x

Mobile

Programming

x x x x x

Documentation x x x x x

Web Testing x x x x x

Mobile Testing x x x x x

Database

Testing

x x x x x

3. Managerial Process

3.1 Management Objectives and Priorities

The project team will be following an agile SCRUM methodology, this will allow the team to

be highly flexible with a high standard of performance. Work is to be done in sprints in an

iterative workflow, work will be produced in 3-week time periods that will be presented to

the client at the end of each sprint. The aim of the team is to produce a product of high

quality and supply the flexibility to suit the client’s needs. Consistent contact with the client

between sprints gives the client the opportunity to provide feedback on the work being

produced. This introduces a level of flexibility as changes to the project can be made if

deemed important enough by the client, or redirection of development focus if the project is

12 | P a g e

heading in the wrong direction. The quality and consistency of work produced must meet a

standard that the team has agreed upon prior to work commencing, this is to ensure a constant

level of high quality is upheld.

Conflicts may occur during development which may lead to work being delayed or

incomplete, work is to be completed to what was agreed upon between the client and team.

Conflict resolution will be handled by the project manager or scrum master, however in the

case of a major conflict between two team members that is out of the project manager’s

control higher authority may have to step in.

3.2 Assumptions, Dependencies, and Constraints

Assumptions

• The Client is receiving treatment from a therapist

• All Data will be stored in the database

• The Client needs to Record their SR data

• The Client has a capable smartphone or mobile device to use the application

• The Therapist has access to a computer to use the web application

• The Client has a network connection to upload their data from their mobile device

Dependencies

• Clients need to log in and record their SR data to the designated frequency determined

by the Clients therapist.

• A dependency on the Therapist to setup the clients account and dictate the required

SR recording Frequency.

Constraints

• Mobile application must run on Android and if possible IOS

• Web application must be compatible with all browsers

• IOS Development and testing may require an IOS device

4. Technical Process

4.1 Methods, Tools, and Techniques

Our team will make use of various tools to assist them over the course of the project. We will

be using Microsoft Visual Studio Code as our IDE for programming tasks with code

management and version control via Git and Microsoft Azure. We also use Trello to organise

our product backlog and sprints and Dropbox for document management. Software designs

are made with LucidChart and Pencil. We make use of Facebook Messenger for

13 | P a g e

communication within the team and Facebook Pages and Email for communications with the

client as well as Doodle to set up meeting times.

5 Non-functional Requirements

5.1 Platform

The intention is for the app to be available on two platforms – Android and iOS. Primarily the

main focus will be on making the app for Android as that is the client’s main preference, but

iOS will be the focus after Android. The speech rating project is currently available in

website form and it is our focus to shift the platform from a website that can be viewed by

any browser to an app on mobile devices.

5.2 Communication

The communication between team members on the project will occur in a messenger group

chat and through emails. Dropbox is also being used to collate files in a central online place

that is easily available to all members. The messenger group chat allows us to organise

meetings and allows us to relay messages to each other so that those who missed a meeting,

or an important piece of information aren’t left out. The meetings are the ideal mode of

communication where we are face to face and it allows us to talk about what needs to be

done, what we have done, and any problems that we have been facing or will potentially face.

Communicating and organising things with the client will be done through emails as this is

the easiest way of contacting the client. This allows us to organise meetings with them.

5.3 Performance

Mobile Application

It is essential that the mobile application should perform well. If the mobile application does

not perform as it expected to the users will uninstall the application from their smartphone.

The app Start-Up, the time that the application takes to start up should be only 1-2 seconds

between the user tapping on the application icon and the first screen of the application.

We have to take into consideration how much battery life which the mobile application will

use and the heat that is generated. Battery life impacts the performance of the application, if

the battery is draining too fast it can mean that the application is using more resources than

necessary. Extra resources being used leads to the processor having a greater workload

which leads to head being generated.

Dealing with memory consumption is important, as implementing functionality in the

application leads to the increase of memory consumption on the device which the application

is installed on. The application will need to be tested to see how memory consumption will be

impacted with the different RAM and processor specifications, as devices come with

different RAM and processor specification.

Web Interface

Good performance is about having the Therapist and Administration users to purposely

interact with the web interface. The benchmark is to respond to input under 100ms. The

benchmark is to load interactive content in under 5000ms. There are factors which impact on

page load performance:

14 | P a g e

• Network speed and latency

• Hardware (slower CPUs)

• Cache eviction

• Differences in L3/L3 caching

• Parsing JavaScript

5.4 Security and Privacy

The mobile application and web interface are to be used as an aid in the managing of a

client’s stuttering. It is also used by therapists to document and aid the treatment of stuttering.

The majority of the data which will be collected with Severity Rating (SR) and Fluency of

Technique records which are numerical, do not raise concern in regards to privacy. However,

the comments that relate to SR records need to be considered private and confidential. Only

the client and therapist will be able to access the comments which relate to SR records.

Only the permitted users can access SR records. Client users cannot access SR records of

another Client user. Therapist users can only access the SR records of their clients, not the SR

records of who are clients with another therapist.

User authorisation is verified by the combination of email and password. The correct

combination of email and password will validate successful login. Passwords will be secured

with a hashing function. This will ensure that passwords are not recoverable and the

password will be reset to a new password.

Error reports are to be tested to ensure that Client and Therapist users do not receive the

output from error logs. Administration users may receive error log output to help with

maintenance.

5.5 Audience, Usability and Accessibility

The current prototype website is designed to follow the Lidcombe program, which is

designed for speech therapists and the parents/guardians of children with speech

impediments. The age of the children can range from 3 to 12 years old, therefore they will be

dependent on their carers to use and report their SR through the application. The new website

and mobile application are aimed to also include the Camperdown program, this is designed

for adults and children over the age of 12 with speech impediments in the intended audience.

There is two ways that the application can be used, through the website on a computer or

through the mobile application. The desktop version is expected to be used more by therapist

users, as they are more likely to have the application open on their office computer while they

are working.

Client users are expected to use the mobile version more frequently as it will be simpler and

quicker to use when only using the application once or twice a day. The mobile version will

also be more accessible as it is more likely that a client will own a mobile device than a home

computer. The website version can also be accessed through a mobile devices browser if the

application fails or there are any compatibility issues surrounding their owned device.

15 | P a g e

The interface design of the mobile application and website will be simple and easy to follow.

This is because the client users may not be very tech-savvy and may get confused or lost in

an overly complicated interface design. Both platforms will also only support English as the

language, as the application is only intended to be used in Australia on its initial release.

5.6 Reliability The website and database will have to accessible 24 hours a day as the time when a client

logs their daily SR data will vary user to user. The system may be temporarily down if

maintenance or update is required. This is aimed to be done at a time of low user activity like

the early hours of the morning, this will help avoid any clients from being unable to input

data. There will be a SQL database which stores and supplies all the client user data and will

be used across both the mobile application and website. Any errors or incidents will be

recorded to a log and reported to the system administrator; from there it will be up to the

system admin to take action if required.

5.7 Modifiability

Cosmetic components of the application such as logos and colour schemes will be able to be

modified without significant changes to the program or extensive technical knowledge. The

major components of the system would require technical knowledge to modify and shouldn’t

need extensive changes.

5.8 Economic

The system currently does not have a budget to draw from and its current design does not

require any expenses. The system will run primarily on web and Android platforms with the

possibility of an iOS app as well. The addition of an iOS app will require an expense in the

form of license fees and a development environment but as it is currently an optional feature

no budget will be required.

5.9 Legal

IP rights

The intellectual property created in this project remains the property of the students in the

case that the client wishes to alter who has the IP rights a contract will need to be formed that

all parties involved agree to and sign.

Privacy Policy

The application collects and stores Clients personal data this data includes

• Name

• Date of birth

• Contact number

• Email address

• SR recorded data

• Anything the client has recorded

• Therapist Name and Address

This data is accessible only by the client and the client’s therapist we will not share this data with any

3rd party unless confirmed that it is okay to do so with the client. the client maintains the right to

update or delete their personal data at any point in time.

16 | P a g e

Production Requirements

Depending on what system the production is going live on and in order for the application to

be available in both apple app store and google play store, there are a number of requirements

that need to be met depending on the system that that it will be released on.

Publishing to Apple App store

Apple has released information regarding the criteria that must be met in order for the app to

be published on their platform this guide can be found at https://developer.apple.com/app-

store/review/guidelines/

The application will also have to be submitted to apple to be approved before it is released on

IOS platform.

There may also be fees associated with getting a developer license and publishing to the app

store

Publishing to Google play store

Publishing an app to google play store is free there is an advised app format to follow when

uploading but it is not mandatory to follow.

5.10 Standards

Because this project utilises two different front-end systems one mobile and one web based.

We will implement a single backend system (PHP) that will sit server side to handle all the

business logic this will create a standardised approach across the multiple interfaces on how

the database is accessed and how the data is stored.

Data Transfer

We will use REST API to communicate between the front-end systems and the backend all

data will be transferred in JSON.

Code standards

• All code will be commented to help readability

• Objects and methods will be named appropriately and relative to the functionality

they provide

• Brackets will be on a new line to make the code easier to read

Database will use standard naming conventions

• Table names will be in all capitals and less than 128 characters long

• Tables will be in 3rd normal form where possible

• Only encrypted passwords will be stored in the database using PHP function

password_hash()

17 | P a g e

6 Software and Systems Architecture

6.1 Architecture objectives

The main goal of the SR system is to provide clients and therapists with an easy to use Digital

record of all SR records. The System will be accessible from a website and a mobile

application giving the users high accessibility. The system will make recording SR details

simple and fast and allow Therapists to keep track of their clients daily, easily seeing who is

keeping track and who isn’t.

6.2 High-level architecture

The project will implement a N-tier based architecture type. This means the project will be

broken down into 3 different tiers, all responsible for completing different tasks. The

Presentation layer made up of a website and mobile app is the frontend User Interface Made

up of a website and mobile application and are responsible for Receiving, Sending and

presenting data from the Logic tier. The Logic tier will be a PHP backend API sitting on the

server this will process and send data from the presentation Tier and request and update Data

inside the Data Tier. The Data Tier is where the Data is stored in this project, we will be

using a SQL Database.

18 | P a g e

6.3 System context

The mobile versions will have to function correctly on their respective operating systems,

there will be a version that can be used on Android devices. The application will have to be

targeted toward recent Android versions and API levels, for example the latest version of

Android is Android 9.0 (API level 28). Not all devices will support the latest update of

Android causing compatibility issues, this can be negated by targeting a slightly lower API

level to maximise the number of supported devices. Currently the application will target

Android 8.0 (API level 26), newer features will be unavailable in this version however newer

versions of Android will still be able to run the application. Applications for Android are

required to be released on the Google Play store, this will require the application to follow the

guidelines provides by Google to properly upload and release the application into the store.

Developing a mobile application for Apple raises the same issues with their API IOS, the

current version that is supported is IOS 12.2 which majority of apple devices still support.

There is a small number of devices that run IOS in comparison to Android. With less devices

there is less hardware variation, reducing the chance a device is unable to run the application

19 | P a g e

due to hardware incompatibility. Applications for Apple devices are released through the

Apple store, the application will have to follow the guidelines provided by Apple and then

undergo a quality review before it can be published.

The website version of the system will have to be able to function correctly on multiple

internet browsers. Some examples of browsers that will have to be supported are Microsoft

Edge, Google Chrome and Mozilla Firefox. A prototype version of the website currently

exists which currently has some of the key functionality built into it, the website version will

use PHP and HTML5 as they are universally accepted by each browser.

6.4 User Interface / Interaction Design

For this project there will be a Web Interface and a Mobile Application Interface. The web

interface will be designed for Therapists and Administration Users and can also be used client

users. The mobile application will be designed for Client users.

The main design concept for the web interface is make it easy to navigate as possible, also to

improve from the current website.

Sitemap

Figure 2. Sitemap of Web Interface

The main design concept for the mobile application is make it easy to navigate and ease of

use.

Mobile Application Wireframes

20 | P a g e

Figure 3. First Screen Wireframe

Figure 4. Log In Screen Wireframe

21 | P a g e

Figure 5. Home Page Wireframe

Figure 6. Record Stutter Severity Wireframe

22 | P a g e

Figure 7. View History Wireframe

Web Interface Wireframes

Figure 8. Login Page Wireframe

23 | P a g e

Figure 9. Administrator Home Page Wireframe

Figure 10. Therapist Home Page Wireframes

24 | P a g e

Figure 11. Client List Wireframe

Figure 12. Add Client Wireframe

25 | P a g e

Figure 13. Add Therapist Wireframe

Figure 14. Client Profile

26 | P a g e

Figure 15. Therapist List

Figure 16. Change Password

6.5 Data model and software design

There are four databases in use for this project, the following Data Dictionaries will describe

the initial database design.

Table 3. Client Data Dictionary

Column (Fields) Data Type Description

27 | P a g e

client_id int Primary Key of Client

Foreign Key of Therapist

Foreign Key of Severity

Rating

given_name varchar(50) Client given name

last_name varchar(50) Client last name

email varchar(50) Client email

password varchar(50) Client password

active bool Determines if Client is active.

True equals active, False

equals not active.

program varchar(50) Determines the program that

the client is using. Either the

Lidcombe or the

Camperdown Programs

Table 4. Therapist Data Dictionary

Column(Fields) Data Type Description

therapist_id int Primary Key of Therapist

given_name varchar(50) Therapist given name

last_name varchar(50) Therapist last name

email varchar(50) Therapist email

password varchar(50) Therapist password

Table 5. Administration Data Dictionary

Column(Fields) Data Type Description

admin_id int Primary Key of

Administration

28 | P a g e

given_name varchar(50) Administration given name

last_name varchar(50) Administration last name

email varchar(50) Administration email

password varchar(50) Administration password

Table 6. Severity Rating Record Data Dictionary

Column(Field) Data Type Description

record_id int Primary Key of Severity

Rating Record

Foreign Key to Client

sr_record int Severity Rating record

fluency_record int Fluency Technique record

record_timestamp date Time stamp of recording

The file format (.CVS ) from the current website will be continued to be used as tool for data

export.

The following Data Flow Diagrams will show the design of the system, this will include all

of the major processes.

29 | P a g e

Figure 17. Context Diagram

Figure 18. Level 1 Data Flow Diagram (DFD)

30 | P a g e

6.6 Assumptions

We are assuming that the software we plan on using is compatible with other software which

might also be used. There is also the assumption that the software we intend to use is free and

also available to be used on our machines that will be used to develop the app. Hopefully

there are no troubles being able to set up the software and that the software is compatible

with our hardware.

6.7 External Dependencies

External dependencies include the hosting of the database on the uni servers as specified by

the client. Hopefully we have database access and that there is no trouble accessing the

database and using it. There is a lot of dependency on the availability of the uni servers as we

aren’t going to be creating the database from scratch. External dependencies can also include

the input of the client. The architecture that the client wants might change as the project goes

on but for now there is no way of predicting this. The clients needs will always present as an

external dependency.