Security Requirements Engineering: A Review and Analysis

Abstract

Security is crucial, especially as software systems become increasingly complex. Both practitioners and researchers advocate for the early integration of security requirements (SR) into the Software Development Life Cycle (SDLC). However, ensuring the validation and assurance of security requirements is still a major challenge in developing secure systems. To investigate this issue, a two-phase study was carried out. First phase: a literature review was conducted on 45 relevant studies related to Security Requirements Engineering (SRE) and Security Requirements Assurance (SRA). Nine SRE techniques were examined across multiple parameters, including major categories, requirements engineering stages, project scale, and the integration of standards involving 17 distinct activities. Second phase: An empirical survey of 58 industry professionals revealed a clear disparity between the understanding of Security Requirements Engineering (SRE) and the implementation of Security Requirements Assurance (SRA). While statistical analyses (ANOVA, regression, correlation, Kruskal–Wallis) confirmed a moderate grasp of SRE practices, SRA remains poorly understood and underapplied. Unlike prior studies focused on isolated models, this research combines practical insights with comparative analysis, highlighting the systemic neglect of SRA in current practices. The findings indicate the need for stronger security assurance in early development phases, offering targeted, data-driven recommendations for bridging this gap.

1. Introduction

Security, privacy, and safety have become essential in modern software development [1]. As cyber threats grow in scale and complexity, they pose serious risks to sensitive data and system reliability [2,3]. Software must remain functional even under attack, prompting increased emphasis on incorporating Security Requirements (SR) early in the Software Development Life Cycle (SDLC) [4].

Critical systems such as IoT, smart grids, and cyber–physical platforms are particularly vulnerable to threats like data leakage and unauthorized access [5]. Early integration strengthens resilience and reduces costly rework [6].

Security is still often treated as a Non-Functional Requirement (NFR), addressed late in development [6]. This delay raises the risk of undetected vulnerabilities. The Requirements Engineering (RE) phase is ideal for embedding security, aligning it with stakeholder needs and reducing risk exposure [6]. Although AI and machine learning offer potential for automating SR identification [7,8]. However, challenges persist in eliciting clear security requirements due to gaps between stakeholder knowledge and technical language [9].

Recent cybersecurity breaches have exposed the costly consequences of weak security measures. In 23 October 2023 and Me reported a breach affecting 5.5 million users and 1.4 million linked profiles, resulting from credential stuffing attacks that exploited reused login credentials. The attack revealed major gaps in user authentication specifically the absence of multi-factor authentication, password reuse detection, and enforced complexity rules [10]. Similarly, the 2022 LastPass breach compromised sensitive customer data after attackers exploited software vulnerability on a DevSecOps engineer’s system. This incident highlighted failures in endpoint protection, device access control, and secure configuration [11], areas that should have been addressed during the requirements engineering phase. The financial impact of such lapses is severe. IBM’s 2023 report states the average cost of a data breach has reached $4.45 million globally. Meanwhile, Statista (2023) projects global cybersecurity spending to exceed $188 billion in 2024. These figures highlight a growing paradox: despite soaring investments, systems remain vulnerable due to overlooked or poorly defined security requirements. Addressing security proactively at the requirements stage is essential to prevent such high-cost consequences and protect critical user data [12].

While numerous methodologies such as SQUARE, CLASP, Secure Tropos, and SREP have been introduced to guide security requirements elicitation and analysis [13], they often lack standardization, comprehensive coverage, or practical integration guidance. Many focus predominantly on the identification and specification of security requirements but provide limited support for validating or assuring them during implementation. Moreover, requirement engineers frequently face challenges in selecting the most suitable SRE technique due to the absence of comparative, practical evaluations [14]. The gap between theoretical frameworks and practical implementation often leads to insufficient adoption of security practices, misalignment with project objectives, and weak assurance of security requirements. As a result, software systems remain vulnerable, and development teams bear the burden of costly rework, delayed delivery, and diminished trust [15].

To address this critical gap, the current study adopts a dual-phase approach combining a comprehensive literature review with empirical validation. The first phase presents a structured comparison of nine widely recognized SRE methodologies across 15 security-focused parameters, revealing their strengths, limitations, and suitability for different project contexts. The second phase of this study surveyed 58 professionals from diverse industries to evaluate their understanding of Requirements Engineering (RE), Security Requirements Engineering (SRE), and Security Requirements Assurance (SRA), a domain still largely overlooked in existing research. Statistical methods, including ANOVA, regression, correlation, and the Kruskal–Wallis test, were employed to identify patterns and gaps in industry practices. Unlike prior work focused on narrow frameworks or specific domains, this study integrates theoretical analysis with empirical data to provide a grounded, practice-oriented perspective. By addressing both SRE and SRA, the study reveals critical assurance deficiencies and proposes a comparative framework to guide practical implementation.

The practical objective of this study is to evaluate the current state of SRE and SRA using completeness and coverage of requirement activities as the quality indicator. Completeness, defined as the extent to which elicitation, analysis, validation, and assurance are explicitly supported, provides a benchmark for assessing the effectiveness of methods and practices examined in this study. The main contributions are outlined as follows.

• This study adopts a two-phase methodology that bridges the gap between theoretical research and industry application. The first phase conducts a systematic literature review of 45 studies, while the second phase involves an empirical survey of 58 professionals from diverse industrial domains. This design allows for a holistic exploration of both academic frameworks and real-world challenges in SRE and SRA.
• Nine established SRE approaches including SQUARE, Secure Tropos, SREP, and CLASP are critically compared across 17 Activities such as scalability, flexibility, risk analysis, validation, and integration of standards. This structured evaluation not only identifies the strengths and limitations of each method but also guides practitioners in selecting context-appropriate techniques for secure software development.
• Unlike prior studies that largely focus on the elicitation and analysis of security requirements, this work highlights a critical and underexplored component Security Requirements Assurance. The findings reveal that most existing approaches lack explicit mechanisms to verify and validate security requirements during and after implementation, which poses a serious risk to system reliability.
• Statistical analysis of the survey responses using ANOVA, correlation, regression, and the Kruskal–Wallis test uncovers significant knowledge disparities among professionals. The results indicate that while awareness of SRE and RE is relatively strong, understanding of SRA is notably weak. This empirical insight substantiates the theoretical gap identified in the literature and emphasizes the need for targeted assurance training and framework development.
• By combining analytical comparisons with industry validation, the study offers a practical decision-making guide for selecting suitable SRE methods and integrating assurance activities throughout the SDLC. This contribution is especially valuable for requirement engineers, security analysts, and project managers seeking to implement scalable and verifiable security practices

The paper is organized as follows: Section 2 presents literature and related work on SRE and SRA. Section 3 explains the research methodology. Section 4 presents the discussion; the findings and their implications are addressed in Section 5. Section 6 wrap up the paper as conclusion.

