text: 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.
  @cite_22: 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.
  @cite_7: It is noted that the factors of software that determine or influence maintainability can be organized into a hierarchical structure of measurable attributes. For each of these attributes the authors show a metric definition consistent with the published definitions of the software characteristic being measured. The result is a tree structure of maintainability metrics which can be used for purposes of evaluating the relative maintainability of the software system. The authors define metrics for measuring the maintainability of a target software system and discuss how those metrics can be combined into a single index of maintainability. >
  @cite_19: 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 customerdoriented, 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.
  @cite_2: 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. >
  @cite_15: 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.
  @cite_25: 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.
summary: Various approaches for non-functional requirements have been proposed. The standard IEEE Std 830-1998 @cite_7 considers requirements specifications in general. It concentrates strongly on functional issues and quality requirements play only a minor role. Ebert discusses in @cite_19 an approach for managing non-functional requirements. He classifies them in and that gives them a first structure. However, this is still too coarse-grained to be applied fruitfully. Also more general approaches such as @cite_25 @cite_2 do not impose a sufficient structure on the quality requirements that foster elicitation or assurance. More structure is provided by the UMD approach @cite_15 . However, it focuses mainly on that should be avoided and hence do not provide enough connection to the stakeholders. Finally, @cite_22 included the use of quality models in their approach to non-functional requirements. However, the used quality models themselves provide no direct connection to the stakeholders.