reconcilingsoftwarerequirementsandarchitectures...

Softw Syst Model (2003) / Digital Object Identifier (DOI) 10.1007/s10270-003-0038-6

Reconciling software requirements and architectureswith intermediatemodels

Paul Grunbacher1, Alexander Egyed2, Nenad Medvidovic3

1Systems Engineering and Automation, Johannes Kepler University, 4040 Linz, Austria; E-mail: [email protected] Corporation, 4640 Admiralty Way, Marina Del Rey, CA, USA; E-mail: [email protected] Science Dept., Univ. of Southern California, Los Angeles, CA, USA; E-mail: [email protected]

Published online: 10 December 2003 – Springer-Verlag 2003

Abstract. Little guidance and few methods are avail-able for the refinement of software requirements into anarchitecture satisfying those requirements. Part of thechallenge stems from the fact that requirements and ar-chitectures use different terms and concepts to capturethe model elements relevant to each. In this paper we willpresent CBSP, a lightweight approach intended to pro-vide a systematic way of reconciling requirements andarchitectures using intermediate models. CBSP lever-ages a simple set of architectural concepts (components,connectors, overall systems, and their properties) to re-cast and refine the requirements into an intermediatemodel facilitating their mapping to architectures. Fur-thermore, the intermediate CBSP model eases captur-ing and maintaining arbitrarily complex relationships be-tween requirements and architectural model elements, aswell as among CBSP model elements. We have appliedCBSP within the context of different requirements andarchitecture definition techniques. We leverage that ex-perience in this paper to demonstrate the CBSP methodand tool support using a large-scale example.

Keywords: Requirements elicitation and negotiation –Architecture modeling – Intermediate models – Trace-ability

1 Introduction

Software systems of today are characterized by increasingsize, complexity, distribution, heterogeneity, and lifespan.They demand careful capture and modeling of require-ments [37, 44] and architectural designs [40, 46] early on,

This paper represents a major revision and extension of thework that has been published in the Proceedings of the Require-ments Engineering 2001 conference [21].

before low-level system details begin to dominate the en-gineers’ attention and significant resources are expendedfor system construction. Understanding and supportingthe interaction between software requirements and archi-tectures remains one of the challenging problems in soft-ware engineering research [36, 37]. Evolving and elaborat-ing system requirements into a viable software architec-ture satisfying those requirements is still a difficult task,mainly based on intuition and experience. Similarly, littleguidance is available for modeling and understanding theimpact of architectural choices on the requirements. Soft-ware engineers face some critical challenges when tryingto reconcile requirements and architectures:

• Requirements are frequently captured informally ina natural language. On the other hand, entities ina software architecture specification are usually spec-ified in a more formal manner causing a semanticgap [31].• System properties described in non-functional require-ments [9] are commonly hard to specify in an architec-tural model [11, 31].• The iterative, concurrent evolution of requirementsand architectures demands that the development ofan architecture be based on incomplete requirements.Also, certain requirements can only be understoodafter modeling or even partially implementing the sys-tem architecture [13, 36].• Mapping requirements into architectures and main-taining the consistency and traceability between thetwo is complicated since a single requirement mayaddress multiple architectural concerns and a singlearchitectural element (for example a COTS compon-ent) typically has numerous non-trivial relations tovarious requirements. The increasing importance ofcomponent-based software development (CBD) em-phasizes the need for agile techniques that allow cap-

P. Grunbacher et al.: Reconciling software requirements and architectures with intermediate models

ture and understanding the complex relationship be-tween requirements and architectural elements.• Real-world, large-scale systems have to satisfy hun-dreds, possibly thousands of requirements [6]. It is dif-ficult to identify and refine the architecturally relevantinformation contained in the requirements due to thisscale.• Requirements and the software architecture emerge ina process involving heterogeneous stakeholders withconflicting goals, expectations, and terminology [3].Supporting the different stakeholders’ interests de-mands finding the right balance across these oftendivergent interests.

In aiming to address these challenges we have de-veloped a lightweight method for identifying the keyarchitectural elements and the dependencies amongthose elements, based on the stated system require-ments. Our CBSP (Component-Bus-System-Property)approach helps to refine a set of requirements by apply-ing a taxonomy of architectural dimensions. The intent ofour work is to provide a generic approach that primarilyworks with arbitrary informal or semi-formal require-ments representations as well as different architecturemodeling approaches. Although requirements may alsobe captured in a formal language such as KAOS [27],informal or semi-formal approaches are still used very fre-quently. In order to validate our research to date, we haveapplied CBSP extensively in the context of EasyWin-Win [4, 20], a groupware-supported requirements negoti-ation approach. EasyWinWin has been selected becauseit supports multi-stakeholder elicitation of requirementsand captures requirements informally but in a structuredfashion.CBSP provides an intermediate model between the

requirements and the architecture that helps to itera-

Fig. 1. CBSP model context

tively evolve the two models [36]. For example, a set ofincomplete and quite general requirements captured asstatements in a natural language might be available. Theintermediate CBSPmodel then captures architectural de-cisions as an incomplete “proto-architecture” that pre-scribes [5] further architectural development. The inter-mediate model still “looks” like requirements but “sound-s” like an architecture. The CBSP approach also guidesthe selection of a suitable architectural style to be usedas a basis for converting the proto-architectures into anactual implementation of a software system architecture.Figure 1 shows the CBSP model in the context of the

Twin Peaks model [36]. The Twin Peaks model suggeststhat requirements and architectures are evolved itera-tively and concurrently. In such a context, the intermedi-ate CBSP model can be used at different levels of detailin the modeling process. For example, it can help to refinehigh-level, informal requirements early in a project andmore elaborated requirements in later iterations; or it canalso help to understand how issues arising in architecturemodeling and simulation relate to the requirements.

CBSP provides:

• a lightweightway of refining requirements using a small,extensible set of key architectural concepts;• mechanisms for “pruning” the number of relevant re-quirements, rendering the technique scalable by focus-ing on the architecturally most relevant set of artifacts;• involvement of key system stakeholders, allowing non-technical personnel (e.g., customers, managers, evenusers) to see the impact of requirements on architec-tural decisions if desired;• adjustable voting mechanisms to resolve conflicts anddifferent perceptions among architects; and• tools supporting selected steps in the approach (how-ever, we would like to stress that a full automation


of the approach is neither possible nor desirable andhuman decision-making is an important aspect of theapproach).

Together, these benefits afford a high degree of controlover refining large-scale system requirements into archi-tectures.The paper is organized as follows: Sect. 2 discusses

details of the CBSP approach. Section 3 describes theapplication of CBSP in a large-scale example. Section 4describes our current tool support. Related work will bediscussed in Sect. 5. Conclusions round out the paper inSect. 6.

2 The CBSP approach

According to (IEEE-610-1990) [23] a requirement is“a condition or capability needed by a user to solvea problem or achieve an objective.” Requirements largelydescribe aspects of the problem to be solved and con-straints on the solution, i.e., desired system features andproperties (both functional and non-functional [9]). Re-quirements are derived from the concepts and relation-ships in the problem domain (e.g., medical informatics,E-commerce, avionics, mobile robotics).Requirements may be simple or complex, precise or

ambiguous, stated concisely or elaborated carefully. Ofparticular interest to our work is a large class of require-ments that is predominantly stated in a natural language,as opposed to precise formalisms. On the surface, such re-quirements are easier to understand by humans, but theyfrequently lead to ambiguity, incompleteness, and incon-sistencies in the architecture and, eventually, the soft-ware system. It is advisable not only to capture the out-come of requirements elicitation, i.e., the requirements,but also the evolution of goals of system stakeholders suchas customers, users, managers, developers [3] to preservethe history and rationale of the requirements productionprocess [18].The relationship between a set of requirements and

an effective architecture for a desired system is not read-ily obvious. Architectures model a solution to a problemdescribed in the requirements and provide high-level ab-stractions for representing the structure, behavior, andkey properties of a software system. The terminology andconcepts used to describe architectures differ from thoseused for the requirements. An architecture deals withcomponents, which are the computational and data elem-ents in a software system [40]. The interactions amongcomponents are captured within explicit software connec-tors (or buses) [46]. Components and connectors are com-posed into specific software system topologies. Finally,architectures both capture and reflect the key desiredproperties of the system under construction (e.g., relia-bility, performance, cost) [46]. These elements of softwarearchitectures can be specified formally using architecturedescription languages (ADLs) [31].