2. Literature Review

This literature review critically analyzes the evolution, methodologies, and gaps within Security Requirements Engineering (SRE), as well as the emerging emphasis on Security Requirements Assurance (SRA). To provide a structured discussion, the review is divided into four key thematic areas: (i) the development and comparative strengths of traditional SRE methodologies; (ii) the relatively underexplored domain of SRA and its integration challenges; and (iii) the rise of automation and artificial intelligence in modernizing security practices. This structured approach ensures a logical flow, linking theoretical advances to industry needs and establishing a clear foundation for the empirical study conducted in the second phase of this research.

2.1. Security Requirement Engineering

Security Requirements Engineering (SRE) is a critical discipline that focuses on identifying, analyzing, and specifying security needs throughout the software development lifecycle. A variety of methodologies and frameworks have been proposed to ensure that security is systematically integrated into system design from the early stages. This study focuses on nine widely recognized SRE approaches in

Table 1. Sre Methods and Rationale.

Method/Approach	Objective and Rationale	Targeted re Stage	Purpose
SQUARE	Integrate security requirements early in SDLC using a 9-step adaptable method for eliciting, categorizing, and prioritizing security needs.	Elicitation, Categorization, Prioritization	To systematically define and prioritize security requirements from the beginning of the SDLC.
Secure Tropos	Use agent-oriented models to define security throughout SDLC, focusing on goals, trust, and secure dependencies.	All SDLC Phases (Focus on Early Requirements)	To embed security into the system by modelling goals, actors, and dependencies.
Abuse Frames	Represent attacker anti-requirements using modified problem frames to elicit security threats like DoS, and interception.	Elicitation (Threat Modelling)	To identify and analyze potential threats and vulnerabilities from an attacker’s perspective.
SREP	Risk-driven, iterative method using Common Criteria and reusable repository to define and prioritize security requirements.	Elicitation, Risk Assessment, Validation	To iteratively derive risk-based, asset-driven security requirements using reusable components.
Misuse Cases	Model hostile behaviors in UML with templates and relationships to depict threats and improve security requirement reuse.	Elicitation (Threat Modelling)	To capture and reuse attack scenarios and model malicious behaviors in system analysis.
UMLsec	Extend UML diagrams with stereotypes, tags, and constraints for formal security requirement verification and system design.	Design, Verification	To enhance UML models with formalized security specifications and enable automated verification.
MORSE	An iterative approach combining SQUARE and misuse cases to elicit, trace, and analyze security requirements in web systems.	Elicitation, Analysis, Traceability	To offer a structured elicitation and analysis approach for security-critical applications.
SecureUML	Model role-based access control policies in UML using OCL for formal authorization in secure distributed system design.	Design (Authorization Modelling)	To specify access control policies formally within UML design for secure systems.
CLASP	Lightweight, role-based process integrating best practices across SDLC to manage and validate security requirements.	Elicitation, Validation, Management	To guide secure software development through structured activities and best practices.

SQUARE [1], Secure Tropos [16,17], Abuse Frames [1], SREP [16,17], Misuse Cases [1], UMLsec [18], MORSE [1], SecureUML [1], STORE [19], and CLASP [17]. This provides a concise comparison of prominent SRE approaches, highlighting their objectives, targeted RE stages, and specific purposes. It serves as a quick reference for researchers and practitioners to select suitable techniques based on their project needs and security focus.

2.2. Security Requirement Assurance

Security assurance verifies that the system meets requirements and can withstand threats and failures. [20]. Current security assurance tools and methodologies may overlook escalating issues due to insufficient requirement specifications, static approaches, and poor development processes. Traditional security assurance approaches are limited by their static nature, inadequate security requirement specifications, and design [21]. While current methodologies excel at identifying anomalies, they struggle to measure their impact and potential risks. Software security assurance measures the beneficial effects of security requirement fulfillment on the security assurance score using several metrics. Understanding the impact will enable stakeholders to maximize positive effects in achieving security goals [22]. There are several security requirement assurance methods exist such as Common Criteria (CC), security metrics [21], security assurance cases (SAC) [23], Threat modelling [24], Formal methods, etc. However, these approaches are often applied post-development, making them reactive rather than proactive. Furthermore, their integration into standard SRE methodologies remain inconsistent, leading to gaps in security validation at the requirement engineering stage. This gap underscores the need for methodologies that bridge the divide between security requirement elicitation and security assurance, ensuring that security measures are not just identified but also validated and enforced.

Critical analysis of early-phase integration barriers. Although methods such as the Common Criteria (CC) and Security Assurance Cases (SACs) offer structured approaches to demonstrating confidence in security properties, evidence from the 16 assurance-focused studies reviewed shows that their uptake during early requirements activities is limited. Both frameworks are predominantly certification-driven and applied late in the development lifecycle, creating a misalignment with elicitation and analysis tasks. Their reliance on extensive documentation and evidence generation is also impractical when requirements are still evolving. Furthermore, the absence of requirement-level assurance metrics constrains the ability to formulate verifiable security objectives at an early stage. Traceability between requirements, threats, and assurance evidence remains weak, while limited tool support exacerbates the cost and effort required to construct and maintain assurance artifacts. These challenges are particularly acute for small and medium-sized organizations, where formal assurance processes are often viewed as prohibitively resource-intensive. Finally, unclear ownership across security, requirements, and quality teams results in fragmented accountability. Together, these factors critically explain why assurance practices, despite their importance, remain poorly integrated into early requirements engineering.

2.3. Automation and AI in Security Requirements Engineering

With the increasing complexity of security threats, automation and artificial intelligence (AI) are emerging as promising tools for enhancing security requirements engineering. Machine learning and deep learning models have been explored for automated classification of security requirements and anomaly detection tasks. Recent studies have also proposed AI-driven tools for recommending security design patterns [25] and for completeness verification of natural language security requirements using AI-based techniques [26]. However, these approaches face challenges such as high computational requirements, sensitivity to noisy data, and the need for domain-specific adaptation and robust datasets. While AI has the potential to revolutionize security requirements engineering, its application remains largely experimental. There is a pressing need for practical implementations that integrate AI techniques within existing SRE frameworks to facilitate automated security requirement elicitation, validation, and assurance.

2.4. Related Reviews and Gap Analysis

Table 2. Extensive Literature on Security Requirement Engineering.

