QUPER Model
Draft Paper
Paper for the Method Engineering course
Master in Business Informatics, Utrecht University
Catalina Sacu 3305260
Table of Contents
1.
Introduction ............................................................................................................................. 2
2.
Method description ................................................................................................................. 3
2.1
General information ...................................................................................................... 3
2.2
QUPER views ............................................................................................................... 4
2.3
QUPER steps and deliverables ..................................................................................... 5
3.
QUPER model in an example ................................................................................................. 6
4.
Process-deliverable diagram (PDD) ....................................................................................... 8
5.
Related literature ................................................................................................................... 13
5.1
Topic origins .............................................................................................................. 13
5.2
Topic elaboration and description ............................................................................. 14
5.3
Application of the model ............................................................................................ 15
6.
Conclusions ........................................................................................................................... 16
7.
References ............................................................................................................................. 16
1.
Introduction
Method Description – Catalina Sacu
Page 2
In the last few years, the discipline of market-driven Requirements Engineering (RE) has become
more and more popular. The interest in this field began to increase in the nineties when
researchers reported that the gap between software engineering research and practice is no more
evident than in the field of requirements engineering (Davis and Hsia, 1994). Consequently, a lot
of research began in this discipline and several methods were developed in order to fill in this
gap.
In the context of RE, products are often developed using a product-line approach (Dikel et al,
1997) that implies combining market considerations with implementation concerns such as
platform scoping (deBaud, Schmid, 1999), release planning (Carlshamre, Regnell, 2000) and
roadmapping (Regnell, Brinkkemper, 2005). Also, there are approaches that, when referring to
requirements prioritization, focus only on functional requirements without paying any attention
to the non-functional aspects which are, at least, equally important (Jacobs, 1999).
In order to overcome these drawbacks, a new conceptual model, called QUPER (QUality,
PERformance) was developed by Björn Regnell, Martin Höst and Richard Berntsson Svensson
in 2007. This paper aims to provide the reader with a thorough understanding of the QUPER
model. The analysis starts from the research paper “Supporting Roadmapping of Quality
Requirements” written by Björn Regnell, Richard Berntsson Svensson and Thomas Olsson. First,
the method is described in detail and, then an example in which the method is applied is given. In
the fourth section of the paper, the process-deliverable diagram of the model is drawn and,
finally, related literature about the model is analyzed.
2.
Method description
In this section of the paper, we are going to give a thorough description of the QUPER model.
First, we are going to give some general information about model, then we are going to analyze
QUPER’s three views and, finally, we are going to give some details about QUPER’s steps and
deliverables.
2.1
General information
The QUPER model aims to support requirements prioritization and roadmapping of both
functional and non-functional requirements (quality aspects) at early stages of release planning
(Regnell et al., 2007).
QUPER incorporates “quality as a new dimension in relation to cost and value, but it can be used
in combination with existing prioritization approaches.” (Regnell, Svensson, 2008). The model
was developed on the basis that quality is continuous and non-linear (Regnell, Svensson, 2008).
As QUPER focuses on both functional and non-functional requirements, there are some
characteristics that the model should have in order to be operational (Regnell, Svensson, 2008):
 Robustness to uncertainties. As the quality attributes can be very uncertain compared to
their market value and the costs of implementing them can be quite high, it is better to
Method Description – Catalina Sacu
Page 3


keep the model simple and not make it difficult by using complex mathematics or
algorithms to achieve the optimum data.
Easiness to use. Once again, the model should contain simple concepts that can be
understood and applied by all the practitioners, no matter of their mathematical skills.
Domain-relevance. The model should be adaptable to a particular domain and easy to
integrate with the company’s existing processes, methods and techniques without any
costly activities.
In order to have a clear image on the model, we are going to present a diagram that presents the
graphical overview of QUPER in the figure below. In the diagram, you can see the steps of the
QUPER model, and for each step, the correspondent views and deliverables are drawn. Each
view, step and deliverable of the model will be further described in this section.
Figure 1 – QUPER model graphical overview
2.2
QUPER views
The QUPER model consists of three views that can make companies understand better the
necessary requirements for their products and also, make a comparison with their competitors’
products in order to decide their future requirements roadmap. In order to understand the views,
it is very important to first explain two concepts as the authors present them in their paper:
breakpoint and barrier. A breakpoint represents an important change in the quality-benefit
relationship and a barrier is an important aspect of the relationship between quality and cost.
The three views of QUPER are:
Method Description – Catalina Sacu
Page 4



