Due to the ongoing digitalization of our everyday life, the consideration of security for software-intensive systems is of great importance. The number of reported security incidents highly increased in the last years. Each may lead to substantial damage for companies, not only financially, but also in terms of reputation loss. In order to avoid such incidents, security should be addressed as early as possible during software development, i.e. during requirements engineering by following the principle of security-by-design.
To spend the available resources during software development effectively, it is necessary to prioritize the analysis of incidents. As a criterion for this prioritization, it is possible to take their risk level into account. It is defined as the likelihood of occurrence of an incident and its consequences for an asset, i.e. something of value. In the context of information security, an asset is a piece of information that shall be protected regarding confidentiality, integrity, or availability. The ISO 27005 standard defines guidelines for security risk management processes which consist of a set of coordinated activities to identify, evaluate, and treat risks.

Although risk management is a well-known concept in the area of security, current research in this field has several open issues, especially in the context of requirements engineering.
We identified the following challenges requirements engineers and security engineers are confronted with when managing security risks.
(1) Having a common understanding of what shall be analyzed: Software under development can be described in terms of its functional requirements. Since these requirements can serve as one of the initial inputs for security analysis, they have to be documented precisely.
(2) Finding the right level of abstraction: Technical details, e.g. which database systems will be used, are not available in the earliest stages of software development. Therefore, it is necessary to abstract knowledge about incidents and suitable countermeasures.
(3) Systematizing the risk management process: Existing risk management processes are often carried out in brainstorming sessions with experts from different disciplines. To capture all relevant security-related aspects, these sessions require a systematic procedure.
(4) Making knowledge reusable: Knowledge about incidents and appropriate countermeasures shall be documented consistently for being transferable to future development projects.
(5) Propagating results to the design phase: The results of the risk management process shall be documented in a systematic way for being considered in the next phases of the development process.
(6) Scaling the process: Due to a large number of activities, the application of a risk management process requires high effort from the engineers. Therefore, its application shall be supported as much as possible, e.g. with graphical editors.

Our contribution in this thesis is two-fold: First, we introduce a requirements engineering framework for distributed systems. It describes a set of patterns, each capturing a typical class of functional requirements. Based on these patterns, we develop a model-based method to elicit and document requirements. The first contribution mainly addresses the first challenge.

Our second contribution is a model-based and pattern-based process for managing security risks during requirements engineering. We provide methods for context establishment and data flow analysis, asset identification, risk identification, risk analysis and evaluation, and risk treatment. We describe patterns of incidents and controls which serve as an input for the method. For the description of these patterns, we develop templates as a unified description format using a level of abstraction that make them applicable during requirements engineering. All results are documented in a risk model. The model holds references to the requirements model, thus ensuring consistency and traceability. The second contribution addresses challenges (2)-(5). To address the sixth challenge, we provide tool support as powerful as possible for applying our method. For example, we provide graphical editors to maintain the models and algorithms to automize steps. Furthermore, we define validation conditions for each step that can be partially checked automatically based on the created models. The conditions ensure that errors in applying the methods can be detected as early as possible. To validate our contributions, we conduct two case studies: (i) A smart parking application and (ii) a small payment service.