Information and Software Technology 49 (2007) 1162–1171

www.elsevier.com/locate/infsof

Modelling non-functional requirements of business processes

Faisal Aburub ¤, Mohammed Odeh, Ian Beeson
Faculty of Computing, Engineering, and Mathematical Sciences, University of the West of England (UWE), Coldharbour Lane,
Frenchay, Bristol BS16 1QY, United Kingdom

Received 2 December 2005; received in revised form 15 December 2006; accepted 19 December 2006
Available online 29 December 2006

Abstract

This paper presents an approach to the identiWcation and inclusion of ‘non-functional’ aspects of a business process in modelling for
business improvement. The notion of non-functional requirements (NFRs) is borrowed from software engineering, and a method devel-
oped in that Weld for linking NFRs to conceptual models is adapted and applied to business process modelling. Translated into this
domain, NFRs are equated with the general or overall quality attributes of a business process, which, though essential aspects of any
eVective process, are not well captured in a functionally oriented process model. Using an example of a healthcare process (cancer regis-
tration in Jordan). We show how an analysis and evaluation of NFRs can be applied to a process model developed with role activity dia-
gramming (RAD) to operationalise desirable quality features more explicitly in the model. This gives a useful extension to RAD and
similar modelling methods, as well as providing a basis for business improvement.
© 2007 Elsevier B.V. All rights reserved.

Keywords: Non-functional requirements; Business process modelling; Role activity diagramming; Business process improvement

1. Introduction ing, these methodologies have a functional emphasis, and

Organisations exert great eVorts to carry out their busi-
ness processes in a way which meets functional require-
ments but also produces good overall or general quality of
service. Borrowing terminology from software engineering,
it might be appropriate to term these general quality attri-
butes ‘non-functional requirements’. It would be useful to
have a method of representing these attributes, so that they
are modelled more explicitly. Such a method might assist
organisations to improve the quality of their business
processes.
Many methodologies [4,7,8,10,15,17] have been devel-
oped to improve business processes and to investigate how
well current business processes have achieved their goals.
Techniques used to model business processes have included
IDEF, Petri Nets, role activity diagrams (RADs), Role
Interaction Diagrams, and Gantt Charts. Generally speak-
*
Corresponding author. Tel: +44 117 328 3343; fax: +44 117 328 2587.
E-mail address: faburub@uop.edu.jo (F. Aburub).
concentrate on showing the detail of how activities are car-
ried out or tasks executed. There has been little attempt to
model properties which apply to a process as a whole rather
than to elements of it.
This paper presents an approach to applying the concept
of non-functional requirements (NFRs) to business process
modelling, developing in particular an extension to role
activity diagramming.
According to Kotonya and Sommerville [9] non-func-
tional requirements can be deWned (from the system point
of view) as “restrictions or constraints placed on a system
service”. Adapting this idea to business processes, and cast-
ing it in a more positive formulation, we can regard an
NFR for a business process as a desirable general property
or quality attribute of a process. Two dimensions of NFRs
for business processes can be identiWed. First, direct-service
qualities represent qualities introduced directly to the cus-
tomers, as for example, service-time, responsiveness, or
empathy. Second, indirect-service qualities represent general
qualities that enable staV members perform their responsi-
bilities eYciently and eVectively, such as system users satis-

0950-5849/$ - see front matter © 2007 Elsevier B.V. All rights reserved.
doi:10.1016/j.infsof.2006.12.002
 F. Aburub et al. / Information and Software Technology 49 (2007) 1162–1171
