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).
TopBackground
Eliciting and modeling software requirements or related information are two different but highly related activities (Hull, Jackson, & Dick, 2005; Zowghi & Coulin, 2005). They may be coupled in several ways, being canonicals, such as in model-driven elicitation and elicitation-driven modeling. In the former, the requirements engineer tries to capture only the information that he or she needs for the model under construction. In the latter, the requirements engineer creates all models at the same time recording every piece of information gathered in the model it belongs to. Each of these approaches has advantages and drawbacks.
If the information is elicited for a given model, the requirements engineer pays attention only to some part of the things he or she is seeing, reading, or hearing. Then, he or she will discard any information that is not focus oriented. When the requirements engineer starts the creation of another model, he or she will change the focus and perhaps will now pay attention to information previously disregarded, provided that he or she comes across the same information. Unfortunately, this does not always happen, especially when the source of information is people. In other words, model-driven elicitation tends to make completeness difficult.
If all information obtained is registered at the same time, every model of the process is opened at the same time, and also, none are finished during an important period. A lack of coherence among models, poor understanding of the information gathered, and misplaced information are the main drawbacks of this approach. However, the loss of information is minimized.
Most researchers explicitly or implicitly prefer model-driven elicitation over elicitation-driven modeling (Leite, Hadad, Doorn, & Kaplan, 2005; Loucopoulos & Karakostas, 1995; Potts, Takahashi, & Antón, 1994). This means that model-driven elicitation has to deal with the risk of information loss. Looking closely into such risk, it can be seen that regardless of the elicitation technique, whether involving document reading, interviews, observation, or any other method (Goguen & Linde, 1993), the requirements engineer does not get exactly whatever he or she is looking for at any time in the information gathering activity (Faulk, 1996). He or she will need some of the information captured in the later stages of the process; however, he or she also needs some of that information in advance. In other words, some of the information gathered is out of time (earlier or delayed). Dealing with the risk of loss of information means dealing with extemporaneous information (EI).
Key Terms in this Chapter
Advanced Information: It is information acquired when it is not yet needed.
Extemporaneous Information: It is information acquired before or after the moment it is needed.
Requirements Modeling: It is the activity that represents, organizes, and registers the information gathered during elicitation. The model itself may be composed by more than one representation.
Requirements Engineering: It is an area of software engineering that is responsible for acquiring and defining the software system’s needs. The aim of requirements engineering is to improve the way in which the services should behave in the future. It covers all activities involved in discovering, understanding, modeling, analyzing, and maintaining the set of requirements for a software system.
Sources of Information: These include documents, key people, books, and so forth that can provide useful information about the subject matter under study.
Retarded Information: It is information acquired after the moment it is needed.
Elicitation: Elicitation is the activity of acquiring knowledge of a given kind during the requirements engineering process. There exist several techniques for elicitation such as interviews, observation, and document reading, among others.