A Broad, Quantitative Model for Making Early Requirements Decisions.

IEEE Software 01/2008; 25:49-56.
Source: DBLP


Although detailed information is typically scarce during a project's early phases, developers frequently need to make key decisions about trade-offs among quality requirements. Developers in many fields-including systems, hardware, and software engineering-routinely make such decisions on the basis of a shallow of the situation or on past experience, which might be irrelevant to the current a consequence, developers can get locked into what is ultimately an inferior design or pay a significant price to reverse such earlier decisions later in the process. By coarsely quantifying relevant factors, a risk-assessment model helps hardware and software engineers make trade-offs among quality requirements early in development.

Download full-text


Available from: James D. Kiper, Dec 19, 2013
1 Follower
27 Reads
  • Source
    • "It uses a Bayesian Belief Net with a fixed set of trade-off parameters to support design decisions . Feather et al. [3] propose a quantitative model for strategic decision analysis and trade-off analysis considering quality requirements, by the " coarse quantification " of relevant risk factors and their interactions. In [18], fuzzy logic values are used for representing and reasoning on the satisfaction degree of imprecise (quality) requirements. "
    [Show abstract] [Hide abstract]
    ABSTRACT: Simultaneously satisfying multiple interacting and possibly conflicting software requirements is challenging. Quantitative cost-benefit analysis of alternative solutions is often hard or biased, and early decisions based on numerical estimates of requirements satisfaction are thus unreliable. We propose a trade-off analysis method that assists decision making in the absence of numerical data. We structure the requirements trade-off problem in terms of a goal model containing alternative design solutions and decision criteria. We propose a trade-off analysis algorithm that takes pair-wise comparisons of alternatives and determines the best solution among alternatives. The optimum alternative is decided by using a heuristic method, which may need to consult with domain experts. We take advantage of the Even Swaps method [1] to incorporate stakeholders' preferences into the decision analysis. The algorithm is implemented in a prototype tool and evaluated in an industrial case study.
    Proceedings of the 2011 ACM Symposium on Applied Computing (SAC), TaiChung, Taiwan, March 21 - 24, 2011; 01/2011
  • Source
    • "4) Scalability: the decision problem may become complicated and impossible to be analyzed manually due to numerous requirements and/or alternatives. Some decision analysis methods evaluate consequences of alternative solutions in terms of precise and meaningful quantitative measures [1], [7], [11]. Some decision analysis approaches such as Analytical Hierarchy Process (AHP) [12] and Even Swaps [13] circumvent the need to measure requirements and consequences of solutions. "
    [Show abstract] [Hide abstract]
    ABSTRACT: System designers and requirements analysts face many competing requirements, such as performance, usability, security, cost, and so forth. To make trade-offs among requirements, ideally analysts would like to quantitatively measure consequences of alternative solutions on requirements. However, during the early stages of requirements and system design, it is hard to quantitatively measure all factors and quantify stakeholders' preferences. The Even Swaps method is a technique developed in management science to assist in multi-criteria decision making which allows the use of available but potentially incomplete quantitative and qualitative measures. It teases out the need to elicit importance weights of requirements. Instead, stakeholders are asked how much they would relax one objective to better achieve another. We apply the Even Swaps technique to requirements trade-offs, and supplement it with an algorithm that automates the decision analysis process. The algorithm fins the most distinguishable pair of alternatives and suggests the next requirements to be swapped to stakeholders.
    Proceedings of the CAiSE Forum 2011, London, UK, June 22-24, 2011; 01/2011
  • Source
    • "The idea to analyze this kind of data is similar to quality spectrum analysis [2], but comparative analysis mentioned in introduction is not proposed in the article [15]. In DDP (defect detection prevention) [16], [17], the relationships among requirements, risks and their mitigations are visualized. Although this visualization shows a macro-view of quality requirements, trade-offs between risks and their mitigation costs are mainly focused. "
    [Show abstract] [Hide abstract]
    ABSTRACT: Quality requirements are scattered over a requirements specification, thus it is hard to measure and trace such quality requirements to validate the specification against stakeholders' needs. We proposed a technique called ``spectrum analysis for quality requirements'' which enabled analysts to sort a requirements specification to measure and track quality requirements in the specification. In the same way as a spectrum in optics, a quality spectrum of a specification shows a quantitative feature of the specification with respect to quality. Therefore, we can compare a specification of a system to another one with respect to quality. As a result, we can validate such a specification because we can check whether the specification has common quality features and know its specific features against specifications of existing similar systems. However, our first spectrum analysis for quality requirements required a lot of effort and knowledge of a problem domain and it was hard to reuse such knowledge to reduce the effort. We thus introduce domain knowledge called term-characteristic map (TCM) to reuse the knowledge for our quality spectrum analysis. Through several experiments, we evaluate our spectrum analysis, and main finding are as follows. First, we confirmed specifications of similar systems have similar quality spectra. Second, results of spectrum analysis using TCM are objective, i.e., different analysts can generate almost the same spectra when they analyze the same specification.
    IEICE Transactions on Information and Systems 04/2010; 93-D(4):702-712. DOI:10.1587/transinf.E93.D.702 · 0.21 Impact Factor
Show more