From Non-Functional Requirements to Design through Patterns

Daniel Gross and Eric YuDaniel Gross and Eric YuFaculty of Information Studies, University of Toronto, Toronto, Ontario, Canada

Design patterns aid in documenting and communicatingproven design solutions to recurring problems. They

describe not only how to solve design problems, but also

why a solution is chosen over others and what trade-offs

are made. Non-functional requirements (NFRs) are

pervasive in descriptions of design patterns. They play

a crucial role in understanding the problem being

addressed, the trade-offs discussed, and the design

solution proposed. However, since design patterns aremostly expressed as informal text, the structure of the

design reasoning is not systematically organised. This

paper proposes a systematic treatment of NFRs in

descriptions of patterns and when applying patterns

during design. The approach organises, analyses and

refines non-functional requirements, and provides

guidance and reasoning support when applying patterns

during the design of a software system. Three designpatterns taken from the literature are used to illustrate

this approach.

Keywords: Architectural properties; Design patterns;Non-functional requirements; Process-oriented; Qualityattributes; Quality requirements; Rationale; Require-ments; Satisfying; Softgoal

1. Introduction

Requirements engineering (RE) is now widely recog-nised as a crucial part of software engineering, and hasestablished itself as a distinct research area. Equallyimportant is how requirements drive the rest of softwaredevelopment. In particular, during the design phase,much of the quality aspects of a system are determined.

Systems qualities are often expressed as non-functionalrequirements, also called quality attributes (e.g. [1,2]).These are requirements such as reliability, usability,maintainability, cost and development time, and arecrucial for system success. Yet they are difficult to dealwith since they are hard to quantify, and often interact incompeting or synergistic ways. During design suchquality requirements appear in design trade-offs whendesigners need to decide upon particular structural orbehavioural aspects of the system. A good designer isone who can do this well, and who has learned how toaddress a range of the quality requirements properlyfrom experience.

The NFR framework [3–5] took a significant step inmaking the relationships between quality requirementsand design decisions explicit. The framework uses non-functional requirements to drive design [6] to supportarchitectural design [7,8] and to deal with change [9].

In the software design area, the concept of designpatterns has been receiving considerable attention [10–13]. The basic idea is to offer a body of empirical designinformation [12] that has proven itself and that can beused during new design efforts. In order to aid incommunicating design information, design patternsfocus on descriptions that communicate the reasons fordesign decisions, not just the results. It includesdescriptions of not only ‘what’, but also ‘why’ [13].Given the attractiveness and popularity of the patternsapproach, a natural question for RE is: How canrequirements guide a patterns-based approach to design?

This paper argues that a systematic approach toorganising, analysing and refining non-functional re-quirements can provide much support for the structuring,understanding and applying of design patterns duringdesign. NFRs that are explicitly represented in designpatterns aid in better understanding the rationales ofdesign, and make patterns more amenable to structuringand analysis. We use examples from the design pattern

Requirements Eng (2001) 6:18–36� 2001 Springer-Verlag London Limited Requirements

Engineering

Correspondence and offprint requests to: D. Gross, Faculty ofInformation Studies, University of Toronto, Toronto, Ontario, CanadaM5S 3G6. Email: gross@fis.utoronto.ca

literature to illustrate how NFRs can be represented andused to guide the application of design patterns duringthe design process.

The next section introduces design patterns, and usesthe well-known ‘Observer’ pattern [10] as a typicalexample from the literature to motivate our approach.Section 3 enumerates the objectives and the mainfeatures of our approach. Section 4 illustrates theapproach using the Observer pattern. Section 5 usestwo patterns from a more complex real-life example (thedesign of a distributed alarm system) to furtherdemonstrate the feasibility of the approach. Section 6discusses the approach. Section 7 points to related work.Finally, section 8 concludes and points to future work.

2. What Are Design Patterns?

Christopher Alexander, the renowned (building) archi-tect widely acknowledged to be the originator of thepattern idea, explains that ‘each pattern is a three-partrule, which expresses a relation between a certaincontext, a problem, and a solution . . . as an element inthe world, each pattern is a relationship between acertain context, a certain system of forces which occursrepeatedly in that context, and a certain spatialconfiguration which allows these forces to resolvethemselves’ [14]. Jim Coplien, a noted researcher andpractitioner in the software patterns community, explainsthat a pattern is a ‘piece of literature that describes adesign problem and a general solution for the problem ina particular context’, and elaborates that ‘if we under-stand the forces in a pattern, then we understand theproblem (because we understand the trade-offs) and thesolution (because we know how it balances the forces),and we can intuit much of the rationale. For this reason,forces are the focus of a pattern’ [12].

Patterns are primarily textual based descriptions.Graphical descriptions such as pictures, object diagramsand the like often accompany the text, usually torepresent the desired solution structures that aresuggested by the pattern. Some approaches use informalmeans of representing solution structures [14], whileothers suggest more formal representations to facilitateanalysis and tool support when applying patternsolutions during systems design [15–17].

Patterns are written using predefined templates orforms. Several pattern forms exist in the literature,differing by the kind of categories they emphasise. Forexample, there is the Alexandrian form [18], the GOF(Gang of Four) form [10] and the Coplien form [19].Coplien and Schmidt [20] provide additional examples.All forms contain the basic categories: name, problemstatement, context, description of forces, solution and

related patterns. Sometimes pattern forms do not use allcategories explicitly, but ask them to be discussed duringthe pattern presentation.

Applying a design pattern may be understood astransforming the system from one stage of developmentto the next (Fig. 1). The system requirements togetherwith the design structures established so far duringdevelopment define the context and the set of forces thatcharacterise the problem. The context is the ‘currentdesign state’ of the system under development. Thesolution section of the design pattern then describes whatnew structures to incorporate into the current design statein order to resolve the forces in a favourable manner.After applying a design pattern, new system structuresare established (‘new design state’), which in turnbecome the context for a new design problem and forcesto be resolved, and for which other design patterns maybe provided.

Consider the ‘Observer’ pattern as a typical examplefrom the pattern literature [10]. The Observer pattern isdescribed using the GOF form, which includes, amongothers, an Intent section, a Motivation section, aStructure section and a Related Pattern section. TheIntent of the pattern is to ‘Define a one-to-manydependency between objects so that when one objectchanges state, all its dependants are notified and updatedautomatically’. The Motivation section explains that ‘acommon side-effect of partitioning a system intocollection of cooperating classes is the need to maintainconsistency between related objects. You don’t want toachieve consistency by making the classes tightlycoupled, because that reduces their reusability’. Thesame section provides an example to illustrate thepatterns intent: ‘Many graphical user interface toolkitsseparate the presentational aspect of the user interfacefrom the underlying application data. Classes definingapplication data and presentation can be reusedindependently . . . Both a spreadsheet object and a barchar object can depict information in the sameapplication data object using different presentations’.Finally, the section explains that the ‘key objects in thispattern are subject and observer . . . All observers arenotified whenever the subject undergoes a change instate. In response, each observer will query the subject to

Fig. 1. Transforming solution structures when applying patternsduring design.

From Non-Functional Requirements to Design through Patterns 19

