A conceptual basis for feature engineering

C. Reid Turner a,1, Alfonso Fuggetta b,*, Luigi Lavazza b,2, Alexander L. Wolf a,3

a Department of Computer Science, University of Colorado, Boulder, CO 80309, USAb Dipartimento di Elettronica e Informazione, Politecnico di Milano, Piazza Leonardo da Vinci 32, Milano 20133, Italy

Received 13 April 1998; received in revised form 10 August 1998; accepted 4 December 1998

Abstract

The gulf between the user and the developer perspectives lead to di�culties in producing successful software systems. Users are

focused on the problem domain, where the system's features are the primary concern. Developers are focused on the solution

domain, where the system's life-cycle artifacts are key. Presently, there is little understanding of how to narrow this gulf.

This paper argues for establishing an organizing viewpoint that we term feature engineering. Feature engineering promotes

features as ®rst-class objects throughout the software life cycle and across the problem and solution domains. The goal of the paper

is not to propose a speci®c new technique or technology. Rather, it aims at laying out some basic concepts and terminology that can

be used as a foundation for developing a sound and complete framework for feature engineering. The paper discusses the impact

that features have on di�erent phases of the life cycle, provides some ideas on how these phases can be improved by fully exploiting

the concept of feature, and suggests topics for a research agenda in feature engineering. Ó 1999 Elsevier Science Inc. All rights

reserved.

1. Introduction

A major source of di�culty in developing and deliv-ering successful software is the gulf that exists betweenthe user and the developer perspectives on a system. Theuser perspective is centered in the problem domain.Users interact with the system and are directly con-cerned with its functionality. The developer perspective,on the other hand, is centered in the solution domain.Developers are concerned with the creation and main-tenance of life-cycle artifacts, which do not necessarilyhave a particular meaning in the problem domain.Jackson notes that developers are often quick to focuson the solution domain at the expense of a properanalysis of the problem domain (Jackson, 1995). Thisbias is understandable, since developers work primarilywith solution-domain artifacts. Yet the majority of their

tasks are motivated by demands emanating from theproblem domain.

Looking a bit more closely at this gulf in perspectives,we see that users think of systems in terms of the featuresprovided by the system. Intuitively, a feature is a co-herent and identi®able bundle of system functionalitythat helps characterize the system from the user per-spective. Users report defects or request new function-ality in terms of features. Developers are expected toreinterpret such feature-oriented reports and requestsinto actions to be applied to life-cycle artifacts, such asmodifying the appropriate set of implementation ®les.The easier the interpretation process can be made, thegreater the likelihood of a successful software system.The key, then, is to gain a better understanding of thenotion of feature and how that notion can be carriedforward from the problem domain into the solutiondomain.

As an illustration of the central importance of fea-tures, consider the software in a large, long-lived systemsuch as a telephone switch. This kind of system iscomposed of millions of lines of code, and includesmany di�erent types of components, such as real-timecontrollers, databases and user interfaces. The softwaremust provide a vast number of complex features to itsusers, ranging from terminal services, such as ISDN, callforwarding and call waiting, to network services, such as

The Journal of Systems and Software 49 (1999) 3±15www.elsevier.com/locate/jss

* Corresponding author. Tel.: +39-02-2399-3540; fax: +39-02-2399-

3411; e-mail: alfonso.fuggetta@polimi.it1 E-mail: reid@cs.colorado.edu2 E-mail: lavazza@elet.polimi.it3 E-mail: alw@cs.colorado.edu

0164-1212/99/$ - see front matter Ó 1999 Elsevier Science Inc. All rights reserved.

PII: S 0 1 6 4 - 1 2 1 2 ( 9 9 ) 0 0 0 6 2 - X

call routing, load monitoring and billing. 4 Somehow,the software that actually implements the switch must bemade to exhibit these features, as well as to toleratechanges to the features in a cost-e�ective manner. BellLaboratories, for example, developed a design in thesolution domain for its 5ESSÒ switch software by fol-lowing a layered architectural style (Carney et al., 1985).This was supposed to result in a clean separation ofconcerns, permitting features to be more easily addedand modi®ed.

Despite the continuing interest in the notion of fea-ture, to date there has been little work speci®cally ad-dressing its support throughout the life cycle.Nevertheless, one does ®nd the notion used in severalrelevant, if limited, ways.· In domain analysis and modeling, the activity of

feature analysis has been de®ned to capture a custom-er's or an end user's understanding of the generalcapabilities of systems in an application domain(Kang et al., 1990; Krut, 1993). Domain analysis usesthe notion of features to distinguish basic, corefunctionality from variant, optional functionality(Gomaa et al., 1994). Although features are an explic-it element of domain models, their connection to oth-er life-cycle artifacts is e�ectively non-existent.

· There has been work on so-called requirements clus-tering techniques (Hsia and Gupta, 1992; Palmerand Liang, 1992), which would appear to lend itselfto the identi®cation of features within requirementsspeci®cations. But they do not address the questionof how those features would be re¯ected in life-cycleartifacts other than requirements speci®cations andin a restricted form of design prototypes.

· Cusumano and Selby (1995) describe the strong ori-entation of software development at Microsoft Cor-poration toward the use of feature teams andfeature-driven architectures. That orientation, how-ever, has more to do with project management thanwith product life-cycle artifacts and activities. Cusu-mano and Selby o�er no evidence that the notion offeature has been driven throughout the developmentprocess, although doing so would seem natural insuch a context.

· Several researchers have studied the feature interac-tion problem, which is concerned with how to identify,prevent and resolve con¯icts among a set of features(Aho and Gri�eth, 1995; Cameron and Velthuijsen,1993; Gri�eth and Lin, 1993; Lin and Jazayeri,1998; Zave, 1993). The approaches identi®ed in thisliterature do not provide insight into the role of fea-tures across the full range of life-cycle activities and

the ability of features to span the problem and solu-tion domains.

