feature-oriented nonfunctional requirement analysis for ... · keywords software product line,...

Peng X, Lee SW, Zhao WY. Feature-oriented nonfunctional requirement analysis for software product line. JOURNAL OF

COMPUTER SCIENCE AND TECHNOLOGY 24(2): 319–338 Mar. 2009

Feature-Oriented Nonfunctional Requirement Analysis for Software

Product Line

Xin Peng1 (彭鑫), Member, CCF, Seok-Won Lee2, and Wen-Yun Zhao1 (赵文耘), Senior Member, CCF

1School of Computer Science, Fudan University, Shanghai 200433, China2Knowledge-Intensive Software Engineering Research Group, Department of Software and Information Systems

College of Computing and Informatics, University of North Carolina at Charlotte, Charlotte, NC 28223, U.S.A.

E-mail: [email protected]; [email protected]; [email protected]

Received March 17, 2008; revised December 1, 2008.

Abstract Domain analysis in software product line (SPL) development provides a basis for core assets design and imple-mentation by a systematic and comprehensive commonality/variability analysis. In feature-oriented SPL methods, productsof the domain analysis are domain feature models and corresponding feature decision models to facilitate application-orientedcustomization. As in requirement analysis for a single system, the domain analysis in the SPL development should con-sider both functional and nonfunctional domain requirements. However, the nonfunctional requirements (NFRs) are oftenneglected in the existing domain analysis methods. In this paper, we propose a context-based method of the NFR analysisfor the SPL development. In the method, NFRs are materialized by connecting nonfunctional goals with real-world context,thus NFR elicitation and variability analysis can be performed by context analysis for the whole domain with the assistanceof NFR templates and NFR graphs. After the variability analysis, our method integrates both functional and nonfunc-tional perspectives by incorporating the nonfunctional goals and operationalizations into an initial functional feature model.NFR-related constraints are also elicited and integrated. Finally, a decision model with both functional and nonfunctionalperspectives is constructed to facilitate application-oriented feature model customization. A computer-aided grading system(CAGS) product line is employed to demonstrate the method throughout the paper.

Keywords software product line, nonfunctional requirement, domain analysis, feature-oriented method, variability ana-

lysis

1 Introduction

Software systems, aside from implementing all thedesired functionality, must cope with nonfunctionalaspects such as reliability, security, accuracy, safety,performance, etc.[1] Ineffectively dealing with nonfunc-tional requirements (NFRs)[1−4] is a common cause ofsoftware-intensive system failures and can badly affectconfidence in the system. This is the same as in thesoftware product line (SPL) development, and it is evenharder to properly deal with the NFRs in SPL. Thegoal of SPL engineering is to support the systematicdevelopment of a set of similar software systems (calleddomain) by understanding and controlling their com-mon and distinguishing characteristics[5]. Commonali-ty in a specific domain provides the basis of proactivereuse in SPL, while differences among different applica-tion products (i.e., variations) demand proper variabi-lity mechanisms in the analysis and design model to

enable application-oriented customization.NFR analysis is part of domain analysis in SPL de-

velopment. Domain analysis is the requirement analysisactivity for a specific domain to identify and documentthe commonalities and variations in related systems inthe domain[5]. There have been many studies focusedon the domain analysis and design in SPL (e.g., [5–9] and our previous work [10, 11]). These studies onlyconcentrate on the domain analysis and design for func-tional requirements and their variations, although theexistence and influence of NFRs are also mentioned insome of them (e.g., [5, 7, 12]). However, NFR-relatedvariations also exist and have great influence on SPL de-sign and implementation. For example, computer-aidedgrading system (CAGS) software for examinations atdifferent levels and scales (e.g., regular in-school exami-nations, region-level unified examinations, and collegeentrance examinations, etc.) may require different le-vels of security, performance, privacy, etc., although

Regular PaperThis work is supported by the National Natural Science Foundation of China under Grant Nos. 60703092 and 90818009, the

National High Technology Research and Development 863 Program of China under Grant No. 2007AA01Z125.

320 J. Comput. Sci. & Technol., Mar. 2009, Vol.24, No.2

their business functions are similar to each other. Fur-thermore, redundant NFR design and implementationusually mean much higher cost of their ownership andmaintenance, or influence on other more desired goalsdue to NFR conflicts. For example, it is unnecessary toinclude hard-certification-based authentication and en-crypted storage/transfer in CAGS applications for in-school examinations, but they are essential to collegeentrance examinations, since the scores directly decidewhether a student can be matriculated by universities.Therefore, nonfunctional variations should be identifiedand embodied in the domain analysis and design, sothat each application in the targeted domain can haveproper nonfunctional designs and achieve overall qua-lity.

Functional variability is usually embodied in op-tional and alternative functionalities. Nonfunctionalvariability is different, due to the characteristics ofNFRs. Since NFRs can hardly ever be satisfied, theyare more often treated as conceptual “soft” goals withthe connotation of partial satisfaction[2]. On the otherhand, NFRs are closely related to functional require-ments, and there exist conflicts and tradeoffs betweendifferent NFRs. Therefore, nonfunctional variations of-ten exhibit different types and levels of sensitivity tononfunctional properties and tradeoffs, e.g., normal andstrong authentication. As for the influence on the SPLdesign, NFRs in SPL first bring NFR-related opera-tionalizations and constraints to the implementationof related functions similar to the NFRs for individ-ual systems. Furthermore, the nonfunctional varia-tions will influence the commonality/variability ranges,which are crucial to variability-oriented design in SPLarchitecture. From the aspect of application derivation,nonfunctional goals play different roles in leading cus-tomized application beyond the functional perspectives.

NFRs have been frequently neglected or poorly con-sidered in software design[1], both in traditional soft-ware development and in SPL. This is partly due to thevagueness of NFRs and complex dependencies amongthe NFRs (e.g., positive or negative, partially or fullyetc.)[1−4]. It is even more difficult in the NFR analysisand design for SPL: not only should NFRs be iden-tified and considered, but also NFR-related variationsshould be analyzed and properly treated in SPL design.Related issues include: 1) how to identify the common-ality/variability from SPL context; 2) how to integrateNFRs into the domain model; 3) how to provide differ-ent tradeoff choices for applications, etc.

In this paper, we propose a feature-based NFRanalysis method for SPL development, supportingthe NFR elicitation, nonfunctional variability analysis,

NFR integration, and decision modeling. The methodtakes a feature-centered viewpoint in the NFR analysis,since feature-based methods provide good mechanismsfor commonality/variability analysis and representationand have been widely adopted in the domain analysis(e.g., [5–8, 10]). On the other hand, the method in-troduces a context model which depicts real-world ex-ecution environment for functional features, as the an-chor for the NFR elicitation and variability analysis. Inrequirement engineering, the effect of real-world envi-ronment (or context) has long been realized (e.g., [13,14]). The environment is there as the reality, and therequirements originating from the environment are de-sired or optative conditions over the phenomena in theenvironment[13].

In the method, an initial functional feature modelis assumed to be built beforehand, and the methodwill first construct the domain context model. Second,the nonfunctional goals related to each functional fea-ture are identified from the context model by match-ing NFR templates. Third, the NFR graph introducedin [2] is employed to refine the nonfunctional goalsinto sub-goals at different levels, and identify opera-tionalizations for NFR levels and related dependencies(positive or negative). Fourth, nonfunctional variationsare analyzed from the three levels of NFR goal, NFRlevel and operationalization according to feature con-texts, NFR templates, NFR conflicts, and environmen-tal dependencies. Then, NFRs are integrated into afeature model along with the nonfunctional variationsand constraints. Finally, a feature decision model withboth functional and nonfunctional perspectives is con-structed based on the analysis of the NFR conflicts,dependencies and feature constraints. By incorpora-ting both the functional and nonfunctional require-ments into the domain feature model and the decisionmodel, we provide a comprehensive basis for applicationproduct customization. As a demonstrating productline, the CAGS product line is employed to illustratethe method throughout the paper.

The remainder of this paper is organized as follows.Section 2 introduces the CAGS product line and ana-lyzes the NFR-related problems encountered in the do-main, providing background illustration for the issueof the NFR analysis for SPL. Section 3 presents back-ground introductions to the feature model, nonfunc-tional goals and NFR graphs employed in our method.Section 4 gives an overview of the whole method, andfour method phases are introduced in Section 5. Section6 briefly evaluates our method and discusses related is-sues on the NFR analysis for the SPL development.Then, Section 7 introduces related work and compares

Xin Peng et al.: Feature-Oriented NFR Analysis for SPL 321

them with our method. Finally, Section 8 draws theconclusions and plans for our future work.

2 NFR Analysis for SPL: Problems

2.1 CAGS Product Line