synchronise its state with the subject’s state. This kind ofinteraction is also known as publish–subscribe. Thesubject is the publisher of notifications . . . Any numberof observers can subscribe to receive notifications’ (boldface in the original). The Structure section provides anobject diagram representing the pattern solution thatdeals with the requirements of consistency, loosecoupling, reusability and extensibility. Finally, theRelated Pattern section suggests that the Mediator andthe Singleton pattern may be useful when applying theObserver pattern.

The object diagram in Fig. 2 (from [10]) shows thesolution structures proposed by the pattern. From thisfigure a designer attempting to learn or use the patterncannot tell why these structures are being advocated. Theintentions and rationales are implicit. The problems andforces that these objects and structures aim to addressand resolve are presented discursively in the text. Suchtextual descriptions are, however, not easily amenable toanalysis and tool support.

3. A Requirement-Driven Approach to DesignPatterns

We propose an approach that makes the reasoningstructure behind a design pattern explicit, and amenableto systematic analysis. It focuses on the non-functionalrequirements that the pattern addresses, the trade-offsthat are involved, and how the requirements are metwhen the pattern is applied. The approach aims to:

. Clarify the role of NFRs in design patterns: NFRsdiscussed in design patterns are explicitly represented.This makes them ‘first-class citizens’ which enablesreferring and analysing the role they play in theargumentation structure of the design patterns.

. Provide structure for characterising each pattern:

NFRs relate to each other and to the alternative

solutions discussed in patterns. NFRs are the criteriafor evaluating why to accept or reject a solution.Making such relationships explicit allows characteris-ing pattern solutions in terms of their NFR relatedproperties.

. Systematically support for the application of patterns

during design: NFRs need to be systematicallyaddressed during design. Characterising patternswith respect to NFRs allows for better addressingsystem-wide NFRs when retrieved, selected, and thenapplied patterns to the current design situation.

. Support forward engineering and traceability: NFRsbecome focal points to be addressed by patterns.Designers are guided while addressing NFRs, whensearching, retrieving and selecting patterns. Keepingtrack of how NFRs drive the applying of patternsduring design allows to retain how the systemstructures evolved and thus facilitates NFR-relatedtraceability.

To achieve the above objectives, the approach adopts thefollowing as its main features:

. Represent requirements as design goals: Functionaland non-functional requirements are represented asgoals to be achieved during design. Non-functionalrequirements are denoted by NFR softgoals. NFRsoftgoals are used to express the forces in designpatterns, and the quality requirements to be achievedby the intended software system. We call themsoftgoals because they typically do not have clear-cut criteria of achievement. A qualitative style ofreasoning is used during analysis. Functional goalsrepresent the functions that the system is to achieve.They serve as focal points for analysing alternativesystem functions and structures during the designprocess.

. Show relationships among the goals in a graph: NFRsoftgoals discussed in a pattern are arranged as a goalgraph (NFR goal graph). NFR goals are connected toreflect their respective contribution to each other. Thecontributions are typed according to whether they arepositive or negative and whether ‘partial’ or ‘suffi-cient’.

. Identify implicit or intermediate goals: While con-necting goals through contribution links additionalgoals may be identified. They provide furtherclarification on what the NFRs mean and how theyrelate among each other in the pattern.

. Show how known solutions achieve goals: Solutions ina design pattern describe known design techniquesthat can be adopted during system design. Solutionsare represented as operationalising softgoals. They‘operationalise’ because they turn goals into solutions;they are still treated as goals because there can still be

Fig. 2. Observer pattern solution structure in UML1 (adapted fromGamma et al. [10]).

1UML: Unified Modeling Language [21].

20 D.Gross and E.Yu

different ways of achieving them. For each potentialsolution, the goal graph shows how, and how well, itachieves the stated NFR softgoals.

. Identify unintended correlation effects among goals

and solutions: Correlation links describe non-intended‘side-effects’ solution structure have on various NFRsoftgoals. Through the use of contribution andcorrelation links synergistic and/or competing NFRsoftgoals may be specified.

. Show how alternative solution structure contribute

differently to goals: Alternative solutions in a pattern(represented as operationalising softgoals) contributedifferently to the NFR softgoals in the goal graph.Each proposed solution can be analysed in terms of itsNFR softgoal achievement. Synergistic and/or com-peting NFR softgoals (and thus NFR requirements)can be identified.

. Support argumentative style of modelling: Claims foror against modelling choices are documented throughargumentation softgoals. This is useful to recorddesign assumptions. Such argumentation softgoals aretreated as goals, since they in turn may still need to bejustified or can be refuted. Argumentation softgoalsmay strengthen, weaken or completely refute thecontributions softgoals may have on each other.

. Reason qualitatively to establish the degree of goal

achievement: An interactive labelling procedure isused to judge how well solution structures achieve therequirements. During this procedure softgoals arelabelled in accordance to how well they have beenachieved so far by the proposed solution structures.These labels are then propagated upwards in the goalgraph, while taking into account the different types ofcontribution and correlation links that relate goals inthe goal graph.

. Identifying type and topic in goals: While representinga non-functional requirement as a softgoal, it isanalysed into a type and a topic. The NFR typedenotes the quality desired (such as performance,optimal utilisation), while the NFR topic denotes anexisting or intended structure or behaviour that shouldexhibit that desired quality (software processes,memory, data structures). The identification of topicallows specifying to what part or aspect of theintended system the quality requirements apply.

. Elaborate the system under design: System design isdescribed in terms of the incremental elaboration ofthe functional structure. The elaboration is guided bythe operationalising softgoals described in the goalgraph. Alternative operationalising softgoals relate toalternative functional decompositions during systemdesign. Functional goals are used as focal points forspecifying such alternatives as functional decomposi-tions.

4. Illustrating a Requirement-Driven Approachto Design Patterns

This section illustrates how our approach is used torepresent, analyse and then apply the Observer designpattern during design.

Consider a typical design setting in which the problemdiscussed by the Observer pattern arises: A softwaredesigner may have in her current design several objectssuch as a spreadsheet, a bar chart and a pie chart object.All objects manipulate and display their data that need tobe kept consistent among each other. Figure 3 describessuch a design situation.

Let us now demonstrate how an NFR goal graph isbuilt when analysing the pattern text, and refer to the firstparagraph in the Motivation section of the pattern (italicsadded to emphasise relevant NFRs):

A common side-effect of partitioning a system into acollection of cooperating classes is the need to maintainconsistency between related objects. You don’t want to achieveconsistency by making the classes tightly coupled, because thatreduces their reusability.

From the above paragraph we define the NFR softgoalconsistency[object_data]. The type of the NFR soft-goal is the required property, consistency. The topic ofthe NFR softgoal is object_data. Together they expressthe requirement (i.e., design goal) of achieving con-sistency among object data. Further requirements arethat objects should be reusable – reusability[objects] –and loosely coupling – loose_coupling[objects]. Thislatter design goal is inferred from the wish to avoid tightcoupling among objects. The paragraph argues that tightcoupling would reduce reusability. From this we inferthat loose_coupling[objects] contributes positively toreusability[objects]. We show this by creating acontribution link of type ‘Help’ from loose_coupling[objects] to reusability[objects], which denotes apositive contribution but not sufficient by itself toachieve reusability[objects]. Other mechanisms suchas standardised interfaces are needed to sufficientlyachieve the reusability goal of objects. This can beshown by defining the standardised_interface [ob-jects] NFR softgoal, and creating from it a contributionlink of type ‘Help’ to reusable[objects]. This additionalNFR softgoal is not explicitly mentioned in the pattern

