4) have not been considered in any of theses

4)  Secure
Tropos: Tropos methodology 21 was intro-duced by Castro et al. in order to
cover system requirements during the whole software
development process. However, Tropos methodology gives a strong focus on the
early stage of system analysis. The framework includes five development phases:
early requirements, late requirements, architectural design, detailed design
and implementation. However, security concepts have not been considered in any
of theses phases. Thus, Mouratidis et al. extended Tropos methodology in order
to accommodate security concepts during the requirements analysis. The
extension is called Secure Tropos 22 and utilizes only the early and late
requirements phases of Tropos framework. Secure Tropos introduces the concept
of security constraints. According to the authors, security constraints are a
set of conditions, rules and restrictions that are imposed on a system and the
system must operate in such way that none of them will be violated 22. In the
early requirements phase, a security diagram is constructed in order to
represent the con-nection between security features, threats and mechanisms
that help the satisfaction of security goals. The security diagram is taken
into consideration at the late requirements phase in order for the designers to
impose security constraints to the system-to-be. The enforcement of security
constraints in different parts of the system can facilitate the disclosure of
possible conflicts between requirements.

 

7)  KAOS:
In 2000, KAOS 23 was first introduced as a goal-oriented requirements
engineering method in order to elaborate requirements from high level goals.
According to the authors, the fulfillment of goals might be blocked by some
exceptional agent behaviors that are called obstacles. In KAOS method, these
obstacles have to be identified and resolved, through the elaboration of
scenarios between soft-ware and agents, in order to produce a reliable system
24. However, due to the fact that KAOS methodology considers only functional
requirements, authors extended KAOS 25 in order to elaborate security
requirements as well. The main idea of the extended framework is to build two
models. A model of the system-to-be, that will describe the software and the relations
between goals, agents, objects, operations and requirements and an anti-model
that will capture possible attackers, their goals and system vulnerabilities in
order to elicit all possible threats and security requirements to prevent such
treats. Security requirements that derived by the anti-model as countermeasures
have to be integrated in the original model.

We Will Write a Custom Essay Specifically
For You For Only $13.90/page!


order now

 

8)  PresSure:
In 2014, Fabender et al. introduced a problem-based methodology, which is
called presSure 26-

 

in order to identify security needs during requirements analysis of
software systems. The identification of security requirements is based on
functional requirements of a system-to-be and on the early identification of
possible threats. The methodology supports the modeling of functional requirements
through problem diagrams. At next stage and after identi-fying the critical
assets of the system and the rights of the authorized entities, possible
attackers and their abilities have to be determined. Based on that information,
a set of graphs is generated in order to visualize flows of possible threats
related to the attackers access to critical assets. Security requirements
derived from the analysis of these graphs. For each identified asset, every
functional requirement is related with possible threats and security
requirements