Requirements engineering starts with requirements elicitation. This paper initially looks at what research has told us about requirements elicitation and what we still need to know. A study is proposed to further our understanding. Firstly it is clear that requirements elicitation has not been done well and that failure causes considerable problems. In 2006 C. J. Davis, Fuller, Tremblay, & Berndt found "accurately capturing system requirements is the major factor in the failure of 90% of large software projects," echoing earlier work by Lindquist (2005) who concluded "poor requirements management can be attributed to 71 percent of software projects that fail; greater than bad technology, missed deadlines, and change management issues". The cost of this failure is enormous. Another study found that failed or abandoned systems cost $100 Billion in the USA alone in 2000 (Browne & Rogich, 2001). Not only does a failed system cost money, but fixing mistakes made at requirements elicitation stage accounts for 75 percent of all error removal costs (Urquhart, 1999). What's hard about requirements elicitation? In comparing techniques for requirements elicitation a 2006 study suggested 22 different sources of difficulties with requirements (Table 1).
This list covers problems that occur because communication between humans is fraught with difficulty, but also problems that arise because the needs of an organization change with time and with possibilities that people only notice after they start thinking about the project. Many of our information systems theories make the assumption that requirements are a stable set and we only have to be smart enough to find them. This ignores the reality that organizations are dynamic and needs can be created as opportunities arise. This paper concentrates on the difficulties associated with the communication between humans which is a necessary part of requirements elicitation.
How can We Find Requirements?
There are so many methods suggested for requirements elicitation and analysis that it is not instructive to list them all. Two authors make a sensible attempt at classifying the various techniques. Maiden and Rugg (1996) present the acquisition of requirements (ACRE) framework of 12 elicitation techniques (Table 2).
Which Requirements Elicitation Method is Best?
We are indebted to A. Davis, Dieste, Hickey, Juristo, and Moreno (2006) for a fairly comprehensive review of the research into requirements elicitation. This review classified research in terms of rigour and both the question being asked and the results of the research. Their review found some research results that were consistent enough to draw conclusions that might be generalized. These included:
* Structured interviews gather more information than unstructured interviews.
* Unstructured interviews gather more information than sorting and ranking techniques
* Interviewing is cited as the most popular requirements elicitation method
Method for this Study
Given that research efforts have found that interviews are the most effective way of obtaining requirements, an obvious research question is "what do we know about making interviews most effective?" Following the method of (A. Davis, Dieste, et al., 2006) a search of research publications was made in February 2007. 796 online databases were sampled which include ABI/Inform Global (ProQuest), Academic Research Library (ProQuest), APAFT: Australian Public Affairs--Full Text (Informit), Business Source Premier (EBSCO), Communication & Mass Media Complete (EBSCO), Emerald Management Xtra (Emerald), Expanded Academic ASAP (Gale), Factiva, ACM library and the IEEE Library. In addition Google scholar was used, which returned some thesis material not available through the databases. A search was made for refereed articles using the keywords "requirements", "information system requirements", "requirements analysis", "information systems + dialogue" and "interview. …