Alan M. Davis

Effectiveness of Requirements Elicitation Techniques: Empirical Results Derived from a Systematic Review

This paper reports a systematic review of empirical studies concerning the effectiveness of elicitation techniques, and the subsequent aggregation of empirical evidence gathered from those studies. The most significant results of the aggregation process are as follows: (I) interviews, preferentially structured, appear to be one of the most effective elicitation techniques; (2) many techniques often cited in the literature, like card sorting, ranking or thinking aloud, tend to be less effective than interviews; (3) analyst experience does not appear to be a relevant factor; and (4) the studies conducted have not found the use of intermediate representations during elicitation to have significant positive effects. It should be noted that, as a general rule, the studies from which these results were aggregated have not been replicated, and therefore the above claims cannot be said to be absolutely certain. However, they can be used by researchers as pieces of knowledge to be further investigated and by practitioners in development projects, always taking into account that they are preliminary findings

Identifying and measuring quality in a software requirements specification

Numerous treatises exist that define appropriate qualities that should be exhibited by a well written software requirements specification (SRS). In most cases these are vaguely defined. The paper explores thoroughly the concept of quality in an SRS and defines attributes that contribute to that quality. Techniques for measuring these attributes are suggested.<<ETX>>

A comparison of techniques for the specification of external system behavior

The elimination of ambiguity, inconsistency, and incompleteness in a Software Requirements Specification (SRS) document is inherently difficult, due to the use of natural language. The focus here is a survey of available techniques designed to reduce these negatives in the documentation of a software products external behavior.

The art of requirements triage

Driven by an increasingly competitive market, companies add features and compress schedules for the delivery of every product, often creating a complete mismatch of requirements and resources that results in products failing to satisfy customer needs. Triage is the process of determining which requirements a product should satisfy given the time and resources available. The author presents three product development case studies and 14 recommendations for practicing this neglected art.

Elicitation technique selection: how do experts do it?

Requirements elicitation techniques are methods used by analysts to determine the needs of customers and users, so that systems can be built with a high probability of satisfying those needs. Analysts with extensive experience seem to be more successful than less experienced analysts in uncovering the user needs. Less experienced analysts often select a technique based on one of two reasons: (a) it is the only one they know, or (b) they think that a technique that worked well last time must surely be appropriate this time. We present the results of in-depth interviews with some of the worlds most experienced analysts. These results demonstrate how they select elicitation techniques based on a variety of situational assessments.

Operational prototyping: a new development approach

The two traditional types of software prototyping methods, throwaway prototyping and evolutionary prototyping, are compared, and prototypings relation to conventional software development is discussed. Operational prototyping, a method that combines throwaway and evolutionary prototyping techniques by layering a rapid prototype over a solid evolutionary base, is described. Operational prototypings implications for configuration management, quality assurance, and general project management are reviewed. The application of operational prototyping to a prototype ocean surveillance terminal is presented.<<ETX>>

Status report: requirements engineering

It is argued that, in general, requirements engineering produces one large document, written in a natural language, that few people bother to read. Projects that do read and follow the document often build systems that do not satisfy needs. The reasons for the current state of the practice are listed. Research areas that have significant payoff potential, including improving natural-language specifications, rapid prototyping and requirements animation, requirements clustering, requirements-based testing, computer-aided requirements engineering, requirements reuse, research into methods, knowledge engineering, formal methods, and a unified framework, are outlined.<<ETX>>

Requirements engineering: In search of the dependent variables

When software development teams modify their requirements engineering process as an independent variable, they often examine the implications of these process changes by assessing the quality of the products of the requirements engineering process, e.g., a software requirements specification (SRS). Using the quality of the SRS as the dependent variable is flawed. As an alternative, this paper presents a framework of dependent variables that serves as a full range for requirements engineering quality assessment. In this framework, the quality of the SRS itself is just the first level. Other higher, and more significant levels, include whether the project was successful and whether the resulting product was successful. And still higher levels include whether or not the company was successful and whether there was a positive or negative impact on society as a whole.

Linking Requirements and Testing in Practice

An increasing number of organizations are interested in binding requirements and testing more closely together. Based on a series of practitioner interviews conducted in five Finnish organizations, this paper presents a set of good practices that can be applied to create a stronger link between requirements engineering and testing. These practices include early tester participation particularly in requirements reviews, setting up traceability policies, taking feature requests from testers into account, and linking testing personnel with requirement owners. Due to reported hardships in implementing complete test traceability to requirements, communication links between testers and requirement owners are suggested in order to overcome the deficiencies of document links.

Giving voice to requirements engineering

Developers have plenty of reasons to avoid investing in requirements engineering: It is next to impossible to capture user needs completely, and needs are constantly evolving. The gap between software research and practice is no more evident than in the field of requirements engineering. Requirement engineering has a fairly narrow goal - determine a need and define the external behavior of a solution - but the range of research into requirements is enormous. >