Fig. 3. Current design state: how to make those objects worktogether?

From Non-Functional Requirements to Design through Patterns 21

text. It is the justification, however, for the abstractclasses Subject and Observer in the Observers patternsolution in Fig. 2, which provide a standardised interfacefor the publish–subscribe mechanism among Observerand Subject objects.

In order to clarify the relationship among the solutioncomponents of the observer pattern and the NFRsoftgoals identified so far, let us refer to a subsequentparagraph in the pattern text. After introducing Subjectand Observer objects and describing how they collabo-rate, the pattern text further explains that (bold text in theoriginal, italics by us):

This kind of interaction is also known as publish–subscribe.The subject is the publisher of notifications. It sends out thesenotifications without having to know who its observers are. Anynumber of observers can subscribe to receive notifications.

First we define the operationalising softgoal observer_pattern[objects] to denote the solution structure appliedto objects in the domain. We then define theoperationalising softgoals publish_subscribe[objects]and abstract_classes[objects] to denote the publish–subscribe and the abstract classes solution componentsrespectively, and make them subgoals of observer_pattern[objects]. This is shown by two definedcontribution links of type ‘and’ to the observer_pattern[objects]. Having the two components of the observerpattern solution made explicit, we can describe theirrespective contribution to the NFR softgoals identified sofar. The publish_subscribe design technique sufficientlyachieves reducing the coupling among objects and

maintaining consistency among object data. This isshown by creating contribution links of type ‘Make’from publish_subscribe[objects] to the reduced_coupling[objects] and consistency[object data].Similarly, a contribution link from abstract_classes[objects] to standardised_interface[objects] of type‘Make’ shows that introducing abstract classes suffi-ciently achieves a standardised interface for objects.

The italicised phrase ‘Any number of observers’ in the

pattern text suggests that the ability to add further

observers to the design, without the need to change the

subject object, is another NFR that the pattern addresses.

We define the extensibility[system_functions] NFR

softgoal to denote this requirement. We further observe

that reduced coupling of objects helps achieving

extensibility of system functions. We define this

synergistic ‘side-effect’ by adding a correlation link of

type ‘Help’ from reduced_coupling[objects] to ex-tensibility[system_functions] This link type appears as

a dotted line in Fig. 4.

Figure 4 shows the NFR goal graph we have defined.

NFR softgoals are denoted by the light solid-line clouds.

Operationalising softgoals are denoted as clouds with

thick solid borders. The links between them are the

contribution and correlation links discussed. The

contribution types defined in the notation are ‘Make’,which means sufficiently achieves the parent goal;

‘Some+’, there is some positive contribution of

unknown extend towards the parent goal. The ‘and’refinement into two sub-softgoals means both sub-

Fig. 4. Representing the properties of the Observer pattern solution structure as an NFR goal graph.

22 D.Gross and E.Yu

softgoals are needed to be achieved in order to achievethe parent goal. ‘Break’, ‘Hurt’ or ‘Some-’ denotenegative contributions. These contribution types are usedto help propagate the achievement status of the goalsthrough the network interrelationships using an inter-active qualitative reasoning process as described inChung et al. [4]. Please refer to the Appendix for a fulllegend of the notation.

Let us now turn to the trade-offs discussed in theobserver pattern. First we define the alternative solutionrejected by the pattern, to have objects collaboratedirectly. This is denoted by the direct_collaboration[objects] operationalising softgoal. From the patterntext we know that objects collaborating directly aretightly coupled. This is shown through a contributionlink of type ‘Hurt’ from direct_collaboration[objects]to reduced_coupling[objects].

We can now analyse whether other NFR softgoals areimpacted negatively through a tightly coupled solutionstructure. Note that by following the contribution link oftype ‘Hurt’ from direct_collaboration[objects] toreduced_coupling[objects], and the correlation linkof type ‘Help’ from reduced_coupling[objects] toextensibility[system_functions], we can deduce that,since direct collaboration among objects does not reducecoupling, it inhibits, to a certain extent, the extensibilityof system functions.

Let us look for trade-offs not discussed in the patterntext. We can, for example, ask what positive properties a

design has in which objects are directly collaborating.

Two properties come to mind: having direct collabora-

tion helps the performance of the system since less

method invocations are performed – performance[system_processes] – and making software code less

abstract makes it easier to understand – understand-ability[system]. The publish–subscribe mechanism,

however, is hurting performance and makes the software

code difficult to understand.

We can add such explanations to justify the choice of

link types in the goal graph. This is done through

argumentation softgoals that argue for or against the link

type. Figure 5 illustrates the argumentation softgoal

‘abstract code is difficult to understand’ which supports

the contribution link of type ‘Hurt’ from publish_subscribe[objects] to understandability[system].This support is expressed through a contribution link

of type ‘Make’ from the argumentation softgoal to the

contribution link.

Understandability of the software code has in turn a

positive impact on the maintainability of the system –

maintainability [system], which is another relevant

NFR softgoal we can now identify. Since performance

and understandability are not primary concerns of the

pattern but rather ‘side-effects’, they are defined as

correlation links. These appear as dotted line links in the

NFR goal graph. Figure 5 summarises the trade-offs

discussed.

Fig. 5. Representing the reasoning structure of the Observer pattern as an NFR goal.

From Non-Functional Requirements to Design through Patterns 23

We now apply the Observer pattern during design.This is done by relating the operationalising softgoals inthe NFR goal graph to a functional elaboration structurefor the system under development. Figure 6 shows on theleft-hand side a ‘collapsed’ version of NFR goal graphfor the observer pattern. Only the alternative operatio-nalising softgoals and several pertinent NFR softgoalsare shown. On the right-hand side we see a fragment of afunctional elaboration of the software system underdevelopment. The manage_views function is furtherelaborated into the functional goal view_objects_updated. A functional goal is used to express thepossibility of alternative choices for elaborating func-tional structure, while a task represents a particular wayof achieving a goal. The alternative tasks are linked tothe goal through ‘means–ends’ links, denoting thedifferent means that can be used to achieve the goal.The means–ends reduction in the functional elaborationare the concrete manifestations of the correspondingoperationalising softgoals in the NFR goal graph. Themeans–ends links are related to the operationalisinggoals through ‘design justification links’. Designjustification links with a ‘Make’ contribution denotethat the alternative task ‘implements’ sufficiently thetechnique represented by the operationalising goal, whilejustification link with an ‘and’ contribution (not shownin Fig. 6) denotes that the alternative task partlyimplements the technique represented by the operatio-nalising goal. In order to fully implement thatoperationalising softgoal, another ‘and’ contributionfrom a task would be needed.