faction and information availability. The latter do not
produce value for customers directly but enable delivery of
direct-service qualities.
A method is developed below for representing NFRs
and linking them to a RAD model, using a speciWc business
process in healthcare, namely cancer registration in Jordan,
for illustration. The application of role activity diagram-
ming to the cancer registration process is shown method,
followed by the method for developing and linking NFRs.
2. Process modelling using role activity diagrams (RADs)
According to Ould [13] a process is “a coherent set of
actions carried out by a collaborating set of roles to achieve
a goal”. Pidd [14] deWnes a model as “an external and
explicit representation of part of reality as seen by the peo-
ple who wish to use that model to understand, to change, to
manage and to control that part of reality”. Therefore, the
main purpose for modelling is to express, represent, under-
stand, or manage a certain process. According to Lin et al.
[11], one of the most important objectives of process model-
ling is to capture existing processes by structurally repre-
senting their activities and related elements. Process
modelling should facilitate comprehensive understanding
of organisational processes. Because business processes are
usually complex, as for example in banking or healthcare
processes, techniques to express, specify, understand, and
model characteristics of these processes need to be suY-
ciently powerful and Xexible, while retaining comprehensi-
bility.
RADs [13] are diagrammatic notations to represent
and model coordinated behaviour and interactions within
a process. According to Ould [13], “RAD shows the roles
that play a part in the process, and their component
actions and interactions, together with external events
and the logic that determines which actions are carried
out when. So, it shows the activity of roles in the process
and how they collaborate”. RADs can be used to give a
visual representation of the roles of all players in a busi-
ness process, and of the interactions between the roles.
According to Giaglis [5], the adoption of role as a primary
unit of analysis makes RADs particularly suitable for
modelling organisational contexts. Saven [16] adds that
the depiction of interactions brings communication
aspects of a process to the fore and makes RAD models
easy to read and understand. In comparison with UML
Activity Diagrams, we see RADs as at the same time con-
ceptually simpler, and more strongly oriented towards
business, as distinct from software, processes.
In a RAD, a role involves a sequence of activities which
are carried out together within a particular responsibility.
“Roles are abstract notations of behaviour describing a
desired behaviour within the organisation. They can also
include software systems, customers and suppliers”, [16].
Each role is represented in a RAD as a named bounded
area containing activities, interactions, and logical ele-
ments. Activities are represented as black boxes. Fig. 1
1163
shows an example. Vertical lines linking activities and inter-
actions within a role represent states of the role. Concurrent
activities in a role can be represented using up-pointing tri-
angles, and alternative activities shown using down-point-
ing triangles. Interactions are represented by horizontal
lines linking boxes in diVerent roles; a shaded box shows
where the interaction is initiated, and a white box shows the
receiving end.
3. A RAD model of the process of cancer registration
We will use the process of cancer registration as an illus-
trative example. The Wrst author studied the administration
of cancer care in Jordan as part of his Ph.D. research, under
the supervision of the other two authors.
Cancer registration (CR) is the systematic collection and
classiWcation of data on all types of cancers and persons
diagnosed with cancer. Cancer registries aim to determine
the distribution of cancer, monitor the growth of cancer per
cancer type, evaluate the current treatment process, and
monitor patient survival rates. Cancer registration is part of
a wider process of cancer care. Cancer control needs a high
degree of collaboration between cancer centres and cancer
registries.
The cancer registration process in Jordan is managed by
the Jordan cancer registry (JCR) which tracks malignant
and some benign cancer cases [12]. The JCR is the oYcial
(and only) cancer registry in Jordan. The CR process, in
Jordan as elsewhere, involves activities and high levels of
interaction among many individuals and groups within sev-
eral organisations.
The CR process in Jordan was studied as part of a
wider modelling of cancer care and registration which
focused on activities and interactions within hospitals and
between hospitals and the JCR. Cancer registration (CR)
is chosen here as a self-contained subprocess within the
more general context of cancer care, which provides suY-
cient illustration for the purposes of the present paper.
The investigation at the JCR included observation and
some participation in its work, as well as interviews with
managers and staV.
The main roles involved in the CR process in Jordan are:
(1) JCR (Jordan cancer registry); (2) Laboratories; (3) Reg-
istrars; (4) Health Sector. The laboratories and registrars
are located in individual hospitals. Table 1 brieXy describes
the roles, activities and interactions involved in this process.
A RAD model of the process of cancer registration is
shown as Fig. 1.
4. NFRs in business processes
Non-functional requirements (NFRs), sometimes
termed quality, or quality of service, attributes or require-
ments, have been a topic of interest within systems engi-
neering, software engineering, and requirements
engineering for a considerable period of time [1,3,6,9].
Gilb’s inXuential treatment of them [6] dates back
1164 F. Aburub et al. / Information and Software Technology 49 (2007) 1162–1171