The above-described differences between require-ments and architectures make it difficult to build a bridgethat spans the two. For example, it is unclear in gen-eral whether and how a statement of stakeholder goalsshould affect the desired system’s architecture; similarly,deciding how to most effectively address a functionalrequirement often boils down to relying on the archi-tects’ intuition, rather than applying a well-understoodmethodology. For these reasons, we have formulatedCBSP, a technique easing the development of an ar-chitecture addressing a given set of requirements ina more straightforward and consistent manner than at-tempting to transfer directly requirements into archi-tectures. This section will introduce the CBSP tax-onomy of architectural dimensions and describe a processthat guides the development of the intermediate CBSPmodel.

2.1 CBSP taxonomy

The fundamental idea behind CBSP is that any softwarerequirement may explicitly or implicitly contain informa-tion relevant to the software system’s architecture. It isfrequently very hard to surface this information, as dif-ferent stakeholders will perceive the same requirement invery different ways [20]. At the same time this architec-tural information is often essential in order to properlyunderstand and satisfy requirements. CBSP supports thetask of identifying architectural information contained inthe requirements and explicating it in an intermediatemodel.The CBSP dimensions include a set of general archi-

tectural concerns we have derived from existing softwarearchitecture research [31, 33, 40, 45, 46, 49]. These dimen-sions can be applied to systematically classify and refinerequirements and to capture architectural trade-off issuesand options (e.g., impact of a connector’s throughput onthe scalability of the topology).Each requirement is assessed for its relevance to the

system architecture’s components, connectors (buses),topology of the system or a particular subsystem, andtheir properties. Thus, each derived CBSP artifact ex-plicates an architectural concern and represents an earlyarchitectural decision for the system. For example, a re-quirement such as

R: The system should provide an interface to aWebbrowser.

can be recast into a CBSP processing component element(Cp) and a CBSP bus element (B)

Cp: A Web browser should be used as a componentin the system.B: A connector should be provided to ensure inter-operability with third-party components.

It is important to emphasize that, while CBSP sup-ports recasting requirements into more architecturally“friendly” model elements along well-defined dimen-


sions, it does not prescribe a particular transformationof a requirement. Instead, our intent is to give a soft-ware architect sufficient leeway in selecting the mostappropriate refinement or, at times, generalization ofone or more requirements. Examples of both refine-ment and generalization are given below. Architectingsoftware systems is inherently a human-intensive activ-ity. The goal of CBSP is, therefore, not to eliminatethe role of human architects in the process. Instead,its goals are to aid the architects in making decisionsthat are effective and timely and in preserving thesedecisions.There are six possible CBSP dimensions discussed be-

low and illustrated with a simple example from a spread-sheet manipulation application. The six dimensions in-volve the basic architectural constructs [31] and, at thesame time, reflect the simplicity of the CBSP approach.

1. C are model elements that describe or involve an in-dividual Component in an architecture. For example,the requirement:

R: Allow user to directly manipulate spreadsheetdata.

may be refined into CBSP model elements describingboth processing components (Cp) and data compo-nents (Cd)

Cp: Spreadsheet manipulation UI component.Cd: Data for spreadsheet.

2. B are model elements that describe or imply a Bus(connector). For example:

R: Manipulated spreadsheet data must be storedon the file system.

may be refined into

B: Connector enabling interaction between UIand persistency components.

3. S are model elements that describe System-wide fea-tures or features pertinent to a large subset of thesystem’s components and connectors. For example:

R: The user should be able to select appropriatedata filters and visualizations.

may be refined into

S: The system should employ a strict separa-tion of data storage, processing, and visualiza-tion components.

4. CP are model elements that describe or imply dataor processing Component Properties. As discussedabove, the properties in CBSP are the “ilities” ina software system, such as reliability, portability, in-crementality, scalability, adaptability, and evolvabil-ity. For example:

R: The user should be able to visualize the dataremotely with minimal perceived latency.

may be refined into

CP: The data visualization component should beefficient, supporting incremental updates.

5. BP are model elements that describe or imply BusProperties. For example:

R: Updates to system functionality should be en-abled with minimal downtime.

may be refined into

BP: Robust connectors should be provided to facili-tate runtime component addition and removal.

6. SP are model elements that describe or imply System(or subsystem) Properties. For example:

R: The spreadsheet data must be encrypted whendispatched across the network.

may be transformed into

SP: The system should be secure.

Note that, e.g., the BP example (5) involved refininga general requirement into a more specific CBSP element.On the other hand, the SP example (6) involved the gener-alizationofa specific requirement intoaCBSPartifact.Re-finements and generalizations such as those shown aboveare a function of the needs of the specific systemunder con-struction, the characteristics of the application domain,and the software architect’s background and experience.Additionally, refining or generalizing a requirement mayalso require consulting the system’s customers for addi-tional context and information.As such,while itwouldun-doubtedly be very useful, it is unrealistic to expect thatformal rules could be provided for transforming a require-ment intomore specific or generalCBSP elements.A meta-model showing the different model elements

relevant to CBSP is given in Fig. 2. Requirements arerelated to architectural elements such as components orconnectors via an intermediate CBSP model that acts asa bridge. Different subtypes of CBSP elements are used torepresent different architectural dimensions listed in theCBSP taxonomy.

2.2 The CBSP process

We also provide a step-by-step process and techniquessupporting the synthesis of the intermediate CBSPmodeland the architecture in a collaborative manner. Fig-ure 3 depicts process activities and deliverables using theIDEF0 notation [24]. In an envisioned iterative life-cyclethe depicted CBSP process represents one cycle of evolv-ing and refining an architecture out of a given set ofrequirements.Each CBSP step is discussed in more detail below. We

use ETVX (Entry, Task, Verification, and eXit) [42] todocument the steps. ETVX cells consist of four compo-nents: (1) Entry lists all items required for the executionof the task (e.g., people, tools, artifacts, etc.); (2)Task de-scribes what should be done, by whom, how, and when(this includes appropriate standards, procedures and re-sponsibilities); (3) Verification/Validation describes allchecks and controls that help to indicate if the task is be-ing executed properly; and (4) eXit lists criteria which


Fig. 2. CBSP Meta Model

Fig. 3. CBSP process


need to be satisfied before the task can be consideredcomplete and the output(s) of the task itself.

2.2.1 STEP 1: Selection of requirements for nextiteration

To reduce the complexity of addressing large numbers ofrequirements, a team of architects applies the CBSP tax-onomy to the most essential set of requirements in eachiteration. The architects eliminate requirements consid-ered unimportant or infeasible through stakeholder-basedprioritization, thus arriving at a set of core requirementsto be considered for the next level of refinement (seeTable 1). Stakeholders rate each requirement for each oftwo criteria [6]: (1) importance shows the relevance andvalue to project success; while (2) feasibility addressesperceived technical, economic, or political constraints onimplementing a requirement.

2.2.2 STEP 2: Architectural classification ofrequirements

A team of architects classifies the selected requirementsusing the CBSP taxonomy (see Table 2). Each require-ments is assessedby the experts basedon the requirement’srelevance to the CBSP dimensions, using an ordinal scale(not=0; partially=1; largely=2; fully=3). For instance,a requirement that is rated as partially relevant along the

Table 1. ETVX cell for step 1

Selection of requirements for next iteration

E Initial set of requirements (in informal or semi-formal notation)Prioritization methodVoting tool

T All success-critical stakeholders eliminate unimportant and infeasible requirements

V Check selection of stakeholdersCheck level of consensus among stakeholders to initiate discussions in case of diverging opinions

X Set of requirements for next-level CBSP refinement


Architectural classification of requirements

E Set of requirements for next-level CBSP refinementCBSP taxonomyVoting tool

T Architects classify selected requirements using the CBSP taxonomy

V Check selection of architectsCheck completeness of classification

X Voting ballotsArchitectural relevance profiles for all requirements

