This article describes an evaluation of six different methods for prioritizing software requirements. Based on the quality requirements for a telephony system, the authors individually used all six methods on separate occasions to prioritize the requirements. The methods were then characterized according to a number of criteria from a user's perspective. We found the analytic hierarchy process to be the most promising method, although it may be problematic to scale-up. In an industrial follow-up study we used the analytic hierarchy process to further investigate its applicability. We found that the process is demanding but worth the effort because of its ability to provide reliable results, promote knowledge transfer and create consensus among project members. # 1998 Elsevier Science B.V.

The task of finding an optimal selection of requirements for the next release of a software system is difficult as requirements may depend on each other in complex ways. This paper presents the results from an in-depth study of the interdependencies within 5 distinct sets of requirements, each including 20 high-priority requirements of 5 distinct products from 5 different companies. The results show that (1) roughly 20% of the requirements are responsible for 75% of the interdependencies, (2) only a few requirements are singular, (3) customer-specific bespoke development tend to include more functionality-related dependencies whereas market-driven product development have an emphasis on value-related dependencies. Several strategies for reducing the effort needed for identifying and managing interdependecies are outlined. A technique for visualization of interdependecies with the aim of supporting release planning is also discussed. The complexity of requirements interdependency analysis is studied in relation to metrics of requirements coupling. Finall); a number of issues for further research are identified.

The process of selecting requirements for a release of a software product is challenging as the decision-making is based on uncertain predictions of issues such as market value and development cost. This paper presents a method aimed at supporting software product development organisations in the identification of process improvement proposals to increase requirements selection quality. The method is based on an in-depth analysis of requirements selection decision outcomes after the release has been launched to the market and is in use by customers. The method is validated in a case study involving real requirements and industrial requirements engineering experts.

The problem of requirements inter-dependencies resulting in conflicts and trade-offs is long known in the requirements engineering community. In this paper we discuss how such dependencies can be deduced from the semantics of requirements and how their traceability can be maintained when concerns are formed from initially unstructured requirements, or requirements are composed for analysis purposes. 1.

Context: To select the essential, non-negotiable product features is a key skill for stakeholders in software projects. Such selection relies on human judgment, possibly supported by structured prioritization techniques and tools. Goal: Our goal was to investigate whether certain attributes of prioritization techniques affect stakeholders ’ threshold for judging product features as essential. The four investigated techniques represent four combinations of granularity (low, high) and cognitive support (low, high). Method: To control for robustness and masking effects when investigating in the field, we conducted both an artificial experiment and a field experiment using the same prioritization techniques. In the artificial experiment, 94 subjects in four treatment groups indicated the features (from a list of 16) essential when buying a new cell phone. In the field experiment, 44 domain experts indicated the software product features that were essential for the fulfillment of the project’s vision. The effects of granularity and cognitive support on the number of essential ratings were analyzed and compared between the experiments. Result: With lower granularity, significantly more features were rated as essential. The effect was large in the general experiment and extreme in the field experiment. Added cognitive support had medium effect, but worked in opposite directions in the two experiments, and was not statistically significant in the field experiment. Implications: Software projects should avoid taking stakeholders’ judgments of essentiality at face value. Practices and tools should be designed to counteract biases and to support the conscious knowledge-based elements of prioritizing.

This paper outlines a systematic approach to defining, eliciting, and specifying the structure and the information content of the Electronic Health Record.

OF THE LICENCIATE THESIS Author and name of the thesis: Jarmo Hurri Using decision tools in deciding system product requirements: literature review and a behaviourally motivated lightweight tool Date: 3.9.2000 Number of pages: ii + 75 Department: Department of Computer Science and Engineering Professorship: Tik-76 Computer Science Supervisor: Professor Reijo Sulonen When system product requirements are decided, the objective is to set targets for properties of upcoming product releases. This problem has two important perspectives: it is both an investment problem and a goal setting problem for product development projects. From the investment point of view the objective is to select requirements that produce an optimal profit. From the point of view of goal setting, the objective is to set challenges for product development projects. The projects must strive to find e#cient technical solutions to these challenges. In decision making literature one can find a large set of...

Determining which requirements are selected for implementation of software applications is crucial to the satisfaction of customers. In a commercial setting, the value assigned by markets to a publicly held company is the ultimate measure of the degree to which the company meets its business goals -- satisfies its customers. We argue that portfolio theory provides a market driven, systematic, and more objective approach to selecting requirements and also accounts for uncertainty and incomplete knowledge in the real world. We illustrate through two examples, that the economic dimension is an important factor of software engineering decision-making because it facilitates the calibration of our estimates of limited resources. The underlying point is that the success or otherwise of software systems in commercial settings can be better ascertained by making the connection to market-assigned value explicit. Our particular application of portfolio-based reasoning is a step in contributing towards this objective.

Crime and disorder reduction (CDR) research analysts („analysts‟) in a UK local authority have generated suggestions for enhancing geovisualization prototypes designed using human-centred methods (Lloyd, Dykes and Radburn 2007; Lloyd, Dykes and Radburn 2008). Prioritising these candidate improvements is an important process and may require modification to established decision