SREPPLine: Towards a Security Requirements
Engineering Process for Software Product Lines
Daniel Mellado
, Eduardo Fernández-Medina
and Mario Piattini
Ministry of Work and Social Affairs
Management Organism of Information Technologies of the Social Security
Software Development Centre of the National Social Security Institute, Madrid, Spain
ALARCOS Research Group, Information Systems and Technologies Department
University of Castilla-La Mancha
Paseo de la Universidad 4, 13071 Ciudad Real, Spain
Abstract. Security related requirements are increasingly becoming a significant
portion of the total set of requirements for many software systems. At the same
time, nowadays many systems are developed based on the product line engi-
neering paradigm. Within product lines, security requirements issues are ex-
tremely important because weakness in security can cause problems throughout
the lifecycle of a line. The main contribution of this work is that of providing a
standard-based process, which is an add-in of activities in the domain engineer-
ing as well as in application engineering processes. These processes deal with
the security requirements from the early stages of product line lifecycle in a
systematic and intuitive way especially adapted for product line based devel-
opment. It is based on the use of the latest security requirements techniques, to-
gether with the integration of the Common Criteria (ISO/IEC 15408) into the
product line lifecycle. Additionally, it deals with security artefacts reuse, by
providing us with a Security Resources Repository. Moreover, it facilitates the
conformance to the most relevant security standards with regard to the man-
agement of security requirements.
1 Introduction
Our society has become increasingly IT-based [31], depending as it does on a huge
number of software systems which have a critical role and which manage critical and
sensitive information, it is absolutely vital that Information Systems (IS) are properly
assured from the very beginning [1, 22], due to the potential losses faced by organiza-
tions that put their trust in all these IS. Moreover, it is widely-accepted the principle
which establishes that the building of security at the early stages of the development
process is cost-effective and also brings about more robust designs [17].
Furthermore, nowadays, there is an increase in the demand as well in the com-
plexity of the software needed. Thus, in order to obtain high-quality IS along with
higher productivity, software product line (SPL) based development has become the
Mellado D., Fernández-Medina E. and Piattini M. (2007).
SREPPLine: Towards a Security Requirements Engineering Process for Software Product Lines.
In Proceedings of the 5th International Workshop on Security in Information Systems, pages 220-232
DOI: 10.5220/0002424702200232
most successful approach in the reuse field, because it can help us significantly re-
duce time-to-market as well as development costs [3, 4], by increasing the reuse of all
types of artefacts, thanks to the combination of coarse-grained components with a
top-down systematic approach where the software components are integrated into a
high-level structure.
Due to the complexity and extensive nature of product line development, security
and requirements engineering are much more important for a product line practice.
Security is a cross-cutting concern in software intensive systems and should conse-
quently be subject to careful requirements analysis and decision making, in addition
the requirements for cost-effective product line development complicate this task.
Therefore, the discipline known as Security Requirements Engineering is a very im-
portant part of the SPL development process for the achievement of secure SPL and
applications, because it provides techniques, methods and standards for tackling this
task in the development lifecycle. It also implies the use of repeatable and systematic
procedures to ensure that the set of requirements obtained is complete, consistent,
easy to understand and analysable by the different actors involved in the development
of the system [18].
In the last few years, it has been a spectacular growing of security standards and
security related proposals which have been developed to try to help develop security
critical IS. Moreover, it has recently been developed SPL reference architectures for
security and SPL requirements management approaches and tools, such as [14, 29].
Nevertheless, after analysing the previously performed comparative analyseses of
several relevant proposals of IS security requirements, as those of [6, 23, 28, 30,
32],etc. in [24, 25], we conclude that those standards and proposals are neither spe-
cific enough for a systematic and intuitive treatment of SPL security requirements,
nor make it easy the task of integrating security requirements engineering activities
into the SPL based development. In addition, they did not provide intuitive, system-
atic and methodological support for the management of security requirements, with
the aim of developing secure SPL and products that conform to the most relevant
security standards with regard to the management of security requirements (such as
mainly ISO/IEC 15408 [10] as well as ISO/IEC 27001 [12], ISO/IEC 17799 [11] or
ISO/IEC 21827 [8]).
In this paper, as an evolution of our previous proposal SREP [25], we will present
a Security Requirements Engineering Process for software Product Lines (SREP-
PLine), which is a standard-based process that describes how to integrate security
requirements into the software engineering process in a systematic and intuitive way,
as well as a simple integration with the rest of requirements and the different
phases/processes of the SPL development lifecycle. Additionally, this process will
facilitate the fulfilment of the IEEE 830:1998 standard [7], and it will help develop IS
which conform to the aforementioned security standards with regard to the manage-
ment of security requirements, and without being necessary to perfectly know those
standards; hence, reducing the participation of security experts to achieve it. In order
to reach these goals, our approach is based on the reuse of security artefacts which are
integrated in the variability model of the SPL, by providing a Security Resources
Repository (SRR), together with the integration of the Common Criteria (CC)
(ISO/IEC 15408) into the SPL lifecycle.
The rest of the paper is organized as follows: in section 2, we will summarize the
main concepts of requirements engineering in software product lines. Then, in section
3, we will present an outline of our proposed security requirements engineering proc-
ess for software product lines (SREPPLine). Later, in section 4, we will explain the
security resources repository. Finally, in section 5, we will state our conclusions and
future work.
2 A Summary of Product Line Requirements Engineering
A software product line is a set of software-intensive systems sharing a common,
managed set of features
[15] that satisfy the specific needs of a particular market
segment or mission and that are developed from a common set of core assets in a
prescribed way [4].
The software product line engineering paradigm separates two processes: domain
engineering and application engineering [27]. Domain engineering is the process of
SPL engineering in which commonality and variability of the product line are defined
and realised, and it is composed of five key sub-processes: product management,
domain requirements engineering, domain design, domain realisation and domain
testing. According to [27],the domain requirements engineering sub-process encom-
passes all activities for eliciting and documenting the common and variable require-
ments of the product line. Hence, domain requirements engineering differs from re-
quirements engineering for single systems in the following subjects: commonality
analysis; variability analysis and modelling; and it tries to anticipate prospective
changes in requirements, such as laws, standards, technology changes and market
needs for future applications. Application engineering is the process of SPL engineer-
ing in which the applications of the product line are built by reusing domain artefacts
and exploiting the product line variability, and it is composed of the following sub-
processes: application requirements engineering, application design, application reali-
sation and application testing.
Product line requirements define the products and common and variable features
of the products in the product line. Requirements common across the entire family,
which constitute the product line requirements and an important core asset, should be
managed separately from requirements that are particular to a subset of the products
(or to a single product), which must be managed as well. Product line requirements
engineering incorporates different requirements sources, such as stakeholders (do-
main experts, etc.), existing products or competitors’ products, existing model do-
mains or the SPL scope. The product line scope bounds the products included in the
product line: product line requirements refine the scope by more precisely defining
the characteristics of the products in the product line. The scope and product line
requirements are tightly coupled and evolve together [4].
Finally, after analysing several relevant proposals of SPL requirements and some
SPL requirement management tool, as those of [4, 14, 16, 27, 29], we argue that those
proposals are neither specific enough for a systematic and intuitive treatment of SPL
A feature is an end-user visible characteristic of a system.
security requirements, nor make it easy the task of integrating security requirements
engineering activities into the SPL based development.
3 SREPPLine: a Security Requirements Engineering Process for
Software Product Lines
The Security Requirements Engineering Process for software Product Lines (SREP-
PLine) is an add-in of activities (that are decomposed into tasks which receive input
artefacts and which generate output artefacts, with the participation of different roles)
that are integrated into a SPL development process model of any organization provid-
ing it with a security requirements approach. The order in which they are performed
depends on the particular process that is established in the organization. Hence the
sub-process and its activities described in this paper can be combined with existing
development methods such as the Unified Process or other development processes. In
this paper we will describe the integration of our process into the SPL engineering
framework proposed in [27].
Fig. 1 The Software Product Line Security Requirements Engineering Framework.
As it is shown in Fig. 1, SREPPLine is composed of two sub-processes with their
respective activities: PLSecDomReq (Product Line Security Domain Requirements
Engineering sub-process) and PLSecAppReq (Product Line Security Application
Requirements Engineering sub-process). These sub-processes cover the four basic
phases of the requirements engineering according to [19]: requirements elicitation;
requirements analysis and negotiation; requirements documentation; and requirements
validation and verification. Therefore, at least, they have to be performed for each
iteration of the Domain or Application Requirements Engineering Process of the SPL,
respectively. However, in this paper due to space restrictions, we will outline the key
activities and tasks that have to be part of PLSecDomReq and we will present a brief
overview of PLSecAppReq (as an evolution of SREP [25]).
3.1 Product Line Security Domain Requirements Engineering Sub-process
The main goals of this sub-process (SP1) are the development of common and vari-
able security requirements which conform to IEEE 830:1998 as well as their precise
documentation in a Protection Profile
(PP) similar document and the development of
their common and variable related security artefacts following a CC similar format.
The process model of this sub-process is shown in Fig. 2.
SP1 - Activity A1.1: Security Management Scoping. This activity comprises the
following tasks: security resources repository improvement (up-to-date artefacts and
links); identification of specific stakeholders; security definitions agreement; security
environment identification (security policy, security standards, laws, constraints,
security needs and security acceptance criteria as well as the evaluation assurance
level (EAL) of the CC); identification of the relevant type of assets and security ob-
jectives; security cost impact and risk superficial estimations; and security features
identification (commonalities and variability).
SP1 - Activity A1.2: Security Assets Scoping. This activity comprises the following
tasks: security assets identification for each asset (or group of them) and for the envi-
ronment; security assumptions; security asset scoping, which aims at identifying par-
ticular components to be developed for reuse, common and variable assets; identifica-
tion of dependences between security assets; and valuation of security assets.
SP1 - Activity A1.3: Security Objectives Scoping. This activity comprises the fol-
lowing tasks: security objectives identification (commonality and variability analy-
sis); security objectives modelling and specification (APE_OBJ CC class); security
objectives valuation.
The Common Criteria define a Protection Profile as an implementation independent statement
of security requirements that is shown to address threats that exist in a specified environment
SP1 - Activity A1.4: Security Threats Scoping. This activity comprises the follow-
ing tasks: identification of potential vulnerabilities in public domain sources; identifi-
cation of the attack tree associated with the business pattern or SPL domain; identifi-
cation of the misuse cases and threats for each security objective and asset (common-
ality and variability analysis), because each asset is targeted by threat/s that can pre-
vent the security objective from being achieved; threats modelling and specification;
validation of security objectives against threats and assets and their variability mod-
Fig. 2. Activity model of PLSecDomReq.
SP1 - Activity A1.5: Security Risks Assessment. This activity comprises the follow-
ing tasks in order to achieve 100% risk acceptance: assessing whether the threats are
relevant according to the security level specified by the security objectives; estimating
the security risks based on the relevant threats, their likelihood and their potential
negative impacts, depending on the variation points. To do so, the ISO/IEC 13335
(GMITS) [9], provides guidance on the use of the risk management process. In Spain
it could be used MAGERIT [21], which conforms to ISO/IEC 13335.
SP1 - Activity A1.6: Security Requirements Scoping. This activity comprises the
following tasks: security requirements elicitation, the suitable security requirements
or the suitable package of security requirements that mitigate the threats at the neces-
sary levels with regard to the risk assessment must be selected; identification of
common security requirements according to the elicited requirements and through the
previously performed risk analysis; defining variable requirements and variability
dependencies; security requirements modelling; definition of CC operations (itera-
tion, assignment, selection or refinement); definition of security test/metric and coun-
termeasure for each security requirement. Thus, at the end of this activity and accord-
ing to ISO/IEC 17799:2005 it must have been specified the functional, assurance, and
organizational security requirements, along with the security requirements for the IT
development and operational environment.
SP1 - Activity A1.7: Security Requirements Negotiation and Prioritization. This
activity comprises the following tasks: interdependences with other functional and
non-functional requirements and trade-offs in the security variability model and there-
fore in the orthogonal variability model; balancing the risk with the economical im-
pact of implementing countermeasures.
SP1 - Activity A1.8: Security Requirements Specification. This activity comprises
the following tasks: security requirements modelling and security requirements
SP1 - Activity A1.9: Security Requirements Artefacts Inspection. This activity
comprises the following tasks: i) it is verified whether the security requirements con-
form to CC (ISO/IEC 15408) and to IEEE 830-1998 standard, because according to
this standard, a quality requirement has to be correct, unambiguous, complete, consis-
tent, ranked for importance and/or stability, verifiable, modifiable, and traceable. ii)
Furthermore, SREP proposes the use of the SSE-CMM (ISO/IEC 21827) in order to
help in the evaluation of the product line security engineering process in the Domain
Testing sub-process, with the help of the CC_SSE-CMM [20] approach. Thereby, we
propose to evaluate the security of the SPL along with the product line security engi-
neering process by using the CC assurance requirements and the SSE-CMM at the
same time with the help of CC_SSE-CMM. iii) It will verify in the Domain Testing
sub-process the fulfilment of the previously approved EAL and the CC evaluation.
3.2 Product Line Security Application Requirements Engineering Sub-process
PLSecAppReq (Product Line Security Application Requirements Engineering sub-
process) activities in this sub-process (SP2) are similar to SREP [25] activities, except
for some specific tasks and activities that are unique to security requirements engi-
neering in SPL. The main goals of this sub-process are: elicitation and documentation
of the security requirements and their related security artefacts; to make them conform
to IEEE 830:1998, as well as to gather them in a Security Targets
(ST) similar docu-
ment; at the same time to reuse, as much as possible, the security domain artefacts and
Due to space restrictions, we have enumerated in Fig. 1 the key activities of
PLSecAppReq sub-process and below we will only describe the key differences be-
tween this sub-process and security requirements engineering for single systems (such
as SREP):
- Requirements elicitation is based on the communication of the available com-
monality and variability of the SPL. Most of the requirements are not elicited
anew, but are derived from the domain requirements.
- During security requirements elicitation, the differences between security appli-
cation artefacts and security domain artefacts (sec-deltas) must be detected,
evaluated with regard to the required adaptation effort, and suitably documented.
If the required adaptation effort is early known, trade-off decisions concerning
application security artefacts are possible not only to reduce the effort but also to
increase the amount of domain artefacts.
4 The Security Resources Repository
SREPPLine proposes a Security Resources Repository (SRR), which facilitates the
product line security requirements engineering by making it easier the development
with security requirements reuse, which is an important concept in SPL because it
helps us increase the security requirements quality for an improved use in subsequent
projects [32]. Moreover, it helps manage in an easier way one of the most important
factors of success in the development of a secure SPL: the management of commonal-
ities and variability of the security requirements and their traceability links.
The security requirements can be obtained from security objectives or threats
starting from the assets for a new SPL or for a new product of a SPL. Furthermore,
the SRR uses the concept of package, understood as a homogeneous set of require-
ments that can be applied to different products of the SPL, and that are put together to
satisfy the same security objectives as well as to mitigate the same threats, being a
bigger and more effective reuse unit. The security domain requirements engineering
as well as the security application requirements engineering sub-processes are sup-
ported by this repository.
Next, we will outline the most important and/or complex aspects of the meta-
model shown in Fig. 3:
- ‘Domain Threat’ and ‘Domain Security Requirement’ (or CC Component) are
described independently of particular products. They can be represented as dif-
ferent specifications, thanks to the elements ‘Threat Specification’ and ‘Security
The Common Criteria define a Security Target as an implementation dependent statement of
security needs for a specific identified product.
Requirement Specification’. They are included in the core assets of the SPL, to-
gether with the ‘Security Objective’, which are documented through a goal tree
specified in XML in order to enable the explicit documentation of variability.
Besides all of them support traceability links.
- ‘Security Requirement Package’ is a set of requirements that work together to
satisfy the same security objectives and mitigate the same threats.
- The ‘Security Requirement – Security Requirement’ relationship allows an in-
clusive or exclusive trace between requirements, that is variability constraints.
An exclusive trace between requirements means that they are mutually alterna-
tive, for example that they are in conflict or overlapping, whereas, an inclusive
trace between requirements means that to satisfy one, other/other/s is/are needed
to be satisfied. In addition, it is used to model the dependencies with other func-
tional and non-functional requirements. Traces among requirements in the SPL
infrastructure do automatically also exist in the products.
In addition, there could have been links further on to design level specifications,
security test cases, countermeasures, etc., as well as traceability links with other arte-
facts (“artefacts dependencies”), through the relationship between a variant of the
orthogonal variability model and the associated development artefact, because our
proposed model process is based on the concept of the orthogonal variability model
of Pohl et al. [27]. Thus, the SRR must be integrated into the SPL core assets reposi-
tory to facilitate these traceability links between the variability model of the SPL and
the different types of security artefacts and the other development artefacts.
Finally, we would like to point out the fact that using the CC, a large number of
security requirements on the SPL itself and on the products development can be de-
fined. Nevertheless, the CC neither provide us with methodological support, nor con-
tain security evaluation criteria pertaining to administrative security measures not
directly related to IS security measures. However, it is known that an important part
of the security of an IS can be often achieved through administrative measures.
Therefore, according to ISO/IEC 17799:2005, we propose to include legal, statutory,
regulatory, and contractual requirements that the organization, its trading partners,
contractors, and service providers have to satisfy, and their socio-cultural environ-
ment. After converting these requirements into software and system requirements
format, these requirements along with the CC security requirements would be the
initial subset of security requirements of a SPL, acting like horizontal security re-
quirements patterns for the software product lines of the organization.
Fig. 3. Product Line Security Resources Meta-model.
5 Conclusions and Further Work
Nowadays, software security is generating a growing interest mainly due to the in-
creasingly crucial nature of the IS with corresponding levels of new legal and gov-
ernmental requirements. At the same time, there is an increasing need to obtain high-
quality IS along with higher productivity. For this reason, software product line based
development has become the most successful approach for ensuring quality, eco-
nomic efficiency and manageability of software systems [2]. Nevertheless, require-
ments management and security of information are much more critical in SPL due to
the complexity and extensive nature of them. Therefore, we believe that it is vital to
deal with security at all stages of SPL development, especially in the management of
security requirements, since these form the basis for the achievement of a robust IS.
Hence, the contribution of this work is that of providing a standard-based process
that deals with security requirements from the early stages of SPL development in a
systematic and intuitive way specially adapted to SPL based development, which is
based on the use of the latest security requirements techniques, such as UMLSec [13],
security use cases [5] or misuse cases [30]; as well as on the reuse of security arte-
facts, by providing a Security Resources Repository (SRR), together with the integra-
tion of the Common Criteria (ISO/IEC 15408) into the SPL lifecycle. Furthermore, it
also conforms to the most relevant security standards with regard to the management
of security requirements such as the aforementioned ISO/IEC 15408 and ISO/IEC
17799:2005 (sections: 0.3, 0.4, 0.6 and 12.1) and ISO/IEC 27001:2005 standard (sec-
tions: 4.2.1, 4.2.3, 4.3, 6.a, 6.b and A.12.1.1). Furthermore, it facilitates that the prod-
ucts of the SPL conform to these former standards as well as the fulfilment of the
IEEE 830:1998 standard. In addition, SREPPLine suggests using a method to carry
out the risk assessment which conforms to ISO/IEC 13335 (GMITS).
As the application of any methodology or requirements engineering process will
normally fail because it has to be manually performed, further work is also needed to
develop a new version of our previously developed CARE (Computer-Aided Re-
quirements Engineering) tool (SREPTOOL [26]) in order to support and gather the
new characteristics of our proposed security requirements engineering process for
software product lines. Furthermore, we will carry out a refinement of the theoretical
approach by proving it with a real case study to complete and deeply detail SREP-
PLine. Finally, we will work to complement this process in order to provide a holistic
framework for security engineering in software product lines.
This paper is part of the ESFINGE (TIN2006-15175-C05-05) and RETISTRUST
(TIN2006-26885-E) projects of the Ministry of Education and Science (Spain), and
of the MISTICO (PBC-06-0082) and DIMENSIONS (PBC-05-012-2) projects of the
Consejería de Ciencia y Tecnología de la Junta de Comunidades de Castilla- La Man-
cha and the FEDER.
1. Baskeville, R., The development duality of information systems security. Journal of Man-
agement Systems, 1992. 4(1): p. 1-12.
2. Birk, A., Heller, G., John, I., MaBen, T.v.d., Müller, K., and Schmid, K., Product line
engineering industrial nuts and bolts. 2003, Fraunhofer IESE: Kaiserslautern.
3. Bosh, J., Design & Use of Software Architectures. 2000: Pearson Education Limited.
4. Clements, P. and Northrop, L., Software Product Lines: Practices and Patterns. SEI Series
in Software Engineering. 2002: Addison-Wesley.
5. Firesmith, D.G., Engineering Security Requirements. Journal of Object Technology, 2003.
2(1): p. 53-68.
6. Firesmith, D.G., Security Use Cases. Journal of Object Technology, 2003: p. 53-64.
7. IEEE, IEEE 830: 1998 Recommended Practice for Software Requirements Specifications.
8. ISO/IEC, ISO/IEC 21827:2002 Information technology -- Systems Security Engineering --
Capability Maturity Model (SSE-CMM). 2002.
9. ISO/IEC, ISO/IEC 13335 Information technology - Security techniques - Management of
information and comunications technology security - Part 1: Concepts and models for in-
formation and comunications technology security management. 2004.
10. ISO/IEC, ISO/IEC 15408:2005 Information technology - Security techniques - Evaluation
criteria for IT security, (Common Criteria v3.0). 2005.
11. ISO/IEC, ISO/IEC 17799 Information technology - Security techniques - Code of practice
for information security management. 2005.
12. ISO/IEC, ISO/IEC 27001:2005 Information technology -- Security techniques -- Informa-
tion security management systems -- Requirements. 2005.
13. Jürjens, J., UMLsec: extending UML for secure systems development. UML 2002 - The
Unified Modeling Language. Model Engineering, Languages,Concepts, and Tools. 5th In-
ternational Conference., 2002. LNCS 2460: p. 412-425.
14. Käkölä, T. and Dueñas, J.C., Software Product Lines: Research Issues in Engineering and
Management. 2006: Springer.
15. Kang, K., Cohen, S., Hess, J.A., Novak, W.E., and Peterson, S.A., Feature-Oriented Do-
main Analysis (FODA) Feasibility Study. 1990, Software Engineering Institute, Carnegie-
Mellon University.
16. Kim, J., Kim, M., and Park, S., Goal and scenario bases domain requirements analysis
environment. The Journal of Systems and Software, 79(7) (2005). p. 926 - 938.
17. Kim., H.-K., Automatic Translation Form Requirements Model into Use Cases Modeling
on UML. ICCSA 2005, LNCS, 2005: p. 769-777.
18. Kotonya, G. and Sommerville, I., Requirements Engineering Process and Techniques.
Hardcover ed. 1998, UK: John Willey & Sons. 294.
19. Kotonya, G. and Sommerville, I., Requirements Engineering Process and Techniques.
2000: John Willey & Sons.
20. Lee, J., Lee, J., Lee, S., and Choi, B., A CC-based Security Engineering Process Evalua-
tion Model. 27th Annual International Computer Software and Applications Conference
(COMPSAC'03), 2003: p. 130-.
21. López, F., Amutio, M.A., Candau, J., and Mañas, J.A., Methodology for Information Sys-
tems Risk Analysis and Management. 2005: Ministry of Public Administration.
22. McDermott, J. and Fox, C. Using Abuse Case Models for Security Requirements Analysis.
in Annual Computer Security Applications Conference. 1999. Phoenix, Arizona.
23. Mead, N.R. and Stehney, T. Security Quality Requirements Engineering (SQUARE) Meth-
odology. in Software Engineering for Secure Systems (SESS05), ICSE 2005 International
Workshop on Requirements for High Assurance Systems. 2005. St. Louis.
24. Mellado, D., Fernández-Medina, E., and Piattini, M., A Comparative Study of Proposals for
Establishing Security Requirements for the Development of Secure Information Systems.
The 2006 International Conference on Computational Science and its Applications (ICCSA
2006), Springer LNCS 3982, 2006. 3: p. 1044-1053.
25. Mellado, D., Fernández-Medina, E., and Piattini, M., A Common Criteria Based Security
Requirements Engineering Process for the Development of Secure Information Systems.
Computer Standards and Interfaces, 29(2) (2007). p. 244 - 253.
26. Mellado, D., Rodríguez, M., Fernández-Medina, E., and Piattini, M., Soporte Automatizado
a la Ingeniería de Requisitos de Seguridad. X Workshop Iberoamericano de Ingeniería de
Requisitos y Ambientes de Software (IDEAS'07), 2007: p. (accepted).
27. Pohl, K., Böckle, G., and Linden, F.v.d., Software Product Line Engineering. Foundations,
Principles and Techniques. 2005, Berlin Heidelberg: Springer.
28. Popp, G., Jürjens, J., Wimmel, G., and Breu, R., Security-Critical System Development
with Extended Use Cases. 2003: 10th Asia-Pacific Software Engineering Conference. p.
29. Schmid, K., Krennrich, K., and Eisenbarth, M., Requirements Management for Product
Lines: A Prototype. 2005, Fraunhofer IESE.
30. Sindre, G. and Opdahl, A.L., Eliciting security requirements with misuse cases. Require-
ments Engineering 10, 2005. 1: p. 34-44.
31. Siponen, M.T., Secure-System Design Methods: Evolution and Future Directions. IT Pro-
fessional, 8(3) (2006). p. 40-44.
32. Toval, A., Nicolás, J., Moros, B., and García, F., Requirements Reuse for Improving Infor-
mation Systems Security: A Practitioner's Approach. Requirements Engineering, 6(4)
(2002). p. 205-219.