The functional goal view_object_updated is a focalpoint for two alternative functional elaborations, whichcorresponds to the two alternative solution structuresdiscussed in the design pattern. Updating the view of anobject can occur by having objects directly collaboratethrough messaging, or by using the Observer pattern.Each alternative is linked to the corresponding oper-ationalising softgoal through the ‘design justification’

link. Operationalising softgoals are in turn connected tothe NFR softgoals relating alternative functional aspectsof the system to operationalizing softgoals. This allowsshowing the trade-offs, rationales and justifications thatwent into their design.

Finally, the functional elaboration structure in Fig. 6refers to the object-oriented diagram shown in Fig. 7.The functional elaboration structure serves as a focalpoint for alternative functional elaboration, and justifica-tion of design in terms of Patterns and NFRs theyaddress. The object diagram represents one particularfunctional and structural design that corresponds tochoosing one particular alternative branch in thefunctional elaboration structure. In this way many‘justified’ alternative object diagrams can be generatedfrom a functional elaboration structure.

5. Example: The ‘TeleLarm AB’ Alarm System

5.1. Introduction

The previous section introduced our approach forrepresenting design patterns and using them duringdesign. In this section will take a more complex exampleto illustrate how to express the NFR-related reasoningthat a designer needs to do when applying severalpatterns during design.

The example patterns are taken from a real-life projectfor designing real-time alarm systems as reported byMolin and Ohlsson [22]. The patterns reported address avariety of requirements and design issues relevant to thatdomain. These include, among others, requirements suchas performance optimisation and optimal utilisation oflimited memory, reliability (such as fault tolerance),maintainability and portability.

We chose this example because it reports a real-lifeeffort in using patterns to document the requirements andarchitectural design features of a commercial line ofproducts. Although the patterns are domain specific,their textual representation is a typical example of howpatterns are documented in the pattern literature.Fig. 6. Applying the Observer pattern during design.

Fig. 7. Solution structure after applying the Observer pattern.

24 D.Gross and E.Yu

This section will present the Deviation and the Pointpattern, which are the first two (out of the six) designpatterns discussed in Molin and Ohlsson [22]. Since wewish to demonstrate how patterns are successivelyapplied during design, we will keep the presentation ofthe Deviation and point patterns short and elaboratemore on applying the Point pattern.

This section first introduces the design context thatgives rise to the problems the Deviation and the Pointpatterns come to address. It then gives a brief overviewof the Deviation pattern, its structure, how it is appliedduring design, and the resulting design context. Then thePoint pattern is illustrated, presenting its structure, how itis applied during design, and the resulting designcontext. Finally, we will illustrate what additionalNFR-related analyses are needed when applying thePoint pattern after the Deviation pattern during design.

Figure 8 shows how a fire alarm system can bedescribed by its physical entities and their connections.The control nodes are autonomous processors. Eachcontrol node has a set of input sensors and/or outputdevices connected. Sensors and output devices areconnected to control nodes through communicationlines. Control nodes are also interconnected betweenthemselves through communication lines.

Figure 9 shows an object diagram that describes thedesign of a control node in the above system. Thediagram shows that an Alarm_Handler is responsible forsurveying the environment. The Device_Poller objectretrieves input status of all input devices connected tothe control node, and stores all inputs as System_Status objects. An Alarm_List object keeps track of allthe alarms that the locally attached output devices areresponsible for. This is done by managing a mappingbetween the locally attached output devices and the

subset of System_Status objects that are needed tocheck for the occurrence of an alarm. The Alarm_Listobject is also responsible for checking, on behalf of theAlarm_Handler object, the system status with respect toeach defined alarm. Finally, the Alarm_List object writesto Output_Device objects in order to write to the locallyattached output devices to either report the currentsystem state or activate actuators in the environment toperform emergency actions. Note that the Device_Poller object and then Alarm_Handler objects areworking concurrently within the control node.

There are two principal problems with the abovedesign that arise when considering that we deal with adistributed processor environment, and that input andoutput devices exhibit great variability in the type ofsensors, their detection algorithms, access protocols andphysical packaging. The following section will discusshow the Deviation pattern addresses the first problem ofdistribution. Section 6 will discuss how the Point patternaddresses the second problem of device variability.

5.2. Understanding, Analysing and Applying theDeviation Pattern

Dealing with a distributed environment means that anoutput device may be dependent on a set of inputdevices, no matter where the input devices are physicallylocated in the distributed system. An input device mightbe connected to the same control unit as the outputdevice, or it may be connected to another, remote,control unit. The ‘mapping’ between outputs devices andsystem status items defined in the Alarm_List object (forall output devices locally available) may need to refer toSystem_Status objects that are locally available and toSystem_Status objects that reside on other control

Fig. 8. Overview of a fire alarm system (adapted from Molin andOhlssson [22]).

Fig. 9. Solution structure of one control node in the alarm system.

From Non-Functional Requirements to Design through Patterns 25

nodes, and that need to be fetched from there. A key

question is how to make remote system status locally

available such that the performance of the system is not

compromised during an alarm situation, when the

Alarm_List object needs to traverse all subsets of

System_Status objects, while at the same time also

keeping on eye on other required system qualities such

as memory utilisation and the complexity of design.

This question is addressed by the Deviation pattern.

Figure 10 is an NFR goal graph that represents the

argumentation structure of the Deviation pattern. The

NFR goal graph was constructed in a ‘middle out’

manner, similar to how we have demonstrated it with the

Observer pattern. Some NFR softgoals and contribution

links were explicitly mentioned as forces and relation-

ships among forces in the pattern text, while others NFR

softgoals and contribution links were identified while

further analysing the pattern text and clarifying its (often

implicit) argumentation structure.

The top part of Fig. 10 shows that the pattern author

has put up-front two major requirements during the

design – memory utilisation minimised in the system –

and achieving good performance of the system. In

pattern terminology these two top-level goals in the

graph indicate that the basic question the designer faces

is how to resolve the forces of minimising memory

utilisation, while at the same time achieving good system

performance.

At the bottom of Fig. 10 we can see the three

alternative solution strategies that are discussed in the

pattern: (a) to store in each control node references to

system status information that is stored in a remote

control node (i.e., introduce a proxy System_Statusobject); (b) to duplicate all system status information to

all control nodes in the system (i.e., introduce a

replication mechanism for System_Status objects);

(c) to duplicate only status information that is deviant

from its normal value to all control nodes in the system

(introduce a replication mechanism but for deviant status

information objects only). The components of the third

solution are further elaborated, to clarify its contribu-

tions to pertinent NFRs in the goal graph. All three

alternative solutions are denoted by the operationalising

softgoals at the bottom of Fig. 10.

The NFR softgoals between the top part and the

bottom part of Fig. 10 represent the argumentation

Fig. 10. The reasoning structure of the Deviation pattern.

26 D.Gross and E.Yu