JCR
Registrar
(Medical Records) Laboratory

Send form to JCR Send different forms to JCR

Change laboratory’s
form into JCR form
Check forms

Compare primary cancer site with its

ICD -O code
N Y
Mismatch ?
Return the form to hospital Return the form to laboratory

Check if patient exists in the JCR DB

Y N
Does patient exist in JCR database?

Check if the primary cancer Add patient to

site exists in the JCR DB JCR database

N Y
Does primary cancer site
exist in JCR database? Add primary cancer
site to JCR database

Add primary cancer site to JCR database

Y N
Is there additional
data ?

Modified patient’s file

Save form in JCR

archive
At end of year

Analyse the JCR DB which

is collected in the last year

Generate statistical
reports
Healthcare Sector

Send reports to all Healthcare Sectors

Comparing the report on the

regional level

Fig. 1. RAD model of the cancer registration process.

20 years. NFRs are those general qualities of a software problematic to specify, and also to measure. Nevertheless,
(or other engineered) system, such as reliability, perfor- much eVort has been expended in incorporating NFRs in
mance, or scalability, which refer to the system as a whole modern software development methods, including those
rather than to speciWc functional capabilities. They are using UML modelling [19].
 F. Aburub et al. / Information and Software Technology 49 (2007) 1162–1171 1165

Table 1
The cancer registration process: roles, activities and interactions
Goal: collection and classiWcation of cancer control data
Role Activities Interactions
JCR Checking forms, checking if patient and primary cancer site exist in JCR database, saving Registrar (Medical Records),
new cases and new primary cancer sites, generating annual reports, and comparing these Laboratory, Health Sectors
reports regionally
Laboratory Sending JCR form JCR
Registrar Sending JCR form JCR
Health Sector Receive reports JCR

Functional View

RAD
Activities Interactions Roles

Creating,
Business Creating, Creating,
Business modifying, modifying, modifying,
Process and/or
Process removing
and/or and/or
Model removing removing
activities interactions roles

Analysis of NFR

NFR Graph
Non-Functional View

Fig. 2. Linking the non-functional to the functional view.