component (C) dimension implies that it has some (par-tial) impact on one ormore architectural components.A profile showing the aggregated architectural rele-

vance (e.g., C/B/S/CP/BP/SP) is created for each re-quirement. Figure 4 shows some examples of relevanceprofiles.

2.2.3 STEP 3: Identification and resolution ofclassification mismatches

If multiple architects independently perform an archi-tectural classification of requirements using CBSP, theirfindings may diverge since they may perceive the samestatement differently. Revealing the reasons for diverg-ing opinions is an important means of identifying misun-derstandings, ambiguous requirements, tacit knowledge,and conflicting perceptions [20]. The voting process is asa mechanism to reveal dissent among the architects andto reduce risks in requirements refinement (see Table 3).The measured consensus among the architects serves asa proxy for their mutual understanding of a requirement’smeaning and their agreement on the architectural rele-vance of a requirement. We determine the level of consen-sus through Kendall’s coefficient of concordance, a meas-ure of the association among stakeholders’ ratings [47].The rules in Table 4 indicate how to proceed in

different situations: in case of consensus among archi-tects, the requirements are either accepted or rejected


Fig. 4. Relevance profiles


Identification and resolution of classification mismatches

E Voting ballotsArchitectural relevance profiles for all requirements

T Architects discuss reasons for diverging opinions for low-consensus itemsArchitects update requirements to address issues and ambiguitiesArchitects exclude architecturally irrelevant requirements

V Check dependencies among requirements to make sure critical requirements are not dropped

X Issues and ambiguitiesArchitecturally relevant requirements

Table 4. Concordance/relevance matrix

RelevanceConcordance ≥ Largely < Largely

Consensus Accept RejectConflict Discuss

based on the voted degree of architectural relevance.We accept requirement as architecturally relevant ifthe mean of all stakeholder is at least “largely”, oth-erwise the requirement is rejected. If the stakehold-ers cannot agree on the relevance of a requirementto the architecture, they further discuss it to revealthe reasons for the different opinions. This discussion


Architectural refinement of requirements

E Issues and ambiguitiesArchitecturally relevant requirements

T Architects rephrases and splits requirements that exhibit overlapping CBSP propertiesArchitects eliminate redundancies

V Check to make sure that redundancies are minimized

X CBSP elementsDependencies among CBSP elements

process may also involve customers and other stake-holders to clarify a requirement and eases the subse-quent step of refining it into one or more architecturaldimensions.

2.2.4 STEP 4: Architectural refinement of requirements

In this activity the team of architects rephrases and splitsrequirements that exhibit overlapping CBSP propertiesand concerns (see Table 5). Each requirement passing theconsensus threshold (concordance and at least largely rel-evant) may need to be refined or rephrased since it may berelevant to several architectural concerns. For instance,if a requirement is largely component relevant, fully busrelevant, and largely bus property relevant, then splitting


it up into several architectural decisions using CBSP willincrease clarity and precision.During this process, a given CBSP artifact may ap-

pear multiple times as a by-product of different require-ments. For example, the following two requirements re-sult in the identification of a Cargo data component.

R01: Support for different types of cargo.R09: Support cargo arrival and vehicle estimation.

Such redundancies are identified and eliminated in theintermediate CBSP model. It is also possible to mergemultiple related CBSP model elements and converge ona single artifact (e.g., R09_Cd: Vehicle in Fig. 5).This step of the process may be undertaken using two

slight variations. The first variation involves identifyingonly the structural aspects of the system, i.e., its C, B,and S elements. Then, for each of these elements, theirproperties are identified in a separate (sub)step. This hasthe advantage of separating the two concerns (structureand functionality vs. non-functional system aspects) andallowing an architect to focus more clearly on the “bigpicture”. The second variation is to identify, in a singlestep, both the system’s structural elements and their non-functional properties. This has the advantage of stream-lining the process and allowing the architect to focuson a single system concern (or small set of concerns) ata time. Both variations can be combined in one project.For example, the team of architects may perform a single

Fig. 5. Relationships between requirements and CBSP model in cargo router example

iteration using the first variation followed by iterationsusing the second variation.

2.2.5 STEP 5: Trade-off choices of architecturalelements and styles with CBSP

At this point, requirements should have been refined andrephrased into CBSP model elements in such a mannerthat no stakeholder conflicts exist and all model elementsare at least largely relevant to one of the six CBSP dimen-sions. Based on simple CBSP model elements, a “proto-architecture” can be derived.Architectural styles [1, 30, 40, 46] provide rules that

exploit recurring structural and interaction patterns (re-ferred to as “architectural patterns”) across a class ofapplications and/or domains. A style guides the architec-tural design of a system, with the promise of desirablesystem qualities. At the same time, the rules guiding theselection and application of a style (or of specific architec-tural patterns suitable in that style) are typically semi-formal at best, requiring significant human involvement.Furthermore, multiple architectural styles may appear tobe (reasonably) well suited to the problem at hand, re-quiring additional work to select the most appropriatestyle. This issue is further discussed below.Based on the dependencies among the elements in

CBSP, the rules of the selected style allow us to composethem into an architecture. In other words, we select the



Trade-off choices of architectural elements and styles with CBSP

E CBSP elementsDependencies among CBSP elementsProperty to Style Mapping Table

T Architects identify candidate stylesArchitects identify candidate architectural elementsAnalyze properties of CBS elements

V Reconcile CBSP elements with architectural elements to avoid incompatible solutions

X Candidate stylesCandidate componentsCandidate connectors

style based on (1) the characteristics of the applicationdomain and (2) the desired properties of the system, iden-tified in the requirements negotiation and elaborated inthe CBSP model (see Table 6). This can, of course, resultin multiple candidate styles (or no obvious candidates).The selection of the style is choice of the architects. Byconsidering the rules and heuristics of the selected style(s)the architects start converting the CBSP model elementsinto components, connectors, configurations, and data,with the desired properties.The specific procedure we are using for selecting the

suitable architectural style(s) is derived influenced by ourprevious work [12, 31, 32, 34], from the Architect’s Auto-mated Assistant (AAA) approach [12, 16], as well as thework of other researchers [14, 16, 45] on characterizing adclassifying architectural styles. AAA supports rapid eval-uation of architectural options with respect to recurringstylistic concerns (i.e., architectural properties) such asconcurrency, distribution, loci of control, layering, reen-trance, latency, data transfer types, and so forth. In add-ition to these recurring properties (which map to CBSP’sP dimension), we augment the support provided by AAAby decomposing architectural styles along five concerns(which account for CBSP’s C, B, and S dimensions):data, behavior, interaction, structure, and compositionrules. Our expanding classification of styles, which grewout of our classification of software connectors [33], cap-tures known styles in terms of these five concerns. To-gether, AAA and the style classification provide a signifi-cant aid to the architect in further refining CBSP modelelements into architectures that adhere to specific styles.The observation that guides our selection of styles is

that, while individual architectural elements and theircomposition in an architectural topology are important,it is the properties of those elements and the topologythat guide the selection of a given style.An example set of properties for data components,

processing components, buses, and (sub-) systems is spec-ified as the rows of Table 7. For example, we may beinterested whether a given data component is cached ;we may also like to know whether a given connector is

asynchronous. Note that Table 7 is clearly not complete;many other properties for each CBSP element are pos-sible. However, the goal is not to produce a complete suchtable, for two reasons: First, a complete table may beinfeasible since it would constitute a complete character-ization of any software system. Second, the goal of thetable is to help us identify the appropriate architecturalstyle. As such, it needs to be only as comprehensive as ne-cessary to narrow down the choice of the appropriate stylebased on the properties in question; if the table proves tobe insufficient in helping an architect determine a suitablestyle in a given project, it is simply expanded to includeadditional properties.Table 7 shows a characterization of five architectural

styles (client-server, C2, event-based, layered, and pipe-and-filter) based on a set of example properties. Thestyles are characterized in detail by Fielding [14]. In thispaper, we only briefly summarize them:

