2018 Thesis Dana Doherty - Chatbots
2018 Thesis Dana Doherty - Chatbots
2018 Thesis Dana Doherty - Chatbots
I declare that this is all my own work and does not contain unreferenced material copied from any
other source. I have read the University’s policy on plagiarism and understand the definition of
plagiarism. If it is shown that material has been plagiarised, or I have otherwise attempted to obtain an
unfair advantage for myself or others, I understand that I may face sanctions in accordance with the
policies and procedures of the University. A mark of zero may be awarded and the reason for that
mark will be recorded on my file.
I confirm that the Originality Score provided by TurnItIn for this report is ________.
[your signature]
Acknowledgements
I would like to take this opportunity to thank my project supervisor Dr Kevin Curran for his
continuous guidance and encouragement throughout the entirety of the project. I would also like to
thank Dr Daniel Kelly for his feedback and guidance during the development stage. Finally I would to
thanks Dr Michael McTear for his guidance and valuable and critical input on the Testing and
Evaluation Chapters.
Contents
1. INTRODUCTION ................................................................................................................. 1
1.1 AIMS & OBJECTIVE ......................................................................................................... 1
1.2 LITERATURE REVIEW .................................................................................................... 2
1.3 CHATBOTS IN INDUSTRY .............................................................................................. 3
1.3.3 CHATBOTS ..................................................................................................................... 6
1.4 NATURAL LANGUAGE UNDERSTANDING ENGINE ................................................ 7
1.5 ARTIFICIAL INTELLIGENCE .......................................................................................... 8
1.5.1 ARTIFICIAL INTELLIGENCE METHODS .................................................................. 8
1.6 CHATBOT ARCHITECTURE ......................................................................................... 10
1.7 SUMMARY OF REPORT ................................................................................................ 10
1.8 CONCLUSION .................................................................................................................. 11
2. REQUIREMENTS SPECIFICATION AND ANALYSIS .................................................. 11
2.1 PROBLEM STATEMENT ................................................................................................ 11
2.2 PROPOSED SOLUTION .................................................................................................. 12
2.3 SOFTWARE DEVELOPMENT METHODOLOGIES .................................................... 12
2.3.1 WATERFALL METHODOLOGY ................................................................................ 13
2.3.2 INCREMENTAL MODEL............................................................................................. 13
2.3.3 CHOSEN METHODOLOGY ........................................................................................ 14
2.4 INFORMATION GATHERING TECHNIQUES ............................................................. 14
2.4.1 CHOSEN INFORMATION GATHERING TECHNIQUE ........................................... 16
2.5 FUNCTIONAL AND NON-FUNCTIONAL REQUIREMENTS .................................... 17
2.5.1 FUNCTIONAL REQUIREMENTS ............................................................................... 18
2.5.2 NON-FUNCTIONAL REQUIREMENTS ..................................................................... 18
2.6 SOFTWARE AND HARDWARE SPECIFICATION ...................................................... 19
2.6.1 SOFTWARE REQUIREMENTS ................................................................................... 19
2.6.2 HARDWARE REQUIREMENTS.................................................................................. 19
2.7 PROJECT PLANNING ..................................................................................................... 19
2.7.1 PROJECT MILESTONES AND DELIVERABLES ..................................................... 20
2.7.2 DEVELOPMENT ITERATION BREAKDOWN .......................................................... 21
2.7.3 RISK MANAGEMENT.................................................................................................. 22
2.7.4 PROJECT MANAGEMENT .......................................................................................... 23
3. DESIGN ............................................................................................................................... 25
3.1 ARCHITECTURAL DESIGN........................................................................................... 25
3.2 DATABASE DESIGN....................................................................................................... 29
3.3 CLASS DIAGRAM ........................................................................................................... 30
3.4 SPEECH RECOGNITION ................................................................................................ 32
3.5 ACTIVITY DIAGRAMS .................................................................................................. 33
3.6 SEQUENCE DIAGRAMS ................................................................................................ 38
3.7 CONVERSATIONAL USER INTERFACE DESIGN ..................................................... 40
3.8 DIALOG DESIGN............................................................................................................. 42
4. IMPLEMENTATION AND TESTING .............................................................................. 46
4.1 CONFIGURING THE DEVELOPMENT ENVIRONMENT: ......................................... 46
4.2 AUTHENTICATION: ....................................................................................................... 48
4.3 DATABASE DEVELOPMENT ........................................................................................ 48
4.4 GOOGLE TWO-FACTOR AUTHENTICATION: .......................................................... 49
4.5 OPEN BANKING API: ..................................................................................................... 51
4.6 WEBHOOK DEVELOPMENT: ....................................................................................... 56
4.7 CHATBOT WEB CLIENT................................................................................................ 63
4.8 GIT VERSION CONTROL............................................................................................... 64
5. TESTING ............................................................................................................................. 64
5.1 SIMULATED CONVERSATIONAL TESTING ............................................................. 65
5. 2 WEBHOOK TESTING .................................................................................................... 73
5.3 USER TESTING:............................................................................................................... 74
6. EVALUATION................................................................................................................... 75
6. 1 CONCLUSION ................................................................................................................. 79
6.2 FUTURE ADVANCEMENTS ......................................................................................... 79
6. REFERENCES ...................................................................................................................... 2
HTTPS://WWW.BBA.ORG.UK/WP-
CONTENT/UPLOADS/2014/06/BBA_COMPETITION_REPORT_23.06_WEB_2.0.PDF .. 4
7.APPENDICES ........................................................................................................................ 8
7.1 APPENDIX A QUESTIONNAIRE RESULTS USER REQUIREMENTS .................... 9
EEE521 Final Year Project 2017/18 B00659303
Abstract
People interact with systems more and more through voice assistants and chatbots. The days of solely
engaging with a service through a keyboard are over. These new modes of user interaction are aided in
part by This research will investigate how aadvancements in Artificial Intelligence and
The produced prototype was found to be a very The TrueLayer API will be used to retrieve account
information which has
just recently been made accessible to the public. This is part of the Open Bank
Standard which allows developer’s access banking data through the API
Rest client. This came about through the bank as a platform (BaaP) standard.
useful tool to justify the need of a modern method of interaction to be integrated within many services
offered by banks and financial businesses. In an industry with low user satisfaction rates and limited
technology to increase accessibility. It is clear the chatbot overcomes the challenges banks face to
increase the use of their services and gain a competitive edge over leading competitors.
With many people adopting Smart Assistant Devices such as Google Home or Amazon’s Alexa. The
chatbot was tested across a range of devices such as Google Home and Assistant on android devices to
outline the key differences between the two modes of interaction , spoken and text dialog. These test
were carried out to identify the value in integrating such technology surrounding the recent interest in
1
EEE521 Final Year Project 2017/18 B00659303
chatbots and conversational interfaces. Proving chatbots can be applied to a specific domain to enhance
accessibility, reaffirming that they are more than just a passing fad and have a viable use.
2
EEE521 Final Year Project 2017/18 B00659303
1. Introduction
“Digitalisation, the surge of mobile and internet connected devices has revolutionised the way people
interact with one another and communicate with businesses” (Eeuwen, M.V. ( 2017)). Millennials are
accepting and supporting new technology into the routine of their everyday life, this is becoming more
Banks are now enabling the use of technology so customers can perform more tasks online, such as;
cheque image clearing to allow the payment of cheques remotely and intelligent chatbots to increase
customer service and assist employees. A chatbot is a “simple software program that can respond to
customer prompts i.e. what’s my bank balance?” (Entrepreneur, . (, 2016)). Mastercard has launched
Kai an artificial intelligent chatbot and other bots for financial services. They can handle customer
queries such as: ‘what is APR?’, requests, look at spending habits and solve problems. This in turn
enables financial institutions to provide a new, engaging experience and strengthen their relationship
with the customer, with the aid of natural language used by bots to establish a more personal and
contextual conversation (Wire, . (, 2016)). The focus of this project is to implement these new
technologies to create an intelligent chatbot to enable banks to appeal to millennials and potentially gain
a lifelong customer.
1
EEE521 Final Year Project 2017/18 B00659303
2
EEE521 Final Year Project 2017/18 B00659303
financial services as well as banking industries (Ajimon and , G. G.S. Gireesh K,.(George and Kumar,
2013)). Advancements in technology has transformed many of our services into the digital era and the
banking industry is one of the primary industries to avail of these advancements to improve their
services. Currently within the UK two paradigms are available for online banking. One of which is an
integrated internet bank which still operates through the branch but has an online presence. The other,
a stand-alone internet bank, that operates completely independently and its only existence is solely
through the internet (MarketLine, 2017).
Banks implement technology to strengthen their processing capacity, acquire a larger customer base
and expand the services they could offer (Consoli, . (, 2005)). The use of internet banking has grown in
demand enormously in the last decade. “15% of branch customers use online banking once a day, 59%
once a week, 77% at least once a month and 53% were confident in carrying out the best part of their
banking online” (Barty, J. and Recketts, T. BBA, (2014)). Online banking has become more popular as
it negates the need for customers to visit their local branch as they can manage their finances on the go
to meet the demand of modern life. This is evident as branchless banks are now emerging from the
industry such as Atom Bank and many banks now closing some of their branches. This is evident with
the recent closure of 11 Ulster Bank Branches in NI due to the increased number of customers
performing their banking online (The Belfast Telegraph).
HoweverHowever, a recent study by Ling et al., (2016), notes that most internet banking service
providers struggle to get many of their customers to use their service. They identify lack of customer
satisfaction when using online banking services to be a major cause. “Service quality, web design and
content, security, privacy, speed and convenience” (Ling et al., 2016) are stated identified as the top
factors influencing customer satisfaction This suggests that there is a lack of technology in place to
enhance the customer online banking experience which could be improved by integrating a chatbot to
provide an efficient, convenient and personal service.
3
EEE521 Final Year Project 2017/18 B00659303
4
EEE521 Final Year Project 2017/18 B00659303
Figure 1: Figure 1.3.1 - Interest in chatbots within the Financial Industry (Source: W.B. King, W.B
2017)
Mark ZuckerBerg CEO of Facebook, believesC chatbots provide more personal and immediate ways
for customers to communicate with an organisation allowing them to provide consistent and appropriate
customer service at scale (Conversational Business, 2017). Facebook has now released its own
Messenger Bots, which allows organisations to develop their own Chatbot through Messenger to deliver
their services.
Facebook are also developing AI methods to obtain specific information related to users across relevant
topics. The acquired information is used as a dataset to develop and improve their Artificial Intelligence
so they can analyse, group and rate each user post (Rossmann et al., 2017).
“44% of US consumers prefer to interact with a chatbot compared to a human in relation to customer
queries” (Wellers et al., 2017). This is evident as Chatbots are also becoming more prevalent in other
industries such as; insurance, recruitment, media and pharmaceuticals.
5
EEE521 Final Year Project 2017/18 B00659303
Figure 1.3.2 2. displays the tasks that can be replaced with the integration of chatbots into an
organisation, with the goal of advancing access and use over time.
1.3.3 Chatbots
A chatbot is a software tool that utilises natural language processing (NLP) for human machine
interaction (HMI) and Machine Learning (ML). “The complexity of a chatbot is directionally
proportional to the scope of the domain”. An open domain requires a larger knowledge base, whereas,
a closed domain has a more specific knowledge base that was developed to achieve a specific goal
(Gregori, E. , 2017).
6
EEE521 Final Year Project 2017/18 B00659303
Chatbot technology initially began in the 1960s to determine whether a chatbot could be portrayed as a
human. Throughout the 1980s there was an elevated amount research carried out on natural language
interfaces which lead to the development of sophisticated chatbot architectures such as A.L.I.C.E. This
chatbot architecture is one of the earlier chatbots developed in 1995 by Dr Wallace which is now open-
source, the acronym stands for Artificial Linguistic Internet Computer Entity. This is a chatbot you can
create through interaction as it will learn from previous interactions to create its knowledge base. Its
knowledge is saved in AIML (Artificial Intelligent Mark-up Language) files which evolved from the
Extensible Mark-up Language (XML) (Shawar, B.A and and Atwell, E, 2007).
Chatbots are developed using two approaches; a rule based approach where chatbots operate by moving
through branches of a tree diagram of an expert system. The second approach involves advanced
artificial intelligence and machine learning, thus the chatbot can learn from the conversations,
generating appropriate responses to continuously improve over time (Watson, A. 2017).
There are two modes in which chatbots can simulate a conversation with users which include :
Ssystem-initiated chatbots where– they commence the conversation with the user and
User-initiated chatbots where- the user directs the conversation instead.
Systems that incorporate the two methods of initiation are known as mixed initiative systems (Duijst,
D. 2017).
7
EEE521 Final Year Project 2017/18 B00659303
8
EEE521 Final Year Project 2017/18 B00659303
“Entities are domain specific information extracted from the utterance that maps the natural language
phrases to their canonical phrases in order to understand the intent. They help in identifying the
parameters which are required to take specific action” (Kar, R and Haldar, R. Kar and Haldar, 2016).
Establishing the context of the of the users message is a vital feature that allows the chatbot to deal with
situations that it may not be able to carry out a specific action for. This is due to the user input being
very vague or may have an alternative meaning. The context is the capacity of a chatbot to sustain its
state, also referred to as the number of user supplied input (utterances) when the context is extracted
and the appropriate intent is paired to conduct the desired action for the user.
Intents are the core backbone of conversational interfaces. The intents represent what the customer is
wanting to achieve such as ‘show me my balance’. The text sent by the user in natural language is
analysed to identify the corresponding intent of the text. This requires matching a specific user supplied
phrase with an appropriate action to be executed by the system. The chat bot would then return
appropriate dialog in order for the user to achieve their goals.
Actions are the processes or steps executed by the system when the intent of a message is identified,
they contain parameters which categorise and define its properties (Kar, R and Haldar, R. Kar and
Haldar, 2016).
Sentiment analysis incorporates multiple natural language processing techniques in order to extract
meaning and polarity from text. Polarity detection classifies text to be either positive or negative and
measures the intensity of the overall polarity detected. Sentiment analysis achieves a more in depth
understanding of the contextual role of each concept within a given piece of text (Cambria, E. and
White, B, 2017).
Part of Speech (POS) Tagging: this involves assigning a label to each word in the user
input with its part of speech (e.g. noun, verb, adjective, etc.). The labels or tags can be
rule-based (a manually developed set of rules is defined to establish part of speech
for ambiguous words provided in the conversational context). The labels can also be
developed utilising advanced models that are trained using input labelled with the
appropriate POS. This is additionally used in response generation in order to outline
the POS object type of the expected response made by the chat bot (Cahn, 2017).
9
EEE521 Final Year Project 2017/18 B00659303
Figure 31.6.1: illustrates a standard chatbot architecture (source: Michael McTear, (2018) ).
Input can be supplied to the chatbot in the form of text or speech. The Input is sent to the dialog
management system which is the NLU in this case, which determines an appropriate response and
amends the chatbots state accordingly to carry out the required action. The chatbot will produce text
and speech responses in the form of both text and speech.
• Analysis - This section will include various software methodologies; quantifiable feedback will
be collected from questionnaires which will be analysed to identify the requirements of the
chatbot. The internal and external hardware and system requirements are outlined. A Gantt
chart will be provided outline the project schedule and when each milestone should be met.
10
EEE521 Final Year Project 2017/18 B00659303
• Design - This section will cover the overall design of the chatbot; UI diagrams/story boards
will be included which detail how the GUI will appear to the user. The technical architecture
will be designed and displayed in graphical form such as an activity diagram. It will outline
how each component interacts with each other. The design for the database and the relationships
between tables will be provided.
• Implementation and testing - The section will document the implementation process to develop
the solution, including; the code used to develop compelling features. Define what was learnt
during each iteration and document each prototype. Once implementation is complete the
chatbot will be tested using unit testing and appropriate test cases. Any errors or faults identified
will be fixed to ensure maximum quality.
• Evaluation and Reflection - An evaluation will be carried on the completed project to determine
its quality and value. It will detail how the overall project was developed. Reflecting upon the
overall experience, highlighting any areas that could be improved for future work and what
well throughout the project.
1.8 Conclusion
There is clear evidence based on the research conducted that there will be a drastic increase in the
number of chatbots being implemented within the financial service industry. The vast amount of
research that has been carried out, and currently ongoing, within the artificial intelligence field has led
to the rise of more sophisticated and intellectual chatbots. This will prove to be immensely beneficial
in providing convenient and accessible customer service at a rapid scale.
11
EEE521 Final Year Project 2017/18 B00659303
services are constantly seeking to expand their technologies, both to improve customer service and
increase delivery of services through the advancements in technology. This is to gain a competitive
edge over other banks for financial benefits and to expand its customer base. A domain specific chatbot
will be implemented to assist users with their banking. In order to overcome the user satisfaction issues
associated with online banking services. The chatbot will provide personal and efficient communication
between the user and their bank in order to manage their finances and get assistance when needed, such
as; answering any queries and booking appointments. The chatbot will allow users to feel confident
and comfortable when using this service regardless of the user’s computer literacy due to the natural
language used in messages. It also provides a very accessible and efficient service as all interactions
will take place within the one chat conversation negating the need for the user to navigate through a
site.
12
EEE521 Final Year Project 2017/18 B00659303
13
EEE521 Final Year Project 2017/18 B00659303
Figure 42.3.2.1: . Displaying the Incremental Model (Source: Moniruzzaman and Hossain , 2013)
Testing and debugging are made easier as faults are identified early on during small
manageable cycles. This methodology is flexible during implementation as new
requirements identified are easily integrated at each build and a, updated version is
released (Khan et at., 2011).
14
EEE521 Final Year Project 2017/18 B00659303
15
EEE521 Final Year Project 2017/18 B00659303
final software to be developed. The prototyping approach allows the developer to get a deeper
understanding of the requirements through continuous communication and each prototype iteration or
cycle (Tata McGraw-Hill PublishingInstructional Software Research and Development, 2007).
As the purpose of this project is to provide a chatbot to assist with online banking, the question relating
to users who have had past experiences in interacting with a chatbot, see question 5figure 7.1.1 of
appendix A indicates valuable insight into whether or not it was an efficient and enjoyable experience
for the users.
16
EEE521 Final Year Project 2017/18 B00659303
It’s clear from analysing the responses of this question that a small number of the respondents have
interacted with a chatbot before as only 11.54 % had previously interacted with a chatbot. Tthat the
majority of users that
have interacted with a chatbot, even if the interaction did not go seamlessly had a very positive opinion
of chatbots in general and actually felt as though they were communicating with
a human as the conversation felt very natural. , Tthis is due to the chatbot having the
ability to understand the natural language used in messages and generate an
appropriate response through various artificial intelligence methods such as natural
language processing. Users found it to be very informative and efficient when replying
to their queries . Although some respondents found that it could take a long time to
reply, or provide very simplistic responses to more complex tasks and become
unresponsive. This reaffirms the need for the chatbot to have a method that will give
the user guidance if it does not understand the context of the conversation or if it
cannot assist the user any further. This may be in the form of a link in the chat
conversation to get assistance from a human or a list of instructions the chatbot can
understand.
The results from the question 4 of appendix A‘Do you feel online banking is secure?’ are displayed in
figure 7.1.2 of appendix outlining there is only a only a 31.028.34% difference in the amount of users
that feel online banking is secure. Out of 264 responses 6558.383% feel online banking is secure
however a lot of users also worry about their personal information being compromised, stolen or
account being hacked and a criminal gaining access to their financial information and committing fraud.
Due to the security concerns most people have in regards to about online banking the chatbot will have
2-Factor Authentication implemented. This feature will reassure users that their account will be
protected, even if a criminal gains access to a user personal information they would need the users
mobile phone in order to successfully access their account as a unique code is sent to the users phone
each time upon requesting to login, the code is validated to allow users access to their account.
17
EEE521 Final Year Project 2017/18 B00659303
18
EEE521 Final Year Project 2017/18 B00659303
• Appropriate handling of unexpected input & , and correctly inform the user if it cannot provide
assistance
19
EEE521 Final Year Project 2017/18 B00659303
4 Design 20/01/2018
5 Iteration 1 26/01/2018
6 Iteration 2 15/02/2018
7 Iteration 3 9/03/2018
9 Testing 03/04/2018
10 Evaluation 05/04/2018
The project deliverables are outlined to construe the end result of this project. The deliverables are
shown in table 2 below:
Table 2: Project Deliverables
1 Interim Report
3 Final Report
4 Viva Demonstration
20
EEE521 Final Year Project 2017/18 B00659303
21
EEE521 Final Year Project 2017/18 B00659303
When each iteration is completed and the finished solution developed. The project
will be evaluated to highlight what was learnt and reflect upon the entire project life
cycle. This gives me the opportunity to discuss what was achieved and what steps or
features I would do differently in future projects from what was learnt during this
experience.
22
EEE521 Final Year Project 2017/18 B00659303
will be taken to reduce risks in this project; Github to backup code and prevent loss,
use own initiative to keep on top of project plan, regularly make backups of
project report and important documents, if an unplanned day off occurs make up for
work lost.
23
EEE521 Final Year Project 2017/18 B00659303
24
EEE521 Final Year Project 2017/18 B00659303
3. Design
25
EEE521 Final Year Project 2017/18 B00659303
26
EEE521 Final Year Project 2017/18 B00659303
Authenticator
App
Send
SMS
Users will interact with the chatbot from the web client and Google assistant app for Android
devices. Users will carry out their interaction with the chatbot in the form natural language
voice or text-based phrases. With the Google assistant integration, users will receive rich
responses, such as; images, and cards thus improving ease of use and interaction experience
for users as less typing and effort will be required when interacting with the chatbot mainly
through the use of voice commands. The google assistant integration means the chatbot is
easily be extended by Google Home.
The client side of the application is developed using g HTML5, CSS, JavaScript and Laravel
Blade.
This is a templating engine built into the Laravel framework which follows the MVC
architectural pattern. Laravel Blade compiles and caches view files to improve the
performance of the application. Blade template supports separation of view files to be split up
27
EEE521 Final Year Project 2017/18 B00659303
into sections using the ‘@section’ annotation, which enhances the readability of frontend
code, as HTML,PHP and JavaScript can be clearly separated into particular sections of the
view and the ‘@yield' annotation is utilised to render the content for sections of the view.
Blade utilises template inheritance to allow views to derive the base layout of another view to
modify and reuse UI components dynamically without replacing the code in the view it is
inheriting from. Blade also has its own annotations for control structures which may be
required in certain view files, for instance; the ‘@foreach' annotation (Laravel, 2018).
The client side also avails of the chart.js CDN (Content Delivery Service) to display the
user’s spending details in a graphical format so they can easily see where they spend the most
of their money.
The Laravel framework is also used to implement the Web client and Webhook which
receives the JSON data from the NLU via HTTPS POST requests. The Webhook is
implemented as a controller class so the corresponding web route can be is defined as an
endpoint,
where the NLU posts real-time payload to the Webhook. The Webhook receives data from
the NLU when it detects an intent has been triggered by the user from the client-side, Google
Assistant or Home devices.
A webhook receives data posted to it from another service when an update or event occurs
whereas an API follows a RESTful design approach that makes requests to retrieve the data
(elastic.io, 2018).
Dialogflow is utilised as the natural language understanding engine (NLU), which allows the
chatbot to be trained to recognise entities and intents in a user utterance. The Chabot will be
designed using intent mapping on the Dialogflow console to route user utterances to a
collection of phrases.
The Ffigure 73.1.2 represents the flow of data as an intent is invoked by a user: Dialogflow
recognises if an intent was triggered through its training using a collection of typical user
phrases. This data is then posted to the fulfilment webhook. The required entities/parameters
are extracted along with the action and a custom response is generated and returned to the
28
EEE521 Final Year Project 2017/18 B00659303
user either visually or spoken from the webhook. The Webhook parses and validates the JSON
from the payload it receives and encodes the JSON response generated to be sent back to the
user for both text and voice interaction.
Dialogflow
The Webhook parses and validates the JSON from the payload it receives and
encodes the
JSON response generated to be sent back to the user for both text and voice
interaction.
29
EEE521 Final Year Project 2017/18 B00659303
table holds data regarding the usersuser’s bank accounts, for instance they may have multiple
account types with the one bank such as current and savings, however the users online
banking credentials they possess for each bank are not saved.
30
EEE521 Final Year Project 2017/18 B00659303
31
EEE521 Final Year Project 2017/18 B00659303
HTML5
🎤
Speech-To-Text/
Speech Recognition API Text-To-Speech
Dialogflow will then take the deciphered speech and convert it into a structured JSON object
it can analyse, this is used as the text input. The JSON response is given an entity matching
score also known as confidence score. This score expresses how well the NLU engine
matched the user input to an intent defined on the console (DialogFlow, 2015). Scores range
between 0-1, 1 being an exact match. Below is a snippet of the JSON object response. User
says: “Who are you?”.
{{ “fulfilment”:
“fulfilment”: {{
“speech”:
“speech”: “I
“I am
am your
your smart
smart banking
banking bot,
bot, use
use me
me to
to get
get your
your account
account balance
balance quickly,
quickly, view
view transactions,
transactions, debits,
debits, account
account
details and receive currency conversions.”,
details and receive currency conversions.”,
“messages”:
“messages”: [[
{{
“type”:
“type”: 0,
0,
“speech”:
“speech”: “I
“I am
am your
your smart
smart banking
banking bot,
bot, use
use me
me to
to get
get your
your account
account balance
balance quickly,
quickly, view
view transactions,
transactions, debits,
debits,
account details and receive currency conversions.”
account details and receive currency conversions.”
}} ]]
},
}, “score”:
“score”: 11 -- Exact
Exact Match
Match
},
},
32
EEE521 Final Year Project 2017/18 B00659303
33
EEE521 Final Year Project 2017/18 B00659303
34
EEE521 Final Year Project 2017/18 B00659303
35
EEE521 Final Year Project 2017/18 B00659303
36
EEE521 Final Year Project 2017/18 B00659303
The diagram shown in Figure 113.5.2 outlines the flow of data when a user requests their
account balance. The NLU determines the context and presence of required entities in user
input that was matched to an intent. The webhook then receives the user input in JSON
format.
Figure 12: “Registration and Login” UML activity diagram.
37
EEE521 Final Year Project 2017/18 B00659303
entered to verify their account, if the code is correct the user is redirected to chatbot view.
the response. Once the webhook receives the data returned by the API it encodes the data to
JSON which is as the response sent back to the NLU to be displayed to the user through the
Chatbot view.
38
EEE521 Final Year Project 2017/18 B00659303
In order to implement a successful chatbot the user group that will be interacting with it is
carefully thought through. The target audience for the chatbot consists of different age groups
with varying technical ability, as mobile banking is relevant across a broad range of age
groups. To appeal to all age groups the chatbot will utilise simplistic and straightforward
responses. Google assistant allows developers to determine a voice for their bot that matches
the personality and utilise rich responses (Actions on Google, 2018). However the majority
39
EEE521 Final Year Project 2017/18 B00659303
of users of an application like this already carry out the most part of their online interaction
through some messaging platform, so the use of such an application should come with ease
(Interactions.acm.org, 2017).
PRINCIPLES DESCRIPTION
1. Design by personality The bot personality should provide a natural and unique interaction
experience for
users. The personality should be designed to guide the users through the
interaction
which may include being aware of what the user may say or want. The
personality is
the style and manner the bot holds throughout the interaction.
2. Flexibility in response Flexible responses should be provided to user input, the bot should have
3. Text vs Custom It should be clear to the user what input is expected to carry on in the
Buttons converastion. A
text commands from the user, a good UI should render structured options to
the user
4. Simplicity in Be concise and clear in response to questions. The conversation flow should
Interaction be
40
EEE521 Final Year Project 2017/18 B00659303
5. Conversation Flow The conversation flow is important to ensure that the user is not irritated in
situations
where the bot may not be able to provide an appropriate answer immediately.
The
their query.
6. Tasks and duty The bot should deliver explicit tasks for a particular domain.
specifications
7. Rigid syntax, then People are prone to spelling mistakes or using colloquial phrases which may
NLP not be
8. Empathy and It is important that the bot builds a rapport with the user and convey emotion
emotional state in responses based on certain user input.
9. Keep conversation Users want to interact with the bot to receive answers or reach a goal quickly.
short Avoid long winded conversations as it will make the interaction feel
burdensome. This helps avoid ambiguity.
10. Triggers and actions The bot needs to persuade users and seek ways to encourage users to carry out
specific actions through the bot.
11. Predict and Bots can analyse previous input from users for important parameters, in order
personalise to
13. Providing a way out Allow user to begin the conversation again or exit the conversation.
14. User boredom The conversation should engage the user throughout the interaction.
A set of design patterns where outlined for domain specific chatbots including those utilised
within a finance industry.
Table 5: CUI Design Patterns.
41
EEE521 Final Year Project 2017/18 B00659303
DESIGN DESCRIPTION
PATTERNS
2. Cognitive load Chatbots should present coherent choices to users to reduce the
amount of effort needed for the user to interact with it. This can be
be designed with human like phrases to respond to users with in order to sound more natural.
Another design aspect will include fall-back intents. If a user utterance cannot be matched to
an intent, the chatbot will respond with a message stating it did not match the input to an intent
and prompt the user to repeat the query or provide more details. The dialog is also designed
using follow-up intents, these provide a more natural conversational flow when interacting with
the chatbot. Follow-up intents extract more information from users as and when required, for
instance; a user may say;
The chatbot is aware it needs more information from the user such as; date, time and phone
number and will therefore use follow-up intents to extract the required information from the
42
EEE521 Final Year Project 2017/18 B00659303
user. Dialogflow recommend designing a linear dialog for interactions where data present in
the conversation is extracted to help the users achieve their goal, this is applied to the
design specification is applied to the chatbot as it is an tasked-based interaction chatbot that
consist of banking domain knowledge. The user utterance can be said in many different ways:
In this example the chatbot will extract the required entity parameters ‘balance’ and
‘account’ in order to return a custom response to the user (Dialogflow, 2018).
The Ffigures 14 5s 3.8.1 and 15 6 3.8.2 illustrate show the design for the Ggoogle assistant
application. It follows a
simplistic layout so it is intuitive and efficient for users, in comparison to other forms of
traditional UI (DZone, 2018). Users can directly ask a question to the chatbot using the input
box or tapping the devices microphone. Once the icon is tapped it will activate the devices
microphone and make the user aware it has started recording and the chatbot response will be
displayed on screen instantly. Google assistant uses specific colours for each message. The
43
EEE521 Final Year Project 2017/18 B00659303
use of different colours will be utilised to distinguish between the chatbot response and the
user input.
Figure 1673.8.3 outlines shows the design for the web-based chatbot view. Users can see how
much they
spend and what they spend their money on in a graphical format, this will help users identify
over expenditures, for instance; they may realise they spend far too much on coffee each
week. It is made visually clear to the user what the bot’s response is, as each individual
message has an associated title and colour depending on whether or not it was sent by the
user or the bot.
Figure 178 3.8.4 shows the QR code displayed to users for them to scan using the
authenticator app on their device. Users will not be able to access the chatbot view without
verifying their account first as users will be prompted to enter a unique code after each login.
Once the QR code is scanned a unique 6 digit number will be sent to the user’s mobile device
44
EEE521 Final Year Project 2017/18 B00659303
for them to enter. Descriptive text will be used in order to guide the user through the process
of downloading the authenticator app.
45
EEE521 Final Year Project 2017/18 B00659303
Users will be able to view their transactions on a regular basis without the need to navigate
through various web-pages. Once the user requests to view their transactions an email will be
sent to their email address that was provided at registration.
Design Conclusion
46
EEE521 Final Year Project 2017/18 B00659303
was also added globally to the root directory in order to utilise the framework and create a
project. Figure 19204.1.1 shows the command which was executed used to install the
Laravel\Homestead vagrant box
To configure Homestead, the command presentedshown in figure 2014.1.2 was utilised applied
to initialise the environment inside the project directory.
C:\Users\dana\Documents\bot\bankbot>vendor\\bin\\homestead make
Note the IP address at the top of the file shown displayed in figure 2124.1.3 is the IP for the
Vagrant box
and the connected database is specified declared under ‘databases:’
To serve the project the “vagrant up” command shown in figure 2234.1.1, this is
executeddeployedrun withinin the
47
EEE521 Final Year Project 2017/18 B00659303
C:\Users\dana\Documents\bot\bankbot>vagrant up
The vagrant box also contains the operating system required for this project which is Ubuntu
Linux. In order to connect to the virtual machine an SSH terminal command is used to
establish a secure connection to the vagrant box.
C:\Users\dana\Documents\bot\bankbot>vagrant ssh
4.2 Authentication:
An authentication package is included with the Laravel framework that handles authentication.
The Laravel framework comes with an authentication package to handle authentication. The
command definedoutlined in figure 2454.2.1 shown below generates the foundation for
authentication. This creates the
controllers, views and routes to support authentication.
48
EEE521 Final Year Project 2017/18 B00659303
The migration command outlined in figure 267 4.3.2 creates a new migration file to update the
users table to store their Google 2-factor authentication credentials.
The G2FA() function presented defined in figure 278 4.4.1, displays the code used to
implement 2–Factor
authentication. The authenticated user is obtained and an instance of the Google2FA facade is
created. A unique secret key is added appended to the user’s record and saved to the database.
The
49
EEE521 Final Year Project 2017/18 B00659303
getQRCodeGoogleUrl methodfunction of the facçade creates an Image URL for the QR code,
thus
allowing users to scan the QR code using their authenticator app. The users email is sent along
with the secret key, and the application name (BankingBot), to their authenticator appThe users
email along with
the secret key., Users must manually enter the which they are required keyto enter upon
verifying their account. is sent to their
authenticator app along with the name of the application (BankingBot), this is to identify
which key should be used for their account. The QR image URL is then passed to the view to
display the QR code.
Figure 289 4.4.2 shows depicts the verify_g2fa() controller function which handles verification
of the unique
secret key submitted by the user., This particularthe secret key is obtained from the incoming
request which
holdings the posted data. The window variable specifies the time frame for how longwhich the
key remainsis
valid. A secret key is created every 30 seconds. If the key is valid, a database operation is
performed to set the boolean user attribute g2fa_active to true in the database , save it to the
database and save the verified useradd it to the HTTP
session to determine if the user is verified between session states. and the user is redirected to
the chatbot view.
50
EEE521 Final Year Project 2017/18 B00659303
The Laravel blade file, which defines the frontend for the account verification view, is shown
in figure 29304.4.3, the image URLurl for the QR code is used to display the image within a
HTML
image tag. The user is able to submit their secret key via the form input and Laravel comes
with built in support to prevent csrf vulnerabilities. The input is posted to the corresponding
HTTP route outlineddefined in figure 3014.4.4.
The web routes used to handle account verification are shown in the below snippet:
An authorisation link is embedded within the controller class which in turn redirects the user’s
browser to the TrueLayer’s Authorisation Server. A list of real world banks is presented where
the user can select their bank and login with their online banking credentials.
51
EEE521 Final Year Project 2017/18 B00659303
range of banks in which they have a pre-existing bank account with. Users can view their
banking information from various accounts from within the chatbot.
After successfully logging into their bank account and permitting the application access to their
sensitive data. TrueLayer API authenticates users through the OAuth2 RFC6749 flow to grant
the application access to the users’ personal banking data on their behalf once redirected back
to the web application. This is achieved by obtaining an access and refresh token through a
TLS encrypted connection, once the user is authorised and redirected back to the chatbot
application. The refresh token is stored in the database, to uniquely identify users upon each
request. The method used to retrieve the access token is shown in figure 3124.5.1
The TrueLayer API was integrated in order to access the user’s banking data enabling the
chatbot to conform to Open Banking standards . This API allows users to select from a wide
range of banks in which they have a pre-existing bank account with. Users can view their
banking information from various accounts from within the web application. TrueLayer API
authenticates users through the OAuth2 flow to grant the application access to the user
personal banking data once redirected back to the web application. This is achieved by
obtaining an access and refresh token once the user is redirected back to the chatbot
application after logging into their bank account using their online banking credentials.
The refresh token is stored in the database, to uniquely identify users upon each request.
The method used to retrieve the access token is shown in figure
52
EEE521 Final Year Project 2017/18 B00659303
The TrueLayer API is A RESTful API which returns JSON that is parsed and stored in the
database. The API is queried using HTTP requests to specified endpoints. Guzzle is
integrated to send HTTP requests to the API endpoints. A HTTPS POST request is sent to
the token endpoint of the Truelayer API containing the code retrieved from incoming request
after the user is redirected back to the web application after successfully logging into their
bank.
53
EEE521 Final Year Project 2017/18 B00659303
To retrieve the user accounts a userthey may hold with their bank the TrueLayer data APIapi
endpoint is
queried as outlined figure 323., Tthis returns a JSON object containing the account details, for
instance a user may
have a current and
savings account.
The JSON is
then decoded
and the details are
saved to
the database.
54
EEE521 Final Year Project 2017/18 B00659303
An important feature is to retrieve the users balance, to ensure users can instantly view their
account balance information. Figure 345 4.5.4 highlights shows the getBalance() method
function, t used to retrieve the users balance. This function makes a call to the defined endpoint
specified by Truelayer Data API to retrieve a user’s balance information such as available and
current balance. Firstly the result returned form the request are decoded into a PHP array and
then parsed to extract the users balance which is then stored in the database.
Figure 3564.5.5 outlines the function which retrieves the user’s transactions from the
55
EEE521 Final Year Project 2017/18 B00659303
API for a specific account. The transactions object returned from the API is filtered by the
‘merchant_name’ index as not all transactions returned contained the index ‘merhant_name’,
each transaction is then saved to the database.
The webhook was implemented as a controller class that expose the web route as an
endpoint. The webhook receives the data from Dialogflow NLU and parses the JSON to
extract the entities present the in user utterance to provide a custom response to the user.
The PHP json_decode() function is used to convert the incoming JSON Object from the NLU
into a PHP variable. The code shown in figure 3784.6.2 is a snap shot of the webhook which
returns a custom response when a user requests a currency conversion. Firstly the
appropriate entities are extracted from the request posted to the Webhook then a method call is
invoked to the function that will query the Fixer.io API using the Currency Rates library
installed and the response is returned to Dialogflow in JSON format. The response
is defined for both speech and text in the response array. Each response is sent with the header
Content type: application/json which will display the JSON in plain text to the user through the
chatbot.
56
EEE521 Final Year Project 2017/18 B00659303
Figure 3894.6.3 shows the convert function which implements the library to call the Fixer.io
API.
The required entities are extracted out of the user response and passed as parameters to the
convert function within the webhook and the conversion is returned in a string format.
57
EEE521 Final Year Project 2017/18 B00659303
When the incoming POST request is received by the webhook, the action of the request is
determined in order to return an appropriate response as outlined in figure 3940.6.4. When the
user requests to view their balance, the entity is recognised by the NLU were appropriate
actions were defined for each corresponding entity created within the DialogFlow Developer
console. The if statement within the webhook evaluates whether the requested action of the
user supplied utterance matches the action defined for the balance entity.
Figure 401.6.5 shows the Dialogflow console recognising developer defined entities from
an example user training phrase used to develop the chatbot’s knowledge base.
58
EEE521 Final Year Project 2017/18 B00659303
The chatbot was trained to recognise custom entities relevant to the banking domain. This
allows the chatbot to recognises the entities in the user utterance to deliver a relevant
response.
The retrieveTransactions() function will retrieve the users transactions from the database
using the transactions() function implemented in the user model. Laravel’s Mail::to function
is utilised to send the transactions email to the user.
The amount_spent() function is shown in figure 44,54.6.9 which iterates through each
transaction
and adds each transaction item to an array to work out the total. The sum is calculated for
every outbound transaction which is the amount the user spent over the last 7 days.
An email is sent containing the user transactions for the last seven days using the Mail::to
command as part of the mail facade. An instance of the logged in user is obtained and the
mail is sent using an instance of the Mailable class created RequestTransactions, the
59
EEE521 Final Year Project 2017/18 B00659303
transactions array is passed to the mailable class which is used to construct the email.
The following command creates the Mailable class:
.
The mailable class is used to configure and build the email that is sent to the user. The
transactions object is initialised and passed through to the mail view in the build function
shown in figure 456.6.10.
The Blade file used to format the transactions email sent to users is outlined outlined in figure
467.6.11.
It consists of markdown and HTML to display the users transactions in a table format to
replicate the design of a traditional paper based statement. Markdown components are used
60
EEE521 Final Year Project 2017/18 B00659303
to render certain UI elements such as buttons and message component which defines the
message to be displayed to users.
The code definedshown in figure 478.6.12 shows the make_appointment() function which
obtains an
instance of the authenticated user in order to make an appointment. The
required parameters used to make the appointment are passed from the webhook using a
61
EEE521 Final Year Project 2017/18 B00659303
method call defined in figure 489.6.13. In the make_appointment() function an instance of the
AppointmentReminder class is created in order to send a text notification of their
appointment. The users phone number and appointment details are passed as parameters.
Figure 49504.6.14 outlinesshows the AppointmentReminder Class which makes use of the
Twilio API to
send SMS messages to users to notify them the confirmation details regarding their
appointment. The Twilio client credentials are set in the ENV file of the project to ensure
they cannot be easily accessed.
62
EEE521 Final Year Project 2017/18 B00659303
Figure 5124.7.1 shows the function that will produce a speech synthesis of the bots response
to
the user in order to provide audio responses reducing the amount of time required to interact
63
EEE521 Final Year Project 2017/18 B00659303
with the chatbot. The HTML5 Speech API is implemented for speech recognition and
synthesis. Dialogflow comes with support for integration of the Google Assistant, supported
across an array of devices including google Home and Android devices. Dialogflow allows
developers to extend the Actionss on Google (AoG) console to test the chatbot across multiple
devices. The Google assistant integration is shown below.
Throughout the development lifecycle GitHub was integrated as the chosen method of version
control for the project. As the application was updated during each iteration, and these changes
were committed to the GitHub repository to ensure the codebase for the application was
managed effectively. Figure 523 outlines the use of the Git Bash terminal that was used to push
changes to the master branch of the project.
5. Testing:
A crucial part of any software development lifecycle is testing. This involves carrying out
certain procedures and operations to understand the limitations of the software. It is evident
that with testing the constraints of the application that particular bugs and errors are picked
up and documented through test cases. This will improve the overall standard and quality of
the chatbot and enhance the user experience.
Various testing methods were carried out in order to measure the overall effectiveness of the
chatbot. The dialog was tested to measure the efficiency of the chatbot which includes
measuring how well the chatbot can understand a user supplied utterance, even if miss spelt.
Identifying if the intent was recognised, with average response times between text and voice
64
EEE521 Final Year Project 2017/18 B00659303
interactions are also included in said response. The chatbot was tested in a specific manner to
record the performance metrics.
A Dialogflow command line tool called dialogflow-cli , written in JavaScript, was installed
into the project directory for the purpose of undertaking these tests. This was employed to
replicate how users would interact with the chatbot and metrics were recorded for each
simulated interaction.
To initialise the mock interaction for testing the tool fires a welcome event to the Dialogflow
API once instantiated in the command line, it then and displays the response returned from the
API as the result returned through the
command prompt.
Each type of use case was tested through the command line and the response was returned in
JSON format.
A total of 20 simulated utterances were tested and the results are shown in table 5. Each
utterance tested was uniquely phrased including variations of the same utterance to
accumulateaccumulate a range of results so and thoroughly classify the chatbots understanding
can be thoroughly classified.
From the results shown in the table 65 it can be determined how well the chatbot understood
the
sentence and typical response times are displayed to measure the overall performance of the
chatbot. This also outlines how it handles unexpected input, such as misspelt words. The
cconfidence score is returned along with the intent the test user phrase was matched to.
65
EEE521 Final Year Project 2017/18 B00659303
balance?
please?
details)
days?
tamsucyions 1 ✓ N/A
yen
appointment please?
66
EEE521 Final Year Project 2017/18 B00659303
089456787642
Table 65 displays the results from simulated "typical" interactions with the chatbot through the
command line tool. The simulated phrases were derived from the user questionnaires and
observing the users interacting with the chatbot, the dialog for the chatbot was devised during
the design stage. Every utterance is given an "Confidence Score", rated on a scale of 0.0 - 1,
with 1 being a complete match and 0 meaning the utterance was not successfully matched to
any intent. However, the NLU has also given words or utterances, where no intent was
recognised, a complete confidence score of 1 as it was matched to the default fall-back intent
to handle unexpected input from the user with ease. It is clear that the response times do vary
depending on the underlying functionality required for the user to achieve their goal, for
instance: ; requesting their transactions via email or the chatbot sending text confirmation of
their appointment.
Overall, the chatbot is able to match intents with the majority of the utterances with only 10%
of the utterances failing to match. This is taking spelling mistakes into account also. The total
number of successful matched intents out of 20 user phrases amounted to 80%. These results
indicate that the chatbot can understand most phrases including spelling mistakes reflecting the
quality of the dialog. The phrase "wat have I spnt this weke" (meaning "what have I spent this
week") obtained a low confidence scored of 0.33 a perfect 1 , however the chatbot was able to
understand the intent of the utterance and identify the action on the understanding score as
shown in figure 534re… even though
misspelt.
67
EEE521 Final Year Project 2017/18 B00659303
17.7897/20= 0.8894 60594 (ms) 60.594(sec) / 20 = 3.02 sec 3 minutes and 26 seconds
The average response time has been rounded to 3 seconds, which is quite a rapid response
time. This suggests that users will be able to perform their necessary tasks through interacting
with the chatbot relatively quickly which is also reflective onin the overall dialog duration as
shown in table 76, this represents the overall interaction time. The results will be further
elaborated upon in the Evaluation, with user testing results in contrast to the simulated
resultsphrases.
Both the Google Assistant and Home agent were tested through the AoG Simulator on
the Actions on Google console (AoG). The Google Assistant integration was tested through
the simulator using text input while the Google Home was tested through voice interaction on
the AoG simulator. The simulator returns a JSON object holding information regarding the
chatbots understanding level identifying whether the utterance was matched to an intenta
phrase. Similar phrases were used across devices to outline any variations in the NLU
understanding.
68
EEE521 Final Year Project 2017/18 B00659303
Intent Google Assistant Matched Google Home Matched Web APP Matched
1.Show me my ✓ 1.Show me my ✓
Transactions Transactions
69
EEE521 Final Year Project 2017/18 B00659303
Intent Google Assistant Matched Google Home Matched Web APP Matched
70
EEE521 Final Year Project 2017/18 B00659303
Tronsoctions tronsoctions
Transactions Transactions
% Response Accuracy
71
EEE521 Final Year Project 2017/18 B00659303
particular words were incomplete or missmispronouncedpelt as shown in table 87. It was found
that input text provided to the Google Assistant on android phones, follows a more rigid syntax
as it expects the intent present in the given input text to match the defined intent used within
the training phrases, however this only applies when the use of input text is provided by the
user, as the same speech recognition and machine learning algorithms are implemented with
the Google Assistant regardless of the device or surface its embedded in.
The Google
Assistant follows a more rigid NLP syntax, however this only applies when the use of input
text is provided by the user, as the same speech recognition and machine learning algorithms
are implemented with the google assistant regardless of the device its embedded in. The
speech recognition software in the Google aAssistant transforms the users speech, even if
incorrect, to the appropriate input text before itsit’s sent to the NLU. Consequently the Google
Home device This is why
the Google Home device was able to recognise and detect incomplete or missmispronounced
pelt words, as interaction only occurred through voice commands. Based on these results it is
clear that voice interaction is the optimal method of engaging with the chatbot due to it being
able to comprehend pronunciation errors and interpret them accordingly. It was also found
that the Google Assistant could only match an intent of a to a misspelt utterance when the
trained intent or recognised entity was typedspelt correctly during text interaction.
It is clear from the results shown in table 9 that the Google Home device was the prime mode
of interaction with the chatbot, as it was able to match the intent of each supplied utterance,
achieving a perfect score of 100%. Establishing that spoken natural language conversational
interfaces perform best, compared to that of text-based interactions as the Google Assistant
achieved a result of 57.14%. There is a stark contrast between the two conversational interfaces,
implying spoken dialog is a much better method of interacting with natural language
conversational interfaces. The speech recognition on the Google Assistant has a higher
recognition rate in comparison to the HTML5 Speech API as it had an average speech
recognition of 85.71%, suggesting the Google platforms will perform better in real interactions
with users.
Table 10: “Conversation exit rate”.
72
EEE521 Final Year Project 2017/18 B00659303
1. 3
2. 4
3. 4
Table 10 8 outlines the number of turns the chatbot took to try and understand the intent of an
utterance corresponding to the misspelt phrase defined in table 87 7 before exiting the
conversation. On each turn the chatbot responded with fallback intents such as: "Sorry, I did'nt
quite get that, could you repeat that please?" or "Sorry, I’m having difficulty understanding
what you said, could you say that again?”. This feature handles unexpected input or when the
chatbot cannot understand a given utterance. This also outlines the use of different fallback
intents used even if the user utterance was the same on each turn. The chatbot exited the
conversation due to repeatedly prompting the user for an appropriate utterance and lack thereof,
its inability to understand the intent of the given utterance to successfully match it to a trained
intent to carry out the appropriate action and fulfil the user’s goal.
5. 2 Webhook Testing
To test the custom fulfilment provided through the Webhook, a tool called Postman was
utilised to send HTTPS POST requests to the Webhook. This was used to test the response
sent back from the Webhook to a given user utterance. The body of the request is obtained
from the Dialogflow developer console which is sent with the POST request to the Webhook.
The body holds the JSON object which represents the users phrase along with other
parameters returned by the NLU as shown in figure 545below.
73
EEE521 Final Year Project 2017/18 B00659303
Postman was used to test the Webhooks functionality in a separate environment, in which it
was developed, meaning errors could be rectified before integrating the agentit with other it
the various various
devices such as: ; Google Assistant and, Google Home or the web based chatbot. This identified
network and access errors as status codes are returned with each response. An example of the
JSON response object returned by the Webhook is shown belowin figure 556XXXXXXXXX:
The integration of other API’s implemented within the project were also tested, to determine
whether it could successfully call the TrueLayer API and identify any required parameters or
authentication headers that were required to be sent with each subsequent request.
74
EEE521 Final Year Project 2017/18 B00659303
chatbot; Ggoogle Aassistant, Hhome and the web-based chatbot. This will give an insight into
the true
quality and overall usefulness of the chatbot which is measured by the user’s interaction
experience. In order to conduct user testing, a set of questions were constructed to evaluate
the chatbot. These questions were distributed as an online questionnaire across a group of
users which can be found in the appendix section of the report.
65. Evaluation
The purpose of evaluating the software is to identify the quality of the chatbot by outlining
the performance attributes and analysing the results, future work is purposed along with a
reflection of the current work completed.
The results from the user questionnaires gave great insight into the overall response
and precision rate. The questionnaires were distributed across a user group consisting of 15
individuals with varying technical knowledge. These were completed by parents and
prospective students at the Ulster University Open Day as part of the school of Engineering
and Computing, this user group is truly reflective of the target audience that would benefit
from an application like this. The results from the user questionnaires will be compared to the
simulated user interactions identifying subjective and objective metrics.
During the questionnaire the users were observed to capture free standing information
regarding the interaction experience which also qualify as subjective measurements. This
allowed the identification of other quality metrics which were not initially considered and
lead to a deeper understanding of the chatbots performance. (How often the chatbot repeated
itself, ).
The metrics shown in table 9 were They completed a user questionnaire targeted to capture the
quality of the chatbot.
The Subjective measurement (n)Users Objective metrics (n)Users subjective
and Naturalness 44% Speech Recognition 80% objective
metrics Likeability 93.33% Response accuracy 86.67% outlined in
table 11 Ease of use 86.66%
were
obtained using a
75
EEE521 Final Year Project 2017/18 B00659303
range of question types including Likert scale and numerical scales to accurately assess the
chatbots performance.
Each metric outlined in table 11 was measured in relation to a specific question to gather
qualitative results. These questionnaires can be found in appendices.
Table 11: “Subjective & Objective Measurements obtained from User questionnaire”.gathered from
As outlined in section 1.2 the majority of banks struggle to get their customers to use the
technology
in place due to low user satisfaction when interacting with their services. From the results
shown in table 119 it can be established that integrating a chatbot into their banking services
would greatly increase the rate of user satisfaction. This is evident as 73.33% of all users
stated the chatbot was “extremely ” quick comparedfound the chatbot to be a lot quicker tohan
the current technology offered by their
bank, for instance, online banking applications. From completing the user testing phase, it was
found that 86.66% of all respondents foundstated found the chatbot was
either “extremelyvery easy” or “moderatelyeasy” easy to talk to and it achieved an overall
likability of 93.33of 93.33% as outlined in table 119,. Rreaffirming
that chatbots can successfully engage users and increase satisfaction. The objective metrics
obtained from the questionnaire results identify the chatbots performance and quality in a real
interaction. Overall the chatbot received a very high speech recognition rate as 80.00% of users
stated they were “very strongly” well understood by the chatbot. This measurement reflects the
accuracy
76
EEE521 Final Year Project 2017/18 B00659303
of the emulated actions during testing as shown in table 7 of testingThe chatbot obtained an
overall understanding score of 0.8894 (89.00%) in the range between 0.0-1 during the
simulated tests as depicted in table 6 of section 5. This result is on the higher tier of the
understanding scale.
Evidence from the results gathered during user testing, through measuring the response
accuracy to real user interaction, that the chatbot has a high competency level as both the results
from the simulated and user tests have a very low variance of 2.33% in regards to the
understanding score. These measurements reflect the accuracy and thoroughness of the
emulated actions performed during testing as illustrated in section 5.
It is clear from the questionnaire results that the majority of users preferred to interact with
the chatbot through voice commands, with 66.67% of users preference being voice
77
EEE521 Final Year Project 2017/18 B00659303
interaction, as shown in figure 567 . This supports that more users are wishing to be able to
freely
interact with applications and not be limited to traditional modes of interaction. This feature
also offers users the ability to interact with chatbot without it requiring much attention on
focusing on the task at hand, as users ask the chatbot a question and it will recognise the users
voice negating the need for the user to type.
The focus of any chatbot is to allow users to complete tasks with ease using natural language.
It i’s important that the chatbot clearly understood the user and the user felt confident in
interacting with the chatbot. Its outlined in figure 578 that this was achieved as only 13.33%
of
users stated they were “often” left in a state where they were unsure how to carry on the
conversation. These results reflect low frustration rates among users as 60% of user never
experienced this and 26.67% stating it did not occurred “Not often.” often. This clearly suggests
the
chatbot is able to sufficiently guide users through the conversation with ease providing
appropriate responses to the majority of user phrases.
78
EEE521 Final Year Project 2017/18 B00659303
Enabling the chatbot to be context aware provides a great advantage for users as they can
simply refer back to a previous conversations and still be understood by the chatbot. This is
particularly useful in long conversational flows, reducing the amount in which the user has to
repeat themselves thus shortening the time taken to achieve a task.
65. 1 Reflection
The results gathered throughout the testing phase support the research conducted within section
1.3, which outlines the prevalence of chatbots within industries, particularly within the banking
and financial sector. The findings prove that the chatbot is a very suitable method for adopting
technology as a means to distribute a service. The developed chatbot allows users to interact
with their bank through natural language interaction, granting users more convenient and
efficient access to their banking information. The project gradually evolved and progressed
throughout its entirety and the main objectives and requirements have been met as outlined in
section 2.5.1 and 2.5.2. This chatbot allows users to connect to various banks they may have
an existing account with all from within the one communication channel through natural
language.
79
EEE521 Final Year Project 2017/18 B00659303
was brought to light through of recent media events such as the Cambridge Aanalytica
discreditscandal, that which resulted in Facebook haltedpausing their process of allowing other
apps to integrate with its messenger service app review, so this integration was not developed
as Facebook hads stopped allowing developers to create new apps or chatbots through the
service. Although Facebook have now just recently reopened their app review processs, now
allowing developersallowing developers to integrate with the Messenger service again,
enabling this integration feature to be developed for future protypes (Facebook, 2018).
Integrating Google authentication would have been an advantageous feature to implement,
allowing users to link their Google account across the multiple devices the agent is
distributed on, for instance, Google Assistant enhancing the cross-platform experience for
users.
User can find out financial information about their account, such as how much they spent
within a week. From this feature it was thought that during the later stages
of development users should be able to directly query the chatbot to determine where and
what they spend their money on. Although users can view this information in a graphical
format onin the web app it would also be useful if they could find this information out through
interaction with the chatbot.
The chatbot could also be developed to be multilingual. Supporting multiple languages would
help aid banking exclusion in developing countries and enhance the overall accessibility of
technology within the banking industry whilst targeting a larger user group.
From observing the users interact with the chatbot during user testing, there were numerous
suggestions to integrate the chatbot across other popular platforms such as Amazon Echo or
Dot, this would increase the availability of the chatbot and the integration of the DialogFlow
API allow the chatbot to be easily exported Amazon Alexa.
65.2 . Conclusion
The rise and popularity of chatbots is clearly outlined in figure 1 of section 1.3. With this in
mind the data gathered from testing the chatbot justifies the recent growth and demand for
companies wanting to integrate a chatbot. It was determined that chatbots perform at a very
80
EEE521 Final Year Project 2017/18 B00659303
high standard and provide reliable and rapid responses to users compared to that of traditional
methods. The average time spent interacting with the chatbot is very low as it provides an
efficient way for users to manage their banking. The low interaction time reflects the high
understanding and speech recognition rates, offered through the adoption of conversational
user interfaces thus allowing users to freely interact with the chatbot to meet the demands of
modern life. The chatbot has proven to fulfil the demand of users wanting instant access and
availability information and services.
Integrating sentiment analysis to capture the user’s emotions. The user’s transactions could
be analysed using NLP techniques to identify spending habits.
Due to the increased development of the IoT, it would be good to branch out into this area as
chatbots produce a
mass amount of data which is needed for concepts such as IoT and Big Data to be successful
which also go in hand with further advances in AI and Machine learning. The
IoT could be implemented through the Google Home device.
81
EEE521 Final Year Project 2017/18 B00659303
1
EEE521 Final Year Project 2017/18 B00659303
6. References
(United kingdom online banking (2002). MarketLine, a Progressive Digital Media business, 2017)
(Accessed 10/10/2017)MarketLine, a Progressive Digital Media Business. (2002). ‘United Kingdom
online banking’. Available at: http://www.marketlineinfo.com (Accessed 10/10/2017).
Ling, G., Fern, Y., Boon, L. and Huat, T. (2016). Understanding Customer Satisfaction of Internet
Banking: A Case Study In Malacca. ‘Procedia Economics and Finance’, 37, pp.80-85.n (Accessed
11/10/2017)
Barty, J. and Recketts, T. (2014). 'Promoting Competetion in the UK banking Industry', Promoting
Competetion in the UK banking Industry. BBA Competition Report., , pp. 4. Available at:
https://www.bba.org.uk/wpcontent/uploads/2014/06/BBA_Competition_Report_23.06_WEB_2.0.pdf
(Accessed 10/10/2017).
Aburub, F., Odeh, M., & Beeson, I. (2007). ‘Modelling non-functional requirements of business
Cardline. (2010). ‘Half of UK internet users now bank online’, 10(3), pp. 32-32. Availablle at:
http://web.b.ebscohost.com/bsi/detail/detail?vid=1&sid=23ade416-2f14-4608-a8a1-
3de95541175b%40sessionmgr102&bdata=JnNpdGU9YnNpLWxpdmU%3d#AN=47659678&db
=bth (Accessed 10/10/2017).
Half of UK internet users now bank online.(2010). Cardline, 10(3), 32-32, .(Accessed 10/10/2017)
HDFC bank, niki.ai tie up for chatbot banking.(2017). FRPT- Finance Snapshot, , 24-25.( Accessed
11/10/2017)
FRPT Research- Finance Snapshot. (2017). ‘HDFC Bank, Niki.ai tie up chatbot for banking’, pp
Ling, G. M., Fern, Y. S., Boon, L. K., & Huat, T. S. (2016). Understanding customer satisfaction of
internet banking: A case study in malacca. Available at doi:https://doi.org/10.1016/S2212-
5671(16)30096-X
2
EEE521 Final Year Project 2017/18 B00659303
Hugh J. Watson, H. J. (2017). 'Preparing for the Cognitive Generation of Decision Support', MIS
Quarterly
Daniëlle Duijst, D. (2017). 'Can we Improve the User Experience of Chatbots with
Personalisation?', University Of Amsterdam, (), pp. 3 [Online]. Available
at: 10.13140/RG.2.2.36112.92165 (Accessed: 11/10/2017).
Watson, A. (2010). How to succeed with NLP: Go from good to great at work using the power of
neuro-linguistic programming. Oxford: Capstone .(Accessed 11/10/2017)
KingING, W. B. (2017). Year of the chatbot: Credit unions gearing up for artificial
intelligence. Credit Union Journal, 21(4), 18-18 . (Acccessed 11/10/2017).
Dole, A., Sansare, H., Harekar, R. and Athalye, S. (2015). [online] www.ijettcs.org. Available at:
http://www.ijettca.org/Volume4Issue5(2)/IJETTCS-2015-10-09-16.pdf [Accessed 11 Oct. 2017].
D. Latimore, D I. . Watson, I. & C. Maver. C. (2000). The customer speaks: ‘3300 Internet users tell
us what
Yusuf Dauda, S.Y., & Lee, J (2015). ‘ A conjoint analysis of consumers ׳preference on future online
Goncalo Bapista, G. and Tiago Oliveira, T. (2015). ‘Understanding mobile banking: The unified
theory of
acceptance and use of technology combined with cultural moderators’, : Elsevier Ltd.
3
EEE521 Final Year Project 2017/18 B00659303
Ajimon George. A and G.S. Gireesh Kumar, G. (2013) 'Antecedents of Customer Satisfaction In
Internet Banking: Technology Acceptance Model (TAM) Redefined', Global Business Review, 14(4),
pp. [Online]. Available at: http://journals.sagepub.com/doi/10.1177/0972150913501602
Available
at: https://smartech.gatech.edu/bitstream/handle/1853/58516/evaluation_of_modern_tools_for_an_o
mscs_advisor_chatbot%281%29.pdf?sequence=1&isAllowed (Accessed: 21/10/2017).
YY Onufreiv, YY. (2017). ‘The Rise In Chatbots Trends’THE RISE IN CHATBOTS TRENDS. THE
RISE IN CHATBOTS TRENDS. - (-), 82-83. (Accessed 16/10/2017)
Eric Gregori, E. (2017). 'Evaluation of Modern Tools for an OMSCS Advisor Chatbot'. [Online].
Available
at: https://smartech.gatech.edu/bitstream/handle/1853/58516/evaluation_of_modern_tools_for_an_o
mscs_advisor_chatbot%281%29.pdf?sequence=1&isAllowed (Accessed: 21/10/2017).
Erik Cambria, E., Bebo White, B. (2014) 'Jumping NLP Curves: A Review of Natural Language
Processing Research', IEEE Computational Intelligence MAgazineCOMPUTATIONAL
INTELLIGENCE MAGAZINE. [Online]. Available at: http://sentic.net/jumping-nlp-
curves.pdf (Accessed: 21/10/2017).
https://www.bba.org.uk/wp-
content/uploads/2014/06/BBA_Competition_Report_23.06_WEB_2.0.pdf
4
EEE521 Final Year Project 2017/18 B00659303
Rohan Kar, R. and Rishin Haldar, R. (2016). 'Applying Chatbots to the Internet of Things:
Opportunities and Architectural Elements',, , (), pp. [Online]. Available
at: https://arxiv.org/abs/1611.03799 (Accessed: 06/11/2017).
Nat Landry, N. (2011). ‘ Iterative and Agile Implementation Methodologies in Business Intelligence
and
Software Development’, : Lulu Enterprises.
A B M Moniruzzaman, A. B. M. and Dr Syed Akhter Hossain, S.A. (2013). ' Comparative Study on
Agile software development methodologies', Global Journal of Computer Science and
Technology, 13(7), pp. [Online]. Available
at: https://arxiv.org/ftp/arxiv/papers/1307/1307.3356.pdf (Accessed: 08/11/2017)
Asif Irshad Khan, A.I., Rizwan Jameel Qurashi, R. J and Usman Ali Khan, U. A. (2011). 'A
Comprehensive Study of Commonly Practiced Heavy and Light Weight Software Methodologies
', IJCSI International Journal of Computer Science Issues, 8(4), pp. [Online]. Available
at: https://arxiv.org/ftp/arxiv/papers/1111/1111.3001.pdf (Accessed: 08/11/2017)
Jonathan Lazar, J. (2001) User-centered Web Development, United States of America: Jones and
Bartlett Publishers .
Graham Oakes, G. (2008). ‘Project Reviews, Assurance and Governance’, United Kingdom: Gower
Publishing Limited.
Instructional Software Research and Development (2007) Structured System Anal And Design Isrd,
New Delhi: Tata McGraw-Hill Publishing Company Limited.
Pauline M. McGuirk, P. M. Phillip and O'Neill, P. (2016). 'Using questionnaires in qualitative human
geography', University of Wollongong, Faculty of Social Sciences, (), pp. 11 [Online]. Available
at: http://ro.uow.edu.au/cgi/viewcontent.cgi?article=3519&context=sspapers (Accessed:
12/11/2017).
Melanie Exner-Stöhr , M., Alexander Kopp , A., Leonhard Kühne-Hellmessen , L., Lukas Oldach ,
L., Daniela Roth, D. Aand Alfred Zimmermann, A. (2017). 'The potential of Artificial Intelligence in
academic research at a Digital University', Digital Enterprise Computing, (), pp. 3 [Online]. Available
at: https://dl.gi.de/bitstream/handle/20.500.12116/120/paper05.pdf?sequence=1&isAllowed=y (Acce
ssed: 16/11/2017).
5
EEE521 Final Year Project 2017/18 B00659303
Kazuo Yano, K. (2017). ‘How artificial intelligence will change HR’.40(3), 43-44.(Accessed
16/11/2017)
Stuart J. Russell, S. J and Peter Norvig, P. (1995). Artificial intelligence A modern approach.
Noor Atikah, N., Amira Fauzi, A., Rohayanti Hassan, R., Zuraini Ali Shah, Z. A. and Zalmiyah
Zakaria, Z. (2016) Extraction of Non-Functional Requirements in Reviewing Requirements
Specification Document, 2, pp. 1 (Accessed 19/11/2017).
Frank Tsui, F., Orlando Karam, O. and Barbara Berna, B. (2016). ‘Essentials of Software
Engineering’. 4th Edition [Online]. Available
at: https://books.google.co.uk/books?hl=en&lr=&id=fV-
HDQAAQBAJ&oi=fnd&pg=PP1&dq=functional+and+nonfunctional+requirements+definition+soft
ware+development&ots=P3-
Cil3TVN&sig=kWwrD0XWLzWyxfi49W4XVfWxXWg#v=onepage&q&f=false (Accessed:
19/11/2017).
Milan van Eeuwen, V. M. (2017). 'Mobile conversational commerce: messenger chatbots as the next
interface between businesses and consumers', University of Twente, (), pp. 2 [Online]. Available
at: http://essay.utwente.n l/71706/1/van%20Eeuwen_MA_BMS.pdf(Accessed: 20/11/2017)
Teller Vision. (2017). 'HGS Identifies Top 10 Customer Experience Trends', Issues and Trends, (), pp.
4 [Online]. Available at: http://eds.a.ebscohost.com/eds/pdfviewer/pdfviewer?vid=14&sid=1fd6a005-
b85b-430e-b3c8-30a3f70d947e%40sessionmgr4007 (Accessed: 21/11/2017).
Bayan Abu Shawar, B. A. and Eric Atwell, E. (2007). 'Chatbots: Are they Really Useful?', LDV-
Forum, pp. 29, 30
[Online].Available: http://eprints.whiterose.ac.uk/81930/1/AComparisonBetweenAliceElizabeth.pdf (
Ac
cessed:22/11/2017).
OLGA ANNENKO, O. (2016). When to Use Webhooks vs. APIs To Sync Data Between
Applications, Available at: https://www.elastic.io/sync-data-between-applications-apis-
webhooks/ (Accessed: 01/03/2018).
6
EEE521 Final Year Project 2017/18 B00659303
7
EEE521 Final Year Project 2017/18 B00659303
7.Appendices
The appendices are an opportunity to provide secondary material in support of the description in the
body of the report. In principle, the reader need not look at the appendices and no specific marks are
awarded for this section.
Sample content:
8
EEE521 Final Year Project 2017/18 B00659303
9
EEE521 Final Year Project 2017/18 B00659303
10
EEE521 Final Year Project 2017/18 B00659303
11
EEE521 Final Year Project 2017/18 B00659303
Figure 7.1.1 responses to user that have used a chat bot before
12
EEE521 Final Year Project 2017/18 B00659303
13
EEE521 Final Year Project 2017/18 B00659303
Figure 7.1.2 results displayed for how secure users feel online banking is on Survey Monkey
14
EEE521 Final Year Project 2017/18 B00659303
15
EEE521 Final Year Project 2017/18 B00659303
16