structure of the pattern. In principle the pattern arguesthat adopting the first solution, to reference remotesystem status data, would reduce data duplication andthus memory utilisation needs in the system. However,performance of the system during alarm situations wouldnot be optimal. Also, in this particular design context(i.e., in an embedded system), storing references for allremote input status data is too expensive in terms ofmemory utilisation. This solution is rejected. The secondsolution duplicates all input status data to all controlnodes, which would provide optimal performance duringalarm situations. However, memory utilisation would notbe minimised. This solution is also rejected. The thirdsolution is then adopted as the pattern solution,duplicating only deviant objects. The pattern furtherargues in support for this solution in this particulardesign context, since the ratio of sensors versus thenumber of sensors participating in an alarm is rather low.Therefore there is not a lot of deviant input statusinformation that needs to be duplicated, which mitigatesthe memory utilisation concern. Having all deviant inputstatus data duplicated in all control nodes makes themlocally accessible to all the local processes that accessthem during an alarm, which optimises their perfor-mance.

Let us now turn to applying the pattern duringdesign. Figure 11 shows the kind of requirements theintended alarm system should meet. It includes thenon-functional requirements mentioned previously (bythe clouds denoting softgoals on the left-hand side),together with a first elaboration of the functions thesystem should be capable of performing. Tasks on theright-hand side refer to objects and methods defined inthe object diagram. These include the ability to surveythe physical environment by detecting out-of-the-ordinary occurrences, responding to those occurrences,monitoring and reporting facilities of the system status.Each one of these sub-functions is refined into moreparticular functions. During design the designers now

asks: How can the system be further designed so that

the non-functional requirements mentioned will be

met, and how does that design relate to further

refinements of the functional and structural aspects of

the system?

Figure 12 shows how the deviation pattern is applied

and what impact it has on the functional structure of the

system. To avoid cluttering the diagram, Fig. 12 hides

some of the argumentation goals shown in Fig. 10. On the

left-hand side we can see the three solutions discussed

in the pattern text, denoted by the reference_&_distribute_on_demand[input_status_data], apply_deviation_pattern[input_status_data] and replicate_on_ all_nodes[input_status_data] operationalising

softgoals. On the right-hand side we can see how each

one of the solution strategies generates alternative

refinements to the input_status_data stored, input_status_data_ disseminated and input_status_ data_accessed functional goal. We have replaced the func-

tional tasks store_input_status_data, disseminate_input_status data and access_input_status_data in

Fig. 11 with corresponding functional goals. Through

refining and analysing how to achieve the non-functional

part of the system, the designer arrived at the insight that

storing, disseminating and accessing input status data

may be done in more than one way.

Figure 13 shows the solution structure after applying

the deviation pattern. It shows that instead of storing

every input status as System_Status objects, we only

store Deviation objects, which represent input status

information that exceeds certain threshold limits. A

Replication_Handler object was also added to replicate

a copy of Deviation objects to all control units. The

Alarm_List object is now aware that it refers to

Deviation objects rather than to all System_Statusobjects. It can, however, deduce system states that do not

point to a Deviation object, are not exceeding a

threshold and are thus in a normal state.

Fig. 11. Functional and non-functional aspects of the alarm system.

From Non-Functional Requirements to Design through Patterns 27

Fig. 12. Applying the Deviation pattern during design.

Fig. 13. System solution structure after applying the Deviation pattern.

28 D.Gross and E.Yu

5.3. Understanding, Analysing and Applying thePoint Pattern

This section illustrates two further advantages whenmaking NFR explicitly for describing and for applyingpatterns during design. First, it illustrates how to expresspatterns that make use of other patterns in order toaddress particular sub-problems in their proposedsolution structure. Second, it illustrates the NFR-relatedreasoning a designer needs to make when applyingseveral patterns during design.

The point pattern addresses the problem of variabilityof I/O devices in the type of sensors, their detectionalgorithms, access protocols, physical packaging, and themeans by which sensors, actuators and other outputdevices are connected to the system. However, despitethe variations in the make-up of those devices, theirlogical behaviour (such as requesting their status oractivating actuators) are similar over all devices, sensors,actuators and output devices. The point pattern problemstatement therefore is: ‘How can the logical behaviour ofthe system be separated from the variation among inputsensors and output actuators?’ In other words, how can astandardised interface be established which separates thelogical behaviour from the device variations?

The Point pattern discusses two alternative strategiesfor achieving a standardised service interface. One

approach is to create a standardised interface to alldevices that are attached to the systems control units.The interface would be defined as an abstract base class,

corresponding to an abstract device, and variations of thedevice implementation would be defined in correspond-ing subclasses. This would be the most natural approachto establish the logical device behaviour within the base

class and then have each subclass implement its ownway of relating to its device. It is, however, inadequatesince in this particular problem context the number ofinput sensors or actuators that may be connected to onesuch device varies as well. This would introduce another

element of variability that cannot be accommodated in astable manner within the abstract base class representinga device.

The other approach that the Point pattern proposes,and adopts, is to establish a standard ‘logical’ serviceinterface for logical input and output relevant to theproblem domain, such as for input sensors or logicaloutput units. To this end the Point pattern suggests

defining an abstract base class called point. A device isthen covered by a set of points.

The Point pattern uses another pattern, the Bridge

pattern [10] in order to decouple the Point abstractionfrom the Point implementation code. The bridge patternintroduces another layer of indirection (polymorphicinvocation) between the clients interfacing and the

Fig. 14. The reasoning structure of the Point pattern.

From Non-Functional Requirements to Design through Patterns 29

implementation code. This has some negative effect on

the performance of the system when accessing I/O

devices (such as accessing the sensor state information);

this is not mentioned in the pattern text description but

can be identified with our ‘middle out’ approach of

analysis and described in the NFR goal graph.

Figure 14 summarises the forces and solution

discussed in the Point pattern. The figure shows that

the Point pattern is in fact addressing two distinct issues.

It addresses the additional variability of devices by

suggesting a logical rather than device-oriented abstract

service interface. This is addressed by the abstract_logical_base_classes[service_interfaces] operation-

alising softgoal. The pattern also addresses the issue of

separating implementation code from interface code

through the Bridge pattern. This is a related but different

concern, and is shown by the apply_bridge_pattern[service_implementation] operationalising softgoal.

The Bridge pattern addresses extensibility issues,

allowing for new types of device to be added without

affecting the point ‘client’ code.

Figure 15 illustrates how the Point pattern is applied

during design. As described in the Point pattern text, the

diagram shows that accessing input sensors (and output

actuators) can be done in two different ways. One is

through the base class abstracting the notion of device.

This is denoted by the access_sensors_through_device_abstraction task. The other alternative is

through the base class abstracting the notion of a logical

device. This is denoted by the access_sensors_through_point_abstraction task. Both alternative

tasks are linked through ‘means–ends’ link to the

sensors_accessed functional goal. Note again the

switch from accessing_sensors (and accessing_actuator) task to the sensors_accessed (and the

actuator_accessed) goal symbol to indicate functional

alternatives, as described in the Point pattern. The

means–ends links connecting the alternative tasks to

their respective goals are then related to the correspond-

ing operationalising goals through design justification

links.

Figure 15 illustrates how applying the Point pattern

may have impact on non-functional requirements

(‘forces’) already addressed by having applied previous