2.3
The benefit view that includes three breakpoints that show the main changes in the benefit
level with respect to user quality perception and market value. There are three
breakpoints related to this view (Regnell et al.,2007):
 The utility breakpoint – marks the border between the low level of quality at
which users do not accept the product on the market as they find it useless and the
level of quality at which the users start to recognize the product’s value.
 The differentiation breakpoint – marks the shift from the useful quality level to a
quality level that offers the product a competitive market position that only a few
products can reach.
 The saturation breakpoint – marks the point at which the product has excessive
quality that would not offer practical benefits to the customers.
The cost view that includes the cost barriers which denote the non-linear relationship
between quality and cost. This means that there are situations in which an increase in
quality has a low increase in costs, but also situations in which an increase in quality
determines a sharp rise in costs. So, a barrier occurs when a change in quality determines
a shift from a low level of the costs to a high one.
The roadmap view that combines the first two views by positioning the breakpoints and
barriers together on the same scale. The purpose of this view is to compare your
product’s current quality with the competitors’ products and to settle some targets for the
future releases in order to support roadmapping.
QUPER steps and deliverables
In order to apply the QUPER model, several steps have to be followed (Regnell et al., 2007) and
some deliverables have to be realized. In this part of the paper, we are going to describe these
steps and their deliverables.
1) Define the quality indicators. This is the most important step as the quality indicators are
specific to different entities and they determine the future decisions on requirements. Of
course, the deliverables of this phase consist of the identified quality indicators. The
number of quality indicators that have to be identified depends on the domain, the
product and the most-strategic use cases.
2) Define the current market expectations. This phase involves estimating the breakpoints
(the utility breakpoint, the saturation breakpoint and the differentiation one) and the cost
barriers for each quality indicator. Obviously, the deliverables of this phase are the
breakpoints values of the quality indicators and the cost barriers.
3) Identify the quality level of reference products. This allows the company to have a better
image on their estimates in order to set some future targets. The deliverables of this phase
are the quality level of the previous release and also, several quality levels for the
competing products.
4) Estimate targets for coming releases by taking into account the fact that the number of
relevant targets depends on the chosen quality indicator, each of them having different
implications on cost and benefits. The final purpose is to decide on the actual targets for
the next releases.
5) Approve and communicate roadmaps with realistic targets for software engineering.
After doing the analysis in the previous steps, you can now decide on a roadmap (which
Method Description – Catalina Sacu
Page 5
is the deliverable of this phase) in order to improve your product and find the best
balance between quality-benefit and quality-cost.
6) Revise the roadmaps and iterate any necessary steps in order to improve them. Once the
estimations become more accurate or the market situation changes, it is necessary to
refine your roadmaps, and set more realistic milestones. Also, it is important to align the
iterations of the steps with the frequency of the releases. The deliverable of this step is
also a roadmap, but an updated one.
3.
QUPER model in an example
As prioritization of the requirements necessary for developing software has become very
important, we will apply the QUPER model in a practical situation: the improvement of the time
to boot an (a bundled) operating system in a netbook. Let’s suppose the company we are working
for is Asus.
In step 1, we will define the quality indicator as being the time to boot the (bundled) operating
systems for netbooks and especially for our new product, EEE PC 1000 HD. As netbooks are
becoming more and more popular, it is very important to have a good boot time of the operating
system in order to save the battery life and make the netbooks more operational.
In step 2, we would like to analyze the current market expectations for netbooks and set the
utility, differentiation and saturation breakpoints in terms of seconds until the operating system
finishes its booting. This stage is very important in order to have a better image on what our
customers are expecting from our future products and whether or not we can accomplish their
expectations. Also, it is very important to estimate the cost barriers we could meet if trying to
overcome this breakpoints. In our case, if we want to reach the differentiation breakpoint, we
would have to face some hardware costs such as a better CPU or development costs such as
software optimization for this new architectural type. Furthermore, for the saturation breakpoint
to be achieved, there are some considerable costs that, at least, for the moment do not sustain
achieving this performance (e.g: peak performance hardware, considerable development effort
spent on redesigning the boot manager and the operating system initialization).
In step 3, once we have settled what the breakpoints for our product should be, we would like to
compare our product’s boot time with our competitors’ one to see if we can overcome them
through our quality or we have to find other ways (e.g: lower costs, better price, etc.). This step
also serves as an incentive for our company to find better solutions.
In step 4, we establish some targets for the future releases of our netbooks. We try to find some
achievable targets and what architecture modifications and costs these targets would imply. Also,
it is useful to try to estimate the time span we would need for achieving those targets.
An example of a deliverable of QUPER first four steps can be seen in table 1.
Description
Quality indicator:
Quality type:
Method Description – Catalina Sacu
Time to boot (bundled) operating system on a netbook
Performance
Page 6
Definition:
Utility:
Current
market
Differentiation:
expectations Saturation:
Competitor product X:
Reference
products
Competitor product Y:
Our product Z:
Candidate
targets for
release n
Low target:
Mid target:
High target:
Measured from when the user presses the ON button until the
operating system is fully loaded using our Eee PC 1000 HD
with Intel® Celeron M 353 CPU, at least 1 GB (DDR2),
160GB HDD.
60 sec.
30 sec.
5 sec.
55 sec.
40 sec.
50 sec.
Target rationale
40 sec. Depending on the market dynamics and the
competitors’ decisions, this time span for the
booting of the operating system might be enough.
25 sec. We could improve the boot time and, also, make
sure that it doesn’t depreciate in time by employing
a more efficient logging policy, a better process
manager and by using Solid State Disks (SDD).
However, as we are already aiming the low end
users, this might not be necessary.
10 sec. As netbooks are becoming more and more popular
and they will soon be used for a lot of common
tasks, a booting quick time will be a very important
feature. So, in order to achieve this target, we will
have to design a new architecture for the boot
manager, improve the processor’s speed and cut out
different boot elements that are not necessary for
booting or whose functions are replicated elsewhere.
Table 1 –A deliverable of QUPER’s first four steps
Once these steps have been accomplished, the other two steps (5 and 6) have to be deployed, but
since the authors are still doing some research regarding these steps, they have not provided a
template yet. The result of step 5 will be a roadmap that integrates all the results from the
previous steps (breakpoints values, competing quality level, our current release quality level, cost
barriers, our actual target for the next release). Then, for each new release, we will have to
update this roadmap in order to acknowledge the changes from the market and try to be better
than our competitors.
Consequently, the template for the deliverable of the first four steps can be seen in the table
below.
Description
Quality indicator:
Quality type:
Definition:
Method Description – Catalina Sacu
Page 7
Utility:
Current
market
Differentiation:
expectations Saturation:
Competitor product 1:
Reference
products
Competitor product 2:
…
Competitor product x:
Our product Z:
Target rationale
Candidate
targets for
release n
Target 1:
Target 2:
…
Target y:
Table 2 – A template for QUPER’s first four steps
4.
Process-deliverable diagram (PDD)
In this section of the paper, we are going to create the Process-Deliverable Diagram (PDD) of the
QUPER, also including a description of the diagram and the activity and deliverable tables.
The Process-Deliverable Diagram can be seen in the figure below.
Method Description – Catalina Sacu
Page 8
Figure 2 – QUPER process-deliverable diagram
Method Description – Catalina Sacu
Page 9
The diagram shows that the process of creating a quality level roadmap for a future release of a
product includes three phases: Define quality indicators and their current market expectations,
Estimate reference products’ quality and future quality targets, Deliver quality requirements
roadmap. As it can be seen, the roles involved in the QUPER model are represented just by the
team that is working on a certain project. It involves the project manager and the other members
that usually prioritize requirements, create roadmaps and do release planning.
The first phase is: Define quality indicators and their current market expectations. The purpose
of this phase is to, first, define the quality indicators that will be analyzed, and then, determine
the breakpoints (utility, differentiation, saturation) and the cost barriers that can appear. The
breakpoints are important because they can offer a clear image on the current market
expectations. The analyzed cost barriers will give the team the opportunity to see exactly the
necessary costs for developing the desired quality indicators. The deliverables of this phase are
the quality indicators with the characteristic breakpoints and the cost barriers.
The second activity is: Estimate reference products’ quality and future quality targets. First, the
team focuses on analyzing the market in order to determine what the quality levels of our
competing products are. This is important as we would have to implement a value for our quality
indicators that is, at least, as good as the ones of our competitors’. If the cost barriers do not
allow it, we will have to find other ways to overcome our competitors (e.g: lower costs, better
price, etc.). Also, we will see what the value of the quality indicators for our previous release is.
These two sub-activities will help us to further calibrate our estimates and have objective
measures to relate our targets to. Then, the team will have to estimate targets for future releases,
propose candidate targets and decide on actual targets. The number of relevant targets depends
on the quality indicator.
Once these activities are finished, we can now proceed with the last phase which is the one of
creating and delivering the final quality level roadmap for future releases. This roadmap is an
aggregation of the already created deliverables. The QUPER model and the roadmap view
provide a rationale when deciding what level of quality we need for a particular feature, in a
certain market segment for the next release and releases after that. Once a roadmap is finished, it
will have to be reviewed and updated for every certain release. This will be done by iterating the
necessary steps as estimates become more certain or circumstances change (e.g: market has
matured and developed, we want to enter new market segments (different quality levels may be
necessary), our competitors have improved their quality level). The iterations have to be aligned
with the release frequency.
The activities and their sub-activities from the PDD are described in the following table.
Activity
Sub-activity
Description
Define quality indicators and
their current market expectations
Define quality indicators
The purpose of this activity is to state the QUALITY
INDICATOR(S) that will be analyzed, by also giving
the quality type and a short description.
Method Description – Catalina Sacu
Page 10
Estimate reference products’
quality and future quality targets
Deliver quality requirements
roadmap
Determine the utility breakpoint
For each quality indicator, the utility breakpoint is
estimated by determining the lowest acceptable
quality value on the current market.
Determine the differentiation
breakpoint
For each quality indicator, the differentiation
breakpoint is estimated by determining the quality
value that marks the shift from useful to competitive
quality.
Determine the saturation breakpoint
For each quality indicator, the saturation breakpoint is
estimated by determining the quality value considered
to be excessive in the current market.
Estimate cost barriers
Once the benefits breakpoints are determined, the
COST BARRIERS that can occur are estimated. A
barrier can be determined when the cost for
implementing a specific quality aspect shifts from a
plateau-like situation where an increase in quality has
a low penalty to a sharp rise where an increase in
quality has a high cost penalty.
Identify competing products’
quality level
The COMPETING QUALITY LEVEL(S) is (are)
determined in order to have a better image on what the
customers would expect from our product. This is
done by analyzing the market and see what the quality
levels of our competing products are.
Identify current quality level
The CURRENT QUALITY LEVEL for one of our
releases is determined by looking at the quality level
for our current release of the product.
Estimate quality targets for future
releases
The purpose of this activity is to decide on candidate
targets for the product release n by estimating a
number of relevant QUALITY TARGETS (e.g: low,
mid or high target) depending on the QUALITY
INDICATOR.
Create roadmap for future releases
The purpose of this phase is to create an initial quality
requirements ROADMAP by aggregating the already
created deliverables (QUALITY INDICATORS,
COST BARRIERS, COMPETING QUALITY
LEVEL(S), CURRENT QUALITY LEVEL) in order
to have a common vision for the future release.
Review roadmap
Once the ROADMAP is created, it has to be reviewed
before any new release in order to be sure the
information is correct.
Method Description – Catalina Sacu
Page 11
If some of the information in the ROADMAP has
changed (e.g: market has matured and developed, we
want to enter new market segments (different quality
levels may be necessary), our competitors have
improved their quality level), the ROADMAP has to
be updated by iterating the necessary steps.
Update roadmap
Table 3 – QUPER activity table
The definitions of the concepts and deliverables from the PDD are given in the table below.
Concept
Definition
(SOFTWARE) QUALITY INDICATOR
A variable whose value can be determined through direct analysis
of product or process characteristics, and whose evidential
relationship to one or more attributes is undeniable (Nance and
Arthur, 2002). A quality indicator is characterized by three
breakpoints (the utility breakpoint, the differentiation breakpoint
and the saturation breakpoint) that are expressed in different
measuring units depending on the quality indicator (Regnell and
Svensson, 2008).
COST BARRIER
The resources and time needed to progress toward more costeffective forms of collaboration (Lasser and Heiss, 2005), also
considered to be a barrier that occurs when the cost shifts from a
plateau-like situation where an increase in quality has a low cost
penalty, to a sharp rise where an increase in quality has a high cost
penalty (Regnell and Svensson, 2008).
COMPETING QUALITY LEVEL
Degree to which a set of competing products inherent
characteristics fulfills the customer’s requirements (ISO9000,2005).
The standard defines requirement as need or expectation.
CURRENT QUALITY LEVEL
Degree to which a current set of inherent characteristics fulfills the
customer’s requirements (ISO9000, 2005).
QUALITY TARGET
Requirements with potential quality commitment (Regnell and
Svensson, 2008).
(PRODUCT) ROADMAP
A disciplined, focused, multiyear approach to product planning
(Vähäniitty et al., 2002) that can also be seen as a common vision
with realistic targets for downstream systems and software
engineering (Regnell and Svensson, 2008).
Table 4 – QUPER concept table
Method Description – Catalina Sacu
Page 12
5.
Related literature
5.1
Topic origins
As requirements prioritization and cost-analysis have become very important in order for the
requirements engineers to be able to select the products’ requirements, there is some research
done in this field. Consequently, there are a few papers that represent the foundation for the
QUPER model, even if the models presented there can differ to a considerable extent if
compared to QUPER.
Looking back into the past, we can see that in 1966 a new “method to transform user demands
into design quality, to deploy the functions forming quality, and to deploy methods for achieving
the design quality into subsystems and component parts, and ultimately to specific elements of
the manufacturing process” (Akao, 1966), called Quality Function Deployment (QFD), was
developed. QFD transforms customer’s needs into engineering characteristics by gathering and
organizing the customer’s and user’s requirements, establishing the relationships between them
in a relationship matrix, add some control characteristics and also, prioritizing them (Karlsson,
1997). But, even if the method has been successfully applied in various industries, services, etc.
and, even if it focuses on both functional and non-functional requirements, it still is a very
complex model that might require a company to completely change its practices. On the other
hand, QUPER is a simple model with concepts that are easy to understand and apply, possible to
be used with the company’s current approach. But, it is clear that QFD is one of the origins for
QUPER.
Moreover, one of the models regarding the patterns of quality was developed by Noriaki Kano
and his colleagues (Kano, 1980). The main goal of this model is to offer some insight into the
product attributes that are perceived to be important to customers (Matzler, Hinterhuber, 1998).
They consider that value, quality and innovation shouldn’t be mutually exclusive goals and by
applying this model, it is possible to see which product attributes should be present. In order to
do this, Kano and his colleagues analyze the fact that customers have both conscious and
subconscious needs that can be satisfied by implementing precise quality attributes. The results
are displayed in a 2D graph taking into account the fact that there are three types of needs: basic,
performance and excitement. Like QUPER, this model views quality as being nonlinear, but it
does not include the cost dimension.
A way of prioritizing requirements is also provided in (Karlsson, Ryan, 1997). The authors rank
the candidate requirements in two dimensions depending on their value to users and their
estimated cost of implementation (Karlsson, Ryan, 1997). Also, they analyze three factors that
influence the stakeholder’s satisfaction:
 quality that has to be maximized
 cost that has to be minimized
 time to delivery that has to be minimized.