While these methods are particularly associated with
software or systems engineering, related ideas in the Weld
of quality function deployment (QFD) are capable of
broader application in systematically mapping customer
needs into the Wnal engineering speciWcation of a product
or service.
Learning from these approaches to NFRs, and using
them analogically, we suggest it will be useful to identify
and model desirable qualities or properties of business
processes in general. The objective is not so much to
design a technical system, or a product, but to under-
stand and model the quality attributes of the business
itself. If this can be done eVectively, it might point the
way to improvements which could be made in the busi-
ness processes.
We have developed an approach which models business
process NFRs and links them to RAD models of the pro-
cesses. Our way of proceeding is to model the NFRs of a
process and map the NFR model to the functional process
model represented by the RADs. EVectively, the NFR
model is applied to the functional model by using it to iden-
tify activities, interactions, and roles in the functional
model which could usefully be modiWed to deliver or serve
the NFRs better.
The production of NFRs is essentially a top-down pro-
cess which starts from consideration of general qualities or
desirable attributes of the business as a whole. These are
seen as ‘goals’ for the business, from which sub-goals can
be methodically derived. Modelling the business via RADs,
by contrast, proceeds in a bottom-up direction, identifying
activities and interactions taking place in the business and
representing them as a set of interacting roles. Fig. 2 illus-
trates the general approach. The RAD and NFR modelling
are independent of one another; by bringing them together,
activity- and goal-focused views of the business can be inte-
grated, to provide a basis for the critique and improvement
of the business processes. Systematic matching of the NFRs
against the functional process model might reveal omis-
sions or superXuities in the processes which could indicate
where improvements might be made.
The method will be explored in detail in the next section,
and applied to the cancer registration process, so see if it
can be improved.
4.1. A Method for modelling business process NFRs
We have adapted a software engineering approach
derived from Cysneiros and Chung and their respective col-
leagues [3,1,2] as an immediate model for representing and
decomposing NFRs and resolving conXicts between goals.
Applying their approach to the present purpose of analys-
ing and improving a business process, we propose a six-step
method:
(1) Elicit NFRs and decompose them into subgoals.
(2) DeWne relationships between goals and subgoals.
(3) Identify actors who will achieve NFRs (goals).
(4) Operationalise goals.
(5) Analyse positive and negative interactions between
goals.
(6) Select which NFRs to address to achieve process
improvement.
1166 F. Aburub et al. / Information and Software Technology 49 (2007) 1162–1171
4.1.1. Elicit NFRs and decompose them into subgoals
Elicitation of NFRs can proceed through examination
of academic literature or business documents, but the most
fruitful approach is likely to be observing or interviewing
people involved in the business process under investigation.
In the CR process, one non-functional requirement which
appears critical is “quality of information”.
NFRs can be thought of as goals, and an NFR can often
be decomposed into sub-goals, whose satisfaction will lead
to satisfying the ultimate goal ([2,9], and see Fig. 3). And/or
trees can be used to represent a decomposition into subgo-
als. The root of the tree represents the original NFR (par-
ent goal).
The NFR “quality of information” might be decom-
posed into (1) completeness of clinical information and (2)
accuracy of information (Fig. 4). To determine when a goal
or subgoal is satisWed requires identiWcation of measures of
satisfaction for each. What the appropriate measure of sat-
isfaction is will depend on the type of goal and the context.
For example, to satisfy a ‘quality of information’ NFR in
cancer registration will require a diVerent measure from a
similarly deWned NFR in banking.
In the CR context, Skeet [18] states completeness of
information can be accomplished in two ways: (1) com-
pleteness of cover, and (2) completeness of detail. He fur-
ther suggests that accuracy of information can be
accomplished through: (1) accuracy of detail, (2) accuracy
NFR1
Sub-goal1 ………………….. Sub-goal n
Fig. 3. Goal approach for NFRs.
Cancer Registration
Process
Quality of Information
Completeness Accuracy of
of Information Information
Fig. 4. Subgoals of ‘quality of information’.
of reporting, and (3) accuracy of interpretation. Satisfying
the completeness and accuracy goals will depend on Wnding
measures for satisfying their respective subgoals.
4.1.2. DeWne relationships between goals and subgoals
The relationship between a parent NFR and its oVspring
(subgoals) can be represented as AND- or OR-relation-
ships. In an AND-relationship, depicted by a single arc
across the parent-child connecting lines, the parent will be
satisWed if only if all its oVspring are satisWed (Fig. 5).
In an OR-relationship, depicted by a double arc across
the parent-child connecting lines, the parent goal is satisWed
if one of its oVspring is satisWed (Fig. 6).
4.1.3. Identify actors who will achieve NFRs (goals)
Identifying actor(s) who should be responsible to
achieve the identiWed NFRs will help to link the non-func-
tional view with the functional view, since at the end we
need to relate the NFR model with the functional process
model. We simply annotate the NFR graph with the name
of the responsible actor (Fig. 7).
4.1.4. Operationalise goals
In order for goals to be satisWed, some operation needs
to be put in place. Goals can be operationalised in two
ways, statically or dynamically [3]. Static operationalisation
refers to the provision of data to satisfy an NFR, while
dynamic operationalisation refers to the carrying out of
actions to satisfy an NFR. In modelling NFRs, static oper-
ationalisation can be represented using a dotted circle, and
Cancer Registration
Process
Quality of Information
Completeness Accuracy of
of Information Information
Fig. 5. Completeness AND accuracy.
Fig. 6. OR-relationship.
 F. Aburub et al. / Information and Software Technology 49 (2007) 1162–1171 1167

Process: Cancer Registration population and (2) by avoiding the inadvertent dupli-
cation of patients [18],
Actor: Cancer Registry
(b) to ensure completeness of details, both personal and
clinical information should be complete; and incom-
plete forms need to be returned to source.
Quality of Information
These operationalisations are shown in Fig. 8.

4.1.5. Analyse positive and negative interactions between

