TopIntroduction
The Requirements Engineering (RE) goal is to systematize the process of requirements construction and management (Maculay, 1993; Reubenstein & Waters, 1991; Maté & Silva, 2005) along with the creation of a compromise among clients and users with developers, since both human groups must participate and collaborate together. To accomplish such tasks, the requirements engineers should understand and participate in the definition of the context of use for the software system to be developed. The requirements engineers usually ignore totally or partially both, the current and the foreseen future context of use. The latter must be conceived having as a resource the new tool: the system software itself. Frequently, nobody knows in detail such future context of use. To be able to participate in the definition of the future business process, the requirements engineers must understand the current business process in advance. Therefore, the Requirements Engineering process involves, as the first step, elicitation and modeling of the current business process and later, definition and modeling of the future business process. Both models have different purposes. The first one is used as a help for understanding the current business process and as a tool to validate with clients and users such understanding. The second one is used as a help for the planning of the future business process, to validate such plans with the clients and users, to specify the software requirements and to give an environment reference for software designers.
The Requirements Engineering process consists of three main activities: elicitation, modeling, and analysis of the application domain (Kotonya & Sommerville, 1998; Sommerville & Sawyer, 1997). Analysis includes the sub-activities of verification, validation and negotiation. The difficulties that requirements engineers must face to understand and elicit the clients and users’ necessities are widely known. The more complex the application domain, the more difficult the definition or construction of software requirements becomes. Many times, requirements engineers must become themselves problem domain experts during the acquisition of knowledge about the application domain. Concurrently, Requirements Management deals with the changes in the existent requirements and the irruption of new ones (Kotonya & Sommerville, 1998; Sawyer & Kotonya, 2004).
RE provides methods, techniques and tools to help requirements engineers elicit and specify software requirements, ensuring their highest quality and completeness. However, the problem of completeness is a certain menace to requirements quality and it casts serious doubt on the whole Requirements Engineering process. Completeness is an unreachable goal and to estimate the degree of completeness obtained at a certain step in the software development process is also very difficult (Doorn & Ridao, 2008). The requirements engineer faces a Universe of Discourse (UofD) that seems she / he will hardly ever fully know. This situation is not unique during the whole software development process; something similar happens while testing.
The use of statistical models, based on capture and recapture methods (Otis, Burnham, White, & Anderson, 1978) to predict the number of defects in a code artifact, was successfully introduced some time ago (Petersson, Thelin, Runeson, & Wohlin, 2003) and later, these models have been used to discover defects in requirements documents (Walia & Carver, 2008). 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 non-discovered requirements after a requirements elicitation process.
The following section analyses the validation problem in RE. Then, a section describing the use of the Language Extended Lexicon (LEL) and Scenarios in RE is included. After that, the problem of estimating closed population is studied. Later, the use of capture and recapture in RE domain is introduced; finally, some future work and conclusions are presented.