CAGS[15], computer aided grading system, is forsubjective examinations, in which an electronic an-swer is reviewed and graded by several graders (usuallyteachers) for fairness. By CAGS, electronic answerswill first be collected and pretreated, and then be de-composed into data units, usually by questions. Whengrading, the answer data units will be organized anddispatched to graders according to predefined rules andprivilege settings[15]. After each grading, results (in-cluding scores and comments) are submitted automati-cally and statistics and analysis can be performed. Insome cases, additional checking and mediation may beperformed to ensure the grading quality and fairness.

Fig.1. Snapshots of CAGS application products. (a) CAGS for

spoken examination. (b) CAGS for written examination.

The CAGS software was first developed for spokenEnglish examinations in Chinese colleges and achieved

its initial success[15]. Later, another similar examina-tion mode, the traditional written examination, wasconsidered by the CAGS group, since these two kinds ofgrading systems are common in most aspects and onlydiffer in the preparation and presentation of the elec-tronic answers. Therefore, the CAGS software evolvedto cover both spoken and written examinations (seeFig.1). On the other hand, the CAGS software is grad-ually applied to more examinations at different levels(e.g., middle school, college, city and province) andwith different features (including regular in-school exa-minations, and official college and senior middle-schoolentrance examinations). Ultimately, the CAGS soft-ware has evolved into the CAGS product line includinga complete series of electronic grading products for di-fferent mode, level and featured examinations.

The initial functional feature model for the simpli-fied CAGS product line is shown in Fig.2 (a brief in-troduction to the feature model can be found in Sub-section 3.1). From the feature model, we can seethat “CAGS” includes five mandatory parts of “Login”,“AnswerPrepare” (prepare electronic answers for grad-ing), “AnsPackDispatch” (pack answers and dispatchto graders), “Grade” (examine and mark the assignedanswer), “Query&Stat.” (query and statistics), and anoptional part of “Check&Mediation” (additional checkand mediation for questionable answer grading). “An-swerCut” is another example of optional feature, whichmeans an image answer may need to be cut into severalparts in written answer preparation. Besides optional-ity, generalization is another mechanism of feature vari-ability (Alternative and OR sub-features). For exam-ple, “ImgShow” and “AudioPlay” are two alternativesub-features of “AnsDisplay”; “subjectExam” (exam-ination by subjects) and “syntheticExam” (examina-tion with mixed subjects) are two OR sub-features of“writtenExam”, which means, in the application of awritten examination, the supported examination typescan be subject-oriented or synthetic or both (see thecardinality [1..2]). In Fig.2, another lightweight mech-anism for feature generalization, facet (see Subsection3.1), is also employed, which denotes dimensions of pre-cise description for functional features[10]. The valuespace of facets is called terms which can also havetheir generalization structure (see underlined featuresin Fig.2). In Fig.2, “dispatchMode” is identified as afacet of “AnsPackDispatch”, and can be “byPaper” or“byQuestion” in a certain CAGS application.

2.2 Nonfunctional Variations in CAGS

Due to the broad spectrum of the CAGS productline, a great deal of variations exist among different


Fig.2. Initial functional feature model for simplified CAGS product line.

CAGS applications, so commonality/variability analy-sis must be performed to enable the design and imple-mentation of the reuse platform for application deriva-tion. In the beginning, the CAGS group concentratedon the functional variations within the desired domainscope as shown in Fig.2, including different answer me-dia (audios or images), different distribution policies,etc. These variations have led to a series of variable de-sign and implementation for different application prod-ucts. Then, the nonfunctional concerns, such as secu-rity, reliability and performance, etc, are gradually re-cognized. Furthermore, these concerns exhibit diversityin different applications.

Grading security is the primary nonfunctional con-cern in CAGS applications, including authentication,transfer security and storage security. However, it dif-fers greatly in different applications. In the applicationsin middle schools, the clients seldom care for securityrequirement, since the system is only used in their in-house examinations and users are all their teachers. Onthe other hand, in the applications in official (college orsenior middle-school) entrance examinations, gradingsecurity is greatly emphasized as the scores are signifi-cant to the students and the graders are from variousorganizations.

For spoken examinations, grading is performed bylistening to the audio records, so speeding must be auser-friendly function in most of the time to enable thegrader to quickly go through the record. However, insome official spoken examinations, speeding is not al-lowed, since it will bring up the issue of irresponsibilityof graders. Therefore, by considering the reliability ofgrading, speeding should not be developed as a fixedfunction, but as an optional one.

For written examinations, a primary concern ofusers’ experience and grading reliability is the defini-tion of the answer images generated by answer sheet

scanning. High definition is always a desired feature forgraders. However, high definition is highly tied to theresolution of the monitor being used. Although moni-tor resolution is not a problem for most of the clients,there are still some small schools that have only oldCRT monitors. For these clients, low-definition answerimage is the only choice. Furthermore, high-definitionanswer images have a much larger demand on stora-ge space and the price of the corresponding scanneris much higher, which can heavily influence the clientchoice. Therefore, both high- and low-definition answerimages should be supported by the CAGS product lineto provide products suited for different clients.

2.3 Problems

In the SPL development, the variability analysis isessential to both functional and nonfunctional require-ments. And both functional and nonfunctional fea-tures are identified from the marketing plan[7]. If theSPL group decides to involve applications with differ-ent nonfunctional concerns in the SPL scope, nonfunc-tional variations will emerge. For example, most non-functional variations in CAGS SPL originate from themarketing plan that involves both high- and low-endexaminations in the product line.

Specialization and optionality are the two basic vari-ability mechanisms[8,10]. From Subsection 2.2, we cansee there are also nonfunctional variations in the CAGSdomain.• Grading Security. Clients are much concerned

over formal official examinations, but not so much con-cerned over other types of examinations. High securityis always good, but it may bring additional cost andhave influence on the convenience of use. For example,in most of the common implementation with high secu-rity, each user must have a hard certification (usuallya USB key) and take it when using the system. These


additional costs and inconveniences are unacceptable insome applications of nonofficial examinations.• Grading Reliability. This is always a big concern in

all of the grading applications, but the reliability differsin degree, e.g., high-reliability spoken examinations donot allow speeding when playing answer audios.• User Experience. High definition is always desired,

but limitations on monitor devices and high equipment(the scanner) cost may bring up some other issues.

From these, we can see that there are nonfunctionalvariations in SPL development. Nonfunctional varia-tions are not as obvious as functional ones. For exam-ple, an optional function can be definitely involved inor removed from a product, but an NFR can never besaid to be involved or removed but only high or lowin the degree of its effectiveness. However, we can stillconsider NFRs from a realistic viewpoint, that is to sayan NFR can be seen as not concerned if no special con-sideration is needed for it. For example, security canbe seen as not concerned if simple password-based au-thentication and plain-text-based transfer/storage areacceptable. Besides the optionality, NFRs can also bealternative in desired satisfaction levels or implementa-tion ways. For example, high-level security demandshard-certification-based SSL transfer, while medium-level security demands only soft-certification-based SSLtransfer (see the NFR graph in Fig.3).

In the SPL design and implementation, separatingand localizing variations are a primary respect to max-imize the reusable parts while reserve necessary flexi-bilities for product diversity. The same as functionalvariations, nonfunctional variations (including optionaland alternative NFRs) also have significant impacts onvariability design and implementation. Nonfunctionalvariations can influence the commonality/variabilityboundaries in design and implementation. OptionalNFRs can bring optional functions into the design andimplementation, e.g., encrypt/decrypt for storage se-curity. Alternative NFRs can bring variable functions,e.g., password-, soft-certification-, or hard-certification-based authentication. Moreover, nonfunctional varia-tions can also refine existing functions based on dif-ferent constraints on them, e.g., the difference of userexperience will bring a new variation of image defini-tion into existing function of electronic answer prepa-ration. These nonfunctional variations should be em-bodied in the domain model to meet different prefer-ences and different environmental constraints in differ-ent applications. For example, all of the password-based, soft- and hard-certification-based authentica-tions should be supported by the SPL platform for pos-sible uses. Therefore, nonfunctional variations must be

identified, explicated and documented, just as what hasbeen done for the functional variations, and incorpo-rated into the feature model to achieve a comprehensivedomain model with both functional and nonfunctionalperspectives.

3 Background

3.1 Feature Model and Feature DecisionModel

Domain engineering and application engineering aretwo essential phases in the SPL development. Domainanalysis, which is the domain-level requirements anal-ysis activity for the SPL development, constitutes thedomain engineering together with domain design andimplementation. Domain analysis techniques can beused to identify and document the commonalities andvariations in related systems in a domain[5].