Completeness Accuracy of
of Information Information
Fig. 7. An actor for ‘quality of information’.
dynamic operationalisation using a bold circle. An arrow is
used to show that satisfaction of a subgoal leads to satisfac-
tion of the parent goal.
For example, completeness of information might be one
of the subgoals of a ‘quality of information’ NFR. The sub-
goal can be further reWned into (1) completeness of cover
and (2) completeness of detail subgoals. These second level
subgoals can be operationalised as follows:
(a) completeness of cover can be achieved in two ways:
(1) by registering every cancer case within a deWned
goals
When qualities (NFRs) are collected for a business pro-
cess, some of them may be found to conXict with each other
while others appear to complement or strengthen one
another.
For example, validation of information in cancer registries
may conXict with conWdentiality of access to information.
But validation of information is likely to complement accu-
racy of information. On the NFR diagrams, dotted lines
marked by a plus or minus sign are used to represent positive
and negative interactions. An example is shown in Fig. 9.
Process redesigners can use the model to identify the
most beneWcial operationalised goals with least conXict.
They can use the diagrams as a basis for performing a
trade-oV analysis, which will indirectly reXect on the func-
tional view of the overall business process.
Cysneiros et al. [3] propose a procedure for linking an
NFR network to a conceptual model. We can adapt this to
business process modelling as follows:

Process: Cancer Registration

Actor: Cancer Registry

Quality of Information

Completeness of Accuracy of
Information Information

Completeness of Completeness of
cover details

Register every Avoid duplications Complete Complete Return incomplete

cancer case of patients personal clinical form to its source
information information

Fig. 8. Dynamic and static operationalisations.

1168 F. Aburub et al. / Information and Software Technology 49 (2007) 1162–1171

Process : Cancer Registration

Actor : Cancer Registry

Quality of Information Confidentiality

Validation of +
Information
- Security ( access
Accuracy of
Information to information)

Consistency Compare own Give laboratories

check data with data & hospitals access
from hospitals & to information
laboratories

Fig. 9. Positive and negative interactions between goals.

Process : Cancer Registration

Actor : Cancer Registry

Quality of Information Confidentiality

S P

Validation of
S S P
Information

Accuracy of Security ( access

Information to information)

S S S

Consistency Compare own Give laboratories

check data with data & hospitals access
from hospitals & to information
laboratories

Fig. 10. Evaluation of an NFR graph.

(a) Compare and adjust NFR graphs for the same actor
within a process to Wnd and remove conXicting NFRs.
For example, compare ‘information validation’
against ‘conWdentiality’ for the cancer registry within
the CR process.
(b) Compare and adjust NFR graphs for the same pro-
cess to Wnd and remove conXicting NFRs. For exam-
ple, compare ‘information validation’ for the cancer
registry actor with ‘information validation’ for the
hospital actor.
(c) Perform a pair-wise comparison and adjustment on
graphs within the same process that have not already
been compared under (a) or (b).
(d) Broaden the checking and adjustment procedure
across processes within the overall business process.
4.1.6. Select which NFRs to address to achieve process
improvement
When interactions among NFR graphs have been identi-
Wed, an evaluation can be performed to determine which
 F. Aburub et al. / Information and Software Technology 49 (2007) 1162–1171 1169

Process : Cancer Registration

Actor : Cancer Registry

Quality of Information
S

Validation of
S
Information

S S S

Consistency Compare own Give laboratories &

check data with data hospitals access to
from hospitals & information
laboratories

Fig. 11. Part of NFR graph to be linked.

