January 1997. Revision prepared for Requirements Engineering, Volume 1, Number 4.

Dealing with Change:

An Approach Using Non-Functional Requirements1

Lawrence Chung Brian A. Nixon Eric Yu

Computer Science Program Department of Computer Science Faculty of Information Studies

The University of Texas at Dallas University of Toronto University of Toronto
P. O. Box 830688
Richardson, TX 75083{0688 Toronto, Ontario M5S 3H5 Toronto, Ontario M5S 3G6
U.S.A. Canada Canada
chung@utdallas.edu nixon@ai.utoronto.ca eric.yu@utoronto.ca
(1{972) 883{2178 (1{416) 978{4299 (1{416) 978{3107
Facsimile (1{972) 883{2349 Facsimile (1{416) 978{1455

1
This is an extended and revised version of a paper [13] appearing in the Proceedings of the Second
International Symposium on Requirements Engineering, York, England, March 1995. A draft of that paper
was prepared when all three authors were at the Department of Computer Science, University of Toronto.
Address correspondence to the rst author.

1
Abstract
Non-functional requirements (or Quality Requirements, NFRs) such as condentiality, perfor-
mance and timeliness are often crucial to a software system. Concerns for such NFRs are often
the impetus for change. To systematically support system evolution, this paper adapts the
\NFR-Framework" which treats NFRs as goals to be achieved during development. Through-
out the process, consideration of design alternatives, analysis of tradeos and rationalisation
of design decisions are all carried out in relation to the stated goals, and captured in historical
records. We show how such historical records of treating NFRs as goals also systematically
support system evolution. This approach is illustrated by a study of changes in loan policies
at Barclays Bank. The study considered changes in NFRs, and associated changes in priori-
ties, workload and functionality. The study's historical records helped quickly determine the
impact of changes. We also present guidelines for consistently managing historical records,
and address tool support for the change process.

Keywords: change, non-functional requirements, software quality, software evolution.

2
1 Introduction
Non-Functional requirements (or quality requirements, NFRs) such as condentiality, per-
formance, informativeness and timeliness are often crucial to a software system, such as a
banking information system or medical and government information systems. Such concerns
for non-functional requirements are often the impetus and justication for the evolution of
a system. Furthermore, the continued success of a software system often requires meeting
changing organisational needs in a competitive marketplace [32].
In fact, changing and con icting requirements were one of the three main problems for
software development, as identied in problem-driven empirical studies [20]. Consequently,
developers continuously aim for better software, increased productivity and lower cost, all in
the presence of a changing environment. But dealing with change is dicult. Why?
Changes to existing software requires dealing with many changes, and many types of
changes. For a banking system, for example, these include changes in organisation (e.g.,
reduction in sta), non-functional requirements (e.g., greater informativeness), functional
requirements (i.e., what the system does, e.g., what the system should print on statements),
priorities (e.g., condentiality is more important than speed), organisational workload (e.g.,
the number of bank clients), target-system techniques (e.g., how to achieve good response
time) and the like. This involves identifying important changes, determining their potential
impact on quality issues, and incorporating the impact through the process of improvement.
The eect of changes can include a change in the target system selected, and a change in the
degree of meeting requirements | both the requirement which was changed, and others. In
dealing with change, thus, there are many decisions to make which are inter-related, many
options at each decision point, many criteria for each decision, and, consequently, developers
need to know which decisions to re-consider.
To alleviate these diculties in dealing with change, given the need for system quality, this
paper looks to goal-oriented requirements engineering. More specically, this paper adapts a
goal-oriented framework, the NFR Framework [9, 41, 16] which treats quality requirements
as goals to be achieved during the process of system development, hence being complemen-

3
tary to the traditional product-oriented approach which measures quality of the product.
Throughout the process, consideration of design alternatives, analysis of design tradeos and
rationalisation of design decisions are all carried out systematically in relation to the stated
goals. This process not only serves as a means for quality-focussed development but also
results in an history record. In this paper, we show how an historical record of the systematic
treatment of quality requirements during the development process can also serve to support
evolution of the system.

Study. This process-oriented incremental approach is illustrated by a study of changes

in bank loan policies at Barclays Bank. In the study, we consider the impact of changes,
primarily changes in non-functional requirements driven by changes in organisational policy.
The scenario is based on two editions of The Barclays Code of Business Banking [2, 3]
which is in real-world use, setting out the general principles and terms of Barclays Bank's
dealings with its business loan customers. One edition of the Code [2] was a common example
for the Workshop on Research Issues in the Intersection between Software Engineering and
Articial Intelligence, Sorrento, Italy, May 1994.
In reviewing both editions of the Code [2, 3], we see that the bank has a number of
quality concerns, including security, accuracy and timeliness. Furthermore, we assume that
performance is also an important quality concern.
The rst edition [2] identies a number of changes which were to be implemented in 1992,
many of which relate to oering clients several options for more informative reporting on
bank-loan statements. This trend towards greater informativeness continued in the second
edition [3], which is quite similar to the rst edition.
We considered how our approach might be used to help bankers deal with changes. In
the study we reviewed policy manuals for bank loans, which re ected changes in corporate
requirements and operations. We considered a variety of non-functional requirements (for
informativeness, performance, timeliness, etc.). We addressed changes in NFRs, as well as
associated changes in priorities (e.g., there was a trend towards greater informativeness),
workload (e.g., increases in statements generated) and functionality (e.g., sending additional

4
or more detailed statements to clients). We also considered a change in techniques used to
produce a target system.
Using the approach involving historical records, we were able to quickly represent and deal
with changes, and determine the overall impact of changes, including the impact on meeting
NFRs for the changed system.

Paper Outline. Section 2 presents an overview of our process for dealing with change. In
a study using the scenario of the Barclays Code of Business Banking, Section 3 illustrates
the rst half of the change process, namely how we generate an initial design from the bank's
initial requirements. It also gives a brief tutorial on the NFR Framework. Section 4 continues
the study by illustrating the second half of the change process, namely, how the initial design
can be changed to deal with changes in requirements, based on the trends of change in the
Barclays Codes. Section 5 oers guidance for the change process in term of guidelines for
consistently managing historical records in the presence of changes in the world. Section 6
discusses the cataloguing of domain and NFR-specic knowledge to aid the process of dealing
with NFRs and change. Section 7 describes a set of features that a tool should have to support
the change process. Section 8 presents related work and future work, while Section 9 presents
lessons learned through the study, contributions of the paper, and some open issues.

2 An Overview of the Change Process

This section describes a process of change which exploits the goal-oriented requirements engi-
neering paradigm, consistent with the requirements engineering process of [37]. This process
is intended to alleviate the diculties in dealing with change, while maintaining a focus on
quality. In order to deal with change, we go back to the source where the changes originated,
namely the previous requirements description, and compare with the new one. Changes can
be introduced to deal with the current needs of the organisation. This can involve changes to
non-functional requirements, as well as associated changes in priorities, functionality, work-
load, and so on. Since this may involve improving the quality of the existing system, it is

5
helpful to put quality concerns foremost in the minds of system developers, who can then try
to address such concerns appropriately.
By adapting the goal-oriented NFR Framework [9, 41], we treat quality requirements as
goals to be achieved during the process of system development, as well as during subsequent
system evolution. Throughout the process, consideration of design alternatives, analysis of
design tradeos and rationalisation of design decisions are all managed systematically in
relation to the stated goals. This process not only serves as a means for quality-focussed
development, but also results in an history record. In terms of the historical record, changes
in quality requirements of an existing system are made incrementally only to those parts of
the existing system components that need change.
Our process-oriented incremental approach is depicted pictorially in Figure 1. In this
approach, the change process starts with the development of an initial system, if not already
available. Here, we represent the initial requirements and map out an initial design. The
history record resulting from the initial requirements engineering process is sketched on the
left-hand side of Figure 1. We then represent change in requirements, produce a revised
design, and determine the results which might stem from the changes. The history record
resulting from this change process is shown on the right-hand side of Figure 1. Note that this
change process can continue to successively yield new systems. In this case, the term \initial"
should be replaced by \old" (\previous" or \currently existing").

Initial Requirements Engineering. Now we go through this systematic process, in more

detail, which involves an initial requirements engineering process followed by a change process.
An early step in the initial process is to identify the initial top-level requirements. By con-
sulting the particular organisation's high-level requirements description, policy documents,
memos, employees, similar systems, etc., we identify the initial top-level requirements and
represent them as goals to achieve in an history record. If needed, we also prioritise the goals
according to the needs of the particular organisation at hand.
In a bank loan system, such as business banking at Barclays Bank, we would be dealing
with a combination of NFRs in calculating loan interest, printing statements, providing infor-

6
 Before 1992 greater After
informativeness
Initial Requirement New Requirement

Initial Design Result: New Design

informativeness
performance

Figure 1: Change process.

mation to clients, etc. Such NFRs would include: informativeness of loan information, good
time performance, accuracy in time-related matters, providing information in a timely way,
etc.
As NFRs are often interpreted dierently by dierent groups of people, we may also want
to clarify them, via decompositions, and justify the way they are claried, via rationale. The
initial top-level requirements and their decompositions are depicted on the top portion of the
left-hand side of Figure 1.
In moving to a target system, we consider design techniques, from a catalogue of such
techniques, to achieve NFRs represented as goals. To select a technique among alternatives,
we carry out tradeo analysis by considering their impact on the goals, with the help of a
catalogue of interrelationships which describes contributions of goals towards meeting other

7
top goals. This analysis may involve consideration of domain knowledge, priorities, the sys-
tem's workload, etc. Afterwards, we nally choose the target and record rationale behind
the decision. This kind of decision rationale facilitates later review, justication and system
evolution, as well as enhancing traceability. The resulting history record is shown on the
bottom portion of the left-hand side of Figure 1.
We can then evaluate the impact of decisions (at the bottom of the historical record) upon
NFRs (at the top of the record) by tracing upwards.
Throughout this initial development process, design alternatives, tradeos, decisions and
rationale are all considered in relation to the NFRs stated as goals, managed systematically,
and recorded in the history record.

Dealing with Change. Now let us turn to dealing with change. We consider both the
sources of change (e.g., changes in organisational policy) and the eects of change (e.g.,
changes in the target system produced).
The sources of change can be manifold: changes in organisation (e.g., reduction in sta),
NFRs (e.g., greater informativeness, in a bank loan system, because the bank wants to serve
customers better), functional requirements (i.e., what the system does, e.g., what the system
should print on statements), priorities (e.g., informativeness is more important then con-
dentiality), workload (e.g., the number of bank clients), and the like. The eects of change
can include a change in the target system selected, and a change in the degree of meeting
requirements | both the requirement which was changed, and others.
The result of the initial requirements engineering process was an history record of goals,
design alternatives, tradeos, decisions and rationale. This history record enables develop-
ers to deal with change incrementally by revising only those parts that need change, then
regenerating the rest and determining the eects of such revision.
Importantly, we do not start again \from scratch." Instead, we start with the initial
requirements which have already been represented as goals in the history record. We re ect the
changes into the history record by: examining the dierences between the initial requirements,
possibly tracing back to their sources if ambiguities arise, and the new requirements which

8
need to be extracted from their corresponding sources; and representing the new requirements
as goals incrementally.
This incremental change to the history record may involve, for each new change, nding a
relevant component (or components) in the initial historical record and making adjustments
to it by adding a new component, changing priority, changing workload, re ecting change in
organisational policy, etc. This way, we are able to represent the new set of requirements and
associated changes quite concisely and quickly. Addition of the new requirements as goals
leads to new interrelationships, between the new and initial requirements, and decompositions
of the new requirements or even initial ones. These changes, in turn, may lead to new
interrelationships between the initial design components and the additions.
In moving to a new target system, we reconsider the target alternatives and the tradeos
considered previously for the initial design. As well, there may be new target-system alter-
natives and new or revised tradeos to consider in the new context. Afterwards, we nally
choose the new target and record rationale behind the decision.
Throughout this change process, design alternatives, tradeos, decisions and rationale are
again all considered in relation to the stated goals, managed systematically and recorded in
the history record, a structure which has been used for both initial development and later
change.
By comparing the initial design, we can clearly see the impact of changes in the new
target system design, and in the degree of meeting some initial top-level requirements, and
the reasons why.
In the next two sections, we illustrate in detail the change process by studying the scenario
of the Barclays Code of Business Banking.

9
3 Study (I): Generating the Initial Design from Initial Re-
quirements
This section and the next illustrate the approach to dealing with change, by studying the
Barclays Code of Business Banking, described in Section 1. This section describes how an
initial design of the bank loan information system might be generated from the initial quality
requirements before changes were made. It also introduces the NFR Framework and its main
components. Section 4 continues the study, with consideration of changes in the bank's
requirements, and associated changes in priorities, workload, functionality and target-system
techniques.

3.1 Initial Top-Level Requirements

We rst consider a development process which re ects the situation prior to the 1992 changes
in the Barclays Code [2]. At the same time, we review the main concepts of the NFR Frame-
work. A number of quality requirements are identied in the Code, including informativeness,
condentiality (security) and accuracy. As Barclays is increasing automation while its sta
complement is decreasing [4], we assume that system performance is another important re-
quirement.
One type of service that Barclays Bank provides is lending money. When clients want to
borrow money, they go through negotiations with the bank concerning loan period, interest
rates, method of payment, etc. The bank can change some conditions during the loan period,
and wants to keep clients informed in a timely manner. The bank also wants to keep clients'
nancial aairs condential.
Interest rates on loans have two components: a base rate (prime rate), which is set na-
tionally by the bank for all customers, and an interest margin which is set individually for
each customer based on the risk involved. The bank gives advance written notice of changes
in the interest margins. Advance notice is not given for changes in the base rate, which take
eect immediately for all clients, and are advertised in the national press.

10
 In reviewing Barclays' policies, supplemented with our intuition about banking, we identi-
ed important NFR goals. Some are captured and shown in Figure 2 (adapted from [11, 12]).
A legend for all goal graphs (historical records) is shown in Figure 3.
Time Timeliness Informativeness Security
[loan-info] [loan-info] [loan-info] Accuracy [loan-info]
[loan-info]
+ +

Time[produce Time[change Time[produceTime[change Confirmation TimelyAccuracy Accurate Accurate

statements] BaseRate] statements] BaseRate] [loan-info] [loan-info] Properties Attributes
[loan-info] [loan-info]

Figure 2: Initial top-level goal graph for loan information system.

Legend

Link Types: Goal Types: Link (Correlation) Node Values:

Values:
++ very positive very satisficed
satisficing link NFR goal + positive satisficed
correlation link satisficing goal partially satisficed
unknown
argument ? or neutral neutral or unspecified
partially denied
AND node
- negative denied
-- very negative

Figure 3: Legend for graphical symbols for goal graphs.

Main goals are shown at the top of Figure 2. Nodes represent goals, which stand for
requirements. As a performance requirement [49], for example, the goal Time[loan-info] (or
TimePerformance[loan-info]) means loan information should be processed by the system with
good time performance, i.e., rapidly. Timeliness[loan-info] means that clients should be quickly
notied about loan information. Similarly, Informativeness[loan-info] means loan information
should be informative, and Security[loan-info] means that loan information should be main-
tained securely, i.e., kept condential. Finally Accuracy[loan-info] means that loan information
should be maintained accurately. These requirements are shown at the top of Figure 2 as NFR
goals. The nodes represent goals, which stand for requirements. Each goal has a sort, e.g.,

11
Security, which indicates the kind of requirement associated with the goal, and a parameter,
e.g,. [loan-info], to indicate the subject of the goal.
Decompositions are one type of method for taking a goal and generating ospring goals.
For example, the parent goal Timeliness[loan-info] can be decomposed into ospring goals
Timeliness[change Base Rate] and Timeliness[produce Statements], which are connected by an
AND link. The interpretation is that if the base rate can be changed in a timely manner,
and statements can be produced in a timely manner, then we have some condence that
timeliness of loan information can be \satisced." Since goals representing NFRs are rarely
\satised" in a clear-cut sense, but decisions do contribute to, or hinder, a particular goal, we
use goal satiscing [54] to suggest that generated software is expected to satisfy NFRs within
acceptable limits, rather than absolutely.
Besides AND links, other kinds of link types (beyond [44]) are available, which indicate
dierent relationships; for example a negative link (shown as \-" in gures) indicates that if
the ospring goal is satisced, the parent goal will be denied.
Goals can be decomposed using a variety of methods. Above, we used a method which
decomposed Timeliness[loan-info] into goals for operations on the loan information. The same
pre-dened generic method is used to decompose the top-level TimePerformance goal.
Generic methods often capture knowledge from a domain or a quality-related eld of
study (e.g., performance or security). In order to support the development process, we have
catalogued (See Section 6) in a knowledge base such expert knowledge about sorts, decom-
positions, correlations and satiscing goals, for some specic NFRs. This study draws on
those catalogues, which were developed as parts of specialisations of the NFR Framework to
deal with accuracy, security and performance [7, 10, 9, 46, 47, 48, 49]. Such catalogues are
available to the developer throughout the development process. In addition, developers can
dene and use their own methods.
Using another method, the security goal is decomposed into goals for accuracy, conden-
tiality and availability, which are the major components of security as viewed by security
experts (e.g., [28]). The cataloguing of such expert knowledge is considered in Section 6.

12
Similarly, accuracy can be decomposed [9] into goals for accurate attributes, accurate proper-
ties, and timely accuracy. Timely accuracy, the timely recording of information items in the
information system, will be further considered in Section 4.
A satiscing goal is one which is intended to satisce an NFR goal. It takes its parent
goal and moves towards an alternative for the target system, and is shown as a dark circle.
Barclays policies state that loan information be conrmed in writing for informativeness.
The satiscing goal of Conrmation is a good choice, not only for informativeness, but also for
accuracy. Accordingly, a positive contribution of conrmation towards accuracy is established
through a correlation link (shown as a dotted line) labelled with \+".
p
Each of the goals is associated with a label indicating whether it is satisced (\ "), denied
(\X") or has some intermediate or unknown value. The labelling algorithm can be viewed as
starting with leaf-nodes, and propagating values upwards, by considering the combination of
node label values and link types. Here, satiscing conrmation gives some positive contribu-
tion to satiscing informativeness and accuracy, which in turn contributes towards satiscing
security. We call the kind of historical record shown in Figure 2 a \goal graph."2

3.2 Generating the Initial Design

To generate an initial design (Figure 4), we continue the process of dealing with the initial
quality requirements, focussing on a portion of Figure 2 which deals with timeliness and time
performance. As mentioned above, changes in base interest rates3 must be put into eect
immediately. We consider a change in base rate prior to 1992 (After 1992, this discussion also
applies, but as we will see in Section 4, it will interact with changes in other requirements).
The need to identify and focus on priority goals (critical goals, or goals involving dominant
parts of the workload) has been pointed out for performance goals in particular [55], and
quality goals in general [39, 33]. Thus we rene the time performance goal for changing the
base rate by identifying it as critical; to support this, we attach an argument (Claim) that
2
By our convention, top-level goals, satiscing goals, priority goals and other important goals are shown in
bold face in historical records.
3
Note that a change in interest rates is not treated herein as a change in requirements.

13
 Time[loan-info] Timeliness[loan-info]

Time Time Timeliness

Timeliness
[produce stmts] [change BaseRate] [change BaseRate] [produce stmts]

Claim["must be
done immediately"]
+
Time[change BaseRate; critical]

Claim["fast: Claim["very slow:

change just 1 central value"] change value for each of many clients"]

++ -
StoreCentrallyOnce StoreForEachClient
[BaseRate] [BaseRate]

This history record shows:

1. Identication of priority (critical) goal;
argument based on policy
2. Correlation of Time with Timeliness
3. Consideration of target alternatives

Figure 4: Goal graph with portion of initial design of loan information system.

base rate changes must be done immediately. Note that this design rationale in this case is
based on organisational policy.
Now for changing the base rate, the goal for timeliness, the provision of information in
a timely way, will be helped by quickly changing the base rate. The reason is that a system
which can make the change with good time performance will be able to assist in notifying
customers of the change in a timely manner. This correlation link is detected and shown in
the gure with a \+" sign.
In moving towards a target system for changing the base rate, we consider the satiscing
goals. One alternative is to store the new rate for each client. Even though there is only
one base rate at any given time, it may be helpful to replicate the base rate for each client.

14
For example, this can be helpful if the base rate is kept at one place, and client-specic
information is kept at some other place. This is ruled out by arguing that it is very slow
(shown as \-" in Figure 4) when the base rate is changed, since each client record must be
updated, and that there are many clients. This later argument is based on workload, and is
suggested by statistics [4, 5] available to us.4 Although this alternative is negative for time
performance, the change in requirements in Section 4 will introduce a tradeo which shows a
positive correlation with another quality requirement.
Another target alternative is to store the base rate once, as a single value in the information
system. This treats the base rate as an attribute of the group of all loans taken as a whole.
As only one value must be changed, it is argued that this provides a very fast method (shown
as \++") of bringing the new base rate into eect, and this method is chosen for the target
system.
Now we have labelled some leaf nodes as satisced or denied. To determine the impact
on higher-level goal nodes, the labelling algorithm is used. Working bottom-up, it takes into
account the labels of ospring, and the link type (e.g., \+", \-"). For example, storing the
base rate once, when combined with its very positive (\++") parent-ospring link, leads to
a good satisfaction of the critical time goal. This in turn has some positive contribution to
the timeliness goal for changing the base rate, and some partial positive contribution to the
overall goals for time performance and timeliness, shown at the top of Figure 4. Note that a
satisced ospring, when combined with a negative link, would lead to a denied parent; for
example, if we had chosen StoreForEachClient, the critical time goal would have been denied.
The process of constructing the goal graph was facilitated by the use of the framework's
methods for capturing knowledge about NFRs, and the decomposing and satiscing of NFR
goals, as well as knowledge about justifying design decisions. Using the approach, we were
able to draw on catalogues of NFR knowledge, described in Section 6. We were also able to
represent domain knowledge, including priorities and workload information. This process was
4
While we do not have the number of clients available to us, in 1993, the average balance of loans and
advances to customers of United Kingdom oces was 60 230 million Pounds Sterling, and the worldwide sta
numbered 97 800.

15
also facilitated by the use of the framework's correlation rules for capturing knowledge about
goal interactions, positive and negative. The framework oers the evaluation procedure, by
which we were also able to see, throughout this goal graph expansion process, the eect of
each design decision using the framework's evaluation procedure.
We have now considered the use of the NFR Framework, but without dealing with a
change in requirements. The next section will consider the impact of changing requirements.

4 Study (II): Changing the Design to Deal with Changed

Requirements
Continuing the study, we now consider how we could deal with a change in requirements,
as well as associated changes in priorities, workload and functionality. We also consider the
addition of a target-system technique.

4.1 Changing the Design by Adding a New Requirement

We consider a change in requirements, in particular the addition of a new requirement due
to a change in organisational policy. We now consider the transition to oering loan clients
more reporting detail and options on their statements. The provision of enhanced statements
started in 1992. Both editions of the Code [2, 3] re ect the changes in organisational policy,
with the trends being towards greater informativeness, and the provision of more detailed
breakdown of charges.
For the purposes of the study, we assume that the provision of enhanced statement would
include a detailed list of the base rate(s) and interest margin(s) which were in eect for the
client during the period of the statement. Note however that the details of the enhanced
statements are not mentioned in the Barclays Codes.
In Figure 5, we consider the addition of a requirement for good time performance for
producing enhanced statements. Figure 6 provides a legend for changed goal graphs, and is
to be used in conjunction with the basic legend of Figure 3.

16
 Time[loan-info] Informativeness[loan-info]

Time Time Time

[produce statements] [change Base Rate] [produce enhanced statements]

Time Time
[include Base Rates] [include Margin Rates]

This history record shows:

1. New NFR Goal due to organisational policy change
2. Added ospring to AND node
3. Added positive Correlation to Informativeness
4. Assumed enhanced statements include
adding info on interest rates and calculations

Figure 5: Goal graph with new requirement.

Legend for Changes

Link Types Goal Types

new link
new NFR goal
new correlation link
new argument
AND node with a new offspring
new satisficing goal

Figure 6: Legend for graphical symbols for changed goal graphs.

17
 The time goal for enhanced statements is in turn decomposed into time goals for including
both base rates and margin rates in statements. The gure's legend shows how new goals
and new links to ospring are presented.
Note that the change in requirements (e.g., increased informativeness) may re ect a change
in priorities, and may lead to a change in functionality (e.g., providing more detailed state-
ments), and an change in workload (here, an increase in system processing).

4.2 Adding a New Target Technique

Time[loan-info] Informativeness[loan-info]

Time Time Time

[produce statements] [change Base Rate] [produce enhanced statements]

Claim["must be
done immediately"]

Time[change BaseRate; critical]

Time Time
[include Base Rates] [include Margin Rates]

++ + -
Claim["fast: Claim["fast: Claim["very slow:
change just but some change value for
1 central value"] overhead"] each of many clients"]

StoreCentrallyOnce StoreForEachClient
StoreCentrallyThenForEachClient
[BaseRate] [BaseRate]
[BaseRate]

This history record shows:

1. New target alternative added
2. Added relationship of new alternative to existing priority (critical) NFR goal

Figure 7: Goal graph with new requirement and target technique.

In Figure 7, we extend Figure 5 to show the addition of a new possible satiscing goal,
18
StoreCentrallyThenForEachClient[BastRate], shown at the bottom centre of the gure. This
represents a new techniques for the target system, which will be discussed below. Note that
the new satiscing goal has been associated to its parent goal by a new link, which has a label
value. As well, a new argument (Claim) has been associated with that link.

4.3 Changing the Design to Meet the New Requirement

In Figure 8, the history record shows the results of additional NFR goal Time[produce enhanced
statements]:
1. Decompose into Time[include Base Rates] and another goal
2. Correlation (++, +, -) of Time[include Base Rates] with 3 alternative satiscing goals
3. Decompose TimelyAccuracy[loan-info]
4. Correlations with new goal TimelyAccuracy[produce enhanced statements]
5. Add arguments
6. Argument added re workload
7. Result: Change in satiscing goal chosen, i.e., change in target system
In Figure 8, the new requirements result in interaction with existing requirements, leading
to new tradeos (e.g., accuracy-performance), and a new target system, with new arguments
leading to the revised system. In particular, there is interaction between changing the base
rate (Figure 5) and producing statements (which are assumed to now include the base rates).
This leads to a tradeo between time performance and timely accuracy, the timely recording
of information items in the information system.
Figure 8 shows a goal for Timely Accuracy of loan information. This would be decomposed,
prior to 1992, into goals for accuracy for changing the base rate, and for producing (basic)
statements. After 1992, another ospring, for the accuracy of producing enhanced statements,
would be added. A similar decomposition was shown previously in Figure 5, in which a time
performance goal of producing enhanced statements was decomposed into time goals for
including the various interest rates in the statements.

19
 Timeliness Informativeness
[loan-info] [loan-info]

+ +
+
Time TimelyAccuracy
[loan-info] [loan-info]
+

Time Time
Time
[change [produce
[produce enhanced
Base Rate]
stmts.] stmts.]

Claim["must
be done
Time Time Timely Timely
immediately"] Timely
[include [include Accuracy Accuracy
[produce [change Accuracy
Base Rates] Margin Rates] [produce
enhanced BaseRate]
stmts.] stmts.]
Time[change BaseRate;
critical]

Claim[#3]

Claim[#1] Claim[#2]

++ -
- + +
+
StoreCentrally StoreCentrally Store
Once ThenForEachClient ForEachClient
[BaseRate] [BaseRate] [BaseRate]

 Claim[#1: "slow: extra rate retrievals for EACH of MANY clients"]

 Claim[#2: "fast (but some overhead) since retrieving each client record anyhow, and each has
interest rate info; correct right after rate change"]
 Claim[#3: "fast since retrieving each client record anyhow, and each has interest rate info;
incorrect right after rate change"]

Figure 8: New design resulting from adding a new requirement.

20
 Now consider the performance impact of including the base rates upon the existing alter-
natives for a target system, and the associated arguments. This is an example of \downward
correlation" [9]: a correlation link is established from a NFR to a satiscing technique. Stor-
ing the base rate for each client will result in very fast time performance (shown as \++"),
since preparation of each statement must involve retrieval of each client record anyhow; since
each record would include the base rates, little additional work would then be needed to
obtain them. Storing rates centrally would result in poor performance (shown as \-") due to
the extra rate retrievals required for each client; we can argue, based on the organisation's
workload, that this choice is very poor due to the large number of bank clients.
The choice of target system design is not yet complete, however, due to the impact of the
target alternatives upon the Timely Accuracy goal for producing enhanced statements. This
is an example of \upward correlation" [9]): a correlation link is established from a satiscing
technique to a NFR. Here there is an accuracy issue which stems from including the base rate
in statements.
Suppose the base rate is changed just before statements are prepared. Now if only one
base-rate value is changed in the entire system, this can be quickly changed, preserving
accuracy. However, if the rate is changed for each client, this might take a long period of time
to complete, and it is possible that some statements would incorrectly show only the old base
rate.
Now we introduce a new alternative, StoreCentrallyThenForEachClient[BaseRate], which
was not considered in the initial study. This third alternative is an hybrid of the other two
satiscing methods; it involves rst changing the centrally stored rate, then updating the
rates stored in all client records. Its time performance for including the base rate (shown as
\+") is in between the other two methods. It is a little slower than only storing the value
for each client, due to the overhead of having to rst decide whether a rate has recently been
changed, etc.
However, this hybrid method can maintain accuracy, as it checks whether the base rate
has recently been changed before retrieving a value: if there has been a recent change, it uses

21
the (correct) central value; otherwise it uses the (correct) value in the client record.
Thus the arguments show that in producing enhanced statements, there are tradeos
between time performance and timely accuracy. As accuracy is a very important corporate
goal, it is given priority, and storing the base rate for each client is ruled out, as it sometimes
gives incorrect results. On the other hand, performance is also important, so storing the rate
centrally alone is ruled out, as it is generally slow, even though accurate. Thus the hybrid
method is chosen, as it is accurate and oers reasonable performance.
Recall that with the prior requirements (Figure 4), the rate would have been stored only
centrally. If the hybrid method had been considered earlier, it would have been ruled out,
due to its performance overhead. Now, however, in the presence of the accuracy-performance
tradeo, the new hybrid method is considered reasonable, oering timely accuracy, and also
reasonable time performance for both changing the base rate and including the rate in state-
ments. Thus consideration of an organisational change has resulted in a change in the target
system.
Given the choice of target system, we wish to see the impact on quality requirements. We
can use the framework's partially automated labelling procedure, which takes into account the
values (satisced, denied, etc.) of lower nodes, and the link relationships (positive or negative)
to determine whether higher nodes are satisced. Here, for example, the choice of the hybrid
method has a positive impact upon timely accuracy of producing enhanced statements, and
upon time goals for both changing the base rate and including the base rates in statements.
These last improvements has a positive impact on meeting ther time performance goal for
producing enhanced statements. The overall impact on top goals is shown in Figure 9.
To simplify the presentation, note that some nodes (both those before and after the
changes) are not decomposed to satiscing goals, or are not labelled. For example, we did
not consider here how to satisce the new time performance goal for including margin rates
in statements. Likewise we did not consider, either initially or subsequently, Time[produce
statements].
But for achieving good time performance for loan information, quickly including the mar-

22
 Timeliness Informativeness Security
[loan-info] [loan-info] [loan-info]
Time Accuracy
[loan-info] + [loan-info] +
+
+

Time Time Time Confirmation TimelyAccuracy Accurate Accurate

[produce [change [produce [loan-info] [loan-info] Properties Attributes
[loan-info] [loan-info]
statements] BaseRate] enhanced
statements]

Figure 9: Impact on top-level requirements of adding new requirement.

gin rate in the enhanced statements is important, and quickly producing the basic statements
was and is important. So here, without satiscing the ospring we cannot label the top-level
parent TimePerformance[loan-info] as satisced. What we can say about the unlabelled goals
is that if the initial goals were satisced and remained satisced, they would contribute to
satiscing the parents. Likewise, satiscing new ospring will help to satisce the parents.

4.4 Impact of Change on Other Top-Level Requirements

What has been the impact of the change in requirements?
1. The goal graph (Figure 9) now includes the history of dealing with the change. Goals
have been added for producing enhanced statements, and ospring goals have been added
for including various interest rates in the statements. In addition, the graph now contains
the interactions which were detected among the initial and additional goals. Tradeos were
considered and arguments were revised.
2. We have considered changes in priorities, workload and functionality which are associ-
ated with the change in requirements. This led to consideration of a new satiscing goal.
3. This has lead to a change in the target system. This was driven by changes in require-
ments, and was rationalised by changes in arguments.
4. This has also changed the extent to which we have satisced the overall top-level require-

23
ments, not just the lower-level ones considered in the previous sub-section. The eect was to
meet the new goals, which contributed positively towards the top-level goals. For example,
the new goal TimelyAccuracy[produce enhanced statements] was satisced and makes a pos-
itive contribution towards TimelyAccuracy[loan-info]. As part of the tradeo, however, time
performance for changing the base rate went from being very satisced to being satisced,
which is still acceptable for this critical goal. By comparing Figure 9 with Figures 2 and 4, it
can be seen that the overall impact has been an increase in informativeness and timeliness,
with some time performance cost due to the extended processing needed for producing the
enhanced statements.

5 Guidelines for the Change Process

Dealing with change is dicult due to many changes, and many types of changes in non-
functional requirements, functional requirements, priorities and workload, and the like. Fur-
thermore, in dealing with change, there are many decisions to make which are inter-related,
many options at each decision point and many criteria for each decision. In view of the need,
we present guidelines for maintaining the consistency of history records, in the presence of
such changes.
Incorporating changes into the initial design involves identifying changes in the require-
ments, organisation and its workload, and associating them with appropriate components of
the history record, i.e., goal graph. This process of identication and association is often
interleaved, and proceeds incrementally, together with the analysis of change in design trade-
os, the evaluation of change in goal achievement, and the rationalisation of the change in
relation to the previous system and a trace of its sources.
An important aspect of our work is its knowledge-based approach, helping the developer
capture, use and re-use development knowledge. To more fully realise the benets of this
approach, tools should provide semi-automated support of a developer dealing with change.
We have developed tools for dealing with quality requirements for the NFR Framework
(See Section 7). These tools primarily help the developer state and rene goals. But now,

24
dealing with change may require operations, such as removal of a goal, which may temporarily
make the goal graph inconsistent. In these cases, help is needed to restore the goal graph to a
consistent state. Accordingly we oer some guidelines, for helping ensure that some syntactic
and semantic structural consistency criteria are met. These would help us provide a tool to
deal with situations relating to change, some of which were illustrated in Section 4.

5.1 Desirable Properties of Goal Graphs

Incorporation of revisions into a goal graph includes a process of rening goals, detecting
interactions, disambiguating terminology, and detecting con icts, omissions and redundancies.
This process is facilitated by a number of notions.

Basic Traceable Goal Graph.

These notions apply to all goal graphs, whether initial or changed.
The use of the notion of structurally traceable goal graph provides some \syntactic" prin-
ciples for maintaining the structure of a goal graph:
1. Each argument should be attached to a goal or a link.
2. Each link should have its direction (positive, negative or neutral) and strength (strong,
weak, to-be-specied) of contribution specied.
These guidelines help the labelling procedure to determine whether goals are satisced.
This knowledge-based process becomes more justiable by the use of the notion of a
knowledge-source traceable goal graph:
1. Each decomposition, satiscing or argumentation should be associated with either a
generic- or developer-supplied method.
2. Each correlation link should be associated with a generic- or user-supplied correlation
rule.

25
These guidelines help trace decisions to identiable sources of knowledge, including generic
knowledge of a particular NFR (e.g., security or performance), and the developer's expertise.
When a goal graph is completed with respect to the incorporation of changes, we use the
notion of a goal-decision traceable goal graph:
1. Each NFR goal should have at least one target-system design alternative selected for
it (forward traceable); conversely, a design alternative needs to be traceable to a NFR
goal (backward traceable).
2. Each goal needs to be associated with an originator, such as a responsible person or a
document.
3. Each priority (criticality or dominance) of a goal needs to be associated with an origi-
nator.
4. Each link needs to be associated with an originator.
This notion allows us to trace the relationships among design decisions, their corresponding
goals, properties of goals, and the people who stated the goals.

Meaningfully-Changed Goal Graph.

The process of change is incremental, i.e., there is a goal graph before the change, and changes
are re ected into the existing goal graph, which results in a new goal graph. However, the
construction of a meaningfully changed goal graph may proceed at intervals after a group of
changes are introduced in order to allow consideration of a temporarily partially disconnected
goal graph. We thus introduce the notion of a value-changed goal graph:
1. When a change process is completed, each sink (i.e., a node without any outgoing link)
should be labelled as either satisced or denied, and the labelling procedure invoked.
2. An argument or an originator should be recorded for a change, as suggested by the
second criterion for goal-decision traceable goal graphs.

26
 3. In addition, although omitted from goals graph presentations, the times of changes
should be recorded (See Section 7).
This notion helps ensure that the reasons for changes are documented, and that the results
of the changes are evaluated and can be compared to the previous system.
In order to clearly recognise the eects of changes, we introduce the notion of identiably-
changed goal graph: The impact of each addition, deletion and change in importance of
requirements on new interrelationships, design techniques and design rationale should be
marked as such. This notion helps extract the impact of changes upon the previous system.

5.2 Guidelines for Dierent Categories of Changes

Incorporating revisions into a goal graph is facilitated by a scheme which divides NFR-related
changes into three categories (which correspond to the three types of goals in the legend of
Figure 3) and uses a set of guidelines for propagating the changes. The guidelines are based
on these categories, the kinds of operations on quality requirements, and the structure of the
goal graph.

Guidelines for Changes in NFR Goals. A change in a NFR goal usually proceeds in a
downward direction, linking and expanding the goal to other NFR, satiscing and argument
goals:
(a) addition of a quality requirement: A new goal should generally be linked with exist-
ing goals (NFR, satiscing and argumentation goals). If afterwards there remain any
isolated NFR goals without ospring, we see if ospring can be created and related to
other existing goals. This involves an iterative stage of decomposing the added goals,
considering design trade-os and selecting satiscing goals, and providing arguments
for or against design decisions.
(b) deletion of a quality requirement: This can involve deleting (possibly recursively) all
links (both incoming and outgoing) associated with the requirement, or re-associating

27
 the links with another goal. Each satiscing goal without a parent should be deleted or
linked to another NFR goal. An argument without a parent usually needs to be deleted.
(c) changing the priority (criticality or dominance) of a quality requirement: This can be
done by changing the priority attribute of a relevant goal. This aects the way con-
icts are resolved and the number and type of methods to be selected as well as their
associated arguments.

Guidelines for Changes in Satiscing Goals. A change in a satiscing goal proceeds
both upwards to parents, propagating it to satiscing and NFR goals, and downwards to
ospring, propagating it to other satiscing goals and to argument goals:
(a) addition: This establishes new correlation links and aects goal achievement.
(b) deletion: If this results in an NFR goal having no remaining satiscing goal, that NFR
goal needs further expansion. Also, some correlation links may be deleted, which aects
goal achievement.
(c) change in priority: This aects goal achievement.

Guidelines for Changes in Arguments.

(a) addition: If the argument supports another goal, it has the eect of strengthening the
importance of the goal; if the argument denies another goal, it would have the opposite
eect.
(b) deletion: If the argument is in support of another goal, it has the eect of weakening
the importance of the goal; otherwise, it would have the opposite eect.
(c) change in priority: (1.) If the argument is in support of another goal, this has the eect
of strengthening the importance of the goal, if the argument becomes more critical
(or dominant), but weakens its importance if the argument becomes less critical (or
dominant). (2.) If the argument is in denial of another goal, this has the eect of

28
 weakening importance of the goal, if the argument becomes more critical (or dominant),
but strengthens its importance if the argument becomes less critical (or dominant).

Guidelines for Changes in Links. The impact of addition, deletion and change in priority
of each link, such as a conjunctive (AND) or disjunctive (OR) link, should be structurally
traceable and value-changed.

5.3 Guidelines for Domain-Driven Changes

Changes which originate in the domain will have an impact on the system. We brie y consider
how domain-driven changes (such as changes in priorities, workload and functionality) can
be expressed by a developer in terms of changes to the historical records. These may in turn
lead to further changes to the historical records. Guidelines for maintaining consistency after
a domain-driven change can then of course be expressed in terms of individual guidelines for
maintaining historical records, given above.

Guidelines for Changes in Priorities. Priorities can be associated with goals, e.g., in-
dicating that a goal is critical, or deals with a dominant part of the workload. The priority
associated with a goal may be changed. This may lead to the addition or removal or goals
or links which contribute (positively or negatively) to the goal with changed priority. In
addition, link types may change to show changes in relationships with priority goals.
When a goal's priority has been changed, the developer may choose to focus attention
on the newer or higher priority goals: the depth of goal renement may be increased or
decreased; in addition, a change in link type may result in more or less contribution being
needed to satisce a goal. Furthermore, the developer may consider correlations and tradeos
of new goals and all other goals; in addition, correlations which involved removed goals may
be reviewed.
Then the applicable guidelines will be applied for addition and removal of goals and links,
and for changed link types.

29
Guidelines for Changes in Workload. Workload (e.g., the number of bank clients) is
often recorded in historical records as arguments. Changes in workload can lead to changes
in arguments, and the applicable guidelines would apply.

Guidelines for Changes in Functionality. Consider the case of adding functionality.

The developer would consider what NFRs apply to the new function. For example, the
function may be the parameter of an NFR goal. Consider the case of adding a new sub-task
to an existing task. Then existing goals and decompositions involving the task should be
reviewed to see if a goal involving the new sub-task should be generated. This would be
especially of interest when renements are used which decompose a task into its components.
For all cases of added functionality, the developer should consider correlations and trade-
os between all existing goals and any goals involving the new function. Arguments concerning
new goals and new decompositions should be recorded. Workload information related to the
new function and its associated goals should be recorded, e.g., as arguments.
Then the applicable guidelines will be applied for dealing with added goals, links, etc.

Guidelines for New Target Techniques. In the course of dealing with change, addi-
tional techniques for producing a target system may be considered which were not addressed
in an initial historical record. Some of these additional techniques may result from new tech-
nologies, while others may be considered due to changes in tradeos, costs, etc. As well, some
techniques which were initially ruled out may be reconsidered, or considered in more detail.
Such changes are not necessarily strictly domain-driven, but may be at least external to an
existing system.
The new techniques may be represented as satiscing goals which are added to the his-
torical record, and the appropriate guidelines will apply. If a new satiscing goal is added to
the record but not associated with other goals, the record should be examined to see if it is
meaningfully-changed.
Removal of target techniques or functionality should also be considered in a fuller set
of guidelines. For now, one can approximate the treatment of their removal by (greatly)
30
decreasing the priority of such goals, and not selecting them.

6 Cataloguing Domain and NFR-Specic Knowledge

The change process, introduced in Section 2 and illustrated in Sections 3 and 4, can be
facilitated when knowledge about various types of NFRs and the application domain had been
collected and organised in such a way to be available to the developer at the time of both the
initial development and its subsequent changes. An important role of the NFR Framework is
to help in organising such knowledge and to make them available to the developer as needed.
In several of our studies [14, 47, 9, 10, 48, 49], this cataloguing of knowledge has been helpful,
and was typically performed early.
The NFR Framework allows for acquisition and representation of knowledge about the do-
main being developed. This might include representation of functional requirements, schema,
priorities and workload.

NFR-concepts

Performance Security Cost

User-Friendliness
Availability
Time Integrity
Confidentiality
Space
Response
Time Throughput Accuracy
Main Secondary Completeness
Memory Storage
InternalConsistency ExternalConsistency

Figure 10: Catalogue of some NFR terminology.

The NFR Framework also allows for acquisition and representation of knowledge about
the particular NFRs being considered. This involves gathering and cataloguing knowledge
from industry and academia, for areas such as security and performance. Part of that process
involves the statement of a terminology of concepts for the particular NFRs, as shown in
31
Figure 10.
These concepts then can be used in the systematic cataloguing of techniques (methods)
for decomposing NFRs. Methods are then made available to developers for use and reuse, or
at least as a check-list.
How do we organise methods? Goals have sorts, parameters, and priorities; methods
can rene goals along each of these dimensions. Methods are grouped into decomposition,
satiscing and argumentation methods, and can be grouped by the types of the parents and
ospring and can also be grouped into predened- and developer-dened methods. We can
form broad groups of methods for each of these axes. Smaller groups of methods are formed
by multiple inheritance, from two or more of the (somewhat orthogonal) broad groups.
In the case of performance, additional broad groups include sources of methods (e.g.,
implementation techniques from databases, object oriented systems, semantic data models
[45, 46]), issue-based layers (following [27], used to reduce the number of issues addressed at
a time; here layers are based on the data models of source and target languages), workload,
and principles for achieving responsiveness [55] (e.g., by ordering execution of operations to
respond quickly to users). This grouping is used to organise methods in the Performance
Requirements Framework [49], which is a specialisation of the NFR Framework dealing with
performance requirements. The broad groups are shown in Figure 11, starting at the left. This
multiple inheritance arrangement should help the developer in understanding, representing
and using a fairly large number of methods, since it allows gradual step-wise renement. The
groupings should help a developer focus attention on, and combine, groups of understood
methods. The gure was prepared using the Performance Requirements Assistant [49] (which
uses the Telos representation language [40] and associated translation and graphical display
software [34, 56]), which is based on the NFR Assistant [9] (which was developed using the
ConceptBase knowledge base management system [31]).
The catalogues of design techniques for achieving NFRs (e.g., Figure 12, with general
methods for condentiality starting at the top) can be compiled, and made available to
developers for use and reuse. Such techniques are collected from work done by researchers

32
 DBBasedSM

OOBasedSM

SDMBasedSM
EnititiesSM
TransactionsOrAttributesSM
LayerBasedSM
IsAHierarchiesOrAttributesSM
LongTermProcessesOrIntegrityConstraintsSM
SM WorkloadBasedSM

EarlyFixingSM
LateFixingSM
SPEBasedSM
HybridFixingSM
ExecutionOrderingSM

SortBasedSM

ParameterBasedSM

Figure 11: An hierarchy for performance satiscing methods (SMs).

33
 Confidentiality Assurance Techniques

identification virusFilter
authentication validateAccess encryption
auditing
perturbation
password
subsystem
cardKey PIN manual
compareSignature biometrics noiseAddition
requireAdditionalID valueRemoval

Figure 12: Catalogue of some design satiscing techniques for condentiality.

and practitioners in the particular areas such as security (e.g., [28]) and performance [55, 27] of
implementation of information systems [48]. Additionally, although not shown, the catalogue
of techniques for rationalising decisions can also be compiled, and made available to developers
for use and reuse. Interestingly, catalogues can deal with other NFRs, other classes of issues,
e.g., business process reengineering [62], and other phases of development, e.g., software
architecture [15].
While knowledge about rening NFRs, design techniques and rationale can be catalogued
by means of methods, knowledge about their inter-relationships can be catalogued by means
of correlation rules (Figure 13) which specify positive or negative correlations between and
among NFRs, design techniques and rationale. Also collected from work done by researchers
and practitioners in the particular areas of NFRs, the catalogue of correlation rule help analyse
trade-os among decisions.
These catalogues can serve as a resource. However, there are costs for capturing and
organising knowledge. These include costs for understanding particular non-functional re-
quirements, such as accuracy, performance and security; costs for understanding the domain
and system; and costs for understanding and recording changes. These catalogues, once de-
veloped, can speed up the process of dealing with change, as seen in Sections 3 and 4. This

34
 Technique Validate- Authentication-
NFRGoal Access rules requiringAdditionalID
Accuracy
+
Confidentiality + +
UserFriendliness -
Response Time -
Figure 13: Catalogue of some correlations.

is an important payo of the knowledge-based approach, which helps us then eectively use
the information to deal with change.

7 Tool Support: The NFR Assistant

The NFR Assistant supports the use of the NFR Framework in systematically dealing with
NFRs during the process of software development. Throughout the process, the NFR Assis-
tant helps the developer to browse, query, tailor and extend various catalogues and construct
the history record.
When using the NFR Assistant, the developer initiates the process of software development
by dening or loading an initial set of domain knowledge, including functional requirements
and non-functional requirements, for the particular application domain. The developer also
denes or loads predened NFR-specic terminology catalogues (Figure 10), method cata-
logues (Figures 11 and 12) and correlation catalogues (Figure 13) to deal with the particular
NFRs (e.g., accuracy, performance, security) being considered.
Using a catalogue of decomposition techniques which the NFR Assistant displays, the
developer then iteratively renes the top-level NFRs represented as goals into more specic
ones, while establishing relationships between NFRs (and among NFRs and links). When
desired, the developer browses design techniques in the catalogues of such techniques and
correlations, considers tradeos, selects techniques, and records rationale behind the decisions.
Developers can extend or tailor the predened catalogues, as they go along, if they are not
35
adequate or sucient for accommodating the needs of the particular organisation at hand.
During these repetitive renements, functional requirements serve as parameters of NFRs,
design techniques, and design rationale. As a result, the developer also elaborates functional
requirements as needed.
Throughout this process, NFRs, design alternatives, decisions and rationale are all organ-
ised in an history record. In the process, the developer is in full control, selectively focusing
attention and determining what part of the history record to rene next.
In addition to enabling the developer to browse and query various catalogues, the NFR
Assistant helps the developer in constructing the history record. The history record, along
with various catalogues, can be represented in a conceptual modelling language such as Telos
[40], which supports abstraction principles including classication, aggregation and special-
isation, and allows the association of various times of changes, such as creation time and
deletion time, by treating links as objects which have attributes.
When the developer selects from a catalogue a pre-dened method for a renement, the
NFR Assistant rstly generates appropriate subgoals, as well as a corresponding link, accord-
ing to the denition of the chosen method. Afterwards, the NFR Assistant infers correlations,
both positive and negative, according to the denitions in the catalogue of correlation rules.
The NFR Assistant also helps the developer with evaluation of goals. The developer can
simply assign a label to a sink (i.e., a node with no outgoing link) which indicates whether the
sink is satisced or denied. Upon the change in any label, the Assistant determines, possibly
with input from the developer, all those goals and links that are aected by such a change,
and assigns new labels to them appropriately.
To date, the NFR Assistant [9, 10] has been implemented, oering catalogues for security,
accuracy and (in a partial assistant [48, 49]) performance. These tools primarily help the
developer state and rene goals. But now, dealing with change may require operations, such
as removal of a goal, which may temporarily make the goal graph inconsistent. In Section 5, we
oered some initial guidelines for helping ensure that some syntactic and semantic structural
consistency criteria are met. In the next section, we discuss extensions to the NFR Assistant.

36
8 Discussion
8.1 Related Work
This paper extends an earlier paper [13] which described the usage of the NFR Framework
[41, 9] to deal with change. It oered an initial set of guidelines for well-formedness of historical
goal records in the presence of change. Drawing on our previous studies of attaining quality
during the development of banking systems [47, 9, 10, 11, 12, 49], it presents an initial study
of dealing with change in a bank loan system, to oer initial evidence for the usefulness of
our approach to dealing with change. It also deals with the combination of performance and
requirements for accuracy, timeliness and informativeness, in more detail than presented in
[11, 12]. We extend the paper by describing herein a process for dealing with change. We
also extend the initial set of guidelines for well-formedness of historical goal records in the
presence of change. This paper also discussed how to provide tool support in dealing with
change.
Dealing with change has been a topic of concern in software engineering [36], with increas-
ing interest from the requirements engineering community in recent years [26, 32, 38].
Work related to our approach includes work in decision support systems (e.g., [35, 52])
which in uenced the argumentation aspects of the NFR Framework. The current work adapts
the NFR Framework, hence using the ideas of design rationale. However, the current work
is distinct as it deals with changes, and utilises semantic structures, such as link types,
correlations and method instances, in guidelines for incorporating changes. The current work
also demonstrates how such structures help annotation of changes.
The change process proposed in this paper can be viewed as being complementary to the
comprehensive environment, in [50, 51], which supports process execution (based on formal
process denition), capture of traces between requirements and their sources, and experience-
based process improvement by relating the traces to the process denitions. Our change
process can benet from Pohl's environment's features for process execution and improvement,
to provide better support for systematically dealing with change using NFRs. Conversely,

37
Pohl's environment can benet from our change process' features for organising and managing
NFRs, design alternatives, tradeos, decisions and rationale, to support change driven by
NFRs. To bridge the two, a formal denition of our change process is needed.
The change process presented in this paper has NFRs as a focal point. NFRs play a role
in Sutclie's [57] conceptual framework for requirements engineering.
A large empirical study of requirements traceability is reported in [23] which involves devel-
oping and following the life of a requirement from its origin through all phases of development.
This approach is similar to ours concerning defects, such as ambiguities, omissions and con-
icts. However, we have looked at traceability with more emphasis on incorporating changes
in NFRs, and systematically detecting defects and supporting the process of corresponding
changes in designs and implementations.
The improvement paradigm of Goal-Question-Metric in the TAME project [6] is similar to
our approach in the sense that it uses the notion of goals and provides a way of argumentation
via questions. TAME can be viewed as somewhat complementary as its goals are general
requirements and it uses a collection of metrics for improvement, while our approach uses
NFRs as goals to systematically support improvement by way of decomposition, correlation
and achievement, which are all integrated into a development history record serving as the
basis for change. Metrics [18] can also play an important role in maintenance, and our work
is generally related to work in maintenance on software evolution and traceability.
Work on requirements analysis for safety-critical systems [19] shares a similar spirit with
ours in that both are concerned with NFRs and their analysis starting with organisational
needs. Coombes and McDermid's work has taken a causal reasoning approach, hence is com-
plementary to our amalgamation of qualitative reasoning from truth maintenance systems
[1] and dialectical reasoning from work on design rationale [35, 52]. The two are also com-
plementary as Coombes and McDermid's work focusses on safety and its analysis, while our
approach is directed to systematically supporting changes using NFRs.
Requirements engineering research can benet from the study of real-world systems [21].
We have benetted from this approach in reviewing editions of The Barclays Code of Business

38
Banking.
This work grows out of the earlier DAIDA environment [30] which provides support for
all phases of information system engineering. Our work extends the environment with prin-
ciples and guidelines for using NFRs to guide the software evolution process, and tools us-
ing DAIDA's knowledge base management facilities [31]. Our framework follows a decision-
oriented (as opposed to activity- or product-oriented) approach to managing software evolu-
tion [29, 53], but provides additional representation and support, and is driven by NFRs.

8.2 Future Work

Framework Extensions. Interestingly, this study has presented some support for some
extensions to the NFR Framework, particularly in representing changes in strengths of goal
achievement. Examples have arisen for both increases and decreases in strength. For exam-
ple, the organisational policy change resulted in an increase in informativeness, as well as a
decrease in performance, albeit to acceptable levels. While the framework currently has a
variety of values for goal achievement (e.g., satisced, denied, neutral, etc.), this study sug-
gests adding additional \shadings" to the existing values. For example, there could be several
degrees of satisced, and several degrees of denied. This would help us represent, for example,
situations where a requirement is initially satisced, and subsequently also satisced, but to
a greater degree. This could be viewed as adding some features of quantitative frameworks,
while, at a high level of abstraction, retaining the features of a qualitative framework [9].
Such extensions to the NFR Framework should be formalised, e.g., along the lines of [41].
This would allow us to be more precise in the use of terminology in this paper (e.g., showing
pp
shadings such as \ " or \++") which represent extensions to the label and link types dened
in [41].
Currently, dierent strengths of relationships and goal achievement would be informally
taken care of by the developer who uses the interactive label propagation algorithm. The
framework could also provide a convenient notation for re ecting changes made over time; a
corresponding graphical notation would be helpful for tools for display purposes.

39
 The guidelines are organised by the structure of a goal graph. When the guidelines are
suitably formalised, we could envisage demonstrations of correctness by structural induction
on the goal graph and a formal verication that the labelling algorithm generates a unique
and consistent assignment of labels.

Tool Extensions. Some extensions are also needed to the NFR Assistant (Section 7),
a tool intended to help developers use the NFR Framework. The tool should provide support
to distinguish new goals and links from old ones in a goal graph, and extract the dierences
between the old and new goal graphs.
The tool should also be extended to support our guidelines, rst by detecting violations
of the properties of Section 5.1, and then by informing the developer of goals, links and labels
which should be adjusted according to the guidelines of Section 5.2. Support for re ecting
changes from the domain (Section 5.3) should also be considered.
While we have presented in Section 5 some guidelines for dealing with individual operations
on goal graphs, it would also be helpful to determine some commonly-arising sequences of
operations, and then oer such sequences as atomic operations in a tool.
In using the NFR Assistant's semi-automatic approach, developers direct the overall de-
velopment process, select focus, choose or supplement pre-dened methods and correlation
rules, provide rationale, and use their own expertise about the domain and the NFRs. We
feel there is a need to oer active guidance or a model for process enactment, for example, as
described in [50].
Considering the vast amount of informal descriptions, sometimes loosely connected to one
another, we feel that this study suggests the need for even more structure to argumentation,
perhaps by way of a model of organisation which provides a rich ontology, as presented, for
example, in [59, 60, 64]

Studies. Further studies of real systems could be made, in order to illustrate more of
the cases of the guidelines presented in Section 5. Studies would also help determine how
easily the framework and its notation can be learned and applied by practitioners, as raised

40
by experts in other domains (governmental and medical computing) who reviewed some of
our previous studies of dealing with NFRs [14].

9 Conclusions
Our overall long-term goals are to help developers deal with change. This involves oering
support for dealing with quality requirements, decreasing developers' eort (by decreasing
development time and cost), and oering schemes for concise representation as well as as-
sistance in reasoning. Our approach had been to take an existing framework [9, 41, 16] for
dealing with quality requirements, and then provide a set of guidelines stating the mechanics
of incrementally dealing with changes in the context of the framework. Our study of change
in a banking environment shows that the framework's historical records provide a concise way
to dealing with change while considering quality requirements.

Our Observations in this Study. In dealing with change in this study, we reviewed two
editions of the Barclays Codes of Business Banking. In some cases we supplemented them
with a little creativity; in addition, the results of this study have not been reviewed by the
bank; as a result, the particular conclusions of this study are not necessarily what the bank
would do.
We identied some initial top-level requirements for a variety of NFRs including informa-
tiveness, performance, timeliness, etc. We considered changes in NFRs as well as associated
changes in priorities, workload, functionality and target-system techniques.
Using the approach involving historical records, we rst captured the \initial" system.
Then we considered the changes in the bank's policy manual. By reviewing and revising the
historical records, we found that we were able to quickly represent and deal with changes.
We were able to record changes in design rationale, and deal with interactions and changed
tradeos, which arose from the changes. By using prioritisation of goals, we were able to
focus on priorities during change, helping deal eectively with tradeos. We then were able
to determine the overall impact of changes, including the impact on meeting NFRs for the

41
changed system.
Our treatment of initial and revised requirements was aided by the use of method cat-
alogues. Our study drew on catalogues developed as parts of specialisations of the NFR
Framework to deal with the particular NFRs of accuracy, security and performance.

Expressing Change in Historical Records. We considered both the sources of change

and the eects of change. In the historical record, we considered changes in goals, changes in
the priority (criticality or dominance) of goals, changes in decisions, and changes in rationale.
This involved identifying important changes, determining their potential impact on quality
issues, and incorporating the impact through the process of improvement.
Our operations in dealing with change on the goal graphs (going from Figure 4 to subse-
quent gures) have mainly involved (See Section 5):
 adding a new goal (e.g., due to changes in organisational policies);
 revising an existing interaction (e.g., correlations; labelling);
 considering new interactions;
 (re-) considering alternative target systems (e.g., methods);
 providing arguments for the chosen system, e.g., based on the organisation's workload,
such as the number of clients.
In our experience in conducting this study, this process was quite rapid: there was little
additional material to add to the graph; and of the new material, some of the bookkeeping
(e.g., some correlation and labelling) can be handled automatically. This kind of saving
helps the developer to focus on the domain and the quality requirements. We feel that a
main reason for this saving is that the NFR Framework captures underlying structure and
real-world knowledge (Cf. [24, 25, 43]), which is needed, used, and re-used.

Contributions. More specically, our approach leads to the following benets:

42
  changes in NFRs are representable, thanks to knowledge-based approach which enables
capturing concepts central to dealing with NFRs, both initial and subsequent ones;
 incorporating change is conceptually simple, thanks to the use of the same structure for
developing and recording both the initial goal graph and its subsequent revisions;
 incremental change is dealt with quickly, thanks to the NFR Framework's provisions for
encoding NFR-specic information to relate new requirements to old ones, and to nd
correlations among the new requirements.
 identifying the needed change is less time-consuming and less costly, thanks to the
already encoded goals and their interactions. By consulting the initial goal graph, a
developer dealing with change can detect patterns in goal graphs, and reduce searches of
large volumes of documentation whose references to quality have already been captured
in the initial goal graph.
The NFR Framework is good for dealing with change, because it inherently deals with
alternatives in a goal-oriented way. When there is change, some other alternative becomes
appropriate because of the new circumstances. Managing change in terms of the means-ends
(alternatives-goals) linkages is an important dimension because the underlying interactions are
captured. Most work on change and software evolution deals with the historical or temporal
dimension, e.g., versioning and conguration management.
Future work would explore the interaction of the means-ends reasoning dimension with
these other dimensions in dealing with change. The idea of applying means-ends reasoning to
deal with change is also the basis for a framework for process reengineering [60, 61, 62, 63],
where a combination of functional and non-functional means-ends reasoning is used to support
process re-design.
Work is also needed to extend notations for change, and suitably formalise them. Further
tool support for the change process would aid developers. Another avenue of future work con-
cerns the change process. Further studies of real systems should be made, with participation
and feedback from practitioners, in order to discover both its strengths and weaknesses.
43
Acknowledgments. Our appreciation to Anthony Finkelstein, Stephen Fickas and Martin
Feather for selecting and providing a copy of the Barclays Code of Business Banking for use as
a common example at the Workshop on Research Issues in the Intersection between Software
Engineering and Articial Intelligence, Sorrento, Italy, May 1994. Our sincere gratitude for
all his help to Tim Baxter of Barclays Bank in London who provided us with the current
edition of the Code. We thank the anonymous referees for their helpful comments. Our
gratitude to the journal's editor Peri Loucopoulos and assistant Janet Houshmand for all
their work in guiding this paper through the publication process. We thank the referees of
the earlier conference paper for their helpful suggestions. Our gratitude to Professor John
Mylopoulos for his ongoing help in this work. Our families have been a constant source of
love and support.

References
[1] Articial Intelligence Journal, Special Issue on Qualitative Reasoning, vol. 24, nos. 1{3,
Dec., 1984.
[2] Barclays Bank PLC, The Barclays Code of Business Banking. London, England, eective
31st Jan. 1992.
[3] Barclays Bank PLC, The Barclays Code of Business Banking. London, England, May
1993.
[4] Barclays Bank PLC, Annual Review & Summary Financial Statement, London, England,
1993.
[5] Barclays Bank PLC, Report and Accounts, London, 1993.
[6] V. R. Basili and H. D. Rombach, \The TAME Project: Towards Improvement-Oriented
Software Environments," IEEE Trans. on Software Eng., vol. 14, no. 6, June 1988, pp.
758{773
[7] L. Chung, \Representation and Utilization of Non-Functional Requirements for Informa-
tion System Design." In R. Anderson, J. A. Bubenko, Jr., A. Slvberg (Eds.), Advanced

44
 Information Systems Eng., Proc., 3rd Int. Conf. CAiSE '91, Trondheim, Norway, May
13{15, 1991. Berlin: Springer-Verlag, 1991, pp. 5{30.
[8] K. L. Chung, P. Katalagarianos, M. Marakakis, M. Mertikas, J. Mylopoulos, Y. Vas-
siliou, \From Information System Requirements to Designs: A Mapping Framework."
Information Systems, Vol. 16, No. 4, September{October 1991, pp. 429{461.
[9] K. L. Chung, Representing and Using Non-Functional Requirements: A Process-Oriented
Approach. Ph.D. Thesis, Dept. of Computer Science, Univ. of Toronto, June 1993. Also
Technical Report DKBS{TR{93{1.
[10] L. Chung, \Dealing With Security Requirements During the Development of Information
Systems." In C. Rolland, F. Bodat and C. Cauvet (Eds.), Advanced Information Systems
Eng., Proc., 5th Int. Conf. CAiSE '93, Paris, France, June 8{11, 1993. Berlin: Springer-
Verlag, 1993, pp. 234{251.
[11] L. Chung, B. A. Nixon and E. Yu, \Using Quality Requirements to Drive Software
Development." Workshop on Research Issues in the Intersection Between Software Eng.
and Articial Intelligence, Sorrento, Italy, May 1994.
[12] L. Chung, B. A. Nixon and E. Yu, \Using Quality Requirements to Systematically De-
velop Quality Software." Proc. 4th Int. Conf. on Software Quality, McLean, VA, U.S.A.,
October 3{5, 1994.
[13] L. Chung, B. A. Nixon and E. Yu, \Using Non-Functional Requirements to Systemat-
ically Support Change." Proc., 2nd Int. Symp. on Requirements Eng., York, England,
March 27{29, 1995, pp. 132{139.
[14] L. Chung, B. A. Nixon, \Dealing with Non-Functional Requirements: Three Experimen-
tal Studies of a Process-Oriented Approach." Proc., 17th ICSE, Seattle, WA, U.S.A.,
Apr. 1995, pp. 25{37.
[15] L. Chung, B. A. Nixon and E. Yu, \Using Non-Functional Requirements to Systemat-
ically Select Among Alternatives in Architectural Design." Proc. 1st Int. Workshop on
Architectures for Software Systems, Seattle, Washington, Apr. 1995, pp. 31{43.

45
[16] L. Chung, B. A. Nixon, E. Yu and J. Mylopoulos, Non-Functional Requirements in
Software Engineering. Forthcoming monograph, 1997.
[17] D. D. Clark and D. R. Wilson, \A Comparison of Commercial and Military Computer
Security Policies," Proc. IEEE Symp. on Security and Privacy, 1987, pp. 184{194.
[18] D. Coleman, D. Ash, B. Lowther and P. Oman, \Using Metrics to Evaluate Software
System Maintainability." IEEE Computer, vol. 27, no. 8, Aug. 1994.
[19] A. C. Coombes and J. A. McDermid, \Using Qualitative Physics in Requirements Spec-
ication of Safety Critical Systems | A Potential AI User's Perspective." Workshop on
Research Issues in the Intersection Between Software Eng. and Articial Intelligence,
Sorrento, Italy, May 1994.
[20] B. Curtis, H. Krasner and N. Iscoe, \A Field Study of the Software Design Process for
Large Systems." Comm. of the ACM, vol. 31, no. 11, Nov. 1988, pp. 1268{1287.
[21] S. Fickas, \Desert Island Column," Automated Software Eng., Vol. 1, No. 1, Mar. 1994,
pp. 141{146.
[22] A. C. W. Finkelstein and S. J. M. Green, Goal-oriented Requirements Engineering. Tech.
Rept TR{93{42, Imperial College (London Univ.), forthcoming.
[23] O. C. Z. Gotel and A. C. W. Finkelstein, An Analysis of the Requirements Traceability
Problem. Proc. Int. Conf. on Requirements Eng. Colorado Springs, 1994.
[24] S. J. Greenspan, J. Mylopoulos and A. Borgida, \Capturing More World Knowledge
in the Requirements Specication." Proc. 6th Int. Conf. on Software Eng., 1982, pp.
225{234.
[25] S. Greenspan, J. Mylopoulos and A. Borgida, \On Formal Requirements Modeling Lan-
guages: RML Revisited." Proc. 16th ICSE, Sorrento, Italy, May 1994, pp. 135{147.
[26] S. D. P. Harker, K. D. Eason and J. E. Dobson, \The Change and Evolution of Require-
ments as a Challenge to the Practice of Software Engineering." Proc. of the IEEE Int.
Symp. on Requirements Eng., San Diego, CA, Jan. 4{6, 1993. Los Alamitos, CA: IEEE
Computer Society Press, 1992, pp. 266{272.

46
[27] William F. Hyslop, Performance Prediction of Relational Database Management Sys-
tems. Ph.D. Thesis, Dept. of Computer Science, Univ. of Toronto, 1991.
[28] European Communities, Information Technology Security Evaluation Criteria, Provi-
sional Harmonised Criteria, Version 1.2, June 1991, Luxembourg.
[29] M. Jarke and T. Rose, \Managing Knowledge about Information System Evolution."
Proc. SIGMOD '88, Chicago, May 1988, pp. 303{311.
[30] M. Jarke, J. Mylopoulos, J. W. Schmidt, Y. Vassiliou, \DAIDA: An Environment for
Evolving Information Systems," ACM Trans. on Information Systems, vol. 10, no. 1,
Jan. 1992, pp. 1{50.
[31] M. Jarke (Ed.), ConceptBase V3.1 User Manual. Univ. of Passau, 1992.
[32] M. Jarke, K. Pohl, \Requirements Engineering in the Year 2001: On (Virtually) Man-
aging a Changing Reality," Workshop on System Requirements: Analysis, Management,
and Exploitation, Schlo Dagstuhl, Saarland, Germany, October 4{7, 1994.
[33] J. M. Juran, F. M. Gryna Jr., and R. S. Bingham Jr. (Eds.), Quality Control Handbook,
3rd Ed., New York: McGraw-Hill, 1979.
[34] Bryan M. Kramer, RepBrowser tool and documentation, Dept. of Computer Science,
University of Toronto, 1995.
[35] J. Lee, Extending the Potts and Bruns Model for Recording Design Rationale. Proc. 13th
Int. Conf. on Software Eng., Austin, Texas, May 1991, pp. 114{125.
[36] M. M. Lehman and L. A. Belady. Program Evolution: Processes of Software Change.
London: Academic Press, 1985.
[37] P. Loucopoulos and V. Karakostas, System Requirements Engineering. McGraw-Hill,
1995.
[38] Nazim Madhavji, Panel on \Impact of Environmental Evolution on Requirements
Change." In Proceedings of the Third IEEE International Symposium on Requirements
Engineering, Annapolis, MD, U.S.A., Jan. 6{10, 1997, pp. 98{99.

47
[39] T. J. McCabe and G. G. Schulmeyer, \The Pareto Principle Applied to Software Quality
Assurance," In G. G. Schulmeyer and J. I. McManus (Eds.) Handbook of Software Quality
Assurance, New York: Van Nostrand Reinhold, 1987, pp. 178{210.
[40] J. Mylopoulos, A. Borgida, M. Jarke, and M. Koubarakis, Telos: Representing Knowl-
edge about Information Systems, ACM Trans. on Information Systems, vol. 8, Oct. 1990,
pp. 325{362.
[41] J. Mylopoulos, L. Chung, B. Nixon, \Representing and Using Non-Functional Require-
ments: A Process-Oriented Approach." IEEE Trans. on Software Eng., Special Issue on
Knowledge Representation and Reasoning in Software Development, Vol. 18, No. 6, June
1992, pp. 483{497.
[42] J. Mylopoulos, L. Chung, E. Yu and B. Nixon, Requirements Engineering 1993: Selected
Papers. Tech. Rept. DKBS{TR{93{2, Dept. Computer Science, Univ. of Toronto, July
1993.
[43] J. Mylopoulos, A. Borgida, and E. Yu, \Representing Software Engineering Knowledge,"
Automated Software Engineering, to appear, vol. 4, no. 3, July 1997.
[44] N. Nilsson, Problem-Solving Methods in Articial Intelligence. New York, McGraw-Hill,
1971.
[45] B. A. Nixon, K. L. Chung, David Lauzon, Alex Borgida, J. Mylopoulos and Martin
Stanley, Design of a Compiler for a Semantic Data Model. In Joachim W. Schmidt
and Costantino Thanos (Editors), Foundations of Knowledge Base Management. Berlin:
Springer-Verlag, 1989, pp. 293{343.
[46] B. Nixon, \Implementation of Information System Design Specications: A Performance
Perspective." In P. Kanellakis and J. W. Schmidt (Eds.), Database Programming Lan-
guages: Bulk Types & Persistent Data | The 3rd Int. Workshop. Aug. 1991, Nafplion,
Greece. San Mateo, CA: Morgan Kaufmann, 1992, pp. 149{168.
[47] B. A. Nixon, \Dealing with Performance Requirements During the Development of In-
formation Systems." Proc. of the IEEE Int. Symp. on Requirements Eng., San Diego,
CA, Jan. 4{6, 1993. Los Alamitos, CA: IEEE Computer Society Press, 1992, pp. 42{49.
48
[48] B. A. Nixon, \Representing and Using Performance Requirements During the Develop-
ment of Information Systems." In M. Jarke, J. Bubenko, K. Jeery (Eds.), Advances in
Database Technology - EDBT '94, Proc. 4th Int. Conf. Extending Database Technology,
Cambridge, U.K. Berlin: Springer-Verlag, 1994, pp. 187-200.
[49] B. A. Nixon, \Dealing with Performance Requirements for Information Systems."
Ph.D. thesis draft, Dept. of Computer Science, University of Toronto, Dec. 1996.
[50] K. Pohl, A Process Centered Requirements Engineering Environment. Ph.D. Dissertation,
Informatik V, RWTH-Aachen, Germany, Feb. 1995.
[51] Klaus Pohl, Process-Centered Requirements Engineering. Research Studies Press Ltd.
New York: John Wiley & Sons Inc., 1996.
[52] C. Potts and G. Bruns, Recording the Reasons for Design Decisions, Proc. 10th ICSE,
1988, pp. 418{427.
[53] C. Rolland \Modeling the evolution of artifacts." Proc. Int. Conf. on Requirements En-
gineering, Colorado Springs, Colorado, U.S.A., Apr. 1994.
[54] H. A. Simon, The Sciences of the Articial, 2nd Edition. Cambridge, MA: The MIT
Press, 1981.
[55] C. U. Smith, Performance Engineering of Software Systems. Reading, MA: Addison-
Wesley, 1990.
[56] Martin T. Stanely, Telos sh tool and documentation, Dept. of Computer Science, Uni-
versity of Toronto, 1995.
[57] A. Sutclie, \A Conceptual Framework for Requirements Engineering." In Requirements
Engineering, Vol. 1, No. 3, 1996, pp. 170{189.
[58] U.S. Dept. of Defense, Trusted Computer Systems Evaluation Criteria, DOD 5200.28{
STD, Dec. 1985.
[59] E. Yu, Modelling Organizations for Information Systems Requirements Engineering.
Proc. of the IEEE Int. Symp. on Requirements Eng., San Diego, CA, Jan. 4{6, 1993.
Los Alamitos, CA: IEEE Computer Society Press, 1992, pp. 34{41.

49
[60] E. S.K. Yu and J. Mylopoulos, \Understanding `Why' in Software Process Modelling,
Analysis, and Design." Proc. 16th Int. Conf. on Software Engineering, Sorrento, Italy,
May 1994, pp. 159{168.
[61] E. Yu and J. Mylopoulos, \From E-R to `A-R' { Modelling Strategic Actor Relation-
ships for Business Process Reengineering," Int. Journal of Intelligent and Cooperative
Information Systems, vol. 4, nos. 2 & 3, 1995, pp. 125-144.
[62] E. Yu, Modelling Strategic Relationships for Process Reengineering. Ph.D. Thesis, Dept.
of Computer Science, Univ. of Toronto, 1995. Also Technical Report DKBS{TR{94{6.
[63] E. Yu, J. Mylopoulos, and Y. Lesperance, \AI Models for Business Process Reengineer-
ing", IEEE Expert, August 1996, pp. 16-23.
[64] E. Yu, \Towards Modellinge and Reasoning Support for Early-Phase Requirements En-
gineeering." In Proceedings of the Third IEEE International Symposium on Requirements
Engineering, Annapolis, MD, U.S.A., Jan. 6{10, 1997, pp. 226{235.

50