In widely-used feature-oriented methods (e.g., [5–8,10, 11]), the product of domain analysis is a featuremodel. The feature model describes the system-to-beas a combined set of feature variables[16]. It is the ba-sis of the domain design and implementation and canbe tailored to produce the specification and design ofapplication product[6]. A feature is a characteristic ofsoftware from users’ or customers’ views[6]. The fea-ture model provides formal representations for featuresalong with variations (Optional, Alternative, and ORfeatures) and feature refinement structure according todecomposition and generalization (see Fig.2). Optionalfeatures can be included in or removed from applica-tion product. Alternative features mean that one andexact one of them should be bound to the parent fea-ture in application product. OR features mean that anynon-empty subset of them can be bound to the parentfeature in application product. Besides, some methodsalso introduce another lightweight mechanism for fea-ture generalization, called facet[10] (or characterizationin [8]), which refines a feature by identifying its at-tribute features[8]. Facets can be construed as perspec-tives, viewpoints, or dimensions of precise descriptionfor features[10].

In an SPL, variability is usually defined through vari-ation points. A variation point defines a decision pointtogether with its possible choices (functions or quali-ties), and the available functions or qualities for a varia-tion point, i.e., available choices, are called variants[12].The number of variants that can be chosen for a varia-tion point is called cardinality[12]. In a feature model,Optional, Alternative and OR features are variationpoints. For an optional feature, the variants are in-clusion and removal of the feature. For an Alternative


or OR feature, the variants are its sub-features. In thefeature model, cardinality is only effective for OR fea-tures, since an OR feature can have different numbersof sub-features bound to different applications. Cardi-nality can be represented as [min..max], e.g., [1..2] for“writtenExam” in Fig.2.

Variations defined in domain engineering (whetherfunctional or nonfunctional) are resolved in differentphases of application engineering to derive the applica-tion product. For helping resolution decision in appli-cation development, a decision model is proposed. Adecision model structures the variability within a prod-uct line as a set of decisions to be resolved along withthe interrelations between the decisions[9]. With thedecision model, complexities of variability can be re-duced greatly by providing a clear and natural decisionpath to follow. Therefore, after integrated into featuremodel, nonfunctional perspectives should also be incor-porated into the feature decision model to provide full-scale variability resolution guidance. The incorporationcan be implemented systematically by considering de-pendencies among NFR goals, functional features andenvironmental conditions.

3.2 Nonfunctional Goals and NFR Graph

There are fundamental differences between goals andfeatures[16]. Goals represent stakeholders’ intentions,which are manifestations of intent that may or maynot be realized. Features in the product line representsystem-to-be functions or properties. A goal model pro-vides a natural way to identify variability at the earlyrequirements phase by allowing the capture of alter-native ways for stakeholders to achieve their goals[17].NFRs can also be embodied in a goal model. SomeNFRs might not be satisfied completely, and they areusually represented as soft goals[4]. These NFR-relatedgoals and their variations should be further analyzed,refined and integrated into the feature model.

In our method, candidate NFRs are first captured ina goal model. A goal model consists of one or more rootgoals that represent stakeholder objectives, and each ofthem is AND/OR decomposed into sub-goals to form aforest[16]. We use the NFR graph to represent the goalmodel for NFRs. The NFR graph provides refinementstructure for various NFRs. In an NFR graph, NFRsare viewed as goals (roots of an AND/OR graph) thatare decomposed into sub-goals (sub-graphs) until all thenecessary operationalizations (actions and information)are represented at the leaf-node levels of the graph[1].

The NFR graphs in our method are adapted from theNFR graphs used in [1] and [2] by adding mechanismsfor variations in sensitivity of nonfunctional properties

(NFR level). On the other hand, environmental depen-dencies are identified for each operationalization to helpdetermine its applicability in the domain.

There are both general and domain-specific non-functional goals. For the former, corresponding NFRgraphs can be reused in different domains. For the lat-ter, NFR graphs should be constructed by consideringdomain-specific stakeholder concerns. The NFR graphsfor Security, Usability, Grading Reliability and Grad-ing Usability in CAGS domain (segment) are depictedin Fig.3, in which “Security” and “Usability” are gen-eral goals while the other two are specific to the CAGSdomain. In our NFR graph, there are four elements:• NFR goals (including sub-goals) represent the re-

finement of abstract NFRs.• NFR levels identified for each atomic NFR sub-goal

denote the levels of typical sensitivity. An atomic NFRgoal can have several levels or only one level (itself).• Operationalizations are actions or suggested re-

strictions for the implementation of each NFR level.An NFR level can have multiple operationalizations ascombined implementation policies.• Environmental conditions specify necessary real-

world conditions (e.g., devices) required by operationa-lizations.

In Fig.3, “Security” is decomposed into “Authen-tication”, “Transfer Security” and “Storage Security”.Three levels of Transfer Security are identified. Theycan be implemented by SSL transfer without client cer-tification, with soft certification and hard certification,respectively. Grading Reliability and User Experienceare domain-specific NFR goals. In their decompositionstructures, Electronic Answer Definition is identified asa common sub-goal of them, since high answer imagedefinition contributes to both of them.

Similar to [1], static and dynamic operationaliza-tions are distinguished, which are depicted by solidcircle and dashed circle, respectively. Dynamic op-erationalizations are those that call for actions to beperformed[1] (e.g., Audio Speeding), while static oper-ationalizations express certain restrictions (e.g., the re-strictions “No Additional Request for Use” and “HighImage Resolution”).

In an NFR graph, there are four types of rela-tions between different elements: AND/OR decompo-sition between a goal and its sub-goals; an atomic goaland corresponding NFR levels; AND/OR decomposi-tion between NFR level and its operationalizations; en-vironmental dependencies between operationalizationsand environmental conditions. Similar to OR relationsbetween goals, OR decomposition between NFR leveland its operationalizations represent alternative opera-tionalizations, while AND decomposition represents


Fig.3. NFR graph for Security, Usability, Reliability and User Experience in CAGS domain.

all-included operationalizations. For example, dynamic“Grading Surveillance” and static “Must Finish theWhole Answer Record” in Fig.3 are identified as ANDoperationalizations for “Compelled Grading Control”.The former provides real-time grading surveillance ofcertain graders, while the latter restricts that each an-swer record must be played completely before the scoreis given.

In NFR graphs, conflicts between NFRs can be iden-tified between different operationalizations. For exam-ple, we can find conflicts between “Transfer Security”and “Usability”. High transfer security has conflictwith “Cost of Ownership” and “Convenience of Use”,since each user should get a hard certification (e.g., USBkey) and take it when it is used. Another conflictingexample is the restriction “Must Finish the Whole An-swer Record” and “Audio Speeding”. It should be em-phasized that we can only identify non-trivial conflictsand ignore others. For example, storage-performance-related conflicts are ignored here, since sufficient stor-age space can be seen as always available in CAGS do-main due to great development of storage devices.

Environmental dependencies are identified to eval-uate the applicability of each operationalization. InFig.3, “USB Key” and “High-Resolution Monitor”are identified as the environmental dependencies of“Transfer with Hard-Cert.-SSL” and “High Image Res-olution”, respectively. These dependencies will be

evaluated in the NFR variability analysis.In NFR graphs, original goal variations exist at dif-

ferent levels. An OR decomposition of a goal introducesa variation point, which defines alternative ways of ful-filling the goal[16]. Multiple NFR levels for the sameatomic goal specify possible variations on the sensitiv-ity level. There are also alternative operationalizationsfor the same NFR level. Besides these variations in theNFR graphs, application diversity in the domain canalso bring nonfunctional variations. For example, non-functional goals concerned in an application may notbe so concerned in another application, environmentaldependencies for the same operationalization may havedifferent status of satisfaction in different applications,and different applications may have different tradeoffdecisions for the same NFR conflicts. All of these serveas starting points of nonfunctional variability analysis.Our method tries to identify these nonfunctional vari-ations in support of the feature context and NFR tem-plate, and incorporate these goal-based NFRs into thefeature model, along with the nonfunctional variations.

4 Method Overview

The whole process of our method is depicted inFig.4, including four phases with related artifacts. InFig.4, arrows represent production and consumptionrelations between phases and artifacts and also theorder of phases/activities. It is similar to the NFR


analysis strategy for individual system employed in[1], namely constructing functional and nonfunctionalperspectives separately and then integrating them to-gether. The difference is that our method concentrateson the nonfunctional variability analysis and NFR-oriented decision modeling. The method includes fourmajor phases: 1) feature context construction, 2) non-functional variability identification, 3) NFR integrationand, 4) NFR-oriented decision modeling. The start-ing activity is the feature context construction. Forthe whole method, the main input artifacts are initialfunctional feature model and NFR graphs, which repre-sent initial functional and nonfunctional perspectives,respectively. The final outputs are the NFR-integratedfeature model and feature decision model (underlinedartifacts in Fig.4).

4.1 Feature Context Construction

The first phase, feature context construction,constructs the feature context model for the initial

functional feature model. All of the requirements arebased on the environment[13]. Feature context mod-els the real-world context where nonfunctional concernsoriginate, including execution scenarios, related people,entities, events and their properties. Variations withinthe domain scope are also embodied in the feature con-text. In our method, a feature context model is onlyconstructed for the initial functional feature model andservers as an anchor for NFR elicitation and variabilityanalysis.

