Object-Oriented Requirements Engineering and Management
Joseph E. Kasser DSc, CEng, CM, MIEE Systems Engineering and Evaluation Centre University of South Australia (UniSA) Mawson Lakes South Australia, 5095 Joseph.firstname.lastname@example.org Abstract Object-Oriented requirements engineering is an approach to encapsulating information about the process and product, as well as functionality into a requirements object. This paper identifies properties of a requirement object based on information in the process (development, management and test and development streams of work in the system life cycle (SLC) as well as information about the product needed. The paper also describes some of the functionality that could be added to the requirements object. The paper concludes that Object-Oriented requirements engineering and management can effect a significant reduction of the problems currently encountered in the SLC due to poor requirements engineering and management. Background The systems and software development industry is characterized by a paradigm of project failure (Standish 1995). The situation has been described by Cobb’s Paradox (Voyages 1996), which stated “We know why projects fail, we know how to prevent their failure --so why do they still fail?” One of the known contributing causes of these project failures is poor requirements engineering and management, which has been repeatedly and widely discussed and documented for at least 10 years (Hooks 1993; Kasser and Schermerhorn 1994; Jacobs 1999; Carson 2001; etc.). However, this continual documentation and discussion of the problem of poor requirements engineering and management has not resulted in a practical solution to the problem. This paper contains a preliminary introduction to an Object-Oriented approach to requirements engineering that might help to reduce the contribution of poor requirements engineering and management to project failures. Requirements engineering and management Requirements engineering and management is evolving. Dorfman and Thayer (1990) stated the definition of requirements engineering as “the science and discipline concerned with analysing and documenting requirements”. Kotonya and Sommerville (1998) restated the definition of requirements engineering as “the systematic process of eliciting, understanding, analysing, documenting (and managing) requirements”. In effect, they expanded the definition to include the elicitation process as well as the managing process. There has since been recent recognition that a requirement is more than just the imperative statement. For example, both Alexander and Stevens (2002) and Hull et al. (2002) discuss additional properties of the text-based requirement (e.g. priority and traceability) in conjunction with improving the writing of requirements. The IEEE Computer Society Computing Curriculum Software Engineering --- Public Draft 1 --- (July 17, 2003) Software Engineering Education Knowledge Software states “Requirements identify the purpose of a system and the contexts in which it will be used. Requirements act as the bridge between the real world needs of
Systems Engineering Test and Evaluation (SETE) Conference, Canberra, October 2003
users, customers and other stakeholders affected by the system and the capabilities and opportunities afforded by software and computing technologies. The construction of requirements includes an analysis of the feasibility of the desired system, elicitation and analysis of stakeholders' needs, the creation of a precise description of what the system should and should not do along with any constraints on its operation and implementation, and the validation of this description or specification by the stakeholders. These requirements must then be managed to consistently evolve with the resulting system during its lifetime.” However, in practice, there is difficulty...