Haley includes the notion of trust assumptions and

Haley et al. 16 introduced a problem based approach in order to elicit and analyze security requirements. The authors describe an iterative process of four steps. During these steps, security goals can be identified after the identification of functional (business) requirements. The identification of security goals includes the identification of system assets and a threat analysis. Risk assessment is also supported during the identification of security goals. However, in order to elicit security requirements from these security goals, the authors of Security Requirements Engineering Framework (SREF) 16 take security requirements as constraints for functional requirements of the system under consideration and these constraints satisfy one or more security goals. The authors also encourage the use of problem diagrams to capture functional requirements with such constraints. The framework includes the notion of trust assumptions and the construction of satisfac-tion arguments by system analysts in order to validate security requirements. Privacy requirements are not considered by this framework. 4) Eliciting Security Requirements from the Business Pro-cess Models : N. Ahmed and R. Matulevicius introduced an asset based approach in order to elicit security goals from business process models and translate them into security requirements 17. The method consists of two stages. At the first stage, an early analysis is performed in order to determine business assets that must be protected against security risks and security goals. At the second stage, the elicitation of security requirements is performed during examination of the security risk of business assets in five contextual areas: access control, communication channel, input interfaces, business services and data store. The final result is the elicitation of security requirements and the generation of business rules that satisfy security goals of the system under consideration. This framework does not support categorization, prioritization and validation of security requirements. 5) Security Requirements Engineering process (SREP): Mellado et al. presented SREP method 18 in order to provide a unified framework that considers concepts from requirements engineering and security engineering as well. Security Re-quirements Engineering Process (SREP) is an iterative and incremental security requirements engineering process and is aiming to integrate security requirements at the early stages of software development life cycle 19. SREP is an asset-based method, as well as a threat and risk driven method and it is based on the integration of Common Criteria 20 into the software life cycle in order to specify security requirements and validate that products meet security goals. The main idea of the proposed framework is that the unified process is divided into four phases: Inception, Elaboration, Construction and Transition. Each phase might include many iterations of nine activities (definitions, identification of assets, security objectives and threats, risk assessment, elicitation of secu-rity requirements, categorization-prioritization, inspection and repository improvement) but with different emphasis depend-ing on what phase of the lifecycle the iteration is in 18. Also, the authors propose the use of Security Resources Repositories to store sets of requirements that can be reused in different domains. Privacy requirements have not been considered by the authors.