patterns (‘the deviation pattern’). Even though having

made design choices for optimising performance (by

duplicating deviations), there is no guarantee that

performance would not be adversely affected during

subsequent design. The use the Point pattern makes of

the Bridge pattern may still adversely affect the overall

system performance. Thus, when applying subsequent

patterns, the designer needs to analyse whether and in

what way already met non-functional requirements may

still be negatively impacted.

Figure 16 illustrates the solution structure after

applying the Point pattern. The Point object is used to

Fig. 15. Applying the Point pattern during design.

30 D.Gross and E.Yu

access both input and output devices, and is the interfacethrough which the Device_Poller object and theAlarm_List object access I/O devices respectively,while the PointImp object implements the differentprotocols to access I/O devices. There is a zero-to-manyrelationship between the devices and the PointImpobject, which means that one input device may haveseveral points defined, if that input device offers severalsensor services to the control node.

6. Discussion

The approach presented in this paper offers a systematicway of relating non-functional requirements, throughdesign patterns to the design of software system. Itsupports organising, analysing and clarifying NFRs inpatterns, and structuring, understanding and applying ofdesign patterns during design. NFRs that are explicitlyrepresented in design patterns and during design aid inbetter understanding the rationales of design, and makethe patterns approach more amenable to analysis, designguidance and tools support. Treating functional and non-functional requirements as goals allows exploring andretaining a design history of alternative design choices,their rationales and reasons why they were accepted orrejected during design.

The approach advocates a ‘semi-formal’ style ofmodelling. It formalises how (and how sufficiently)softgoals contribute to each other, provides somestructuring of softgoals in terms of type and topic, and

allows analysing those contribution structures withqualitative reasoning methods. Although natural lan-

guage together with informal graphical representationsare powerful and intuitive in communicating designpattern intents and solution structure, providing some

structuring can be very useful. Our semi-formalapproach provides abilities to better understand and

analyse the complex trade-offs that need to be madeduring design. It also provides abilities to better deal

with changes in requirements and design assumptionduring the software development life cycle and system

evolution. The design history allows reasoning about theimpact of making one NFR (say, reusability) more

important than another one (say, time to market). Designdecisions that optimised for time to market can be found,

and alternatives favouring reusability that were pre-viously rejected may be reconsidered. Other changessuch as design assumptions can be tracked. For example,

the assumption of using one operating system (anoperationalising goal) over another would yield better

market penetration (an NFR), may change or be provedwrong and thus invalidate previously assumed contribu-

tion structures. Re-evaluating the contribution structureswould provide the basis for considering other, previously

rejected design alternatives.

Such benefits of making NFRs explicit were con-firmed in three case studies we performed. The case

studies analysed architectural documents of a newproduct provision software infrastructure, a new line of

attendant console products, and the addition of a newservice provision infrastructure into an existing tele-communication switching system.

Fig. 16. System solution structure after applying the Point pattern.

From Non-Functional Requirements to Design through Patterns 31

Although not directly performed for patterns, the casestudies pointed us to the need to consider coarser-grainedconstructs, such as patterns, when representing anddealing with non-functional requirements during design.In particular, we observed that designers often think interms of solutions that address a variety of NFRs at once,rather than in terms of fine-grained (NFR) goalrefinements. Furthermore, in projects where patternswere used during design it ‘showed up’ in the NFR goalgraphs and the functional elaboration structures weproduced. This motivated the approach presented in thispaper, to incorporate design patterns into NFR modellingand reasoning.

The case studies showed that our approach for dealingwith NFRs is applicable to complex real-life projects.Although being a simple modelling tool, and lightweightin terms of formalisation, NFR goal graphs wereconsidered very valuable by practitioners in makingthe argumentation structure of ongoing discussionsexplicit. The strength is in its simplicity, in that itallows documenting the essential NFRs when facing thetremendous complexity of telecommunication systems.Participants felt that goal graphs presented the rationalesfor specific choices and the arguments for them in ahighly compressed and readable form. Trade-offs couldbetter be discussed, analysed and clarified than whenbeing presented in a linear text.

The need to manage change along the lines of non-functional requirements was further emphasised in thesecond case study. The design team learned that it wasgiven more time than initially anticipated to completethe project. The designers were then asked to find designdecision that traded-off the time to market NFR withother NFRs of the system. Without a design history asdescribed above such information is not systematicallyavailable.

Following are further discussion points we wish toaddress:

. Global versus local design constraints: One of themajor challenges when dealing with NFRs is that theyare constraints that need to be dealt with globally,while introducing ‘coordinated’ design techniqueslocally. We deal with NFR that are global constraintsover the system, by carefully refining and connectingthem in terms of type and topic to more local NFRs,until the designer arrives at local design techniques(operationalising softgoals) that she can apply. Havingan NFR goal graph structure allows justifying howthose local techniques in fact contribute to the globalconstraints introduced by ‘global’ non-functionalrequirements.

. Generic versus domain-specific know-how: Molin andOhlsson [22] discuss their concern of what the best

level of generality ought to be for documenting theirpatterns. They explain that their patterns are specificto fire alarm systems; however, most of their patternsreported are not that specific, and could be rewrittenfor a wide range of systems, to make them moreaccessible to a wider audience. However, they pointout that stating the patterns in general terms makesthem more difficult to understand at the level wherethe reader can actually apply them. The ability toprovide for ‘topic’ structures allows describingpatterns in more generic terms. This more genericdescription can be used when searching for patternsand applying the pattern during design. We have not‘generalised’ the patterns to make them more widelyapplicable, in order to stay close to the patterndescription given in Molin and Ohlsson’s paper.

7. Related Work

The approach proposed in this paper is based on the NFRframework [3–5]. The NFR framework introduces theconcept of softgoal for specifically dealing with non-functional requirements during requirements analysisand design. Softgoals are treated as design goals that areill defined and tentative, and for which no formalisablecriteria of achievement exists. It further introduces thecontribution types among softgoals to provide a ‘softer’notion for specifying and reason about goal achieve-ment. We adopted these concepts from the NFRframework and applied them to design patterns. Designpatterns become NFR goal graph fragments thatrepresent reusable knowledge, and that can be analysedand applied during design. This extends the NFRframework with the ability to deal with coarser-grainedproblem and solution structures. It further provides aricher representation for the relationships between non-functional requirements, functional requirements andfunctional solution structures that get refined duringdesign. The notation for representing the functionalelaborations is adopted from Yu [23]. In his work Yuuses this notation in order to model the design of (social)actor behaviour in a distributed environment. Futurework will adopt this distributed view for functionalelaboration and allow clustering functional elaborationsand alternative reasoning along the lines of stakeholders’accountability and expertise.

Although there has been some interaction between thepattern and the requirement engineering communities,not much work has been done in using patterns toconnect requirement to design in general and the linkingof NFRs to software patterns in particular. One

32 D.Gross and E.Yu

