Security requirements engineering framework for software product lines

  • Authors:
  • Daniel Mellado;Eduardo Fernández-Medina;Mario Piattini

  • Affiliations:
  • Spanish Tax Agency, Large Taxpayers Department - IT Audit Unit Paseo de la Castellana 106, 28046 Madrid, Spain;University of Castilla-La Mancha. Alarcos Research Group, Information Systems and Technologies Institute, Information Systems and Technologies Department, ESI, Paseo de la Universidad 4, 13071 Ciu ...;University of Castilla-La Mancha. Alarcos Research Group, Information Systems and Technologies Institute, Information Systems and Technologies Department, ESI, Paseo de la Universidad 4, 13071 Ciu ...

  • Venue:
  • Information and Software Technology
  • Year:
  • 2010

Quantified Score

Hi-index 0.00

Visualization

Abstract

Context: The correct analysis and understanding of security requirements are important because they assist in the discovery of any security or requirement defects or mistakes during the early stages of development. Security requirements engineering is therefore both a central task and a critical success factor in product line development owing to the complexity and extensive nature of software product lines (SPL). However, most of the current SPL practices in requirements engineering do not adequately address security requirements engineering. Objective: The aim of this approach is to describe a holistic security requirements engineering framework with which to facilitate the development of secure SPLs and their derived products. It will conform with the most relevant security standards with regard to the management of security requirements, such as ISO/IEC 27001 and ISO/IEC 15408. Results: This framework is composed of: a security requirements engineering process for SPL (SREPPLine) driven by security standards; a Security Reference Meta Model to manage the variability of those SPL artefacts related to security requirements; and a tool (SREPPLineTool) which implements the meta-model and supports the process. Method: A complete explanation of the framework will be provided. The process will be formally specified with SPEM 2.0 and the repository will be formally specified with an XML grammar. The application of SREPPLine and SREPPLineTool will be illustrated through a description of a simple example as a preliminary validation. Conclusion: Although there have been several attempts to fill the gap between requirements engineering and SPL requirements engineering, no systematic approach with which to define security quality requirements and to manage their variability and their related security artefacts in SPL models is, as yet, available. The contribution of this work is that of providing a systematic approach for the management of the security requirements and their variability from the early stages of product line development in order to facilitate the conformance of SPL products with the most relevant security standards.