In order to investigate candidate requirements, this approach uses the Analytic Hierarchy Process
(Saaty, 1980) to do pair-wise comparisons between requirements according to their relative value
and cost. There are five steps to prioritize the requirements and then the results are put in a costvalue diagram that will provide support for the software managers to decide on the prioritization.
Method Description – Catalina Sacu
Page 13
Even if probably this approach is close to the QUPER model, it only deals with the functional
requirements without addressing explicitly the quality attributes.
Probably another method that stands as a foundation for QUPER is the Architecture Trade-off
Analysis Method (ATAM) developed by Rick Kazman and his colleagues. It is “a method for
evaluating architectural level designs that considers multiple quality attributes such as
modifiability, performance, reliability, security” (Kazman et al., 1998) to see whether the
architecture will meet its requirements or not. Also, the method considers that each quality
attribute has connections with other attributes and that is the reason why it first tries to analyze
the attributes individually, then determine the sensitivity points between them and finally the
trade-offs among them. As we can see, there is a connection between ATAM and QUPER, but
while the former considers decision making at architectural level, the latter goes one level up and
takes into consideration the market evolution and tries to develop requirements roadmaps and
release planning.
A more recent method regarding implementation and prioritization of requirements is the one
called “Gilb Style” (Gilb, 2005) that focuses on (Jacobs, 1999):
 quality requirements
 quantification
 strict separation between design and requirements
 constraints and assumptions.