interesting work that does pick up the idea of usingpatterns for addressing non-functional requirements inarchitectural design is that of Bosch and Molin [24]. Inthat paper the authors propose a software architecturedesign method that is based on iterative evaluation andtransformation cycles. First a rough high-level archi-tecture is designed. It is then evaluated on how well itmeets the non-functional requirements of the system.Evaluation is done through a variety of techniques.Having identified problems in meeting non-functionalrequirements, transformation techniques, which arebased on applying patterns, are used to optimise weakareas in the architecture to better fulfil the non-functionalrequirements, while making trade-offs among others.Although the Bosch and Molin work gives a very usefuloverall methodology of how to approach the design ofsoftware architectures, the method does not deal in detailwith representing and analysing the structural propertiesof patterns or the refining and analysing of the evolvingarchitecture, or how they achieve or conflict with NFRs.Our approach can therefore be used to complement theirgeneral methodology and give more particular notationalsupport and guidance for such analysis and reasoning.

Design rationale is another related area. Lee [25]presents a goal-oriented approach to facilitating deci-sion-making processes, which in turn extends an earliermodel for representing design rationale [26]. The NFRframework builds on this earlier work with a focus ondealing with NFRs. Our work adopts the distinctionsbetween NFR and FR goals, but incorporates FR goals toestablish alternative functional elaborations, and forrelating operationalising softgoals to them during design,as initially outlined in Mylopoulos et al. [27]. Our worktherefore falls within the area of goal-oriented require-ment engineering [28,29], where goals are used toidentify, analyse and refine requirements and serve asselection criteria for solution specifications.

Our approach also relates to the area of requirementstraceability support [30] for the development life cycle.Our work can be seen as specialising such traceabilityparticularly to deal with non-functional requirements,design patterns and alterative functional elaborations ofthe system.

8. Conclusions and Future Work

This paper proposed an approach for better dealing withNFRs that are presented in design patterns, and whenapplying patterns during design. The approach in itscurrent form proved useful to practitioners in the fieldfor better understanding, discussing, analysing and

documenting NFRs and related design decisions duringdesign. This section discusses several areas where ourapproach can be further extended to provide additionalcapabilities.

. Representing Solution Structures: In this paper wehave represented solution structures with the UMLnotation [21]. The solution structure is the outcome ofan argumentation and decision process. The process ismade explicit by the NFR goal graphs and functionalelaboration structure. A notation such as UML doesnot allow one to express structures (i.e., components,interfaces and connectors) that are still underdevelopment, and where requirements have onlybeen partly accomplished. We are currently workingon a representation of solution structures that have aricher semantics for representing a structural view ofthe system that is only partially developed, and wherefunctional (and non-functional) goals have not yetbeen fully developed into solution structures.

. Scalability and Tools Support: Although NFR goalgraphs capture a lot of essence, they may becomequite large. Current research is underway to betterdeal with large NFR goal graphs. This is done byclustering them along the lines of stakeholders whoare responsible for their achievement. These enhance-ments are done within the larger research goal toestablish an actor-oriented approach for requirementsand design. Our research group is also working ontools support. The tool can be requested from the Website given at ref. [31].

. Applicability of Patterns During Design: Our ap-proach recognises the need for ‘applicability condi-tions’ to make the application of design knowledge(such as those captured in design patterns) moreselective, and context dependent, when applied duringsystem design. For example, let us suppose that thedesigner of the Point pattern wishes to emphasis thatthe pattern should only be applied to service interfacesof devices that have no hard real-time requirementsand their sensing of the environment is not critical tothe system’s survival. However, for certain alarmconditions direct access to input devices is needed tofully optimise performance. The ‘pattern designer’would attach this applicability condition to thepatterns operationalising softgoal, suggesting that thedesigner who is applying the Point pattern duringdesign should not trade-off performance and surviva-bility with maintainability and extensibility of thesystem. Further work needs to be done to explore howapplicability conditions are best specified and utilisedwhen applying patterns.

. Patterns with Alternative Implementations: Somepatterns in the literature provide alternative imple-

From Non-Functional Requirements to Design through Patterns 33

mentations, where each implementation may havesome impact on further NFRs. We address such issuesby partitioning the design process (i.e., the NFR goalgraphs and the functional elaboration structure) intolayers of design decisions. In this sense implementa-tion decisions may be seen as addressed in a later‘decision’ layer after having adopted the patternduring the design process in a previous layer. In thispaper we have not illustrated this feature. Furtherresearch is underway to utilise the functional goalconstruct in conjunction with actor-related constructsfor representing ‘delegated’ decisions in patterns andduring design. Alternative implementations may thenbe seen as providing alternative choices later in thedevelopment process, while the decision itself isdeferred.

. Domain-Dependent Specialisations: Our approach isdomain independent. The emphasis is on propertiesand structures of design elements and relationshipsbetween non-functional requirements and designelements for better representing and evaluatingdesign alternatives rather than explicitly expressingthe design elements themselves. However, similar todomain-dependent architectural descriptions that takeadvantage of domain-specific structuring principles(such as real-time structures), our approach could beextended to include such domain-specific constructs tobetter represent relationship structures and betterallow for evaluating alternative designs in termspertinent to a particular domain, which are oftenoptimised for dealing with particular NFRs.

. Higher-Order Causal Relationships and NFRs in

Patterns: An interesting observation pointed out byone of our reviewers was the relationship betweenforces in design patterns and higher-order relation-ships discussed in Gentner [32]. Higher-order relation-ships are a (cognitive) means to select amongrelationships that exist among objects in a domain.Design patterns reason about such relationshipsamong design objects in terms of their NFR proper-ties. By making NFRs explicit, we provide support fordenoting the elements involved in higher-orderrelationships. Future work can focus on how to utilisethe theoretical framework provided in Gentner [32] toenhance the analysis, reasoning and support forapplying design patterns.

. Improved Representation of Pattern Languages: Inthe design pattern literature, several related patternsare often organised into a ‘pattern language’. Coplienexplains that ‘a pattern in isolation solves an isolateddesign problem; pattern languages build a system. It isthrough pattern languages that patterns achieve theirfullest power’[12]. If each pattern has clearerstructure, then the relationships among patterns

would also become more perspicuous. For example,patterns may be related via their positive or negativeforces, via the problem structure, etc. Current patternlanguages are typically represented as directed acyclicgraphs with a single type of link with no clearsemantics. Such graphs can be enriched by other kindsof semantic relations, showing how a number ofpatterns together can lead to the design of wholesystems.

. Better Retrieval of Patterns and Knowledge-Based

Support: With more explicit structure, patterns can beretrieved more easily from a richer catalogue. Therecan be more dimensions for indexing, accessing andnavigating the catalogues. Future work will focus onhow to index, access and navigate such catalogues andhow such catalogues could server as a basis for aknowledge base [33], for storing and guiding retrievalof design know-how that addresses NFRs and relatedtrade-offs during design.

. NFR Goal Graphs Facilitating the Reuse of Design

Patterns: Following from the above, the reuse ofdesign patterns could be facilitated when having amore explicit structure of the patterns’ design goals.Currently, patterns need to be searched in full textwith unstructured search strings. Having an explicitstructure for the NFRs a pattern comes to addresswould aid in searching for patterns according to thetrade-offs they make. Future work could investigatehow reuse would be facilitated. This may also includeinvestigating how the pattern problem context couldbe better characterised within which the NFRs play arole.