Ref.	Key Focus	Methodologies Used	Validation Approach	Findings	Practical Applicability	Limitation
[1]	Anwar Mohammad et al., 2019, An SLR evaluated 20 SRE approaches, comparing threat modelling and risk analysis.	A comparative synthesis of methodologies.	Theoretical evaluation, no empirical validation.	Identified the most-used SRE techniques and their attributes	Useful for understanding SRE methodologies but lacks implementation insights	Some approaches included design aspects, despite focusing solely on requirement engineering.
[2]	Hnaini, Mazo et al., (2024)/E-SCORE streamlines security requirements in engineering, establishing criteria through article evaluation.	Tool-supported SRE through E-SCORE framework	Comparative evaluation using defined criteria	Establishes clear criteria for evaluating SRE completeness	Can formalize RE processes in complex environments	Challenges include a limited understanding of security criteria and low adoption.
[4]	Niazi et al., 2020, The study developed RESMM with 79 practices from SLR findings.	Literature-driven framework + case studies	Applied RESMM on two real-world projects	Established a maturity framework for assessing security requirements and engineering readiness	Can help organizations assess security maturity levels	Requires broader validation across diverse industries and complex software development settings.
[19]	Ansari et al., (2022)/STORE methodology enhances ERP security requirements, outperforming SQUARE in effectiveness.	STORE methodology for ERP security RE	Compared with SQUARE in ERP projects	Outperforms traditional SRE in ERP-specific needs	Good for enterprise-level applications and standards compliance	STORE needs validation on large-scale projects and a supporting tool.
[26]	Luitel et al., 2024, Automated completeness checking for natural language requirements	AI-driven requirement completeness verification	Masked prediction and noise-tolerance testing	Improves quality assurance of natural language requirements	Suitable for documentation-heavy engineering projects	Prone to noise in masked prediction and limited domain scope.
[27]	Casillo et al., 2025, Evaluation of domain-independent security requirement identification using NLP and machine learning models.	BERT-based NLP models for security requirement extraction	Computational evaluation of NLP performance	Achieved high accuracy in classifying security-related requirements	Supports automation in requirement engineering tasks	BERT-based models show promise but require extensive computational resources; domain-specific adaptation remains a challenge.
[28]	Lins et al., 2024, A comprehensive review of security requirements engineering for IoT-based systems.	SRE review for IoT systems	Systematic literature synthesis	Highlights IoT-specific RE gaps like scalability and heterogeneity	Valuable for IoT-focused development teams	Struggles with heterogeneity and scalability of IoT security requirements.
[29]	Bhole et al., 2024, The transition from manual to semi-automated security requirements engineering for Industry 4.0.	Compliance-focused hybrid SRE model for Industry 4.0	Case studies in industrial environments	Improved security process automation and compliance	Highly applicable to industrial automation and manufacturing	Difficult integration in generic software settings; lacks domain-flexibility
[30]	Aviv et al., 2024, Challenges and methodologies in security requirements engineering for Web3 systems.	Conceptual modeling for SRE in Web3 systems	Literature-driven framework	Captures security challenges in decentralized tech ecosystems	Raises awareness of Web3-specific security gaps	Limited by lack of case studies; no practical framework tested
[31]	Guntur Budi Herwanto, Fajar J Ekaputra, et al., 2024, Systematic literature review on holistic privacy requirements engineering.	A systematic review of privacy focused RE frameworks	Literature evaluation	Identifies inconsistencies in privacy requirement handling	Useful for privacy-sensitive sectors like healthcare and fintech	The absence of a unified framework requires standardization for broader applicability.
[32]	Hassan et al., 2025, Hybrid deep learning model for security requirements classification.	Deep learning-based classification model for SRE	Dataset-driven performance benchmarking	Effective in automating requirement categorization	Supports efficiency in early security requirement analysis	Dependence on dataset quality; generalizability of the model needs further testing.
[33]	Span et al., 2024, The research surveys provide Standards-integrated SRE with MBSE and systems theory	Systems theory & MBSE integration into SRE	Comparative framework analysis	Suggests standard-driven security integration strategies	Applicable in model-based development and systems engineering	Scarcity of tools and resource requirements hinder industrial use
[34]	Pargaonkar, 2023, The study explores RE-QA synergy, focusing on traceability and communication.	Empirical study on RE and QA alignment	Interviews and traceability analysis	Identifies gaps in requirement traceability and QA workflows	Helps QA and RE teams coordinate effectively	Requires consistent updates; fragile in agile settings
[35]	Ardi et al., 2023, The study evaluates upskilling engineers to reduce vulnerabilities and assess training.	Training assessment for secure software engineering	Pre/post-training evaluation	Demonstrates improved security awareness post-training	Enhances human capability in security-sensitive roles	Challenges include training adaptation and workforce distribution; further verification is needed.
[36]	Olukoya, (2022)/Compared NDPR with existing standards, showing improvements in completeness and consistency.	NDPR compliance assessment with global standards	Policy-based comparative evaluation	Demonstrates stronger completeness and consistency	Aids compliance alignment for privacy and security standards	Lack of uniform global standards; needs better modelling, automation, and formalization.
Current study	Comparative analysis of SRE methods + empirical survey on security knowledge	Mixed method: Literature review + practitioner survey + statistical analysis (ANOVA, regression, correlation)	Empirical validation with 58 professionals from diverse industries	Identifies gaps in security assurance knowledge, emphasizing the need for SRA integration into SDLC	Broad industry applicability; informed by real-world practices	SRA is evaluated via awareness levels, not by actual system deployment; lacks real-world implementation validation

explains the analyses of Security Requirements Engineering (SRE) approaches addressed in the literature. SRE has evolved into a multidisciplinary domain where traditional, manual techniques operate alongside emerging automated methods driven by advanced technologies. Early studies mainly relied on conceptual frameworks, systematic reviews, or domain specific case analyses, whereas recent developments have incorporated machine learning (ML) and deep learning (DL) to automate the elicitation and classification of security requirements. Despite varied methodologies, a shared objective remains to enhance the accuracy, efficiency, and assurance of security requirements across the software development lifecycle. A comparative analysis of these contributions, whether empirical, theoretical, or algorithmic, reveals important insights into the maturity of SRE research, existing gaps, and future directions. This study critically evaluates both classical and contemporary approaches across categories such as validation techniques, practical applicability, and methodological limitations, highlighting achievements to date and areas requiring further advancement.

Although the body of research in Security Requirements Engineering (SRE) continues to grow, several critical gaps persist. Many prior studies have focused on developing theoretical frameworks without empirical validation. For instance, the systematic literature review by Anwar Mohammad et al. [1] offered a comparative overview of SRE methods but lacked practical assessment. Similarly, works by Sabau et al. [25] and Aviv et al. [30] proposed conceptual models for integrating security into design but remained untested in real-world settings. Empirical efforts by Niazi et al. [4] and Bhole et al. [29], examined model effectiveness within specific contexts, such as organizational maturity and Industry 4.0, yet their findings were domain-limited and not easily generalized. AI-based studies, such as those by Casillo et al. [27] introduced automation in requirements classification but encountered limitations related to data dependency and limited applicability across domains. Domain-specific research in IoT systems [28], privacy engineering [31], or standards-based modelling [33] has revealed localized challenges, but lacks a holistic view of how security requirements are managed across industries. This study addresses these limitations by adopting a comprehensive, practice-oriented approach. It presents a comparative analysis of nine established SRE methodologies, grounded in empirical feedback from 58 professionals across multiple sectors. Moreover, it uniquely emphasizes Security Requirements Assurance (SRA), a critical yet often overlooked aspect of secure software development.

