Abstract
The difficulties that software developers must face to understand and elicit clients’ and users’ necessities are widely known. The more complex the context of the problem, the more difficult the elicitation of software requirements becomes. Many times, requirements engineers must become themselves problem-domain experts during the acquisition of knowledge about the context of the application. The requirements engineering (RE) objective is to systematize the process of requirements definition (Maculay, 1993; Maté & Silva, 2005; Reubenstein & Waters, 1991) along with creating a compromise among clients and users with developers since they must both participate and collaborate together. The requirements engineering process consists of three main activities: elicitation, modeling, and analysis of the application domain (Kotonya & Sommerville, 1998; Sommerville & Sawyer, 1997). Later, requirements management deals with the changes in the requirements and the irruption of new ones. RE provides methods, techniques, and tools to help requirements engineers elicit and specify requirements, ensuring their highest quality and completeness. However, the problem of completeness is a certain menace to requirements quality and casts a serious doubt on the whole RE process. Completeness is an unreachable goal, and to estimate the degree of completeness obtained at a certain step in the project is even more difficult. The requirements engineer faces a universe of discourse (UofD) that he or she will hardly ever fully know. This situation is not unique during the whole software development process since something similar happens while testing. The use of statistical models to predict the number of defects in a software artifact was successfully introduced some time ago (Petersson, Thelin, Runeson, & Wohlin, 2003). In this article, the use of capture and recapture information is applied in the RE field in order to make an estimation of the number of undiscovered requirements after a requirements elicitation process. The following section analyses the validation problem in RE. Then, a section describing the use of LEL (languageextended lexicon) and scenarios in requirements engineering is included. After that, the problem of estimating closed populations is studied. Later, the use of capture and recapture in the RE domain is introduced, and finally, some future work and conclusions are presented.
TopBackground
The completeness problem in software engineering and requirements engineering is very similar to others in many knowledge areas. Otis, Burnham, White, and Anderson (1978) introduced a method to estimate the size of a closed population of wild animals based on the data gathered during repetitive capture of specimens. This method has been extended to the area of software inspections by several authors (Biffl, 2003; Briand, El Emam, Freimut, & Laitenberger, 2000; Thelin, 2004; Petersson, Thelin, Runeson & Wohlin, 2003; Wohlin & Runeson, 1998).
Requirements validation has become a complex task mainly due to the kind of representation models used, which requires clients and users with special skills to understand them. As it is pointed out by several authors (Cysneiros & Yu, 2003; Sommerville & Sawyer, 1997), the requirements validation seldom discovers all defects, which may reach later stages in the software development process. It has been proven that the use of natural-language representation for requirements helps validation, especially when requirements are expressed using the client user’s vocabulary (Leite & Franco, 1990). To be able to provide such representation, the requirements engineer should acquire the clients’ and users’ vocabulary. However, ambiguity is the main drawback of the natural-language approach (Berry & Kamsties, 2004; Jackson, 1995; Sommerville & Sawyer, 1997). The construction of a glossary of clients’ and users’ jargon helps reduce ambiguity and build requirements specification in an understandable language. Several experiences have shown that a glossary of the clients’ and users’ vocabulary is, in itself, a source of information to elicit valuable UofD information (Ben Achour, Rolland, Maiden, & Souveyet, 1999; Oberg, Probasco, & Ericsson, 1998; Regnell, 1999; Rolland & Ben Achour, 1998; Weidenhaupt, Pohl, Jarke, & Haumer, 1998).
Key Terms in this Chapter
Verification: It is the activity of checking different parts of a model or different models among them. It should answer the question “Are we creating the model right?”
Requirements Engineering: It is an area of software engineering that is responsible for acquiring and defining the capabilities of the software system.
Validation: It is the activity of contrasting a model with the actual world. It should answer the question “Are we creating the right model?”
Language Extended Lexicon: It is a semiformal model holding the most relevant words or phrases of the language of the application domain carrying a special meaning.
Elicitation: This is the activity of acquiring knowledge of a given kind during the requirements engineering process.
Scenario: This is a semiformal model describing observable situations in the current UofD or guessed situations that would take place when the software system is put into operation.
Requirements Management: It is the activity of following up on the evolution of the software system requirements set, and dealing with the allocation of requirements to specific pieces of the software and with the changes in the requirements along time.
Capture and Recapture: It is a method to estimate the abundance of members of a given class in a closed environment. Specimens are captured, marked, and released.