## 4 How to Quality Good Security Requirements? The common goal of any research contribution in the SRE community is ultimately to facilitate capturing good security requirements [29, 39, 40, 41]. If the security requirements are error-prone (i.e., ambiguous, incorrect, inconsistent) then the security design will be ineffective regardless of the successful implementation of efficient security solutions [42]. For instance, let's take as an example the security requirement that states: \"The data flow between device1 and device2 must be encrypted by a strong encryption algorithm\". This requirement is ambiguous, because it does not explicitly define what a strong encryption algorithm means. This ambiguity may lead to false assumptions concerning the rigor of security protection, which eventually impacts the decisions related to the secure solutions. The RE literature features numerous works describing different characteristics of good security requirements (a.k.a. quality criteria) such as unambiguous, traceable, consistent, etc. These characteristics help to verify and validate the quality aspects (i.e., the goodness) of security requirements. Nonetheless, there exists no consensus on how to characterize a good security requirement. In addition, there is no one complete and consistent set of characteristics [43]. In this context, we studied 185 definitions from 17 literature works depicted in Table 1. Different sources have listed different sets of criteria defining different characteristics of good requirements. The objective of this survey was to identify and study all the concepts discussed in each of the definitions, thereby analyzing the possibility to reach a consensus. Since, the list being huge and the definitions complex, we developed a semantic graph-based analysis tool using the python graph module NetworkX [55]. This allows us to formalize the definition and analyze the similarities or differences between the definitions. The nodes in the graph represent the criterion names and the concepts concerning the respective definitions. The edges correspond to the reference links expressing the semantic relation between a criterion and its associated concepts or between some criteria. For labelling the reference links (edges), we used a standard format by associating the abbreviation of the criteria with the source ID of the respective authors in Table 1 that propose the criterion. This ensures the unique interpretation of the reference links in the graph. For instance, the edge labelled M8 from node \"modifiability\" and node \"express each requirements separately\" means IEEE 830 1998 [30] (Source ID 8) refers to expressing each requirements separately in the definition of modifiability. \begin{table}
\begin{tabular}{c c c} \hline \hline \multirow{2}{*}{**Source Identifier**} & \multirow{2}{*}{**Source Name**} & \multicolumn{2}{c}{**Number of Criteria**} \\  & & **Proposed in the Source** \\ \hline
1 & ISO 29148:2011 [35] & 13 \\
2 & [PERSON] 2009 [17] & 11 \\
3 & [PERSON] 2003 [39] & 15 \\
4 & [PERSON] 1999 [44] & 10 \\
5 & [PERSON] 1996 [45] & 7 \\
6 & [PERSON] 1984 [46] & 5 \\
7 & [PERSON] and Alee 1998 [47] & 8 \\
8 & IEEE 830 1998 [30] & 9 \\
9 & [PERSON] et al. 1993 [48] & 20 \\
10 & [PERSON] 1994 [43] & 13 \\
11 & Sommerville and Sawyer 1997 [34] & 7 \\
12 & [PERSON] 2004 [49] & 15 \\
13 & [PERSON] et al. 2010 [50] & 15 \\
14 & Kar and Bailey 1996 [51] & 10 \\
15 & [PERSON] 2008 [52] & 13 \\
16 & [PERSON] and Keepence 1995 [53] & 5 \\
17 & IEEE 12333:1998 [54] & 9 \\ \hline \multicolumn{2}{c}{Total} & 185 \\ \hline \hline \end{tabular}
\end{table} 
Table 1: Quality Criteria—consolidated sources list. Figure 2 shows the complete view of the resulting semantic graph generated using Gephi tool [56]. The first result of this analysis produced a complex graph containing 212 nodes and 278 edges. The graph projects a total of 71 criterion nodes and 141 concept nodes. Every node is connected in the graph, highlighting the complexity of the semantic dependencies between the quality criteria.