Content uploaded by Lianping Chen
Author content
All content in this area was uploaded by Lianping Chen on Jan 16, 2015
Content may be subject to copyright.
38 IEEE SoftwarE | publIShEd by thE IE EE comput Er SocIE ty 0740 -745 9/13 /$ 31.0 0 © 2013 IE EE
AT THE HEART of any engineering dis-
cipline is the interplay between problem
and solution development. In software
engineering, we determine a software
solution’s effectiveness with respect to
a problem, yet the nature of the prob-
lem and its scope could depend on what
solutions already exist or what solu-
tions are plausible and cost-effective.
This iterative and concurrent develop-
ment and trade-off between software
problems and solutions characterize
the twin peaks model of software
development.1
For the development of many large-
scale, software-intensive systems, the
software architecture is a fundamen-
tal part of a software solution.2 It sig-
nicantly affects software quality and
cost, but not all of a system’s require-
ments affect software architecture
equally.3 In many cases, only some re-
quirements actually determine and
shape a software architecture;4 we call
these architecturally signicant re-
quirements (ASRs). If ASRs are wrong,
incomplete, inaccurate, or lack details,
then a software architecture based on
them is also likely to contain errors.
Unfortunately, in practice, stake-
holders and requirements engineers
frequently fail to express or effectively
communicate ASRs to the architects,
preventing the architects from mak-
ing informed design decisions.4 This is
partly due to a lack of an authoritative,
evidence-based discourse characteriz-
ing ASRs.
To address this, we carried out an
empirical study to help characterize
ASRs. Based on the study’s results,
this article presents an evidence-based
framework for systematically charac-
terizing ASRs. We hope our ndings
can help practitioners better understand
and deal with ASRs, as well as pro-
vide researchers with a framework for
discussing and conducting further re-
search on ASRs. The work can also in-
form researchers’ development of tech-
nologies for dealing with ASRs. Finally,
our ndings can enrich understanding
of requirements and architecture in-
teractions, allowing the twin peaks to
move from aspiration to reality.
Methodology
and Research Design
As our research method, we used
grounded theory (GT),5 which pro-
vides a systematic process of generat-
ing theory from data. GT has gained
popularity among software engineering
researchers, who have reported its ef-
fectiveness for topics that lack empiri-
cal research.6 GT recommends avoiding
the formulation of research questions
upfront, promoting instead the selec-
tion of a general area of interest for re-
search. We chose to explore ASRs as an
area of research.
We collected the data in our
study by conducting interviews with
FOCUS: Twin Peaks
Characterizing
Architecturally
Signicant
Requirements
Lianping Chen, University of Limerick and Paddy Power PLC
Muhammad Ali Babar, Lancaster University and IT University
of Copenhagen
Bashar Nuseibeh, University of Limerick and The Open University
// A new framework characterizes architecturally
signicant requirements on the basis of
an empirical study of 90 practitioners from
organizations of various sizes and domains. //
march/aprIl 2013 | IEEE SoftwarE
39
90 practitioners, who we recruited
through personal connections and so-
cial networks. We conducted the inter-
views mostly via email and sometimes
via phone. In instances when we used
email for data collection, participants
didn’t have to nd a sufcient chunk
of free time to t researchers’ sched-
ules, but could answer in their own
time; this also provided participants
with more time for reective answers.
Figure 1 summarizes the participants’
demographics.
The participants came from four
countries (58 percent from the US, 28
percent from India, 13 percent from
the Netherlands, and 1 percent from
the UK), as shown in Figure 1a. Figure
1b shows that the participants repre-
sented a diverse set of industries. Each
participant had worked for an average
of seven organizations during his or
her career. Cumulatively, the partici-
pants had worked for more than 500
distinct organizations throughout their
careers. The size of the organizations
they worked for ranged from very small
(fewer than 10 people) to very large
(more than 10,000 people), as shown in
Figure 1c.
Given our research’s focus on under-
standing requirements’ effects on archi-
tectures, we decided to limit participa-
tion to be only from those professionals
who had experience working with soft-
ware architectures in their current or
previous roles. Although the majority of
participants we interviewed were soft-
ware architects, some were executives,
managers, consultants, or developers.
None of our participants specically
identied themselves as requirements
engineers, but we observed that consul-
tants often played such roles. As Figure
1d shows, 52 percent of our participants
were architects, followed by 20 percent
executives, 14 percent managers, 8 per-
cent consultants, and 6 percent develop-
ers. Together, the participants had more
than 1,448 years of accumulated work
experience in software development and
761 years in software architecture, as
shown by Figure 1e.
We conducted our interviews via
informal conversations. Most of the
conversations kicked off with the fol-
lowing question: “From your observa-
tions and experiences, what are the
characteristics that distinguish ASRs
from other requirements? In other
words, what, if anything, makes them
unique or peculiar?” Follow-up ques-
tions sought to clarify or gather more
details about the characteristics men-
tioned by the participants.
For analyzing the data, we used
some of GT’s qualitative data analysis
techniques such as open coding, con-
stant comparison method, selective
coding, and memoing.7 We began data
analysis as soon as we collected some
data and continued iteratively and in
parallel. We used a tool called NVivo
to facilitate the analysis.
Only concepts that were men-
tioned by at least two participants
were included in the nal ndings.
Once concepts earned their way into
the theory, we did not discriminate
between them based on their frequen-
cies; rather, we focused on the logical
relationships among concepts, as rec-
ommended by GT.
Characteristics
of Architecturally
Signicant Requirements
A framework of characteristics of ASRs
emerged from our analysis. Figure 2
shows the framework, which consists of
four sets of characteristics: denition,
descriptions, indicators, and heuristics.
Denition
ASRs are those requirements that have
a measurable impact on a software
system’s architecture. Essentially, this
denition delimits a portion of require-
ments, the portion that affects the ar-
chitecture of a system in measurably
identiable ways. Do such require-
ments really exist? Our empirical data
appears to conrm this—for example,
participants didn’t perceive a require-
ment stating that “temperature should
be displayed in Celsius not Fahrenheit
on this webpage” to be architectur-
ally signicant, but they did usually
perceive a requirement stating that
“the system should provide ve nines
(99.999 percent) availability” as archi-
tecturally signicant.
“Signicant” is a key term in our
denition. What does it mean? Ulti-
mately, it is measured by high cost of
change. This cost can be monetary or
not (for example, time, resources, rep-
utation, and opportunity cost). What
cost is considered as high? The an-
swer is invariably project-specic—a
US$10,000 cost can be high for a small
budget project but low for a large one.
Some cost measures can be entirely
qualitative but still identiable in their
ability to distinguish ASRs.
Descriptions
ASRs are often hard to dene and artic-
ulate, tend to be expressed vaguely, tend
What cost is considered as high?
The answer is invariably project-specic.
40 IEEE SoftwarE | www.computEr.org/SoftwarE
FOCUS: Twin Peaks
(a) (b)
(c)
(e)
(d)
0
5
10
15
20
25
30
35
40
45
50
1–5 6–10 11–15 16–20 21–25 26–30 31–35 36–40
Number of participants
Years of experience
Software development
(min = 3, max = 37, avg = 16, total = 1,448)
Software architecture
(min = 1, max = 23, avg = 8, total = 761)
UK
1%
US
58%
India
28%
Netherlands
13%
Other
(telecom, retail, military, legal,
investment, insurance, healthcare)
8%
Financial
services
6%
Computer
software
58%
Information
technology
and services
28%
Very large
(>10,000)
47%
Very small
(<10)
14%
Large
(250–10,000)
16%
Medium
(50–249)
19%
Small
(10–49)
4%
Developer
6%
Excecutive
(VP, CEO,
president,
chief scientist,
director)
20%
Manager
14%
Architect
52%
Consultant
8%
Figure 1. Demographics of study par ticipants: (a) distribution over countries, (b) distribution over industries, (c) distribution over organization
sizes, (d) job positions, and (e) experience in software development and architecture.
march/aprIl 2013 | IEEE SoftwarE
41
to be initially neglected, tend to be hid-
den within other requirements, and are
subjective, variable, and situational. We
could argue that other requirements also
demonstrate these descriptive character-
istics, or descriptions. However, ASRs’
architectural signicance made these
characteristics’ manifestations unique
and challenging for ASRs.
Hard to dene and articulate. One par-
ticipant noted, “Users usually nd it
difcult to articulate [ASRs], as many
of them are about abstract and general
concepts.”
In addition, ASRs are expected to
be ready in the early stage of the soft-
ware development process. At this early
stage, customers might not yet be clear
about their exact needs, and some re-
quirements decisions (especially about
details) might not have been made. This
adds to the difculties of dening and
articulating ASRs.
Tend to be described vaguely. Many ar-
chitects reported that ASRs they re-
ceived are too vague to be used for
making informed architectural deci-
sions. Vaguely described ASRs often
lead to bad decisions because architects
can make wrong assumptions about the
missing details.
Consider an example of users re-
questing the ability to receive notica-
tion about cash ows. Architects as-
sumed that emails would be acceptable
for this. During detailed design, users
explained that they wanted real-time
notication, the ability to subscribe to
different account topics, and a user in-
terface that shows all of this. This re-
quired publish-subscribe, a different ar-
chitecture style.
Tend to be neglected initially. One par-
ticipant said, “Typically [ASRs] are
overlooked in the early phase of a proj-
ect.” ASRs are often neglected initially
because of a lack of initial awareness
of their signicant effects on architec-
ture, and thus aren’t given sufcient
attention. One participant said, “Us-
ers do not typically have a good under-
standing of [ASRs]; people who con-
duct requirement analysis often do not
document them properly. … Users will
not ask for them unless you are deal-
ing with a highly tech-savvy group of
users.” Another participant said that
neglecting ASRs in this way often hap-
pens with less-experienced teams.
Many times, requirements aren’t
recognized as architecturally signi-
cant until they’ve incurred a high cost,
and at that stage, rectifying mistakes
can be costly.
Tend to be hidden within other require-
ments. Following the way people spon-
taneously express requirements, ASRs
usually aren’t emphasized in require-
ments’ oral or written descriptions;
rather, they’re embedded in other re-
quirements’ descriptions. Short phrases
such as “highly available system of
99.999 percent uptime” or “fault
tolerant” are often only mentioned
briey while describing other require-
ments, but these phrases can signi-
cantly affect architecture.
When architects receive ASRs that
are hidden within other requirements,
the ASRs usually aren’t sufciently
elaborated and often lack the key de-
tails required for making informed ar-
chitectural decisions.
Subjective. ASRs tend to be requested
subjectively based on opinion instead of
fact-based objective decisions. One par-
ticipant reported, “[ASRs requested by
customers] usually contain subjectiv-
ity—for example, ‘The system should
be available for 24/7’—whether it
[needs to] be or not.”
This subjectivity can lead to inac-
curacy of the requirements conveyed
to architects. Small differences in ASRs
can lead to big differences in resulting
architectures.
Variable. ASRs can change over time.
This is usually unavoidable owing to
• Have a measurable impact
on the software system’s
architecture
• Wide impact
• Targeting tradeoffs
• Strictness (constraining,
limiting, nonnegotiable)
• Assumption breaking
• Difcult to achieve
Denition
Architecturally
signicant
requirements
• Hard to dene and articulate
• Tend to be described vaguely
• Tend to be neglected initially
• Tend to be hidden within
other requirements
• Subjective
• Variable
• Situational
Descriptions
Indicators
• Quality attributes
• Core features
• Constraints
• Application environment
Heuristics
Figure 2. A framework of the characteristics of architecturally signicant requirements.
42 IEEE SoftwarE | www.computEr.org/SoftwarE
FOCUS: Twin Peaks
changes that take place in business
and technology. As a participant re-
ported, “Requirements always change
over time, during the project and after-
ward.” Another participant reported,
“Technology as dened as hardware,
software, and the relatively new inclu-
sion of user experience is now changing
so quickly that companies are viewing
products as having a very limited (and
short) lifetime before needing to be re-
designed to take advantage of those
ch a nges .”
ASRs can also vary over space—
for example, consider the variability
of ASRs for different but similar soft-
ware systems that are engineered using
a software product line paradigm.8
Situational. Whether a piece of require-
ment is architecturally signicant de-
pends on situations. As one participant
said, “A requirement is architecturally
signicant in one case, while being ‘just
a requirement’ in the other case.”
Requirements can be situational
regarding an existing architecture, a
project’s context or scope, and so on.
A requirement might be architecturally
signicant in a situation where a “bad”
architecture is in place, but is not so
when the architecture is “good.” An-
other participant reported, “A simple
requirement in a smaller project might
not be architecturally signicant. Take
the same requirement and enhance
scope, add multiple interactions—then
it could become signicant.”
A requirement’s architectural sig-
nicance can depend on many fac-
tors. So, a denitive judgment on a
requirement’s architectural signicance
usually can only be made when the re-
quirement really incurs a high cost or if
the architects require it to make archi-
tectural decisions. During requirements
gathering, we can only say that certain
requirements are likely to be architec-
turally signicant. Finding a denitive
list of ASRs is not feasible. ASRs need
to be dealt with individually.
Indicators
Although the cost of change is a mea-
sure of signicance, getting an accurate
cost of a requirement is challenging (de-
spite extensive studies9). In addition,
an estimate of whether a requirement
is architecturally signicant can be im-
portant for guiding the gathering of
ASRs, but cost estimation is usually un-
dertaken after requirements have been
gathered.
ASRs do have some characteris-
tics that help us distinguish them from
other requirements without needing to
undertake a full cost estimation. In-
dicative characteristics, or indicators,
provide such pragmatic hints about
the architectural signicance of a
requirement.
Wide impact . When a requirement has
wide impact on a system, it’s usually ar-
chitecturally signicant. This can be in
terms of the components, other require-
ments, the code modules, the stakehold-
ers, or other things that are affected by
the requirement. Participants noted,
“Yes, there are requirements [that] can
be thought of as architecturally signi-
cant because those requirements impact
the system as a whole immediately”;
“[An ASR] has widespread impact
across multiple components of the sys-
tem”; and “The more broadly a require-
ment and its resolution can be applied,
the more signicant it is.”
Targeting trade-offs. A requirement that
targets trade-off points is usually ar-
chitecturally signicant. A trade-off
point is one at which there’s no solution
that satises all involved requirements
equally well, therefore architects must
select a design option that compromises
some requirements to meet others. Such
requirements can directly affect archi-
tecture decisions’ outcome, thus they’re
architecturally signicant. One par-
ticipant reported this as follows: “The
trade-offs are the weak points—the
raw nerves— of the architecture. If a
new requirement happens to (uninten-
tionally) target these trade-offs—these
weak points—then the probability of
it becoming architecturally signicant
is higher than if it did not target these
trade-offs.”
When the requirement targets a
trade-off point, the details, accuracy,
and precision of the requirement de-
scription become important. One par-
ticipant reported that half-a-second
difference in his system’s performance
requirements can lead to a totally dif-
ferent design.
Strictness (constraining, limiting, non-
negotiable). A strict requirement neces-
sitates a particular design option, and
the requirement itself can’t be negoti-
ated. When making architectural deci-
sions, the requirements that can be sat-
ised by multiple design options (or can
be negotiated to a form that can be sat-
ised by multiple design options) will
allow exibility in architectural design,
whereas a strict requirement will deter-
mine architectural decisions because it
can’t be satised by alternative design
options (thus being constraining or lim-
iting). One participant reported, “Our
Although the cost of change is a measure
of signicance, getting an accurate cost
of a requirement is challenging.
march/aprIl 2013 | IEEE SoftwarE
43
signicant requirements were those
that would be the limiting, or dening,
characteristics of the product.”
Assumption breaking. When designing
a system’s architecture, the architect
makes some fundamental assumptions
(explicitly or implicitly). For example,
architects assume that turning down
the server at midnight for maintenance
is acceptable. Later on, this might no
longer be acceptable if the business
expands to countries in different time
zones.
When a requirement breaks any of
these assumptions, it’s architecturally
signicant. This is because it requires
architectural change to accommodate
the requirement. One participant re-
ported, “Down the line someday, we
meet our assumptions face to face, and
a requirement that actually crosses the
boundary of that assumption would be
the one that changes the architecture.”
Judging whether a requirement
breaks any such fundamental assump-
tions requires good knowledge about
the system’s existing architecture. A
well-organized record of the assump-
tions and related architectural decisions
can make the job easier, so there’s a
need for effective tools that can manage
assumptions and design decisions.
Difcult to achieve. If a requirement is
difcult to meet or is technologically
challenging, it’s likely to be architec-
turally signicant. One participant re-
ported, “The uniqueness of [ASRs] to
me is … difculty of achieving. For ex-
ample, latency is very hard to achieve if
not thought [about] early on.”
Heuristics
Judging whether a requirement has wide
impact, whether a requirement tar-
gets trade-offs, whether a requirement
strictly requires a particular design
option, whether a requirement breaks
existing architectural assumptions, or
whether a requirement is difcult to
achieve can require substantial knowl-
edge of the solution space.
Requirements engineers, however,
aren’t usually expected to have exten-
sive solution space knowledge. Thus,
many of them are unlikely to be able
to use such indicators to identify ASRs.
Therefore, we need characteristics that
are familiar to requirements engineers.
We discovered a set of such characteris-
tics, which we call heuristic character-
istics, or heuristics.
Heuristics can guide requirements
engineers to ask questions proactively
regarding concerns that are likely to be
architecturally signicant but that us-
ers don’t mention.
Quality attributes. When a requirement
species a software system’s quality at-
tributes, it’s usually architecturally sig-
nicant. The participants mentioned a
variety of such quality attributes from
the software systems that they worked
on (see Figure 3).
Quality attributes’ specic meanings
can vary from project to project, so we
must also gather details of quality at-
tributes—for example, a general state-
ment that “the system should respond
in real time” probably won’t be enough
to make correct architectural decisions.
Core features. A requirement that refers
to a software system’s core features is
likely architecturally signicant. Core
features dene the problems the soft-
ware is trying to solve; they usually
capture the essence of the software sys-
tem’s behavior and describe the core
expectations users have on the software
system. They directly serve to achieve
the objective of building the system.
These requirements are usually as-
sumed, often implicitly, to be the invari-
ants of the software system. They are
part of the fundamental assumptions
that the architecture is built upon. Based
on a software system’s core features,
the most relevant quality attributes of-
ten choose themselves; as one partici-
pant reported, “Based on the unique
functional aspects a software system
is targeted to address, the nonfunc-
tional ones often align themselves. ...
A high-frequency quantitative trading
engine with millisecond latency will
automatically emphasize performance,
whereas an airline control system will
immediately focus on reliability.”
Constraints. Requirements that im-
pose constraints on a software system
are usually architecturally signicant.
These can be nontechnical—such as
nancial, time, and developer skill
constraints—or technical—such as
constraints imposed by existing archi-
tectural decisions or by a client’s tech-
nical decisions.
Application environment. Requirements
that dene the environment in which
the software system will run are likely
to be architecturally signicant. Par-
ticipants mentioned examples such as
application servers, the Internet, cor-
porate networks, embedded hardware,
virtual machines, mobile devices, and
so on. Systems running in different en-
vironments often have vastly different
architectures.
Adaptability
Availability
Congurability
Flexibility
Interoperability
Performance
Reliability
Responsiveness
Recoverabilit y
Scalabilit y
Stabilit y
Security
Extensibility
Modularity
Portability
Reusability
Testability
Auditability
Maintainability
Manageabilit y
Sustainability
Supportability
Usability
Figure 3. Software systems’ quality
attributes that participants mentioned during
the study.
44 IEEE SoftwarE | www.computEr.org/SoftwarE
FOCUS: Twin Peaks
Implication on Practice
In this article, we made a distinction
between requirements that have signi-
cant impact on software architecture
and other requirements. This distinc-
tion has helped us focus on ASRs when
dealing with interplay between require-
ments and architecture.
ASRs can be challenging to deal with,
as revealed by our descriptive character-
istics. Descriptive characteristics explain
why ASRs are challenging to handle.
They can also be useful input for devel-
oping evaluation criteria for approaches,
tools, and practices to deal with ASRs.
In practice, there is no label for each
requirement to tell us whether or not it
is architecturally signicant. To make
the distinction practical, we need prag-
matic characteristics to enable us to
identify ASRs. Indicative characteris-
tics provide such pragmatic hints about
the architectural signicance of a re-
quirement. They rely on some knowl-
edge of the solution space.
Heuristic characteristics highlight
requirements that tend to be architec-
turally signicant, using terminology
familiar to people in the problem space.
In contrast to indicators, they can be
used by people who do not have suf-
cient knowledge of the solution space.
They can guide requirements engineers
to ask questions proactively, on con-
cerns that are likely to be architectur-
ally signicant but that users do not
mention. These characteristics have the
potential to bring substantial improve-
ments to the gathering of ASRs by iden-
tifying those ASRs that might other-
wise be ignored.
The twin peaks model suggests that
requirements and architecture should
be treated iteratively and concurrently.
Our observations of the situational na-
ture of ASRs suggest that such itera-
tion is inevitable. Some requirements
are only recognized as architecturally
signicant after architects realize they
need them to make architectural deci-
sions. At this point, architects usually
need to ask requirements engineers to
provide them.
Our ndings also reveal another
interaction between requirements and
architectures: providing feedback on an
architecture’s impact on requirements
to inform requirements decisions and
to avoid committing to infeasible re-
quirements or requirements that cost
more than the value they can generate.
The concrete manifestation of this
nding can be in the form of improved
requirements negotiation—for exam-
ple, if a requirement targets a trade-off
point but doesn’t bring sufcient value
to justify the cost incurred by the corre-
sponding design option, one can nego-
tiate the requirement with the users to
make the requirement less demanding
or drop it altogether.
This also poses challenges to what
used to be traditional thinking that
one should not consider solution space
concerns while gathering requirements.
This can be true for requirements that
are not architecturally signicant.
However, for ASRs, architects’ feed-
back about requirements’ impact can
help with better-informed requirements
decisions. Thus, we suggest that appro-
priate use of solution space knowledge
can help gather and negotiate ASRs
more effectively.
Indicative characteristics also sug-
gest that there should be a closer col-
laboration between requirements
engineers and software architects. De-
velopment teams, processes, and prac-
tices should be organized and designed
in a way that encourages and facilitates
such collaboration, with correspond-
ing tools that encourage exchange
rather than separation of development
activities.
Although it is perhaps contro-
versial, it does appear that
there is a case to be made for
requirements engineers having better
knowledge of software architectural
concerns. We suggest that such knowl-
edge could enable them to gather and
negotiate ASRs more effectively. They
can ask questions of users more au-
thoritatively during requirements elici-
tation. However, we are not arguing
that solutions could determine problem
analysis, but rather inform it and en-
sure that implications of requirements
on architecture (and vice versa) are un-
derstood and communicated.10
Acknowledgments
We thank our study participants for their
contributions and this article’s reviewers for
their prompt and thoughtful comments. This
work was funded in part by SFI Lero grant
10/CE/I1855 and ERC Advanced Grant
2916 52 .
References
1. B. Nuseibeh, “Weaving Together Requi re-
ments and Architectu res,” Computer, vol. 34,
no. 3, 2001, pp. 115–117.
2. R.N . Taylor, N. Medvidov ic, and E .M.
Dasho fy, Software Architec ture: Found ations,
Theor y, and Practice, Wiley, 2009.
3. C. Hofmeister et al., “A General Model of
Software Architec ture Design Derived from
Five Industrial Approaches,” J. Syste ms an d
Software, vol. 80, no. 1, 2007, pp. 106–126.
In practice, there is no label for each
requirement to tell us whether or not it is
architecturally signicant.
march/aprIl 2013 | IEEE SoftwarE
45
4. P. Clements a nd L. Bass, Relati ng Business
Goals to Architecturally Signican t Require-
ment s for Sof tware Systems, tech. note CM U/
SEI-2010-TN- 018, Software E ng. Inst., Carn-
egie Mel lon Univ., 2010.
5. B. Glaser and A . Strauss, The D iscovery of
Grounded Theory: Strategies fo r Qualitative
Research, Aldine Transaction, 1967.
6. S. Adolph, W. Hall, a nd P. Kruchten, “Using
Grounded Theor y to Study t he Experience of
Softwa re Development,” Empiric al Sof tware
Eng., vol. 16, no. 4, 2011, pp. 487–513.
7. J. Corbin and A. Strauss, Basi cs of Qu alit a-
tive Re search: Techniques and Proced ures for
Devel oping G roun ded Theory, 3rd ed., Sage,
20 0 7.
8. M.A. Babar, L. Chen, and F. Shull, “Manag-
ing Variabi lity in Soft ware Product Lines,”
IEEE Software, vol. 27, no. 3, 2010, pp.
89–91, 94.
9. M. Jorgensen and M. Shepperd, “A Systemat ic
Review of S oftware Development Cos t Esti-
mation St udies ,” IEEE Trans. Sof tware Eng.,
vol. 33, no. 1, 20 07, pp. 33–53.
10. L. Rapanotti et al., “Architectu re-Driven
Problem De composit ion,” Proc. 12th IE EE
Int’l R equire men ts Eng. C onf., IE EE , 2003;
doi: 10.1109/ICR E.2004.1335666.
LIANP ING CH EN is a doctoral researcher at Lero —the Irish Soft ware
Engineering Research Centre at the University of Limerick and a senior
software engineer at Paddy Power PLC. His research interests include
software requirements and architecture, and software product lines.
Chen received an MS in soft ware engineering from Nor thwestern Poly-
technical University. Contact him at lianping.chen@lero.ie.
MUHAMMAD ALI BABAR is a reader in software engineering
at Lancaster University and an associate professor at IT University
of Copenhagen, Denmark. His research interests include software
architecture, cloud computing, and soft ware development paradigms.
Ali Babar received a PhD in computer science and engineering from the
Universit y of New South Wales. Contact him at malibaba@itu.dk.
BASHA R NUSE IBEH is a professor of computing at The Open Uni-
versity, UK , and a professor of software engineering at Lero —the Irish
Soft ware Engineering Research Centre at the University of Limerick. His
research interests include software requirements and design, security
and privacy, and technology transfer. Nuseibeh received a PhD in soft-
ware engineering from Imperial College London. He currently serves as
editor in chief of IEEE Transactions on Software Engineering and holds
a European Research Council Advanced Grant and a Royal Society-
Wolfson Merit Award. Contact him at b.nuseibeh@open.ac.uk.
abouT The auThors
ADVERTISER PAGE
Impact 2013 37
IREB 13
John Wiley & Sons, Inc. Cover 4
StarCanada 2013 Cover 3
Advertising Personnel
Marian Anderson: Sr. Advertising Coordinator
Email: manderson@computer.org
Phone: +1 714 816 2139 | Fax: +1 714 821 4010
Sandy Brown: Sr. Business Development Mgr.
Email: sbrown@computer.org
Phone: +1 714 816 2144 | Fax: +1 714 821 4010
Advertising Sales Representatives (display)
Central, Nor thwest, Far East: Eric Kincaid
Email: e.kincaid@computer.org
Phone: +1 214 673 3742; Fax: +1 888 886 8599
Northeast, Midwest, Europe, Middle East: Ann & David Schissler
Email: a.schissler@computer.org, d.schissler@computer.org
Phone: +1 508 394 4026; Fax: +1 508 394 1707
Southwest, California: Mike Hughes
Email: mikehughes@computer.org; Phone: +1 805 529 6790
Southeast: Heather Buonadies
Email: h.buonadies@computer.org
Phone: +1 973 585 7070; Fax: +1 973 585 7071
Advertising Sales Representatives (Classified Line)
Heather Buonadies
Email: h.buonadies@computer.org
Phone: +1 973 585 7070; Fax: +1 973 585 7071
AdvertiSer informAtion • mArch/April 2013
Selected CS articles and columns
are also available for free at
http://ComputingNow.computer.org.
