# Rapid Requirements Elicitation of Enterprise Applications Based on Executable Mockups
## 3 Exploratory Case Study Research  
In order to verify if executable mockups can be used for requirements' specification from the start, we decided to conduct an exploratory case study [21; 22] with participants from various business domains. The research question and the study proposition are defined as follows:  
* **Research question:Is** it beneficial to organize collaborative development sessions based on executable prototypes in the early phases of requirements elicitation?
* **Study proposition:** Executable prototypes developed in tight cooperation with customers can enhance mutual understanding, increase customer satisfaction, and shorten the requirements elicitation phase.  
So far, we were able to organize 10 sessions. A summary of these sessions is displayed in the following sections. Developed specifications and prototype screenshots are available in [23]. These specifications can be opened and executed by Kroki. The source code of Kroki itself can be downloaded from [6].  
The participants were voluntarily joining the research. Our goal was to find the participants from different business domains, with different company positions and education levels. There was no restriction regarding age, gender, or computer literacy (see Tables 1 and 2). The participants were chosen from domains that we were not familiar with in order to avoid the influence of our domain knowledge. Participants were also not engaged in software design and construction in their workplace. They did not have previous knowledge of Kroki as a tool nor the prototyping approach on which we planned to base the communication on.  
Since we had experience with the development of several ERP (_Enterprise Resource Planning_) systems, we did not choose participants from areas usually supported by ERPs (accounting, invoicing, human resources management, asset management, production, planning, etc.). They were also not chosen from our faculty services since we cooperated with them during our in-house information system development. Although we could more easily gather participants by recruiting our students, we did not engage them because they were not a genuine substitute for real-world customers [24]. We used students for testing the Kroki tool in [25].  
The development team consisted of two researchers who conducted all sessions so as to avoid the impact of different researchers on the outcome. One of them operated Kroki during the sessions, while the other was more engaged in design decisions. Both of them were equally engaged in communication.  
Participants were asked to come to their session with a software application in mind that they would like to have developed and some artifacts (documents, forms, reports, etc.) that could help us better understand their requirements. It could be a development of a new application or an improvement of an existing one that lacked some essential features. Some of the participants were customers during software development in their companies, so they came particularly well prepared and often had examples of documents they were operating with in their everyday tasks. After the sessions, they were able to compare our approach with their previous experiences.  
The sessions were limited to a two-hour time frame. At the beginning of each session, we asked participants to briefly describe their domain, the main goals they wanted to achieve, and the application's main features. We also tried to understand the application boundaries, especially if the application was perceived as a part of an anticipated more complex system. When we felt that we acquired a basic understanding of participant's needs, we would start creating initial mockups for one of the features we agreed upon. Mockups were created using the Kroki mockup editor (Figure 3), so the participants were able to understand the process and suggest corrections. These mockups served as a foundation for further discussion and development.