Most of the security strategies today are primarily designed to provide security protection, rather than to solve one of the basic security issues related to adequate software product architecture. Several models, frameworks and methodologies have been introduced by the researchers for a secure and sustainable software development life cycle. Therefore it is important to assess the usability of the popular security requirements engineering (SRE) approaches. A significant factor in the management and handling of successful security requirements is the assessment of security requirements engineering method performance. This assessment will allow changes to the engineering process of security requirements. The consistency of security requirements depends heavily on the usability of security requirements engineering. Several SRE approaches are available for use and each approach takes into account several factors of usability but does not cover every element of usability. There seems to be no realistic implementation of such models because the concept of usability is not specific. This paper aims at specifying the different taxonomy of usability and design hierarchical usability model. The taxonomy takes into account the common quality assessment parameters that combine variables, attributes, and characteristics identified in different approaches used for security requirements engineering. The multiple-criteria decision-making (MCDM) model used in this paper for usability evaluation is called the fuzzy AHP-TOPSIS model which can conveniently be incorporated into the current approach of software engineering. Five significant usability criteria are identified and used to evaluate the six different alternatives. Such strategies are graded as per their expected values of usability.
It is evident that the digital age is now a much more threatening place. Electronic devices are progressively connected, making it easier for adversaries to attack virtually everyone in the world, often with quite minimal harm. Even basic software that shows or changes local files needs to be safe since users can access or modify high-risk documents that are received via e-mail. Sadly, many software engineers never learnt to write stable apps. With the increase of cybercrime, application security has becoming a major challenge for system managers and cyber users worldwide [
All the relevant details that people will definitely like privately are things like emails, identities or even bank account numbers. Therefore security is crucial to ensure the information is safe, the connection between the company and its customers clearly evolves and improves. If user knows that his data is safe, he would certainly retain their dealings with a software development firm. Software should be compatible from the outset of engineering and design and provide a unified security infrastructure that takes security concepts into consideration. Designers, architects, and experts have acute expectations and possible threats to record. For any step of the software development cycle, risk assessment is a basic requirement. And most significantly, it’s a must to secure the application from any modern fraudulent code intervention after software has been transferred, maintained and up-dated from time to time. The entire process of creation is skewed. Individuals may care about completely inconsequential pieces of software which are installed early in the project and then run through valuable aspects close to the end.
Activities such as quality control, normally near the final step, are streamlined and minimized [
In order to manage security issues it is important to put together enterprise, growth and security groups to identify the main intolerances and business implications induced by risk of security vulnerabilities. Since SDLC is an intake forwarding method and flaws implemented in this step will be distributed in the next implementation phase, it is essential to investigate potential risks at very initial stages. The majority of security bugs found in software and systems were triggered by deficiencies in the methodology for software development process. In order to address this issue, elements of security quality management along the software development life cycle would be described, in general the best practices for security requirement elicitation.
There are numerous security requirements engineering approaches with some advantages and disadvantages developed by different authors. It is a big challenge for the new security practitioners to select the most effective and well-organized security requirements engineering method in the software development process. In this research we implement a MCDM model based methodology to select the most effective SRE approach. Over the past couple of decades, software engineering standards have evolved to deliver high quality software applications. As per the International Standard Organization [
The assortment of an effective security requirements engineering method is a multi-criteria decision-making (MCDM) issue [
The rest of this article is arranged as follows. The different security requirements engineering approaches is presented in Section 2. In Section 3, the requisite usability assessment criteria that are needed to select effective SRE approach are added. Section 4 describes the brief implementation of the proposed hybrid model. Section 5 defines a numerical specification focused on the application of the proposed MCDM model. It also addresses the findings and their confirmation. The conclusion is ultimately stated in the Section 6.
Security specifications are technically called non-functional specifications, typically defined as software qualities, which can be transformed to suitable functional requirements. The outcome application will possibly not be tested before deployment for strength or weakness. If the security requirements are non-functional to functional requirements, these represent component of the entire requirements review process and, if problems are unavoidable, they need not be adequately defined and addressed. Simplification SRE approaches is important because it is more likely that a streamlined approach is implemented than a complicated method. It also emphasizes the significance of technical training in the SRE field for developers and design engineers. Some popular security requirements engineering approaches steps are present below in
SQUARE [ |
SREF [ |
STORE [ |
MOSRE [ |
SREP [ |
MSRA [ |
---|---|---|---|---|---|
The degree to which software is conveniently and comfortably accessible to various types of clients can be described as Usability. Numerous authors have investigated usability in different ways [
This study indicated the integral taxonomy of all principles, variables and characteristics that influence the usability of software systems, as numerous researchers have observed. This taxonomy is represented in
Factor | Sub-factor | Description |
---|---|---|
Efficiency (ST1) | User effort (ST11) | Once participants have understood about the interface, how easily can they execute the given task? |
Time-effective (ST12) | ||
Effectiveness (ST2) | Operability (ST21) | When users switch to the prototype after a time of not utilizing it, how quickly can they recover their skills? |
Scalability (ST22) | ||
Extensibility (ST23) | ||
Learnability (ST3) | User interface (ST31) | How simple is it for individuals to complete basic tasks the very first time they experience a SRE approach? |
Training (ST32) | ||
System structure (ST33) | ||
Satisfaction (ST4) | Convenience (ST41) | How good is it to utilize the SRE approach? |
Likeability (ST42) | ||
Productivity (ST5) | Useful output (ST51) | How easy for the software designers to implement SRE in the software development firms? |
Cost-effective (ST52) |
Analytical hierarchy process [
At the end of the evaluation, the findings can be severely impacted by the mentality, predilection and judgment of the experts. In responding, the concepts of fuzzy set model are used in the AHP technique to enhance the evaluation process findings. The combined effect of fuzzy set concept and MCDM techniques in real-world situations case studies has enhanced the research with the relevant structures. This evaluation is accompanied by the [
Saaty scale definition | Fuzzy triangle scale | |
---|---|---|
1 | Equally important | (1, 1, 1) |
3 | Weakly important | (2, 3, 4) |
5 | Fairly important | (4, 5, 6) |
7 | Strongly important | (6, 7, 8) |
9 | Absolutely important | (9, 9, 9) |
2 | Intermittent values between two adjacent scales | (1, 2, 3) |
4 | (3, 4, 5) | |
6 | (5, 6, 7) | |
8 | (7, 8, 9) |
The fuzzy TOPSIS approach is a powerful and efficient MCDM approach. There are many representations in the literary works of Fuzzy TOPSIS. The general concept is that two standards must be met for the chosen alternative. First, this should be the closest point from the ideal solution; as well as second, this should be the farthest width from the target solution. The conventional TOPSIS approach uses crisp values for comparative analysis [
Next, we assess the weight of the assessment element. The present study introduces Fuzzy AHP to the resolve of problem of fuzzy priority weights. In addition, authors are creating a fuzzy based decision matrix and choosing suitable semantic terms as alternatives to the parameters using
Linguistic variable | Corresponding triangular fuzzy number |
---|---|
Very poor (VP) | (0, 1, 3) |
Poor (P) | (1, 3, 5) |
Fair (F) | (3, 5, 7) |
Good (G) | (5, 7, 9) |
Very good (VG) | (7, 9, 10) |
This segment delivers a comprehensive explanation of the empirical outcomes, their clarification.
ST1 | ST2 | ST3 | ST4 | ST5 | Weights | |
---|---|---|---|---|---|---|
ST1 | 1.00000 | 2.55440 | 1.70170 | 2.42740 | 0.59930 | 0.24130 |
ST2 | 0.39150 | 1.00000 | 0.79640 | 0.97690 | 0.20730 | 0.09530 |
ST3 | 0.58760 | 1.25560 | 1.00000 | 1.05630 | 0.25320 | 0.12240 |
ST4 | 0.41200 | 1.02360 | 0.94670 | 1.00000 | 0.23570 | 0.10340 |
ST5 | 1.66860 | 4.82390 | 3.94950 | 4.24270 | 1.00000 | 0.44160 |
ST11 | ST12 | Weights | |
---|---|---|---|
ST11 | 1.00000 | 0.41110 | 0.29130 |
ST12 | 2.43250 | 1.00000 | 0.70870 |
ST21 | ST22 | ST23 | Weights | |
---|---|---|---|---|
ST21 | 1.00000 | 0.57340 | 0.70860 | 0.24160 |
ST22 | 1.74400 | 1.00000 | 0.89450 | 0.37850 |
ST23 | 1.41120 | 1.11790 | 1.00000 | 0.37990 |
ST31 | ST32 | ST33 | Weights | |
---|---|---|---|---|
ST31 | 1.00000 | 0.59790 | 0.28390 | 0.16900 |
ST32 | 1.67250 | 1.00000 | 0.89050 | 0.34850 |
ST33 | 3.52240 | 1.12300 | 1.00000 | 0.48250 |
ST41 | ST42 | Weights | |
---|---|---|---|
ST41 | 1.00000 | 0.82430 | 0.45184 |
ST42 | 1.21320 | 1.00000 | 0.54816 |
ST51 | ST52 | Weights | |
---|---|---|---|
ST51 | 1.00000 | 0.74470 | 0.42684 |
ST52 | 1.34280 | 1.00000 | 0.57316 |
Main | Local weights | Sub | Local weights | Overall weights | Ranks |
---|---|---|---|---|---|
ST1 | 0.24130 | S11 | 0.29130 | 0.07029069 | 4 |
S12 | 0.70870 | 0.17100931 | 3 | ||
ST2 | 0.09530 | S21 | 0.24160 | 0.02302448 | 11 |
S22 | 0.37850 | 0.03607105 | 10 | ||
S23 | 0.37990 | 0.03620447 | 9 | ||
ST3 | 0.12240 | S31 | 0.16900 | 0.02068560 | 12 |
S32 | 0.34850 | 0.04265640 | 8 | ||
S33 | 0.48250 | 0.05905800 | 5 | ||
ST4 | 0.10340 | S41 | 0.45184 | 0.04672026 | 7 |
S42 | 0.54816 | 0.05667974 | 6 | ||
ST5 | 0.44160 | S51 | 0.42684 | 0.18849254 | 2 |
S52 | 0.57316 | 0.25310746 | 1 |
SRE1 | SRE2 | SRE3 | SRE4 | SRE5 | SRE6 | |
---|---|---|---|---|---|---|
ST11 | 0.7300, |
4.8200, |
1.0000, |
1.4500, |
5.0000, |
2.8200, |
ST12 | 0.7300, |
4.8200, |
1.0000, |
4.4500, |
5.0000, |
2.8200, |
ST21 | 0.8200, |
4.0900, |
0.7300, |
1.6400, |
5.3600, |
2.0900, |
ST22 | 4.1800, |
3.5500, |
0.8200, |
1.1800, |
4.1800, |
2.8200, |
ST23 | 4.4500, |
3.0900, |
2.9100, |
2.8200, |
4.4500, |
3.5500, |
ST31 | 1.2000, |
2.9100, |
2.8200, |
5.3600, |
3.5500, |
3.0900, |
ST32 | 1.0000, |
2.5500, |
1.2000, |
3.5500, |
4.4500, |
2.4500, |
ST33 | 0.7300, |
4.8200, |
1.0000, |
4.4500, |
5.0000, |
2.8200, |
ST41 | 0.8200, |
4.0900, |
0.7300, |
1.6400, |
5.3600, |
2.0900, |
ST42 | 4.1800, |
3.5500, |
0.8200, |
1.1800, |
4.1800, |
2.8200, |
ST51 | 4.4500, |
3.0900, |
2.9100, |
2.8200, |
4.4500, |
3.5500, |
ST52 | 6.2700, |
3.1800, |
1.6400, |
1.4500, |
6.2700, |
3.9100, |
SRE1 | SRE2 | SRE3 | SRE4 | SRE5 | SRE6 | |
---|---|---|---|---|---|---|
ST11 | 0.4200, |
0.5900, |
0.6000, |
0.5400, |
0.4600, |
0.1800, |
ST12 | 0.2000, |
0.4600, |
0.3900, |
0.4200, |
0.5000, |
0.4600, |
ST21 | 0.5900, |
0.5400, |
0.4600, |
0.3800, |
0.4600, |
0.3500, |
ST22 | 0.4600, |
0.3900, |
0.5000, |
0.5200, |
0.5000, |
0.4600, |
ST23 | 0.5400, |
0.5200, |
0.4600, |
0.3800, |
0.5400, |
0.5000, |
ST31 | 0.3900, |
0.4600, |
0.3800, |
0.3500, |
0.4600, |
0.5000, |
ST32 | 0.4600, |
0.5400, |
0.5200, |
0.4600, |
0.5000, |
0.4600, |
ST33 | 0.4600, |
0.3900, |
0.4200, |
0.5000, |
0.4600, |
0.3500, |
ST41 | 0.5400, |
0.4600, |
0.3800, |
0.4600, |
0.3500, |
0.4600, |
ST42 | 0.3900, |
0.5000, |
0.5200, |
0.5000, |
0.4600, |
0.5000, |
ST51 | 0.5200, |
0.4600, |
0.3800, |
0.5400, |
0.5000, |
0.2000, |
ST52 | 0.4200, |
0.5000, |
0.5200, |
0.5400, |
0.5200, |
0.1800, |
SRE1 | SRE2 | SRE3 | SRE4 | SRE5 | SRE6 | |
---|---|---|---|---|---|---|
ST11 | 0.00200, |
0.00200, |
0.00200, |
0.00200, |
0.00200, |
0.00200, |
ST12 | 0.00200, |
0.00100, |
0.00200, |
0.00200, |
0.00200, |
0.00200, |
ST21 | 0.00200, |
0.00100, |
0.00200, |
0.00200, |
0.00100, |
0.00200, |
ST22 | 0.00200, |
0.00200, |
0.00200, |
0.00200, |
0.00200, |
0.00200, |
ST23 | 0.00200, |
0.00100, |
0.00200, |
0.00200, |
0.00200, |
0.00200, |
ST31 | 0.00200, |
0.00100, |
0.00200, |
0.00200, |
0.00200, |
0.00200, |
ST32 | 0.00200, |
0.00500, |
0.00200, |
0.00200, |
0.00200, |
0.00200, |
ST33 | 0.00100, |
0.00200, |
0.00200, |
0.00200, |
0.00200, |
0.00200, |
ST41 | 0.00100, |
0.00100, |
0.00200, |
0.00200, |
0.00200, |
0.00100, |
ST42 | 0.00100, |
0.00100, |
0.00100, |
0.00200, |
0.00200, |
0.00200, |
ST51 | 0.00200, |
0.00000, |
0.00200, |
0.00200, |
0.00200, |
0.00000, |
ST52 | 0.00100, |
0.00000, |
0.00200, |
0.00200, |
0.00100, |
0.00000, |
Alternatives | Gap degree ( |
Satisfaction degree ( |
||
---|---|---|---|---|
SRE1 | 0.4554274 | 0.0557645 | 0.56645784 | 0.47548754 |
SRE2 | 0.0467548 | 0.05546754 | 0.61346574 | 0.38645784 |
SRE3 | 0.0645124 | 0.03754677 | 0.36794574 | 0.65467548 |
SRE4 | 0.0546754 | 0.04649754 | 0.58455124 | 0.44575487 |
SRE5 | 0.0113454 | 0.02346517 | 0.56457944 | 0.46457984 |
SRE6 | 0.04675487 | 0.04454612 | 0.62346457 | 0.38496457 |
With growing usage of the Internet, there is an elevated incidence of malicious software such as viruses impacting a business communications system. The software virus is a component of computer programs that is introduced into another programme and is inactive until it is activated by an unaware person. This cause can be as easy as accessing a file or uploading a document from the internet. With the complication and speed of the software development lifecycle, software engineering is under tremendous pressure to produce market specifications without paying enough attention to the security vulnerabilities that the application might have experienced. With these kinds of security issues, the company would have a problem providing the consistency and availability of the company needed by its clients. However some software firms use security requirements engineering approach during software development process, but even the most advanced SRE approach cannot keep up with the ever-increasing number of malware and malicious programmes out there. This research presents the usability evaluation of different security requirements engineering approaches.
We contrasted and addressed different categories of security requirements engineering (SRE) approaches and procedures. Our viewpoint of assessment and analysis uses some of the usability principles set out in previous works contained in the research. One purpose of such parameters is to evaluate the ability of the process that can provide an environment for its system to develop job in a timely, efficient and productive manner while experiencing practice. Another goal is to explore which SRE approaches can be used to analyses the degree of security of the software against attacks. Our research then demonstrates and prioritizes the SRE approaches founded on the security expert’s viewpoint. We conclude that STORE methodology is the very consistent and usable SRE approaches with a threat-driven approach since it uses an effective and well-organized way of eliciting security requirements in the software development procedure. The findings of this research would assist and provide future directions to the security requirements engineers and security experts. This study helps them in selecting the most effective security requirements engineering approach.
This research work was funded by Institutional Fund Projects under Grant No. (IFPHI-269-611-2020). Therefore, authors gratefully acknowledge technical and financial support from the Ministry of Education and King Abdulaziz University, DSR, Jeddah, Saudi Arabia.