• Client-server architectures involve synchronous call-based interactions between service requesting clientsand service providing servers. The clients are aware ofthe server’s identity and location, but not the other wayaround. The clients may communicate only with theserver, but not with other clients.• C2 architectures involve asynchronous event-based in-teractions among components that may be both serviceproviders (i.e., servers) and requesters (i.e., clients)simultaneously. Connectivity among components iscontrolled by a set of layering rules and explicit, event-broadcasting connectors.• Event-based architectures also involve event-based in-teractions among components. These interactions maybe synchronous or asynchronous. Each component mayprovide or request services. Events are dispatched byspecial-purpose (meta-level) facilities in the system.• Layered architectures involve synchronous call-basedinteractions between components that are divided intolayers. A component in a given layer may only invokecomponents in the layer below it, and is invoked by thecomponents in the layer above it.


Table 7. CBSP to style mapping

CBSP Dimensions Properties Client-Server C2 Event-Based Layered Pipe-and-Filter

Data Component aggregated ++ ++ ++ + −persistent ++ o o o ostreamed − − − − ++cached ++ + − − −

Processing service provide/consume only ++ o o o oComponent has N interfaces ++ + ++ − −

stateful + ++ ++ + −Loose coupling + + ++ − ++can be migrated + ++ ++ − −

Connector/bus synchronous ++ − + ++ −asynchronous − ++ ++ − ++local − ++ o ++ +distributed ++ ++ ++ − +secure + o o + o

(sub)System efficient o + + o −scalable + o − − +evolvable ++ ++ ++ − ++portable o + o ++ oreliable o o − o odynamically + ++ ++ − ++reconfigurable

Legend: ++ extensive support + some support o neutral − no support

• Pipe-and-filter architectures involve asynchronous in-teractions involving the exchange of untyped streamsof data between components (filters) via connectors(pipes).

For each of these styles, we have identified the degreeto which they satisfy the properties identified in Table 7.These (partial) characterizations of the five styles willbe used in the example in the next section to drive theselection of the appropriate style(s) and, subsequently, ar-chitecture(s) in an example application. Both additionalstyles and additional properties should be added to thetable as the need for them arises.The resulting architectural elements, their dependen-

cies, properties, and styles give the building blocks fordeveloping an architecture. At this point, the nature ofsoftware systems demands the involvement of software ar-chitects in order to reconcile CBSP artifacts and packagethem into an effective architecture (see Sect. 3.5).

3 The Cargo Router case study

This section illustrates the development of an interme-diate CBSP model in the context of a case study inwhich we applied the CBSP approach. Our example ap-plication is developed in collaboration with a major U.S.software development organization. It addresses a sce-nario in which a natural disaster results in extensivecasualties and material destruction. In response to the

situation, an international humanitarian relief effort isinitiated, causing several challenges from a software en-gineering perspective. These challenges include efficientrouting and delivery of large amounts of material aid;wide distribution of participating personnel, equipment,and infrastructure; rapid response to changing circum-stances in the field; using existing software for tasks forwhich it was not intended; and enabling the interopera-tion of numerous, heterogeneous systems employed by theparticipating countries. In particular, our system (calledCargo Router) must handle the delivery of cargo fromdelivery ports (e.g., shipping docks or airports) to ware-houses close to the distribution centers. Cargo is movedvia vehicles (e.g., trucks and trains) selected based onterrain, weather, accessibility and other factors. Our sys-tem must also report and estimate cargo arrival timesand vehicle status (e.g., idle, in use, under repair). Theprimarily responsibility of the system’s user is to initiateand monitor the routing of cargo through a simple userinterface.We have performed a thorough requirements, ar-

chitecture, and design modeling exercise to evaluateCBSP in the context of this application. We used Easy-WinWin to identify and negotiate requirements for theCargo Router system. EasyWinWin is a groupware-supported methodology [4] based on the WinWin ap-proach [3] that enhances the directness, extent, and fre-quency of stakeholder interactions. EasyWinWin adoptsa set of COTS groupware components (e.g., electronic


brainstorming, categorizing, voting, etc.) developed atthe University of Arizona and commercialized byGroupSystems.com.The stakeholders jointly elaborated 81 requirements.

In a first step, the team converged on 64 requirements(79% of all requirements) by reviewing and reconcil-ing similar or redundant ones. For instance, one stake-holder asked to “track location of vehicles” whereasanother asked for “the system [to] enable real-time sta-tus reports and updates on ports, warehouses, vehi-cles, and cargo.” Obviously, both stakeholders pursuedsimilar requirements which were merged (after verify-ing stakeholder consensus) into the more general re-quirement “Support for real-time communication andawareness.”

3.1 Selection of requirements for next iteration

The 64 requirements became the initial baseline for theCargo Router project and covered functional and non-functional aspects, system interfaces, software process as-pects, as well as time and budget constraints. To identifythe set of requirements needed for a first CBSP model inthe first iteration, we performed a joint prioritization ofthe 64 requirements and selected the 25 (39%) require-ments with the highest importance and feasibility.

3.2 Architectural classification of requirements

To surface and extract the architecturally relevant in-formation from the pool of 25 core requirements, a vot-ing process was initiated. Four architects classified eachrequirement with respect to its architectural relevancealong the six CBSP dimensions (C/B/S/CP/BP/SP).With four stakeholders involved, a total of 600 votes werecast. This classification process was carried out in lessthan one hour.For instance, the requirement “Support cargo ar-

rival and vehicle availability estimation” was voted to bestrongly component-relevant by all architects, whereasthe requirement “The system must be operational within18 months” was not voted to be architecturally rele-vant. This does not mean that process and businessaspects are, in general, unrelated to a system’s archi-tecture. For example, a schedule constraint may causearchitecturally-relevant requirements to be dropped orrelaxed. Some requirements also received contradictoryvotes: the requirement “Automatic routing of vehicles”was voted component relevant (Cp and Cd) by all ar-chitects, but system property (SP) relevant by only onearchitect. At the same time, there was a high degree ofconsensus on other requirements. For example, since ar-chitects voted the requirement “Support cargo arrivaland vehicle availability estimation” to be only compon-ent relevant (largely and fully ratings), this requirementwas accepted as architecturally relevant without furtherdiscussions.

3.3 Identification and resolution of classificationmismatches

Ambiguities in the requirements’ meanings led to severalconflicts when the architects contradicted one another inrating the architectural relevance of requirements. For in-stance, the architects disagreed on the system property(SP) relevance of the requirement “Automatic routing ofvehicles,” and cast ballots for not , partial , and full ar-chitectural relevance. The concordance matrix in Table 4suggests that in such a situation stakeholders need to dis-cuss the mismatch. In this particular case, the discussionrevealed different perceptions of what this requirementimplied. One stakeholder thought this requirement im-plied that the system needs to suggest paths that vehiclestravel (e.g., via navigation points), but not their sourcesand targets. Another stakeholder perceived the require-ment such that the system would also need to suggestthe sources and destinations for vehicles. The discussionclarified this conflict and an instant re-vote identified thisrequirement as indeed system property relevant.From the total of 150 decisions (= 25 requirements×

6 dimensions), 43 decisions (29% of all decisions) affect-ing 19 requirements (30% of all requirements) turned outto be controversial and needed further attention. After allconflicts were resolved, 19 out of the original 25 require-ments remained in the pool of architecturally relevantrequirements.

3.4 Architectural refinement of requirements

Architecturally relevant requirements explicate at leastone CBSP dimension. Often requirements address mul-tiple dimensions. For instance, the requirement “Matchcargo needs with vehicle capabilities” was voted to beonly processing component (Cp) relevant, whereas the re-quirement “Support cargo arrival and vehicle availabil-ity estimation” was voted to be fully component rele-vant, fully system relevant, and largely bus relevant. Assuch, the latter requirement was much more comprehen-sive than the former. In fact, the latter requirement evendepended on the former. For instance, the need for spe-cial types of vehicles (e.g., to ship liquid substances) alsohas an impact on delivery time. In order to better re-late such requirements, it is necessary to refine them intomore atomic entities. For instance, the fact that cargoarrival estimation depends on vehicle capabilities doesnot imply that the former requirement fully depends onthe latter.CBSP dimensions also play an important role in the

