It is information acquired before or after the moment it is needed.
Published in Chapter:
Handling Extemporaneous Information in Requirements Engineering
Gladys N. Kaplan (Universidad Nacional de La Matanza, Argentina & Universidad Nacional de La Plata, Argentina) and Jorge H. Doorn (Universidad Nacional de La Matanza, Argentina & Universidad Nacional del Centro de la Provincia de Buenos Aires, Argentina)
Copyright: © 2009
|Pages: 5
DOI: 10.4018/978-1-60566-026-4.ch269
Abstract
The key of the success or failure of a software project depends on solving the right problem (Rumbaugh, 1994; Sawyer, 2005). Thus, software requirements should be correct, unambiguous, consistent, and as complete as possible (Institute of Electrical and Electronics Engineers [IEEE], 1998). Errors in requirements raise software development and maintenance costs notoriously (Katasonov & Sakkinen, 2006). The later the requirement error is detected, the higher the correction cost turns out to be. Error correction costs have been widely studied by many researchers (Bell & Thayer, 1976; Davis, 1993). Errors in requirements may be due to several reasons such as poor communication among requirements engineers, clients, and users; poor or nonexistent requirements validation; and the level of sternness of the models being used, especially to model relevant information captured from the universe of discourse (UofD). Requirements engineering is the area of software engineering responsible for proposing and developing solutions to elicit, model, and analyze requirements by means of heuristics, guidelines, models, and processes which tend to requirements’ completeness, quality, correctness, and consistency. Many proposals have been put forward by many researchers (Bubenko & Wrangler, 1993; Jacobson, Christerson, Jonsson, & Overgaard, 1992; Leite & Oliveira, 1995; Macaulay, 1993; Reubenstein & Waters, 1991).