J. Karlsson and K. Ryan, "A Cost-Value Approach for Prioritizing Requirements," IEEE Software, vol. 14, no. 5, Sept./Oct. 1997, pp. 67--74.  Home/Search   Document Not in Database   Summary   Related Articles   Check

....is able to improve both, the accuracy and the precision of the estimates as shown by Figure 1.b. Although not new, the idea has received very little attention in the literature. Earlier work includes Target Software s Software Sizing Method [4] and more recently an article by Focal Point AB [5] where an instance of the method, called the Analytic Hierarchical Process, is used to prioritize requirements relative to their cost. Overall Approach As Figure 2 shows, first the artifacts to be sized are arranged according to their perceived largeness. Once this is done, the relative size of ....

....Figures 6, 7, 8 and 9. on them, the area of the circles corresponds to the standard deviation of the observations. The purpose of the first experiment was to evaluate the robustness of the method under the conditions described bellow using controlled inputs. 1. Reference values, E i , in KSLOC: [50, 30 ,25, 24, 24,10, 9, 8, 5, 5]; 2. Estimation with simulated judgements (E i E j ) e, where e is a random variable with normal distribution, 0 and s = 15 (E E j ) In other words, assuming that 68 of the time, the judgements are within 15 of their true value; A perfectly consistent judgement matrix is one in which ....

J. Karlsson & K. Ryan, A Cost-Value Approach for Prioritizing Requirements, IEEE Software, September/October 1997

....The negotiation process is supported by the WinWin groupware tool which visualises links between stakeholders win conditions, issues, options and negotiated agreements, enables negotiations, and records changes, but does not attempt to resolve any of the issues automatically. Karlsson and Ryan [31] use the Analytic Hierarchy Process to determine cost bene t tradeo s for a set of requirements. The relative value of requirements is determined by customers and users, and the relative cost is determined by the developers. These results are then combined and the system stakeholders use the ....

Karlsson, J., and Ryan, K. A cost-value approach for prioritizing requirements. IEEE Software 14, 5 (September/October 1997), 67-74.

....The negotiation process is supported by the WinWin group ware tool which visualises links between stakeholders win conditions, issues, options and negotiated agreements, enables negotiations, and records changes, but does not attempt to resolve any of the issues automatically. Karlsson and Ryan [31] use the Analytic Hierarchy Process to determine cost benefit tradeoffs for a set of requirements. The relative value of requirements is determined by customers and users, and the relative cost is determined by the developers. These results are then combined and the system stakeholders use the ....

KARLSSON, J., AND RYAN, K. A cost-value approach for prioritizing requirements. IEEE Software 14, 5 (September/October 1997), 67-74.

.... construction effort is currently planned for the next software release Which customer category will be most satisfied with the current set of planned requirements How long does it on average take for a requirement to go from approved to specified The research on requirements prioritisation [7] is a striking example of how an old technique from decision theory Analytical Hierarchy Process (AHP) 8] after adaptation to RE, can support and improve decisionmaking in a new context. When adopting existing decision support methods to the special case of software requirements, it is ....

Karlsson, J. and Ryan, K. "A Cost-Value Approach for Prioritizing Requirements", IEEE Software, September/October 1997.

....of a caller, as over time callers learn tactics for publicizing or hiding their identity. Functional Morphology and Value Analysis Numerous proposals have been made for assigning priorities to features or requirements and managing tradeoffs involving multiple requirements and design criteria [Boe95, KR97]. Sullivans [Sul96] application of real options theory to the valuation of product features is a more recent and economically more sophisticated contribution of the same kind. These approaches all have in common the provision of a normative basis for decision making and prioritization, a ....

Karlsson, J. & K. Ryan. "A Cost-Value Approach for Prioritizing Requirements". IEEE Software, pp. 6774, 1997.

.... on short time to market is evident [10, 7] The achievement of high software quality in a market driven context is inherently related to the challenge of meeting customers demands [4] Market driven Requirements Engineering processes [1, 3] have a strong focus on requirements prioritization [6, 5] and often deliver incremental releases of a continuously evolving product [8] This paper describes and compares two RE processes used at different companies (Ericsson Radio Systems AB and Telelogic AB) which both address the challenges of market driven software development. Traditional ....

Karlsson, J., Ryan, K., "A Cost-Value Approach for Prioritizing Requirements", IEEE Software, September/October 1997.

