Existing literature (Boehm, 1981; Brooks, 1987; Cook, 2002) and empirical studies (Basili & Perricone, 1984; Emam & Madhavji, 1995; Marshall & Rossman, 1989) emphasize the importance of the Requirement Engineering (RE) activities as these activities have a strong and positive correlation with the success of most software projects. Four of the ten main success factors deal with RE: user involvement, clear business objectives, minimized scope, and firm basic requirements. RE can be broadly defined as the process of discovering, identifying, and documenting the actual customer needs (Nuseibeh & Easterbrook, 2000). This chapter focuses on Requirements Management (RM), one of the main activities in the RE process. RM is about organizing the information and requirements gathered during the RE process and managing changes of these requirements (Grehag, 2001).
Top15.1 Introduction
Existing literature (Boehm, 1981; Brooks, 1987; Cook, 2002) and empirical studies (Basili & Perricone, 1984; Emam & Madhavji, 1995; Marshall & Rossman, 1989) emphasize the importance of the Requirement Engineering (RE) activities as these activities have a strong and positive correlation with the success of most software projects. Four of the ten main success factors deal with RE: user involvement, clear business objectives, minimized scope, and firm basic requirements.
RE can be broadly defined as the process of discovering, identifying, and documenting the actual customer needs (Nuseibeh & Easterbrook, 2000).
This chapter focuses on Requirements Management (RM), one of the main activities in the RE process. RM is about organizing the information and requirements gathered during the RE process and managing changes of these requirements (Grehag, 2001).
As AMs and OSD highlight, one of the most challenging aspects of RM is that the requirements gathered are seldom static. They are likely to change over time, during the project phases and during maintenance (Berry, 2002; Harker & Eason, 1992). Consequently, changes to requirements must be managed during the whole lifecycle of a product starting early in the elicitation phase (Lauesen, 2002).
Managing changing requirements is a critical activity. In fact, requirements changes impact on costs and time. Consequently, they affect the uncertainty and risk of a project (Cook, 2002; Lubars et al., 1993; Stark, 1998).
Furthermore, the level of requirements uncertainty and variability may affect the choice of the development approach to employ in a project (MacCormack & Verganti, 2003). Because of this, AMs have been proposed in order to deal with changing requirements. These methods should help companies deliver valuable software in situations with constant change and turbulence (Highsmith, 2002).
There are two main strategies to deal with changing requirements (Saiedian & Dale, 2000; Grehag, 2001):
- 1.
Defensive strategy: Trying to reduce or avoid changes (e.g., using an effective requirements definition strategy).
- 2.
Reactive strategy: Managing properly the changes that actually occur (e.g., including support to changes into the product or process adding flexibility).
We focuses on both the defensive and the reactive strategy. In order to understand how to implement a defensive strategy, we have analysed the factors that lead to change the requirements. In fact, addressing properly these factors allow companies to improve their requirements definition process and, consequently, reduce the amount of change requests. Furthermore, to understand how to manage inevitable requirements changes, we have investigated how software companies consider and deal with requirements variability.
To address these issues, an empirical investigation has been performed interviewing personnel of 35 software companies. The final findings of our survey highlight some potential areas to improve RE and some suggestions for RM.