Functional Specification For Student Bot Network

Functional Specification For Student Bot Network === __Student 1:__ Conor Carney __Student Number:__ 16363111 --- __Student 2:__ Ben Clarke __Student Number:__ 15337426 --- __Supervisor:__ Dr. Darragh O'Brien __Completion Date:__ 06/12/2019 --- ## Table of Contents 0. [__Table of Contents__](#0-Table-of-Contents) 1. [__Introduction__](#1-Introduction) - 1.1 Purpose - 1.2 Scope - 1.3 Document Overview 2. [__General Description__](#2-Description) - 2.1 Product/System Functions - 2.2 User Characteristics and Objectives - 2.3 Operating Scenarios - 2.4 Constraints 3. [__Functional Requirements__](#3-Functional-Requirements) - 3.1 Function like a Bot - 3.1.1 Description - 3.1.2 Criticality - 3.1.3 Technical Issues - 3.1.4 Dependencies with other requirements - 3.2 Platform as a Service (PaaS) - 3.2.1 Description - 3.2.2 Criticality - 3.2.3 Technical Issues - 3.2.4 Dependencies with other requirements - 3.3 Function as a Service (FaaS) - 3.3.1 Description - 3.3.2 Criticality - 3.3.3 Technical Issues - 3.3.4 Dependencies with other requirements - 3.4 Natural Language Processing (NLP) - 3.4.1 Description - 3.4.2 Criticality - 3.4.3 Technical Issues - 3.4.4 Dependencies with other requirements - 3.5 Language Translation - 3.5.1 Description - 3.5.2 Criticality - 3.5.3 Technical Issues - 3.5.4 Dependencies with other requirements 4. [__System Architecture__](#4-System-Architecture) - 4.1 System Architecture - 4.2 Description of System Architecture Diagram 5. [__High Level Design__](#5-High-Level-Design) - 5.1 Diagram - DFD - 5.1.1 Diagram Description - 5.2 Diagram - LDS - 5.2.1 Diagram Description 6. [__Preliminary Schedule__](#6-Preliminary-Schedule) 7. [__Appendices__](#7-Appendices) - 7.1 Appendix A (References) --- ## 1. Introduction ### 1.1 Purpose The following functional specification document is designed to give a broad overview of the proposed Student Bot Network. It will allow new and existing students of Dublin City University to interact with the bot on any of our supported social messaging apps. Students will be able to query the bot with questions relating to their class schedule, room availability, locating rooms or buildings on campus and also in relation to public transport services. The plan is to have a certain number of functions available to the user on initial release with the easy option of scalability available in regards to adding in newly requested functions. ### 1.2 Scope This network is being developed to aid new students that find settling into college a bit difficult in relation to their class schedule and navigating their way around campus. It will also provide existing students with a new way of easily accessing this information by sending a simple query to our bots. Students will be able to access our bots through the following social messaging apps, Facebook Messenger, Discord and Slack. ### 1.3 Document Overview The rest of the document is as follows: __Section 2__ aims to cover the overall purpose of the bot network,its objectives, features and constraints. This section gives a high level overview. __Section 3__ will cover the functional requirements and the actions the user must follow to get up and running with our bot network so the interactions can begin. __Section 4__ will involve covering the networks architecture with the use of diagrams to aid the explanation. __Section 5__ will cover the high level design with the aid of diagrams. __Section 6__ will give an overview of the preliminary schedule followed by Gantt chart showing how our work was carried out along with the dates and duration of each task. __Section 7__ will contain a glossary along with additional information that fully explains the functionality of the product. --- ## 2. General Description ### 2.1 Product / System Functions Below is a list of the main functions that our project will contain. If needs be, new functions can be easily added due to the scalability of our network which will be covered in section 3. - Help - What’s next - Free room - Where is - Route to - Next bus - Coin flip ### 2.2 User Characteristics and Objectives As the bot network will be available through Facebook Messenger, Slack and Discord, the network is available to anyone who has a device capable of accessing these messaging apps and internet access. The majority of the target audience will be made up of students who are new to DCU with the remainder being existing students. The bot network will be easily accessible to the user. Fortunately the network does not require the user to have an extensive knowledge of how it works. The user just simply queries the bot with a set question. The list of set questions will be available to the user by simply sending the message “help” to the bot, which will then return a subset of the most frequently asked questions along with a link to a Wiki page for further reading. For new students who are only making themselves familiar with daily life on campus all functions will provide great help to them. Whereas for the student who is already familiar with the buildings and classes on campus allowing them to easily find out what class they have next through a single message will reduce the time they would regularly spend searching to find what class they have next. ### 2.3 Operational Scenarios _Help_ If a user queries the bot correctly with the message ‘help’, the bot will respond with a subset of the most commonly asked questions along with a Wiki link. The Wiki link will contain additional information that can help to better the users experience with the bot. _What’s next_ If a user queries the bot correctly with the message ‘What’s next for (Course Code)’ the bot will return the module code, the name of the module, the class type (e.g. Tutorial), the room name and time the class begins at. ![](https://imgur.com/TAPXqsZ.jpg) _Free Room_ If a user queries the bot correctly with the message ‘Is (room name) free’, the bot will respond saying that the room is either free or in use at this time. This will aid students who are looking for free rooms that they can study in. _Where is_ If a user queries the bot correctly with the message ‘Where is (room name / building name)’ , the bot will respond with a Google Maps link to where on campus the building in which the requested room is situated. _Route To_ If the user queries the bot correctly with the message “How do I get to (address)”, the bot will respond with the overall time and route with a google map link of the route to the address supplied. _Next Bus_ If the user queries the bot correctly with the message “When is the next bus from (stop number)”, the bot will respond with the next 3 available busses from the bus stop supplied. ### 2.4 Constraints A list of possible constraints that we may face can be found below: - __Internet Connection__ As the users of the network may not always have a stable internet connection / no internet access at all, this means that they may not always be able to interact with the bot or the bot may be slow to respond. - __Unexpected Platform Errors that havent been caught during testing a go__ Scenario 1: Overtime as the user exercises the network, it is possible for the user to query the bot with something specific that could throw an error that hasn’t been caught during the testing phase. Scenario 2: As the messaging platforms are constantly upgrading their services, these upgrades might cause some issues for the user due to these upgrades resulting some downtime or unavoidable errors that cannot be caught during the testing phase. - __Function server and/or Messaging Services having unavoidable downtime__ It is possible that the network may experience some downtime due to the function server and/ or the messaging services having unforeseeable downtime due to the abstract nature of the service. --- ## 3. Functional Requirements ### 3.1 Function like a Bot #### 3.1.1 Description It is essential that the bot behaves like a bot, meaning that the responses must be quick and must be what the user requested the bot for. #### 3.1.2 Criticality This aspect of the project is vital as there is an expectation for a bot to do what is requested as quickly as possible. #### 3.1.3 Technical issues As the bot is making API calls and sending information to URLs via GET and POST requests, the main issue will be formatting the output from each call to the correct format to use later in the system. #### 3.1.4 Dependencies and other requirements The bots response time is dependant on the users internet connection as this will determine if the user can successfully query the bot and also determine how quick the responses will be. ### 3.2 Platform as a Service (PaaS) #### 3.2.1 Description Platform as a Service (PaaS) is a cloud computing model that has scalability and resilience at its heart. It requires no expensive hardware or software to run, just a node on a PaaS providers infrastructure. In the groups case this PaaS provider is Heroku and supports a large range of programming languages. #### 3.2.2 Criticality As the code for the bots will be hosted on this infrastructure, it is very critical that this service is kept up to date and maintained sufficiently. #### 3.2.3 Technical issues As Heroku is run on individual git repositories, a technical issue may be correctly updating these repositories with fixes and updates. #### 3.2.4 Dependencies and other requirements The main dependency is Heroku and the platforms ability to remain in a 'live' state. ### 3.3 Function as a Service (FaaS) #### 3.3.1 Description Functions as a Service (FaaS) is a cloud computing model that enables users to develop applications and deploy functionalities without maintaining a server, increasing process efficiency. The service that will be used is OpenFaaS. OpenFaaS is programming language independent via the use of Docker, meaning any programming language can be used to write the functions. #### 3.3.2 Criticality As the functions that the groups bots will call to retrieve the required information for the user are hosted here, it is essential that these functions are kept up to date in order to continuously get the correct information to the user. #### 3.3.3 Technical issues As OpenFaas is deployed on Docker Swarm, the issue of keeping this updated and 'live' through the use of a DigitalOcean server may arise and result in some short periods of downtime. #### 3.3.4 Dependencies and other requirements The main dependency is Docker Swarm and the services ability to remain in a 'live' state and correctly build new functions and update existing functions. ### 3.4 Natural Language Processing (NLP) #### 3.4.1 Description The groups use of Natural Language Processing is to score and interpret the intention of the users input to determine the correct call to the FaaS functions and to determine what language the user is entering for use in the language Translation(section 3.5). #### 3.4.2 Criticality It is critical that the NLP returns the correct intent score for the function call as it is vital for the user to receive the correct response. #### 3.4.3 Technical issues Issues can arise in the error handling if none of the return intent scores meet the required for a function call. #### 3.4.4 Dependencies and other requirements Wit.ai is the api that the group will be using for NLP and Language Translation(section 3.5) as this is does both jobs in a single API ### 3.5 Language Translation #### 3.5.1 Description The groups use of Language Translation is to convert the users input from their native language to English. Once the text is translated, it is then run through the Natural Language Processing to work out the intent. After the intent is worked out, the corresponding function is then called. Once the response has been generated, it will then be translated back to the users native language before being returned to the user. #### 3.5.2 Criticality The Language Translation will be critical for non-english user queries as the functions are developed in the english language and the query will need to be translated to and from the users language. #### 3.5.3 Technical issues Similar to Natural Language Processing (NLP)(section 3.4), any potential issue will arise in the error handling as a result of non-supported languages. #### 3.5.4 Dependencies and other requirements Again, similar to Natural Language Processing (NLP)(section 3.4), Wit.ai will handle the detection and translation of the users input language. --- ## 4. System Architecture ### 4.1 System Architecture Diagram ![](https://imgur.com/HwY7uH8.jpg) ### 4.2 Description of System Architecture Diagram The above system architecture diagram shows the different components that make up the bot network. The actor queries the bot on any of the messaging apps. These messaging bots are stored on Heroku which will ping the corresponding function(s) that are held in OpenFaas. This will then generate a response that the bot will return back to the actor in a natural language format. --- ## 5. High Level Design ### 5.1 Data Flow Diagram ![](https://i.imgur.com/kcajhWU.jpg) ### 5.1.1 Description of Data Flow Diagram The Data Flow Diagram gives high level overview of how data enters and exits the system and how it is transformed while in the system. When the user messages the bot, that message is attached to an API call to our translator. From there the translation is sent via an API call that returns a json object which includes intention data plus function scoring and is returned to the bot. This intent payload is then sent via a GET request to the correct FaaS function as indicated by the intention data. This is returned as a string and is then passed to the response translator via an API call which returns the required language translation as a string. Finally the translated response is returned to the user via a json payload. ### 5.2 Logical Data Structure Diagram ![](https://i.imgur.com/YewYi90.jpg) ### 5.2.1 Description of Logical Data Structure Diagram The logical data structure diagram provides a high level overview of how the user will interact with the bot network. The user will issue the bot with a query. The bot will then send the users query to be translated to English. Once in English, the query will then pass through Natural Language Processing to determine what function will be called. Once function as been determined, this is added to a request payload that is sent to our Functions Service. This runs the required function and returns a response, typically in structured English, which is then sent back to the bot. The bot then sends this response to be translated back to the users natural language, finally to be returned back to the user. --- ## 6. Preliminary Schedule | Sprint | Length | Start | End | Objectives | |----------|:-------------:|------------:|----------:|----------------:| | 1 | One week | 06/12/19 | 13/12/19 | Upskilling in NodeJS | | 2 | One week | 16/12/19 | 23/12/19 | Platform Approach Research | | 3 | Two weeks | 23/12/19 | 06/01/19 | PaaS Creation| | 4 | One week | 06/01/20 | 13/01/20 | Function Approach Research | | 5 | Two weeks | 13/12/19 | 27/01/20 | FaaS Creation| | 6 | One week | 27/01/20 | 03/02/20 | Paas and Faas Testing | | 7 | One week | 03/02/20 | 10/02/20 | Paas and Faas Integration | | 8 | One week | 10/02/20 | 17/02/20 | Translation and NLP Integration | | 9 | One Week | 17/02/20 | 24/02/20 | Load Testing | ```mermaid gantt title Preliminary Schedule Chart section Sprint 1 Upskilling in NodeJS :a1,19-12-06,7d section Sprint 2 Platform Approach Research :a2, after a1, 7d section Sprint 3 PaaS Creation :a3, after a2 , 14d section Sprint 4 Function Approach Research :a4, after a3, 7d section Sprint 5 FaaS Creation :a5, after a4, 14d section Sprint 6 Paas and Faas Testing :a6, after a5, 7d section Sprint 7 Paas and Faas Integration :a7, after a6, 7d section Sprint 8 Translation and NLP Integration :a8, after a7, 7d section Sprint 9 Load Testing :a9, after a8, 7d ``` --- ## 7. Appendix ### Appendix A #### References - [Messenger Platform Documentation](https://developers.facebook.com/docs/messenger-platform/) --> https://developers.facebook.com/docs/messenger-platform/ - [Discord Development Documentation](https://discordapp.com/developers/docs/intro) --> https://discordapp.com/developers/docs/intro - [Slack API Documentation](https://api.slack.com/) --> https://api.slack.com/ - [Wit.ai Documentation](https://wit.ai/docs) --> https://wit.ai/docs - [OpenFaaS Documentation](https://docs.openfaas.com/) --> https://docs.openfaas.com/ - [Heroku Documentation](https://devcenter.heroku.com/) --> https://devcenter.heroku.com/

Syntax	Example	Reference
# Header	Header	基本排版
- Unordered List	Unordered List
1. Ordered List	Ordered List
- [ ] Todo List	Todo List
> Blockquote	Blockquote
Bold font	Bold font
Italics font	Italics font
~~Strikethrough~~	~~Strikethrough~~
19^th^	19^th
H~2~O	H₂O
++Inserted text++	Inserted text
==Marked text==	Marked text
[link text](https:// "title")	Link
![image alt](https:// "title")	Image
`Code`	`Code`	在筆記中貼入程式碼
```javascript var i = 0; ```	`var i = 0;`
:smile:		Emoji list
{%youtube youtube_id %}	Externals
$L^aT_eX$	L^aT_eX
:::info This is a alert area. :::	This is a alert area.