requirements refinement process. For example, the re-quirement “Match cargo needs with vehicle capabilities”was determined to be only component relevant. As such,the requirement was analyzed and refined into the pro-cessing component Cargo/Vehicle Matcher . This process-ing component requires as input cargo and vehicle in-formation, resulting in its dependency on relevant data


components (e.g., Cargo weight). Since some of thosedata components did not exist beforehand, they werealso created. As a result, the refinement of this require-ment produced two types of information: (1) CBSPmodelelements (processing and components) describing archi-tectural decisions and (2) links describing dependenciesamong those model elements. The CBSP model elementsprovide potential building blocks for the architecture,whereas the CBSP dependencies help to clarify potentialcontrol and data dependencies within the architecture.The refinement process of a more complex require-

ment is similar but more elaborate. For instance, as dis-cussed above, the requirement “Support cargo arrivaland vehicle availability estimation” was determined tobe C, B, and S relevant. At a high level, this require-ment supports two processing components: Cargo ArrivalEstimator and Vehicle Availability Estimator . Cargo Ar-rival Estimator depends on data components represent-ing Cargo, the Vehicle carrying the cargo, and the Lo-cation of the vehicle. Vehicle Availability Estimator onlydepends on the knowledge about the vehicle and its lo-cation (but not cargo). The above requirement was alsorated bus-relevant. This was the case because the loca-tion of a vehicle (and its cargo) is variable as it moves.A connector (bus) is therefore needed to allow the systemto track vehicles (recall requirement “Real-time commu-nication and awareness”).Figure 5 shows an excerpt of the CBSP model for

the Cargo Router example. It depicts the refinement ofsix requirements into CBSP model elements. As an ex-ample, the figure depicts the requirement “Support fordifferent types of cargo” (left) and shows that it was re-fined into a simple data component called Cargo (right).The requirement “Support cargo arrival and vehicle avail-ability estimation” was more complex and was brokenup into several model elements including two process-ing components and a bus component. The figure showsthat those model elements were additionally refined viasub-elements (e.g., Vehicle) and dependencies. This addi-tional refinement is not necessary, but can result in usefulinsights into overall system interdependencies. For in-stance, we learn that the cargo component is also neededby other requirements, making Cargo a centerpiece of thesystem. Should we later want to remove cargo descrip-tions from the system, the existing dependencies wouldallow us to reason about the impact of this removal onother parts of the architecture and/or the requirements.In the context of CBSP, refined model elements can bemerged in case of similarity resulting in less duplicationbut more CBSP artifact dependencies (e.g., we do not cre-ate multiple Cargo data components). As stakeholders inour case study refined all requirements into CBSP modelelements, they identified 27 CBSP model elements acrossthe architecturally relevant requirements.While refining requirements into structural CBS elem-

ents and dependencies, it becomes obvious that not allarchitecturally relevant information can be expressed this

Fig. 6. Identifying properties in architecture-relevantrequirements

way. For example, the requirement “Support cargo ar-rival and vehicle availability estimation” among otherelements resulted in a connector “Comm-Link to vehi-cle” but this requirement also implied a central need toaccess (potentially) distributed resources. The connectormust thus accommodate distributed vehicles; ergo a prop-erty of the connector is “distributed.” Other requirementsinfer additional properties. For example, automatic rout-ing of vehicles requires access to some predefined set ofroutes (or navigation points). These need to be persis-tent; hence, the persistent property for the data compon-ent Route. Multiple requirements may infer properties onsingle structural CBS elements. For example, the require-ment “In case of network downtime, the system shouldmaintain the latest known facts about [ . . . ] vehicles” im-plies vehicles to “cache” data. Furthermore, the require-ment “Vehicles are equipped with location emitters andgenerally cannot receive commands during driving” im-plies vehicles to accept “streamed” data (see Fig. 6).

3.5 Trade-off choices of architectural elements and styleswith CBSP

CBSP model elements, their dependencies, and theirproperties are valuable for architecture and requirementstrade-off analyses. They are also useful in creating andmodifying architectural representations. Componentsand buses typically relate to architectural elements di-rectly, or they may encapsulate sets of architectural elem-ents. For example, the architecture of the Cargo Router


will likely have a Vehicle component and a Cargo Ar-rival Estimator component. Even dependencies derivedduring the CBSP refinement are likely to infer architec-tural data and/or control dependencies. For example, theCargo Arrival Estimator component was found to dependon vehicle information. This dependency indicates a datadependency in the architecture.CBSP properties likely will not translate into archi-

tectural elements directly. Instead, they will imply con-straints on architectural elements. The most obvious con-straints on architectural elements are imposed througharchitectural styles. Properties can thus be used to inferor restrict the types of architectural styles applicable tothe CargoRouter case study. Table 8 lists properties iden-tified above and their ability to satisfy a given architec-tural style.A handful of properties does not allow an architect to

derive an architectural style for a complex software sys-tem. However, architectural styles differ in their abilityto satisfy certain properties. It follows that one can favorsome architectural styles over others if the styles favor thedesired properties. As foreshadowed above, the currenttreatment of architectural styles is still largely informal.For this reason, we do not believe that styles can be se-lected and composed automatically from requirements.Instead, this is the responsibility of the architect(s). How-ever, CBSP can recommend styles based on how well theysatisfy the properties of a given system. If an architec-tural style is consistently unsuitable for a given set ofCBS properties then clearly this style is a bad fit. Table 8lists the properties from the Cargo Router system in thecontext of the five example styles introduced in Sect. 2and depicted in Table 7. An architect may infer from thistable that the layered style is clearly less suitable thanthe client-server style for architecting this system. Notsurprisingly, none of the given styles is a perfect fit. For

Table 8. Architectural styles for cargo router

CBSP Dimensions Properties Client-Server C2 Event-Based Layered Pipe-and-Filter

Route persistent ++ o o o o(data component)

Warehouse cached ++ + − − −(data component)

Vehicle streamed − − − − ++(data component) cached ++ + − − −

User Interface for Vehicle, loose coupling + + ++ − ++Warehouse, and Route(processing component)

Comm-Link to Vehicle distributed ++ ++ ++ − +(connector)

System dynamic reconfigure + ++ ++ − ++reliable o o − o o

example, the client-server style is suitable for all but thestreaming property in the Vehicle data component. Thisdoes not necessarily imply that this style is unsuitablefor the system, only that the style needs to be somehowadapted to accommodate this property. The client-serverstyle is clearly better suited than the layered style; how-ever, the C2 and the pipe-and-filter styles are reasonablealternatives to client-server, depending on what proper-ties are deemed most important.CBSP gives the architect the necessary input for de-

ciding how best to design and implement a given systemin a manner that is easier to understand than the originalrequirements. It is then still the architect’s responsibilityto build the system. Both C2 and client-server were con-sidered for the Cargo Router system in our case study,even though the system was eventually implemented ac-cording to the C2 style. Figure 7 depicts the resultingarchitectures in both styles and shows potential solutionsto alleviate the style shortcomings. The solution on theleft of Fig. 7 implements the Cargo Router system usingthe C2 architectural style primarily. We find the Esti-mator component placed underneath the Vehicle com-ponent in the C2 architecture following C2’s rules. C2requires service-providing components to be put aboveservice-requiring components. The CBSP model elem-ents discussed previously are either directly representedin C2 or are grouped together into C2 elements (e.g.,Vehicle data components, Estimator processing compo-nents). The only CBSP artifact not represented in C2is Cargo, which is defined using C2’s ADL [30] (not de-picted here). The C2 architectural style dictates a strictrequest/response behavior of components. It is thus notvery suitable to model the streaming behavior requiredfor vehicles. This problem was solved by implementingthe C2 vehicle component using the pipe-and-filter style.Internally, Vehicle is thus able to receive streaming data


Fig. 7. Two cargo router architectures consistent with CBSP results

from vehicles while externally it appears to be a normalC2 component. The combined system thus implementsall given CBS elements, dependencies, and properties de-spite the imperfect fit of individual styles.The solution on the right of Fig. 7 implements the