3. Research Methodology and Study Design

This study adopts a structured two-phase methodology to examine the current state of Security Requirements Engineering (SRE) and Security Requirements Assurance (SRA) in software development. The first phase involves a systematic literature review to evaluate existing frameworks and practices. The second phase complements this by conducting an empirical survey to capture industry perspectives and practical challenges. By integrating theoretical analysis with real-world insights, the study provides a comprehensive understanding of both the conceptual foundations and implementation barriers in embedding security within requirements engineering.

A quantitative survey design was deliberately selected to establish a baseline understanding of knowledge gaps in SRE and SRA across a broad sample of professionals. This exploratory baseline can inform and guide future qualitative studies, such as interviews or thematic analyses, which may capture richer insights into practitioner experiences and contextual factors.

Unlike prior studies that focused solely on literature reviews or practitioner surveys, our two-stage methodology deliberately combines both. Phase 1 assesses methodological completeness through a structured analysis of SRE methods across 15 activities. Phase 2 validates these findings with a practitioner survey, highlighting gaps in awareness and implementation. This comparative design enables us to evaluate what existing methods claim to support against what practitioners apply, providing a stronger foundation for identifying assurance gaps.

3.1. Phase 1: Literature Review Process

Study Selection: A step-by-step filtering process was done using the PRISMA (Preferred Reporting Items for Systematic Reviews and Meta-Analyses) guidelines, as shown in Figure 1. The first search found 1658 papers from trusted sources such as Google Scholar, ScienceDirect, IEEE Xplore, Scopus, and the ACM Digital Library. After taking out 62 repeated papers, 1596 were kept for review. By checking the abstracts, 430 papers were removed for being unrelated. Another 87 papers were later removed after reviewing their methods and how they handled real-world data. Full-text evaluation of the remaining 1079 studies led to the exclusion of 809 papers that did not meet the established criteria. Ultimately, 45 studies were included in the final review, comprising 29 focused on Security Requirements Engineering (SRE) and 16 addressing Security Requirements Assurance (SRA).

Inclusion and Exclusion Criteria: The comparative analysis of literature used in this study is based on 17 well-defined attributes covering security requirement perspectives broadly is illustrated in

Table 3. Inclusion and Exclusion Criteria for search Screening.

Criteria	Inclusion Criteria	Exclusion Criteria
Publication Year	2009–2025 (to capture foundational and contemporary developments in SRE and SRA)	Studies published before 2009 or after 2025
Article Type	Peer-reviewed journal papers, conference proceedings, or scholarly book chapters	Editorials, white papers, tutorials, blogs, newsletters, and industry reports (grey literature)
Language	English	Non-English publications
Availability	Full-text studies available (≥5 pages)	Abstract-only studies or short notes (<5 pages)
Relevance	Explicitly addresses Security Requirements Engineering (SRE), Security Requirements Assurance (SRA), or related methodologies	Studies focusing only on general cybersecurity or unrelated software engineering topics
Publication Stage	Final, published versions	Drafts, in-press, or unpublished works
Methodological Rigor	Provides empirical evidence, case studies, systematic reviews, or comparative analyses	Conceptual-only studies without validation, unclear methods, insufficient sample sizes, or no statistical validation
Duplication	Most recent and comprehensive version retained	Duplicate or redundant studies
Grey Literature	–	Grey literature excluded (e.g., editorials, white papers, unreviewed preprints such as arXiv, industry reports)

. The inclusion criteria required that selected studies (i) be published in English be-tween 2009 and 2025 to ensure coverage of both foundational and contemporary ad-vancements in SRE, (ii) explicitly address Security Requirements Engineering, security re-quirement assurance, or related methodologies to maintain topic specificity, (iii) propose, evaluate, or compare structured processes, frameworks, or techniques for security re-quirement elicitation, analysis, or assurance, (iv) be published in peer-reviewed journals or conferences to ensure academic credibility, and (v) provide empirical evidence or method-ological insights through case studies, comparative analyses, experimental validation, or systematic literature reviews.

The exclusion criteria eliminated studies that lacked empirical validation or method-ological contributions, ensuring the robustness of the dataset. Specifically, studies were excluded if:

(i)

Studies only provided conceptual discussions or theoretical opinions without practical application.

(ii)

Grey literature—including editorials, white papers, unreviewed preprints, and industry reports lacking standardized peer review—was systematically excluded by restricting searches to peer-reviewed databases, filtering publication type metadata, and applying PRISMA guidelines. Studies failing to meet peer-review standards or methodological rigor were removed, while some preprints and industry cases were cited in the Introduction for contextual illustration only, not as part of the SLR dataset.

(iii)

Studies did not directly address security requirement engineering but focused on broader cybersecurity or unrelated software security aspects.

(iv)

Duplicate studies, where only the latest and most comprehensive version was retained, and.

(v)

Lacked methodological rigor, including those with insufficient sample sizes, unclear research methodologies, or missing statistical validation. The application of these criteria ensured that the final selection of studies was methodologically sound and contributed effectively to the research objectives.

3.2. Phase 2—Practical Implementation via Empirical Survey

Questionnaire Validation: The questionnaire validation process followed a two-stage validation process to ensure the instrument’s clarity, reliability, and effectiveness in capturing meaningful data. The validation involved expert review and a pilot study validation to assess its content validity, construct validity, and internal consistency.

Expert Review for Content Validity: The questionnaire was initially reviewed by three domain experts specializing in software security, requirements engineering, and cybersecurity. The evaluation focused on (i) relevance, ensuring each question aligned with the research objectives, (ii) clarity, assessing whether questions were understandable and free of ambiguity, (iii) comprehensiveness, ensuring complete coverage of security requirement engineering concepts, and (iv) bias identification, eliminating any leading or suggestive questions. Expert feedback led to refining the phrasing of several questions, enhancing the specificity of security assurance-related queries, and removing redundant items.

Pilot Study for Construct Validity: A pilot study with 15 software engineers and security analysts was conducted to test the questionnaire’s effectiveness. Participants evaluated (i) question understanding, (ii) logical sequencing, and (iii) time efficiency in completing the survey. The pilot study revealed the need to reduce the survey length to prevent participant fatigue, merge overlapping Likert-scale questions, and refine ambiguous technical terms. The revised questionnaire exhibited improved readability, reduced redundancy, and better logical structuring.