4.2 Nonfunctional Variability Identification

Nonfunctional variability identification elicits thenonfunctional variations from the NFR graphs with thesupport of feature context and NFR templates. Asmentioned in Subsection 3.2, the nonfunctional vari-ations can originate from different levels of the NFRgraphs (see Table 1). They have different variationrationales, so different principles should be applied tothem. We have different analyses: goal presence analy-sis, NFR level analysis and operationalization analysis.

Fig.4. Process of NFR analysis for SPL.

Table 1. Nonfunctional Variations and Analysis Activities

Variation Level Variation Rationales Analysis Activity Analysis Result

NFR Goal Alternative OR sub-goalsDiversity on the nonfunctional concerns

Goal Presence Analysis Reserved NFR goals and their presenceconclusions (mandatory or optional)

in different applications

Different tradeoff policies in different ap-plications

NFR Level Diversity on the sensitivity level of thesame NFR goal in the domain

NFR Level Analysis Possible necessary NFR levels for eachreserved NFR goal

Different tradeoff policies in different ap-plications

Operationalization Alternative operationalizationsDifferent applicability in the domain dueto the environmental dependencies

OperationalizationAnalysis

Reserved operationalizations and theirrealistic possibility (always satisfiable,partially satisfiable or unsatisfiable)


After these three analyses, we can get complete non-functional perspectives, including all the necessaryNFR goals in the domain, their variability settings, can-didate NFR levels and operationalizations.

For the NFR goals (and sub-goals), the goal presenceanalysis will evaluate their presence status according toNFR templates and contextual information in the do-main. NFR templates in our method encode genericcontexts for nonfunctional concerns. It can be used toevaluate the existence of NFR goals in different appli-cations, and provide heuristics for nonfunctional vari-ability analysis, e.g., different existence status in dif-ferent applications can make an optional NFR goal.After goal presence analysis, not-concerned goals areremoved and reserved goals are further evaluated to bemandatory (concerned in all the applications) or op-tional (concerned in part of the applications). Differentfrom a single system, NFR tradeoffs for an SPL canbe quite different in different applications. To accom-modate these different tradeoff policies, initial presenceconclusions may be adjusted to add more variations.

NFR level analysis further determines necessary lev-els for each NFR goal. Although a higher NFR level isalways better than lower ones, lower levels may needto be reserved due to possible conflicts between higherNFR levels and other NFRs.

Operationalization analysis evaluates the realisticpossibility of each operationalization for reserved NFRlevels by considering its environmental dependencies.The results can be “always satisfiable”, “partially sat-isfiable” or “unsatisfiable”. Accordingly, the variabilitysettings of related NFR levels may be adjusted, e.g., anNFR level can be removed if all of its operationaliza-tions are evaluated to be “unsatisfiable”.

4.3 NFR Integration

Similar to [1], the identified NFRs will finally be in-corporated with the initial feature model along withvariations from nonfunctional perspective. In the NFRintegration, NFR-related operationalizations will be in-corporated into the feature model, and the existingfunctional features may be further refined according tothe attached nonfunctional concerns. NFR-related fea-ture incorporation and refinement will bring new de-pendencies, so necessary NFR-related constraints willalso be added into feature model.

4.4 NFR-Oriented Decision Modeling

The goal of the NFR-oriented decision modeling isto construct functional and nonfunctional perspectivesthat are integrated into the decision tree for variationresolution in application engineering. It first identifies

NFR-related variability decision points by consideringNFR conflicts, NFR dependencies and environmentaldependencies. Then the relations between NFR-relateddecisions and functional decisions are investigated toincorporate the two parts of variability decision points.Finally, the NFR-integrated decision model can be ob-tained, which can provide comprehensive variability de-cision support for application engineering with bothfunctional and nonfunctional considerations.

5 Method Phases

5.1 Feature Context Construction

5.1.1 Feature Context

NFRs are quality constraints imposed on the system.As for an NFR, whether users care for it or not and itssensitivity are primarily determined by the real-worldcontext of related operations. For example, transfer se-curity emerges when sensitive messages are transferredvia public or local network that is also accessible bythose who have the tendency of stealing or forgery. Fur-thermore, the sensitivity of NFRs heavily depends oncontextual details. For example, the desired level oftransfer security is usually determined by details suchas sensitivity of the data transferred, publicity and ac-cessibility of the network, etc.

Nonfunctional requirements, such as security andprivacy issues, originate from human concerns andintents, and thus should be modeled through socialconcepts[14]. In our method, the real-world concept-based context model is established for functional fea-tures to enable nonfunctional variability analysis. Fea-ture context is a formal model depicting how the featurebehaves and works in the domain that includes peo-ple/entities in the real-world, and the relations amongthem. Feature context is more than use case scenar-ios, in that it extends with people/entities indirectly forinvolved to provide a comprehensive context for NFRanalysis.

The construction of the context model is the pro-cess of investigating the real-life contextual elementsand structuring them in a formal and knowledge-basedmodel. Each functional feature and the whole systemcan have their context models at different levels of ab-stractions.

5.1.2 Meta-Model of Feature Context

The meta-model of feature context is depicted inFig.5, providing the skeleton structure of the feature


Fig.5. Feature context meta-model.

context. The kernel of the context is a series of inter-actions between stakeholders (e.g., grader) and systemnodes (e.g., grader client), or between different systemnodes. An interaction can input, output or transfersome data via specific medium. Typical mediums aredevices (usually for interactions between human andsystem, e.g., keyboard for data input) and networks(usually for interactions between system nodes, e.g.,LAN). The data involved in interactions reflect corre-sponding real objects, which are generated from real-lifeactivities that specific actors participate in. For exam-ple, answer files in CAGS reflect answer sheets genera-ted by examinations that different types of studentstake.

It should be emphasized that meta-model in Fig.5defines only the skeleton structure of the feature con-text. For specific domain, necessary entities and prop-erties should be added into the context model, e.g., thedevice scanner and properties defined on examinationin Fig.6.

5.1.3 Example of Feature Context Model

A segment of the feature context model for theCAGS domain is depicted in Fig.6. Each element inthe figure is identified with its type, and interactionsare represented by gray boxes for prominence. TheALT and OR nodes represent variable contextual in-formation, namely alternative and OR choices, e.g.,the OR node connected to “AnsDispatch” shows thatthe system can dispatch answers via LAN or Inter-net or both in an application. In the figure, feature-interaction mappings are listed and it can be seen that“AnsPackDispatch” has two related interactions whileothers have exact one related interaction.

From the figure, we can see that answer files of imageformat are produced by answer scan with the scanner.Image answer file and audio answer file are alternativeinputs for answer package and answer display. “An-swerPack” will produce answer packages, which can betransferred between grading server and client in answer

Fig.6. Segment of the feature context model for the CAGS domain.


dispatch via LAN or Internet. After that, graders re-siding on clients can review answers by monitors (imageanswer) or earphones (audio answer), input mark andcomments by keyboards, and then upload them to theserver via LAN or Internet.

Properties for contextual entities are also specified,e.g., properties defined in “OralExamination” showthat examinations in different applications can varyfrom in-school, region-level to entrance examinations.Descriptions of more contextual properties are omittedhere due to the limitation of the space in this paper.

5.1.4 Contextual Variability

The NFR analysis in our method is domain-oriented,so the feature context can involve domain-specific con-textual variations. In our feature context model, thecontextual variations can be embodied by the ALT/ORnodes and contextual properties.

The ALT and OR nodes in the feature context repre-sent alternative and OR contextual information, respec-tively. For example, in an application of the plannedCAGS SPL, the system can provide one or two gradingmodes of LAN- or Internet-based. It means that theLAN- or Internet-based grading is a variation point,and other network types (e.g., wireless network) neednot be considered in CAGS product line.

Contextual properties embody variations by theirvalues, e.g., the number of students participating in oralexamination is estimated to be 10∼100 000 in differ-ent applications. Therefore, both large- (over 10 000),medium- (thousands of examinees) and small-scale(hundreds of examinees) examinations should be wellsupported by the product line, e.g., in the considera-tion of server performance.

5.2 Nonfunctional Variability Identification

This subsection introduces the three nonfunctionalvariability analysis activities, then the example non-functional perspectives for CAGS as result of nonfunc-tional variability identification.

5.2.1 Goal Presence Analysis

The goal presence analysis evaluates presence sta-tus for each NFR goal. There are some NFRs that

are always desired by stakeholders, e.g., usability inFig.3. For these always-desired NFRs, the initial pres-ence conclusion is always mandatory, but their variabil-ity will be further evaluated according to NFR trade-offs. Other NFRs, such as transfer security are relatedto specific context. For these context-related NFRs, weintroduce NFR templates (general or domain-specific)as heuristics for the presence analysis. The NFR tem-plates characterize typical contextual situations wherecertain nonfunctional goals usually emerge. Then thegoal presence analysis can be performed by matchingbetween the feature context and NFR templates.

