Dealing with Completeness in Requirements Engineering

Abstract

The Requirements Engineering (RE) goal is to sys-tematize 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 develop-ers, since both human groups must participate and collaborate together. To accomplish such tasks, the requirements engineers should understand and par-ticipate 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 busi-ness 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 & Som-merville, 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)