Participant Expertise: More than 100 invitations were distributed, of which 58 participants completed the survey, resulting in a moderate response rate. This aligns with typical participation levels in industry-focused security studies, where survey fatigue and organizational policies often limit full participation—especially in high-security environments. The final sample included professionals across diverse roles such as software engineers, developers, system analysts, QA testers, and product managers. All participants had at least two years of professional experience, with several having over a decade in the field. The survey specifically targeted individuals involved in software development and security requirements engineering to ensure informed and practice-based responses. Participants were selected from a range of sectors, including IT, banking, healthcare, oil and gas, telecom, and academia, as shown in

Table 4. Participants Demographics.

Industry Sector	No. of Respondents	Percentage (%)
IT and Software Development	23	39.7%
Finance and Banking	10	17.2%
Healthcare	8	13.8%
Oil and Gas	7	12.1%
Telecom	5	8.6%
Academia and Research	5	8.6%
Position	Frequency	%
Software Engineer	4	10.2
Business/System Analyst	5	12.8
Developer (ML, Android, IOS, Flutter)	6	15.3
SOC Analyst	9	23
Product Manager	3	7.6
Test Engineer/Quality Control	2	5.1
Others	10	25.6

. This diversity supports the reliability and generalizability of the findings, providing insights grounded in both academic and industrial contexts.

3.3. Statistical Approach for Data Validation

Security Requirements Engineering (SRE) traditionally emphasizes qualitative evaluation and synthesis; the current study adopts a mixed-method approach. The first phase provides a comprehensive review and comparative analysis of existing SRE methodologies, while the second phase incorporates a quantitative survey of industry professionals. In the second phase, several statistical methods were used to analyze and validate the results from the empirical survey. These methods were not intended to build mathematical models but to help interpret the views of professionals on SRE and Security Requirements Assurance (SRA). Descriptive statistics such as mean and standard deviation were used to summarize the participants’ awareness of security practices. To examine differences in understanding across SRE, SRA, and general Requirements Engineering (RE), tests like the t-test and ANOVA were applied. Regression analysis was used to check how knowledge of security related to its use in practice. Since some data did not follow normal distribution, the Kruskal–Wallis test was also used to ensure more accurate results. All findings were presented with p-values, confidence intervals, and effect sizes to support clarity and reliability. Lastly, study limitations, including the small sample size and possible bias in responses, were recognized to provide a clearer picture and guide future studies.

3.3.1. Descriptive Analysis of Security Knowledge

Standard Deviation: Standard deviation is a measure of the amount of variation or dispersion in a set of values. A low standard deviation indicates that the values tend to be close to the mean of the set, while a high standard deviation indicates that the values are spread out over a wider range.

$$\mathsf{\sigma }=\sqrt{{\displaystyle \frac{\sum _{\mathbf{i}=1}^{\mathbf{N}}{\left({\mathbf{x}}_{\mathbf{i}}-\mathsf{\mu }\right)}^2}{\mathbf{N}}}}$$

(1)

σ: population standard deviation

${\mathbf{x}}_{\mathbf{i}}$: each value in the dataset

$\mathsf{\mu }$: population mean

N: number of values in the population

Correlation: Correlation measures the strength and direction of the linear relationship between two variables. The correlation coefficient r ranges from −1 to 1.

$$\mathbf{r}={\displaystyle \frac{\sum \left({\mathbf{x}}_{\mathbf{i}}-\overline{\mathbf{x}}\right)\left({\mathbf{y}}_{\mathbf{i}}-\overline{\mathbf{y}}\right)}{\sqrt{{\sum \left({\mathbf{x}}_{\mathbf{i}}-\overline{\mathbf{x}}\right)}^2{\sum \left({\mathbf{y}}_{\mathbf{i}}-\overline{\mathbf{y}}\right)}^2}}}$$

(2)

x_i and y_i = individual data points.

$\overline{\mathrm{x}}$ and $\overline{\mathrm{y}}$ = means of the x and y datasets respectively.

3.3.2. Inferential Statistical Analysis

T-Test: To compare security knowledge across SRE, SRA, and RE, t-tests and ANOVA were applied to assess statistically significant differences. The t-test evaluates pairwise comparisons, while ANOVA examines differences across all three domains.

$$\mathrm{t}={\displaystyle \frac{{\overline{\mathbf{x}}}_1-{\overline{\mathbf{x}}}_2}{\sqrt{\frac{{\mathrm{s}}_1^2}{{\mathrm{n}}_1}+\frac{{\mathrm{s}}_2^2}{{\mathrm{n}}_2}}}}$$

(3)

${\overline{\mathbf{x}}}_1,{\overline{\mathbf{x}}}_2$ are means of two groups

${\mathbf{s}}_1^2,{\mathbf{s}}_2^2$ are variances

${\mathbf{n}}_{1,}{\mathbf{n}}_2$ are sample sizes

Effect sizes (Cohen’s d): For t-tests, effect size was calculated using the formula:

$$\mathrm{d} = {\displaystyle \frac{\mathrm{t}}{\sqrt{\mathrm{n}}}}$$

(4)

n = (sample size).

Interpretation: 0.2 small, 0.5 medium, 0.8 large.

Confidence intervals (95%): For each Cohen’s d, a 95% CI was computed using ±1.96 × Standard error (SE). 95% is used because it is the standard in scientific reporting, aligning with α = 0.05 significance testing. It conveys the range of plausible values for the effect size with high confidence, while keeping results comparable to reported p-values.

$${\mathrm{S}\mathrm{E}}_{\mathrm{d}}=\sqrt{{\displaystyle \frac{1}{\mathrm{n}}}+{\displaystyle \frac{{\mathrm{d}}^2}{2(\mathrm{n}-1)}}}$$

(5)

ANOVA:

F = Between Group Variances/Within Group Variance

(6)

F-statistics determine whether at least one group differs significantly.

For the one-way ANOVA, η² was calculated:

$${\eta }^2={\displaystyle \frac{{SS}_{between}}{{SS}_{between}+ {SS}_{within}}}$$

(7)

(η²) quantifies how much of the total variance in the data is attributable to group differences rather than random variation.

3.3.3. Variance Analysis

The Kruskal–Wallis test was employed to analyze distributional differences in security knowledge across SRE, SRA, and RE, providing a non-parametric statistical approach to assess whether significant variations exist among these groups. This test is particularly suitable for comparing multiple independent groups when the data does not follow a normal distribution.

