Requirements engineering is concerned with real world goals and functions ( Sedelmaier & Landes, 2014; Zave, 1997 ). It offers suitable techniques for understanding customer needs. According to Lindquist (2005), 71% of project fails are due to poor requirements. Requirements engineering has two major phases; the requirements development and requirements management. The requirements elicitation is considered the most important step in requirement engineering ( Kitapci & Boehm, 2007). The basic purpose of eliciting security requirement is to protect the software systems. Many software systems consider security requirements to be non-functional requirements. Nevertheless, it is considered a functional requirement for other large scale security systems ( Atoum, Otoom, & Abu Ali, 2012 ; Otoom & Atoum, 2013).

This article is concerned with requirements elicitation for Cyber Security Strategies (CSSs). The elicitation is important to break the CSS into manageable, understandable requirements and identify strategic moves. They propose to carry out the elicitation using the concept of viewpoints ( Nuseibeh, Kramer, & Finkelstein, 2003 ; Salem, 2010). The software view points capture software from the purposeful aspect of related software.

For example, the finance manager is concerned with securing carried out transactions while a marking manager is mostly concerned with increasing the revenue. The viewpoints are particularly useful when a large number of stakeholders are involved in a security system. Therefore, exploiting this approach towards CSS implementation is appealing.

The proposed process for requirements elicitation is outlined in Figure 1. The CSS is taken as an input to the analysis process. The Analysis Team should include members with related expertise in the related domains. The more professional and diverse the team, the more successful the analysis output will be good. The view points of the team are gathered, incorporated, and summarized. The analysis team must resolve conflict, generate a reconciled understanding, and make sure that analysis is complete. With the application of the viewpoints, conflicts can be confronted and the requirements are conciliated.

Figure 1. Requirement Elicitation Component

First, the author has discussed the related work. Next, the paper has illustrated the proposed approach. Then the author evaluates the proposed model, and then concludes the article.

There are several requirement elicitation methods. Most methods cover requirement elicitation and analysis.

A set of security requirement systems is based on a list of use cases related to the area of study. McDermott & Fox, (1999) proposed methods for collecting and analyzing requirements for object oriented software. Their model is based on communications between the system and other users that may damage the system. Firesmith, (2003) proposed a similar approach that can identify, analyze and specify requirements. Alexander, (2003); Sindre & Opdahl, (2001) proposed another approach dedicated to non-functional requirements. These approaches have no formal analysis.

Literature also discussed graph based security requirement models. Some of these models are based on building trees of potential security aspects (e.g., faults and attacks) in order to find a formal way to protect a system ( Martins & de Oliveira, 2014). Brooke & Paige, (2003) broke down the system into subcomponents and then link to potential faults in fault tree based on defined unwanted events. Some works are based on security goals ( Li, Horkoff, Beckers, Paja, & Mylopoulos, 2015a ) while others are based on anti-goals ( Li, Horkoff, Paja, Beckers, & Mylopoulos, 2015b ) by negating security properties. Based on the list of defined security patterns, Hatebur, Heisel, & Schmidt, (2006); Yoshioka, Washizaki, & Maruyama, (2008) proposed a model to link security problems together. They applied the patterns to identify several requirements. Using semi-strutted interviews, Alsaleh & Haron, (2016) proposed an approach to extract functional and non-functional requirements for knowledge sharing systems.

Most of the methods discussed in literature are generic, informal and incomplete. To our knowledge, none of the studied methods were used in order to convert a strategic goal to a real requirement.

The author formally define Requirement Elicitation for CSS process as follows: given a set of analysts, A = {a₁ ,a₂ ,a₃ ,...,a_|A| } and the set of all domains of all analysts D={d₁ ,d₂ ,d₃ ,…,d_|D| } and W is the set of the corresponding weights of domains W={w₁,w₂ ,w₃ ,…,w_|W|}. Each analyst has an experience in years/months x in any domain d . In i i practice, selecting analysts is subjective however, the team should be diverse enough with the proper expertise. The Expertise of an analyst has been defined as in formula:

(1)

where:

A_k is any analyst ∈ A.

x_i is experience of analyst A_k measured in years or months in domain d_i

w_i is the weight of domain d_i.

This formula will help us in forming the analysis team to select those having maximum expertise. Each analyst will ultimately have an effect on the holistic security implementation, specifically on each requirement identified directly or indirectly by his/her viewpoint.

Let R be the set of all possible requirements in the CSS document, R = {r₁ , r₂ ,..., r_|R|}. Let an effective factor F be defined as the ability to identify a requirement in R. This function shows whether an analyst can identify a requirement or not. The effective factor F can be defined as a function of analysts and requirements as in formula:

(2)

where:

A_k is any analyst ∈ A. 

R_s is any requirement R. 

f is any value in the set {0,1} (i.e., the range of the effect factor).

In the set {0,1}, zero means the analyst has failed to identify the requirement and one means the analyst has fully identified the requirement. In theory, an analyst may partially identify a requirement which means the effect factor will take a value between 0 and 1. However, for simplicity, this case is neglected and a partially identified requirement is considered as if it is identified. For example, F(a₁ ,r₁ ) = 1 and F(a₁ ,r₅ ) = 0 means analyst (a₁) has identified the requirement (r₁), yet failed to identify the  requirement (r₅ ). The Strength of any requirement, R_s is defined in the formula:

(3)

where:

R_s is any requirement ∈ R 

F(A_i ,R_j ) is as defined by formula (1)  

The stronger the requirement, the more consensus the team has made on. Requirements with lower strength values mean that these requirements were identified by few or less expertize team members. These requirements should go through a reconciliation process to decide if these requirements are valid, or they were identified by mistake and should be removed. Formula (4) illustrates the Requirements Acceptance Criterion.

(4)

S(R_s) is as defined in formula (3).

θ is the requirement acceptance threshold value.

valid, means the requirements above threshold are accepted by the team.

Invalid, means the requirements are below the threshold and need to go through the reconciliation process.

Analyst Effectiveness has been defined as shown in formula (5). This function rates the effectiveness of an analyst who is participating in the requirement elicitation.

(5)

where:

A_k is an analyst ∈ A 

F(A_k ,R₁ ) is as in formula (2). 

This formula will be useful to rate the effectiveness of the analysis team. Such rating will serve as a feedback to select team members to engage in possible future cyber security requirement analysis.

Given a CSS document, the major requirements should be identified first. These requirements could be elicited from the CSS document using the proposed technique. The objective of the proposed approach is to show the technique; a complete case study is out of scope ( Atoum & Otoom, 2016 ). For example, the CSS of Jordan ( Otoom & Atoum, 2013) has several requirements: risk management, awareness, encryption and the JO-CERT requirements.

The applicability of the proposed approach has been shown by an example. Refer to Table 1 for an example to illustrate formulas (1) to (5). Each cell in the table represents the effect factor, filled using the formula (2). The higher the summation value across columns, the more consensus on the identified requirement, whereas the higher the summation values across rows reflects the experience and the effectiveness of an analyst in identifying requirements.

Table 1. Requirement Elicitation Matrix

Figure 2 illustrates an example on applying formula (4) by showing a list of requirements ordered by strength given a threshold value of 0.5. The requirements (r₅, r₁, r₄, r₇, r₂, r₃) are considered valid whereas, the requirements (r₆, r₈) should be considered further by the analysis team who will either accept or reject them depending on the reconciliation process.

Figure 2. Requirements Acceptance

The proposed approach can be applied at high level cyber security requirements. It can be applied on the identified requirements based on the management needs. In other words, the same identified requirement (by this approach) could be further detailed using the same approach.

The author proposed a new approach which is able to elicit requirement from cyber security strategies. The proposed approach is based on viewpoints concept. The cyber security goals are converted to one or more requirements by considering diverse expertise in security and management. The final decision on initial requirements are deemed to the cyber security authority. The approach is considered applicable to the cyber security strategies that are generally very abstract documents.