Cargo Router system primarily using the client-serverstyle. Instead of “hiding” the signal receiving elementas in the C2 solution, this solution models the receiversas clients. Clients are standalone applications that in-teract with servers. In this solution, the server is pri-marily a database to store persistent and cached data.The actual application used by operators of the CargoRouter system is implemented through a separate clientthat communicates with the same data server. Vehicleand warehouse data is thus readily availably without re-quiring the operator client to handle streaming data. Itis interesting to note that the overall client-server archi-tecture addresses most of the properties required by theCargo Router: clients can be distributed, they are looselycoupled, they can be reconfigured dynamically, and theysupport persistent data. The internals of the OperatorClient thus can be implemented in the simple and effi-cient layered architectural style that previously seemed sounsuitable. This solution, like the previous one, demon-strates that by carefully architecting a system, one canaccommodate a variety of properties that may even ap-pear contradictory at times.

4 Tool support

Our ultimate goal is to provide tool support for the CBSPapproach. This section discusses tools we have devised to

support the CBSP approach. We have adopted off-the-shelf components from GroupSystems.com’s groupwaresuite and we have developed a bridge to the COTS mod-eling tool Rational Rose to ease the transition of require-ments into architecture and allow integration of this workwith our existing requirements [20], architecture [30], anddesign tools.Selection of requirements for next iteration. Thisactivity is supported as part of the EasyWinWin ap-proach. Stakeholders use a distributed voting tool to as-sess requirements for their importance and feasibility [6].Voting is used to determine priorities of requirementsand to reveal conflicts, mismatching perceptions, or hid-den assumptions. Stakeholders rate each requirement foreach of two criteria: Importance shows the relevance ofa requirement to project success; feasibility indicates per-ceived technical or economic constraints of implement-ing a requirement. In the voting process developers typ-ically focus on technical issues, while clients and usersconcentrate on the relevance. Requirements are automat-ically grouped in one of four categories: “low hangingfruit” (high importance, low expected difficulties), “im-portant with hurdles” (high priority, difficult to realize),“maybe later” (low-priority, maybe considered later aseasy to realize), and “forget them” (unimportant, diffi-cult to achieve).Architectural classification of requirements. Thisstep is fully tool-supported by a COTS voting tool. TheCBSP dimensions are assessed in a voting process in-volving multiple experts. Figure 8 depicts voting results(architectural relevance profiles) showing requirements asnot relevant (No), and partially (Pa), largely (La), or fully(Fu) relevant .


Fig. 8. CBSP classification and conflict detection

Identify and resolve classification conflicts.We alsoprovide tool support for identifying and resolving classifi-cation mismatches. This is achieved by highlighting con-flicting opinions and perceptions.Different cell colors indi-cate the level of consensus among the experts.Consensus isindicated with green (light gray in Fig. 8), while disagree-ment is indicated with red (dark gray in Fig. 8). The votespread can be displayed (small window in Fig. 8) to triggerdiscussions about differences in opinion.

Fig. 9. CBSP model in IBM rational’s UML modeling tool

Architectural refinement of requirements. A pro-totype interface to a UML modeling tool is provided tosupport repository-based integration and refinement ofrequirements. A bridge from the GroupSystems platformallows translating requirements negotiation results andthe CBSP model into a UML representation (see Fig. 9).UML stereotypes are used to extend the modeling capa-bilities and enable artifact types such as bus property,component, etc. Our tool support supports traceability


between requirements and CBSP artifacts thus easingtrace-off analyses and software evolution [11].Trade-off choices of architectures elements andstyles with CBSP. We currently do not provide spe-cific tool support for recommending architectural styles.CBSP model elements and dependencies do constrain thearchitectural space in a manner that potentially supportsthis kind of reasoning. We intend to address this area inour future work.

5 Related work

The work described in this paper is related to severalareas of research covering requirements, architecture, andmodel transformation.To date, we have applied CBSP in the context of the

WinWin requirements negotiation approach. WinWin isrelated to other techniques that focus on capturing andevolving stakeholder goals into requirements [10, 13, 25,26, 35, 41, 44] (note that goals reflect the objectives of in-dividual stakeholders and may be contradictory). We be-lieve that CBSP would also work with these approaches.Our work on refining requirements complements suchprocesses with a structured transformation technique andtool support. Our approach is also consistent with thePREview approach by Sommerville and Sawyer as it em-phasizes multi-perspective requirements engineering aswell as conflict detection and resolution [48]. However,other approaches that enable automated refinement of re-quirements (e.g., [38]) are predicated on a more formaltreatment of requirements.A key issue in transforming requirements into archi-

tecture and further software model elements is traceabil-ity. Researchers have recognized the difficulties in captur-ing development decisions across modeling model elem-ents [17]. Gotel and Finkelstein [19] suggest a formal ap-proach for ensuring the traceability of requirements dur-ing development. Our approach captures extensive tracesthus satisfying many of the needs identified in [17, 19, 43].CBSP eases capturing of trace links by narrowing thegap between informal or semi-formal requirements andarchitecture models. Traceability can be created natu-rally with CBSP by monitoring the refinement process.This is easy and tool supported. We also developed tech-niques for dealing with traceability between architec-ture, requirements, and code during software evolution(e.g., [11]).Within the area of software architectures, two con-

cepts provide guidance for architects in converting systemrequirements into effective architectures. The first is ar-chitectural styles [46], which capture recurring structural,behavioral, and interaction patterns across applicationsthat are in some way related and/or similar. As discussedabove, we indeed make extensive use of architecturalstyles in formulating an architecture from a collection ofCBSP model elements. The drawback that our approach

inherits from styles is that they are typically collectionsof design heuristics, requiring extensive human involve-ment and adding a degree of unpredictability to the taskof transforming CBSP model elements into architectures.The second related concept is domain-specific softwarearchitecture (DSSA) [49]. A DSSA captures a model ofthe (well understood) application domain, together witha set of recurring requirements (called reference require-ments) and a generic architecture (called reference archi-tecture) common to all applications within the domain.While these DSSA model elements would make the taskof arriving at an architecture from CBSP model elementseven simpler than by leveraging styles, CBSP does not re-quire the existence of a DSSA, nor is it restricted only toextensively studied application domains.Several approaches have been proposed to ease bridg-

ing requirements and architectures:The ATAM technique [25] supports the evaluation of

architectures and architectural decision alternatives inlight of quality attribute requirements.Nuseibeh [36] describes a twin peaks model that aims

at overcoming the often artificial separation of require-ments specification and design by intertwining these ac-tivities in the software development process. In line withthe twin peaks model, the CBSP approach also argues forthe iterative, concurrent development of requirements,architectures, and the intermediate CBSP model. TheCBSP process describes one iteration in such a develop-ment context. The intermediate CBSP model also helpsto relate architectural issues and requirements.Hall et al. describe an extension to Jackson’s Prob-

lem Frames Approach that adopts the idea of the TwinPeaks model supporting the iteration between problemand solution structures [22]. The authors propose to al-low architectural structures, services, and artifacts to beconsidered as part of the problem domain rather than thesolution domain. They extend the current model of themachine domain in problem frames to view it as an archi-tectural engine.Brandozzi and Perry [5] coin the term architecture

prescription language for their extension of the KAOSgoal specification language [27] towards architecturaldimensions.Bruin et al. [7] use an approach called FS-graphs to re-

late the desired system features (e.g., quality attributes)and solution fragments (e.g., development activities) thateffect those features. For example, a desired feature maybe “The system must be secure.” while the correspond-ing solution fragment may be “Employ an encryptionscheme.” FS-graphs use weighted relations and providea set of operators (AND, OR, XOR) to relate multiplefeatures with multiple solution fragments. The objectiveof FS-graphs is to allow reuse and composition of solutionfragments across systems with similar desired features.As may be seen from the simple example above, unlikeCBSP, FS-graphs are not specifically geared to relatinga system’s quality requirements to its architecture, but


instead deal with the solution space at a much higher ab-straction level. Bruin et al. have recently begun movingtheir work in the direction of software architectures aspart of the QUASAR (QUality-driven Software ARchi-tecture) project.Chung et al. discuss how architectural properties such

as modifiability and performance can be modeled as“softgoals” and how different architectural designs sup-port these goals. Architectural decisions can be tracedback to stakeholders [8].Franch and Maiden apply the i∗ actor-based model-