NFR templates provide heuristics for NFR analysisat two different levels. First, the NFR templates spec-ify basic context elements of the typical environmentwhere certain nonfunctional goal emerges. For moreparticular context levels, NFR templates identify keyfactors of contextual elements. These factors provide abasis for further variability analysis of NFR levels andoperationalizations, and NFR-integrated decision mod-eling.

The NFRs can be general or domain-specific. Ac-cordingly, NFR templates can also be general ordomain-specific. The NFR templates for transfer se-curity and “Compelled Grading Control” are presentedin Tables 2 and 3, respectively. The former is domain-independent, while the latter is specific to the CAGSdomain. From Table 2, we can see that transfer securityemerges in the information transfer via certain medium,and the basic context elements include the informa-tion transferred, the medium and potential wiretapper.Typical qualifications on these context elements are alsospecified, e.g., the medium is also accessible for poten-tial wiretapper, which can gain profit or curiosity fromstealing or forgery. The factors identified for transfersecurity analysis include publicity of the system, sensi-tivity of the transferred data and the stealing/forgerycapability of potential wiretappers.

For domain-specific NFR goals, corresponding tem-plates are also domain-specific. For example, the NFRtemplate for “Compelled Grading Control” is given inTable 3, which is defined by domain-specific contextualinformation on “Examination”. We can see “CompelledGrading Control” usually emerges in official examina-tions. These qualifications can help to determine the

Table 2. NFR Template for Transfer Security

Context Elements Qualification Factors

Overall Context Information transfer via the medium Publicity: publicity of the system

Data Sensitive data Sensitivity of data

Medium Medium for data transferring

Potential Wiretapper Someone who can access the same medium andgain profit or curiosity by stealing or forgery

Capability: the capability of practicing steal-ing or forgery


Table 3. NFR Template for “Compelled Grading Control”

Context Elements Qualification Factors

Examination Official Examination Examination Level

Examinee Number

Grader Number

variability on the goal. For example, if only high-endexaminations are targeted by the CAGS group, then itwill be a mandatory NFR goal. However, the currentCAGS group plans to cover both high- and low-end ex-aminations, so “Compelled Grading Control” will beevaluated to be an optional NFR goal.

Then NFR goals can be evaluated according to cor-responding templates and feature contexts. Heuristicrules for the initial NFR presence analysis are straight-forward:• NFR goals whose elements are common in all ap-

plications are evaluated to be mandatory;• NFR goals whose elements only emerge in part of

applications are evaluated to be optional.NFR conflicts are a main origin of nonfunctional

variations. After the initial presence analysis, irrelevantNFRs are removed, and then tradeoff analysis shouldbe performed for all the reserved goals. One of the mainconcerns is whether consistent tradeoff can be made foreach conflict, by considering all the systems within thetargeted SPL scope. If so, the conflict can be resolvedsimilarly to what is done for a single system. If not,the conflict will be suspended to be resolved in appli-cation engineering, and corresponding conflict-relatedvariations would appear.

The suspended NFR conflicts mean related NFRgoals may be abandoned in tradeoffs, so an addi-tional rule should be considered to embody this typeof conflict-related variations: If a mandatory NFR goalconflicts with other NFRs, then it should be adjusted tobe optional.

Part of the results from the NFR presence analysisfor CAGS domain is presented in Table 4. “Transfer Se-curity” is identified to be mandatory, since in all CAGSapplications sensitive answers and marks will be trans-ferred via networks. “Compelled Grading Control” isevaluated to be optional, since both high- and low-endin-school examinations are involved in the SPL scope.Other NFR goals can be determined to be mandatoryat the moment, but will be further evaluated in thefollowing steps.

5.2.2 NFR Level Analysis

NFR levels are the refinement of NFRs on sensibil-ity. NFR level analysis determines necessary levels for

each mandatory and optional NFR goal by evaluatingthe context factors identified in the corresponding NFRtemplates. One of the characteristics of the NFR levelsis that a higher level is always better than the lowerones. Therefore, from the aspect of single NFR goal,if multiple levels exist, higher one can always replacelower ones. However, in case if there are conflicts be-tween NFRs, lower NFR levels may also be reserved ifhigher one conflicts with other NFRs. Thus, the re-served NFR levels can constitute multiple candidatechoices together with other related NFRs to meet dif-ferent preferences. For example, medium “Transfer Se-curity” can be involved in low-end applications withmuch convenience and low cost of ownership.

Then we can summarize principles for NFR levelanalysis as follows:• If an NFR level does not conflict with any other

NFR goals, then lower levels of the same NFR shouldbe removed;• If NFR levels higher than a level conflict with other

NFR goals, the level should be reserved.According to the principles, low “Transfer Security”

can be removed, since the medium level does not con-flict with others; both medium and high “TransferSecurity” are reserved, since the high level conflictswith “Convenience of Use” and “Cost of Ownership”(see Fig.3).

5.2.3 Operationalization Analysis

Operationalization analysis evaluates operationa-lizations for all reserved NFR levels according to re-alistic possibility. Operationalizations provide real im-plementation support for different NFR levels. How-ever, they may depend on certain environmental condi-tions, e.g., “High Image Resolution” depends on “High-Resolution Monitor”. This kind of environmental de-pendencies should be further evaluated to eliminate in-applicable ones or adjust the options for NFR levels.Similar to the NFR presence analysis and level anal-ysis, the operationalization analysis also evaluates en-vironmental dependencies by considering all the sys-tems within the domain scope. The results can be “al-ways/fully satisfiable”, “partially satisfiable” or “unsat-isfiable”. For example, “Transfer with hard-cert. SSL”depends on “USB Key”, which is evaluated to be “al-ways satisfiable” although it requests additional costs.“High Image Resolution” depends on “High-ResolutionMonitor”, which is evaluated to be “partially satisfi-able”, since in some small schools, it is impossible toreplace the entire PC monitors only to meet the re-quirements of an electronic grading system.

Then we can summarize principles for the


operationalization analysis as follows:• if an operationalization is evaluated to be unsatis-

fiable, then it should be removed;• if all the operationalizations of an NFR level are

removed, then it should be removed;• if all the reserved operationalizations of an NFR

level are partially satisfiable, then it should be adjustedto be optional.

From the last two principles, it can be seen that theoperationalization analysis can further adjust the vari-ability setting of the NFR levels. For example, afteroperationalization analysis, “Electronic Answer Defini-tion” is adjusted to be optional, for its operationaliza-tion “High Image Resolution” can only be enabled bypart of the systems in the domain.

5.2.4 Variability-Integrated NonfunctionalPerspectives

After these steps, we can get the variability-integrated nonfunctional perspectives (see Table 4), in-cluding the reserved NFR goals and their optionalitysettings (mandatory or optional), NFR levels and op-erationalizations. Variations in nonfunctional perspec-tives are embodied at different levels (see Table 4 andthe NFR graph in Fig.3):• Optional NFR goals: optional NFR goals are op-

tional decomposition elements of their parent goals;• Alternative and OR sub-goals: if an NFR goal

has multiple reserved sub-goals of OR decomposition,they will constitute alternative or OR sub-goals of it,depending on whether they are exclusive or not.• Alternative NFR levels: multiple reserved NFR

levels for the same NFR goal represent alternative im-plementation levels.

As listed in Table 4, “Transfer Security” is deter-mined to be mandatory and alternative due to its twocandidate levels. “Compelled Grading Control”, “Elec-tronic Answer Definition” and “Do-as-Please (Spoken)”are evaluated to be optional, since each of them has onlyone applicable level. These nonfunctional variationswill be integrated into the feature model and featuredecision model. In order to provide decision bases forthe decision model, related NFR conflicts and rationalare also attached.

5.3 NFR Integration

NFR goals are soft-goals, which are continuouslydecomposed into sub-goals until they can be satisfied(operationalized) by operationalizations[1]. In order toensure the realization of desired NFR goals, relatedgoals and operationalizations should first be incorpo-rated into the feature model. Then variations embodiedin the NFR goals should be treated to be properly em-bodied in a feature model. Finally, NFR-related vari-ability constraints should be elicited for NFR decisionmodeling.

5.3.1 Operationalization Incorporation

In the NFR integration, it is necessary to considerwhere the initial conceptual model will be affected bythe operationalizations and how to include them[1]. Thefirst problem can be resolved by using the heuristicsfrom NFR goal presence analysis, since each reservedNFR goal is evaluated to be mandatory or optional by

Table 4. Part of the Variability-Integrated Nonfunctional Perspectives for CAGS Domain

NFR Goal Optionality Levels Operationalization Conflicts Rational

TransferSecurity

Mandatory Medium Transfer with SSL(with soft cert.)