· Automatic software generation is based on an analysisof a domain to uncover reusable components (Batoryand O'Malley, 1992; Sitaraman, 1992). The compo-nents are grouped into subsets having the samefunctional interface; a complete system is created bychoosing an appropriate element from each subset.The choice is based on the ``features'' exhibited bythe elements. Here, the term feature is essentiallyrestricted to extra-functional characteristics of acomponent, such as performance and reliability.Functionally equivalent systems having di�erentextra-functional characteristics can then be automat-ically generated by specifying the desired features ±that is, the extra-functional characteristics. Al-though this work represents an important elementin support of features, it needs to be extended toencompass the generation of functionally dissimilarsystems through selection of functional characteris-tics.

Thus, there is a growing recognition that features act asan important organizing concept within the problemdomain and as a communication mechanism betweenusers and developers. There has also been some limiteduse of the concept to aid system con®guration in thesolution domain. There is not, however, a commonunderstanding of the notion of feature nor a full treat-ment of its use throughout the life cycle.

We have set out to develop a solid foundation for thenotion of feature and, more importantly, for carrying afeature orientation from the problem domain into thesolution domain. We term this area of study featureengineering. The major goal behind feature engineeringis to promote features as ``®rst-class objects'' within thesoftware process, and thus have features supported in abroad range of life-cycle activities. These activitiesinclude identifying features in requirements speci®ca-tions, evaluating designs based on their ability toincorporate new and modi®ed features, understandingthe relationship between a software architecture andfeature implementation mechanisms, uncovering fea-ture constraints and interactions, and con®guringsystems based on desired feature sets. Features are thusan organizational mechanism that can structure impor-tant relationships across life-cycle artifacts and activi-ties.

This paper proposes some basic concepts for featureengineering and evaluates the potential impact of thisdiscipline on software life-cycle activities. It is based onour experience in applying feature concepts to themodeling of several software systems, including thesoftware of an Italtel telephone switch, and in evaluatingthe support for a feature orientation o�ered by theleading commercial con®guration management systems.This paper does not, however, attempt to report on

4 Note that from the perspective of a switch builder, network services

are not simply internal implementation functions, but are truly system

features, since they must be made available to external organizations,

such as telecommunications providers.

4 C. Reid Turner et al. / The Journal of Systems and Software 49 (1999) 3±15

particular solutions to problems in software engineering,but rather to articulate a framework within which so-lutions might be developed and assessed. Therefore, thispaper should be considered a ®rst step toward thecomplete and detailed de®nition of feature engineeringand of its relationship with other domains of softwareengineering.

In Section 2 we discuss a typical entity-relationshipmodel of life-cycle artifacts and show how features canbe incorporated into that model. We then describe theapplication of feature engineering to a variety of lifecycle activities. In Section 4 we present a study of theItaltel telephone switch software that serves as an initialvalidation of some of the principal ideas developed inthis paper. We conclude with our plans for futureresearch in feature engineering.

2. The role of features within the process

The term ``feature'' has been in common use formany years. In 1982, for instance, Davis identi®ed fea-tures as an important organizational mechanism forrequirements speci®cations.

`` for systems with a large number of internal states,it is easier, and more natural, to modularize thespeci®cation by means of features perceived bythe customer.'' (Davis, 1982)

In a recent survey on feature and service interaction intelecommunication systems, Keck and Kuehn mention asimilar de®nition developed by Bellcore.

``The term feature is de®ned as a `unit of one ormore telecommunication or telecommunicationmanagement based capabilities a network providesto a user'. . .'' (Keck and Kuehn, 1998)

Unfortunately, despite these attempts to precisely de®nethe notion of feature, the term is often interpretedin di�erent and somewhat con¯icting ways. Here,we present and evaluate three candidate de®nitionsthat are intended to capture the range of interpretat-ions commonly used in the software engineeringcommunity. The ®rst de®nition refers to the interpr-etation of the term feature as o�ered by most of thescienti®c literature on the subject, including the twoexamples above. The other two de®nitions representother interpretations of the term feature, as used espe-cially by practitioners. Our intent here is to emphasizethe di�erences among these interpretations, to indicatehow they are interrelated, and therefore, how they canbe eventually reconciled.

2.1. An informal de®nition

At the most abstract level, a feature represents a co-hesive set of system functionality. Each of the threecandidate de®nitions identi®es this set in a di�erent way.1. Subset of system requirements. Ideally, the require-

ments speci®cation captures all the important behav-ioral characteristics of a system. A feature is agrouping or modularization of individual require-ments within that speci®cation. This de®nition em-phasizes the origin of a feature in the problemdomain.

2. Subset of system implementation. The code modulesthat together implement a system exhibit the func-tionality contributing to features. A feature is a sub-set of these modules associated with the particularfunctionality. This de®nition emphasizes the realiza-tion of a feature in the solution domain.

3. Aggregate view across life-cycle artifacts. A feature isa ®lter that highlights the life-cycle artifacts related toa speci®c functionality by explicitly aggregating therelevant artifacts, from requirements fragments tocode modules, test cases and documentation. Thisde®nition emphasizes connections among di�erent ar-tifacts.

It is not altogether clear which de®nition is ``best'', al-though there are several good arguments in favor of the®rst one. In particular, since features originate in theproblem domain and not in the solution domain, the®rst de®nition appears to be more useful than the secondone. Furthermore, the groupings of artifacts made ex-plicit in the third de®nition can be inferred by using the®rst de®nition together with an appropriate model of therelationships among life-cycle artifacts.

Thus, for the purposes of this paper, we employ the®rst de®nition. We use this de®nition as a core conceptto develop a model of the artifacts that are createdduring software engineering activities. This model is notintended to be de®nitive of all life-cycle artifacts.Rather, it is intended to be suggestive of their relation-ships. Particular development environments may de®nethe artifacts and relationships somewhat di�erently indetail, but they will nonetheless be compatible with themin spirit. The model allows us to reason about the re-lationship of features to other life-cycle artifacts, and toarticulate and illustrate the bene®ts derived from mak-ing features ®rst class.

2.2. Features and software life-cycle artifacts

Fig. 1 shows a simple entity-relationship diagramthat models the role of features within a software pro-cess. The model derives from the concepts typically usedin software engineering practice and commonly pre-sented (often informally) in the literature. The entities,depicted as rectangles, correspond to life-cycle artifacts.

C. Reid Turner et al. / The Journal of Systems and Software 49 (1999) 3±15 5

The relationships, depicted as diamonds, are directionaland have cardinality. Despite being directional, the re-lationships are invertible. Again, we point out that thisis just one possible model, and it is just meant to be il-lustrative of the concepts we are exploring. It is notmeant to be a complete model or to constitute the novelcontribution of the paper. We have derived it bystudying available literature on the subject (e.g., PMDB,Penedo and Stuckle (1985)) and by analyzing our ownexperiences on several industrial projects, one of whichis discussed in Section 4.

The model de®nes some of the key aspects andproperties that are relevant to our understanding of therole of features in the life cycle, and are further exploredin this paper.1. Features as life-cycle entities are meant to bridge the

problem and solution domains.2. Features are a means to logically modularize the re-

quirements.3. The documentation of a feature is a user-oriented

description of the realization of that feature withinthe solution domain. This contrasts with, andcomplements, the user-oriented description of afeature as a set of requirements within the problemdomain.

4. The distinction between the problem and solutiondomains helps illuminate the fundamentally di�erentorientations among the various testing activities in

the life cycle. For example, system tests are focusedon user-visible properties and are therefore conceivedof, and evaluated, within the problem domain.

5. The connection between requirements and architec-tural design is di�cult, if not impossible, to formalizebeyond the notion that designs re¯ect the require-ments that drive them. However, if those drivers arefeatures, then there is hope for a better tie betweenthe problem and solution domains.

Two less immediate, but no less important, points canalso be seen in the model. First, while design artifacts aredirectly related to features, the relationships betweenfeatures and the deeper implementation artifacts areimplicit. For example, a developer might want to obtainall modules associated with a particular feature to makea change in the implementation of that feature. Satis-fying such a request would require some form ofreasoning applied to the relevant artifacts and relation-ships. In general, this reasoning would occur at theinstance level, as illustrated in Fig. 2 and explainedbelow. Second, there are two distinct levels at whichfeatures interact. In the problem domain, features in-teract by sharing requirements or by simply dependingon each other for particular services. Similarly, featurescan interact in the solution domain through sharedsubsystems and modules or through use dependencies.Although similar in nature, they are quite di�erent intheir rami®cations. The absence of an interaction in theproblem domain does not imply the absence of an in-teraction in the solution domain, which gives rise to theimplementation-based feature interaction problems(Gri�eth and Lin, 1993). The reverse is also true, but lessobvious, since it arises from the duplicate-then-modifystyle of code update. Such a style results in a prolifera-tion of similar code fragments that are falsely indepen-dent (so-called self-similar code Church and Helfman,1993).

Fig. 2. Instances of entities and relationships.

Fig. 1. Common Life-cycle entities and relationships.

6 C. Reid Turner et al. / The Journal of Systems and Software 49 (1999) 3±15

2.3. The instance level

If we populate the model of Fig. 1 and examine it atthe instance level, additional insights into features arerevealed. Fig. 2 depicts this level for the instances ofentities and relationships of a hypothetical system. The®gure is simpli®ed somewhat by only considering asubset of the entities. The shaded dots represent indi-vidual instances of the entity types named in thecolumns. The unlabeled ovals within a column representinstances of aggregate entity types, which are de®nedthrough the Composes relationship in Fig. 1. In partic-ular, the ovals represent, from left to right, test sets,features, design speci®cations and subsystems. Forexample, there are ten requirements fragments and fourfeatures depicted in the ®gure. Notice that aggre-gate artifacts are not necessarily disjoint. So, forexample, the top two features share the fourth require-ment fragment. The semantics of the arrows are given bythe relationships de®ned in Fig. 1. Recall that they areinvertible.

An instance diagram forms the basis for reasoningabout relationships across the life cycle. There has beena signi®cant amount of work in developing, maintain-ing, and even discovering the data for such representa-tions, but none has involved the use of features as acentral element. We advocate a representation that al-lows one to ask questions that include the following.· Which features were a�ected by this change to a re-

quirement?· Which modules should a developer check out to

make a change to this feature?· Which features were a�ected by this change to a mod-

ule?· Which test cases will exercise this feature?· Which modules are needed to con®gure the system

for these two features?For instance, it is clear that di�erent features are able toshare requirements speci®cations. A shared requirementfrom the switch example could be both the call-for-warding and call-screening features signaling comple-tion with an aural tone. These relationships lead to adeeper set of questions regarding the role of features in aparticular system. Answering the questions that areposed here implies the existence of a number of many-to-many relationships. Researchers have investigatedsome those relationships (Davis and Vick, 1977; Ro-binson and Pawlowski, 1998) and proposed solutionsthat would answer some of the questions. Since featuresare a natural stucturing of the requirements speci®ca-tion, organizing the relationships around features holdspromise for making such e�orts more valuable acrosslife-cycle activities.

The instance diagram also provides useful informa-tion for evaluating the structure of the system. For ex-ample, we can see that the two features represented by

the two topmost ovals in the second column share arequirement, which means that a change to that re-quirement may potentially impact both features. Fur-ther, we can see that despite this shared requirement, thefeature represented by the topmost oval is re¯ected in asingle design fragment, which is in turn implemented ina single module. This implies a signi®cant separation ofconcerns that might make it easier to modify the feature.We can also see that the features represented by the twobottom most ovals do not interact at the requirementslevel, but do in fact interact at the subsystem level. Fi-nally, we can see that there are two subsystems formingpart of the system whose designs are not related to anyparticular feature. This last observation deserves furtherdiscussion.

2.4. The system core

If a system's functionality is viewed, as we advocate,as a set of features then it is natural to ask the followingquestion: ``Is a system completely composed of the set offeatures it provides?'' It is clear that systems includeunderlying componentry to support their features. Thisunderlying componentry, which we call the core, arisessolely in the solution domain to aid development offeatures. Users are generally not concerned with thecore, and therefore it is not directly re¯ected in the re-quirements. A rather obvious core is evident in the ex-ample instance diagram of Fig. 2. At the module level,the core is composed of the bottom two subsystems,which have no tie back to any feature at the require-ments level, other than in their use by subsystems thatdo have such a tie.

Chen et al. (1994) make a similar observation aboutthe existence of feature components and core compo-nents, but their de®nition is based on test coverage. Inparticular, core components are those that are exercisedby all test cases, whereas feature components are thoseexercised by only a subset of the test cases.

In a sense, then, the concept of feature is helping us tode®ne the concept of core ± the core is what remains ofthe system in the absence of any particular feature.Given that we would like maximum ¯exibility in bothmodifying features and in selecting the set of features inany speci®c con®guration of a system, then this de®ni-tion identi®es something quite signi®cant. In fact, whatit provides is the conceptual foundation for the role ofsoftware architecture in software system development.An architecture provides the core functionality of thesystem within the solution domain that supports thefunctionality of the system desired in the problem do-main. Of course, an architecture must embody as-sumptions about the features it is intended to support,and the degree to which it correctly anticipates the needsof those features will determine the quality of thatarchitecture.

C. Reid Turner et al. / The Journal of Systems and Software 49 (1999) 3±15 7

3. Features and life-cycle activities

The artifacts and relationships discussed in the pre-vious section are created and maintained through vari-ous life-cycle activities. In this section we present a briefand high-level survey of what we see as the impact thatfeature engineering can have on several of those manyactivities. Our intention is to suggest some of the broadrami®cations of feature engineering, rather than to at-tempt a complete coverage of the topic.

3.1. Requirements engineering

Requirements engineering includes activities relatedto

``. . . identi®cation and documentation of customerand user needs, creation of a document that de-scribes the external behavior and associated con-straints that will satisfy those needs, analysis andvalidation of the requirements document to ensureconsistency, completeness and feasibility, and evo-lution of needs.'' (Hsia et al., 1993)

Research in requirements engineering is primarily fo-cused on formulating improved notations and analyses,and on developing methods and mechanisms for elici-tation, rationale capture and traceability. Requirementsengineering is the starting point for feature engineering,since it is concerned with the creation and maintenanceof the raw material from which features are composed.Requirement analysis must include the identi®cation ofthe set of requirement fragments that comprise eachfeature, as well as the various dependencies that mightexist among the features. Indeed, several requirementmethods have been proposed that are potentially usefulin the development of feature identi®cation techniques.

Domain analysis is a method for understanding re-quirements in a particular problem domain. The prod-uct of domain analysis is a domain model, whichcaptures the essential entities in a domain and the rela-tionships among those entities. Research in the area ofdomain analysis is focussed on the development ofbetter methods for eliciting and representing domainmodels. In addition, for stable domains, automatedsoftware generation techniques are being sought thatcan exploit the domain models. These techniques wouldprovide reuse of components that implement the entitiesde®ned in the domain model.

Several domain analysis methods, including FODA(Kang et al., 1990; Krut, 1993), use the term feature torefer to the capabilities of systems in a domain. Theytypically seek to distinguish the features that representbasic, core functionality from those that representvariant, optional functionality. A good example of thisapproach is the domain modeling method and envi-

ronment of Gomaa et al. (1994). The environment isused to generate object speci®cations for target systemsbased on a domain model. The object speci®cations aretherefore artifacts in the solution domain. Clearly, be-cause the object speci®cations are generated, their rela-tionship to features can be easily maintained, althoughthis notion of feature is not well developed.

Domain analysis plays a role in the software gener-ation work of Batory and O'Malley (1992) and of Si-taraman (1992), where they analyze a domain touncover reusable components. The components aregrouped into subsets (realms, in the terminology ofBatory and O'Malley) having the same functional in-terface; a complete system is created by choosing anappropriate element from each set. The choice is basedon the ``features'' exhibited by the elements. Here, theterm feature is essentially restricted to extra-functionalcharacteristics of a component, such as performance andreliability. A system can then be automatically generatedby specifying the desired extra-functional characteris-tics. Although this work represents an important steptoward feature engineering, it requires a fuller treatmentof the concept of feature. In particular, if feature spec-i®cations also represented functional di�erences, thenthe generation process would allow for the creation offunctionally di�erent systems.

In addition to domain analysis techniques, there arealso a number of other requirements methods that havebeen developed to represent and structure requirements.Representation and structuring of requirements are keyelements of a feature orientation, but the methods dis-cussed below would need to be enhanced in order to beappropriate for feature engineering.

Use cases (Fowler, 1997; Jacobson et al., 1997) are amethod for representing requirements that has becomequite popular within the object-oriented analysis anddesign community. Use cases are similar to features tothe extent that they represent requirements and somerelationships among those requirements, such as ``uses''and ``extends''. However, features support additionalrelationships, such as ``con¯icts'', ``competes'' and``constrains'', not currently represented by use cases.Moreover, features capture non-functional requirementsalso not currently expressable through use cases.

Quality Function Deployment (QFD) (Day, 1993) isa requirements and design process aimed at identifyingcustomer desires and related technical requirements.QFD exploits some notion of feature, but does not o�erany speci®c aid to support the representation andmanagement of features during the requirement engi-neering phase nor throughout the software developmentprocess.

Hsia and Gupta (1992) have proposed an automatedtechnique for grouping requirements speci®cations.Their purpose is to support incremental delivery ofsystem functionality through progressive prototypes.

8 C. Reid Turner et al. / The Journal of Systems and Software 49 (1999) 3±15

The cohesive structures that Hsia and Gupta seek toidentify are abstract data types (ADTs) for objects in theproblem domain. However, their goal of deliveringADT-based prototypes transcends requirements analy-sis and forces what amount to design choices.

Palmer and Liang (1992) have described a somewhatdi�erent requirements clustering technique. They de®nethe problem as an e�ort to ``aggregate a set of N re-quirements into a set of M requirement(s) clusters whereM�N''. This is a precise statement of the goal of iden-tifying features. Their motivation, however, is to detecterrors and inconsistencies within requirements clusters,and therefore the organizing principle behind theirclusters is similarity of the requirements within a cluster.In other words, they seek to ®nd sets of redundant re-quirements in order to analyze the elements of the set forconsistency. For feature engineering purposes, we in-stead advocate that the organizing principle of a clustershould be relevance of the constituent requirements tothe desired properties of the feature; the issue of redun-dancy and consistency is orthogonal, and so a clusteringfor that purpose, while important, is also orthogonal.

To conclude this discussion of requirements engi-neering, let us return to the feature interaction problemin telecommunications applications mentioned in Sec-tion 1. In telephone switch software, features such ascall waiting and call forwarding both relate to thetreatment of incoming calls to a busy subscriber line(AT&T Network Systems, 1991), and thus exhibitoverlapping requirements fragments. The identi®cationof such feature interactions at the requirements phasecan help eliminate unanticipated interaction problemsduring later phases in the software life cycle. The mostcommon research approach to this problem is the ap-plication of formal veri®cation techniques to systemspeci®cations, with the goal of detecting all undesiredfeature interactions. The critical part of this activity isthe system speci®cation ± that is, the de®nition andapplication of a speci®cation technique that actuallycaptures the relevant properties of the system. Jacksonand Zave propose DFC (Jackson and Zave, 1998), avirtual architecture for representing features that can bedynamically composed to form a con®guration suitableto provide a speci®c service. From our point of view,features can be represented and handled in several dif-ferent ways. In particular, features in DFC are treated as®rst class, and expected to drive the subsequent modelchecking activities and the design of the concrete systemarchitecture. This clearly conforms to our idea of afeature-centric development process.

In general, the fundamental di�culty with require-ments engineering in practice today is identi®ed by Hsiaet al.

``For the most part, the state of the practice is thatrequirements engineering produces one large docu-

ment, written in a natural language, that few peoplebother to read.'' (Hsia et al., 1993)

Feature engineering holds the promise to make the re-quirements e�ort more useful by carrying the results ofthis e�ort forward to the other life-cycle activities in adisciplined way.

3.2. Software architecture and high-level design

Ideally, a requirements speci®cation is a precisestatement of a problem to be solved; it should structurethe problem domain as features to be exhibited by animplementation. The software architecture, on the otherhand, is the blueprint for a solution to a problem,structuring the solution domain as components andtheir connectors. Researchers in software architectureare focusing attention on languages for architecturaldesign, analysis techniques at the architecture level, andcommonly useful styles or paradigms for software ar-chitectures.

Feature engineering has signi®cant implications forsoftware architecture. One is in relating the problem-domain structure of features to the solution-domainstructure of components and connectors. Rarely is thismapping trivial. Another implication is that, from theperspective of the user, features are the elements ofsystem con®guration and modi®cation. A high-leveldesign that seeks to highlight and isolate features islikely to better accommodate user con®guration andmodi®cation requests. Within this context, then, we seeat least two mutually supportive approaches: featuretracing and feature-oriented design methods.

The tracing of requirements to designs has been anarea of investigation for many years. The basic problemis that it is essentially a manual task whose results aredi�cult to keep up-to-date and are prone to errors. Oneway to mitigate this problem is to raise tracing's level ofgranularity from individual requirements fragments tosensible groupings of such fragments ± features. Weconjecture that tracing at the feature level is moretractable and, in the end, more useful than traditionalmethods.

A somewhat di�erent approach to high-level designthan traditional functional decomposition or object-oriented design methods arises from a focus on features.The starting point for a feature-oriented design methodis an analysis of the intended feature set to gain anunderstanding of the features, both individually and incombination. Of particular importance is understandingthe requirements-derived dependencies among the fea-tures. If one takes feature prominence as a design goal,then the top-level decomposition of the architectureshould match the decomposition of the requirementsspeci®cation into features. At each successive level ofarchitectural decomposition, the goal should continue to

C. Reid Turner et al. / The Journal of Systems and Software 49 (1999) 3±15 9

be feature isolation. Points of interaction among fea-tures naturally arise from shared requirements, as wellas from the need to satisfy extra-functional require-ments, such as performance. The criteria for creatingnew components should be to capture explicitly someshared functionality among some subset of features. Inthis way, the feature interactions are caused to distill outinto identi®able components.

In the telephone switch, for example, the call for-warding, abbreviated dialing, and direct connectionfeatures all require the association of directory numberswith a subscriber line (AT&T Network Systems, 1991).Each so-called Switching Module in the architecture(i.e., the module responsible for routing calls) includes aspecial database to store such information. Thus, thedatabase, as a design element, is driven by a speci®c andidenti®able set of features. Maintaining this relationshipis critical to understanding how to properly evolve thiselement without violating some constraint imposed by afeature.

Combining tracing at the feature level with a designmethod that leads to modules representing features andfeature interactions should help to illuminate the tradi-tionally obscure relationship between speci®c featuresand the design elements supporting them. Moreover,when a request for a feature change is presented to adeveloper, that feature can be traced immediately to adesign element associated with the feature. Any poten-tially problematic interactions with other features be-come visible through their capture in shared modulesrepresenting that interaction.

3.3. Low-level design and implementation

Low-level design and implementation are the activi-ties that realize the modules and subsystems identi®ed inarchitectural design. While we could postulate a need forfeature-oriented implementation languages, our experi-ence with feature engineering has not lead to the dis-covery of any compelling arguments in their favor. Thee�ect that feature engineering has on these activities ismore likely felt indirectly through the e�ects on the high-level design and testing activities and through the con-tribution of a tool set that makes the relationshipsacross artifacts visible to the developer.

Nevertheless, a feature orientation frequently existsduring implementation. Cusumano and Selby (1995)report that development e�orts for many Microsoftproduct groups are organized by the features of theirproduct. Small teams of developers are assignedresponsibility for one or more of those features. Espe-cially complicated features are assigned to strongerteams that include developers with more experience.This organizational structure built around featuresextends to teams assigned responsibility for testingparticular features.

Ossher and Harrison (1992) discuss a method of ex-tending existing class hierarchies by applying ``extensionhierarchies'', which would appear to bear some relationto feature engineering at the implementation level.Goals for this work include reducing modi®cation ofexisting code and separating di�erent extensions. Muchlike change sets in con®guration management (see Sec-tion 5), these extensions can be used as a conceptualmechanism to add functionality to existing object-ori-ented systems. Unfortunately, this research describesextensions only at the granularity of object methods,which seems inappropriate for dealing with complexfeatures such as the call-forwarding feature of a tele-phone switch. In addition, the semantic compatibility ofcombined extensions are not well understood in thistechnique, which is a critical need for feature engineer-ing.

A primary bene®t to be gained from concentrating onfeatures as a bridge from the problem domain to thesolution domain is a reduction of the intellectual burdenplaced on developers when interacting with the imple-mentation of a system's features. Developers will be ableto work with a feature implementation without havingto recreate the mapping from problem-domain artifactsto solution-domain artifacts and vice versa.

3.4. Testing

Testing is an approach to software veri®cation thatinvolves experimenting with a system's behavior to de-termine if it meets expectations. In practice, there arethree levels of testing. Unit testing is used to test thebehavior of each module in isolation. Integration testingis used to detect defects in the interactions amongmodules at their interfaces. System testing is focused ontesting the complete system as a whole for compliancewith the requirements set out by the users, including thesystem's intended functionality and performance. Sys-tem testing is oriented toward the problem domain,while unit and integration testing are oriented towardthe solution domain (see Fig. 1).

Feature engineering can have an impact on testingactivities by suggesting a somewhat di�erent organiza-tion of test sets than is traditionally encountered. Inparticular, test sets would be organized around thefeature or features they are intended to test. The tele-phone switch software, for example, supports a vastnumber of features that need to be tested for every re-lease. Having requirements for each feature provides abasis for testing each feature in isolation. Taking all thefeature tests together, we get the equivalent of a systemtest set.

Where a feature implementation is con®ned to asingle module, tests for that feature amount to unit testsfor the module. Of course, feature implementationsfrequently involve more than one module. In this case,

10 C. Reid Turner et al. / The Journal of Systems and Software 49 (1999) 3±15

feature tests are a mechanism for evaluating moduleintegration. The connections between features that arehighlighted by instance diagrams, such as Fig. 2, pointout sets of features that should be tested in combination.This would be useful, for example, in guiding the testingof modi®cations to the database component of thetelephone switch's Switching Module, which is sharedby several features (AT&T Network Systems, 1991).Such feature-combination tests might detect unwantedfeature interactions.

The feature-oriented organization of test sets can alsohelp to minimize regression testing. This harks back tothe theme of users posing requests in terms of features.If a developer can make a change to the system withrespect to some particular feature, then only the testsrelated to that feature (and, possibly, any other featuresthat depend upon that feature) need to be run.

3.5. Con®guration management

Con®guration management is the discipline of coor-dinating and managing evolution during the lifetime of asoftware system. Traditionally, con®guration manage-ment is concerned with maintaining versions of artifacts,creating derived objects, coordinating parallel develop-ment e�orts, and constructing system con®gurations.

The vocabulary of existing con®guration manage-ment systems is oriented toward solution-domain arti-facts, such as ®les, modules and subsystems. Many ofthe accepted con®guration management techniques,such as version management and derived-object cre-ation, should be directly applied at the feature level. Forexample, the developers of the telephone switch softwareshould be able to populate a workspace through a re-quest for a speci®c version of all the artifacts associatedwith a particular feature, such as call waiting, by simplyidentifying the feature, not each of the individual rele-vant artifacts. It should also be possible to issue a re-quest to construct a system where that request can beparameterized by a given set of features. For example, itmight be useful to construct a ``compact'' release of thetelephone switch software that has basic call processingfeatures but no call waiting or call forwarding features.Another useful capability would be the delineation ofparallel workspaces based on features. For features tobecome ®rst class, they will have to exist in the models ofthe systems that are built. This has the potential forraising the level of abstraction at which developers workfrom ®les to features.

Realizing this expanded role for con®guration man-agement will require feature implementations to beseparately encapsulated and versioned. Bare ®les do notappear to be the right abstraction for this purpose.Change sets (Feiler, 1991; Software Maintenance &Development Systems, 1994), on the other hand, showpromise as a potentially useful storage base. In addition,

information about feature dependencies at both thespeci®cation and implementation levels will be neededfor assembling consistent con®gurations.

3.6. Reverse engineering

Reverse engineering is the process of discovering thestructure and organization of an existing system fromany available artifacts. Typically, such artifacts arelimited to those associated with the implementation,such as source ®les. The activities in reverse engineeringcenter on the application of various analyses techniquesto the artifacts in order to reveal internal structure, aswell as to reveal static and dynamic dependencies.

The primary in¯uence of feature engineering on re-verse engineering is to focus the analyses toward dis-covering connections to features. In essence, this meansrecreating the (lost) relationships in Fig. 2. For example,reverse engineering could be used to discover the inter-actions between call waiting and call forwarding, or todiscover the features that are dependent on the databasecomponent of the Switching Module.

One possible technique would be to broaden thescope of program slicing, following Sloane and Holds-worth (1996), to create a feature slice through the im-plementation artifacts. A feature slice would include allof the fragments that contribute to a feature's imple-mentation. Working in the other direction, if a featuretest set existed, then observations of test case executionscould reveal the portions of the implementation thatwere involved in implementing the feature.

4. Case study: Feature engineering in an industrial phone

switch software

We recently performed a study of Italtel's telephoneswitch software in order to validate some of the ideaspresented in this paper against a large and complexsoftware system. Our intent was to identify features inthe system and to evaluate the support that the devel-opment process provides for managing features duringthe system's evolution.

The software implementing the switch consists ofmillions of lines of code and thousands of ®les. Eachrelease of the switch incorporates added functionality,while the basic software architecture remains stable;only small changes are relatively frequent. This is con-sistent with our view of software architecture as de®ningthe system core (see Section 4).

Fig. 3 gives a UML (Rumbaugh et al., 1998; Rum-baugh et al., 1998a) model of the software and docu-mentation artifacts of the system. We developed themodel by examining project documents and interviewingproject personnel. Space does not permit us to explain

C. Reid Turner et al. / The Journal of Systems and Software 49 (1999) 3±15 11

the entire model in detail. Instead, we highlight somerelevant portions of the model.

Requirements for releases are separated into Userrequirements and Release requirements; the latter dictateconcerns related to project management of the releaseprocess, such as the schedule and the assignment oforganizational responsibilities. User-visible services arereferred to as services. Services are assigned to projectmanagers who oversee their design, implementation,documentation and testing.

Each service is in a one-to-one correspondence to aservice requirements document. Service requirementsmodularize the functional and project management re-quirements, documenting the user-visible service to beadded or modi®ed in the release. Thus, the concept ofservice neatly corresponds to our notion of a feature,incorporating both the solution-domain orientation andrequirements clustering aspects of our de®nition (seeSection 2.1).

Having con®rmed the central role that features playin structuring evolutionary changes to the software andthe assignment of work activities to perform thosechanges, we next sought to understand the extent towhich the development process exploits the feature-ori-

ented nature of the software product. It turned out thatthe development process is organized in a traditionalway, focusing on the artifacts that are produced in everyphase of a waterfall-like life cycle. Requirements docu-ments are written by means of simple word processorsand are stored in directories whose structure reproducesthe hierarchical structure of the contents. Relationshipscan be traced in a top-down fashion by navigating ex-plicit references to the names of the lower-level docu-ments. Only in a limited number of cases are referencesrepresented bidirectionally. As a consequence, it is veryhard to determine to which performances a given func-tion or component contributes.

The tools employed in the project are traditional andgeneral purpose, having no particular tie to the featurecontext in which they are employed. We thus set aboutto investigate how one such tool, the con®gurationmanagement system, could be better integrated into thecontext. We ®rst de®ned a set of requirements for con-®guration management support of a feature-orienteddevelopment process. These requirements address fourbasic goals of con®guration management.· Identi®cation: Identify and classify the system arti-

facts and the relationships among them.

Fig. 3. Model of Italtel's telephone switch software artifacts.

12 C. Reid Turner et al. / The Journal of Systems and Software 49 (1999) 3±15

· Control/Process: Control access to system artifactsand ensure that all changes adhere to a desired soft-ware process.

· Construction: Determine and build valid product con-®gurations.

· Status: Record signi®cant events within a develop-ment process and provide information to track thesystem's evolution.

For example, the con®guration management systemmust identify the set of features currently available, theset of versions for each feature, the set of modules thatimplement each feature, and the set of test cases asso-ciated with each feature. The developer must be able toretrieve all the artifacts associated with each feature andto guarantee some consistency constraints when changesare made to those artifacts.

We next developed an evaluation framework thatcould be used to indicate the e�ort involved in realizinga feature orientation within a given con®guration man-agement system. In particular, for each activity andstructure identi®ed in a requirement, we characterizedthe support provided by the con®guration managementsystem as follows.· Native: Feature semantics are built into the system.· Direct: Feature semantics can be supported by con®g-

uration or interpretation of an existing system facilityor facilities.

· Indirect: Feature semantics can be supported byscripts or programs that use the facilities within thesystem and that can guarantee the preservation ofsystem constraints.

· Inadequate: Feature semantics must be supported byscripts or programs that cannot be prevented from vi-olating system constraints or that require duplicatingmanaged information outside of the system.

We evaluated six commercial systems and found thatwhile none of them provided native support for any ofthe required capabilities, a few did provide direct sup-port for several of the required capabilities. Those sys-tems therefore allowed, with some moderate tailoring, ahigher degree of integration of feature orientation withthe current Italtel development process than the systemcurrently used by the development organization. Thefull results of this study are reported elsewhere (Turneret al., 1998).

5. Conclusion

In current practice, the notion of feature is an ill-de®ned, yet widely used, concept. It becomes meaningfulwhen seen as a way to modularize system requirementsand when related to the range of life-cycle artifacts andactivities. We argue that there is a growing need forfeature engineering methods and techniques able tosupport a disciplined projection of features from the

problem domain into the solution domain. Doing so willbridge the gulf between the user and developer per-spectives of a system. In addition, the notion of featureengineering has the potential to improve system under-standing by raising the level of abstraction consistentlyacross the life cycle.

This paper is a ®rst step towards the development offeature engineering. We have presented a provisionalmodel for features in terms of their relationships toother artifacts. Moreover, we have explored how featureengineering a�ects life-cycle activities, including require-ments engineering, testing, con®guration managementand reverse engineering. This has been accomplished byanalysing the state of the art in the ®eld and by evalu-ating our own experiences in real industrial projects. Inparticular, we have brie¯y discussed the results of astudy we carried out to assess the maturity and e�ec-tiveness of a large software house developing telecom-munication software. As a conclusion, we argue that theconcepts involved in feature engineering cut across theentire software life cycle, and that research e�orts in anumber of software engineering disciplines are relevantto feature engineering. These e�orts should be leveragedto help bring features to the fore.

Notice that even if the notion of feature and our ownexperience originate from concepts and techniques de-®ned within the context of telecommunication software,the validity of the observations presented in this paperare not limited to that domain. Indeed, the advent ofcomponent-based software development makes the no-tion of feature engineering of paramount importance inall the application domains where software is used.Component-based development means development byintegration of di�erent chunks of functionality. Thus,feature engineering is de facto a crucial methodologicalconstituent of any component-based developmentmethod.

Certainly, this paper does not provide ®nal solutions.It aims at laying the foundations to address the probleme�ectively. In this respect, the framework presented inthis paper can be further improved. For instance, fea-tures are treated as undi�erentiated from each other. Incomplex software systems, features will exist within hi-erarchies organized by properties such as dependence,importance and complexity. Understanding such hier-archies, and particularly the nature of feature depen-dencies, should produce additional insights and bene®tsto software development.

In addition to re®ning basic concepts of feature engi-neering, there is a need for the development of tools tosupport the integration of features into the solution do-main. Using a feature orientation to make explicit therelationships among development artifacts should in-crease a developer's ability to comprehend complex sys-tems. This will only come about, however, if tools exist tocapture, organize, and present the structure that features

C. Reid Turner et al. / The Journal of Systems and Software 49 (1999) 3±15 13

o�er. These tools would, for instance, provide primitivesfor controlling access to artifacts in terms of features, aswell as support the con®guration of systems based onfeature sets. We are carrying out some experimentationon this topic, as part of our ongoing work to explore andaddress the issues and problems of feature engineering.

Acknowledgements

A. Fuggetta and L. Lavazza are also with CEFRIEL(http://www.cefriel.it). The work of A. Fuggetta wassupported in part by CNR. The work of A.L. Wolf wassupported in part by the Air Force Materiel Command,Rome Laboratory, and the Defense Advanced ResearchProjects Agency under Contract Numbers F30602-94-C-0253 and F30602-98-2-0163. The content of the infor-mation does not necessarily re¯ect the position or thepolicy of the U.S. Government and no o�cial en-dorsement should be inferred. This work bene®ted fromdiscussions with David Rosenblum of the University ofCalifornia at Irvine. The information concerning Ital-tel's software process and products was kindly providedby Giorgio Comparin.

References

Aho, A.V., Gri�eth, N., 1995. Feature interaction in the global

information infrastructure. In: Proceedings of the Third ACM

SIGSOFT Symposium on the Foundations of Software Engi-

neering, ACM SIGSOFT, pp. 2±5.

AT&T Network Systems, 1991. IESS Switch Global Technical

Description, Issue 3.

Batory, D., O'Malley, S., 1992. The design and implementation of

hierarchical software systems with reusable components. ACM

Trans. Software Engrg. Meth. 1 (4), 355±398.

Cameron, E.J., Velthuijsen, H., 1993. Feature Interactions in Tele-

communications Systems. IEEE Communications Magazine 31,

18±23.

Carney, D.L., Cochrane, J.I., Gitten, L.J., Prell, E.M., Staehler, R.,

1985. Architectural Overview. AT&T Technical J. 64 (6), 1339±

1356.

Chen, Y.-F., Rosenblum, D.S., Vo, K.-P., 1994. Testtube: A system for

selective regression testing. In: Proceedings of the 16th Interna-

tional conference on Software Engineering. IEEE Computer

Society, pp. 211±220.

Church, Helfman, J.I., 1993. Dotplot: A program for exploring self-

similarity in millions of lines for text and code. J. Comput.

Graphical Statistics 2 (2), 153±174.

Cusumano, M.A., Selby, R.W., 1995. Microsoft Secrets. The Free

Press, New York.

Davis, A.M., 1982. The design of a family of application-oriented

requirements languages. Computer 15 (5), 21±28.

Davis, C.G., Vick, C.R., 1977. The sofware development system. IEEE

Transactions on Software Engineering SE-3 (1), 69±84.

Day, R.G., 1993. Quality Function Deployment. ASQC Quality Press,

Milwaukee, Wisconsin.

Feiler, P.H., 1991. Con®guration management models in commercial

environments. Technical Report SEI-91-TR-07, Software Engi-

neering Institute, Pittsburgh, April.

Fowler, M., 1997. UML Distilled. Addison-Wesley, Reading.

Gomaa, H.V., Sugumaran, H.V., Bosch, C., Tavakoli, I, 1994. A

prototype domain modeling environment for reusable software

architectures. In: Proceedings of the Third International Confer-

ence on the Software Reuse. IEEE Computer Society, pp. 74±83.

Gri�eth, N.D., Lin, Y., 1993. Extending telecommunications systems:

the feature-interaction problem. Computer 26 (8), 14±18.

Hsia, P., Davis, A.M., Kung, D.C., 1993. Status report: requirements

engineering. IEEE Software 10 (6), 75±79.

Hsia, P., Gupta, A., 1992. Incremental delivery using abstract data

types and requirements clustering. In: Proceedings of the Second

International Conference on Systems Integration. IEEE Com-

puter Society, pp. 137±150.

Jackson, M., 1995. Software Requirements and Speci®cations: A

Lexicon of Practice, Principles and Prejudices. Addison-Wesley,

Reading.

Jackson, M., Zave, P., 1998. Distributed feature composition: a virtual

architecture for telecommunications services. IEEE Trans. Soft-

ware Engrg. 24 (10), 831±847.

Jacobson, I., Christerson, M., Jonsson, P., Overgaard, G., 1997.

Object-Oriented Sofware Engineering: A Use Case Driven

Approach. Addison-Wesley, Reading.

Kang, K.C., Cohen, S.G., Hess, J.A., Novak, W.E., Peterson, A.S.,

1990. Feature-oriented domain analysis (FODA) feasibility

study. Technical Report CMU/SEI-90-TR-21, Software Engi-

neering Institute, Pittsburgh.

Keck, D.O., Kuehn, P.J., 1998. The feature and service interaction

problem in telecommunications software systems: a survey. IEEE

Trans. Software Engrg. 24 (10), 779±796.

Krut Jr., R.W., 1993. Integrating 001 tool support into the feature-

oriented domain analysis methodology. Technical Report CMU/

SEI-93-TR-01, Software Engineering Institute, Pittsburgh, Penn-

sylvania, July.

Lin, Y.-J., Jazayeri, M., 1998. Guest editoral: introduction to the

special section on managing feature interactions in telecommu-

nications software systems. IEEE Trans. Software Engrg. 24 (10),

777±778.

Ossher, H., Harrison, W., 1992. Combination of inheritance hierar-

chies. In: Proceedings of the Conference on Object-oriented

Programming Systems, Languages and Applications. Association

for Computer Machinery, pp. 25±40.

Palmer, J.D., Liang, Y., 1992. Indexing and clustering of software

requirements speci®cations. Info. Decision Technol. 18 (4), 283±

299.

Penedo, M.H., Stuckle, E.D., 1985. PMDB ± A project master

database for software engineering environments. In: Proceedings

of the Eigth International Conference on Software Engineering.

IEEE Computer Society, pp. 150±157.

Robinson, W.N., Pawlowski, S., 1998. Surfacing root requirements

interactions from inquiry cycle requirements documents. In:

Third International Conference on Requirements Engineering.

IEEE Computer Society, pp. 82±89.

Rumbaugh, J., Jacobson, I., Booch, G., 1998a. Uni®ed Modeling

Language Reference Manual. Addison-Wesley, Reading.

Rumbaugh, J., Jacobson, I., Booch, G., 1998b. Uni®ed Modeling

Language User Guide. Addison-Wesley, Reading.

Sitaraman, M., 1992. Performance parameterized reusable software

components. Internat. J. Software Engrg. Knowledge Engrg. 2

(4), 567±587.

Sloane, A.M., Holdsworth, J., 1996. Beyond traditional program

slicing. In: Proceedings of the International Symposium on

Software Testing and Analysis (ISSTA'96). ACM SIGSOFT, pp.

180±186.

Software Maintenance and Development Systems, 1994. Concord,

Massachusetts. Aide de Camp Product Overview, September.

Turner, C.R., Fuggetta, A., Lavazza, L., Wolf, A.L., 1998. Evaluating

support for feature-based development in con®guration manage-

14 C. Reid Turner et al. / The Journal of Systems and Software 49 (1999) 3±15

ment systems. Technical Report CU-CS-875-98, Department of

Computer Science, University of Colorado, Boulder, Colorado,

November.

Zave, P., 1993. Feature interactions and formal speci®cations in

telecommunications. Computer 26 (8), 20±29.

Reid Turner received MS (1995) and PhD (1999) degrees in ComputerScience from the University of Colorado in Boulder. He is currentlyworking at US West Advanced Technologies in Boulder, Colorado.

Alfonso Fuggetta is an associate professor of software engineering atPolitecnico di Milano and senior researcher at CEFRIEL, a researchand education institution created in Milano in 1988 by IT industriesand public administrations. His research interests are in process tech-nology, process improvement, requirement engineering, distributedand mobile systems.

Luigi Lavazza received his Dr. Eng. degree in Electrical Engineeringfrom Politecnico di Milano in 1984. From 1984 to 1990 he worked in

industry, where he was involved in software development, in researchprojects, and in the de®nition of quality manuals. In 1990 he joined theSoftware Engineering research group at CEFRIEL. He is currently anassistant professor at Politecnico di Milano. He is co-author of over 30scienti®c papers. His research interests include advanced software en-gineering environments, software process modeling, assessment, im-provement and measurement, databases for software engineering andrequirements engineering.

Alexander Wolf is a faculty member in the Department of ComputerScience, University of Colorado at Boulder. Previously he was atAT&T Bell Laboratories. Wolf's research interests are in the discoveryof principles and development of technologies to support the engi-neering of large, complex software systems. He has published paperson software engineering environments and tools, software process,software architecture, and con®guration management. He is currentlyserving as Vice Chair of the ACM Special Interest Group in SoftwareEngineering and is on the editorial board of the ACM journalTransactions on Software Engineering and Methodology.

C. Reid Turner et al. / The Journal of Systems and Software 49 (1999) 3±15 15