No full-text available
To read the full-text of this research,
you can request a copy directly from the authors.
Reusing security requirements using an extended quality model
Abstract
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.
... Fabian et al. (2010) have devised and compared the methods involved in security requirements engineering but have not identified the need and the strategy for incorporating them into software projects to ensure security. Luckey et al. (2010) devised an extended quality requirements model to reapply security requirements but failed to identify software project critical security requirements and method to incorporate them into web based projects. Siy et al. (2007) represented an aspect-oriented requirements specification system for software product lines. ...
Managing non functional requirements has been a challenge onto software engineers for a long time. Throughout the years, numerous strategies and methods have been proposed to enhance their elicitation, documentation and approval. Similarly, security requirements emphatically impact the building configuration of complex IT frameworks comparatively as non-functional requirements. Both security building and software engineering furnish strategies to manage such necessities. Nonetheless, there is still a basic crevice concerning the joining of techniques for these two different fields. In this paper we close this crevice as for security prerequisites by proposing a technique that joins software engineering technologies with the best in class security engineering standards. An efficient quality requirement based software model with security requirements is developed by fusing Group Search Optimization and genetic algorithm in our proposed methodology.
... First work in response to the challenges in dealing with security requirements considers the use of quality models to reuse security requirements as they can indicate the social and technological implications of such requirements early on (see, e.g., [17]). However, we still have a limited understanding of how to integrate security requirements to evidently overcome the challenges. ...
Background] The rapidly changing business environments in which many companies operate is challenging traditional Requirements Engineering (RE) approaches. This gave rise to agile approaches for RE. Security, at the same time, is an essential non-functional requirement that still tends to be difficult to address in agile development contexts. Given the fuzzy notion of "agile" in context of RE and the difficulties of appropriately handling security requirements, the overall understanding of how to handle security requirements in agile RE is still vague. [Objective] Our goal is to characterize the publication landscape of approaches that handle security requirements in agile software projects. [Method] We conducted a systematic mapping to outline relevant work and contemporary gaps for future research. [Results] In total, we identified 21 studies that met our inclusion criteria, dated from 2005 to 2017. We found that the approaches typically involve modifying agile methods, introducing new artifacts (e.g., extending the concept of user story to abuser story), or introducing guidelines to handle security issues. We also identified limitations of using these approaches related to environment, people, effort and resources. [Conclusion] Our analysis suggests that more effort needs to be invested into empirically evaluating the existing approaches and that there is an avenue for future research in the direction of mitigating the identified limitations.
... Different approaches are available for gathering secure requirements, but unfortunately, they do not provide significant support for using these secure requirements at the later stages of the software development lifecycle. We believe that security requirements need equal attention at the later stages of development lifecycle as well so that the traceability and usability of the secure requirement may be ensured at later stages [10]. In [3], a survey has been conducted to know the support of existing SRE methods for security requirements. ...
... Interview data: The interview data reflects the findings of the questionnaire: Source code is the clear reusable entity in G and also mentioned frequently as reusable in U. Interpretation: These findings indicate that much of the potential for reuse is unleveraged in the two companies. Literature proposes reuse on a much wider scale from models to requirements (see, e.g., [47, 31, 53]). Reasons for this might be that artefacts of earlier development stages are not available, accessible, or considered useful. ...
Context Reuse can improve productivity and maintainability in software development. Research has proposed a wide range of methods and techniques. Are these successfully adopted in practice? Objective We propose a preliminary answer by integrating two in-depth empirical studies on software reuse at two large software-producing companies. Method We compare and interpret the study results with a focus on reuse practices, effects, and context. Results Both companies perform pragmatic reuse of code produced within the company, not leveraging other available artefacts. Reusable entities are retrieved from a central repository, if present. Otherwise, direct communication with trusted colleagues is crucial for access. Reuse processes remain implicit and reflect the development style. In a homogeneous infrastructure-supported context, participants strongly agreed on higher development pace and less maintenance effort as reuse benefits. In a heterogeneous context with fragmented infrastructure, these benefits did not materialize. Neither case reports statistically significant evidence of negative side effects of reuse nor inhibitors. In both cases, a lack of reuse led to duplicate implementations. Conclusion Technological advances have improved the way reuse concepts can be applied in practice. Homogeneity in development process and tool support seem necessary preconditions. Developing and adopting adequate reuse strategies in heterogeneous contexts remains challenging.
... Most commonly, we find quality models reduced to mere reference taxonomies or implicitly implemented in tools. As explicit and living artefacts, however, they can capture general knowledge about software quality, accumulate knowledge from their application in projects, and allow quality engineers to define a common understanding of quality in a specific context [54,23,31,52]. ...
Software quality models provide either abstract quality characteristics or concrete quality measurements; there is no seamless integration of these two aspects. Reasons for this include the complexity of quality and the various quality profiles in different domains which make it difficult to build operationalised quality models. In the project Quamoco, we developed a comprehensive approach for closing this gap. It combined constructive research, which involved quality experts from academia and industry in workshops, sprint work and reviews, with empirical studies. All deliverables within the project were peer-reviewed by two project members from a different area. Most deliverables were developed in two or three iterations and underwent an evaluation. We contribute a comprehensive quality modelling and assessment approach: (1) A meta quality model defines the structure of operationalised quality models. It includes the concept of a product factor, which bridges the gap between concrete measurements and abstract quality aspects, and allows modularisation to create modules for specific domains. (2) A largely technology-independent base quality model reduces the effort and complexity of building quality models for specific domains. For Java and C# systems, we refined it with about 300 concrete product factors and 500 measures. (3) A concrete and comprehensive quality assessment approach makes use of the concepts in the meta-model. (4) An empirical evaluation of the above results using real-world software systems. (5) The extensive, open-source tool support is in a mature state. (6) The model for embedded software systems is a proof-of-concept for domain-specific quality models. We provide a broad basis for the development and application of quality models in industrial practice as well as a basis for further extension, validation and comparison with other approaches in research.
... Knowledge Reuse (KR) reuses captured document knowledge in software processes (e.g., security requirements knowledge in requirements specifications can be reused in large projects [45]). Knowledge Sharing (KS) exchanges knowledge (e.g., requirements, frameworks, or design decisions) in SD among stakeholders of software projects. ...
... Most commonly, we find quality models reduced to just reference taxonomies or implicitly implemented in tools. As explicit and living artefacts, however, they can capture general knowledge about software quality, accumulate knowledge from applying them in projects and allow to define a common understanding of quality in a specific context [7], [18]- [20]. ...
Published software quality models either provide abstract quality attributes or concrete quality assessments. There are no models that seamlessly integrate both aspects. In the project Quamoco, we built a comprehensive approach with the aim to close this gap. For this, we developed in several iterations a meta quality model specifying general concepts, a quality base model covering the most important quality factors and a quality assessment approach. The meta model introduces the new concept of a product factor, which bridges the gap between concrete measurements and abstract quality aspects. Product factors have measures and instruments to operationalise quality by measurements from manual inspection and tool analysis. The base model uses the ISO 25010 quality attributes, which we refine by 200 factors and 600 measures for Java and C# systems. We found in several empirical validations that the assessment results fit to the expectations of experts for the corresponding systems. The empirical analyses also showed that several of the correlations are statistically significant and that the maintainability part of the base model has the highest correlation, which fits to the fact that this part is the most comprehensive. Although we still see room for extending and improving the base model, it shows a high correspondence with expert opinions and hence is able to form the basis for repeatable and understandable quality assessments in practice.
... Examples are developer communication, inappropriate skills, inadequate resources, staff retention, user communication, lack of training and company culture. Luckey et al. [23] use project parameters to describes projects in a repository of security requirements. They use these parameters to find relevant security requirements for reuse. ...
Requirements Engineering (RE) is a critical discipline mostly driven by uncertainty, since it is influenced by the customer domain or by the development process model used. We aim to investigate RE processes in successful project environments to discover characteristics and strategies that allow us to elaborate RE tailoring approaches in the future. We perform a field study on a set of projects at one company. First, we investigate by content analysis which RE artefacts were produced in each project and to what extent they were produced. Second, we perform qualitative analysis of semi-structured interviews to discover project parameters that relate to the produced artefacts. Third, we use cluster analysis to infer artefact patterns and probable RE execution strategies, which are the responses to specific project parameters. Fourth, we investigate by statistical tests the effort spent in each strategy in relation to the effort spent in change requests to evaluate the efficiency of execution strategies. Our results show no statistically significant difference between the efficiency of the strategies. In addition, it turned out that many parameters considered as the main causes for project failures can be successfully handled. Hence, practitioners can apply the artefact patterns and related project parameters to tailor the RE process according to individual project characteristics.
Today, when a company designs, develops and manufactures goods or services, it must not only target a high level of quality for the products to satisfy customers, but also comply with many standards and regulations. This is particularly true with transportation systems where we can name few famous standards and guidelines: the ISO 26262 [1] addresses the software functional safety in automotive, the ARP4754 [2] provides guidelines for the development of civil aircrafts, and the DO-178C addresses software safety [3] in aeronautics. Furthermore, these safety guidelines impose to the company to be at the state of the art for processes and methods, when designing and developing a new vehicle.In the context of automotive systems’ development, our research aims to strengthen and unify quality definition, assessment, control, or prediction activities for automotive embedded software. Thus, to resolve this problematic, first we have to explore quality concept, qualimetry -the science of quality quantification [4]-, and the state of the art about quality modeling for embedded software. The result is not only to popularize and synthetize the knowledge behind these complex concepts but also, to confirm the choice of qualimetry as the right approach to solve our problematic, for which no proper solution exists yet.We then continue our study considering biology as key factor in our research. Therefore, we create a classified collection of clades of more than 450 quality models for software. We select the most appropriate quality model from this pool of quality models, and after introducing the concept of polymorphism in quality modeling, we demonstrate how to adapt and operationalize this model to automotive embedded software. This last achievement consequently replies to our original problematic.As a further conclusion of our research, we finally investigate whether a unique quality model for software product, as Zouheyr Tamrabet et al. [5] aim to propose, is more appropriate than a meta-model as quality model aggregator for software product, giving a first glimpse of the model result whose qualifier is the genome of software quality model.[1] “ISO 26262-6:2011 - Road vehicles - Functional safety - Part 6: Product development at the software level,” International Organization for Standardization, 2011.[2] “ARP4754A - Guidelines for Development of Civil Aircraft and Systems,” SAE International, Dec. 2010, [Online]. Available: https://www.sae.org/standards/content/arp4754a/.[3] “DO-178C - Software Considerations in Airborne Systems and Equipment Certification,” Radio Technical Commission for Aeronautics, Dec. 2011, [Online]. Available: https://my.rtca.org/NC__Product?id=a1B36000001IcmqEAC.[4] G. G. Azgaldov et al., “Qualimetry: the Science of Product Quality Assessment,” Standart y i kachest vo, no. 1, 1968.[5] Zouheyr Tamrabet, Toufik Marir, and Farid MOKHATI, “A Survey on Quality Attributes and Quality Models for Embedded Software,” International Journal of Embedded and Real-Time Communication Systems (IJERTCS), vol. 9, no. 2, pp. 1–17, 2018, doi: 10.4018/IJERTCS.2018070101.
The MDRE Design for Manufacturability (DFM) involves designing parts or products so that they meet the critical needs of an application while simultaneously being designed for optimal, efficient, and cost-effective manufacturing (Dwyer, M., Avrunin, G., and Corbett, J. Patterns in Property Specifications for Finite-State Verification. In Proceedings of the International Conference on Software Engineering, Los Angeles, CA; 1999). Creating an optimal design requires an understanding of the many variables that can go into its manufacture. Design engineers have a solid knowledge of manufacturing methods, but most still see the value of a DFM exchange with manufacturers. It can be worth its weight in gold if it creates an opportunity to reduce the timeframe from concept to product—which will increase speed to market. It can also reduce manufacturing costs and improve function, performance, durability, and more. A design engineer’s primary focus is on the development of a product and the individual components it comprises (Edvardsson, J. October 1999. A Survey on Automatic Test Data Generation. Proceedings of the Second Conference on Computer Science and Engineering in Linkoping. CiteSeerX: 10.1.1.20.963). Each component’s fit, form, and function are considered relative to how they will interact with each other in the overall framework of the product that is being brought to life. When these minds meet, and the perspective of the manufacturer is considered, it provides a view from an entirely different angle. In short, how to best manufacture, test, and maintain the system (Egyed, A., Grunbacher, P., and Medvidovic, N. Refinement and Evolution Issues in Bridging Requirements and Architecture-the CBSP Approach. In International Software Requirements to Architecture Workshop, Toronto, CAN; 2001).
Multidisciplinary System Engineering provides the processes and oversight for the three main critical aspects of System of Systems design:
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.
This chapter describes several practical experiences we have made over the last 10 years with different parts of the product quality control approach described in this book. The first three experience reports concentrate on building quality models and using them for quality requirements and evaluating quality: the Quamoco base model, the maintainability model for MAN Truck and Bus, the security model for Capgemini TS and an activity-based quality model for a telecommunications company. Next, we describe the application of quality prediction models, in particular reliability growth models, at Siemens COM. Finally, in the last experience report, we focus on applying analysis techniques: We apply static analysis, architecture conformance analysis and clone detection at SMEs.
While software security has become an expectation, stakeholders often have difficulty expressing such expectations. Elaborate (and expensive) frameworks to identify, analyze, validate and incorporate security requirements for large software systems (and organizations) have been proposed, however, small organizations working within short development lifecycles and minimal resources cannot justify such frameworks and often need a light and practical approach to security requirements engineering that can be easily integrated into their existing development processes. This work presents an approach for eliciting, analyzing, prioritizing and developing security requirements which can be integrated into existing software development lifecycles for small organizations. The approach is based on identifying candidate security goals using part of speech (POS) tagging, categorizing security goals based on canonical security definitions, and understanding the stakeholder goals to develop preliminary security requirements and to prioritize them. It uses a case study to validate the feasibility and effectiveness of the proposed approach.
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.
The 6th edition of the SESS workshop aims at providing a venue for software engineers and security researchers to exchange ideas and techniques. In fact, software is at core of most of the business transactions and its smart integration in an industrial setting may be the competitive advantage even when the core competence is outside the ICT field. As a result, the revenues of a firm depend directly on several complex software-based systems. Thus, stakeholders and users should be able to trust these systems to provide data and elaborations with a degree of confidentiality, integrity, and availability compatible with their needs. Moreover, the pervasiveness of software products in the creation of critical infrastructures has raised the value of trustworthiness and new efforts should be dedicated to achieve it. However, nowadays almost every application has some kind of security requirement even if its use is not to be considered critical.
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.
While the Internet is dramatically changing the way business is conducted, security and privacy issues are of deeper concern
than ever before. A primary fault in evolutionary electronic commerce systems is the failure to adequately address security
and privacy issues; therefore, security and privacy policies are either developed as an afterthought to the system or not
at all. One reason for this failure is the difficulty in applying traditional software requirements engineering techniques
to systems in which policy is continually changing due to the need to respond to the rapid introduction of new technologies
which compromise those policies. Security and privacy should be major concerns from the onset, but practitioners need new
systematic mechanisms for determining and assessing security and privacy. To provide this support, we employ scenario management
and goal-driven analysis strategies to facilitate the design and evolution of electronic commerce systems. Risk and impact
assessment is critical for ensuring that system requirements are aligned with an enterprise—s security policy and privacy
policy. Consequently, we tailor our goal-based approach by including a compliance activity to ensure that all policies are
reflected in the actual system requirements. Our integrated strategy thus focuses on the initial specification of security
policy and privacy policy and their operationalization into system requirements. The ultimate goal of our work is to demonstrate
viable solutions for supporting the early stages of the software lifecycle, specifically addressing the need for novel approaches
to ensure security and privacy requirements coverage.
KeywordsRequirements engineering–Internet security and privacy policies–electronic commerce
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.
Non-functional characteristics of products can be essential for business success and are a key differentiator between a company and its competitors. This paper presents the application of a systematic, experience-based method to elicit, document, and analyze non-functional requirements. The objective of the method is to achieve a minimal and sufficient set of measurable and traceable non-functional requirements. The method gives clear guidance for the requirements elicitation, using workshops for capturing the important quality aspects and eliciting the non-functional requirements. This paper shows its application in three different settings, reporting the experience and lessons learned from industrial case studies that applied our NFR method. As the case studies were applied in different domains and performed with companies of various maturity, and since different quality attributes were considered, a set of interesting results has emerged. Therefore, each case study tells its own story about how the elicitation of NFR in industry can work. The paper discusses the different settings and gives a comparison of the different lessons we learned from the case studies.
In contemporary societies, individuals and organizations increasingly depend on services delivered by sophisticated software-intensive systems to achieve personal and business goals. So, a system must have engineered and guaranteed dependability, regardless of continuous, rapid, and unpredictable technological and context changes. The International Federation for Information Processing Working Group defines dependability as "the trustworthiness" of a computing system, which allows reliance to be justifiably placed on the services it deliver.
Nonfunctional requirements (NFRs) have been frequently neglected or forgotten in software design. They have been presented as a second or even third class type of requirement, frequently hidden inside notes. We tackle this problem by treating NFRs as first class requirements. We present a process to elicit NFRs, analyze their interdependencies, and trace them to functional conceptual models. We focus our attention on conceptual models expressed using UML (Unified Modeling Language). Extensions to UML are proposed to allow NFRs to be expressed. We show how to integrate NFRs into the class, sequence, and collaboration diagrams. We also show how use cases and scenarios can be adapted to deal with NFRs. This work was used in three case studies and their results suggest that by using our proposal we can improve the quality of the resulting conceptual models.
A comprehensive framework for representing and using nonfunctional requirements during the development process is proposed. The framework consists of five basic components which provide the representation of nonfunctional requirements in terms of interrelated goals. Such goals can be refined through refinement methods and can be evaluated in order to determine the degree to which a set of nonfunctional requirements is supported by a particular design. Evidence for the power of the framework is provided through the study of accuracy and performance requirements for information systems
The paper proposes a reuse-based approach to determining security requirements. Development for reuse involves identifying security threats and associated security generic threats --- expressed as misue cases --- and requirements --- expressed as security use cases. Development with reuse involves identifying security assets, setting security goals for requirements, based on reuse of generic threats and requirements from the repository.
vii 1 Introduction 1 1.1 What is the Purpose of the ATAM? 2 2 The Underlying Concepts 5 3 A Brief Introduction to the ATAM 7 4 Quality Attribute Characterizations 9 5 Scenarios 13 5.1 Types of Scenarios 13 5.2 Eliciting and Prioritizing Scenarios 16 5.3 Utility Trees 16 5.4 Scenario Brainstorming 18 6 Attribute-Based Architectural Styles 19 7 Outputs of the ATAM 21 7.1 Risks and Non-Risks 21 7.2 Sensitivity and Tradeoff Points 22 7.3 A Structure for Reasoning 23 7.4 Producing ATAM's Outputs 23 8 The Steps of the ATAM 25 8.1 Step 1 - Present the ATAM 25 8.2 Step 2 - Present Business Drivers 26 8.3 Step 3 - Present Architecture 27 8.4 Step 4 - Identify Architecture Approaches 29 8.5 Step 5 - Generate Quality Attribute Utility Tree 29 ii CMU/SEI-2000-TR-004 8.6 Step 6 - Analyze Architecture Approaches 29 8.7 Step 7 - Brainstorm and Prioritize Scenarios 33 8.8 Step 8 - Analyze Architecture Approaches 36 8.9 Step 9 - Present Results 37 9 The Two Phases of ATAM 39 9.1 Phase 1 Activit...
While the Internet is dramatically changing the way business is conducted, security and privacy issues are of deeper concern than ever before. A primary fault in evolutionary electronic commerce systems is the failure to adequately address security and privacy issues; therefore, security and privacy policies are either developed as an afterthought to the system or not at all. One reason for this failure is the difficulty in applying traditional software requirements engineering techniques to systems in which policy is continually changing due to the need to respond to the rapid introduction of new technologies which compromise those policies. Security and privacy should be major concerns from the onset, but practitioners need new systematic mechanisms for determining and assessing security and privacy. To provide this support, we employ scenario management and goal-driven analysis strategies to facilitate the design and evolution of electronic commerce systems. Risk and impact assessme...
Most requirements engineers are poorly trained to elicit, analyze, and specify security requirements, often confusing them with the architectural security mechanisms that are traditionally used to fulfill them. They thus end up specifying architecture and design constraints rather than true security requirements. This article defines the different types of security requirements and provides associated examples and guildlines with the intent of enabling requirements engineers to adequately specify security requirements without unnecessarily constraining the security and architecture teams from using the most appropriate security mechanisms for the job.
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.
Software product line engineering has proven to be one of the most successful paradigms for developing a diversity of similar software applications and software-intensive systems at low costs, in short time, and with high quality, by exploiting commonalities and variabilities among products to achieve high levels of reuse. At the same time, due to the complexity and extensive nature of product line development, security and requirements engineering are critical success factors in the development of a software product line. However, most of the current product line practices in requirements engineering do not adequately address the security requirements engineering. Therefore, in this paper we will propose a security requirements decision model driven by security standards along with a security variability model to manage the variability of the security requirements related artefacts. The aim of this approach is to deal with security requirements from the early stages of the product line development in a systematic way, in order to facilitate the conformance to the most relevant security standards with regard to the management of security requirements, such as ISO/IEC 27001 and ISO/IEC 15408.
This paper presents a framework for security requirements elicitation and analysis, based upon the construction of a context for the system, representation of security requirements as constraints, and satisfaction arguments for the requirements in the system context. The system context is described using a problem-centered notation, then is validated against the security requirements through construction of a satisfaction argument. The satisfaction argument is in two parts: a formal argument that the system can meet its security requirements, and a structured informal argument supporting the assumptions expressed in the formal argument. The construction of the satisfaction argument may fail, revealing either that the security requirement cannot be satisfied in the context, or that the context does not contain sufficient information to develop the argument. In this case, designers and architects are asked to provide additional design information to resolve the problems. We evaluate the framework by applying it to a security requirements analysis within an air traffic control technology evaluation project.
Software requirements arrive in different shapes and forms to development organizations. This is particularly the case in
market-driven requirements engineering, where the requirements are on products rather than directed towards projects. This
results in challenges related to making different requirements comparable. In particular, this situation was identified in
a collaborative effort between academia and industry. A model, with four abstraction levels, was developed as a response to
the industrial need. The model allows for placement of requirements on different levels and supports abstraction or break
down of requirements to make them comparable to each other. The model was successfully validated in several steps at a company.
The results from the industrial validation point to the usefulness of the model. The model will allow companies to ensure
comparability between requirements, and hence it generates important input to activities such as prioritization and packaging
of requirements before launching a development project.
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.
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.
Quality improvement such as increased reliability and maintainability are of utmost importance in software development. In
this field, which was previously ad hoc and unpredictable rather than customer‐oriented, increasing competition and focus
on customer satisfaction have motivated management to put more emphasis on quality issues. This paper provides insight in
techniques for dealing with what customers call generic quality attributes and what software engineers call nonfunctional
requirements. Since requirements management more than many other disciplines in software engineering need practical insight,
examples are provided for dealing with four nonfunctional requirements in large telecommunication systems, namely performance,
usability, reliability, and maintainability. Guidelines are presented for specifying, constructing, analyzing, measuring and
tracing nonfunctional requirements. Many examples from telecommunication system development show how to specifically and pragmatically
deal with nonfunctional requirements. Extracts from three common standards (SEI CMM, ISO 9000–3, BELLCORE suite) are added
in the form of a checklist for underlining the importance of proper requirements management from a customer viewpoint.
Although the term 'non-functional requirement' has been in use for more than 20 years, there is still no consensus in the requirements engineering community what non-functional requirements are and how we should elicit, document, and validate them. On the other hand, there is a unanimous consensus that non-functional requirements are important and can be critical for the success of a project. This paper surveys the existing definitions of the term, highlights and discusses the problems with the current definitions, and contributes concepts for overcoming these problems.
High-profile disasters and the ensuing debates in the press are alerting more people to the crucial nature of software quality in their everyday lives. This should prompt software professionals to take a second look at how they define software quality. In this task of assessing 'adequate' quality in a software product, context is important. Errors tolerated in word-processing software may not be acceptable in control software for a nuclear power plant. Thus, the meanings of 'safety-critical' and 'mission-critical' must be reexamined in the context of software's contribution to the larger functionality and quality of products and businesses. At the same time, software professionals must ask themselves who is responsible for setting quality goals, and make sure they are achieved.
A discussion is presented of the two primary ways of understanding
software costs. The black-box or influence-function approach provides
useful experimental and observational insights on the relative software
productivity and quality leverage of various management, technical,
environmental, and personnel options. The glass-box or cost distribution
approach helps identify strategies for integrated software productivity
and quality improvement programs using such structures as the value
chain and the software productivity opportunity tree. The individual
strategies for improving software productivity are identified. Issues
related to software costs and controlling them are examined and
discussed. It is pointed out that a good framework of techniques exists
for controlling software budgets, schedules, and work completed, but
that a great deal of further progress is needed to provide an overall
set of planning and control techniques covering software product
qualities and end-user system objectives