$$\mathrm{H}={\displaystyle \frac{12}{\mathrm{N}\left(\mathrm{N}+1\right)}}\sum {\displaystyle \frac{{\mathrm{R}}_{\mathrm{i}}^2}{{\mathrm{n}}_{\mathrm{i}}}}-3\left(\mathrm{N}=1\right)$$

(8)

H is the test statistic,

${\mathbf{R}}_{\mathbf{i}}$ represents the sum of ranks for each group,

${\mathbf{n}}_{\mathbf{i}}$ is the number of observations in each group.

3.3.4. Predictive Modeling (Regression Analysis)

Regression analysis is a statistical process for estimating the relationships among variables. Linear regression is used to model the relationship between a dependent variable y and one or more independent variables x.

y = β0 + β1x + ϵ

(9)

y = dependent variable

x = independent variable

β0 = y-intercept (the value of y when =0 x = 0)

β1 = slope of the regression line (the change in y for a one-unit change in x)

ϵ = error term (the difference between the observed value and the value predicted by the model).

3.4. Research Questions

A literature review was conducted to search for initiatives for security requirement engineering and security requirements assurance. According to the objective of the study, and after gathering the required information from the digital libraries, we formulated research questions and surveyed in the second phase to gauge the knowledge of IT professionals in Security Requirements Engineering as shown in

Table 5. Research Question and Way Forward.

Research Questions	Purpose/Focus	Study Phase Addressed
What SRE methodologies have scholars proposed for identifying the security requirements in literature?	Compares existing SRE methods across elicitation, analysis, validation, and management activities.	Phase 1—Systematic Literature Review
2. What techniques of requirement engineering are adopted in literature for security requirements and prominently employed by established SRE methodologies?	Identifies concrete practices (e.g., threat modelling, risk assessment) used in SRE approaches and their practical challenges.	Phase 1—Systematic Literature Review
3. To what degree do SRE methodologies explicitly or implicitly assure the fulfilment of security requirements, and what are the common challenges in RE?	Evaluates the presence (or absence) of assurance within SRE frameworks and examines its reflection in industry knowledge levels	Phase 1—Literature + Phase 2—Survey

.

3.5. Data Sources and Search Approach

This study is based on a literature review and survey, search strategy for this study generally suggested the use and identification of population and intervention. While searching for keywords in search engines, identified some of the relevant keywords mentioned below in

Table 6. Data Source and Search Strategy.

Data Source and Search Approach
Population	Security requirement Engineering, assurance, or security requirements.
Intervention	Current methodologies for security requirements engineering and security requirement assurance.
Search String	“Security” AND “requirement” AND “engineering” OR “approaches” OR “techniques” OR “methods” OR “frameworks”, “security” AND “requirement engineering” OR “requirements”, “security” AND “requirement” AND “assurance”, “security” AND “assurance”.

 with the search string.

4. Discussion

This study adopts a two-phase mixed-method approach to explore the current state and challenges of Security Requirements Engineering (SRE) and Security Requirements Assurance (SRA). In the first phase, a structured literature review of 45 studies was conducted to map existing methodologies and their coverage of key activities. In the second phase, an empirical survey involving 58 professionals was used to quantitatively assess industry awareness and implementation gaps. This discussion is organized around the research questions (RQ1-RQ3) and concludes with a synthesis of findings, practical implications, and future recommendations. Compared with previous reviews that catalogued SRE methods without explicitly addressing assurance, this study advances the field by linking methodological coverage with practitioner knowledge. The integration of a structured completeness analysis with empirical validation provides a more comprehensive diagnostic than earlier single-method studies, making the assurance gap in SRE both theoretically evident and empirically confirmed.

(RQ1) What SRE methodologies have scholars proposed for identifying the security requirements in literature?

Figure 2 compares prominent SRE methods in terms of their coverage of requirement activities and highlights their main disadvantages. The left side shows that methods such as SQUARE, Secure Tropos, SREP, and CLASP support more than 10 out of the 17 activities considered in our review, making them the most comprehensive among the surveyed approaches. For instance, SQUARE provides structured elicitation and prioritization, Secure Tropos embeds security into goal modeling, CLASP integrates security practices across multiple lifecycle phases, and SREP emphasizes risk-driven requirements. By contrast, methods such as UMLsec or misuse cases cover fewer activities and are therefore more limited in scope.

The right side of the figure presents the common limitations across all SRE approaches, which are not specific to any single method but reflect systemic challenges in requirements engineering. These include stakeholder conflicts, resource constraints, and the complexity of modern systems, all of which lead to incomplete or conflicting requirements. The dynamic threat landscape further contributes to outdated requirements, while knowledge gaps among stakeholders can result in overlooked security needs. Together, these limitations explain why comprehensive methods struggle with consistent assurance, reinforcing the need for better integration of SRA into SRE processes.

(RQ2) What techniques for eliciting and analysis of security requirements have been prominently employed by established SRE methodologies?

RQ2 explores the practical application of elicitation and analysis techniques.

Table 7. Requirement Engineering Phases and Potential Challenges.

Requirement Phases	Purpose	Techniques	Potential Challenges
Requirement Elicitation	Gather and understand stakeholder needs and expectations.	Interviews, surveys, workshops, observation, prototyping.	Stakeholders may have conflicting or unclear requirements.
Requirement Analysis	Clarify, organize, and prioritize gathered requirements.	Use case analysis, scenario analysis, modelling, and prioritization.	It is difficult to balance competing stakeholder needs and priorities.
Requirement Specification/Representation	Document requirements in a structured, clear, and detailed format.	SRS (Software Requirements Specification), diagrams, and user stories.	The risk of ambiguity or over-specification limits flexibility.
Requirement Verification and Validation	Ensure requirements meet stakeholders’ needs and are feasible.	Reviews, testing, prototyping, stakeholder validation.	Completeness, Correctness, and Consistency challenges. Time-intensive; requires ongoing stakeholder involvement.

summarizes the requirement engineering phases, corresponding techniques, and potential challenges. Threat modelling, risk assessment, and misuse case modelling are widely adopted in SRE methods for identifying and prioritizing security concerns early in the software development process. These techniques enable structured analysis and proactive identification of vulnerabilities.

(RQ3) To what degree do SRE methodologies explicitly or implicitly assure the fulfilment of security requirements?

Research question 3, which is the primary question of this study. In the requirement elicitation and analysis phase, SRE methodologies investigate and provide support for security requirement assurance. SRE methodologies are designed to enhance security considerations throughout the software development lifecycle. SRE methodologies emphasize validating security requirements against identified threats, vulnerabilities, and industry standards using an assurance perspective.

However, in Methodologies inherently involve some level of assurance for security requirements, it’s important to note that the term “assurance” might not always be explicitly used in all methodologies. However, the concepts of validation, verification, testing, and implementation oversight often align with the idea of ensuring security requirements are effectively implemented. As such, it’s challenging to identify methodologies that completely exclude assurance altogether. In essence, SRE approaches might not explicitly label a “security requirement assurance” phase, but the core principles of these methodologies inherently contribute to the assurance of security requirements.

