Requerimientos no funcionales

Non-Functional Requirements Analysis Modeling for Software Product Lines
Quyen L. Nguyen National Archives and Records Administration, College Park, MD 20740 USA Department of Computer Science, George Mason University, Fairfax, VA 22030 USA qnguyeng@gmu.edu

Abstract
In most IT projects, software developers usually pay attention to functional requirements that satisfy business needs of thesystem. Non-functional requirements (NFR) such as performance, usability, security, etc. are usually handled ad-hoc during the system testing phase, when it is late and costly to fix problems. Due to the importance and criticality of NFR, I study the problem of modeling NFR for Software Product Lines (SPL), which adds yet an additional dimension of complexity. This paper will survey the softwareengineering literature, in search of a systematic way to analyze and design NFR, from the perspectives of the concept of commonality and variability of SPL and the characteristics of NFR. Finally, I will propose a methodology based on the extension of Product Line UML-Based Software Engineering (PLUS) techniques, for a unified and automated method to model NFR throughout all phases of SPLengineering.

This paper is organized as follows. Section 2 discusses about the two-fold challenges of modeling NFR for an SPL. In section 3, I present the case study of an Open Archive Information System (OAIS) [9], which forms the basis for illustration of the different approaches to model NFRs. Sections 4 through 6 are devoted to the study of the analysis modeling techniques and methodologies ofNFRs that can be utilized in the integrated approach presented in section 7. The paper ends with a conclusion and summary in section 8.

2. Problem Statement
First, all issues and challenges in modeling NFRs for a single product carry over to the domain of SPL. Indeed, the specification of an NFR is not easy due to the fuzziness of the test verification, which normally operates in the pass/failbinary mode. Moreover, a quality attribute can also have a negative impact on another quality attribute, so that careless modeling could create inconsistencies in requirement specifications. Since an SPL has the notion of commonality and variability among members of the product line, modeling NFR for SPL is even more complex. Indeed, NFR represents simultaneously an overarching feature acrossproducts of an SPL, and a variant factor. The introduction of an NFR to the set of variants adds another dimension of variability to the SPL. On one hand, an NFR may be required in all members of an SPL. Basic security can be a common feature for the entire product line. But, even for this NFR, one product may need more stringent security requirements than others in the family. That is, there aredifferent levels of security; hence the concept of parameterized or alternative feature can also be applied to an NFR. On the other hand, some products in an SPL may need a certain NFR, while others do not. This implies that we need to extend the notion of optional feature to NFR.

1. Introduction
In most projects, software developers usually pay attention to functional requirements that satisfybusiness needs of the system. Non-functional requirements (NFR) such as performance, usability, reliability, security, and scalability are usually handled in an ad-hoc manner during the system testing phase. Due to the importance and criticality of the NFR, there should be a systematic way to analyze and design those NFR from the beginning of the software development lifecycle. In this paper, Iwould like to research the problem of modeling NFR for Software Product Lines (SPL). How the concept of commonality and variability affects NFR modeling and vice-versa will be investigated. Would it be possible to utilize the techniques specialized for SPL to model NFR?

MiSE’09, May 17-18, 2009, Vancouver, Canada
U.S. Government work not protected by U.S. copyright

56

ICSE’09 Workshop...