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