wiki.ziemers.de

ziemer's informatik Wiki

Benutzer-Werkzeuge

Webseiten-Werkzeuge

Zuletzt angesehen: • requirement-analysis
wiki:software:beuthbot:requirement-analysis

Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

Link zu dieser Vergleichsansicht

Nächste Überarbeitung 		Vorhergehende Überarbeitung
wiki:software:beuthbot:requirement-analysis [10.12.2019 19:22]
Christopher Lehmann angelegt 		wiki:software:beuthbot:requirement-analysis [23.01.2020 15:32] (aktuell)
Timo Bruns
Zeile 1: Zeile 1:
-Test+===== Requirement Analysis BeuthBot ===== 
 + 
 +==== Functional requirements ==== 
 + 
 +''/F100/'' The system must allow the user to enter requests by text or language\\ 
 +''/F101/'' The system should be able to learn from errors from incoming messages\\ 
 +''/F102/'' The system must understand user input\\ 
 +''/F103/'' The system must be able to respond contextually to user input\\ 
 +''/F104/'' The system must persist messages in a database anonymously\\ 
 +''/F105/'' The system must be able to persist and retrieve specified preferences for users\\ 
 +''/F200/'' The system must be able to retrieve the Beuth Mensa menu for a specific day from the [[https://openmensa.org|OpenMensa API]]\\ 
 +''/F201/'' The system must be able to forward the menu from the OpenMensa API\\ 
 +''/F202/'' The system must be able to filter and probe the menu according to the user's specifications\\ 
 +''/F203/'' The system must be able to cache the food plan\\ 
 + 
 +''/F300/'' The system must be able to access the learning rooms of Beuth University of Applied Sciences Berlin\\ 
 +''/F301/'' The system must be able to forward where the learning rooms are located.\\ 
 + 
 +''/F400/'' System must be able to remind user of appointments\\ 
 +''/F401/'' The system must have access to the user's appointment calendar\\ 
 + 
 +''/F500/'' The system must be able to call up the opening hours of the Beuth University buildings.\\ 
 +''/F501/'' The system must be able to cache opening hours\\ 
 + 
 +''/F600/'' The system must be able to retrieve the current weather for Berlin via a [[https://openweathermap.org|Weather API]]\\ 
 +''/F601/'' The system must be able to forward the current weather\\ 
 +''/F602/'' The system must be able to cache the current weather\\ 
 + 
 +''/F700/'' The system must be able to call up the examination dates for exams at the Beuth University for Applied Sciences\\ 
 +''/F701/'' The system must be able to forward the test dates\\ 
 +''/F702/'' The system must be able to filter and probe the examination dates according to user specifications\\ 
 +''/F703/'' The system must be able to cache the test dates\\ 
 + 
 +''/F800/'' The system must be able to call up the winding rooms at the Beuth University for Applied Sciences.\\ 
 +''/F801/'' The system must be able to forward where the winding rooms are located.\\ 
 +''/F802/'' The system must be able to cache the winding rooms\\ 
 + 
 +==== Non-functional requirements ==== 
 + 
 +''/NF100/'' The system must respond to a message within 3 seconds\\ 
 +''/NF101/'' The system must retrieve data from the microservices within a few milliseconds\\ 
 +''/NF102/'' The system must be able to process and evaluate a message within 1.5 seconds\\ 
 +''/NF103/'' The system must have enough memory for persistence of data from ~13k students\\ 
 + 
 +''/NF200/'' Service downtime (NLP component, microservices, gateway) should be less than 1%\\ 
 +''/NF201/'' ref. ''/NF100/''\\ 
 +''/NF202/'' ref. ''/NF101/''\\ 
 +''/NF203/'' ref. ''/NF102/''\\ 
 +''/NF204/'' Database downtime should be less than 1%\\ 
 + 
 +''/NF300/'' The system should be as modular as possible\\ 
 +''/NF301/'' The system should be easily scalable\\ 
 +''/NF302/'' The system should contain easily replaceable components\\ 
 +''/NF303/'' The system should store understandable error messages\\ 
 + 
 +''/NF400/'' The system should be easily portable to other systems\\ 
 + 
 +''/NF500/'' The system should comply with DSGVO guidelines\\ 
 +''/NF501/'' The system should be based on security standards\\ 
 +''/NF502/'' Databases should be protected from unwanted access\\ 
 +''/NF503/'' The databases should be password protected\\ 
 +''/NF504/'' The databases should be based on security standards\\ 
 + 
 +''/NF600/'' The system should restart the service independently in the event of a service failure\\ 
 + 
 +''/NF700/'' The system should be well documented\\ 
 +''/NF701/'' The system should be easy to understand\\ 
 + 
 +==== Use cases ==== 
 + 
 +In the following we present three usecases in detail, which exemplarily describe our functional requirements. 
 + 
 +=== Use case /F103/ === 
 + 
 +**Title**: Responding to user input 
 +  
 +**Short description**: User sends a message to the chatbot via text or speech and the bot replies to it. 
 + 
 +**Actor**: User 
 + 
 +**Preconditions**: The chatbot, NLP component, gateway, registry and microservices are running 
 + 
 +**Basic flow**: The user writes a message to the bot via telegram. This message is processed and evaluated by the NLP component, then the message, including the evaluation of the NLP component, is persisted in the database and forwarded to a corresponding microservice, which then generates a response and sends it back. 
 + 
 +**Effects**: The user gets a reply from the chatbot, which refers to his message. 
 +  
 + 
 +=== Use case /F200/ === 
 + 
 +**Title**: User asks for today's menu of the mensa 
 +  
 +**Short description**: User sends a request to the chatbot that he would like to know what there is to eat in the mensa today. 
 + 
 +**Actor**: User 
 + 
 +**Preconditions**: The chatbot, the NLP component, the Mensa micro service, the gateway and the registry are running. 
 + 
 +**Basic flow**: The user writes a message to the bot via telegram. The NLP component recognizes that the user wants to have today's menu of the mensa. The evaluated message is forwarded to the mensa microservice. The microservice reads out what is required and asks the OpenMensa API for the mensaplan for the Beuth University of Applied Sciences. An answer is generated from the object which the microservice receives from the API and sent back to the user. 
 + 
 +**Effects**: The user gets an answer from the chatbot containing today's menu of the mensa. 
 + 
 +=== Use case /F300/ === 
 + 
 +**Title**: Output learning spaces 
 +  
 +**Short description**: The user wants to know which learning rooms there are and where they are, the chatbot gives him the information. 
 + 
 +**Actor**: User 
 + 
 +**Preconditions**: The chatbot, NLP component, gateway, registry, and learning room service are running. 
 + 
 +**Basic flow**:  User writes to the chatbot that he wants to know which learning rooms there are. The system processes the message and forwards it to the learning room microservice. If the learning rooms have not yet been cached, the service uses web scraping to search for the required information on the corresponding website, generates a response from it and sends it to the user. 
 + 
 +**Effects**: The user receives an answer from the chatbot containing the required information. 
 +<WRAP pagebreak></WRAP>
wiki/software/beuthbot/requirement-analysis.1576002177.txt.gz · Zuletzt geändert: 10.12.2019 19:22 von Christopher Lehmann

Seiten-Werkzeuge