## 4 The Research Method
### The Experiment Setup  
During our controlled experiment, the participants were asked to upgrade an existing information system with new functionalities. The system consisted of Jakarta EE (v10) backend, running on a Wildfly/JBoss application server (v.32), storing data in a relational database (configurable H2/MySql/PSql via Java Persistence API) and a simple web-based user interface (Jakarta Server Faces). The architecture and technological stack of the system was standard and familiar to the experiment participants (please see Section 5 for details), which was checked additionally with the pre-test questionnaire (step 3, see Figure 2). Familiar technologies were chosen since we did not want results to be affected by technology-based drawbacks. Functionally, the system was part of a retailer internal application ecosystem with a simple aim: monitoring the temperature at which products are stored and alarming if a particular temperature measurement goes out of the allowed thresholds for the stored product. On the user interface, in this case, the measured temperature is marked as \"not OK\". Some representative examples of the user interface can be seen in Figure 3.  
As a part of the experiment set-up, we prepared the participants with the initial push to a clean GIT repository (in our case GitLab), where we put all the source code and the documentation related to the system. We also handed them the documentation of the new requirements and the templates (spreadsheets) for the planning phase. **In experimentation session 1** (out of 3), which lasted approximately 3 h, we started with the presentation. During the presentation session (steps 1 and 2, see Figure 2), we presented the system in detail, performed a source code walk-through and demonstrated the development environment setup and initial run. We also presented the new requirements, which consisted of 8 user stories, accompanied by detailed specifications:  
* **User Story #1: Email notification** in case of a measurement outside the tolerances. The participants were instructed that the notification should have included the following information: the product, its permitted temperature tolerances, the measurement taken and the exact time of the measurement. Additionally, they had to ensure that the email was sent from a dedicated email address. * **User Story #2: Monthly reporting** of measurements outside of the allowed tolerances. The monthly report should have included all the measurements, no older than 30 days, that were outside the tolerances. They should have been organised by deviation from  
Figure 3: Sample flow of the system that participants were required to upgrade. the allowed temperature, in descending order, and should have also included the number of improper measurements for each product. * **User Story #3: Colour coding** of the measurement history. The Table with the measurement history should have highlighted the inappropriate measurements in red and the appropriate measurements in green. * **User Story #4: Support for the imperial and metric systems. ** The participants were instructed to introduce settings in the menu that allowed switching between metric and imperial measurement systems. Depending on the choice, the user interface should also have displayed the label \({}^{\circ}\)C or \({}^{\circ}\)F throughout. * **User Story #5: Display products on a graph. ** We wanted to have the product graph in the application menu, which showed products based on their allowed temperature tolerances. This graph would later serve as a basis for highlighting products visually (and their temperature tolerances) in terms of their potential for shared storage. * **User Story #6: Option to import data** from an offline temperature sensor. In case a specific measurement (date, time) has already been imported, the participants were instructed not to import the data again. * **User Story #7: Temperature trend graph** for each product.