None Concerned in all CAGSsystems

High Transfer with SSL(with hard cert.)

Convenience of UseCost of Ownership

Authentication Mandatory Medium Soft-cert-basedauthentication

None Concerned in all CAGSsystems

High Hard-cert-basedauthentication

Convenience of UseCost of Ownership

CompelledGradingControl

Optional N/A Grading surveillance

Must finish the wholeanswer record

Do-as-please (Spoken) Concerned in high-endexaminations

Electronic An-swer Definition

Optional N/A High image resolution None Always desired by users butonly partially applicable in thedomain

Do-as-Please(Written)

Mandatory N/A Image zoom None Always desired by users

Do-as-Please(Spoken)

Optional N/A Audio speeding CompelledGrading Control

Always desired by users, butconflicts with other NFRs


matching between NFR templates and context infor-mation of certain feature. For example, “Transfer Se-curity” affects the functional features involved in sen-sitive data transfer on the network, i.e., “AnsPack-Dispatch”, “Mark&CommentsUpload”, “Query&Stat.”and “Check&Mediation” in the CAGS domain. There-fore, reserved NFR levels and operationalizations for“Transfer Security” can be attached to these features.As for how to integrate operationalizations into the fea-ture model, we have the following rules:• dynamic operationalization is integrated as a sub-

feature of the affected functional feature;• static operationalization is integrated as restriction

on the affected functional feature;• dynamic operationalizations for NFR goals af-

fecting multiple functional features are considered ascrosscutting features, and interactions between affectedfeatures and these crosscutting features should berecorded.

5.3.2 Nonfunctional Variability Treatment

As shown in Subsection 5.2.4, nonfunctional varia-tions are embodied in NFR goals and levels. These vari-ations should be further treated to be properly embod-ied in the feature model. Considering dynamic/staticoperationalizations and the three kinds of variations ofoptional/alternative/OR elements, we have the follow-ing rules:• integrated dynamic operationalization should be

set to be optional if the responding NFR goal is op-tional;• integrated static restriction should be set to be

optional if the responding NFR goal is optional, and

then the optional restriction should be transformed to afacet to provide customizable choices and non-optionalrestriction transformed to an implementation note forthe feature;• if an NFR goal has multiple OR sub-goals, then

operationalizations for these goals are integrated as al-ternative/OR sub-features;• if an NFR goal has multiple reserved levels, then

operationalizations for these levels are integrated as al-ternative sub-features.

In domain analysis and design, separating common-ality/variability and localizing variations are the pri-mary considerations to maximize the reusability of SPLassets. After operationalization incorporation and vari-ability treatment, optional or alternative restrictionsmay be imposed on functional features, so an addi-tional rule should be considered: functional featuresinfluenced by optional or alternative nonfunctional re-strictions should be refined to further separate common-ality/variability and localize variations. For example,“Login” is identified as an atomic feature in the initialfeature model (see Fig.2), since there are no variationswithin it. When the variable NFR goal “Authentica-tion” (medium or high level) is attached to it, the fea-ture “Login” should be refined to localize the variabil-ity within “Authentication” and reserve commonalityin the separated feature “Initialization” (initialize theuser and system information after successful login, seeFig.7).

Following the rules of operationalization incorpora-tion and nonfunctional variability treatment, we can getthe CAGS feature model with NFRs as shown in Fig.7(some elements are omitted for clearness), in which the

Fig.7. CAGS feature model with NFRs.


NFR-related features are represented by dashed panesand NFR goals are connected with their operational-izations. In the figure, “ImageZoom” is set to bemandatory since “Do-as-Please (Written)” is manda-tory, “AudioSpeeding” and “GradingSurveillance” areset to be optional since “Do-as-Please (Spoken)” and“Compelled Grading Control” are optional. “Must Fin-ish the Whole Answer Record” and “High Image Reso-lution” are integrated as facets imposed on correspond-ing features to provide different choices in applicationengineering, since they are for optional NFR goals.“Transfer with SSL” is a new abstract feature to rep-resent the choice of the two levels of high and medium.It is also a crosscutting feature, so it is extracted fromthe four affected features and corresponding crosscut-ting interactions are recorded.

5.3.3 Constraint Elicitation

The variations embodied in the domain featuremodel are to be resolved in application engineering toacquire different customizations. The variability reso-lutions are embodied by determining the binding-states(bound, removed or pending) of the optional, alterna-tive and OR features. The customizations are not free,but restricted by feature constraints. Constraint is akind of static dependency among binding-states of fea-tures, and provides a way to verify the results of re-quirement customization and release planning[8].

The most-used constraints in the feature model arerequires and excludes, in which constraint “A requiresB” denotes that if A is bound then B must be boundtoo, and “A excludes B” means A and B cannot bebound together. Detailed discussions on feature con-straints can be found in [8].

Constraints first exist in the initial functional fea-ture model, such as constraints C1∼C5 presented inTable 5. For example, if the CAGS application servesfor synthetic examinations, then the answer packagesmust be dispatched by questions according to C5 (syn-thetic examination paper is composed of questions ofdifferent subjects), and “ImgShow” and “ImgAnsAc-quire” are bound according to C3 and C4 (“synthe-ticExam” must be “writtenExam”). These functionalfeature constraints can be identified in variability anal-ysis, which is involved in most feature-based domainanalysis methods.

In our method, NFR-related features and variationsare integrated into the feature model along with cor-responding NFR goals. These NFR goals may conflictwith other NFRs or depend on certain environmentalconditions (see Table 4). These kinds of conflicts anddependencies will bring new constraints into the feature

model, such as constraints C6∼C8 in Table 5. NFR-related constraints can be categorized as follows:• NFR-dependency-related constraints. Operatio-

nalizations dependencies bring requires constraints be-tween corresponding features, e.g., C6 and C7.• NFR-conflict-related constraints. Operationaliza-

tions for conflicting NFR goals have excludes con-straints between corresponding features, e.g., C8.

5.4 NFR Decision Modeling

Decision model provides a systematic decision pathfor application customization. In the decision model,each variation point in domain assets should be con-nected to an open decision in the decision model[9]. Thedecision model for feature model can be denoted by adecision tree, in which decision points are structuredin a partial order. Feature decision model can be con-structed by analyzing the partial orders between vari-ations. For example, by considering C1∼C5 only, wecan see that whether “spokenExam” or “writtenExam”should be determined first, then whether “synthet-icExam” or “subjectExam” should be determined, sincethe latter choice is the refinement of the former.

After NFR-related features and constraints are in-corporated into the feature model, we should also inte-grate NFR-related decisions into the decision model.Besides feature constraints, there are another threekinds of external dependencies that can influence thedecision model:• NFR conflicts. Suspended NFR conflicts bring de-

cision points of different tradeoff choices;• NFR dependencies. If NFR goal A depends on

NFR goal B, then B will be chosen if A is bound byprevious decisions.• Environmental dependencies. If an NFR op-

erationalization depends on certain environmentalcondition, then the condition should be involved in thedecision model.


Decision model is constructed for variation resolu-tion, so only optional and alternative goals and fea-tures are taken into account in decision modeling. NFRgoals concerned by clients are primary decision points,so they should first be considered in NFR decision mod-eling based on NFR conflicts and dependencies. Usu-ally, in NFR goal decision, higher goals should be evalu-ated first, if chosen then their mandatory sub-goals arechosen automatically and optional sub-goals are evalu-ated sequentially. In the process, if NFR dependenciesare involved, then required NFR goals are also chosen;if a current NFR goal is involved in conflicts, then atradeoff decision should be made. Usually there is adominant NFR goal in NFR conflict, e.g., in conflictbetween security and cost/convenience, security is usu-ally dominant. Therefore, in decision modeling, thedominant NFR goal in a conflict is evaluated first andconflicting goals are taken as tradeoff annotations onthe decision point. For example, in Fig.8, “with someinconvenience and additional cost” is annotated withthe choice “high” for “Transfer Security Level”.

NFR decisions can also be related to functional deci-sions, if the goal is related to an optional or alternativefunctional feature. In this case, NFR decision is re-lated to the functional decision as a next decision. Forexample, “Compelled Grading Control” is a next de-cision point after “Exam Type”, since it is related to“AudioPlay” and should be determined after “Audio-Play” is bound. Environmental dependencies are alsomodeled as decision points according to similar policies,

e.g., “High-Resolution Monitor” in Fig.8 is consideredafter “ExamType” is determined to be “written”. Be-sides these decision points, other functional or nonfunc-tional decision points can be placed in the decision treeaccording to inter-feature constraints.

