Natural language requirement descriptions are often unstructured, contradictory and incomplete and are therefore challenging for automatic processing. Although many of these de cits can be compensated by means of natural language processing, there still remain cases where interaction with end-users is necessary for clari cation. In this vision paper, we present CORDULA, a system using chatbot technology to establish end-user communication in order to support the requirement elicitation and partial compensation of de cits in user requirements.
Copyright c 2018 by the paper's authors. Copying permitted for private and academic purposes.
1For more information about OTF computing, visit http://sfb901.upb.de
During the development and testing of the current version of CORDULA, we mainly faced four types of challenges.
The rst two challenges are related to the compensation of incompleteness and inaccuracy in UR. There are always cases in which no gold standard exists for compensation (missing information) or in which several di erent suggestions have the same probability (stalemate situation). In such cases, the system cannot make a decision and relies on end-user interaction.
The third and fourth challenges arise from the di erent NLP components CORDULA uses. Heterogeneous results (e.g. POS tags) of individual components (e.g. requirement extraction and lexical disambiguation) can con ict each other (contradictory information). In the past, we tried to solve this problem by assigning some priority to one of the con icting components, which means that one partial result is overwritten by another. However, the predominant component may have been wrong in its decision and destroys the overall result. For example, if the requirement extraction has recognized a process word (\to display") and the component for lexical disambiguation detects this word as a noun (\display"), it will overwrite the previous POS tag. As a result, no structured software requirement can be generated, because the core process word (Action) is missing and the requirement will simply be ignored. It would be easy to detect this error because there has to be at least one process word per sentence, but the nal decision must be made by the end-user in this case (known but not solvable problems).
Sometimes situations arise in which information must be provided subsequently or the system is unable to cope with a given input. However, it cannot be assumed that end-users will be able to understand the identi ed problems at once and solve them. For this reason, we develop a Knowledge Base (KB) and enrich it with instructions and examples. Moreover, it is not su cient to attach a chat functionality to the existing system, but it must become the single point of contact for the users. For this reason, several design questions arise in addition to conceptual questions. 3
The revised version of CORDULA aims to overcome the named weaknesses of the existing system. This already begins with the design of the web interface, which has to be changed in that a dialog between end-users and the system is in the centre of attention (cf. Figure 2) and also a ects fundamental system components such as the KB or the internal communication between the system components.
The idea of using a chatbot has a strong e ect on the underlying system architecture of the current version of CORDULA. Until now, the entire processing pipeline was concentrated on a static input text. Now, new information can be added which can also a ect already processed requirements. For this reason, a requirements manager should be installed to monitor the e ects of the user dialog as well as the changes in the software requirements made via the GUI. 3.1
The main layer shown in Figure 2 is divided into two parts: a chat window on the left and the \speci cation box" on the right. The chat window expects input from end-users in order to provide requirements and additional information. The user input will be forwarded to the server and processed. The server's response will be articulated via the chatbot. Inaccuracies are pointed out and a selection of tailored action proposals is o ered (e.g. context-speci c suggestions to compensate incompleteness, cf. Figure 3). While chatting, the end-users can con rm the system's suggestion or reject it. Additionally, the requirement can be edited or deleted. This means that users communicate with the system in two ways. On the one hand, users transfer the requirements to CORDULA via the chat interface and receive an immediate response. On the other hand, they will be asked to react to certain circumstances (e.g. missing information) and get a chat that adapts to the situation. These interaction possibilities are directly related to the chat history (cf. Subsection 3.2), in which further instructions and examples can be given by CORDULA. As shown on the right-hand side of Figure 2, end-users can oversee and edit the software requirements. This view also contains additional information on semantics and (lexical) annotations and is considered as a debugging view. In order not to discourage the end-users, CORDULA should brie y explain the functions at the beginning of the conversation. End-users should continue only transmitting their requirements and, in the best possible case, not take any further action at all. 3.2
For a better understanding of CORDULA's functionality, we illustrate an exemplary conversation and interaction of CORDULA and a user below. The dialog below (Table 1) is a protocol of how the actors and system components could interact, demonstrated through a vague user requirement.
Action <accesses CORDULA's web GUI> <explains functionality, o ers help> <asks for requirements, gives examples> \I want to send large emails." <NLP> <Requirement Classi cation: true> <OnTopic Classi cation: true> <Semantic Information Labeling: Role, Priority, Action, Object> <Indicator Checking> <Token \large" classi ed as vague> <Action: send , Object: emails ! Email-Service added> \A vague term has been found: large emails.
Please use concrete values (e.g. 500 MBs)." <clicks the edit button> 2Requirement Extraction and Classi cation Tool [DG16] Notes structures, annotations etc. input: Chat or Requirement? input relevant/on topic? requirement labels for further analysis pattern/rule-based search e.g. list matching or from KB KB: Action-Object relation corresponds to Service
Figure 2 [DG16] [DG16] Fig. 3, [DG16] <\I want to send large emails of at least 200MBs."> <submits the changes> <processing like before> <requirement and speci cation is updated> \Your requirement seems to be correct now. New functionality E-Mail Service added to your speci cation." templates used by bot for prompts and responses As we have shown, our current approach for the automatic detection and compensation of linguistic inaccuracies and incompleteness is not able to solve all de cits (cf. Section 2). Therefore, we still depend in part on information provided by end-users. However, since these users have no technical background, they must be supported by a chatbot to be e ciently guided through this process (cf. Section 3). At this point, as we have pointed out, it is not su cient to simply add a chatbot to the previous system. Rather, the entire architecture of the system should switch to interaction and also adapt the design of the GUI. Here, we already outlined some changes we expect to see. However, we expect further challenges, which will accompany us in the development of the next version of CORDULA. The vision described here is only a beginning.
Communication: In the current version of CORDULA, end-users transfer a coherent text to the system as one RD. This puts the individual statements in context. A chat dialog, as we want to introduce it, breaks up this context, which can make processing, such as disambiguation, more di cult. Furthermore, the text quality could further decrease because end-users use a kind of \chat language". Both cases make it necessary to revise the current requirement extraction and classi cation and to train for the new text genre.
Knowledge base: NLP resources in the area of UR are very rare [TLK15]. This includes resources for detection and compensation as well as real UR, which are needed for machine learning approaches. This problem is aggravated by the lack of instruction texts and examples as needed in our chat approach. Users are supported by the system only if it is very close to their own requirement description in domain and wording. A rigid collection of example sentences does not do justice to this claim. An approach for context-sensitive help and requirement examples must be found here.
We believe that we meet the requirements of OTF computing for a fast execution, even with a slower chat solution. The composition of services is a complex task whose success also depends on correctly recognized UR.
This work was partially supported by the German Research Foundation (DFG) within the Collaborative Research Center \On-The-Fly Computing" (SFB 901). [SJ15]