Table 8. SRE Methods and Requirement Phase Activities Comparison.

	SRE Methods and Requirement Phase Activities Comparison
	SRE Methods Activities											SR Elicitation	SR Analysis	SR Validation	SR management	Project Size	Standards
SRE Methods	Flexibility	scalability	Threats,	Req Validation	Risk analysis	vulnerability	Consistency	SR Integration	Assets identification	Misuse Modeling	Domain Knowledge	SR Identification and elicitation	Analysis of business SR conflicts	support provided for validation	Support provided in management
SQUARE	√	√	√	√	√	√	√	x	x		x	√	√	√	x	-	-
Secure Tropos	√	√	√	√	x	√	x	√	x	-	-	√	√	√	√	L	ISO/IEC
Abuse Frame	-	√	√	√	x	√	-	x	√	-	-	x	√	x	√	M	ISO
SREP	√	√	√	√	√	√	√	x	√	x	x	x	√	√	√	-	cc
Misuse-cases	√	x	√	x	x	√	x	√	x	√	x	√	√	x	√	S	-
UMLsec	-	-	√	x	√	√	-	-	x	√	-	x	-	√	-	M	ISO/IEC, IEEE
MORSE	√	x	√	x	x	√	x	√	x	x	x	√	√	x	√	M	-
SecureUML	-	-	x	x	x	x	-	-	x	-	-	x	√	x	-	M	-
CLASP	√	-	√	√	√	√	x	√	√	x	√	√	√	x	-	L	-

SRE Methods and Requirement Phase Activities Comparison compares SRE methods across major categories—SRE activities, SR elicitation, SR analysis, SR validation, SR management, project size, and standards. Each category is further broken into specific activities (e.g., asset identification, misuse modelling, conflict analysis, validation support). This structure shows both the activities covered by each method and the attributes (flexibility, scalability, consistency, risk analysis) that evaluate their effectiveness.

Table 8 referring to the literature results for comparative analysis of SRE approaches. SRE approaches are compared based on a three-level Likert scale, i.e., (“√”, “x”,“-”), for project size, (“Large = L”, “Medium = M”, “Small = s”). The level Likert scale sign “√” indicates that the specific activity is supported within the approach, “x” demonstrates that the approach does not support the available activity and “-” suggests that the available activity is not found in the literature for the SRE approach. Approaches are considered comprehensive if they achieve (70–100% of the activities, average (50–70%) and limited if they achieve below 50%).

5. Finding and Implications (Phase 2)

In the second phase, a questionnaire survey was conducted among software development teams to assess their knowledge about incorporating security in the early requirement engineering phase. The survey was distributed to more than 100 participants, but a total of 58 participants responded, to ensure the robustness of the study findings, multiple statistical tests were conducted, covering both inferential and reliability analyses.

5.1. Descriptive Statistics of Security Knowledge

The descriptive statistics highlight variations in security-related knowledge within software development in

Table 9. Security Awareness Levels.

Knowledge Area	Mean	Std. Dev
SRE (RQ 1)	3.61	0.88
RE (RQ 2)	3.67	0.75
SRA (RQ 3)	2.71	1.1

. Security Requirements Engineering (SRE) has a mean score of 3.61 with a standard deviation of 0.88, indicating a well-established understanding of security methodologies. Requirement Engineering (RE) scores slightly higher at 3.67, with a lower standard deviation (0.75), suggesting consistency in knowledge across respondents. In contrast, Security Requirements Assurance (SRA) has the lowest mean (2.71) and the highest variability (1.1), revealing significant gaps in security assurance expertise reinforces this trend, showing that while teams understand SRE (RQ1) and Requirement Engineering phases (RQ2) including asset identification, threat modelling, and security goal setting they struggle with SRA (RQ3). This lack of expertise poses a challenge, as inadequate assurance processes increase security risks.

5.2. Statistical Comparison of Security Knowledge

The results shown in

1.41 ± 0.25
[1.16, 1.66]

Table 10 highlight clear differences in how professionals understand security-related topics across different fields. Following Equation (4) we identified the Effect sizes and using Equation (5) we illustrated the Confidence intervals for each domain. The inferential analysis highlights significant differences in awareness across the three domains. SRE was significantly higher than SRA with a very large effect size (d = 1.41), while RE was also higher than SRA with a medium effect size (d = 0.48). In contrast, SRE and RE did not differ significantly (p = 0.63; negligible effect). The one-way ANOVA further confirmed these systematic disparities, with a large overall effect (η² = 0.23), indicating that the greatest knowledge gap lies in the limited practitioner awareness of SRA compared to SRE and RE. The results indicate that practitioners demonstrate stronger knowledge of SRE and general RE compared to SRA, confirming that assurance activities are the weakest area. While security concepts are acknowledged within RE, they are not consistently extended to assurance practices. The overall analysis highlights a substantial gap in practitioner awareness of SRA, underscoring the need to strengthen assurance integration within requirements processes to ensure more robust software security.

• Start with the test statistics

T = 10.78 and n = 58

2.

Compute Cohen’s d from t

For a paired-samples design:

$$\mathrm{d}= {\displaystyle \frac{10.78}{58}}=1.41$$

So, the effect size estimate is 1.41 (a very large effect).

3.

Compute the standard error (SE) of d

$${\mathrm{S}\mathrm{E}}_{\mathrm{d}}=\sqrt{{\displaystyle \frac{1}{58}}+{\displaystyle \frac{{1.41}^2}{2(58-1)}}}=0.13$$

4.

Build the 95% Confidence interval (CI)

The 1.96 is the critical Z value for a 95% confidence level under the standard normal distribution. It is used to expand an estimate (mean, effect size, regression coefficient, etc.) by ±1.96 × standard error, giving the 95% CI.

$$1.41\pm 1.96\times 0.13$$

$$1.41\pm 0.25$$

$$[1.16, 1.66]$$

Table 10. Inferential Statistics Results.

Comparison	T/F-Statistic	p-Value	Effect Size	Confidence Intervals
SRE vs. SRA	10.78	0.0017	d = 1.41	[1.16, 1.66]
SRE vs. RE	−0.49	0.6327	d = 0.06	[−0.31, 0.19]
SRA vs. RE	−3.69	0.0049	d = 0.48	[−0.73, −0.23]
ANOVA (SRE, SRA, RE)	8.19	0.0066	η2 = 0.23	-

Table 10. Inferential Statistics Results.

