ArticlePDF Available

Abstract and Figures

In order to avoid the high impacts of software vulnerabilities, it is necessary to specify security requirements early in the development on a detailed level. Current approaches for security requirements engi-neering give insufficient support for refining high-level requirements to a concrete and assessable level. Furthermore, reuse mechanisms for these detailed requirements are missing. This paper proposes a web security model based on experiences with other quality models that is used in a security requirements engineering approach. The model provides (1) a means for refinement and (2) a requirements repository for reuse. The approach is illustrated with an example involving the Tomcat servlet container.
Content may be subject to copyright.
A Security Requirements Approach
for Web Systems?
Stefan Wagner, Daniel Mendez Fernandez, Shareeful Islam, and Klaus
Technische Universit¨at M¨unchen
Software & Systems Engineering
Abstract. In order to avoid the high impacts of software vulnerabilities,
it is necessary to specify security requirements early in the development
on a detailed level. Current approaches for security requirements engi-
neering give insufficient support for refining high-level requirements to a
concrete and assessable level. Furthermore, reuse mechanisms for these
detailed requirements are missing. This paper proposes a web security
model based on experiences with other quality models that is used in a
security requirements engineering approach. The model provides (1) a
means for refinement and (2) a requirements repository for reuse. The
approach is illustrated with an example involving the Tomcat servlet
1 Introduction
Malicious attacks on software systems are a topic with high public visibility as
average users can be affected. The level of vulnerabilities is still high today. The
CERT1reports of 6,058 total vulnerabilities for the first 9 months of 2008. These
attacks have a strong financial impact. In last year’s E-Crime Watch Survey2, it
is stated that on average for each company security attacks result in a monetary
loss of $456,700 in 12 months.
Therefore, software security is still a large and important problem in practice.
It not only affects financial aspects but also ethical issues such as privacy. Hence,
it is an important goal in software development to produce secure systems. This
especially holds for web systems that are usually accessible in public networks.
Secure web systems begin with the specification of security requirements. In
order to become effective, they need to be clear and precise so that they are a real
guidance for their implementation. This way, vulnerabilities can be prevented or
at least reduced.
?This work has been supported in part by the German Federal Ministry of Education
and Research (BMBF) in the project QuaMoCo (01 IS 08023B) and the German
Academic Exchange Service (DAAD).
Problem Despite the importance of high-quality security requirements for web
systems, in practice they are often not well documented or not documented at
all. Quality in general and security in particular are concepts with many facets
and aspects. Hence, formulating precise requirements is difficult and elaborate.
First, there is no methodological guidance for refining high-level security
requirements such as confidentiality or integrity to a concrete and assessable
level. The refinement of security requirements is often complicated by many
reasons such as by unavailable end users. This especially is true for systems that
are distributed within a huge market, as it is the case for many web systems.
Second, it is often unclear how reuse of requirements can be properly integrated
in the development process. It is economically questionable to write detailed
security requirements for each system from scratch.
Contribution The main contribution of this paper is an approach for security
requirements engineering for web systems that mitigates the above mentioned
problems. It uses an explicit and detailed security model as a knowledge repos-
itory for the reuse of requirements and their refinement. This security model
builds on experiences with other quality models and documents in detail what
security means in a given setting. We use the model in the approach to support
two steps in particular: (1) deriving misuse cases based on the modelled attack
patterns and (2) refinement of the high-level misuse cases to assessable, low-level
Related Work In recent years much work has been done considering security
requirements and related engineering processes. SQUARE [1] and SREP [2] de-
scribe activities to elicit and analyse security requirements. Misuse case driven
approaches also contribute to the security requirements process [3]. Our approach
builds on that and adds an activity-based security model as means for refinement
and reuse. Although there exist many approaches for RE that are specifically
elaborated for web systems [4], approaches that address the elicitation and re-
finement of security requirements are still missing. A similar situation exists with
quality models. There are several interesting approaches involving web quality
models, e.g. [5, 6]. However, none of these considers security explicitly.
2 Web Security Model
Quality models describe in a structured way what quality of software means. We
introduce activity-based quality models and propose the web security instance
that we use in the requirements approach.
2.1 Activity-Based Quality Models
We use the term quality model here in the sense of a quality definition model from
[7], i.e. quality models define what quality is for a software system. However, in
practice this is often reduced to single metrics such as number of defects or high-
level descriptions as given by the ISO 9126 [8]. These existing quality models
have broadly acknowledged problems [9].
We have proposed to use activity-based quality models (ABQM) [10, 11] in
order to address the shortcomings of existing quality models. The idea is to avoid
using high-level “-ilities” for defining quality but to break it down into detailed
facts and their influence on activities performed on and with the system. In
addition to information about the characteristics of a system, the model contains
further important facts about the process, the team and the environment and
their respective influence on activities.
For ABQMs, an explicit meta-model was defined in order to characterise the
quality model elements and their relationships. Four elements of the meta-model
are most important: Entity,ATTRIBUTE,Impact and Activity. An entity can be any
thing, animate or inanimate, that can have an influence on the software’s quality,
e.g. the source code of a method or the involved testers. These entities are charac-
terised by attributes such as STRUCTUREDNESS or CONFORMITY. The combination of
an entity and an attribute is called a fact. We use the notation [Entity |ATTRIBUTE]
for a fact. These facts are assessable either by automatic measurement or by
manual review. If possible, we define applicable metrics for measuring the facts
inside the ABQM. An influence of a fact is then specified by an Impact. The
impact on an Activity can be positive or negative. An activity is anything that
is done with the system. For example, redundant methods (code clones) in the
source code render modifications more difficult and elaborate. This is expressed
in the model as [Method |REDUNDANCY]
The model does not only contain these impacts of facts on activities but
also the relationships among these. Facts as well as activities are organised in
hierarchies. A top-level activity Activity has sub-activities such as Use,Maintenance
or Administration. In realistic quality models, these are then further refined.
Having defined all these entries in the ABQM, we can specify which activities
we want to support and which influencing facts need to be considered. In terms
of the above example, if we want to support the activity Modification, we know
that we need to inspect the redundancy of methods.
2.2 The Web Security Instance
For handling web security requirements, we need to create a web security in-
stance of the ABQM. Most important in this instance is to add attacks to the
activity tree. These are activities that need to be negatively influenced. First,
we have to differentiate between anticipated attacks and unanticipated attacks.
A major problem in software security is that it is impossible to know all attacks
that the system will be exposed to. This is the case because new attacks are
developed every day. Hence, to assure quality, we need to employ two strategies:
(1) prepare the system against anticipated attacks and (2) harden the system
in general to avoid other vulnerabilities. For the classification of the attacks,
there are several sources possible. We rely on the open community effort Com-
mon Attack Pattern Enumeration and Classification (CAPEC) [12] that is led
by the U.S. Department of Homeland Security. In the CAPEC, existing attack
patterns are collected and classified. The attacks are organised in a hierarchy
that is adapted in the activities tree (see Fig. 1).
Abuse of
Data Leakage
Data Structure
Exploitation of
Exploitation of
Injection Physical Attack Probabilistic
Spoofing Time and State
Data Attack Exploitation Resource
Fig. 1. The upper layers of the attack sub-tree of the activity tree
The creation of the facts tree is far more complicated. The facts tree needs
to contain the available knowledge about characteristics of the system, its envi-
ronment and the organisation that influence the described attacks. We employed
various sources for collecting this knowledge including the ISO/IEC 27001 [13],
the web guidelines3, OWASP [14], and the Sun Secure Coding Guidelines for
the Java Programming Language [15]. However, two main sources were used be-
cause they constitute large community efforts and hence provide consolidated
knowledge: specific parts of the Common Criteria (CC) [16] and the Common
Weakness Enumeration (CWE) [17]. The Common Criteria describe require-
ments on a system that should ensure security with a focus on what the system
“shall do”. The CWE looks at security from the other direction and describes
reoccurring weaknesses in software systems that lead to vulnerabilities that are
exploited by attacks. Therefore, these two sources combined give a strong basis
for the facts tree.
We cannot describe the incorporation of the sources in all details in this paper
but we give some examples on how knowledge from the sources has been modelled
in our security model. For this, we use a sub-tree of the fact tree for the system
as depicted in Fig. 2. The system consists of Data and Functionality. Furthermore,
it has Dynamics and a Static Structure. These entities have then again children.
For example, data can be a Cookie or an HTTP Request. Interesting functionality
can be Cryptographic Support or File Handling.
Many of the entries in the quality model that have their origin in the Common
Criteria are modelled as a part of Functionality because they mainly describe be-
havioural aspects that nevertheless are important for security. An example that
is shown in Fig. 2 is the cryptographic support of the system. Following the
CC, this can be decomposed into Cryptographic Key Management and Cryptographic
Operation. A further part of Cryptographic Key Management is the Cryptographic Key
Generation. The CC defines a requirement for that key generation that it shall be
Support File Handling Ressource
Allocation Web Page
Static StructureFunctionality Dynamics
Cookie HTTP Request
Fig. 2. Example entries of the system sub-tree from the fact tree
in accordance with a specified algorithm and specified key sizes. In the model, we
express that by using the attribute APPROPRIATENESS for Cryptographic Key Genera-
tion. The resulting fact [Cryptographic Key Generation |APPROPRIATENESS]is textually
described by “The system generates cryptographic keys in accordance with a
specified cryptographic key generation algorithm and specified cryptographic
key sizes that meet a specified list of standards.” Unfortunately, the CC does
not contain any description of impacts. This would make the standard more use-
ful because the motivation to use these requirements would be higher. Hence, we
complete the information using other sources. In this case, the CAPEC contains
possible solutions and mitigations in the description of the cryptanalysis attack
that includes the recommendation to use proven cryptographic algorithms with
recommended key sizes. Therefore, we include the corresponding negative impact
of [Cryptographic Key Generation |APPROPRIATENESS]on Cryptanalysis.
In contrast to the CC, the Common Weakness Enumeration mainly provides
characteristics of the system and especially the kind of code that should be
avoided. We include these characteristics into the model in this negative way
with a positive influence on the attacks, i.e. making attacks easier. Another
possibility is to reformulate the weaknesses as strength that are needed with
negative influence on attacks. We used both possibilities depending on which
option was more straightforward to model.
Several weaknesses in the CWE are not aiming at specific attacks but describe
characteristics that are indicators for possible vulnerabilities. We model these
as facts that have an impact on unanticipated attacks. An example from the
CWE that is in our security model is dead code. Several parts of the code can
be superfluous such as variables, methods or complete classes. For a variable, we
can model that as a positive impact of [Variable |SUPERFLUOUSNESS]on Unanticipated
3 Security Requirements Approach
A requirements engineering (RE) process in general aims at systematically and
effectively defining requirements that are aligned with the needs of all relevant
stakeholders. According to [18] a RE process consists of the activities elicitation,
analysis (refining requirements over several stages) and finally validation. What
specific fine-grained techniques and approaches are used for each of these activ-
ities strongly depends on the application domain. We proposed a requirements
approach that makes use of the ABQM to reuse and refine requirements in [19].
Figure 3 illustrates the instance of the approach for the application domain of
security requirements for web systems. The figure gives an overview of the ac-
tivities, while the tasks within each of the activities are chosen according to the
least common denominator of known security-specific RE approaches. We refer
in particular to the Security Requirements Engineering Process (SREP) [2], the
Security Quality Requirements Engineering Process (SQUARE) [1] and deriva-
tions of these approaches that integrate misuse cases [3].
Activity-based Quality Model
(Attacks) Entities
Impact (+/-)
- Elicit Goals, Services,
Assets & Policies
- Derive Security Goals
- Identify Use Cases
- Identify Threats, Vulnerabilities &
Develop Misuse Cases
- Derive quantified Security Requirements
- Control Requirements
- Update ABQM
Elicitation Analysis Validation
Fig. 3. Integration of the activity-based security model into an RE process
Elicitation During the requirements elicitation high level business requirements
and/or market needs are collected. These represent high-level, initially stated,
requirements. In particular, business requirements encompass (1) goals that have
to be achieved by the final product, (2) services and assets that are offered and
maintained by the product and (3) policies that might restrict its functionality.
This information provides a sufficient basis for deriving security goals.
Analysis The requirements analysis aims at refining the business requirements
to measurable ones. The first step of this refinement procedure consists of the
identification of use cases. They represent the system’s external behaviour by
describing scenarios — specific sequences of interaction between users and the
system. Because for security requirements also undesired use is relevant, misuse
cases are derived. A misuse case can be seen as the inverse of a use case that
shows an undesirable sequence of interactions, i.e. they describe how a specific
attack can be performed.
The last step within analysis consists in deriving more concrete security re-
quirements. These requirements demand specific properties (attributes) of the
system and its environment that are meant to prevent the attack possibilities
described within the misuse cases. For example, if a misuse case describes a
specific attack that embeds malicious code into the system, derived security re-
quirements could demand specific properties of sensitive data that is transmitted
in encrypted connections.
However, as already described, a major challenge consists not only in identi-
fying possible misuse cases but also in deriving security requirements from the
scenarios that address the prevention of such attacks. The quality model there-
fore serves as a knowledge repository that supports the reuse of requirements for
the purpose of identifying and refining them. The activities within the quality
model correspond to the scenarios (use cases and misuse cases) that are elicited
and refined. The entities correspond to the system elements that are constrained
by the requirements in terms of demanding specific properties of these elements,
while the attributes of the entities correspond to such properties.
In this sense, the ABQM can be used to identify misuse cases by harvesting
relevant attack scenarios from the activity tree. To derive quantified security re-
quirements from these misuse cases, the ABQM is also used. As it also defines the
relations between the scenarios and corresponding (e.g. technological) entities of
a system, we only need to follow the impact of an activity to the corresponding
entities to derive detailed requirements. These detailed requirements constrain
the system’s entities in a measurable way. In this case measurable does not nec-
essarily mean automatically measurable. Also manual assessments like reviews
and inspections can be used to evaluate quality requirements. This tackles the
problem that requirements engineers do not need to have all technological possi-
bilities in mind for each scenario. For example, attack scenarios that exclusively
refer to web technologies can be grouped together [2]. As a whole, the analy-
sis process based on the ABQM supports sufficient completeness of the quality
requirements as this repository can be taken as the backbone of requirements
Validation The validation aims at proving and controlling requirements accord-
ing to chosen (quality) criteria. In particular, the goal is to avoid and resolve
conflicted, under-specified, unfeasible, incomplete and incorrect requirements.
To find and correct such requirements, the ABQM can be used. For example,
two requirements are conflicted (make contrary assertions), if they constrain the
same system entity in a different way. Also under-specified requirements can be
detected. If a requirement is under-specified, it is impossible to find an impact to
a certain system entity. Also the correctness of the requirements can be tackled,
because all detailed requirements are derived from business requirements and
can be traced back to them.
Finally, requirements validation also includes updating the ABQM with re-
quirements that are elaborated in addition to ones that are already stored within
the ABQM. This update consists of two steps. First, the activity tree undergoes
an update by inserting new scenarios, such as misuse cases that are not yet
addressed by the activity tree. Second, the entities are inserted by adding the
entities that are constrained with specific quality attributes.
4 Example
To further illustrate our approach, we use the servlet container Tomcat 6.0 4and
develop security requirements for it. Tomcat is the reference implementation of
the Java servlet and JSP specification and provides support to deliver dynam-
ically assembled HTTP responses based on an HTTP request. We follow the
RE process introduced in the previous section, while describing only exemplary
requirements for reasons of space limitations.
Elicitation We concentrate on the most important high level goal for Tomat:
The system allows the user to send any request and get a response. From this
goal the elementary services request and response are derived in terms of that a
server has to respond to every possible sequences of HTTP requests from a client.
Several critical assets are possible but we assume that only sensitive information
is important in our example. Security goals are now identified to protect each
of the identified services and assets and to attain the defined goals. The derived
security goals are: (a) The system services shall be available for the subscript
user and (b) the system shall ensure privacy, integrity and availability of the
sensitive data communicating among the involved legitimate parties.
Analysis Based on the elicited business requirements we examine the threats
and vulnerabilities from our model. We use the identified services as a basis for
identifying the relevant use case (request & response). There are several pos-
sible anticipated attacks for this use case that violate the confidentiality and
integrity of sensitive information. For instance, injection attacks that cause the
unauthorised access in an established session so that attackers can view, cap-
ture and modify any data that is communicated within this session. Therefore,
“attack by injection” is considered as a misuse case. Figure 4 illustrates how
from the ABQM misuse cases are derived. The left side of the figure represents
the attack activities contained in the model, the right side the identified misuse
cases that set the attacks in context to the relevant use cases. In the model, this
attack is influenced by the fact [Directive |SANITATION]and [Processing |SANITATION].
Hence, the requirements have to explicitly include that user input of directives
and processing of data needs to be validated before it is used. In a similar way,
we analyse the other attacks such as resource attacks with their related facts.
Activity Tree of the ABQM (Attacks Activities) Misuse Cases (Attack Scenarios)
Fig. 4. Using the ABQM for deriving misuse cases
At this stage security requirements are specified based on the identified at-
tacks and related facts from the model. These security requirements are detailed
enough to be able to assess their fulfilment directly in the code, e.g. by reviews.
The elicited security requirements can be textually specified like in the following:
The software shall sanitise user-controllable input for content before it is
prepared in output that is used as a web page. Unsanitized special elements
that have control implications in web pages, such as HTML tags or mouse
events, are interpreted as control characters that execute in violation of the
client’s trust in the application or system. This weakness usually enables
cross-site scripting attacks in web applications.
The system shall verify user inputs that are assumed to be immutable but
are actually externally controllable, such as a cookie.
Validation As our short list of the above requirements does not contain any
conflicts, the validation is rather simple. However, there are further threats which
are not currently covered in our activity tree. For example, an attacker can have
the opportunity to view or modify the sensitive data by unauthorised physical
means. This needs to be refined without specific guidance from the ABQM but
can then be fed back into it. This way, this new kind of attack is available in the
requirements elicitation for the next project.
5 Conclusions
Because of the importance of software security in web systems, we need to con-
sider security aspects from the very beginning in the requirements engineering
process. The basis of our security requirements approach consists of an activity-
based security model that uses experiences with such models in other areas. The
way of modelling allows to break down security to assessable and partly directly
measurable characteristics of the system, its environment and the organisation.
The activities in the model consist of common attack patterns that need to be
prevented and thereby deliver the means for refining high-level security goals to
such concrete and assessable, but necessarily measurable characteristics. More-
over, the model can also serve as a comprehensive repository that fosters the
reuse of security requirements.
An example was conducted with the Tomcat servlet container. It showed that
the approach is feasible in principle and that there is a potential for preventing
vulnerabilities by specifying more concrete requirements. We plan to perform
industrial case studies with the security model in order to explore the benefits
and limitations of the approach. Finally, the UMD by Donzelli and Basili [20]
will be analysed for a potential extension of our approach because it contains
some additional aspects that might be useful for requirements elicitation.
1. Mead, N., Steheny, T.: Security quality requirement engineering methodology. In:
Proc. Workshop on Software Engineering for Secure Systems (SESS ’05). (2005)
2. Mellado, D., Medina, E., Piattini, M.: Acommon criteria based security require-
ments engineering process for the development of secure information system. Com-
puter standards & interfaces 29 (June 2007) 244–253
3. Sindre, G., Opdahl, A.: Eliciting security requirements with misuse case. Require-
ments Engineering Journal 44(10) (June 2005) 34–44
4. Koch, N., Escalona, J.: Requirements engineering for web applications - a com-
parative study. Journal of Web Engineering 2(3) (2004)
5. Ruiz, J., Calero, C., Piattini, M.: A Three Dimensional Web Quality Model. Vol-
ume 2722 of LNCS. Springer-Verlag (2003)
6. Malak, G., Badri, L., Badri, M., Sahraoui, H.: Towards a Multidimensional Model
for Web-Based Applications Quality Assessment. Volume 3182 of LNCS. Springer-
Verlag (2004)
7. Deissenboeck, F., Juergens, E., Lochmann, K., Wagner, S.: Software quality mod-
els: Purposes, usage scenarios and requirements. In: Proc. 7th International Work-
shop on Software Quality (WoSQ ’09), IEEE Computer Society (2009)
8. : ISO 9126: Product Quality – Part 1: Quality Model (2003)
9. Kitchenham, B., Pfleeger, S.L.: Software quality: The elusive target. IEEE Softw.
13(1) (1996) 12–21
10. Deissenboeck, F., Wagner, S., Pizka, M., Teuchert, S., Girard, J.F.: An activity-
based quality model for maintainability. In: Proc. 23rd International Conference
on Software Maintenance (ICSM ’07), IEEE Computer Society (2007) 184–193
11. Winter, S., Wagner, S., Deissenboeck, F.: A comprehensive model of usability.
In: Proc. Engineering Interactive Systems 2007 (EIS ’07). Volume 4940 of LNCS.,
Springer (2008)
12. Homeland Security: Common attack pattern enumeration and classification
(CAPEC). Available Online at Accessed in October 2008
13. : ISO/IEC 27001: Information technology – Security techniques – Information
security management systems – Requirements (2005)
14. Wiesmann, A., van der Stock, A., Curphey, M., Stirbei, R., eds.: A Guide to
Building Secure Web Applications and Web Services. OWASP (2005)
15. Sun Microsystems: Secure coding guidelines for the java programming language,
version 2.0. Available Online at
16. : Common criteria for information technology security evaluation, version 3.1.
Available Online at
17. Homeland Security: Common weakness enumeration (CWE). Available Online at Accessed in October 2008
18. Wiegers, K.E.: Software Requirements. Microsoft Press, Redmond, WA, USA
19. Wagner, S., Deissenboeck, F., Winter, S.: Managing quality requirements using
activity-based quality models. In: WoSQ ’08: Proceedings of the 6th international
workshop on Software quality, New York, NY, USA, ACM (2008) 29–34
20. Donzelli, P., Basili, V.: A practical framework for eliciting and modeling system
dependability requirements: Experience from the NASA high dependability com-
puting project. The Journal of Systems and Software 79 (2006) 107–119
... These properties are essentially describing quality patterns. In recent work, such quality models are used to define how to achieve quality in a software system [4,5]. All these quality models focus on software product quality by defining concepts related to the software product itself as opposed to processrelated concepts. ...
... They describe which fact has an influence on an activity. For denoting the previous example , the following notation is used: [ ABQMs have been used for modeling maintainability [3], usability [9], and security [4] . In these case studies existing knowledge in form of guidelines, checklists , standards, etc. has been modeled as an ABQM. ...
... In total, 205 different requirements were analyzed and modeled. To model the activity hierarchy, we used the scheme proposed by Wagner et al. [4]. The constructed entity types were categorized according to the definitions above. ...
In software systems recurring patterns are often observed and have been collected and documented in different forms, as for ex-ample in development guidelines. These well-known patterns are utilized to support design decisions or to automatically detect flaws in software systems. For the most part, these patterns are related to software qual-ity issues and can also be be referred to as software quality patterns. These quality patterns have to be communicated to the various roles contributing to the development of software, e.g., to software architects or developers. Hence, a comprehensive scheme to categorize the various types of patterns is needed to support effective communication. The cat-egories should be shaped so that each category can be communicated to a single organizational role in a company. Since each pattern refers to a specific concept of the software system, a categorization based on sys-tem modeling concepts is used. The presented categorization scheme is grounded on activity-based quality models that are already used to col-lect different patterns related to the quality of software systems. Based on two case studies the applicability of the categorization scheme is shown. Real-world models were categorized using the scheme and the resulting distribution of entities within the different classes is discussed.
... The quality attributes we use in this paper are the activities performed on and with the system, which are derived from activity-based quality models [12]. In the area of security, we use a hierarchy of attacks as activities [27]; in this case activities that should be prevented. ...
... In [12], Deissenboeck et al. propose a quality model (ABQM) that tackles this problem by breaking quality attributes into entities, their properties, and their influence on activities. In [27] we used the ABQM approach for modelling security but with a focus on security requirements. ...
Software development needs continuous quality control for a timely detection and removal of quality problems. This includes frequent quality assessments, which need to be automated as far as possible to be feasible. One way of automation in assessing the security of software are application scanners that test an executing software for vulnerabilities. At present, common quality assessments do not integrate such scanners for giving an overall quality statement. This paper presents an integration of application scanners into a general quality assessment method based on explicit quality models and Bayesian nets. Its applicability and the detection capabilities of common scanners are investigated in a case study with two open-source web shops.
... The approach described in this paper is based on activitybased quality models as proposed in [7]. In [21,22] we described how to use these quality models for refining quality requirements and how to incorporate them into a general requirements process. In contrast, this paper investigates requirements reuse. ...
... Project A was identified as the oldest and was hence chosen to be the training project. As guideline for modeling the security requirements the ABQM on security [22] was used. It provides a basic structure on how security requirements can be modeled. ...
A reoccurring problem in software engineering constitutes ensuring sufficient completeness of requirements specifica-tions with economically justifiable efforts. Formulating pre-cise quality requirements and especially security require-ments is elaborate as they depend on many stakeholders and technological aspects that are often unclear in early project phases. Threats that may have a severe impact on the soft-ware product are sometimes not even known. One approach to tackle this situation is reusing quality requirements, be-cause they are to a high degree similar in different software products. The effect can be higher quality while at the same time saving time and budget. Quality models are a way to explicitly specify quality. Based on activity-based quality models an approach for spec-ifying reusable quality requirements in early project phases is proposed that also allows a direct derivation of suitable quality requirements for new projects. The applicability of this approach and the resulting reuse potential is investi-gated in a case study, which concentrates on the security requirements of six industrial projects.
... The activity-based quality model was successfully applied to usability [30], security [31], and service-oriented architecture [32] before Wagner et al. distilled a comprehensive activity-based meta-model in the scope of the Quamoco project [33,34]. In parallel, the original use case of the activity-based quality model, which focused on maintainability, received extensive tool support [35,36] contributing evidence to the operationalization of quality models in practice [37]. ...
Full-text available
High-quality requirements minimize the risk of propagating defects to later stages of the software development life cycle. Achieving a sufficient level of quality is a major goal of requirements engineering. This requires a clear definition and understanding of requirements quality. Though recent publications make an effort at disentangling the complex concept of quality, the requirements quality research community lacks identity and clear structure which guides advances and puts new findings into an holistic perspective. In this research commentary, we contribute (1) a harmonized requirements quality theory organizing its core concepts, (2) an evaluation of the current state of requirements quality research, and (3) a research roadmap to guide advancements in the field. We show that requirements quality research focuses on normative rules and mostly fails to connect requirements quality to its impact on subsequent software development activities, impeding the relevance of the research. Adherence to the proposed requirements quality theory and following the outlined roadmap will be a step toward amending this gap.
... 시간성(시간에 따라 변하는 특성), 환경요인 등 3가지 범주가 활용된다[13].위험도는 산정 방식에 있어 객관성이 유지되어야 하고 실제 적용이 용이해야 한다. 이를 위해 CVSS 산정 시에는 관련 업계나 전문가들의 투표하는 기법을 도입하기도 하나, 이 역시 투표에 참여하는 기관이나 전문가 의 주관적인 요소가 많이 포함될 수 있다. ...
Recently, as modern Internet uses mashups, Web 3.0, JavaScript/AJAX widely, the rate at which new vulnerabilities are being discovered is increasing rapidly. It can subsequently introduce big security threats. In order to efficiently mitigate these web application vulnerabilities and security threats, it is needed to rank vulnerabilities based on severity and consider the severe vulnerabilities during a specific phase of software development lifecycle (SDLC) for web applications. In this paper, we have first verified whether the risk rating methodology of OWASP Top 10 vulnerabilities is a reasonable one or not by analyzing the vulnerability data of web applications in the US National Vulnerability Database (NVD). Then, by inspecting the vulnerability information of web applications based on OWASP Top-10 2010 list and CWE (Common Weakness Enumeration) directory, we have mapped the web-related entries of CWE onto the entries of OWASP Top-10 2010 and prioritized them. We have also presented which phase of SDLC is associated with each vulnerability entry. Using this approach, we can prevent or mitigate web application vulnerabilities and security threats efficiently.
... These results further confirm evidence from the literature. We can support the indication from our case study in [11] that the requirements are more complete. Furthermore, we confirm Doerr et al. [1] that using a quality model results in more complete and well testable requirements. ...
Conference Paper
Full-text available
Quality requirements are an often neglected part of requirements engineering. If specified at all, they tend to be either too abstract or very technical and without a rationale. In this paper, we evaluate a quality requirements approach, which makes use of activity-based quality models. To this end, we conduct a comparative case study at Siemens in which we compare the requirements resulting from applying our quality model with the requirements previously used in the same environment. The results indicate an improvement of the requirements regarding, e.g., structured ness and trace ability, but also that the productivity perceived by the industry participants could not be increased. The study thus gives first insights into strengths and limitations of using a quality model in an industrial requirements engineering process.
... This classification has been argued to lack clear semantics, e. g. by Jung et al. [15]. To overcome this shortage, activitybased quality models (e. g. [9] [29] [28]) were introduced. Activities , like programming or maintaining software, come with natural decomposition semantics because of the possibility to divide the activities into smaller parts (which are called actions in Activity Theory, cf. ...
Service-oriented architectures (SOAs) are well established as an architectural paradigm for distributed systems. With software systems becoming more and more complex over time, quality assurance becomes increasingly important. A clear understanding of software quality for SOA is therefore crucial in order to assure quality in the long run. In this paper, we present a unifying meta-model to describe the quality of service-oriented systems as an enhancement of the Quamoco meta-model. To put these modeling concepts into practice, we present examples from an initial quality model for SOA-based systems, which is based on empirical results from other sources in the SOA quality community. By integrating these sources of information, similarities as well as contradictions within and between the various models for SOA quality are made transparent. This is the baseline for defining a comprehensive SOA quality model. In addition, this approach represents SOA's distinguishing features regarding quality modeling as first-class model entities to reduce modeling effort while increasing model expressiveness.
... The second example describes that the guardedness of the physical interface against unintentional activation influences the probability of error in executing actions via the GUI. Similar to the model of usability, Wagner et al. [28] developed an ABQM for security. As activities they used attack patterns, describing misuse cases an attacker conducts on the system. ...
Assuring high quality of software is crucial, but a highly complex topic. It is intermingled with most disciplines of software engineering, which have developed their own quality assurance approaches. However, they lack a common foundation, which leads to loss of information between the disciplines and requires additional tracking effort. There is no comprehensive framework to describe all different concepts relating to software quality in a common way. In this paper we present a general quality model, providing the possibility to describe very different concepts related to quality. We show that our quality model is able to integrate the various concepts found in standards, quality models, guidelines, and static code checker rules. Furthermore, we show that the quality model is able to describe the interrelations of disciplines, like requirements engineering and software test, to software quality. With this quality model, we provide a common foundation for concepts related to software quality, enabling consistency and continuity of quality-related information during software development.
... A case-study adopting a similar approach has been conducted in the context of security [9]. In this case-study the stakeholder " attacker " and its intention to attack the system – in our case Tomcat 6.0 – was considered. ...
Conference Paper
Full-text available
In this paper ongoing research for a PhD-thesis is presented. The objective of this thesis is to develop an approach for engineering quality requirements. Quality requirements are an important part of requirements on software and their thorough specification is a prerequisite for the successful development of high quality systems. The presented approach relies on a quality model, that defines software quality and that serves as a structured knowledge-base. The quality model is integrated with an use-case based approach for eliciting and analyzing quality requirements. This way an effective communication with stakeholders as well as the quantification of quality requirements is assured.
In this chapter, after discussing existing quality models and putting them into context, I introduce basics of software measures and details of the ISO/IEC 25010 quality model. The main part of this chapter constitutes the quality modelling approach developed in the research project Quamoco, how to maintain such quality models and three detailed examples of quality models.
Full-text available
Use cases have become increasingly common during requirements engineering, but they offer limited support for eliciting security threats and requirements. At the same time, the importance of security is growing with the rise of phenomena such as e-commerce and nomadic and geographically distributed work. This paper presents a systematic approach to eliciting security requirements based on use cases, with emphasis on description and method guidelines. The approach extends traditional use cases to also cover misuse, and is potentially useful for several other types of extra-functional requirements beyond security.
Conference Paper
Full-text available
Software quality models are a well-accepted means to support quality management of software systems. Over the last 30 years, a multitude of quality models have been proposed and applied with varying degrees of success. Despite successes and standardisation efforts, quality models are still being criticised, as their application in practice exhibits various problems. To some extent, this criticism is caused by an unclear definition of what quality models are and which purposes they serve. Beyond this, there is a lack of explicitly stated requirements for quality models with respect to their intended mode of application. To remedy this, this paper describes purposes and usage scenarios of quality models and, based on the literature and experiences from the authors, collects critique of existing models. From this, general requirements for quality models are derived. The requirements can be used to support the evaluation of existing quality models for a given context or to guide further quality model development.
Conference Paper
Full-text available
We propose a model, whose primary objective is web quality assessment. Furthermore, the model can be used for the classification of web metrics, and the classification of web research works.
Managing requirements on quality aspects is an important issue in the development of software systems. Difficulties arise from expressing them appropriately what in turn results from the difficulty of the concept of quality itself. Building and using quality models is an approach to handle the complexity of software quality. A novel kind of quality models uses the activities performed on and with the software as an explicit dimension. These quality models are a well-suited basis for managing quality requirements from elicitation over refinement to assurance. The paper proposes such an approach and shows its applicability in an automotive case study.
From the Publisher:Without formal, verifiable software requirements -- and an effective system for managing them -- the programs that developers think they've agreed to build often will not be the same products their customers are expecting. In Software Requirements, Second Edition, requirements engineering authority Karl Wiegers amplifies the best practices presented in his original award-winning text -- now a mainstay for anyone participating in the software development process. In this book, you'll discover effective techniques for managing the requirements engineering process all the way through the development cycle -- including dozens of techniques to facilitate that all-important communication between users, developers, and management. This updated edition features new case examples, anecdotes culled from the author's extensive consulting career, and specific Next Steps for putting the book's process-improvement principles into practice. You'll also find several new chapters, sample documents, and an incisive troubleshooting guide.
In order to develop security critical Information Systems, specifying security quality requirements is vitally important, although it is a very difficult task. Fortunately, there are several security standards, like the Common Criteria (ISO/IEC 15408), which help us handle security requirements. This article will present a Common Criteria centred and reuse-based process that deals with security requirements at the early stages of software development in a systematic and intuitive way, by providing a security resources repository as well as integrating the Common Criteria into the software lifecycle, so that it unifies the concepts of requirements engineering and security engineering.
The dependability of a system is contextually subjective and reflects the particular stakeholder’s needs. In different circumstances, the focus will be on different system properties, e.g., availability, real-time response, ability to avoid catastrophic failures, and prevention of deliberate intrusions, as well as different levels of adherence to such properties. Close involvement from stakeholders is thus crucial during the elicitation and definition of dependability requirements. In this paper, we suggest a practical framework for eliciting and modeling dependability requirements devised to support and improve stakeholders’ participation. The framework is designed around a basic modeling language that analysts and stakeholders can adopt as a common tool for discussing dependability, and adapt for precise (possibly measurable) requirements. An air traffic control system, adopted as testbed within the NASA High Dependability Computing Project, is used as a case study.
Conference Paper
Maintainability is a key quality attribute of successful software systems. However, its management in practice is still problematic. Currently, there is no comprehensive basis for assessing and improving the maintainability of software systems. Quality models have been proposed to solve this problem. Nevertheless, existing approaches do not explicitly take into account the maintenance activities, that largely determine the software maintenance effort. This paper proposes a 2-dimensional model of maintainability that explicitly associates system properties with the activities carried out during maintenance. The separation of activities and properties facilitates the identification of sound quality criteria and allows to reason about their interdependencies. This transforms the quality model into a structured and comprehensive quality knowledge base that is usable in industrial project environments. For example, review guidelines can be generated from it. The model is based on an explicit quality metamodel that supports its systematic construction and fosters preciseness as well as completeness. An industrial case study demonstrates the applicability of the model for the evaluation of the maintainability of Matlab Simulink models that are frequently used in model-based development of embedded systems.
Conference Paper
Several approaches for quantitative evaluation of Web-based applications have proposed test-benches, checklists and tools. In this paper, we propose an evaluation approach that integrates and extends the various approaches proposed in this field. We have developed a list of over than 300 criteria and sub-criteria, which we classified using the ISO/IEC 9126 standard as a guide. These criteria represent a first basis for the development of a hierarchical quality model specific to Web-Based Applications. In order to refine our quality model, we followed a systematic approach using the GQM paradigm. A tool supporting our assessment approach has been developed. With this tool, we conducted an experience on several Web systems. The obtained results were rather encouraging. However, they have shown that more dimensions have to be considered to increase the reliability of our model. As a next step, we introduce a three-dimensional model where the initial model is one dimension. The two others represent respectively the life cycle processes and the Web applications domains.
Conference Paper
Use case diagrams (L. Jacobson et al., 1992) have proven quite helpful in requirements engineering, both for eliciting requirements and getting a better overview of requirements already stated. However, not all kinds of requirements are equally well supported by use case diagrams. They are good for functional requirements, but poorer at e.g., security requirements, which often concentrate on what should not happen in the system. With the advent of e- and m-commerce applications, security requirements are growing in importance, also for quite simple applications where a short lead time is important. Thus, it would be interesting to look into the possibility for applying use cases on this arena. The paper suggests how this can be done, extending the diagrams with misuse cases. This new construct makes it possible to represent actions that the system should prevent, together with those actions which it should support