....we call usage based reading. Scenario based requirements can be the basis for a model of system usage. To be able to conduct usage inspections, we need to annotate the scenarios with priority information. Techniques based on pairwise com 6 Accepted at REFSQ 98 parison may be used here [22]. By comparing pairs of scenarios ( we may prioritize them according to criteria such as is more frequently used than and is more critical to hazard than . With the method in [22] it is possible to derive the relative priority , of each scenario . Based on this, we propose to ....

....priority information. Techniques based on pairwise com 6 Accepted at REFSQ 98 parison may be used here [22] By comparing pairs of scenarios ( we may prioritize them according to criteria such as is more frequently used than and is more critical to hazard than . With the method in [22] it is possible to derive the relative priority , of each scenario . Based on this, we propose to conduct usage based inspections of design or code documents using the following scheme of effort partitioning: 1.Prioritize the scenarios according to [22] 2.Decide on the total time T to ....

[Article contains additional citation context not shown here]

Karlsson, J., Ryan, K., "A Cost-Value Approach for Prioritizing Requirements", IEEE Software, pp. 67--74, September/October 1997.

....to a long term product strategy for a range of market segments. An important issue here is how to incorporate the expertise from marketing departments and the visions of top level management in the prioritization process. This paper focuses on how to elevate a prioritization strategy, such as [5] or [1] by making differences in the priorities of the various market segments explicit. Accepted for publication at REFSQ 2000. Regnell, Hst, Natt och Dag, Beremark, Hjelm. Feb 2000. 2 6th Int. Workshop on Requirements Engineering: Foundation for Software Quality, June 5 6 2000, Stockholm, ....

....of a fictitious amount of money on each requirement in accordance to its perceived importance. The assessment of priorities through assignment of absolute numerical values is inherently difficult, and there are strong indications that relative judgements is easier for humans and also more accurate [5]. There are several candidate techniques involving relative judgement through pairwise comparison [6] and one of the most promising technique is the Analytical Hierarchy Process (AHP) 11] This technique is, however, not in its original form adapted to distributed prioritization with multiple ....

Karlsson, J., Ryan, K., "A Cost-Value Approach for Prioritizing Requirements", IEEE Software, September/October 1997.

....and avoid congestion, a more efcient approach to the sorting of requirements is need. Currently the selection is made using expert judgement. A smart grouping of requirements based on the use cases to which they are related, combined with a systematic cost value prioritisation approach [12, 13] applied to use cases instead of single requirements, may speed up the selection process. Fig. 9. An informal depiction of the REPEAT process performance challenge of bridging the chasm between elicitation and selection. REPEAT 1 process performance Time Elicitation Phase Selection Phase ....

Karlsson, J., Ryan, K., A Cost-Value Approach for Prioritizing Requirements, IEEE Software, September/October 1997.

....an actual usage of DCPT for prioritizing new requirements for USC s popular WinWin system. 2. RELATED WORK Relatively few research efforts have been done on the area of requirement prioritization and application to the software development process [1] Some recent work by J. Karlsson and K. Ryan [2, 3] uses the Analytic Hierarchy Process (AHP) 10] to prioritize each requirement s relative value and implementation cost, which are then plotted on a cost value diagram. H. Jung extended Karlsson and Ryan s work with a variant of the 0 1 knapsack model that reduces the complexity of prioritization ....

....importance) average difficulty) The other regions are determined by adding and subtracting a value of 0 3 standard deviations (fractions allowed) of the importance and difficulty from the numerator and denominator respectively. This model is similar to Karlsson and Ryan s cost value model [3], which can be, interpreted as Return OnInvestment (ROI) However, in their work the regions were fixed rather than relative to the averages as described above. Fig. 4. Ratio Model. Item 1 has the largest Return OnInvestment (ROI) Item 2 has a medium ROI. Items 3, 4, 5, and 6 have the ....

J. Karlsson, K. Ryan, "A Cost-Value Approach for Prioritizing Requirements", IEEE Software, Sept. 1997, pp. 67-74.

....them. These scores either determine the benefits that the alternatives deliver or determine the costs that the alternatives entail. In either case, the scores provide an obvious way to rank the alternatives and to choose the best alternative to achieve the goal. Analytic hierarchy process, AHP [2, 3, 4, 5, 6, 7], is a frequently used quantitative method for ranking alternatives based on the aggregated effects of a number of goal attributes. Each attribute is assigned a weight specifying its contribution to the goal. The alternatives, in turn, are evaluated on each attribute and assigned per attribute ....

Karlsson , J and K. Ryan, A Cost-Value Approach for Prioritizing Requirements, IEEE Software, Vol. 14(5), September/October, 1997 pp. 67-64.

....is described more thoroughly in subsequent chapters. The most prolific researchers in this area have been Karlsson and Ryan along with a couple of colleagues. The most thorough description of their work is the licenciate thesis by Karlsson [39] Most of the articles describe the same body of work [40, 42, 43]. The work is continued in [41] The work of Karlsson and Ryan and their colleagues is based on three tools: QFD, AHP and cost e#ectiveness analysis. Their contribution has been an important step in introducing some available practical decision tools into the requirements engineering community. ....

....that is, determine the additional revenue resulting from the implementation of a requirement, subtract from it the cost of designing and implementing the requirement. Choose those requirements that yield the highest (non negative) profits. cost e#ectiveness analysis: Karlsson and Ryan [39, 66, 43] have used the cost e#ectiveness approach, where all costs are converted to one measure, and all benefits are converted to a second measure, but these two measures are not converted to a single one. Instead of comparing the costs vs. benefits by subtracting benefits from costs, the problem is ....