NFRs should be addressed by the process improvement
team. As a Wrst step, labels can be assigned to each goal in
the NFR graphs, as follows:
(a) S if the goal is satisWed.
(b) D if the goal is not satisWed (is denied).
(c) P if the goal is partially satisWed.
This evaluation helps the process improvement team analyse
the impact of selecting a particular goal on other goals. It would
be counter-productive to select achievement of a speciWc goal
for inclusion in process redesign if satisfying that goal led to a
more important goal being denied or only partially satisWed.
By repeating this process, the improvement team can select
most beneWcial goals which involve the least sacriWce. For
instance, conWdentiality makes a negative impact on quality of
information in the cancer registration process shown in Fig. 9.
If conWdentiality is judged to have less priority than quality of
information NFR, it may be acceptable to have conWdentiality
partially satisWed in order to achieve satisfaction of the quality
of information NFR, as shown in Fig. 10.
(b) Within that set of graphs, Wnd those that refer to par-
ticular roles in the RAD model, and proceed to exam-
ine each role in turn.
(c) Relate the activities and interactions included in the
role to the roots (goals) of the NFRs which corre-
spond to that role.
(d) If the role in the RAD model does not cover the
nodes in the NFR graphs, the possibility is raised that
this part of the RAD model is deWcient, and should be
updated by adding or modifying activities or interac-
tions that belong to that role.
(e) If there are actors identiWed in the NFR graphs which do
not correspond to roles in the current RAD model, this
indicates that it might be necessary to add a new role to
the model to satisfy the unmatched NFR(s).
If adjustments are made to the RAD models, it implies that
corresponding changes should be made to the actual processes
(that is, to the activities, interactions and roles in them).
At present, the procedure presented is informal. There
might be beneWts, as we develop it, to use a formal represen-

4.2. Linking the non-functional view to the functional view Table 2

Actions for ‘Quality of Information’
We now sketch a general procedure for linking the NFR Process: Cancer registration
graphs to the RAD models. Goal: Quality of information
Role: Jordan cancer registry (JCR)
(a) Find all the NFR graphs that refer to a particular Action1: Consistency check, AND
process in the RAD model (i.e., in the example case, Action2: Compare own data with data from hospital & laboratories, AND
Action3: Give laboratories & hospitals access to information
the CR process).
1170 F. Aburub et al. / Information and Software Technology 49 (2007) 1162–1171

Registrar
JCR Laboratory
(Medical Records)

Send form to JCR Send different forms to JCR

Change lab oratory ’s

form into JCR form

Check forms

Compare primary cancer site

with its ICD-O code
N Y
Mismatch?

Return the form to hospital Return the form to lab oratory

Check if patient exists in the JCR DB

Y N
Does patient exist in JCR database?

Check if the primary cancer Add patient to

site exists in the JCR DB JCR database

N Y
Does primary cancer site Add primary
exist in JCR database? cancer site
to JCR
database
Add primary cancer site to JCR database
Y N
Is there additional
data?

Modified patient’s file

Save form in JCR archive

Check hospital data by accessing JCR information Check laboratory data by access to JCR information

Compare JCR information with hospital information Compare JCR information with laboratories information

At end of year

Analyse the JCR DB which is collected in the

last year
Healthcare Sector
Generate statistical reports
Send reports to all Healthcare Sectors

Comparing the report on the

regional level

Fig. 12. RAD model after linking with NFR graph.

tation of the improvement steps, perhaps using something To illustrate the process of linking, we will show how
similar to the ECA (event-condition-action) notation famil- part of the Quality of Information NFR graph shown in
iar in database contexts. Fig. 11, can be applied to the RAD model of the CR
 F. Aburub et al. / Information and Software Technology 49 (2007) 1162–1171
