Article Preview
TopIntroduction
Most organizations use a standard set of steps, called the systems development methodology to plan, analyze, design, implement and maintain their information systems (Hoffer, George, & Valacich, 2005). One of the hardest parts of system’s development is deciding what the system should do, that is in determining the system requirements (Crowston & Kammerer, 1998, p. 227). In his classic essay “No silver Bullet”, Frederick Brooks (Brooks, 1975) noted that:
“The hardest single part of building a software system is deciding precisely what to build. No other part of the conceptual work is as difficult as establishing the detailed technical requirements, including all interfaces to people, to machines and to other software systems. No part of the work cripples the resulting system if done wrong. No other part is more difficult to rectify later.”
Thus getting the requirements right may be the single most important and difficult part of the software development process (Guinan, Cooprider, & Faraj, 1998). The key result of requirements problems is rework that implies redoing something that was already complete. Rework can consume 30 to 50 percent of total development cost (B. W. Boehm & Papaccio, 1988), and requirements errors account for 70 to 85 percent of the rework cost (Leffingwell, 1997). Figure 1 illustrates that it costs much more to correct a defect which is found late in a project than to fix it shortly after its creation (Grady, 1999; King & Marasco, 2008). Weigers (2003) asserts shortcomings in requirements practices can pose a great risk to a project success.
Figure 1. Variations in cost to fix a software defect
TopDistributed Requirements Engineering
As organizations become more ‘virtual’, distributed development will become more apparent throughout the entire lifecycle, including analysis of software requirements in the early stages of the development lifecycle (Evaristo, Watson-Manheim, & Audy, 2005). Ocker et al. (1995) reported the successful usage of computer conferencing to support groups working on determining software requirements in an asynchronous distributed environment.
As mentioned earlier, getting requirements right is a software project’s most important part (Hofmann & Lehner, 2001) and its success is critical for achieving project success (Bhat, Gupta, & Murthy, 2006). Despite the abundant literature available on globally distributed virtual teams (Powell, Piccoli, & Ives, 2004) and outsourcing (Dibbern, Goles, Hirschheim, & Jayatilaka, 2004; Yadav & Gupta, 2008), there are very few studies addressing requirements engineering activities like requirements analysis in distributed software development (Yadav, Nath, Adya, & Sridhar, 2007). Requirements analysis involves analysts working with end users/clients to understand the organizational information processing needs and develop IS objectives. Based on the gathered requirements, the analyst builds a model representing ‘what’ the customer requires which establishes a basis for creation of software design.