ing approach [9] for modeling software architectures, notin terms of connectors and pipes, but in terms of actordependencies to achieve goals, satisfy soft goals, use andconsume resources, and undertake tasks [15].Finally, CBSP also relates to the field of transforma-

tional programming [2, 28, 39]. The main differences be-tween transformational programming and CBSP are intheir degrees of automation and scale. Transformationalprogramming strives for full automation, though its ap-plicability has been demonstrated primarily on small,well-defined problems [39]. CBSP, on the other hand, canbe characterized only as semi-automated; however, wehave applied it on larger problems and a more heteroge-neous set of models, representative of real developmentsituations.

6 Conclusions and further work

We have introduced the CBSP (Component, Bus, Sys-tem, Property) approach that aims at reconciling soft-ware requirements and architectures using intermediatemodels. The CBSP intermediate model still “looks” likerequirements, but already “sounds” like architecture. Theuse of CBSP in refining requirements allows developersto systematically explore and identify (1) ArchitecturalElements (Components and Connectors), (2) Architec-tural Properties (CP, BP, and SP), (3) Architectural De-pendencies, and (4) Suitable Architectural Styles. How-ever, the use of CBSP does not result in an architec-ture directly. As demonstrated on the case study, CBSPmerely elicits the architectural building blocks requiredto architect a given system. It is the responsibility of thearchitect to then use these blocks to build an effective ar-chitecture that satisfies CBSP’s architecturally-relevantinformation and, consequently, the requirements.The quality of the results derived through CBSP

varies depending on the capabilities of the participat-ing developers. An experienced architect is likely to elicitmore correct CBSP information than a novice architect.While human error cannot be eliminated in such a soft-ware development activity, CBSP is able to deal with itthrough conflict identification and resolution.The number of artifacts produced by CBSP is related

to the size and complexity of the system. However, thenumber of CBSP elements is unlikely to exceed the num-

ber of architectural elements required to build a system,as CBSP identifies architecturally relevant informationonly. We believe that CBSP is thus scalable to the extentthat the architecture is scalable. Clearly, using CBSP ishuman intensive. It requires multiple architects to inves-tigate all given requirements and refine them into CBSPartifacts. Nonetheless, this or analogous activity must beperformed with or without CBSP; CBSP assists this pro-cess by providing guidance and support.We believe that, although a deliberately simple and

lightweight approach, CBSP assists in coping with thechallenges discussed in the introduction.

• Bridging different levels of formality: CBSP providesan intermediate model that reduces the semantic gapbetween high-level requirements and architectural de-scriptions.• Modeling non-functional requirements: CBSP allowsarchitects to identify and isolate “ilities” in require-ments at the system level (SP) and architectural-element level (CP, BP), thus improving modeling ofnon-functional properties.• Maintaining evolutionary consistency: The intermedi-ate model between requirements and architecture pro-duced by CBSP allows specifying more meaningful de-pendency links that improve evolutionary consistency.• Incomplete models and iterative development : CBSPdoes not mandate that the requirements be complete.CBSP also allows architects to maintain arbitrarilycomplex dependencies between a system’s require-ments and its architecture, thus easing iterations be-tween the two [36].• Handling scale and complexity: CBSP focuses only onthe most essential subset of requirements in each it-eration and, further, on the subset of those require-ments describing architecturally relevant properties. Infact, each activity in the CBSP process results in filter-ing out requirements or merging multiple requirementsinto one. Voting is an important mechanism for reduc-ing complexity by increasing focus and allowing to bet-ter understand different stakeholder perceptions.

In our future work we intend to extend CBSP in thefollowing directions:

• Although successfully demonstrated in the context ofEasyWinWin and C2, we believe that CBSP has po-tential for wider applicability as it provides a genericframework of bridging requirements into architectureand design. Further validation is needed by exploringCBSP using a wider set of requirements and architec-ture languages and methods (e.g., the UML).• We are also aiming at improving the method to bettersupport capturing feedback from architecture model-ing to requirements negotiations. Specifically, we arelooking at how findings from architectural modeling,simulation, etc. can be captured as CBSP model elem-ents (e.g., bus property issue, system property issue,component option, etc.).


• We are interested in extending ADLs (e.g., C2) to bet-ter support modeling of properties captured as gran-ular CBSP model elements. To date, ADLs have beennoticeably deficient in this regard [31].• Another thread of research is to integrate CBSP withapproaches to recover architectural models from ex-isting systems by comparing discovered and recoveredarchitectural models [29].• We are also applying the approach in different projectsto find out if CBSP taxonomies can be tailored andoptimized to different domains. Three case studies arecurrently carried out.• The tools supporting CBSP are only loosely integrated.We will also work to improve the integration and levelof support of our current tool set.

Acknowledgements. This research has been supported by the Aus-trian Science Fund (Erwin Schrodinger Grant 1999/J 1764 “Col-laborative Requirements Negotiation Aids”). This material is alsobased upon work supported by the National Science Foundationunder Grant No. CCR-9985441. Effort also sponsored by the De-fense Advanced Research Projects Agency (DARPA), Rome Lab-oratory, Air Force Materiel Command, USAF under agreementnumbers F30602-00-2-0615 and F30602-00-C-0218. The U.S. Gov-ernment is authorized to reproduce and distribute reprints forGovernmental purposes notwithstanding any copyright annotationthereon. The views and conclusions contained herein are those ofthe authors and should not be interpreted as necessarily repre-senting the official policies or endorsements, either expressed orimplied, of DARPA, Rome Laboratory or the U.S. Government.

References

1. Batory D, O’Malley S (1992) The Design and Implementationof Hierarchical Software Systems with Reusable Components.ACM Transactions on Software Engineering and Methodology(TOSEM) 1(4): 355–398

2. Bauer FL, Moller B, Partsch H, Pepper P (1989) FormalProgram Construction by Transformations-Computer-Aided,Intuition-Guided Programming. IEEE Transactions on Soft-ware Engineering 15(2): 165–180

3. Boehm BW, Egyed A, Kwan J, Port D, Shah A, Madachy R(1998) Using the WinWin Spiral Model: A Case Study. IEEEComputer 7: 33–44

4. Boehm BW, Grunbacher P, Briggs RO (2001) DevelopingGroupware for Requirements Negotiation: Lessons Learned.IEEE Software 18(3): 46–55

5. Brandozzi M, Perry DE (2001) Transforming Goal-OrientedRequirement Specifications into Architecture Prescriptions.In: Workshop “From Software Requirements to Architectures”(STRAW’01) at ICSE 2001

6. Briggs RO, Grunbacher P (2002) EasyWinWin: ManagingComplexity in Requirements Negotiation with GSS. In: 35thAnnual Hawaii International Conference on System Sciences(HICSS’02) – Volume 1. Big Island, Hawaii

7. de Bruin H, van Vliet H, Baida Z (2002) Documenting andAnalyzing a Context-Sensitive Design Space. In: WorkingIFIP/IEEE Conference on Software Architecture (WICSA 3).Montreal

8. Chung L, Gross D, Yu E (1999) Architectural Design to MeetStakeholder Requirements. In: Donohue P (ed.): Software Ar-chitecture, Kluwer Academic Publishers, pp. 545–564

9. Chung L, Nixon BA, Yu E, Mylopoulos J (2000) Non-Functional Requirements in Software Engineering. Kluwer

10. Dardenne A, Fickas S, van Lamsweerde A (1993) Goal-Directed Concept Acquisition in Requirement Elicitation.In: 6th Int. Workshop on Software Specification and Design(IWSSD 6)

11. Egyed A, Grunbacher P (2002) Automating RequirementsTraceability: Beyond the Record & Replay Paradigm. In:17th Int’l Conf. Automated Software Engineering. IEEE CS,Edinburgh

12. Egyed A, Medvidovic N, Gacek C (2000) A Component-BasedPerspective of Software Mismatch Detection and Resolution.IEE Software Engineering 147(6): 225–236

13. Egyed AF, Boehm BW (1999) Comparing Software Sys-tem Requirements Negotiation Patterns. Systems EngineeringJournal 6(1): 1–14