process in Jordan (shown in Fig. 1), to produce the modi-
Wed RAD model for CR shown in Fig. 12.
The NFR graph (Fig. 11) indicates that the Jordan Can-
cer Registry should validate its information by performing
a consistency check, comparing its data with hospital and
laboratory data, and giving laboratories and hospitals
access to registry information to check their data entries.
Table 2 gives a summary of the actions that need to be car-
ried out by the role ‘JCR’ to achieve the goal ‘quality of
information’.
From the original CR process model in Fig. 1 and Table
1, it can be seen that “consistency check” (Action1 in the
Table 2) is already satisWed (in the ‘check forms’ activity,
near the top of the JCR role); but that the other two actions
– “compare own data with data from hospitals and labora-
tories” and “give laboratories and hospitals access to infor-
mation” (Action2 and Action3 in the Table 2) – are not
satisWed. The RAD model can therefore be improved by
adding two interactions in the RAD model, namely “check
hospitals and laboratories data by accessing JCR informa-
tion” and “compare JCR information with laboratories
and hospitals information”, as shown by the dotted lines in
Fig. 12.
5. Conclusion
We have demonstrated the application of a method for
remodelling business processes to achieve better representa-
tion and realisation of ‘non-functional’ aspects of pro-
cesses. The approach has been adapted from methods
developed in software engineering for linking non-func-
tional requirements to conceptual models. We have drawn
an analogy between non-functional requirements in soft-
ware terms, to general or overall quality aspects of business
processes which are not well captured in functionally ori-
ented process modelling methods.
We have shown how the technique of NFR graphing,
including operationalisation of goals, and interaction analy-
sis and evaluation of goals can be applied to produce an
NFR model of a business process which can then be applied
to a functional model developed using role activity diagram-
ming (RAD). The congruence between the central notion of
‘role’ in RAD and that of ‘actor’ in NFR graphing facilitates
the linking process. We used an example from a business pro-
cess in healthcare (cancer registration in Jordan) to illustrate
the argument and show an application of the method.
In future research, we intend to develop and test further
the procedures outlined here for producing a NFR model
1171
of a business process and linking it to a corresponding
functional model in the service of business improvement.
References
[1] L. Chung, B. Nixon, Dealing with non-functional requirements: three
experimental studies of a process-oriented approach, in: Proceedings
of the 17th International Conference on Software Engineering, Seatle,
WA, April 1995, pp. 24–39.
[2] L. Chung, Representing and using non-functional requirements: A
process oriented approach. Ph.D. Thesis, Department of Computer
Science, University of Toronto, 1993.
[3] L. Cysneiros, J. Leite, J. Neto, A framework for integrating non-func-
tional requirements into conceptual models, Requirements Engineer-
ing 6 (2001) 97–115.
[4] T. Davenport, Innovation: Reengineering Work through Information
Technology, Harvard Business School Press, Boston, 1993.
[5] G. Giaglis, A taxonomy of business process modelling and informa-
tion system modelling techniques, The International Journal of Flexi-
ble Manufacturing Systems 13 (2001) 209–228.
[6] T. Gilb, Principles of Software Engineering Management, Addison
Wesley, Reading, MA, 1988.
[7] A. Gunasekaran, B. Kobu, Modelling and analysis of business process
reengineering, International Journal of Production Research 4 (11)
(2002) 2521–2546.
[8] M. Hammer, J. Champy, Re-engineering the Corporation: A Mani-
festo for Business Revolution, Harper Business, New York, NJ, 1993.
[9] G. Kotonya, I. Sommerville, Requirements Engineering: Processes
and Techniques, John Wiley and Sons, England, 1998.
[10] K.T. Lee, K.B. Chuah, A super methodology for business process
improvement, International Journal of Operational Management 2
(1) (2001) 687–706.
[11] F. Lin, M. Yang, Y. Pai, A generic structure for business process mod-
elling, Business Process Management 8 (1) (2002) 19–41.
[12] National Cancer Registry: Incidence of Cancer in Jordan, Jordan
University Press, Amman – Jordan, 1999.
[13] M. Ould, Business Process, Management a Rigorous Approach, The
British Computer Society, Swindon, UK, 2005.
[14] M. Pidd, Tools for Thinking: Modelling in Management Science,
Wiley, London, 2003.
[15] B. Povey, The development of a best practice business process
improvement methodology, Benchmarking for Quality Management
and technology, International Journal of Production Research 5 (1)
(1998) 27–44.
[16] R.S. Saven, Business process modelling: Review and framework,
International Journal of Production Economics 90 (2) (2004) 129–
149.
[17] N. Shin, D. Jemella, Business process reengineering and performance
improvement: The case of Chase Manhattan Bank, Business Process
Management Journal 8 (4) (2002) 351–363.
[18] R.G. Skeet, Quality and quality control, in: O.M. Jensen, D.M. Parkin,
R. Maclennan, C.S. Muir, R.G. Skeet (Eds.), Cancer Registration
Principles and Methods, Lyon, 1991, pp. 101–107.
[19] S.A. Tonu, L. Tahvildari, Towards a framework to incorporate NFRs
into UML Models, in: Proceedings of 1st International Workshop on
Reverse Engineering to Requirements (RETR’05), held at Carnegie
Mellon University, November 7, 2005, pp. 13–18.