Comparison	T/F-Statistic	p-Value	Effect Size	Confidence Intervals
SRE vs. SRA	10.78	0.0017	d = 1.41	[1.16, 1.66]
SRE vs. RE	−0.49	0.6327	d = 0.06	[−0.31, 0.19]
SRA vs. RE	−3.69	0.0049	d = 0.48	[−0.73, −0.23]
ANOVA (SRE, SRA, RE)	8.19	0.0066	η2 = 0.23	-

5.3. Relationship Between Security Awareness and Implementation

The correlation analysis reveals critical insights into the relationship between security requirement knowledge, security assurance awareness, and their implementation in requirement engineering in

Table 11. Correlation Results Among Variables.

Correlation	r-Value	Confidence Interval
SRE & Security Techniques	0.596	[0.38, 0.74]
SRE & SRA	0.446	[0.16, 0.65]
RE & SRA	0.267	[−0.01, 0.52]

. A strong positive correlation (r = 0.596) between SRE methodologies and security techniques indicates that professionals proficient in security requirement engineering also recognize and apply key security practices. Additionally, a moderate correlation (r = 0.446) between SRE and SRA suggests that organizations adopting security methodologies tend to implement assurance techniques, though not consistently. However, the weak correlation (r = 0.267) between RE and SRA highlights a significant gap in integrating security assurance within requirement engineering. This lack of alignment suggests that while security methodologies are acknowledged, their validation and assurance processes remain underdeveloped. The findings emphasize the need for organizations to reinforce security assurance frameworks within requirement engineering to ensure a more comprehensive and effective approach to software security [37].

5.4. Variance and Distribution Analysis

Kruskal-Walli’s test results (χ² = 7.35, p = 0.02537) indicate a statistically significant difference in the distribution of security knowledge across SRE, SRA, and RE in

Table 12. Kruskal–Wallis Test.

Test	Statistics	p-Value	Effect Size
Kruskal–Wallis (SRE, SRA, RE)	7.35	0.02537	(ε2 = 0.10)

. This shows that Security Requirements Engineering is generally better understood than Security Assurance and General Requirements Engineering, where knowledge levels vary. The clear difference points to gaps in how security assurance is included in the requirements process, highlighting the need for proper training and clear methods. These results show the importance of focused efforts to close the knowledge gap, helping to create a more consistent and effective way of handling security in software development.

5.5. Predictive Modeling: Impact of SRE Knowledge

The predictive modeling results in

Table 13. Predictive Modeling.

Regression Model	β Coefficient	Confidence Interval (β)	R-Squared	p-Value
SRE → SRA	0.50	[0.31, 0.69]	0.42	0.015
SRE → RE	0.12	[−0.05, 0.29]	0.29	0.082

indicates show that knowledge of Security Requirements Engineering (SRE) has a strong link with Security Requirements Assurance (SRA). This means that organizations using well-defined security practices are more likely to apply assurance measures correctly. It suggests that a clear understanding of SRE helps in better checking and confirming security controls. However, the results also show that SRE knowledge does not strongly predict how security is applied within general Requirements Engineering (RE). This points to a gap between security theory and how it is used in RE work, showing the need for better ways to connect security methods with everyday requirements practices.

A summary of the Phase 1 and Phase 2: The literature review revealed that widely cited SRE methods (e.g., SQUARE, Secure Tropos, SREP, CLASP) provide structured support for elicitation and analysis but rarely include explicit, measurable assurance activities. This structural omission mirrors the survey findings, where practitioners demonstrated moderate familiarity with SRE and RE but consistently low awareness of SRA. The lack of assurance steps in popular frameworks likely reinforces this gap in practice, as engineers are less exposed to assurance concepts during method adoption. This alignment across phases underscores that the weak presence of SRA in methodological guidance directly contributes to its limited application in industry.

5.6. Implications for Practice and Future Research

The analysis shows that Security Requirements Engineering (SRE) is generally well understood and closely linked to effective security practices, while Security Requirements Assurance (SRA) remains the weakest area. Practitioners demonstrate strong awareness of SRE, but assurance activities are inconsistently applied, and their connection to general Requirements Engineering (RE) is weak. Knowledge differences across these domains are meaningful, with SRE significantly predicting assurance adoption but not influencing everyday RE practices. These findings highlight the urgent need to strengthen assurance integration within requirements processes to achieve a more balanced and reliable approach to software security.

To address this gap, we propose an integrated assurance workflow that demonstrates how SRA can be embedded across the SDLC. During elicitation, security requirements are gathered and supported by threat modelling and risk assessment artefacts. In analysis and prioritization, requirements are linked to assurance criteria through traceability matrices. In the design and specification phase, assurance checklists and test cases are prepared alongside modelling artefacts such as UMLsec diagrams. During implementation and verification, security requirements are validated against these artefacts using reviews, automated testing, and Common Criteria compliance. Finally, in maintenance, assurance is sustained through audits and updates to address evolving threats.

To further illustrate the gaps identified in our review and survey, Figure 3 presents a conceptual alignment of SRA activities with core SRE phases. This alignment is not a new model but a visual representation of where assurance tasks could be explicitly considered in practice, highlighting areas often overlooked in existing SRE methods.

This workflow provides practitioners with a diagnostic guide for reinforcing assurance within existing SRE practices, while offering researchers empirical evidence and a structured baseline for advancing assurance-oriented methodologies.

Limitations and Future Work: Although this study offers important exploratory insights, the moderate sample size limits the generalizability of the results. Future research should adopt larger and more stratified samples across industries, organizational roles, and geographical regions to confirm these patterns and extend the findings. Such studies would not only validate the current results but also provide a stronger basis for understanding how security requirements engineering and assurance practices vary in real-world contexts. In this sense, the present work serves as a foundational study that sets the stage for more comprehensive investigations.

6. Conclusions and Future Work

Security Requirements Engineering (SRE) is a critical component of the Software Development Life Cycle (SDLC), where early identification of security needs is essential. While past reviews have examined SRE techniques, the equally important area of Security Requirements Assurance (SRA) has often been overlooked. To address this gap, this study reviewed 140 research articles, selecting 45 based on quality criteria—29 focused on SRE and 16 focused on assurance. A structured comparison across 17 attributes showed that methods such as SQUARE, Secure Tropos, SREP, and CLASP emphasize threat modelling, requirements elicitation, and defining security objectives, but rarely address assurance in a consistent way. Complementing this review, an industry survey revealed that although awareness of SRE practices is moderate, the understanding and use of assurance techniques remain limited, exposing a gap between research and practice. The study contributes a comparative guide for selecting context-appropriate SRE methods and highlights the need to integrate assurance as a distinct, measurable phase within these processes. The evaluation framework developed here also provides a benchmark for assessing the completeness of SRE approaches. Future research with larger and stratified samples will be essential to validate and extend these exploratory findings.