# Security Monitoring during Software Development:
## 3 Methodology
### Requirements Elicitation and Architecture Design
#### 3.2.1 Requirements Elicitation and Use Case Definition  
For eliciting the requirements of the envisaged VM4 SEC security monitoring platform and defining its main use cases, we followed a formal software engineering methodology, which is based on the results of empirical/industrial studies. It is a methodology that we have widely used in past EU and nationally funded research projects (e.g., SDK4 ED and IoTAC) for requirements elicitation, based on formal principles and mature techniques from the software engineering community. The whole requirements elicitation and use case definition methodology that we followed is illustrated in Figure 9.  
As can be seen in Figure 9, the whole process consists of three main phases. In the first phase, the industrial study that was described in detail in Section 3.1.1 was conducted, which retrieved information from the subject Company through a two-step survey and a focus group. It allowed us to identify the main security monitoring needs of the Company, the core functionalities that the platform should provide, and the additional features that it should exhibit in order to be useful and practical. In the second phase, we analyzed the main outcomes that were collected by the empirical study and extracted a set of requirements that reflect the expressed needs and their corresponding use cases. In the third phase, the participants that took part in the case study performed a peer review of the produced list of the defined requirements and use cases, verified the correctness and completeness of the list, and proposed corrections and additions. Based on their feedback, the initially defined requirements and use cases were finalized. This led to the final list of requirements and use cases that the envisaged platform should satisfy. In particular, the aforementioned process led to 20 requirements and 5 use cases. More specifically, based on the information collected from the empirical case study described in Section 3.1.1 and the process presented in Figure 9, 20 requirements (8 functional and 12 non-functional) were defined. The requirements were defined using common and widely used formal templates. Based on our experience, enforcing the utilization of templates for the formal representation of the requirements allows the finally defined requirements to be (i) more understandable; (ii) easy to follow and inspect, as a unified approach is used for their description; and (iii) less error-prone. For the construction of the requirements, we adopted the guidelines of the ideal functional requirement construction  
Figure 9: The high-level overview of the adopted requirements elicitation and use cases definition process. enunciated in the standard IEEE 29148-2011. According to this standard, the definition of the functional requirements should have the following attributes (as a minimum):  
* An _ID_ for uniquely identifying the requirement, allowing it to be referenced without having to use its complete name. * A _Priority_ for declaring how important is the defined requirement for the overall system, in order to be given higher priority during the development. For defining the priority of the requirements, the Moscow method [44] was used. The priority field takes an integer value between 1 and 4, with 1 corresponding to the highest priority (i.e., declares a must-have feature) and 4 to the lowest priority (i.e., declares a secondary/optional feature). * A _Category_ that classifies the requirement to a specific group. This is important for grouping the requirements into closely related categories that should be considered together. * A _Dependency_ field for denoting whether the defined requirement depends on other requirements of the system. In this field, the IDs of the requirements on which it depends should be provided. * A _Short Description_ field that contains a very brief description of the defined requirement. This description should be clear and concise. At minimum it can be the name of the defined requirement.