The final NFR-integrated CAGS feature decisionmodel is presented in Fig.8, in which decision pointsare denoted by ellipses with “?” mark, decisions arerepresented by arrows, bound features are listed in thepane after corresponding decisions are made. Deci-sions made at each decision point are labeled on thearrows that follow, and arrows without labels representthe next decision points. In the decision model, onlyvariability-related features are involved. For example,“ImageZoom” in Fig.7 is not included in Fig.8, since itis a mandatory feature. From the decision model, wecan see that “ExamType” and “Trasfer Security Level”are two main variations and they are orthogonal. “Ex-amType” is followed by decisions for “Compelled Grad-ing Control” and “High-Resolution Monitor”. The de-cision for “Transfer Security Level” also determines theauthentication policy according to the dependency be-tween these two NFR goals.

6 Evaluation and Discussion

6.1 Evaluation

The feature model, as a product of domain analysisin SPL development, should comprehensively embodyrequirements of all the applications in the domain from

Fig.8. NFR-integrated CAGS feature decision model.


both functional and nonfunctional perspectives. Some-times, obvious NFRs can be naturally identified and in-corporated in the feature model, but other vague NFRsmay be omitted, not to mention nonfunctional varia-tions, which often originate from implicit factors suchas NFR conflicts, NFR dependencies and environmen-tal dependencies, etc. Therefore, nonfunctional require-ments analysis in SPL development is still a big chal-lenge.

The method proposed in this paper provides a sys-tematic process for NFR analysis in SPL development.It is a good complement to traditional feature-baseddomain analysis methods. The effectiveness of themethod has been well recognized by related engineersthrough the comprehensive method application withthe CAGS group, although additional analysis and con-siderations are required. Feedbacks indicate that themethod helped the product line development in severalaspects:

1) the existence and variability of implicit NFRs em-bodied in NFR graphs, feature contexts and NFR tem-plates help a lot with NFR elicitation and variabilityidentification;

2) nonfunctional variations are analyzed from multi-ple aspects of contexts, where those nonfunctional con-cerns originate from, NFR conflicts and environmen-tal dependencies, by providing comprehensive clues fornonfunctional variability analysis;

3) incorporation of NFRs with their variations infeature model helps produce better product line designwith more comprehensive variability considerations(e.g., commonality/variability separation and variationlocalization);

4) the decision model with combined functional andnonfunctional perspectives eases the communicationswith customers by explicitly stating all the decisionchoices on functional, nonfunctional concerns and ex-ternal conditions in an integrated mode.

Besides the CAGS product line, we are also conduct-ing a case study on another Web-based product line ofcollege financial management system, which also em-bodies some critical nonfunctional requirements, e.g.,security, traceability of financial affairs, etc.

6.2 Discussion

As stated in [1], NFRs have received little atten-tion in literature in spite of their importance. Sutcliffeet al.[3] also mentioned that existing work focused toomuch on user activity and system functionality, ratherthan system qualities, generally referred to as nonfunc-tional requirements. The neglect is even more seriousin SPL development. This is partly due to very vague

nature of nonfunctional requirements[1−4] and nonfunc-tional variations. Most NFRs are closely tied with func-tional requirements, so they are often difficult to dis-tinguish from each other. On the other hand, nonfunc-tional variations often originate from NFR tradeoffs,which makes them more confused.

1) Nonfunctional Features vs. Functional FeaturesMost NFRs have close ties with functional specifi-

cation and are gradually refined into the requirementspecification, leading some to argue that NFRs areredundant[3]. For example, most NFR goals concernedin the CAGS domain are integrated as functional fea-tures or restrictions imposed on functional features (seeFig.7). Another typical example of the confusion is“Check&Mediation”, which is also a great contribu-tion to “Grading Reliability” by conducting additionalgrade checking and mediation when large divergenceemerges. However, it is identified as a functional featurefrom the beginning (see Fig.2), because it has been aningrained part of grading for most of the clients. Thisfurther illuminates that it is hard to distinguish func-tional and nonfunctional requirements in many cases.

However, NFR analysis is still essential to mostcases, especially to the SPL development. First, thereare still some NFRs without obvious operationaliza-tions, e.g., cost of ownership. Second, in most cases,NFR goals are first identified then operationalized intocorresponding functions, e.g., security-related func-tions. Third, systematic analysis of NFR origins, con-textual factors, and operationalizations can help tohave comprehensive nonfunctional perspectives, includ-ing applicable NFR level, conflicts and variations. Forexample, the NFR templates and feature contexts inour method provide the basis of nonfunctional variabil-ity analysis.

2) Nonfunctional Variations vs. NFR TradeoffsIt can be observed that most nonfunctional varia-

tions originate from tradeoffs of conflicting NFRs, oth-erwise a high-level nonfunctional quality is always de-sired. For example, the reason why high-level securityis not chosen in some of the applications is due to thecost of additional hard-certifications and the influenceon the usability issues. The conflict detection and res-olution for NFRs are also common in a single productdevelopment (e.g., [1]). However, nonfunctional vari-ability analysis in SPL is more than conflicts identi-fication and resolution. In a single product develop-ment, tradeoff decisions can be made only from theconcerns in the current system. While in SPL devel-opment, NFR tradeoffs are first made in domain engi-neering for all the systems within the SPL scope, andthen completely resolved in application engineering.


Some NFR tradeoffs can be made in domain engineer-ing, if consistent decisions can be made for all the sys-tems. For example, if the CAGS group is targetinghigh-end markets only, then the tradeoff between secu-rity and cost/convenience can be made to choose hard-certification-based authentication and transfer in do-main engineering. In this situation, authentication andtransfer will not become variations, since a unified de-cision can be made for all the systems. However, if aconsistent tradeoff cannot be made, then correspondingconflicts will bring variations into the domain model,e.g., the conflict between security and cost/conveniencein current CAGS SPL (see Fig.7). In domain analysis,these conflict-caused nonfunctional variations should beidentified and integrated into the feature model to pro-vide a basis for domain design and implementation.

7 Related Work

An NFR knowledge base is usually employed in NFRanalysis due to the vagueness of NFRs and the similari-ty of NFR properties in different systems. For example,the knowledge base used in [1] records possible refine-ments and operationalizations for each NFR item, themethod proposed in [3] contains a template for eachhigh-level NFR with embedded heuristics for scenariocreation, validation and benchmark assessment by met-rics. Cysneiros et al.[1] propose a systematic processof NFR elicitation and incorporation into UML-basedconceptual models. Their elicitation process is basedon the use of a lexicon that will not only be used toanchor both functional and nonfunctional models, butalso to drive the NFR elicitation. In their method,NFRs are integrated into UML diagrams, including theClass, Sequence, and Collaboration Diagrams. NFRconflict identification and resolution are also involvedin the method. Sutcliffe et al.[3] propose an analysismethod that describes scenario templates for NFRs,with heuristics for scenario generation, elaboration andvalidation. Liu et al.[14] propose a method of analyz-ing security and privacy requirements based on socialrelationships between problem domain actors using thei∗ modeling language. The method involves techniquesthat assist attacker, vulnerability, countermeasure anal-ysis and access control analysis.

These NFR analysis methods introduced above havesimilar concepts in context- or scenario-based NFR elic-itation, separation then integration of functional andnonfunctional perspectives, and the analysis with anNFR knowledge base. However, they all concentrateon NFR analysis for single software-intensive systemsand do not consider nonfunctional variability analysisand integration for a series of similar systems.

Lee et al.[18] propose a framework that integratesthe notions of goals, scenarios, and viewpoints by us-ing the ontological domain modeling techniques. Theframework has been applied to the information secu-rity requirements domain analysis for the US DoD(Department of Defense) information system Certifi-cation and Accreditation (C&A) activities[19]. Theontological domain requirements model is constructedfrom various regulatory documents at different levelsof abstractions[20]. It is notable that the NFRs in theC&A process are modeled and represented as both ta-xonomical and non-taxonomical ways and later furtherrelationships are inferred through the interaction withthe domain analysts. We believe our work can adoptsome of these modeling techniques with ontological ex-pressive power to perform and improve the NFR anal-ysis in SPL development.

In recent SPL researches, nonfunctional features areoften referred to together with functional features in do-main analysis. For example, Kang et al.[7] propose thatnonfunctional features are identified from the market-ing plan, and they should be identified together withfunctional features in domain analysis for SPL assetdevelopment. Yu et al.[16] propose a process that gen-erates a high variability software design from a goalmodel. The process is supported by heuristic rules thatcan guide the design. The method includes generatingfeature model from variability-embodied goal model.Soft goals that represent stakeholder preferences arealso mentioned, but nonfunctional variability identifi-cation and integration are not. Moon et al.[5] also indi-cate that any quality item that occurs in the nonfunc-tional requirements should have a relationship to func-tional requirements and other quality items. Liaskos etal.[17] propose a goal-based variability acquisition andanalysis method based on the semantic characterizationof OR-decompositions of goals. The method addressesvariability-intensive goal refinement and derivation, butthe integration with functional feature model is notconsidered. Halmans et al.[12] indicate that the cate-gory quality in SPL development subsumes variabilityaspects concerning nonfunctional/quality requirementssuch as security, availability or scalability. They pro-pose use cases as communication medium for the SPLvariability, and indicate that use cases are not suitedto document essential variability concerning the qual-ity. They emphasize that quality-related variability as-pects must be interrelated with the functional and envi-ronmental variability aspects, but do not involve NFRanalysis and representation in their method.