. NFR Goal Graphs as a Basis for Hyperlinked Textual

Representations: NFR goal graphs are not intended tobe used in place of a textual representation of patterns.The benefits of our approach is in the ability to conveya lot of information about structure, meaning andrelationships among NFRs and solution structures in acondensed manner. Additional information can bemade available through hyperlinked facilities thatprovide textual descriptions attached to nodes andlinks and their respective attributes. In such ahyperlink environment the NFR goal graph can thenbe used to navigate through the textual representationin a non-linear manner. This may include navigatingalong trade-offs, alternative solution structures, con-tribution types, related problems, patterns and the like.

. Linking High-Level Business Goals to System Re-

quirements: High-level organisational and systemobjectives may be linked to the forces discussed indesign patterns, and related to when applying patternsduring design. Such links may then provide anunderstanding of how intended software systems andtheir evolving artefacts in fact contribute to the high-

34 D.Gross and E.Yu

level, and to some extent strategic, directions anorganisation wishes to take. Using patterns provides amore convenient language when describing how thedesign contributes to those higher-level objectives,such as time-to-market, cost and the like.

The NFR-driven approach and the pattern approach,therefore, can be very complementary. The patternsapproach needs a way to link to requirements, while theNFR approach needs a way to aggregate its fine-grainedsolutions The NFR approach is goal driven, whereas thepattern approach is solution driven. One is top-down andthe other is bottom-up. The two should be combinedbecause the most interesting design decisions areprobably happening in the interactions in the middle.

Acknowledgements. Financial support from Communications andInformation Technology Ontario, the Natural Sciences and Engineer-ing Research Council of Canada, and Mitel Corporation is gratefullyacknowledged. We also thank the anonymous reviewers for theirvaluable suggestions for improvement.

References

1. Boehm BW. Characteristics of software quality. North-Holland,Amsterdam, 1978

2. Bowen TP, Wigle GB, Tsai JT. Specification of software qualityattributes (Report RADC-TR-85-37). Rome Air DevelopmentCenter, Griffiss Air Force Base, NY, 1985

3. Chung L. Representing and using non-functional requirements: aprocess-oriented approach. Department of Computer ScienceUniversity of Toronto, Toronto, 1993

4. Chung L, Nixon B, Yu E et al. Non-functional requirements insoftware engineering. Kluwer Academic, Boston, MA, 2000

5. Mylopoulos J, Chung L, Nixon B. Representing and usingnonfunctional requirements: a process-oriented approach. IEEETrans Software Eng 1992; 18(6)

6. Chung L, Nixon B, Yu E. Using quality requirements tosystematically develop quality software. In: Proceedings of the4th international conference on software quality, McLean, VA,1994

7. Chung L, Nixon B, Yu E. Using non-functional requirements tosystematically select among alternatives in architectural design.In: Proceedings of the first international workshop on architecturefor software systems, Seattle, WA, 1995

8. Chung L, Gross D, Yu E. Architectural design to meetstakeholder requirements. In: Donohue P (ed). Softwarearchitecture. Kluwer Academic, San Antonio, TX, 1999, pp545–564

9. Chung L, Nixon B, Yu E. Dealing with change: an approach usingnon-functional requirements. Requirements Eng 1996;1:238–260

10. Gamma E, Helm R, Johnson R, Vlissides J. Design patterns:elements of reusable object-oriented software. Addison-Wesley,Reading, MA, 1995

11. Buschmann F. Pattern-oriented software architecture: a system ofpatterns. Wiley, Chichester, UK, 1996

12. Coplien OJ. Software patterns. SIGS Books & Multimedia, 199613. Beck K, Johnson R. Patterns generate architectures. In:

Proceedings of the 8th European conference on object-orientedprogramming, Bologna, Italy, 1994, pp 139–149.

14. Alexander C. The timeless way of building. Oxford UniversityPress, New York, 1979

15. Eden AH, Gil J, Yehudai A. Precise specification and automaticapplication of design patterns. In: Twelfth IEEE internationalautomated software engineering conference, 1997

16. Florijn G, Meijers M, Winsen P. Tool support for object-orientedpatterns. In: Proceedings of ECOOP’97, Finland, 1997

17. Coplien J, Zhao L. Symmetry and symmetry breaking in softwarepatterns. In: Proceedings of the second international symposiumon generative and component-based software engineering, Erfurt,Germany, 2000

18. Alexander C, Ishikawa S, Silverstein M. A pattern language:towns, buildings, construction. Oxford University Press, NewYork, 1977

19. Coplien OJ. A generative development process pattern language.In: Coplien OJ, Schmidt DC (eds). Pattern languages of programdesign. Addison-Wesley, Reading, MA, 1995

20. Coplien JO, Schmidt DC. Pattern languages of program design.Addison-Wesley, Reading, MA, 1995

21. http://www.rational.com22. Molin P, Ohlsson L. The points and deviation pattern language of

fire alarm systems. In: Martin RR, Dirk (eds). Pattern languagesfor program design 3. Corporate & Professional PublishingGroup, Reading, MA, 1998, pp 431–445

23. Yu E. Modelling strategic relationships for process reengineering.PhD thesis, Department of Computer Science, University ofToronto, 1995

24. Bosch J, Molin P. Software architecture design: evaluation andtransformation. In: IEEE engineering of computer based systemssymposium, 1999

25. Lee J. Extending the Potts and Bruns model for recording designrationale. In: Proceedings of the 13th international conference onsoftware engineering, Austin, TX, 1991, pp 114–125

26. Potts C, Bruns G. Recording the reasons for design decisions. In:Proceedings of the 10th international conference on softwareengineering, 1988, pp 418–427

27. Mylopoulos J, Chung L, Yu E. From object-oriented to goal-oriented requirements analysis. Commun ACM 1999;42(1):31–37

28. Yu E, Mylopoulos J. Why goal-oriented requirements engineer-ing. In: Dubois E, Opdahl AL, Pohl K (eds). Proceedings of the4th international workshop on requirements engineering: founda-tions of software quality, Pisa, Italy, 8–9 June 1998, Pisa, Italy.Presses Universitaires de Namur, 1998, pp 15–22

29. Lamsweerde A. Requirements engineering in the year 2000: aresearch perspective. In: Proceeding of 22nd internationalconference on software engineering. ACM Press, Limerick,2000, pp 5–19

30. Jarke M. Requirements Tracing. Communication ACM 1998;41(12)

31. http://www.cs.toronto.edu/km/ome32. Gentner D. Structure-mapping: a theoretical framework for

analogy. Cognitive Sci 1983;7:155–17033. Jurisica I, Mylopoulos J, Yu E. Using ontologies for knowledge

management: an information systems perspective. In: Knowl-edge: creation, organization and use – Proceedings of the 62ndannual meeting of the American Society for Information Science(ASIS’99), 31 October–4 November 1999, Washington, DC, pp482–496

From Non-Functional Requirements to Design through Patterns 35

Appendix

Fig. 17. Modelling notation legend.

36 D.Gross and E.Yu