[Article contains additional citation context not shown here]

Karlsson, J., and Ryan, K. A cost-value approach for prioritizing requirements. IEEE Software (Sept.--Oct. 1997), 67--74.

.... In a similar fashion, a classification of common interactions among non functional attributes of software development has been used to annotate the ways in which requirements conflict [19] Finall y, relationships other than conflict have been considered, such as the cost benefit of requirements[124]. 4.2.1 Uses of the Term Conflict Table 3 summarizes the most general types of interactions found in the requirements engineering related literature. As would be expected, they are divided into correlation types of positive, negative, unspecified, and independent. A more refined analysis of the ....

....to important requirements solves a few important conflicts, but can introduce many other conflicts. Thus, one may need to reconsider the importance of a requirement in the face of trade offs among many other requirements. Research into cost value trade offs of requirements can assist this process[124]. Requirements interaction can also be partitioned using the same means to partition a large set of requirements. See section 4.1. Thus, one could consider all interactions found in a partition of a: stakeholder, scenario, requirement subsumption hierarch y, etc. In fact, decision science ....

Karlsson, J., Ryan, K., A Cost- Value Approach for Prioritizing Requirements, IEEE, Software, September, 1997.

....It is clear that ADTs are a solution domain concept with limited relevance in the problem domain. In addition, this work requires using a development methodology based on ADTs. The goal of delivering ADT based prototypes transcends analysis and forces a particular design choice. Karlsson and Ryan [46] seek to prioritize requirements using a cost value evauation of pairs of requirements. Since the number of requirements pairs grows as the square of the number of requirements, their approach is suited to high level requirements identified in the problem domain. Such requirements are equivalent ....

J. Karlsson and K. Ryan. A Cost-Value Approach for Prioritizing Requirements. IEEE - Software, 14(5):67--74, Sep/Oct 1997.

....product is expected to exhibit. Developers must translate such requirements into appropriate design choices and then into software artifacts [3] The requirements engineering community has recognized the utility of structuring the problem domain, using terms such as high level requirements [6] and requirements clusters [5, 8] However, while some requirements engineering e#orts seek to structure a system s requirements by its gross functional entities (i.e. its features) there is little or no connection made in those terms with later stages of software development. For instance, ....

J. Karlsson. A Cost-Value Approach for Prioritizing Requirements. IEEE Software, 14(5):67--74, September 1997.

No context found.

Karlsson, J., Ryan, K., "A Cost-Value Approach for Prioritizing Requirements", IEEE Software, Sept/Oct 1997, pp. 67-74.

....for each requirement) but the postponed or rejected requirements need to be re estimated based on the eventual architectural decisions and the knowledge gained from the actual design of the subsequent releases. By using, for example, a cost value prioritisation approach with pairwise comparisons [8, 9], an ordered priority list can be obtained where the requirements with a higher market value and a lower cost of development are sorted in the priority order list before the requirements with a lower market value combined with a higher development cost. The purpose of the re estimation is to ....

....for eliciting, reviewing, structuring, and prioritising requirements as well as for planning optimal releases that maximise the value for the most important customers in relation to development time and available resources. One prioritisation method in Focal Point is pairwise comparisons [8]. It is helpful for keeping up concentration and objectivity and Focal Point also provides solutions for reducing the number of comparisons and motivating the priorities. This tool also aids in visualising the decision in a number of different chart types. Due to redundancy of the pair wise ....

[Article contains additional citation context not shown here]

Karlsson, J., Ryan, K., "A Cost-Value Approach for Prioritizing Requirements", IEEE Software, Sept/Oct 1997, pp. 67-74.

.... of the specifications and the knowledge increases as natural language requirements are refined, analysed, and formalised [14] There is, however, a risk that relationships between requirements are overlooked or discovered too late, which in turn may cause problems in requirements prioritisation [6] and release planning [1] Consequently, there is a need to find requirements relations early, without spending too much time on in depth analysis. These relationships are preferably found even when specification quality is low and even if requirements are short, poorly worded or misspelled. Two ....

Karlsson, J., Ryan, K., "A Cost-Value Approach for Prioritizing Requirements", IEEE Software, September /October 14(5), pp. 67-74, 1997.

No context found.

J. Karlsson and K. Ryan, "A Cost-Value Approach for Prioritizing Requirements," IEEE Software, vol. 14, no. 5, Sept./Oct. 1997, pp. 67--74.

No context found.

Karlsson, J. & Ryan, K. (1997). A Cost-Value Approach for Prioritizing Requirements. IEEE Software(September/October): 67-74.

No context found.

Joachim Karlsson, Kevin Ryan, "A Cost-Value Approach for Prioritizing Requirements", IEEE Software, September/October 1997

No context found.

J. Karlsson and K. Ryan, A cost-value approach for prioritizing requirements, IEEE Software 14: 5, Sep#Oct 1997, 67#74.

Online articles have much greater impact   More about CiteSeer.IST   Add search form to your site   Submit documents   Feedback  

CiteSeer.IST - Copyright Penn State and NEC