As the requirements are divided into functional, quality, constraints and cost and the method
sustains the breakdown of requirements into sub-requirements and offers source information for
all the requirements, the “Gilb Style” could be used together with QUPER and is probably the
closest methods related to it.
As QUPER involves managing the requirements lifecycle management, I consider that two other
methods relate to the model described in this paper. They were both developed at two Swedish
companies and proved to be efficient. The first method is called REPEAT (Requirements
Engineering Process at Telelogic) and the second one, RDEM (Requirement Driven Evolution
Model). They both have lifecycle management models which contain different requirements
states “representing the refinement level of each individual requirement in its progress towards
release” (Carlshamre, Regnell, 2000). Also, both methods have well defined roles and
responsibilities in order for the release lifecycle management to be done more efficiently. As
REPEAT is more focused on time-to-market, whereas RDEM is more focused on quality, there
are some differences between the two. A difference can be observed in the types of attributes
defined in every method: the REPEAT attributes are mainly production-oriented, while the
RDEM attributes have a stronger focus on quality issues. As we can see, QUPER seems to have
some common elements with the above described methods, but it brings something new by
giving the opportunity of defining breakpoints and barriers for each quality indicator.
5.2
Topic elaboration and description
As QUPER model has recently been implemented (2007), there is not a lot of literature that
describes and elaborates on it, except for two papers.
Method Description – Catalina Sacu
Page 14
The first one is called “A Quality Performance Model for Cost-Benefit Analysis of NonFunctional Requirements Applied to the Mobile Handset Domain”, written by Björn Regnell,
Martin Höst, and Richard Berntsson Svensson and presented at the Working Conference on
Requirements Engineering: Foundation for Software Quality (REFSQ’07) in 2007. It presents
the conceptual model of QUPER and does a validation of the model through some interviews
with requirements experts in six cases that represent important areas in the mobile handset
domain.
The second paper is called “Supporting Roadmapping of Quality Requirements”, written by
Björn Regnell, Richard Berntsson Svensson and Thomas Olsson and published in 2008. This
paper is a shorter version of the first one, without providing new information related to the
model. Some of the parts are only mentioned without giving many details about them.
Also, if we search the papers on Google Scholar, we will see that the first one is not cited by any
other paper, while the second paper is cited only by three other papers, one of them being
(Regnell, Svensson, 2008). The two other papers are (Olsson et al., 2007) and (Regnell et al.,
2008). As we can see, the authors of the papers are the same as the ones who implemented the
QUPER model. In the last two papers mentioned, they just make a reference to (Regnell et al.,
2007), without elaborating new research on the QUPER method.
5.3
Application of the model
As already mentioned, there is not much literature that could provide us information about the
QUPER model, except for the two papers mentioned above. Several applications of the model
are described in (Regnell et al., 2007) as the research and validation of the model were done at
two case companies in the mobile handset domain. The latter consisted of six interviews carried
out individually by the authors in selected mobile-phone sub-domains: local connectivity,
positioning, Java platforms, mobile TV, memory, and radio network access. The interviews were
documented by note taking. The notes were summarized into an interview report which was
presented to each interviewee for validation. Then some minor corrections and clarifications
were made. For every sub-domain, several quality indicators were defined and then, the
breakpoints benefits and cost barriers were determined and explained.
After applying the model in all the six sub-domains, there were some conclusions drawn. First of
all, it was possible, in general, to define benefit breakpoints and cost barriers. Also, the
interviewees acknowledged the usefulness of the QUPER model, but they raised two problems
like “how many and which quality indicators should be managed?” (Regnell et al., 2007) and
“how do you manage dependencies between quality indicators?” (Regnell et al., 2008). These
and some other reported issues are some of the reasons for doing some future research for this
model.
In the second paper, (Regnell, Svensson, 2008), the same validation is presented, but, as
mentioned before, in a shorter version. More research on this topic will probably be done in the
future and more papers will be published.
Method Description – Catalina Sacu
Page 15
6.
Conclusions
The analysis made in this paper showed that QUPER model enriches the picture of quality
requirements by allowing a better communication and understanding between the software
engineers and the end-users. Also, the validation of the model in the mobile-phone domain
showed its usefulness, this making us believe that it can also be applied in other domains where
product-line products are developed. Consequently, by incorporating quality as a dimension in
addition to cost and value, QUPER model has proved to have a great impact in the releaseplanning decisions and in the estimation of requirements roadmaps, thus in the requirements
engineering domain. As Fred Brooks wrote, “The hardest single part of building a software
system is deciding precisely what to build. No other part of the conceptual work is so difficult as
establishing the detailed technical requirements… No other part of the work so cripples the
resulting system if done wrong. No other part is more difficult to rectify later.”(Brooks Jr.,
1995). This proves that research will continue not only for the QUPER model, but also in the
requirements engineering domain as a whole.
7.
References
Brooks, Jr., F.P. (1995). No silver bullet. In F.P. Jr. Brooks (Eds.), The Mythical Man-Month:
Essays on Software Engineering (pp. 179-203). Boston: Addison Wesley Longman.
deBaud, J.M. & Schmid, K. (1999). A systematic approach to derive the scope of software
product lines. Proceedings of the 21st International Software Engineering Conference, Los
Angeles, USA, 34-43.
Carlshamre, P. & Regnell, B. (2000). Requirements Lifecycle Management and Release
Planning in Market-Driven Requirements Engineering Processes. Proceedings of the 11th
International Workshop on Database and Expert Systems Applications, Greenwich, UK, 961–
965.
Davis, A.M. & Hsia, P. (1994). Giving Voice to Requirements Engineering. IEEE Software,
11(2), 12-16.
Dikel, D., Kane, D., Ornburn, S., Loftus, W. & Wilson, J. (1997). Applying software productline architecture. IEEE Computer 30(8), 49–55.
ISO 9000:2005 (2005). Quality management systems -- Fundamentals and vocabulary.
International Organization for Standardization. Retrieved February 6, 2008, from
http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=42180.
Jacobs, S. (1999). Introducing measurable quality requirements: a case study. Proceedings of the
4th IEEE International Symposium on Requirements Engineering, Limmerick, Ireland, 172–179.
Method Description – Catalina Sacu
Page 16
Kano, N., Seraku, N., Takahashi, F. & Tsuji, S. (1984). Attractive Quality and Must-Be Quality.
Hinshitsu: The Journal of the Japanese Society for Quality Control, 14(2), 39–48.
Karlsson, J. (1997). Managing Software Requirements Using Quality Function Deployment.
Software Quality Journal 6(4), 311–325.
Karlsson, J. & Ryan, K. (1997). A cost-value approach for prioritizing requirements. IEEE
Software 14(5), 67–74.
Kazman, R., Klein, M., Barbacci, M., Longstaff, T., Lipson, H. & Carriere, J. (1998). The
Architecture Tradeoff Analysis Method. Proceedings of the 4th International Conference on
Engineering of Complex Computer Systems, Monterey, CA, USA, 68–78.
Lasser, S. & Heiss, M. (2005). Collaboration Maturity and the Offshoring Cost Barrier: The
Trade-Off between Flexibility in Team Composition and Cross-Site Communication Effort in
Geographically Distributed Development Projects. Proceedings of the International Professional
Communication Conference, Limerick, Ireland, 718-728.
Matzler, K. & Hinterhuber, H.H. (1998). How to make product development projects more
successful by integrating Kano's model of customer satisfaction into quality function
deployment. Technovation, 18(1), 25-38.
Nance, R. E. & James D. A (2002). Managing Software Quality: A Measurement Framework for
Assessment and Prediction, Springer.
Olsson, T., Svensson, R. & Regnell, B. (2007). Non-functional requirements metrics in practice
– an empirical document analysis . Proceedings of the Workshop on Measuring Requirements for
Project and Product Success, Palma de Mallorca, Spain, 73-87.
Regnell, B. & Brinkkemper, J. (2005). Market-Driven Requirements Engineering for Software
Products. In A. Aurum & C. Wohlin (Eds.), Engineering and Managing Software Requirements.
(pp. 287–308). Heidelberg: Springer.
Regnell, B., Höst, M. & Svensson, R. (2007). A Quality Performance Model for Cost-Benefit
Analysis of Non-Functional Requirements Applied to the Mobile Handset Domain. Proceedings
of the Requirements Engineering Conference: Foundation for Software Quality, Trondheim,
Norway, 277–291.
Regnell, B., Svensson, R.B. & Olsson, T. (2008). Supporting Roadmapping of Quality
Requirements. IEEE Software, 25(2), 42-47.
Regnell, B., Svensson, R. & Wnuk, K. (2008). Can We Beat the Complexity of Very LargeScale Requirements Engineering? Proceedings of the 14th international conference on
Requirements Engineering: Foundation for Software Quality, Montpellier, France, 123-128.
Method Description – Catalina Sacu
Page 17
Saaty, T. (1980). The Analytic Hierarchy Process. New York: McGraw-Hill.
Vähäniitty J., Lassenius C. & Rautiainen K. (2002). An Approach to Product Roadmapping in
Small Software Product Businesses. Proceedings of the 7th European Conference on Software
Quality, Helsinki, Finland, 12-13.
Weerd, I. van de, Brinkkemper, S. (2008). Meta-modeling for situational analysis and design
methods. In M.R. Syed and S.N. Syed (Eds.), Handbook of Research on Modern Systems
Analysis and Design Technologies and Applications (pp. 38-58). Hershey: Idea Group
Publishing.
Final remarks
Method Description – Catalina Sacu
Page 18