From the above work, we can learn NFR analysis inSPL development has been recognized in some of the


current SPL researches. In these studies, it is treatedas NFR analysis for a single system in most cases, e.g.,NFRs in SPL are considered as holistic requirements ofall the systems. However, marketing plan of an SPLmay cover applications with diverse nonfunctional con-cerns. For example, the CAGS group involves bothhigh-end (high security and reliability with additionalcost and some inconvenience) and low-end (convenientand without additional cost) examinations in their tar-geted markets. Therefore, nonfunctional variations exi-st in some SPLs and are essential to domain analysis.Our method proposed in this paper focuses on nonfunc-tional variability analysis and integration, providing asystematic way for NFR elicitation, variability analysis,integration and decision modeling.

8 Conclusion and Future Work

In SPL development, NFRs and nonfunctional vari-ations should be carefully identified and presented indomain analysis, just as what has been done for typ-ical functional requirements, to provide a comprehen-sive basis for variability-oriented design and implemen-tation. NFRs are usually hidden in everyone’s minds[1],so NFR elicitation is difficult, and it is even harder inSPL development for the requirements to analyze non-functional variations among different systems that existwithin a domain. In this paper, we propose a context-based method of NFR analysis for SPL development. Inthe method, NFRs are materialized by connecting NFRgoals with real-world context, so nonfunctional variabil-ity analysis can be performed by context analysis for thewhole domain. After variability analysis, our methodintegrates both the functional and nonfunctional per-spectives by integrating NFR-related goals and oper-ationalizations into the initial functional domain fea-ture model. NFR-related constraints are also elicitedto construct the NFR-oriented decision model to facili-tate application-oriented feature model customization.

In our future work, we will concentrate on more sys-tematic NFR-oriented analysis and design method forSPL development, including NFR elicitation, variabil-ity analysis and NFR-oriented variability design. Onthe other hand, we will try to integrate the method intoour existing tools for SPL analysis and implementation,and perform more case studies on SPL development forhigh-confidence domains. We will integrate the NFRanalysis method proposed in this paper into our fea-ture modeling tool[10] to enrich the nonfunctional fea-ture modeling capability, including context modeling,nonfunctional variations identification and representa-tion, NFR integration and decision modeling, etc. Wewill also integrate the comprehensive decision model

into our recently developed product derivation tool[11]

to provide systematic feature decision support for ap-plication generation.

References

[1] Luiz Marcio Cysneiros, Julio Cesar Sampaio do Prado Leite.Nonfunctional requirements: From elicitation to conceptualmodels. IEEE Trans. Software Eng., 2004, 30(5): 328–350.

[2] Mylopoulos J, Chung L, Nixon B A. Representing and us-ing nonfunctional requirements: A process-oriented approach.IEEE Trans. Software Eng., 1992, 18(6): 483–497.

[3] Sutcliffe A, Minocha S. Scenario-based analysis of non-functional requirements. In Proc. Workshop on RequirementsEngineering for Software Quality (REFSQ’98) at CAiSE’98,Pisa, Italy, June 8–9, 1998, pp.219–234.

[4] Chung L, Nixon B A, Yu E, Mylopoulos J. Non-Functional Re-quirements in Software Engineering. Kluwer Academic Pub-lishers, 2000.

[5] Moon M, Yeom K, Chae H S. An approach to developing do-main requirements as a core asset based on commonality andvariability analysis in a product line. IEEE Trans. SoftwareEng., 2005, 31(7): 551–569.

[6] Kang K, Cohen S, Hess J, Nowak W, Peterson S. Feature-oriented domain analysis (FODA) feasibility study. TechnicalReport CMU/SEI-90-TR-21, Software Engineering Institute,Carnegie Mellon University, Pittsburgh, PA, November 1990.

[7] Kang K C, Donohoe P, Koh E, Lee J, Lee K. Using a mar-keting and product plan as a key driver for product line assetdevelopment. In Proc. the 2nd Int. Conf. Software ProductLines (SPLC), San Diego, CA, USA, August 19–22, 2002,pp.366–382.

[8] Zhang W, Mei H, Zhao H. Feature-driven requirement depen-dency analysis and high-level software design. RequirementsEng., 2006, 11(3): 205–220.

[9] Cristina Gacek, Michalis Anastasopoules. Implementingproduct line variabilities. In Proc. the 2001 Int. SoftwareReusability Symp. (SSR), Toronto, Ontario, Canada, May18–20, 2001, pp. 109–117.

[10] Peng X, Zhao W, Xue Y, Wu Y. Ontology-based feature mod-eling and application-oriented tailoring. In Proc. the 9th Int.Conf. Software Reuse (ICSR), Turin, Italy, June 12–15, 2006,pp.87–100.

[11] Peng X, Shen L, Zhao W. Feature implementation modelingbased product derivation in software product line. In Proc.the 10th Int. Conf. Software Reuse (ICSR), Beijing, China,May 25–29, 2008, pp.142–153.

[12] Halmans G, Pohl K. Communicating the variability of asoftware-product family to customers. Software and SystemModeling, 2003, 2(1): 15–36.

[13] Jin Z. Revisiting the meaning of requirements. J. Comput.Sci. & Technol., 2006, 21(1): 32–40.

[14] Liu L, Yu E, Mylopoulos J. Security and privacy requirementsanalysis within a social setting. In Proc. the 11th IEEE Int.Conf. Requirements Engineering (RE), Monterey Bay, CA,USA, September 8–12, 2003, pp.151–161.

[15] Wu Y, Zhao W, Peng X, Xue Y. A computer aided grad-ing system for subjective tests. In Proc. the 2006 AdvancedInt. Conf. Telecommunications and Int. Conf. Internet andWeb Applications and Services (AICT/ICIW), Guadeloupe,French Caribbean, February 19–25, 2006, p.2.

[16] Yu Y, Lapouchnian A, Liaskos S, Mylopoulos J, Leite J C S P.From goals to high-variability software design. In Proc. the17th Int. Symposium on Methodologies for Intelligent Sys-tems (ISMIS), Toronto, Canada, May 20–23, 2008, pp.1–16.


[17] Liaskos S, Lapouchnian A, Yu Y, Yu E, Mylopoulos J. Ongoal-based variability acquisition and analysis. In Proc. the14th IEEE International Conference on Requirements En-gineering (RE), Minnesota, USA, September 11–15, 2006,pp.76–85.

[18] Lee S W, Gandhi R A. Ontology-based active requirementsengineering framework. In Proc. the 12th Asia-Pacific Soft-ware Eng. Conf. (APSEC), Dec. 15–17, 2005, pp.481–490.

[19] Lee S W, Gandhi R A. Requirements as enablers for soft-ware assurance. CrossTalk: The Journal of Defense SoftwareEngineering, 2006, 19(12): 20–24.

[20] Lee S W, Muthurajan D, Gandhi R A, Yavagal D, Ahn G.Building decision support problem domain ontology from se-curity requirements to engineer software-intensive systems.Int. Journal on Software Eng. and Knowledge Eng., 2006,16(6): 851–884.

Xin Peng is an assistant profes-sor in the School of Computer Sci-ence, Fudan University, China. Hereceived his Ph.D. degree from Fu-dan University in 2006. He is amember of China Computer Federa-tion. His current research interestsinclude software product line, soft-ware component and architecture,software maintenance and software

reengineering.

Seok-Won Lee is an assistantprofessor in the Dept. Softwareand Information Systems, The Uni-versity of North Carolina at Char-lotte. He received his B.Sc. degreein computer science from DongkukUniversity at Seoul, Republic of Ko-rea, M.Sc. degree in computer sci-ence from University of Pittsburgh atPittsburgh, Pennsylvania, USA, and

Ph.D. degree in information technology from George MasonUniversity at Fairfax, Virginia, USA. His areas of specializa-tion include software engineering with specific expertise inontological requirements engineering and domain modeling,and knowledge engineering with specific expertise in knowl-edge acquisition, machine learning and knowledge-basedsystems. He is currently leading the Knowledge-IntensiveSoftware Engineering Research Group (NISE) at the UNCCharlotte.

Wen-Yun Zhao is a full profes-sor and director of Software Engi-neering Lab in the School of Com-puter Science, Fudan University,China. He received his M.S. degreefrom Fudan University in 1989. He isa senior member of China ComputerFederation. His current research in-terests include software reuse, soft-ware product line, software compo-

nent and architecture.

feature-oriented nonfunctional requirement analysis for ... · keywords software product line,...

Documents