Article

A Broad, Quantitative Model for Making Early Requirements Decisions.

IEEE Software 01/2008; 25:49-56. DOI: 10.1109/MS.2008.29
Source: DBLP

ABSTRACT 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.

0 Bookmarks
 · 
70 Views
  • [Show abstract] [Hide abstract]
    ABSTRACT: ContextChoosing a design solution most often involves dealing with trade-offs and conflicts among requirements and design objectives. Making such trade-offs during early stages of requirements and design is challenging because costs and benefits of alternatives are often hard to quantify.Objective The objective of this work is to develop a decision analysis method that assists in making trade-offs in the absence of quantitative data.Method In this method, stakeholders qualitatively compare consequences of alternatives on decision criteria. We propose an algorithm that generates all possible consequences of alternatives on requirements, according to the rough qualitative comparisons that stakeholders made. The possible consequences generated by the algorithm are then analyzed by the Even Swaps Multi-Criteria Decision Analysis method to determine the best solution. The Even Swaps method is a technique developed in management science to assist in multi-criteria decision making when explicit value trade-offs are not available.Results and conclusionsOur algorithm teases out the need to accurately measure or estimate costs and benefits of alternative design solutions. The algorithm automates the Even Swap process, and reuses stakeholders’ value trade-offs throughout the Even Swaps process. We applied the prototype tool in several case studies to evaluate the utility of the method. The results of case studies provide evidence that our decision aid method selects the optimum solution correctly compared to results of other similar quantitative methods, while our method does not rely on detailed numerical assessment of alternatives and importance weights of criteria.
    Information and Software Technology 06/2012; 54(6):517–530. · 1.52 Impact Factor
  • Source
    [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. 01/2010; 93-D:702-712.
  • Source
    [Show abstract] [Hide abstract]
    ABSTRACT: As the prevalence of software increases, so does the complexity and the number of requirements associated to the software project. This presents a dilemma for the developers to clearly identify and prioritize the most important requirements in order to deliver the project in given amount of resources and time. A number of prioritization methods have been proposed which provide consistent results, but they are very difficult and complex to implement in practical scenarios as well as lack proper structure to analyze the requirements properly. In this study, the users can provide their requirements in two forms: text based story form and use case form. Moreover, the existing prioritization techniques have a very little or no interaction with the users. So, in this paper an attempt has been made to make the prioritization process user interactive by adding a second level of prioritization where after the developer has properly analyzed and ranked the requirements on the basis of quality attributes in the first level, takes the opinion of distinct user’s about the requirements priority sequence. The developer then calculates the disagreement value associated with each user sequence in order to find out the final priority sequence.
    International Journal in Foundations of Computer Science & Technology (IJFCST). 08/2014;

Full-text (2 Sources)

View
15 Downloads
Available from
May 19, 2014