14. Fielding RT (2000) Architectural Styles and the Design ofNetwork-based Software Architectures. University of Califor-nia, Irvine

15. Franch X, Maiden NAM (2003) Modeling Component De-pendencies to Inform their Selection. In: 2nd InternationalConference on COTS-Based Software Systems, Springer

16. Gacek C (1998) Detecting Architectural Mismatches DuringSystems Composition. In: Center for Software Engineering,University of Southern California, Los Angeles, CA 90089

17. Gieszl LR (1992) Traceability for Integration. In: 2nd Interna-tional Conference on Systems Integration (ICSI 92)

18. Gotel O, Finkelstein A (1995) Contribution structures. In:Second IEEE International Symposium on Requirements En-gineering, York, England

19. Gotel OCZ, Finkelstein ACW (1994) An Analysis of the Re-quirements Traceability Problem. In: 1st International Confer-ence on Requirements Engineering

20. Grunbacher P, Briggs RO (2001) Surfacing Tacit Knowledgein Requirements Negotiation: Experiences using EasyWin-Win. In: 34th Hawaii International Conference on SystemSciences

21. Grunbacher P, Egyed A, Medvidovic N (2001) ReconcilingSoftware Requirements and Architectures: The CBSP Ap-proach. In: 5th IEEE International Symposium on Require-ments Engineering, IEEE CS

22. Hall JG, Jackson M, Laney RC, Nuseibeh B, RapanottiL (2002) Relating Software Requirements and Architecturesusing Problem Frames. In: IEEE International RequirementsEngineering Conference (RE’02), Essen, Germany

23. IEEE-610 (1990) IEEE Standard Glossary of Software Engin-eering Terminology. The Institute of Electrical and ElectronicsEngineers

24. IEEE-1320 (1999) IEEE Standards Software Engineering:IEEE Standard for Functional Modeling Language – Syntaxand Semantics for IDEF0. The Institute of Electrical and Elec-tronics Engineers

25. Kazman R, Barbacci M, Klein M, Carriere SJ, Woods SG(1999) Experience with Performing Architecture Tradeoff An-alysis. In: International Conference on Software Engineering.Los Angeles, CA

26. Kunz W, Rittel H (1970) Issues as elements of information sys-tems. Center for Planning and Development Research, Univ.of California, Berkeley

27. Lamsweerde Av, Darimont R, Letier E (1998) Managing Con-flicts in Goal-Driven Requirements Engineering. IEEE Trans-actions on Software Engineering 24(11): 908–926

28. Liu J, Traynor O, Krieg-Bruckner B (1992) Knowledge-BasedTransformational Programming. In: 4th International Confer-ence on Software Engineering and Knowledge Engineering

29. Medvidovic N, Egyed AF, Grunbacher P (2003) StemmingArchitectural Erosion by Coupling Architectural Discoveryand Recovery. In: STRAW’03: Second International SofTwareRequirements to Architectures Workshop at ICSE 2003 Port-land, Oregon. http://se.uwaterloo.ca/∼straw03/

30. Medvidovic N, Rosenblum DS, Taylor RN (1999) A Languageand Environment for Architecture-Based Software Develop-ment and Evolution. In: International Conference on SoftwareEngineering. Los Angeles, CA

31. Medvidovic N, Taylor RN (2000) A Classification and Com-parison Framework for Software Architecture DescriptionLanguages. IEEE Transactions on Software Engineering 26(1):70–93

32. Mehta N, Medvidovic N (2003) Composing ArchitecturalStyles from Architectural Primitives: Proceedings. In: ESEC/FSE, Helsinki


33. Mehta NR, Medvidovic N, Phadke S (2000) Towards a Tax-onomy of Software Connectors. In: 22nd International Confer-ence on Software Engineering, Limerick, Ireland

34. Mikic-Rakic M, Mehta NR, Medvidovic N (2002) Architec-tural style requirements for self-healing systems. In: Proceed-ings of the Workshop on Self-Healing Systems, Charleston,South Carolina

35. Mullery G (1979) CORE: A Method for Controlled Require-ments Specification. In: 4th International Conference on Soft-ware Engineering, Munich, Germany

36. Nuseibeh B (2001) Weaving Together Requirements and Ar-chitectures. IEEE Computer 34(3): 115–117

37. Nuseibeh B, Easterbrook S (2000) Requirements Engineering:A Roadmap. In: The Future of Software Engineering, SpecialIssue 22nd International Conference on Software Engineering,ACM-IEEE

38. Nuseibeh B, Kramer J, Finkelstein A (1994) A Frameworkfor Expressing the Relationships Between Multiple Views inRequirements Specification. IEEE Transactions on SoftwareEngineering 20(10): 760–773

39. Partsch H, Steinbruggen R (1983) Program TransformationSystems. ACM Computing Surveys 15(3): 199–236

40. Perry DE, Wolf AL (1992) Foundations for the Study of Soft-ware Architectures. Software Engineering Notes

41. Potts C, Burns G (1988) Recording the reasons for designdecisions. In 10th International Conference on Software En-gineering, IEEE Comp. Soc. Press

42. Radice R, Roth N, O’Hara A Jr, Ciarfella W (1985) A Pro-gramming Process Architecture. IBM Systems Journal 24(2):79–90

43. Ramesh B, Jarke M (2001) Toward Reference Models for Re-quirements Traceability. IEEE Transactions on Software En-gineering 27(4): 58–93

44. Robertson S, Robertson J (1999) Mastering the RequirementsProcess, Addison-Wesley

45. Shaw M, Clements P (1997) A Field Guide to Boxology: Pre-liminary Classification of Architectural Styles for SoftwareSystems. In: COMPSAC, 21st Int’l Computer Software andApplications Conference

46. Shaw M, Garlan D (1996) Software Architecture: Perspectiveson an Emerging Discipline, Prentice Hall

47. Siegel S, Castellan NJ (1988) Nonparametric Statistics for theBehavioral Sciences, McGraw-Hill, New York

48. Sommerville I, Sawyer P, Viller S (1998) Viewpoints for re-quirements elicitation: A practical approach. In: Third IEEEInternation Conference on Requirements Engineering (ICRE98), Colorado Springs, IEEE CS Press

49. Tracz W (1995) DSSA (Domain-Specific Software Architec-ture) Pedagogical Example. ACM SIGSOFT Software Engin-eering Notes

Paul Grunbacher is an As-sociate Professor at JohannesKepler University Linz and a re-search associate at the Center forSoftware Engineering (Univer-sity of Southern California, LosAngeles). He studied BusinessInformatics and holds a Ph.D.from the University of Linz.Paul’s research focuses on apply-ing collaborative methods andtools to support and automate

complex software and system engineering activities such asrequirements elicitation and negotiation or software inspec-tions. He is a member of ACM, ACM SIGSOFT, and IEEE.

Nenad Medvidovic is an As-sistant Professor in the Com-puter Science Department at theUniversity of Southern Califor-nia and is a faculty member ofthe USC Center for Software En-gineering (CSE). He received hisPh.D. in 1999 from the Depart-ment of Information and Com-puter Science at the Universityof California, Irvine. Medvidovicis a recipient of the 2000 Na-

tional Science Foundation CAREER award. Medvidovic’sresearch interests are in the area of architecture-based soft-ware development. His work focuses on software architec-ture modeling and analysis; middleware facilities for ar-chitectural implementation; product-line architectures; ar-chitectural styles; and architecture-level support for soft-ware development in highly distributed, mobile, resourceconstrained, and possibly embedded computing environ-ments. He is a member of the ACM, ACM SIGSOFT, andIEEE.

Alexander Egyed received theMS and ME degrees from theUniversity of Southern Califor-nia, Los Angeles, and the Jo-hannes Kepler University, Linz,Austria, respectively, and re-ceived the PhD degree from theUniversity of Southern Califor-nia, Los Angeles, in computerscience in 2000. He is currentlya research scientist at Teknowl-edge Corporation, Marina del

Rey, California. His research interests are in software model-ing, transformation, analysis, and simulation. He is a memberof the IEEE, the IEEE Computer Society, the ACM, and theACM SIGSOFT.

reconcilingsoftwarerequirementsandarchitectures...

Documents