Project Handbookbenleonforte.com/Project Handbook.pdf · 2019-07-03 · Sam Rasmussen, Ben...
Transcript of Project Handbookbenleonforte.com/Project Handbook.pdf · 2019-07-03 · Sam Rasmussen, Ben...
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.